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

В мире победившего эджайла, SCRUM, как один из наиболее популярных фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков он стал чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами. Более того, сегодня строгая приверженность принципам SCRUM нередко становится маркером профнепригодности для людей, которые имели неосторожность переродиться из полноценных проектных методологов и руководителей в фанатично зацикленных на ритуалах scrum-мастеров (речь не обо всех, но о об очень многих). В посте попытался обобщить все проблемы SCRUM, как "фреймворка" для проектного управления и создания продуктов.

2024 год рисует жестокую кривую с объемом кандидатов в IT. Мы подровняли её и разобрались — кто, куда и зачем? Опубликовали пять вакансий на самые объемные специальности и анализируем полученные данные: как опытные специалисты выдавливают джунов, с чем сталкиваются новички и где у них есть шанс прорваться?

Нашёл у себя в ящике стола один очень старый каталог книг Microsoft Press за 1988–89 годы. Мне нравится иногда его доставать, перечитывать описания компьютерных книг тех лет, разглядывать их обложки. Да и просто названия книжек из этого проспекта заставляют погрузиться в ностальгическое настроение.

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

Когда-то давным-давно (почти десять лет назад) мне пришлось писать довольно много статей для разных компаний, которые впервые выходили на Хабр. Среди них были совсем небольшие стартапы, IT-компании побольше, международные корпорации, и все они хотели одного: написать статью, которую все прочитают, запомнят и к которой читатели непременно вернутся. Практически утопия. Идея найти формулу идеальной статьи сродни попыткам отыскать философский камень: вроде все компоненты есть, рецептура есть, но всегда чего-то не хватает. И кажется, что на Хабре волшебную формулу ищут многие. Кто-то пишет статью с самым высоким рейтингом, кого-то добавляют в закладки сотни пользователей, кто-то — мастер вызывать аудиторию на обсуждение и собирает буквально бесконечные ветки комментариев. А если автор опытный, то он периодически миксует суперспособности своих публикаций.

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

Однажды, выполнив в Гугле запрос "Three body problem" ("Задача трёх тел"), я был просто поражен - первая страница результатов состояла только из ссылок на роман китайского писателя-фантаста Лю Цысиня с соответствующим названием, а также на телесериал, снятый по этому роману, т.е. ссылок на собственно задачу трёх тел не было вообще! Мне это показалось удивительным и несправедливым, поскольку сама по себе задача трёх тел тоже может выглядеть увлекательной в популярном изложении. В этой публикации я постарался привести некоторые доказательства этого утверждения.

Когда в последний раз вы сталкивались с трудной для понимания темой? Или проводили часы за просмотром обучающих видео на YouTube?

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

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

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

Если вы когда-нибудь использовали в работе retrieval augmentation generation (RAG) на базе векторного поиска и не лезли туда под капот, но были бы не прочь, я постараюсь погрузить вас в то, как устроена векторная база данных внутри.

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

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

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

Привет, с вами снова Даша и Uzum Market. В прошлый раз мы глубоко погрузились в пайплайн работы поиска нашего маркетплейса, и я обещала вам вернуться с новостями о его улучшении. Так вот, время пришло, и сегодня мы поговорим про наш опыт внедрения векторного поиска!

О, таблица merchants2? Да, у нас закончились столбцы в merchants, поэтому мы сделали merchants2.

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

Однако как‑то на всем известном видеохостинге я наткнулся на трансляцию мужика с проекта Moscow Python (прошу прощения, имя я не запомнил, и сейчас уже просто не найду) который вещал что‑то о начале пути питониста, а заодно рассказал о программе для изучения английского языка Anki. А далее, прямо на трансляции, он сам решил написать аналогичную программу, но совсем в примитивном виде. И тут, очевидно вдохновившись, меня посетила идея, что вполне полезной могла бы оказаться программа для изучения технического английского языка. Ну зачем мне сразу весь язык, если в конкретный период времени он мне необходим только для уверенного чтения и понимания документации. И я написал...

Иногда в жизни бывает так – вам вручают белую каску менеджера вместо привычной оранжевой или синей каски исполнителя и говорят: «Теперь ты — руководитель проекта. На тебя вся надежда». Что делать, если при этом вы не изучали, например, PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами)? Вы могли в них участвовать, но отвечали за функционал и делали работу руками. Как пересесть в другое кресло и вжиться в иную роль, по возможности гася в себе синдром самозванца?

В ЛАНИТ мы выполнили тысячи различных проектов – внутренних, внешних, с различными видами контрактов и оплат, сервисных и строительных, связанных с привлечением десятков субподрядчиков. Персонально я когда-то тоже получил белую каску – управлял внедрением ERP-систем, руководил отделом консалтинга, вел международные и локальные проекты. Так что сегодня дам несколько, надеюсь, полезных советов.

Иногда про великих людей говорят: «Они изменили мир». Про нашего героя я так говорить не стану. Он целый мир создал! Гэри Гайгэкс не просто автор, он настоящий демиург, творчество которого прямо повлияло на жизнь многих поколений игроков. Коснулось оно и тех, кто никогда в жизни не держал двадцатигранную кость, ведь D&D – это целый мир, а не просто одна из игр… Однако и жизнь Гэри порой напоминала игру. Был там и риск, и азарт, и горы золота, и прекрасные женщины, из-за которых мужчины ненавидели друг друга, и даже драконы, готовые сожрать нашего героя. А убив некоторых из драконов, герой и сам начинал превращаться в монстра… Сегодня мы будем говорить про Гэри Гайгэкса, ведь его жизнь – то ещё приключение, вполне достойное стать основой для великолепной игры от создателя Подземелий и Драконов.

Сколько открытых багов у вас в бэклоге? 100? 1000?
А сколько времени они там лежат? Неделю? Месяц? Годы?
А почему так происходит? Нет времени? Надо делать более приоритетные задачи? «Вот сейчас все срочные фичи реализуем, а потом точно будет время на разгребание багов»?

… Некоторые используют Zero Bug Policy, у кого-то хорошо развита культура работы с багами (своевременно актуализируют бэклог, пересматривают ошибки при изменении функциональности и т.д.), а кто-то выращивает волшебников, которые пишут вообще без багов (маловероятно, но, может, и такое бывает).

Сегодня я расскажу вам про наше решение по чистке бэклога багов — проект «Багодельня».

Проблемы в организационных процессах компании заметны не сразу. Поначалу «звоночки» кажутся случайными ошибками. 

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

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

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

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

Мне не раз попадались такие проекты, от кода которых берет оторопь. Такое чувство, что сами авторы не смогут объяснить - почему у них все выглядит именно так. В этот момент у меня возникает вопрос: как так получилось? Если вас он тоже волнует, то могу пожелать лишь приятного чтения.

Несколько лет назад я собирал материалы для Музея скинов Winamp, и часть файлов показалась мне повреждённой. Я решил исследовать их, и оказалось, что на самом деле эти скины являются просто zip-файлами с другим расширением. Что же будет, если извлечь эти файлы? О, чего там только нет!