Все-таки если не лезть в дебри, то оно вполне, ИМХО (а дебри везде есть, это как времена в английском;))
Соглашусь, что в Паскале проще - но есть еще один нюанс, который я учитывал, давая эту рекомендацию - все-таки хорошо учить не мертвому языку, Си в этом плане куда лучше. И есть потом куда развиваться (я про плюсы и дебри).
Если про == я могу согласиться, то что не так с открывающей скобкой в блоке? B про "мутнейшее описание сложных конструкций" можно подробней? - прямо очень интересно, без всякого сарказма.
Ну, уж ) генераторы/итераторы и декораторы - это как раз не магия, а хороший синтаксический сахар (за который как раз этот язык можно и нужно любить).
Магия - это не очевидное поведение.
Например, в Python значения "по-умолчанию" у фии, которые не являются примитивом, сохраняются между вызывами этой функции, ну или то, что округление по-умолчанию - "бухгалтерское".
Лапша - например, задекларировано, что все есть объект, но при этом чтобы посчитать кол-во символов в строке нужно сделать "len( строка )" вместо "строка.len" и тд. Т.е. есть собственные базовые фии вызываются иногда "из объекта", а иногда "на объект", всякие магические названия вроде __main или не менее магические названия приавтных членов класса, геттеров/сеттеров, кваргсы и тд - те когда нет четкой и жесткой структуры работы.
Я преподавал и много, для себя вывел следующее - лучший язык для понимания - это Си, без плюсов.
Потому как там четкая система типов, указатели (очень важная штука для хорошего программиста), а при левелапе можно и ООП настоящее дать, но уже в плюсах.
То, что в статье - полностью согласен.
Про Python могу очень много плохого наговорить с аргументами, его преподносят часто как "гораздо лучший, чем лапшистый и с кучей магии PHP", а по факту лапши и магии там в разы больше. Я не люблю ни тот, ни тот, но, к сожалению, ввиду того что Python преподается практически во всех университетах мира, он стал стандартом де-факто, увы.
И индексы тоже не нужны! Да и БД! Даешь просто текстовые файлы!!! )))
Конечно нужны - это единственное, что бережет консистентность ваших данных в БД, а как известно из законов Мерфи - если что-то может случиться - это случиться.
Джуны/кот/комета/шальной скрипт/не сработавшая тразакция - на страже всего этого стоят эти ключи, чтобы случайно и далеко не обязательно, что напрямую через шастанье в БД не превратить ваши данные в желе.
Попробовав все что сейчас есть из устоявшегося, считаю что это либо VUE, либо Svelte.
VUE из-за зрелого коммьюнити с инфраструктурой, да и в целом отличного и модульного подхода (в тч composition API), кроме того найти разработчиков под него не проблема. Писать на нем проще, нет такого оверхэда как на React и Angular, компоненты просты и с нормальным HTML в качестве шаблона, причем в компонет можно как инкапсулировать все - и шаблон, и логику и стили, так и вынести их вовне. Отсуствие ада коллбэков, нормальная событийная модель и отсутствие JSX из-коробки (хотя можно использовать) для меня огромный плюс.
Svelte из-за простоты, размера и скорости, приятного и простого апи.
Все остальное или переусложнено, имеет странный api, необъяснимую магию или имеет околнулевое коммьюнити и полное отсутствие кадров на рынке.
Это не оборонительная ответственность - он ее реально никуда не смещает, он ее берет потому что считает, что так нужно (например потому, что остальные не справятся или не сделают так, чтобы дальше было хорошо) - и он имеет право так считать и делать, если он эту ответственность берет на себя. Ничего "вовне" не уходит в этом случае - ответственность замыкается на нем и он ее тащит.
Что до лысения - если реально начнётся - нужно сходить к доктору и если это окажется естественное состояние - не нужно мучать свой организм гормонами, постоянными процедурами и тд - ибо только в этом случае или постоянной пересадки вы сохраните волосы - лечить это не научились, нужно просто это принять и все - нечего в этом страшного нет, ну придётся имидж чуток подправить, чтобы соответствовать образу и все.
С одной стороны производители техники, как бы это сказать мягко... охренели и делют дичь из вязкого вещества и палок и при этом палок систематически не докладывают.
С другой стороны вы купили бюджетку за очень не дорого.
Вы купили ноут с дискреткой (что сразу плохо, ибо в ноуте оно не нужно). А в бюджетке оно не нужно и проблемно вдвойне. Это же касается и охлаждения и места в ноуте, его комплектации опреденным форм-фатором дисков и т.д.
Вы говорите про драйвер для Линукса, однако тут вопросы к производителю железа, а не к производителю ноута, ибо он (это, к сожалению, правда, хоть и очень не хочется) задумывался под винду, ну вот так, да.
Апгрейд - ноутбуки не приспособлены к этому, если не разработаны специально под это, и, обычно, используются AS IS, все остальное - на ваш страх и риск.
Акум - вопрос, а пробовали в Вантаже смотреть, есть ли параметр "заряжать на 80% при работе на зарядке" + скорее всего вы его и использовали по-большей части на ней? Ну вот плоды, к сожалению, ИМХО, это должно быть сразу в БИОСе, но есть что есть.
Бонусная переферия (мышь и тд) - это сразу мусор, вроде как все технари это все прекрасно понимают, нет? ) Ну и после возни с жидким металлом перепаять микрик в мышке вроде как не должно быть сложным.
Грубо говоря простыми словами - вы купили бюджетный автомобиль для езде в городе, а пытались его использовать как внедорожник.
Но да, это не оправдывает некоторых костыльных и дурацких решений (а возможно они сделаны намеренно для запланированного устаревания).
Lenovo по цене/качество сейчас вообще самое лучшее решение на рынке (Lenovo ThinkBook G6+ / Lecoo и тд).
Преимуществ, когда один стэк и на фронте и на бэке - куча, нода уже взрослая и отлично показала себя в проде, библиотек на все случаи жизни, а если что-то не так - всегда можно залезть и поправить.
Все проблемы у людей от головыи рук, не надо инструменты винить.
При безграмотной арзитектуре, погоне за хайпом и борще в голове вас нечего не спасёт. Выбирать надо под задачу, под вектор развития и под приемственность (сходите ваканчии под go/rust помониторьте).
У нас в университете был лифт, когда я туда поступил, он уже не работал. У меня учился там старший товарищ, и даже когда он поступал - лифт тоже не работал. На одном из капустников мы задали вопрос нашему декану - а вообще этот лифт когда-либо работал? Декан хитро улыбнулся и сказал что да, при сдаче корпуса, но потом его сразу отключили. На вопрос почему, Декан с ещё бОльшей хитрецой ответил так: "Представьте, что лифт вмещает n человек, а хотят на нем уехать k, и k всегда много больше n..." - это про поиск девушек в IT, если вы не поняли про что я)
Ибо читаемость того, что на картинках, скажем так - не очень.
Есть очень простое правило для малого разрешения - если в изображении/глифе можно что-то выкинуть без ущерба для распознавания - выкидывайте - это повысит скорость общего узнавания и понимания.
Про тогглы - это боль (даже для больших экранов - а какой стейт - это включено???), на маленьком разрешнии - боль в кубе, вместо этого нужно использовать чекбокс.
Ну, если честно, мне понятно, что не нравится ему в этом макросе.
Но с чем я категорически не согласен - c тем, чтобы писать такое без макросов. А для того, чтобы было понятно LE/BE и тд - макрос нужно нормально назвать, и это будет лучше чем каждый раз писать однострочник, ибо так можно вообще от функций тогда отказаться.
И второе - проверно годами - эмоции в работе всегда только мешают - не можешь их сдерживать - не ревьюруй код и вообще не связывай себя с работой с людьми. Дело тут не в снежинках или в том, что дерьмо не должно быть названо дерьмом, а в перегрузке ответа лишним.
А ответ должен был быть простым и четким "Поздно прислан запрос - если есть необходимость успевать в мое окно релизов, направляйте запрос за n дней до него, и нужно переименовать данную функцию, чтобы было понятно LE или BE операция за ней стоит" - все четко, быстро, по делу и без окраски.
Это не тратит время, чтобы продраться сквозь эмоции за смыслом, так делают профи. Но, к сожалению (ну или к счаcтью), "миром правят психопаты" (c)
Ну и професссионал не только понимает конкретное, но и мыслит гораздо шире и смотрит вперед - нужно понимать, что обидев пусть даже снежинку, которая делала вклад в общее дело и лишившись ее, лучше общему делу не станет. Уметь нужно балансировать между надо/надеол/заменить/смотивировать, а не рубить кровавым топорищем (ну или рубить, но четко понимать зачем ты это делаешь).
Все-таки если не лезть в дебри, то оно вполне, ИМХО (а дебри везде есть, это как времена в английском;))
Соглашусь, что в Паскале проще - но есть еще один нюанс, который я учитывал, давая эту рекомендацию - все-таки хорошо учить не мертвому языку, Си в этом плане куда лучше. И есть потом куда развиваться (я про плюсы и дебри).
Если про == я могу согласиться, то что не так с открывающей скобкой в блоке? B про "мутнейшее описание сложных конструкций" можно подробней? - прямо очень интересно, без всякого сарказма.
Ну, уж ) генераторы/итераторы и декораторы - это как раз не магия, а хороший синтаксический сахар (за который как раз этот язык можно и нужно любить).
Магия - это не очевидное поведение.
Например, в Python значения "по-умолчанию" у фии, которые не являются примитивом, сохраняются между вызывами этой функции, ну или то, что округление по-умолчанию - "бухгалтерское".
Лапша - например, задекларировано, что все есть объект, но при этом чтобы посчитать кол-во символов в строке нужно сделать "len( строка )" вместо "строка.len" и тд. Т.е. есть собственные базовые фии вызываются иногда "из объекта", а иногда "на объект", всякие магические названия вроде __main или не менее магические названия приавтных членов класса, геттеров/сеттеров, кваргсы и тд - те когда нет четкой и жесткой структуры работы.
Делал на ATTINY85, BluePill для такого это даже не оверинженеринг, а гораздо хуже )
А где я писал, что что-то не описано в документации? )
Ну и описанная магия магией быть не перестает.
Я преподавал и много, для себя вывел следующее - лучший язык для понимания - это Си, без плюсов.
Потому как там четкая система типов, указатели (очень важная штука для хорошего программиста), а при левелапе можно и ООП настоящее дать, но уже в плюсах.
То, что в статье - полностью согласен.
Про Python могу очень много плохого наговорить с аргументами, его преподносят часто как "гораздо лучший, чем лапшистый и с кучей магии PHP", а по факту лапши и магии там в разы больше. Я не люблю ни тот, ни тот, но, к сожалению, ввиду того что Python преподается практически во всех университетах мира, он стал стандартом де-факто, увы.
Это просто еще одна ступень защиты (как и ограничение прав), естественно, а не серебрянная пуля, вы предлагаете ее отключить.
А часто бывает, что скрипт при разработке что-то делает, и права там не мешают.
Ну и есть еще плюшки от FK, например удаление цепочек.
И индексы тоже не нужны! Да и БД! Даешь просто текстовые файлы!!! )))
Конечно нужны - это единственное, что бережет консистентность ваших данных в БД, а как известно из законов Мерфи - если что-то может случиться - это случиться.
Джуны/кот/комета/шальной скрипт/не сработавшая тразакция - на страже всего этого стоят эти ключи, чтобы случайно и далеко не обязательно, что напрямую через шастанье в БД не превратить ваши данные в желе.
Попробовав все что сейчас есть из устоявшегося, считаю что это либо VUE, либо Svelte.
VUE из-за зрелого коммьюнити с инфраструктурой, да и в целом отличного и модульного подхода (в тч composition API), кроме того найти разработчиков под него не проблема. Писать на нем проще, нет такого оверхэда как на React и Angular, компоненты просты и с нормальным HTML в качестве шаблона, причем в компонет можно как инкапсулировать все - и шаблон, и логику и стили, так и вынести их вовне. Отсуствие ада коллбэков, нормальная событийная модель и отсутствие JSX из-коробки (хотя можно использовать) для меня огромный плюс.
Svelte из-за простоты, размера и скорости, приятного и простого апи.
Все остальное или переусложнено, имеет странный api, необъяснимую магию или имеет околнулевое коммьюнити и полное отсутствие кадров на рынке.
Это не оборонительная ответственность - он ее реально никуда не смещает, он ее берет потому что считает, что так нужно (например потому, что остальные не справятся или не сделают так, чтобы дальше было хорошо) - и он имеет право так считать и делать, если он эту ответственность берет на себя. Ничего "вовне" не уходит в этом случае - ответственность замыкается на нем и он ее тащит.
Очередная реклама фуфломицина, дожили (
Что до лысения - если реально начнётся - нужно сходить к доктору и если это окажется естественное состояние - не нужно мучать свой организм гормонами, постоянными процедурами и тд - ибо только в этом случае или постоянной пересадки вы сохраните волосы - лечить это не научились, нужно просто это принять и все - нечего в этом страшного нет, ну придётся имидж чуток подправить, чтобы соответствовать образу и все.
Насчёт девченок не переживайте - не уменьшатся)
Очень спорно.
С одной стороны производители техники, как бы это сказать мягко... охренели и делют дичь из вязкого вещества и палок и при этом палок систематически не докладывают.
С другой стороны вы купили бюджетку за очень не дорого.
Вы купили ноут с дискреткой (что сразу плохо, ибо в ноуте оно не нужно). А в бюджетке оно не нужно и проблемно вдвойне. Это же касается и охлаждения и места в ноуте, его комплектации опреденным форм-фатором дисков и т.д.
Вы говорите про драйвер для Линукса, однако тут вопросы к производителю железа, а не к производителю ноута, ибо он (это, к сожалению, правда, хоть и очень не хочется) задумывался под винду, ну вот так, да.
Апгрейд - ноутбуки не приспособлены к этому, если не разработаны специально под это, и, обычно, используются AS IS, все остальное - на ваш страх и риск.
Акум - вопрос, а пробовали в Вантаже смотреть, есть ли параметр "заряжать на 80% при работе на зарядке" + скорее всего вы его и использовали по-большей части на ней? Ну вот плоды, к сожалению, ИМХО, это должно быть сразу в БИОСе, но есть что есть.
Бонусная переферия (мышь и тд) - это сразу мусор, вроде как все технари это все прекрасно понимают, нет? ) Ну и после возни с жидким металлом перепаять микрик в мышке вроде как не должно быть сложным.
Грубо говоря простыми словами - вы купили бюджетный автомобиль для езде в городе, а пытались его использовать как внедорожник.
Но да, это не оправдывает некоторых костыльных и дурацких решений (а возможно они сделаны намеренно для запланированного устаревания).
Lenovo по цене/качество сейчас вообще самое лучшее решение на рынке (Lenovo ThinkBook G6+ / Lecoo и тд).
Там кровати-то двигать бесполезно давно)
Кто на первой фотографии - робот? (:
Почему нет?
Вот не надо пинять на язык, ладно)
Преимуществ, когда один стэк и на фронте и на бэке - куча, нода уже взрослая и отлично показала себя в проде, библиотек на все случаи жизни, а если что-то не так - всегда можно залезть и поправить.
Все проблемы у людей от головыи рук, не надо инструменты винить.
При безграмотной арзитектуре, погоне за хайпом и борще в голове вас нечего не спасёт. Выбирать надо под задачу, под вектор развития и под приемственность (сходите ваканчии под go/rust помониторьте).
У нас в университете был лифт, когда я туда поступил, он уже не работал. У меня учился там старший товарищ, и даже когда он поступал - лифт тоже не работал. На одном из капустников мы задали вопрос нашему декану - а вообще этот лифт когда-либо работал? Декан хитро улыбнулся и сказал что да, при сдаче корпуса, но потом его сразу отключили. На вопрос почему, Декан с ещё бОльшей хитрецой ответил так: "Представьте, что лифт вмещает n человек, а хотят на нем уехать k, и k всегда много больше n..." - это про поиск девушек в IT, если вы не поняли про что я)
Уберите этот фильтр и будет куда проще.
Для начала я бы шрифт сменил )
На что-то такое
А потом уж все остальное.
Ибо читаемость того, что на картинках, скажем так - не очень.
Есть очень простое правило для малого разрешения - если в изображении/глифе можно что-то выкинуть без ущерба для распознавания - выкидывайте - это повысит скорость общего узнавания и понимания.
Про тогглы - это боль (даже для больших экранов - а какой стейт - это включено???), на маленьком разрешнии - боль в кубе, вместо этого нужно использовать чекбокс.
Нет, код, увы это не гуманитарная дисциплина. Нейминг внутри кода - может быть.
Для себя я определил очень простые пункты для понятного именования:
называть так, чтобы можно было понять в текущем контексте что это
текущий контекст - это модуль + класс + фя (в простом приближении)
не добавлять у именам название контекста - те Array.isArray - это очень плохо
имена формировать как "что" (существительное) + "делает" (глагол), например emailValidate
lowerCamelCase
Но вообще все ИМХО, главное чтобы был описанный стандарт, принятый в команде и все его придерживались.
Ну, если честно, мне понятно, что не нравится ему в этом макросе.
Но с чем я категорически не согласен - c тем, чтобы писать такое без макросов. А для того, чтобы было понятно LE/BE и тд - макрос нужно нормально назвать, и это будет лучше чем каждый раз писать однострочник, ибо так можно вообще от функций тогда отказаться.
И второе - проверно годами - эмоции в работе всегда только мешают - не можешь их сдерживать - не ревьюруй код и вообще не связывай себя с работой с людьми. Дело тут не в снежинках или в том, что дерьмо не должно быть названо дерьмом, а в перегрузке ответа лишним.
А ответ должен был быть простым и четким "Поздно прислан запрос - если есть необходимость успевать в мое окно релизов, направляйте запрос за n дней до него, и нужно переименовать данную функцию, чтобы было понятно LE или BE операция за ней стоит" - все четко, быстро, по делу и без окраски.
Это не тратит время, чтобы продраться сквозь эмоции за смыслом, так делают профи. Но, к сожалению (ну или к счаcтью), "миром правят психопаты" (c)
Ну и професссионал не только понимает конкретное, но и мыслит гораздо шире и смотрит вперед - нужно понимать, что обидев пусть даже снежинку, которая делала вклад в общее дело и лишившись ее, лучше общему делу не станет. Уметь нужно балансировать между надо/надеол/заменить/смотивировать, а не рубить кровавым топорищем (ну или рубить, но четко понимать зачем ты это делаешь).