Stack Overflow может закрыться в ближайшие месяцы после почти 20 лет работы. Причина — стремительный рост популярности нейросетей, к которым разработчики всё чаще обращаются за помощью вместо поиска ответов на SO. По данным разработчика Теодора Смита, количество новых вопросов на Stack Overflow за последние два года сократилось на 76,5%, что ставит под угрозу дальнейшее существование ресурса.

Как вы думаете, какие последствия нас ждут, если SO закроется? Сможет ли ChatGPT быть достаточно умным, чтобы самостоятельно придумывать ответы на вопросы о новых фреймворках, которые появятся в будущем?

Источник

В продолжение темы о выгораниях. Пока вы с нетерпением ждёте новогодних каникул, ребята из Долины впахивают до роскомнадзора. Статья 2017 года, но судя по рассказам с мест история ещё вполне имеет место быть.

https://www.nytimes.com/2017/08/31/opinion/sunday/silicon-valley-work-life-balance-.html

Очевидно, что всё с подключением к интернету подвержено кибератакам. Пока на реальные штуки нападают не так часто, как в кино, но то ли ещё будет. Учитывая, что в IoT-стартапах про безопасность порой вообще не вспоминают.

https://vc.ru/trade/184130-postamaty-pickpoint-stali-avtomaticheski-otkryvat-dvercy-v-rezultate-kiberataki

В продолжение к предыдущему посту.

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

https://stringconcat.com/ru/a-little-bit-about-content-discovery-ru/

Новая статья в нашем блоге. Рассказываю о своем опыте переезда. Сегодня речь пойдет про транспорт в Сингапуре. Своя машина или общественный транспорт
https://stringconcat.com/ru/it-emigration-singapore-transport/

Всем привет!

Наш вебинар на тему «Рефакторинг архитектуры бэкенда: от MVC к Clean Architecture» начнется через час, в 11:00 по Москве.

Ссылка на трансляцию

Мы обещалим выслать Чек-лист идеального проекта. Обещали - высылаем!

Плох тот разраб, что не хочет поработать в Гугле. Но что действительно происходит в огромных IT-гигантах и так ли густо там намазано мёдом? Мы с друзьями поработали в Yandex, ThoughtWorks и других топовых конторах, а теперь делимся опытом и впечатлениями в цикле статей.
Читайте первую:

Работа в IT-гигантах. Часть 1: как туда устроиться

Нашел первоначальное поределние Big ball of mud. Что называется не отнять, не добавить

Большой шар грязи - это беспорядочно структурированные, разрастающиеся, скрепленные скотчем и проволокой джунгли в стиле спагетти. Эти системы демонстрируют явные признаки нерегулируемого роста и неоднократного ремонта. Информация распределяется между удаленными элементами системы беспорядочно, часто до такой степени, что почти вся важная информация становится глобальной или дублируется. Общая структура системы, возможно, никогда не была четко определена. Если бы переделка таких систем была возможна, они исчезли или изменились бы до неузнаваемости. Программисты, у которых есть хоть капля архитектурного чутья, избегают этих болот. Только те, кто безразличен к архитектуре и, возможно, довольны инерцией повседневной рутинной работы по заделке дыр в этих разрушающихся плотинах, довольствуются работой с такими системами.
Брайан Фут и Джозеф Йодер, 1997 год

Стоит заметить что воз и ныне там...

Давно бьюсь с любителями замокать все подряд. Я бы сказал Mock Driven Developer’ами. Оказывается уже 6 лет как написана статья Робертом С Мартином, который сказал “Mock across architecturally significant boundaries, but not within those boundaries”. Не добавить не убавить. http://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html

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

https://stringconcat.com/ru/work-for-faang-ru-2/

Заключительная статья из цикла о работе в конторах уровня FAANG. Про деньги, оценки эффективности и перспективы трудоустройства после. Ну, и главный вывод из всего цикла: поработать хорошо, но неведомого чуда не произойдёт.
https://stringconcat.com/ru/work-for-faang-3-ru/

Боже, это просто чудесная утренняя история: исследователь безопасности заметил в статье сотрудника PayPal упоминание нескольких внутренних пакетов, в т.ч. analytics-paypal. И для эксперимента разместил пакет с таким же названием в публичном репозитории. И что вы думаете, конечно же часть внутреннего софта от PayPal собралась с использованием его пакета, который "стучал на землю" ему в сервера.

Как следствие исследователь провернул совершенно аналогичную атаку на почти все крупные айти компании-гиганты. И если подумать, я знаю где у меня совершенно такие же проблемы, пойду чинить https://www.bleepingcomputer.com/news/security/researcher-hacks-microsoft-apple-more-in-novel-supply-chain-attack/

Никогда такого не было и вот опять!

Интересный пост от Владимира Хорикова о DDD-трилемме. Не совсем согласен с выводом о том, что нужно предпочитать чистоту (мне больше по душе инкапсуляция), имхо всё-таки некоторые внешние операции допустимы, правда их совсем немного. Но такая трилемма действительно имеет место быть.
https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/

Хорошая подборка бесплатных и условно-бесплатных сервисов для разработчиков. CI/CD, мониторинг, управление логами, бесплатные опции крупных облачных провайдеров и другое.

https://free-for.dev

Если вы только собираетесь создавать новый проект на java\kotlin\scala, то я для вас нашел отличный репозиторий. Из него можно позаимствовать gradle\maven конфигурацию, с подключенными и настроенными тулзами типа линтеров, jococo и всех прочих.

Если же не собираетесь стартовать — просто почитайте его readme файл, уверен что вы найдете не одну best практику, которую стоит использовать.

https://github.com/binkley/modern-java-practices

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

https://stringconcat.com/ru/coding-interview-ru/

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

На что я обратил внимание
- пара ссылок на книгу Team Topologies (в когнитивной нагрузке и платформенных командах);
- облачные песочницы, даешь дев-стенды разработчикам!
- захолдили SAFe и GitOps.
- захолдили пулл-реквесты как инструмент peer review (недавно делал пост со схожими мыслями).

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

Знакома ли вам ситуация, когда ответом на любой вопрос является "так исторически сложилось"?
-Почему у нас здесь микросервисы?
-так сложилось. Всегда были.

-почему мы используем кафку?
-не знаю, вроде нормально ведь.

Чтобы не попадать в такие ситуации придуманы architectural decision records. Это фиксация принятых архитектурных решений с обоснованием почему. Если хотите начать использовать, то вам в помощь прекрасный шаблон ведения таких записей.

https://github.com/adr/madr

Да, это хорошая идея вести запись прямо в репозитории

Одно дело, когда политик спрашивает «Как ваши дела?», и совсем другое, когда ваша мама спрашивает «Как ваши дела». Они имеют ввиду совершенно разные вещи.

Таким образом, 2 семантически одинаковые фразы имеют совершенно разное значение в зависимости от контекста. И вот тут то мы пришли к определению Bounded Context из DDD.

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

Нашли такую фразу? Поздравляю! Вы нашли bounded context. И два значения одного и того же термина.