Отдал бы и ползарплаты! Войти !bnw Сегодня Клубы
Привет, TbI — HRWKA! 1185.5 пользователей не могут ошибаться!
?6622
прекрасное6359
говно5764
говнорашка5432
хуита4524
anime2946
linux2543
bnw2515
music2442
log2224
рашка2208
ололо1853
pic1780
быдло1429
сталирасты1422
украина1398
дыбр1212
гімно1158
bnw_ppl1068
дунч1041

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Wed Jul 29 2020 22:55:23 GMT+0200 (Central European Summer Time) Posted as new post Clubs: Tags: *it *развитие *коучинг *обучение *programming Хочется осветить один важный, но часто незаметный и упускаемый из виду аспект разработки кода ( на самом деле работает и вне кода, но с кодом будет нагляднее ). Многие энтузиасты программирования, в основном конечно джуниоры, но встречается и среди системных архитекторов ( я видел ), начиная разработку очередного продукта как то не задумываются о его lifecycle ( как долго будет разрабатываться? как долго будет востребован? известно ли его "конечное состояние" или можно будет развивать бесконечно? ... ), в итоге на архитектуру конечно не забивают, но стараются не слишком ей заморачиваться на ранних этапах, стремясь побыстрее получить результат или как то балансировать между результатом и проработкой архитектуры ( этому чем-то способствует философия Agile, особенно если человек неправильно её понимает ). Сразу скажу, что здесь речь пойдёт о проектах, которые: 1) технически сложные 2) не имеют ограничений по срокам ( либо сроки очень большие ) 3) потенциально могут стать продуктом, который можно продолжать развивать бесконечно и сейчас не ясно где развитие продукта закончится В самом начале такого проекта нужно понимать, что результаты - не цель ( как парадоксально бы это не звучало ), цель - ускорение/упрощение получения результатов в будущем. Будущем, да. Про настоящее здесь нужно забыть, и расставляя приоритеты - не думать "какой результат это принесёт", а "каким образом это облегчит дальнейшее получение результатов". При этом облегчение получения результатов само по себе является результатом, так что выходит как бы бесконечная рекурсия, но каждый следующий виток упрощает следующие ( да-да, и может наступить момент, когда уже просто нечего оптимизировать/упрощать и вот тогда это самые "результаты" и начинаются, как бы сами собой, быстро, легко и экспоненциально ). Но не будем забегать вперёд. Вот, нарисовал небольшую инфографику для наглядности - https://tinystash.undef.im/il/5BUy29qSa7HaGuKJt6KgbjZ565uaMJMdDghgCNkYswNZiyFZBpEkxjuNd6Ft9HA3mVgMBjZ6hWugK8SQckth8JFz.png , кстати, основано на реальных событиях, конкретные проекты упомянуть пока не буду но оба находятся в начале пути, и, как вы уже наверно догадались, один из них уже имеет _видимый_ прогресс, а во втором пока вообще непонятно что происходит и происходит ли ( да ещё и код закрыт ). Почему так, почему людям так хочется гнаться за результатами? Если это не внешнее ограничение, например, сроки полученные от инвестора ( кстати, одна из причин, почему многие стартап-компании делают продукт "на отьебись", нет нет они не обманывают инвестора умышленно, но он им даёт требования и сжатые сроки и у них нет выбора, а заработать хочется, вот и получается, что инвестор вовремя получает продукт, который он хотел, но чуть позже выясняется, что одно нужно исправлять, другое переписывать, а через какое то время - что выгоднее уже вообще всё переписать, чем платить за постоянный мэйнтенанс ( при этом если первоначальный продукт был достаточно успешен и принёс прибыль то это происходит и дальше всё идёт гладко, но чаще конец печален ) ), то вторая по распространённости причина - неуверенности в себе как программиста. Начиная непривычный, или просто более сложный, чем обычно, проект ( особенно если это проект одного разработчика ( или маленькой команды ) ), человек постоянно ощущает сомнения - а получится ли? а смогу ли?, и чтобы их преодолеть ему нужно регулярно видеть _видимый_ прогресс, а это значит, что первым делом он пытается пробиться к ( если это игра ) геймплею, как к глотку свежего воздуха. Когда это происходит ( если происходит ), выделяется дофамин, человек радуется ( "у меня всё получается!" ), и потом пытается как то "натянуть" на то что есть ( что часто является 'Proof of Concept' и в принципе дальше развиваться не может без переписывания большей части кода ) какую-то архитектуру. Но, вот незадача, дофамин возвращается на место, человек замечает, что вроде работает, тратит время, силы, а визуально ( геймплей ) ничего не меняется, ничего нового не добавляется. Становится грустно и неприятно заниматься архитектурой, а приятно - добавлять больше и больше геймплея или чего-то видимого. И возникает порочный круг - те сопли ( архитектурой это не назвать ), на которых сейчас всё держится, могут выдерживать добавление новых фич только ценой роста технического долга ( который уже и так немаленький ), но если начать заниматься техническим долгом - портится настроение, снижается энтузиазм ( "я не этим скучным переливанием из пустого в порожнее хотел заниматься!" ) и рано или поздно желание продолжать проект заканчивается ( да, это результат 99%, если не 100%, таких проектов основанных на энтузиазме от _видимого_ прогресса ). Некоторые бросают сразу ( иногда начиная новый проект и наступая на те же грабли ), некоторые пытаются выжать из того что есть всё, что можно, ценой многочисленных хаков и прочих отвратительных практик ( а иногда потом ещё и продать ), но результат один. Что делает грамотный системный архитектор? Системный архитектор не спешит. Он _уже_ видит результаты в будущем, потому что понимает, что грамотно и вовремя спроектированная архитектура позволит ускорять скорость дальнейшей разработки экспоненциально ( или близко к этому ). Какая разница, что уже месяц нет видимых результатов? Постоянное улучшение архитектуры ускоряет дальнейшее её улучшение, а также облегчает добавление фич и тех самых результатов, за которыми гонятся неуверенные в себе джуниоры в самом начале проекта. Единственное, что интересно на ранних стадиях проекта - ускоряется ли ускорение разработки? Если ускоряется - всё в порядке. Но когда же начинать добавлять сами результаты? Здесь два способа - либо когда это становится уже настолько легко и быстро, что почти не занимает времени, либо использовать формулу вида "чем ближе архитектура находится к состоянию, в котором она сможет поддерживать добавление всех фич, запланнированных в проекте, тем больше внимания можно уделять добавлению этих самых фич по сравнению с улучшением архитектуры". Второй способ является более сбалансированным и часто оптимальным, но если у проекта нет видимого конца жизни ( или он ещё неизвестен, или выглядит, что проект можно будет развивать бесконечно ) то первый предпочтительнее чтобы такой вот "конец жизни" проекту не создать самому. Конечно, есть здесь и подводные камни. Во-первых, может возникнуть over-engineering архитектуры, вплоть до состояния когда сам автор не в состоянии разобраться, что делает какой-то элегантный, но уж очень хитросплетённый код. Решение - балансировать техническую сложность частей кода, и не давать ей концентрироваться в одном месте, вовремя разделяя на более простые компоненты ( даже ценой потери некоторой элегантности ). Во-вторых, может возникнуть другая крайность - когда код настолько сильно фрагментирован, что изменения приходится делать во многих файлах ( которые ещё надо найти ). Решение - наоборот 'концентрировать' какие-то разрозненные части кода в ключевых местах, желательно там, где возможно какое-то элегантное решение, позволяющее уменьшить общий объём кода. Умение балансировать между этими двумя крайностями приходит только с опытом, здесь нет универсальной формулы. Иногда можно ориентироваться по ощущениям - если ощущается неудобство от постоянных поисков по коду - можно сконцентрировать, если ощущается дискомфорт от необходимости напрягаться, чтобы разобрать хитросплетённый шедевр - можно разбить на более простые части. Есть ещё зависимости от IQ, опыта программирования в целом и в конкретном языке, или в конкретной сфере ( например геймдев или веб ) - чем они выше, тем код продукта может быть сложнее, а, следовательно, элегантнее и его объём будет меньше. Нужно также учитывать других разработчиков, если имеются или если планируется подключить в будущем. Чем сложнее код - тем сложнее будет найти разработчиков ( кстати, вопреки распространённому мнению говнокод - самый простой для понимания вариант кода и разобраться в нём может практически любой ( другое дело что его архитектура ( точнее, её отсутствие ) постоянно способствует появлению багов от любого, казалось бы, несвязанного с этим, изменения ) , просто по ощущениям это как в говне копаться, хотя тут тоже зависит от разницы между уровнем говнокодности и например IQ человека, которому нужно будет с этим возиться, совсем зелёный джуниор может даже и не догадаться, что с кодом что-то не так ). В общем, надеюсь эти небольшие мысли вслух направят начинающих джуниоров-энтузиастов на правильный путь и позволят удасться тем их проектам, которые иначе провалились бы про причинам, описанным выше. ! protected by SuperBnW ( https://github.com/afwbkbc/superbnw ) ! Public key: https://github.com/afwbkbc/gpg/blob/master/5122E95DCC3CF31CE9F75D956AF7D685006F5088.asc -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEUSLpXcw88xzp912VavfWhQBvUIgFAl8h4jsACgkQavfWhQBv UIjYEgv/QnMfp3EY0oEyzgmxpEwHZZ75+MULMpUAZC9ey6QMsNYckK5eHcDJ1pki 7J9eZ6Y/6sLuAP0j7GfZhrpPOE8XmigGDsJcvLXvDmWx6LQ3tvWDda4Q0Tzcv3DA 4O+ehwCKafS5z93zHCO1Wlo2gaKyLGvpxGwPSF/yTMBjePcRJ0ibPlp87Il6H2gA 321Y1AcbMf6dmppmHL85jhpM9kA28UjqZSLjWVlELeVBcMzuYJjzQoTIi0k3gu+D Ms8xgCbDc7Hm+Sa6HVko2qIeWdh3TrCD7aYzqWjIlHvTjcP4ahQjY2YFcY9TFX2Z xwblPpoMD06sFmDQ5uY2mOKb+rAKfHaqjFho2iHlRDtFZYZZ8+KA6tFC5jYtXIHA gmk2aP1DaYQKNsIRj3dPYfujGGd+not7SazCEawBz5YvqD15twvn0VkNyzU2XRbE cipsbC7bYj01UNn7w+eBAjwwzI4rMP0dqeeJSyC88G62+yy6DXzIAPWVHyphB6Jy O/a4D0cu =x8Uc -----END PGP SIGNATURE-----
#YFXPYP (0) / @n / 88 дней назад

Обнаружил ФАТАЛЬНЫЙ НЕДОСТАТОК программы на главной https://learnbchs.org/index.html

main(int argc, char *argv[]) спокойно меняется на main() и экономит вам аж 22 байта в исходниках (если вы прогрессор и юзаете UTF8) и 8 байт в выпуке gcc.

Больше не зайду на этот сайт. Говно зделоно тупо.

#V0XHX4 (0) / @bazar / 419 дней назад
Блэд, для некоторого дерьма вроде лечения спидорака или рассчёта траекторий астероидов придется брать стек, похожий на BCHS, и делать из него LCXXNS(с подмножествами OpenCL|CUDA).
#TLPTPQ (0) / @tk1teasy / 644 дня назад
https://pp.userapi.com/c845221/v845221211/be4cb/cAXKhob1FO8.jpg Если вдруг окажетесь на разработке, запомните одно простое правило. Тимлид, который выглядит, как Билл Гейтс - умная рожа, понтовый телефон, понтовая мышь, хинкпад, флешки-брелки, дешевый smart watch напоказ и ботанские очки - это, как правило, плохой тимлид. Фронтендщик, скорее всего. Настоящий тимлид выглядит как бомжара привокзальный. Внешняя атрибутика ему совершенно не нужна. Вот таким можете доверять смело. Не подведут. А эти в проде еще не были. Сразу видно. Слишком много понтов. В штабе платона полно разработчиков. Какие-то мальчики и девочки в шортиках и футболочках. Ноутбуки. ЗГ-интернет. Панамки и бейсболки. Спутниковые телефоны. Оборудования на килотонны баксов. Оптика. LTE. Информационщики. Что-то вещают. Что-то пишут. Что-то передают. Долго смотрю на них и никак не могу врубится. Кто они? Что они здесь делают? Программисты? Про раз-работку ра-а-ссказывают? Блин, инопланетяне какие-то на хрен... Еще один совет - если программист выглядит вот так и пахнет шампунем - это хреновый программист. Настоящий программист тоже выглядит как бомжара. И пахнет так же.
#20KCEN (8+1) / @anarchy / 780 дней назад

https://github.com/dhall-lang/dhall-lang
кто-нибудь успешно юзал?

#JV2CON (0) / @ninesigns / 835 дней назад

В тред призываются люди, состоящие одновременно в следующих множествах:

I. люди, разрабатывающие (или делавшие это в прошлом) нетривиальный софтверный проект (не хуйню в стол) в команде (т.е не аутизм в одно ебало) больше одного года;

II. люди, считающие, что правильная архитектура ПО, абстракции, использование UML-хуйни, диаграмм классов для обмена идеями и фиксирования архитектурных решений нахуй не упали.

Так вот I U II, можете начать в коментариях обосновывать, почему вы не долбоебы, например.

#FIULH2 (61) / @ninesigns / 933 дня назад

Почти все охуенные разработчики, которых я встречал (ирл или в интернетах) обладают двумя признаками:
1. шарят в численных методах
2. могут разобраться в любом самом страшном говнокоде

Буду продолжать наблюдения

#SLC0AS (19+1) / @ninesigns / 957 дней назад
После нескольких месяцев унылых ковыряний до кое-кого дошло что `filter_map` просто "нинужен" в strymonas, т.к. `filter |> map` (самое лобовое решение) метакомпилируется просто всегда лучше. Т.е. как это часто бывает - вопрос изначально поставлен был неправильно и нужно было таки выйти из системы, чтобы увидеть очевидное решение к несуществующей проблеме. Небесполезный экспириенс, каждый раз..
#8PY9II (0) / @ygrek / 1034 дня назад

Почему julia дает пизды вашим любимым* язычкам программирования.

https://julialang.org/blog/2017/01/moredots

Используя dot call как здесь:

X .= f.(2 .* X.^2 .+ 6 .* X.^3 .- sqrt.(X))

или

@. X = f(2X^2 + 6X^3 - sqrt(X))

Вы эксплицитно требуете от компилятора сгенерировать объединить циклы и сгенерить векторизированый код, который не будет делать промежуточных аллокаций массивов.

Данный подход можно заставить работать и для своих контейнеров, для этого нужно будет реализовать функцию, которая будет работать селектором для данных из вашего контейнера.

Кроме того, есть возможность при помощи библиотеки GPUArrays обсчитывать массивы на opencl/cuda, используя тот же самый код, как и для обычного кода, но используя специальные типы. Все благодаря multiple dispatch и макросистеме.

[*] кроме, пожалуй, хаскеля, если ghc сделает loop fusion и вы не обосретесь с ленивостью

#BD4GXR (37+5) / @ninesigns / 1064 дня назад

https://blog.racket-lang.org/2017/10/racket-v6-11.html

Typed Racket supports refinement types and dependent function types. Previously
an experimental feature, refinement types allow types to describe more
interesting properties of values, especially integers. For example, this type
shows that the max function always produces a number at least as big as its
inputs:

(-> ([x : Integer] [y : Integer])
(Refine [z : Integer]
(and (>= z x) (>= z y))))

#JMH83R (6) / @ninesigns / 1090 дней назад
>Прохладная: компания наняла аджайл-коча, чуваку 60+ (<тут был линк на его профиль>), в принципе интересный background, программировал В СВОЕ ВРЕМЯ на smalltalk и lisp, есть в старой голове какие-то интересные мысли. Но. В обязательном порядке согнали всех слушать курсы старого пердуна. Дед массово топит за классическое ООП времен Гради Буча. Риторика уровня "есть только мой правильный путь решить задачу, все остальное неправильно". Самое интересное, дед умудряется эффективно паразитировать на компаниях своим религиозным промыванием мозгов. Он реально похож на какого-то сектанта, избегает конкретики и придерживается размытых формулировок, которые дают ему свободу выкручиваться из каверзных вопросов.
#LR1N9C (0+1) / @ckorzhik / 1117 дней назад

Короче copy-pastные ошибки заебали, хочу мод в емаксе, который подсвечивает похожести в скопипащеных строках, может уже есть такое?

#NKD460 (27) / @ninesigns / 1139 дней назад
https://github.com/Lovesan/clave Такое. Красивый и удобный лисповый интерфейс к библиотекам FFmpeg. В процессе, но кое-что работает уже. Пока не хватает swresample и swscale, но скоро будет. Также, потом отдельной asdf-системой будет postroc, т.к. она загплена. Еще с документацией пока проблемы, как впрочем и у самого ffmpeg. Тестируется все на винде, под FFmpeg 3.2.4, собранный мной лично: https://static.lovesan.ru/ffmpeg/ffmpeg-3.2.4-win64-lgpl.zip Но, в принципе, ничто не мешает работать и с линуксом, надеюсь я там правильные имена файлов so-шек вписал, в src/lib.lisp В README.md там пример, типа, берем, и конвертируем любое медиа, поддерживаемое FFmpeg, и у которого есть звуковой поток, в mp3-файл.
#WTCEXP (2) / @lvsn / 1178 дней назад

Хуевый дизайн?
Нет времени разбираться кто владеет временем жизни объекта?
Хочется применить чего-нибудь такого новенького?
Не уверен в собственной job security?

std::shared_ptr - твой выбор!

#6HKTWG (5+2) / @ninesigns / 1182 дня назад
ipv6 ready BnW для ведрофона BnW на Реформале Викивач Котятки

Цоперайт © 2010-2016 @stiletto.