• Scala мертва?
    +3
    Go vs Java: выбор очевиден. Go примитивнее Java, меньше библиотек, фреймворков и тулов. Гораздо труднее найти квалифицированных разработчиков. За 2 месяца можно только язык выучить, для полноценной разработки это крайне мало — надо знать инструменты, паттерны, best practices, библиотеки и их особенности. На это уйдёт не один год. В то же время никаких значимых преимуществ GO не даёт.

    Go vs Scala: вообще разные весовые категории.

    Scala/Java/Kotlin vs TypeScript: на TypeScript-e пишут фронтэндеры. А квалифицированный фронтэндер — это дорогой и труднонаходимый зверь, которого все хотят оторвать с руками.

    Kotlin vs Scala: спорный вопрос, я бы точно предпочёл kotlin. Но очевидно есть аргументы и за другой вариант

    Ну и если бы я верил в то, что система, написанная FullStack-разработчиками может в принципе работать :)


    Вот этого комментария в сторону FullStack-разработчиков я вообще не понял — очевидно у автора своего рода юнешеский максимализм
  • Частотный анализ русского текста и облако слов на Python
    0
    Вы забыли про ёфикацию и про удаление имён людей.
    Сам занимался составлением частотных списков, но больше для английского языка.
    И могу сказать, что эта задача гораздо более сложная, чем кажется и далеко не сводится к выбору «правильного» языка программирования и библиотек.
  • Удалёнка за доллары: а меня возьмут?
    +2
    Программистов консультантами обычно не называют

    Ещё как называют!
  • Paragon открыла свой драйвер NTFS для Linux, предложив включить его в ядро
    0
    ntfs-3g не работает на этапе загрузки
  • Paragon открыла свой драйвер NTFS для Linux, предложив включить его в ядро
    0
    «Родной» драйвер линукс поддерживает запись — можно изменять уже созданный файл (не уверен, правда, можно ли при этом менять размер). За счёт этого можно, к примеру, ставить линукс внутрь файла на NTFS
  • Свободу байтам
    +3
    Простите, откуда у вас информация, что лидеры в блокировках РФ и Китай?
    У вас есть ссылка на источник?
    По-моему, как минимум Туркменистан и Северная Корея блокируют сильнее, чем РФ.
  • Как перезапустить закон Мура программными методами. Ускорение софта в тысячи раз
    0
    Вообще говоря ускорение в 1000 раз — это часто вообще не проблема для многих бизнес-задач (и часто на это даже не требуется много времени). Сам пару раз ускорял в несколько тысяч раз некоторые долгие задачи.

    Проблема, скорее не в программистах (они, как правило, фанатеют от оптимизации, иногда даже слишком), а в менеджменте, который не ставит подобных задач.

    И часто почему-то перформанс ассоциируется со скалабилити. Нет, господа, скорость не всегда подразумевает 1000 серверов.
  • Детальный разбор структуры зарплат IT-специалистов в Кремниевой Долине
    0
    Не понимаю, почему все так пугаются индусского акцента. Я не могу сказать что индусы как-то сильно коряво говорят. Вот шотландский английский — вот это жесть!
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Проблема передачи транзакционного и секурити контекстов а так же калбэки — это типичная проблема микросервисов, реализованных через REST/SOAP, но, с другой стороны, никто не запрещает использовать другие протоколы, где эти вопросы решены, например RMI.
  • Сравниваем подсистемы WSL 1 и WSL 2. Стоит ли переходить?
    0
    Не совсем понимаю ваш сценарий. Вы запускаете IDE в Windows или в Linux?
    Если вам часто требуется Linux, то просто останавливайте его только в конце рабочего дня.
    Зачем постоянно перезапускать виртуальную машину?
  • Сравниваем подсистемы WSL 1 и WSL 2. Стоит ли переходить?
    –2
    Far Manager требует опции: «Use Legacy console (requires relaunch, affects all consoles)», а WSL 1 наоборот хотел не «legacy» консоль.

    WSL2 — это и есть виртуалка, только неудобная и ограниченная только одной операционной системой. Ни тебе андроид запустить, ни мой любимый арч, ни CentOS, часто используемый в продакшене. Работает только на Windows Pro. Да ещё какие-то непонятные ограничения с GUI.
    Зачем это надо вообще? Virtual Box бесплатен и работает как часы.

    Я понимаю, что MS хочет перетянуть разработчиков на тёмную сторону. Но разработчикам то это зачем?
  • Сравниваем подсистемы WSL 1 и WSL 2. Стоит ли переходить?
    0
    Меня WSL раздражает тем, что требует новую консоль, которая ломает Far.
    Кроме того, HyperV конфликтует с VirtualBox (пришлось удалить).

    В связи с этим возникает закономерный вопрос: зачем вообще нужен WSL, когда есть Sygwin и виртуальная машина, на которую можно установить любой Linux. Который при этом будет гарантированно быстро работать.
  • Как я два раза подряд искал работу на карантине
    –2
    Конечно, обычно есть всегда есть главный луп, который реагирует на нажатия и мигает. И дополнительно: вычислительные потоки, выполняющие долгие операции, либо слушатели реагирующие на внешние события (например, изменения на файловой системе)
  • Apple Silicon: конец эры Wintel
    +1
    Ну может вам по характеристикам и программируемый калькулятор подойдёт, но какое это имеет значение в контексте сравнения компьютеров?
  • Apple Silicon: конец эры Wintel
    0
    Вот уж действительно: слона то не заметили. Сравнивать пассивный кулер с активным — это за гранью добра и зла.
  • Apple Silicon: конец эры Wintel
    0
    Я не вижу нормальных характеристик ни того ни другого компьютера, в прочем это не важно, ибо вы прислали обе устаревшие модели. Надо смотреть модель ssd и качество сборки (в апловской сборке я почти уверен), размер батареи, качество приёма Wifi, динамики.
  • Apple Silicon: конец эры Wintel
    +2
    Так с «примерно равными» или именно равными? Качество сборки тоже учитывали?
    Мне вот интересно с чем вы сравнивали. Хочу вот тоже сравнить
  • Apple Silicon: конец эры Wintel
    0
    Откуда вы знаете про большинство? У эпла одни из самых популярных компьютеров, если чо. И с каким аналогом вы сравнивали Apple air?
  • Apple Silicon: конец эры Wintel
    +1
    У эпла ценник не высокий.
    В этом легко убедиться, если сравнить с любым компьютером похожей комплектации.
  • Как я два раза подряд искал работу на карантине
    –9
    Фронт-энд практически всегда и сложнее и стресовее и часто требует более высокой квалификации (если речь не идёт о расчёте параметров чёрных дыр). Я вообще не понимаю откуда растут ноги от подобного пренебрежительного отношения к фронтенду.
    К слову, самые сложные мультипоточные баги с которыми мне приходилось сталкиваться были связанны с фронтендом.
  • Что я узнал после более чем 1000 code review
    0
    Как раз для изоляции — фич друг от друга.


    Ну правильно. Но зачем изолировать задачи выполняющиеся одним и тем же автором, на протяжении короткого времени и часто вперемешку. А после мерджа в мастер всё равно обе модели выглядят по сути одинаково.

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

    Чем больше объем мерджа тем больше разбираться что сломало CI, меньше гранулярность при черрипике, если надо будет, больше объем ревью и так далее.


    Ну вообще это больше зависит от пропускной способности ревьюверов, а не от бренчинг модели.

    Вообще, конечно, чем чаще мерджинг тем лучше, хоть полфичи хоть четверть. Feature branch модель скорее неявно поощряет откладывать мерджинг, до тех пор пока таска не полностью завершена
  • Что я узнал после более чем 1000 code review
    0
    Что значит фиг знает где? Он составляет историю мастера.


    Вы пытаетесь использовать ветки для документации истории изменений. Но они для этого не предназначены. Они нужны для изоляции кода.
    Для документации изменений существуют комментарии к коммитам, где может быть любая исчерпывающая информация. Мердж коммит находится «вдалеке» от основного коммита и надо искать где находится тот, про который написано в мердже.

    Потому, что вы можете работать, как вы сами говорили, над несколькими фичами, одна может быть готова отправке в мастер, другая не готова — тесты не дописаны, не компилируется, нет документации или какие там у вас характеристики проверяет билд еще.


    А в мастер не обязательно мержить, когда вся фича готова. Можно замерджить и 10 фич и полфичи. Главное — чтобы существующий код не ломался и был проревьювен.

    Если она не вмерджена в мастер, значит не готова. Берите всегда из мастера.


    Необязательно: она может быть сделана, но непроревьювена.
  • Что я узнал после более чем 1000 code review
    0
    Обычно он содержит ссылку на PR которую можно открыть и посмотреть все детали


    Почему нельзя взглянуть сразу в коммит сообщения, где так же будет ссылка на таску в джире (если коммит связан с таской). Зачем мне идти в мердж коммит, который фиг знает где, открывать пул реквест и только там смотреть конкретные таски?

    Можно так же мерджить их в мастер пофично (всегда решить какую фичу вмерджить, а какую — нет). Для готовой работы есть уже мастер с его историей.


    Зачем что-то мержить в местер пофично? Если какая-то фича не вмержена в мастер, то я как разработчик фичи нахожусь в подвешенном состоянии ибо не знаю, какую версию кода брать для дальнейшей работы над другими задачами: с фичей или без неё.

  • Что я узнал после более чем 1000 code review
    0
    Да
  • Что я узнал после более чем 1000 code review
    0
    Но вы-то предлагает ветку на разработчика — т.е. там должны быть вообще все зачачи разработчика даже логически не связанные или как?


    Совершенно верно. Собственно так это и задумывалось: youtu.be/4XpnKHJAok8?t=1599

    Я подразумеваю, что ветки сливаются в какой-то момент в основную. Соответсвтенно, merge commit будет содержать описание и ссылку на задачу и можно будет посмотреть в истории по master.


    Merge commit будет содержать название ветки, но что мне это даст? Не проще ли просто посмотреть в комментарии к коммитам.

    История в фичебранчах как правило не нужна другим разработчикам, кроме того, случая, когда они совместно работают над долгоживущим бранчем. Но этот случай вообще непонятно, как решать в режиме «ветка на разработчика».


    Как фича бренчи улучшают понимание, если разработчики синхронизируются только с мастер веткой? Они могут появляться и исчезать без всяких следов. Так зачем их создавать тогда?

    Я не спорю что есть ситуации, когда надо действительно сделать какую-то отдельную изолированную ветку длиной в полгода. Но зачем засорять гит тысячами мелких бренчей мне непонятно.

    Ага, с моей точки зрения это не должно занимать сильно больше времени, чем написание данного коммента.

    Это сильно раздражает. Это всё равно что раз в час писать в журнал что сделал за последний час — недолго, но мерзко
  • Что я узнал после более чем 1000 code review
    0
    Что их заставляет так делать? Как они поступают когда одна задача готова, а другая — еще нет? Как потом в истории разобраться зачем именно было сделано конкретное изменение?


    Что значит зачем? Программирование — это творческий процесс. Разработчики работают, как им удобнее. Если у меня есть 2 задачи по фронту и бакенду для фичи A и фронт+бакэнд для фичи B.
    То мне может показаться удобнее написать сначала бакэнд для обеих фич а затем фронт для обеиз фич.

    Как потом в истории разобраться зачем именно было сделано конкретное изменение?


    В коммитах должно быть описание. Ваши ветки в этом, кстати, мало помогают. Ибо разработчики смотрят историю основной ветки (как правило).

    С моей точки зрения, все коммиты связаны с задачами, если у вас нет никакой задачи не создавайте коммит. Если у вас есть задача, оформите это в багтрекере. Если у вас коммит связан с закрытой задачей, значит в багтрекере вранье — либо задача не закрыта, либо это новая задача, связанная с данной.


    То что вы описываете-это самая настоящая бюрократия. И она плохо ложится на реалии.
    Я например постоянно переписываю документацию. И что мне для каждой опечатки таску и отдельную ветку создавать?
  • Что я узнал после более чем 1000 code review
    0
    Один разработчик — одна ветка. Заводить по ветке на фичу — крайне неудачная идея по моему опыту.

    Во первых возникает туева хуча веток. Часто работу нельзя правильно разбить по этим веткам, да и не нужно.
    Если ревьювер занят, то накапливается куча веток которых надо смержить друг в друга а также в локальную ветку. Это крайне неудобно.
    Кроме того разработчики часто работают над несколькими задачами одновременно. Надо постоянно переключаться между ветками.
    Непонятно куда девать коммиты которые не связаны непосредственно с тасками, либо таски не созданы, либо уже закрыты.

    Forking workflow же вообще не имеет никаких недостатков и выглядит более элегантно.

  • Что я узнал после более чем 1000 code review
    0
    Потому что мы мержим конкретный код у которого есть конкретный автор, а не просто кучу абстрактных бренчей, которые мы создаём тысячами.
    Автор всегда имеет удалённую копию и может синхронизировать свою работу.
    Всегда можно посмотреть кто над чем работает.
    Работа разработчика не блокируется, если пул реквест отсрочен. Он может продолжать мерджить из мастера и продолжать свою работу.
    И такси надо объединять не в рамках релиза, а постоянно.
  • DI из ада
    +2
    Можно и по другому сказать: спринг контекст выступает в роли сервис локатора
  • Что я узнал после более чем 1000 code review
    0
    Смотря что вы подразумеваете под фичей. Если таску в джире, то её делает один человек. И один пул реквест покрывает потенциально несколько тасок.

    В общем читать здесь: www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
  • DI из ада
    0
    В приведенных примерах все поля private, так что я не понимаю, о каком присваивании без сеттеров вы говорите.


    Вы писали, про то что поля, нарушают принципы инкапсуляции. Так вот: сеттеры точно также нарушают принципы инкапсуляции, но при этом ещё превращают код в месиво.

    По поводу тестирования: я так понял, вы имеете в виду, что можно поднять контекст Spring в тесте и обойтись без сеттеров/конструкторов. Это будет интеграционный тест, про них я ответил выше


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

    Пожалуй, действительно формально конструктор -самый правильный вариант. Но на практике инжекция в поля выглядит гораздо менее громоздкой и более элегантной.
    И почти всегда её достаточно. А там где не хватает, можно и конструктор добавить.

    Насколько я знаю, для DI Spring всегда использует Reflection API.

    Не обязательно.

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

    И это тоже необязательно
  • DI из ада
    +4
    Утверждение, что инжекция в поля это худший вариант — необоснованное и не выдерживает никакой критики.

    То есть, поля не инкапсулированы, а сеттеры инкапсулированы? Да что вы говорите? Что мне мешает вызвать сеттер вместо присваивания?

    На самом деле поля можно (и наверно нужно) сделать приватными и они будут скрыты.
    Сеттеры нужны только в тех случаях когда требуется логика при изменении поля, либо для совместимости с некоторыми фреймворками. Если просто бездумно их пихать там где не надо, то код превращается в мусор.

    Про тестирование вообще улыбнуло — автор явно не знает как тестируются спринг бины.

    «Spring использует Reflection API» — ну это вообще-то не всегда.
  • Что я узнал после более чем 1000 code review
    0
    Я для себя давно пришёл к выводу, что ветки надо создавать не по фичам, а по разработчикам. Это прям снимает кучу проблем.
  • Как проще всего перейти с macOS на Linux
    +1
    Я не могу спорить с человеком который сравнивает технику по таким параметрам

    "… похожие на макбук… алюминиевые ультрабуки… линейку не прикладываю"
  • Как проще всего перейти с macOS на Linux
    +4
    Ну посмотрите спецификации хотя бы.

    «Хуавей на амд можно захакинтошить» — и тут я начинаю подозревать, что вы никогда ничего не хакинтошили.
  • Как проще всего перейти с macOS на Linux
    +7
    Я конечно извиняюсь, но Huawei Matebook 13 и MacBook Pro это вообще совершенно разного калибра вещи.

    Автор сравнивает MacOS и Linux, но сравнивать можно только то, что может работать на одном и том же железе
  • Как проще всего перейти с macOS на Linux
    +3
    Кажется почти невероятным, что автор не упомянул, что чип T2 плохо работает в Linux.

    Без жутких хаков завести Linux (с установкой на внутренний SSD, разумеется) на современном MacBook Pro не получится.
  • Об оценках сроков в разработке ПО
    +2
    Подгонка закрытия задач под рамки итераций — это одна из проблем скарама. Для её решения есть Scrumban. Оценки получаются гораздо точнее если над ними подумать денёк. Никто не сможет дать правильную оценку без кода, требований и за 15 минут.
  • Тёмная сторона работы в Яндекс.Маркете
    +2
    OK, про OsX понял, а вот про 0.01% случаев, когда ад начинается, интересно узнать примеры кейсов.

    Ведь, в большинстве случаев, нам просто требуется включить несколько нативных библиотек и вызывать нужную, проверяя ОС.
    Как в общем-то все эти Java -wrapper-ы и делают
  • Тёмная сторона работы в Яндекс.Маркете
    0
    Нет никакого квеста. Всё прекрасно собирается как мавеном так и граделом за один проход и одной командой. Никаких разных систем сборки не надо. Для launch4j формально требуется windows, но можно обойти это ограничение, если приспичит.

    Нам по сути надо либо shell -скрипт приконкатенатить к fat-jar-у либо exe-шник который запускает сам себя как java -jar . Все эти trap-ы и проверку версий пишете внутри shell скипта.

    Кроме того, вроде как в последней джаве сделали какой-то упаковщик.

    Если нужен rpm — используете redline rpm, если msi — wix плагин для мавена (ну здесь уже без Windows билдера походу не обойтись)