Size: a a a

2021 January 18

A

Alex in ctodailychat
Igor V
По-моему речь шла о другом. О том, что не нужно специально усложнять.

Многие бойцы в попытках написать типа умный код усложняют код и как следствие усложняют систему на ровном месте. Они неплохо умеют писать код, но пока еще не умеют строить системы, которые всегда работают.

Типичный пример такого типа умного кода -  это когда нужно забрать файл с S3/FTP и вместо того, чтобы явно принять путь до файла, эти ребята переносят бардак из своей головы в код и реализуют неявную логику генерации путей до файла аля /opt/output/" + today.strftime(‘%Y%m%d’). Happy debugging, testing and maintenance.

Треды, локи и блокирующие очереди там где можно обойтись новым процессом. Типа умная обработка ошибок, когда со своей стороны мы ничего уже не можем сделать вместо того чтобы громко упасть. Кафки, кубернетисы, микросервисы, микрофронденты и другие слова на К и М это скорее всего усложнения там, где это совершенно не нужно.

Надежная система собирается как конструктор и базируется на простых и скучных компонентах, а не наоборот.
#fomo
источник

ИМ

Илья Макеев... in ctodailychat
Alex
у меня карбон (черная с красной подсветкой, как у @Onlinehead )

свичи супер, но очень ненадежные - CTRL все время ломается. уже пару раз заказывал с амазона/аликспресса.

сейчас купил вторую точно такую же - на запчасти)) но свичи классные, потому что у этих свичей led посреди кнопки. Это очень удобно. У новых логитектов новые свичи - romer GX. У них, как и у черри, лед "сверху" и поэтому подсвечивается только "врехний" ряд символов на цифрах. И это ппц неудобно.

Я стал изучать вопрос и обнаружил, что у всех механических клав с подстветкой это общее место. Светится только верх. Это ппц((( Собственно, потому и купил вторую, пока с производства не сняли((
я правильно понял что проблема в том что кнопки снизу не подсвечены?)
источник

A

Alex in ctodailychat
Илья Макеев
я правильно понял что проблема в том что кнопки снизу не подсвечены?)
вот смотри, слева g413, справа любая мех.клава в мире
источник

ИМ

Илья Макеев... in ctodailychat
ааа
источник

A

Alex in ctodailychat
у  g413 светится и цифра "9" и скобка. у остальных только "9"
источник

ИМ

Илья Макеев... in ctodailychat
да я да понял уже
источник

ИМ

Илья Макеев... in ctodailychat
просто нет рядом черри и непонятно было)
источник

A

Alex in ctodailychat
это потому что у большинства свичей led в верхней части. иногда производители клав извращаются вот так - но это тоже бред


сорри, вы призвали в чат клаво-задрота, больше не буду
источник

KS

Kirill Sulim in ctodailychat
Igor V
По-моему речь шла о другом. О том, что не нужно специально усложнять.

Многие бойцы в попытках написать типа умный код усложняют код и как следствие усложняют систему на ровном месте. Они неплохо умеют писать код, но пока еще не умеют строить системы, которые всегда работают.

Типичный пример такого типа умного кода -  это когда нужно забрать файл с S3/FTP и вместо того, чтобы явно принять путь до файла, эти ребята переносят бардак из своей головы в код и реализуют неявную логику генерации путей до файла аля /opt/output/" + today.strftime(‘%Y%m%d’). Happy debugging, testing and maintenance.

Треды, локи и блокирующие очереди там где можно обойтись новым процессом. Типа умная обработка ошибок, когда со своей стороны мы ничего уже не можем сделать вместо того чтобы громко упасть. Кафки, кубернетисы, микросервисы, микрофронденты и другие слова на К и М это скорее всего усложнения там, где это совершенно не нужно.

Надежная система собирается как конструктор и базируется на простых и скучных компонентах, а не наоборот.
С другой стороны, чрезмерное упрощение приводит к тому, что код пухнет на глазах, и становится плохо поддерживаем. У меня есть теория, что существует 2 типа программистов. Программисты с условно "большой оперативной памятью", которые легко работают с функциями длиной 500 строк, помнят про 300 глобальных переменных и то, где какие файлы лежат. Такие люди очень хорошо делают quick and dirty код и могут запустить техническую часть стартапа за неделю. А есть люди, у которых встроенный графовый процессор. Такие люди очень плохо работают с функциями в 500 строк, но могут держать в голове систему из множества взаимодействующих компонентов. Эти люди могут расчистить авгиевы конюшни исторических наслоений легаси и написать рядом систему, которая уже будет использовать кубернетес, кафку и прочие модные технологии к месту. Проблемы начинаются тогда, когда вторые люди приходят в стартап и начинают строить кубернетес кластер, либо когда люди первого типа приходят на проект с большой сложной системой, и начинают поверх нее строить хаки для быстрого запуска. К тому же эти два типа людей часто ненавидят друг друга :) Так что с моей точки зрения существует не только проблема оверинжениринга, но и проблема излишнего упрощения, которая скрывает сложность системы хардкодом и дублированием. Как всегда, нужен баланс, а скатывание в крайности понижает эффективность работы. Не важно будет ли это оверинжиниринг или чрезмерное упрощение.
источник

L

Lev in ctodailychat
Черт, я внутренне тоже думал про такое разделение людей, но только теперь осознал его явно
источник

SS

Slava Savitskiy in ctodailychat
нормальные программисты могут переключаться между двумя режимами
источник

SS

Slava Savitskiy in ctodailychat
источник

L

Lev in ctodailychat
источник

АА

Александр Арбузов... in ctodailychat
Slava Savitskiy
нормальные программисты могут переключаться между двумя режимами
define "нормальный"
источник

IR

Ilya Robustov in ctodailychat
Коллеги, может у кого есть на примете выпускник или молодой специалист в спб, ищу младшего сис. администратора в команду. Современная техника, интересные задачи, облачный стек серверов, гибридная ad и многое другое. ЗП в районе 50 на старте + различные плюшки.
источник

АА

Александр Арбузов... in ctodailychat
Kirill Sulim
С другой стороны, чрезмерное упрощение приводит к тому, что код пухнет на глазах, и становится плохо поддерживаем. У меня есть теория, что существует 2 типа программистов. Программисты с условно "большой оперативной памятью", которые легко работают с функциями длиной 500 строк, помнят про 300 глобальных переменных и то, где какие файлы лежат. Такие люди очень хорошо делают quick and dirty код и могут запустить техническую часть стартапа за неделю. А есть люди, у которых встроенный графовый процессор. Такие люди очень плохо работают с функциями в 500 строк, но могут держать в голове систему из множества взаимодействующих компонентов. Эти люди могут расчистить авгиевы конюшни исторических наслоений легаси и написать рядом систему, которая уже будет использовать кубернетес, кафку и прочие модные технологии к месту. Проблемы начинаются тогда, когда вторые люди приходят в стартап и начинают строить кубернетес кластер, либо когда люди первого типа приходят на проект с большой сложной системой, и начинают поверх нее строить хаки для быстрого запуска. К тому же эти два типа людей часто ненавидят друг друга :) Так что с моей точки зрения существует не только проблема оверинжениринга, но и проблема излишнего упрощения, которая скрывает сложность системы хардкодом и дублированием. Как всегда, нужен баланс, а скатывание в крайности понижает эффективность работы. Не важно будет ли это оверинжиниринг или чрезмерное упрощение.
согласен! практически то же самое для себя сформулировал
источник

АА

Александр Арбузов... in ctodailychat
кмк, в проекте должны быть и такие и такие программисты. и прекрасно, если не будет войны :)
источник

ИМ

Илья Макеев... in ctodailychat
есть два типа программистов - у одних один выход из функции у других несколько
источник

SS

Slava Savitskiy in ctodailychat
Александр Арбузов
define "нормальный"
это и есть определение 😏
источник

AC

Aleksei Chernov in ctodailychat
Kirill Sulim
С другой стороны, чрезмерное упрощение приводит к тому, что код пухнет на глазах, и становится плохо поддерживаем. У меня есть теория, что существует 2 типа программистов. Программисты с условно "большой оперативной памятью", которые легко работают с функциями длиной 500 строк, помнят про 300 глобальных переменных и то, где какие файлы лежат. Такие люди очень хорошо делают quick and dirty код и могут запустить техническую часть стартапа за неделю. А есть люди, у которых встроенный графовый процессор. Такие люди очень плохо работают с функциями в 500 строк, но могут держать в голове систему из множества взаимодействующих компонентов. Эти люди могут расчистить авгиевы конюшни исторических наслоений легаси и написать рядом систему, которая уже будет использовать кубернетес, кафку и прочие модные технологии к месту. Проблемы начинаются тогда, когда вторые люди приходят в стартап и начинают строить кубернетес кластер, либо когда люди первого типа приходят на проект с большой сложной системой, и начинают поверх нее строить хаки для быстрого запуска. К тому же эти два типа людей часто ненавидят друг друга :) Так что с моей точки зрения существует не только проблема оверинжениринга, но и проблема излишнего упрощения, которая скрывает сложность системы хардкодом и дублированием. Как всегда, нужен баланс, а скатывание в крайности понижает эффективность работы. Не важно будет ли это оверинжиниринг или чрезмерное упрощение.
а третьи умеют переключаться между этими режимами в зависимости от текущих потребностей бизнеса
источник