111.2
Karma
86.3
Rating
Джехи @jehy

Tech Lead

Лайфхак – пишем и бесплатно хостим в облаке вебсайт с гостевой книгой

+11

Раз пять пытался придумать смешной комментарий про то, что даже сам термин "гостевой книги" ушёл в небытие уже лет 10 как… Но смешнее, чем заголовок поста в сочетании с тегами и 2019 годом — не выходит.

Руководство по Discovery.js: быстрый старт

0

Матерь божья, я и не знал, что npx умеет локальные пакеты запускать — всегда использовал только для запуска пакетов из регистри без установки.

Руководство по Discovery.js: быстрый старт

0
npm install @discoveryjs/discovery @discoveryjs/cli
npx discovery

Вероятно, имелась в виду установка пакета с ключом -g, иначе непонятно, куда его ставит автор. Если же пакет ставится в проект, который исследуется, то этим самым меняется его древо зависимостей, что очень странно (я понимаю, что это демо, но всё же).


Кроме этого, совсем непонятно, зачем после установки пакет запускается через npx. Если так можно, то зачем его ставили локально? А если нужно ставить локально — то почему его не запускают локально?


В общем, пояснения о переводчика пригодились бы. Кстати, забавно, что переводится статья с английского, написанная явно русскоязычным автором. Смайлик.


Теперь по сути. Морда discovery в целом забавная и можно найти ей применения. Насчёт jora — вроде уже есть jq, чем, как вы считаете, jora лучше?

Асинхронный Typescript в Rich Internet Application и декораторы для борьбы с ним

+1

TLDR: чтобы наши асинхронные функции на клиенте не конфликтовали, мы рассовали их выполнение по очередям в зависимости от вьюхи.


Вроде, остальная часть поста — вода в декораторах.

Книга «ВкусВилл: Как совершить революцию в ритейле, делая всё не так»

0

Видимо, вы невнимательно читали статью.
Основной целью как раз является решение вопроса SMM, а не оттока покупателей. Поэтому я и говорю, что система работает. Считать подход ущербным можно, но это совершенно другой спор.


Отток она тоже явно уменьшает, но насколько — этот вопрос неочевидный и вторичный.


Ну и мне просто любопытно — а как вы бы предложили удержать клиента, который не идёт на контакт и при первом прецеденте перестаёт пользоваться вашим сервисом? Надеюсь, ответ будет не "всё сразу делать везде идеально"...

Книга «ВкусВилл: Как совершить революцию в ритейле, делая всё не так»

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

Лайфхак — говорите "оставить". И не думаете об этом.


У меня есть стандартный алгоритм — подошёл, поставил корзину, " пакет не нужен, по куар коду, оставить, картой", получил продукты. Всё.


А те, кто играют в игру, те платят информацией о себе.

Я так понимаю, вы не пользуетесь сервисами гугла, яндекса, Амазона, интернет банкингом и смартфоном? Или сеть продуктовых магазинов с вашей точки зрения особо опасна?

Книга «ВкусВилл: Как совершить революцию в ритейле, делая всё не так»

0

У вас были какие-то случаи, когда люди молча выкидывали продукты, и не давали фидбек, и вы проецируете это на всех, и считаете, что система не работает. Не надо так!


Система отлично работает, пользовался ей пару раз, и это весьма мало, при условии, что закупаюсь там постоянно.


Ну и да — здесь речь шла не столько про то, чтобы получить фидбек, сколько про то, чтобы переместить его из соцсетей в магазины. Подозреваю, что чаще всего люди, которым лень отнести в магазин испорченный товар, и в соцсети постить не будут. Так что всё отлично работает.

Как я не стал программистом в 35 лет

+1

Повторюсь — 99% разработки это Java, на которой можно писать и без эмулятора на древнейшем компьютере.


Дальше остаётся засунуть это в андроидный бойлерплейт и раскидать кнопочки — что тоже по большей части можно сделать без эмулятора. Можно даже проверить, что всё это добро собирается. остаётся совсем немного работы по отладке — но в целом и без этого можно уже послать код куда-нибудь на вакансию. Ещё можно одолжить у кого-нибудь телефон на последний этап. Или попросить кого-нибудь удалённо протестировать ваш apk.


Читать книжки — это важно, и можно в том числе читать книжки по разработке. Но для этого более рационально использовать что-нибудь вроде kindle — стоит дёшево, живёт вечно.

Как я не стал программистом в 35 лет

+1

Для того, чтобы научиться разработке на Android… Вам не нужно устройство на Android… Достаточно эмулятора. А можно и без него, поскольку 99% нужных навыков это разработка на Java/Kotlin.

Как я не стал программистом в 35 лет

0
все эти разговоры, что где-то там забирают новичков с руками и ногами, что программистов не хватает… Где? Я не вижу.

Наша компания специально открыла офисы в нескольких городах в РФ, Украине и Белоруссии. И мы готовы брать джунов и обучать их. На этой неделе выходят два человека с почти нулевым опытом в Москву и в Тверь. И мы в этом ваще не уникальны. Скину в личку ссылку на вакансии, чтобы было понятно, что они есть.


Или они смотрят на меня, как на программиста с уровнем ниже 0.

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

Как я не стал программистом в 35 лет

+9

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


Мне когда-то запали в душу слова Стивена Кинга:


Называйте меня колбасником. Да, я колбасный писатель. То, что я пишу, — это колбаса. Сел и съел. Я признаю это и не принимаю никаких претензий: ведь я никогда не выдаю свою колбасу за белужью икру.

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


И ещё одна цитата от Стивена:


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

Это не про какой-то божественный талант. Это просто про то, что у тебя как-то получается, и к чему при этом лежит твоя душа. Если у тебя нет потребности писать код — то не стоит себя насиловать. Возможно, стоит поискать себя где-то ещё, в том числе в связанных профессиях. В тестировании (хороший QA получает не меньше разработчика), в devOps (редкий и очень ценный зверь), в DBA (видел много прекрасных людей, которые живут этим), аналитике, и так далее.

Как я не стал программистом в 35 лет

+20

Можно много всего сказать про этот пост, но отмечу два момента, от которых просто кровь из глаз пошла.


Самостоятельное обучение жутко неэффективно. То, чему тебя научат, например, за полгода, ты будешь самостоятельно разбирать года два.

Чудовищная ложь. На дворе 2019 год, но до сих пор тебя не научат ничему из того, что нужно и используется в продашне на bleeding edge. Любые материалы устаревают ещё до момента выхода. Самый важный навык разработчик — это умение самостоятельно обучаться. А если уж хочется облегчить себе жизнь — то можно начать с сотен разных платных и не очень онлайн курсов, которые хотя бы дадут базу.
Если же автор имел в вижу, что обучаться можно только работая — это тоже ложь. Поскольку в работе тебе нужно решать конкретные бизнес задачи, и скорее ты приносишь туда свой багаж знаний и инструментарий для их решения, чем его тебе дают там на блюдечке. Обучаться на работе можно только на стартовых позициях при условии наличия хороших сеньёров, или вопреки всему.


Всё вот это длинное нытьё про профильное образование, опыт работы, который получили только те, кому повезло, и ужасных HR.

Сменил 5 мест работы. Ни в одном HR не считали техническое образование необходимым навыком. Сейчас, в большой серьёзной компании на 300 человек, с постоянным кадровым голодом по разработчикам — мы тоже не можем себе этого позволить. Мы берём разработчиков любого пола, возраста, ориентации и образования, предлагая им релевантную их опыту позицию. Критерии — чтобы человек был адекватен, и чтобы хотел развиваться. Всё.
В чём проблема с тем, что автору давали сразу отбой — не знаю, удалённой диагностикой по посту на хабре не занимаюсь. Возможно, в том, что он в жизни общается в том же тоне, в котором написан этот пост. Или нет. Но точно не в профильном образовании или отсутствии опыта.


Ну и последнее. О наличии опыта, компьютера, книжек, и так далее.
Свои первые программы я написал на даче, ручкой на листке в клетку, прочитав взятый с собой учебник.
Свои пет проджекты я писал, когда ещё такого слова не было.
И мне непрерывно хотелось писать что-то больше, сложнее, интереснее.
Насколько я знаю моих друзей, у них было так же.
Их писали не ради денег, не для того, чтобы показать работодателю или заполнить гитхаб. А потому что хотелось. Если этого нет — автор, вы уверены, что вы действительно хотели программировать? Насколько искренен человек, который хочет быть художником, но при этом рисует раз в год?

Node.js или Java: производительность, ресурсы, управление потоками, популярность и личный опыт

+7

Статья полна сравнениями тёплого с мягким, сферическими бенчмарками в вакуме и просто дилентантскими утверждениями.


Лень перечислять всё, для примера "один из минусов Node.JS":


был случай, когда разработчик удалил свою библиотеку из NPM и множество приложений использующих ее перестали работать;

1) NPM и Node.JS это разные вещи. Как можно делать вывод о платформе на основании менеджера пакетов?
2) Вот уже много лет с этого случая как в NPM запрещено удаление пакетов.
3) Есть альтернативы NPM и в виде менеджера пакетов и в виде хранилища.
4) Есть решения в виде локальных кеширующих NPM серверов.
5) Самое главное — приложения не "перестали работать". Удаление библиотеки никак не повлияло на работу приложений. А вот собираться они перестали.


О качестве остальной статьи делайте выводы сами.

9 лет в монолите на Node.JS

+1

Если у вас пять разработчиков в компании — то безусловно да. И мотивация "стек — отстой" — крайне плохая.


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

9 лет в монолите на Node.JS

0

Да, часто про molecular слышу хорошее от адекватных людей, но пока ни разу не трогал, о чём жалею.
Порекомендуете по нему хорошей литературы?

9 лет в монолите на Node.JS

0
есть потребность бизнеса и конкуренты не будут ждать идеальный код перфекциониста.

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


но стал выстрелом в ногу, даже в две, а потом и в голову

Да, ничего не даётся бесплатно. И при переходе на новые технологии и архитектуру ты обязательно сперва выстрелишь себе в ногу — вообще без вариантов. Нужно просто это пережить.

9 лет в монолите на Node.JS

0

Чуть выше писал — http, redis, rabbit. Обмен по большей части в JSON или ProtoBuf. Наверняка что-то ещё есть, о чём я не знаю. Какой-то единой шины нет — может быть, это принесло бы нам счастье, но навскидку не могу сказать проблемы, которую она бы решила. Но тут как — возможно, я просто не осознаю, что она есть.

9 лет в монолите на Node.JS

+1

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

9 лет в монолите на Node.JS

0

Да, как-то так. Главное — вовремя поймать момент, когда первое состояние переходит во второе, и осилить перейти. Но до него ещё нужно дожить, что выходит не так часто, как хотелось бы.

9 лет в монолите на Node.JS

+1

Да, проблем было гораздо больше, но я был ограничен и временем доклада и размером статьи. Огромное мало кто прочитает. Судя по комментариям, и эту длину многие читали по диагонали.


  1. Удалось ли при такой поэтапной миграции полностью отказаться отказаться от старого кода в монолите? И была ли такая цель вообще?

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


На сколько больше у вас стало девопсов в итоге?

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


Мс и монолит у вас on-premise?

Да, конечно. Свои облака, мощности, поднимаемые по запросу и в ответ на нагрузку, и прочие радости.

9 лет в монолите на Node.JS

-2
Не получается понять что всё-таки вы имеете в виду под этой необходимостью "проверять много переиспользований". Это какая-то ручная работа?

Ага. Например, замена кода при breaking changes, или проверка использования каких-то deprecated методов.


Так ведь его не меньше, его как минимум столько же. Только теперь вместо "Ctrl+click, Ctrl+click, Ctrl+click, о, всё понятно" это превращается в: "а, тут мы дёргаем другой сервис, окей, пошёл смотреть его код".

Крайне редко приходится смотреть что-то ещё, обычно скоуп задачи ограничивается одним сервисом. И даже если двумя, то это всё равно меньше кода, чем совокупность двух десятков сервисов в монолите.


Я понял, вы имеете в виду: "с микросервисами моя задача, как разработчика, вероятно, будет ограничина одним микросервисом".

Нет, я имею в виду, что много маленьких итеративные правки проще одной огроменной.


Как монолитность-микросервисность влияет на владение кодом?

Снова повторюсь. Обычно известно, какая команда отвечает за тот или иной микросервис целиком.


При монолитном подходе точно так же можно навешать измерялок на любые интересные части кода и мониторить их не "в среднем", а по-отдельности. Это же не какая-то магия, которая у микросервисов есть, а у монолитов нет.

Разделить использование RAM или CPU по исполняемым функциям на продакшне — не такая простая задача. Она тоже решаема, но распределить по микросервисам проще.

9 лет в монолите на Node.JS

+2
Опять же — проблема большого количества людей со своими вкусами. Не все команды были за внедрение TS. Насильно это делать не хотелось. А вот в микросервисах в некоторых командах он отлично зашёл.

9 лет в монолите на Node.JS

0
"использовать криво" — это про людей, а не про монолиты.

Повторюсь. Проблема — не в факте кривизны использования, а в количестве переиспользований, которые надо проверить за раз.


Это проблема дизайна: как сделать так, чтобы глядя на код было очевидно какие эффекты он вызывает. Микросервисы эту проблему вообще никак не адресуют.

Повторюсь. Меньше кода — проще понять.


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

Повторюсь. Перейти на мажорную версию, поправив 10 строчек — легко. Перейти на мажорную версию, поправив 1000 строчек — кошмар.


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

С микросервисами нам стало проще локализовать проблему в конкретном сервисе.


Это проблема JS и к монолитам отношения не имеет. Тут даже наоборот — будь у вас статическая типизация, монолит делал бы любую работу с кодом проще, чем микросервисы.

Это проблема JS+монолита. Я и имел в виду, что при статической типизации было бы порядком проще.


Искушение, конечно, вызвано тем, что зарелизить один сервис "проще", чем два.

В нашем флоу, разработчик делает задачи, и ничего не знает о релизах — так что ему всё равно, сделать правку в одном сервисе, или в двух.


С микросервисами фичи превращаются в "вот этот код, вон тот код, дождаться вон того релиза, и вот потом-то уже сможем зарелизить нашу фичу".

Да нет, просто релизим, но не включаем. Проверить её работоспособность можно и без зависимых микросервисов.


Часто бывает, что проблема в сервисе Z, который вызывает сервис Y, который в цикле дёргает X по 20 раз на каждую транзакцию :-)

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

9 лет в монолите на Node.JS

0
Понять, с какими именно тестами связаны изменения в коммите — задача весьма нетривиальная. Разве что сначала проверить покрытие текущее покрытие тестов. Смайлик.

Так что это время прогона всех юнитов. Наиболее результативным оказался поиск самых долгих тестов и их профилирование. Например, отрыли древний тест, в котором разработчик решил проверить, что несколько тысяч случайно сгенерированных величин будут действительно случайны… И мы проверяли это несколько лет!

9 лет в монолите на Node.JS

0
Да, некоторые технические ограничения приводят к более вдумчивой разработке и лучшему качеству кода — есть такое. И это не только про микросервисы.

9 лет в монолите на Node.JS

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

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

9 лет в монолите на Node.JS

0
Чуть ниже поправили, что всё же около 6к. И обработкой запросов занимаются сотни инстансов приложения — запросы у нас тяжёлые, это не выдача какого-нибудь куска статики, а подзапросы в большое количество внешних сервисов, их агрегация и обработка.

Циферки RPS на самом деле мало чего значат без понимания, что именно за запросы идут, и с чем можно их сравнивать, поэтому я их не очень люблю приводить — слишком многие начинают сравнивать тёплое и мягкое.

9 лет в монолите на Node.JS

0
Просто правки разбиваются на порции по числу микросервисов, в каждом из которых гораздо легче их внести, проверить и выкатить. Опять же, часто выходит, что большую часть микросервисов обновлять и не нужно.

9 лет в монолите на Node.JS

0
23кк/60/60 = 6.3к, если меня не обманывает математика. Про 383 только комментатор выше писал, забыв ещё раз на 60 разделить, а я внимания не обратил. И да — это среднее — у нас по большей части пользователи из РФ, так что ночью нагрузки почти нет.

9 лет в монолите на Node.JS

+3
При монолитной архитектуре никто не говорит, что должен быть единственный инстанс приложения.
Тем более, в случае Node.JS — будь это так — мы бы на одном потоке не пережили бы и открытие сервиса.
Инстансов у нас было большое количество, ещё и с распределением по ролям, окружениям, балансировкой — но это уже отдельная большая история.

9 лет в монолите на Node.JS

+1

Да, lint-staged это прекрасная вещь, мы его тоже используем, и тоже с хаски на прекоммите — потому что линтинг всех корректных файлов монолита занимает около двух минут.


Про slowlint у меня, видимо, плохо получается пояснять. Попробую ещё раз здесь.


Предпосылки такие:


  • У нас было большое количество файлов, которые не проходят линтинг. Почти все, на самом деле.
  • Хотелось, чтобы линтинг был в CI, но при этом не мешал разработчикам.
  • Хотелось, чтобы линтинг шёл постепенно. Прогонять --fix по всему репозиторию — чревато ошибками, грозит потерей верхнего слоя истории, мердж конфликтами, да и не поправит автомат и половины ошибок.
  • Хотелось, чтобы новые файлы обязательно соответствовали нашим стандартам.

Можно было бы вогнать всё в .eslintignore, но тут проблема — если это сделать, то любая IDE сразу применит его и перестанет использовать линтер — так что ничего лучше не станет. Хотелось таки мозолить глаза разработчикам. Поэтому slowlint делает очень простую вещь — он позволяет добавить дополнительный файл а-ля .eslignignore, который не воспринимается IDE, но используется при проверках. К сожалению, из коробки в eslint нет возможности использовать два игнор файла, иначе надстройка была бы не нужна.


В результате, файлы у нас делаятся на три категории:
1) Игонорируется в .eslintignore — те вещи, которые не надо трогать никогда — например, легаси библиотеки. CI, IDE и линтер их игнорирует. В целом, у нас уже нет такого кода в репозитории.
2) Игнорируется в slowlint — те вещи, которые надо исправить. IDE не воспринимает этот игнор, ошибки мозолят глаза разработчикам, код постепенно переписывается и удаляется из игнор листа. А ещё этот список можно автоматически перегенерировать при помощи slowlint, если внезапно куча некорректного кода исправилась или куда-то уехала.
3) Нигде не игнорируются.


Звучит несколько сумбурно, но отлично у нас отработало.


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

9 лет в монолите на Node.JS

Набор для игры в Лазертаг. Посвящается тем, кто играл в войнушку

0
Очень люблю лазертаг. Но проблема — хочется играть компанией человек в 8, при этом хотя бы с несколькими режимами — десматч, командный десматч и захват точки. К сожалению, описанная в статье игрушка всего этого не даёт. Думал какое-то время собрать сам — протокол-то известный, и делается в пол пинка на ардуинах — даже есть соответствующие исходники и схемки — но вот времени на это никак не хватает. А сподвигнуть никого не смог, даже за деньги. Какое-то время думал просто купить готовый набор — но он каких-то совсем несуразных денег везде стоит.

MMORPG в одиночку (2d stalker)

+16
Так почему не вложить в открытый доступ код? Если вы не собираетесь монетизировать проект, то минусов у такого решения нет. Понятно, что стыдно обычно… Но пускай это вас не останавливает.

Плюсы выкладки:
1) Могу найтись ещё энтузиасты, которые вам помогут. Если не разработкой, то может быть контентом или графикой.
2) Возможно, кому-то это поможет понять, как работают игровые движки, или сделать свою игру на основе вашей, что тоже приятно.

Как проходят алгоритмические секции на собеседованиях в Яндекс

+35
Полным аналогом подобных собеседований для разработчиков является прохождение IQ тестов для любой другой специальности. Когда-то это даже было популярно. Но со временем таки большая часть адекватных людей осознала, что результат прохождения IQ тестов зависит только от того, сколько человек тренировался в прохождении IQ тестов.

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

И вдвойне забавно выглядит то, что компания фактически признает то, насколько синтетические у неё собеседования — публикуя советы, рекомендуя leetcode и целый сервис «контекст» исключительно для того, чтобы люди могли проходить эти тренировки.
Не, я не спорю — решать алгоритмические задачи весело и интересно. Как и всякие там IQ тесты, тренажёры для мозгов типа luminocity и так далее. Но у меня есть подозрение, что таким образом компания теряет людей, которые действительно занимаются разработкой, и у которых нет времени или желания тренироваться в прохождении синтетических тестов.

Я прочитал 80 резюме, у меня есть вопросы

0
Да, доверяют. По сути это минимальная проверка на адекватность — что человек в нужном городе, на нужном стеке, с релевантным опытом, с разрешением на работу, смог внятно заполнить резюме и договориться о интервью. А не откликнулся на вакансию, например, с идеей продать нам свою CMS (да, и такое бывает).

Кроме этого, HR так же общаются с человеком на очном этапе на пространные темы. Редко бывает, чтобы что-то насторожило, но в этом случае уже вырабатывают общее мнение со всеми, кто беседовал с соискателями.

Но у нас HR реально крутые. До сих пор (два года уже) приятно, насколько было адекватное общение при устройстве на работу.

Я прочитал 80 резюме, у меня есть вопросы

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

1) Моё хобби и личные увлечения не должны иметь значения для компании. Не то, чтобы мне было что скрывать, но зачем?
2) Сопроводительное письмо я буду писать только если я собираюсь прям в дрим тим. Если компания с моей точки зрения рядовая — я просто буду кидать резюме пачками. Пусть и с более низкой конверсией. Потому что ценю своё время и потому что считаю выдавленное из себя сопроводительное письмо извращённой формой лести — не хочу идти в компанию, где это реально важно.
3) Нет, я не буду указывать минусы. Потому что не знаю, как оценит это читающий, и насколько важно в его глазах это будет. В двух предложениях сложно раскрыть минусы подробно, а эссе я писать не буду — длинные резюме сразу уходят в помойку, большинство людей не осиливает их читать. Если интересно, о минусах можно поговорить на личном собеседовании.

Как не поддаться панике, если в гости нагрянуло много программистов?

+1
Хотел увидеть про проблемы и лайфхаки, увидел только рекламу…

PHP GR8: повысит ли JIT производительность PHP 8

-7
Я к тому что эти «80% рынка» не имеют отношения к разработке, и являются готовыми настроенными решениями. Что никак не должно влиять на решение выбора языка при разработке своего проекта.

Если мы хотим узнать, что именно «на рынке» — можно, посмотреть последний опрос на stackoverflow по используемым языкам, например. Или зайти на hh и сравнить количество вакансий по разным языкам. И увидеть, что там и в помине нет никаких 80% PHP.

PHP GR8: повысит ли JIT производительность PHP 8

-15
Есть ложь, есть наглая ложь, а есть статистика.

Убираем из этой статистики друпалы, вордпрессы, битриксы и так далее — получим совершенно другую картину.
Ну или можно пойти от обратного — как много вы знаете крупных порталов, продуктов и систем, которые написаны на PHP?

Если кто-то правда сидит и думает, на чём ему написать очередной CRUD — да, PHP отлично под это подходит. Но разбрасываться фразами про «доминирование» и «делаете неправильно» — это очень странно. Причём вне зависимости от контекста.
1 There