Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих от Бхаргава А. Эта книга рекомендована Яндекс Практикум при подготовке к алгоритмическому собеседованию. Сам автор указывает, что книга для самоучек, студентов, выпускников и тех, у кого программирование не является основным профилем.

Мое впечатление неоднозначно. С одной стороны, до сего момента я не встречал описания динамического программирования, поиска кратчайшего пути в графе по алгоритму Дейкстры и использование K ближайших соседей для классификации и аппроксимации (возможно, все это есть в 4^м или последующих томах Кнута, но в магазине они мне не встречались). С другой стороны, описания и примеры, приведенные в книге, таковы, что практической пользы не представляют. Описания очень поверхностны, примеры нарочно примитивны, код в половине случаев не приведен. Но даже там где есть код, он нарочито упрощен под конкретный пример и на практике бесполезен.

Казалось бы, есть масса книг - каталогов шаблонов. Они реально полезны и новичку и профессионалу. Эта книга не из их числа. Но, видимо, это и не было целью. Напоминает научно-популярные книги издававшиеся в СССР: простым языком рассказывает о сложных вещах, прививает у читателя интерес к теме, расширяет кругозор. Не более. Но тоже важно.

Вернемся к Яндекс Практикум и их рекомендации. Если алгоритмы так важны, то почему именно эта книга? Есть масса других, где и алгоритмов больше и разобраны они так, что бери да пользуй. Например, классический труд Д. Э. Кнута Искусство программирования. Да, рисунки в детском стиле в Грокаем алгоритмы забавны. Но иллюстрации в Искусство программирования полезны для понимания. Разве это не важнее, если уж кандидата посылают на алгоритмическое собеседование?

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

Представьте себе ситуацию. Скоро истекут сроки подачи документов в колледж. Очередная партия новичков изберет профессию, адепты которой постоянно задаются вопросом: «А нужны ли будут программисты через год... через пять лет... или через десять лет?». И хотя горячие дебаты на этот счет уже улеглись, в воздухе висит немой вопрос: не настанет ли час, когда крупные языковые модели, такие как ChatGPT, заменят нас на поприще написания кода. Неважно, кто ты — абитуриент, зависший в нерешительности перед выбором ВУЗа, или матерый кодер, я предлагаю тебе остановиться и кое-что переосмыслить. А поможет нам в этом деле... кукла Барби.

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

Многие компании успешно внедрили практики DevOps в свой инженеринг. Мы в SHARE NOW сделали также. Команды в компании ответственны не только за разработку программ, но и за то как эти программы попадут в продакшен, и как они будут обслуживаться. You build it — you own it.

Остается вопрос — как узнать что мы на правильном пути? Как измерить DevOps? Здесь нам и помогут DORA метрики.

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

На Хабре неоднократно в комментариях звучало мнение, что Россия впереди планеты всей по онлайн‑сервисам. Мол, у нас и госуслуги, и финтех, и такси, и доставки — все на высочайшем уровне, а в остальных странах, а особенно в отсталой Европе бедные бюргеры до сих пор стоят в многочасовых очередях, заполняют вручную тонны бумажек и ждут в очередях на кассах чтобы сделать банковский перевод, а курьер не привезет им ночью смузи в течении получаса после заказа. Давайте разбираться, так это или нет.

_{— Стакан наполовину пуст или наполовину полон?
— Мы инженеры. Стакан изготовлен по неверной спецификации.
/Сериал "Мир Дикого Запада" (Westworld)/}

В середине этого января я шла с учёбы домой мимо могилы Ивана Кулибина. Простудный насморк не давал продышаться, я то и дело останавливалась среди гигантских сугробов. У памятника стоял первоклассник с бабушкой, внимательно его разглядывал, а потом спросил: «Кто это?». «Изобретатель», — машинально подумала я. «Великий русский инженер», — ответила бабушка. «Ин-же-нер», — повторил мальчик, кивнул и продолжил рассматривать чертежи на камне.

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

Боитесь стажёров? Не хотите тратить своё время на обучение начинающих специалистов? Задач много, а специалистов по ИБ мало?

Делюсь опытом построения стажёрского конвейера на базе SOC. Может, это решит ваши проблемы.

Многие российские современные IT-компании имеют стажёрские программы. Я знаком с несколькими примерами ИБ-стажировок в таких компаниях, но ничего близкого к описанной далее реализации не нашёл. Мне кажется, что всё просто и очевидно, но почему вы так не делаете? Не найдя ответа на вопрос, решил написать об очевидном, подкрепляя личным опытом.

Хочу поделиться своим опытом реализации микросервисной архитектуры поверх actor-model фреймоворков, таких как AKKA и Microsoft Orleans.

Моя гипотеза: если использовать один стек для реализации микросервисов, то можно:

• Существенно снизить сложность разработки и объем кода
• Упростить отладку и поиск ошибок
• Упростить деплой
• Упростить задачу определения границ сервисов
• Избавится от ограничения применения stateful-сервисов
• Упростит работу с распределенными транзакциями.

О… Похоже на «серебряную пулю»! Давайте разберемся, так ли это.

Сегодня ровно 20 лет, как я начал программировать профессионально. За эти годы я:

• Получил одобрение на петицию по грин‑карте за выдающиеся способности в науке.
• Стал Google Developer Expert.
• Стал IEEE Senior Member.
• Был операционным директором в компании со 100 сотрудниками.
• Написал код, который скачали 135 миллионов раз.
• Выступал перед аудиторией в 2000 человек, дважды.
• Стал самым честным человеком в России по версии НТВ.

Но упустил я гораздо больше и делал всё это слишком долго. Думаю, этот путь можно было бы пройти «на скорость» лет за 5 с теми подходами, принципами и приоритетами, которым я научился. Если вы только начинаете свой путь, этот текст может сэкономить вам 15 лет жизни.

Привет! Меня зовут Сергей, я бэкенд разработчик команды SEO в Банки.ру.
В этой статье хочу описать свое знакомство с техникой Trace Based Testing (TBT): 

• расскажу о концепциях, которые чаще всего используются сейчас в тестировании
• кратко опишу, что такое distributed tracing 
• поделюсь опытом работы с TBT. 

Статья — мой субъективный взгляд на технику как бэкенд-разработчика. QA инженеры могут со мной поспорить и, скорее всего, будут правы.

Поп-культура — зеркало общественных настроений. В книгах, фильмах, музыке, комиксах и компьютерных играх часто находят отражение не только сами исторические события, но и рефлексия авторов произведений об этих событиях. Недавно в Голливуде произошло одно из таких: забастовка Гильдии сценаристов закончилась их победой. Среди прочего сценаристы добились от киноиндустрии обещания не заменять их труд работой ИИ. Беспрецедентная победа человека над машиной! Любопытно, как теперь роботы и социальные утопии о будущем будут представляться сценаристами в сериалах и фильмах. Пока такие истории ещё только рождаются в киностудиях по всему миру, а мы решили заглянуть в прошлое и посмотреть, как сценаристы и режиссеры представляли себе технологию искусственного интеллекта и как отношение к ней менялось с течением времени.

Всем привет, меня зовут Иван. Хочу поделиться опытом, который может пригодиться тем, кто захочет сделать такую же странную вещь, как и я, — установить OpenSuse на планшет с Windows.

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

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

Спустя четыре месяца (испытательный закончился) у многих закрались подозрения, что на самом деле парень ничего не делает. Но как доказать это со стороны объективно? Решили посмотреть историю коммитов. Оказалось, он почти не коммитил (последний месяц вообще перестал), а на совещаниях ссал в уши ездил по ушам. Парень продолжил работать на прошлой работе и был преподом на курсах. Такой вот overemployed, с двумя зарплатами по ставке синьора.

Ему предложили перевестись в другой отдел. Менеджеру все сошло с рук. Часть разрабов сидела с лицами «‎а что так можно было?»‎. А я понял, что нельзя так просто взять и посмотреть статистику коммитов.

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

Шел 2021 год, русские хакеры продолжают переигрывать и уничтожать загнивающий Запад, вмешиваясь в выборы, ломая фейсбуки и пентагоны. Тем временем на Хабре выходят статьи о создании неубиваемых Kubernetes-кластеров, которые, по видимому, всех нас переживут. А кто-нибудь подумал о простых пацанах (пацанессах)??? Как быть обычному программисту, который хочет свой небольшой кластер и ламповый CI/CD с автодеплоем приложения, чтобы кенты с района не засмеяли?

Всем привет, меня зовут Алексей и я алкоголик разработчик на Python/Go в Домклик. Сегодня мы будем понижать порог входа в self-hosted Kubernetes и GitLab AutoDevops.