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

Разумеется, многие из таких сервисов существовали и раньше, однако именно на 2022 и 2023 годы пришелся их рассвет — настолько стремительный и яркий, что неподготовленный пользователь может легко заблудиться в этом новом направлении.

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

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

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

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

Привет, Хабр! Меня зовут Владислав Воячек, я работаю архитектором в ИТ‑холдинге Т1. Одна из моих задач — управление техническим долгом. И хочу поделиться с вами современными подходами к решению этой непростой задачи.

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

Не тратьте время на задачи – сначала разберитесь в основах. В статье:

1. Как проходят собеседования (ВАЖНО!)
2. Big O, оценка сложности алгоритмов
3. Популярные техники: два указателя, DFS, динамическое программирование и другие
4. Какие задачи решать, чтобы пройти в Яндекс

Читаем, практикуемся, получаем оффер!

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

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

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

Agile-манифест был подписан аж в 2001 году, и неужели за прошедшие 25 лет, никто не захотел в нём что-то поменять?

Я предлагаю посмотреть на «12 принципов» с точки зрения того, как гибкие подходы могут адаптироваться к управлению проектами в зависимости от масштаба задач и стадии готовности продукта. Это не просто моё мнение — 3 дня обучения бок о бок с другими руководителями проектов из разных сфер только убедили меня в том, насколько важна эта тема.

Зачастую, когда речь заходит про принцип инверсии зависимостей, можно услышать, что инверсия зависимостей (далее DIP) — это что-то там про зависимость от абстракций, и приводятся примеры, где в качестве «плохого» случая, используются конкретные классы, а в исправленном случае, используются абстрактные классы или интерфейсы. Но такая трактовка принципа в корне неверна.

Почему такая трактовка неверна и в чем же суть принципа — об этом и пойдет речь далее.

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

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

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

Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код.

В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше.

Например, в чистом коде я до сих пор не знаю способа за конечное время дать ответ на вопрос «Сколько уровней абстракции в этой функции?». А если взять DDD — то я до сих пор не знаю способа, который бы позволял стабильно и за конечное время находить границы между ограниченными контекстами (прошу прощения за каламбур) или агрегатами.

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

Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял.

Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет.

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

Привет, Хабр! Меня зовут Сергей Махнаткин, я работаю разработчиком в отделе User Experience в Yandex Cloud. В прошлом году мы писали о нашей дизайн-системе и библиотеке компонентов Gravity UI. С тех пор система не раз обновлялась и обрастала новыми функциями, и сегодня я хочу рассказать о новом инструменте — Markdown Editor, который значительно упрощает процесс работы с документацией.

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

Ресурсы

• Build Your Own Text Editor — наверно, самый фундаментальный пост о создании текстового редактора с нуля, который я видел. Это превосходный туториал на случай, если вы хотите начать писать собственный текстовый редактор. Стоит заметить, что в редакторе из этого туториала в качестве внутренней структуры для текста используется, по сути, вектор строк.
• Text Editor: Data Structures — отличный обзор множества структур данных, которые можно использовать при реализации текстового редактора. (Спойлер: как минимум одна из них будет рассмотрена в моём посте)
• Плейлист Ded (Text Editor) на YouTube — это потрясающая серия, в которой @tscoding фиксирует процесс создания с нуля текстового редактора. Эти видео стали для меня источником вдохновения.

Зачем?

1. Я хотел заняться проектом, непохожим ни на один свой прошлый.
2. Я хотел создать инструмент, которым смогу пользоваться.
3. Мне всегда хотелось глубже разобраться с созданием собственных структур данных.

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

Здесь вы узнаете о 4 уровнях модели TCP/IP. О том, что такое MAC-адрес и IP-адрес, и зачем нам 2 типа цифровых адресов. Как работает DNS. Зачем нужны коммутаторы и роутеры. Как работает NAT. Как устанавливается защищённое соединение. Что такое инфраструктура открытых ключей, и зачем нужны TLS-сертификаты. Чем отличаются три версии протокола HTTP. Как происходит HTTP-аутентификация. И в конце будет несколько слов о VPN.

Сочетать учёбу и работу в IT – задача, мягко говоря, непростая. Даже если вы только ходите на занятия и делаете «домашку». А уж если вы захотите сами организовать обучение – сложности будут расти в геометрической прогрессии.

Недавно наша команда iOS-документов в МойОфис решила перейти на SwiftUI – декларативный UI-фреймворк от Apple. После достаточно безболезненного рефакторинга модуля с UIKit на SwiftUI оставалось всего ничего – обучить коллег новому фреймворку.

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

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

Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:

Мы работаем по Agile. Спринты по 1-2 недели

Под "Agile" они, конечно же, имеют в виду Scrum. Но я с уверенностью могу сказать, что ни в одной компании, что я работал, Agile'ом даже и не пахло. И тут я даже не говорю о том, что Agile каким он был задуман в принципе не дошел до массовой разработки (о чем рассказывал один из создателей Agile Дейв Томас на конференции GOTO 2015). Я говорю об Agile в общепринятом значении этого слова.

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

По некоторым причинам команде разработчиков либо не получается наладить работу по Agile, либо руководство знает, как лучше, и навязывает собственное видение методологии разработки. Эту проблему адресовал в своей статье Рон Джефрис (вот перевод на русский), дав красноречивое название подобным практикам — "Dark Scrum". Существует и более мягкая формулировка для тех, кто считает подобное положение вещей скорее фичей, а не багом — "Pseudo Agile" или "Post Agile".

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