То, что ChatGPT может автоматически генерировать что-то, что хотя бы на первый взгляд похоже на написанный человеком текст, удивительно и неожиданно. Но как он это делает? И почему это работает? Цель этой статьи - дать приблизительное описание того, что происходит внутри ChatGPT, а затем исследовать, почему он может так хорошо справляться с созданием более-менее осмысленного текста. С самого начала я должен сказать, что собираюсь сосредоточиться на общей картине происходящего, и хотя я упомяну некоторые инженерные детали, но не буду глубоко в них вникать. (Примеры в статье применимы как к другим современным "большим языковым моделям" (LLM), так и к ChatGPT).

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

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

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

Привет, дорогой Хабр. Душа просит выговориться, так что я пришел к тебе – заодно надеюсь поделиться чем-то полезным с молодыми айтишниками. За свою карьеру я прошел через фриланс, стажировки, корпорации, смену профессии и даже запуск собственного SaaS'а (об этом как-нибудь отдельно...). Я наделал кучу ошибок и набил болезненных шишек. Под катом я вспоминаю 5 важных уроков, которые я бы хотел получить 10 лет назад.

Кто-то в качестве своего первого серьезного проекта пишет калькулятор, другие веб-сайт и в принципе идея ограничивается только скилами и вашей собственной фантазией (или фантазией преподавателя, если у вас такой есть). Калькулятор мне писать не хотелось (как минимум из-за наличия прекрасной функции eval частично заменяющей его), а для веба на тот момент я был слишком зелен и ничего не понимал в протоколах, html, фреймворках и т.д.

Но месяцы за изучением Python были пройдены, сотни задач на Stepik, Leetcode и подобных ресурсах решены, десятки часов Хирьянова и других святил на Youtube с упоением просмотрены и руки невероятно чесались написать что-то «своё, масштабное и нужное».

Привет. Мне 32 года, идентифицирую себя как Middle Frontend Developer. У меня почти 7 лет опыта работы, из которых только три я считаю релевантными, где я работал с современными технологиями типа React, TypeScript, GraphQL и т.д. До этого работа заключалась в разработке сайтов с использованием JQuery.

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

Есть ли так самая «очередь за забором» или нет? Есть ли на рынке кадровый голод? Ответ и да, и нет одновременно.

Вот представьте, вы большая компания, и вам нужен водитель на авто. Вы размещаете вакансию, на следующий день у вас тысяча откликов. Листаете резюме:

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

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

Так при чем тут "культурный контракт"? Все просто, при приеме каждого сотрудника моя первая беседа с ним была на основе тезисов:

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

Игнорируй лишний контекст.
ыва


Помешанность на созвонах. Прими это как данность.

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

Айти в целом это вечный туман войны и research.

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

Плюсы и минусы профессии

Идеальное место работы (спойлер: только в твоей голове)

Удалёнка (подводные камни)

Наличие нескольких работ - для многих физическая необходимость, т.к. работодатели как минимум в 4 случаях из 5 - лжецы.

Зарплаты.
Вы будете удивлены, но я бы хотел приоткрыть вам зазеркалье:

/

Замечания о математике, алгоритмах и методах, применяемых при компьютерной симуляции флюидов (например, огня и дыма) в режиме реального времени.

Исходный код к этой статье выложен на GitHub.

Огонь как явление очень интересен с точки зрения компьютерной графики. Раньше огонь было принято имитировать. Например, в фильме «Властелин колец» Питера Джексона для изображения огня использовались спрайты с огромным количеством дыма (на тот момент симуляция флюидов обходилась слишком дорого, даже при бюджете блокбастера). Когда требовалось моделировать огонь в режиме реального времени, например, в видеоиграх, использовались почти исключительно нефизические подходы.

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

"Сесть за компьютер, написать и запустить программу Hello, world. Одновременно скачать книжку с описанием языка и базовых приемов и читать ее в общественном транспорте, перед сном и в приемной у зубного врача. Периодически садиться за компьютер, написать и отладить программы: сортировки массива, игры Жизнь, ханойских башень итд. С выводом на текстовый терминал, окно в GUI или веб-страницу - по вкусу. Далее вы поймете в какую сторону копать или не идти в это дело вообще."

Молодой человек вас горячо благодарит и уверяет как он сильно хочет стать настоящим программистом. Потом он Hello, world не пишет и никакой книжки читать не начинает, но последовательно спрашивает у вас:

Мы получили 1022 заявки, приняли из них 918, в шорт‑листы попало более 300 статей. Точной цифры по шорт‑листам нет неслучайно: поскольку наш естественный интеллект это вам не ChatGPT склонен уставать и ошибаться, несколько статей могут попасть в шорты, но, скорее всего, выпадут из них — так, во время подготовки этой статьи выяснилось, что из финала выбыли двое участников, скрывшие свои публикации в черновики.

Вообще, такого «Технотекста», как в этот раз, ещё не было: обычно мы сравнительно легко отсеивали участников и выбирали финалистов, разница в уровне материалов была очевидной. В этот раз номинанты сильные — и многие статьи не вышли в финал не потому, что они какие-то не такие, а потому что они объективно слабее лучших из лучших — но очевидно, что сильнее большей части статей на Хабре. Хотя участники «Технотекста» из года в год находят отличные способы добить нервную систему модераторов конкурса 😃

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

Привет, Хабр!

На связи Андрей из сообщества ITMO.OpenSource. Мы считаем, что важно делать открытую науку, поэтому пишем об открытом коде, проводим митапы «Scientific Open Source» и разрабатываем научные решения с открытым кодом.

Мы убеждены, что открытая наука – это не просто код на github, но и совокупность факторов, которые позволяют этим кодом эффективно воспользоваться: запустить, модифицировать, внедрить в другие проекты. Поэтому я решил перевести популярную статью JS-разработчицы Киры Окли «Art of README». Несмотря на разницу в экосистемах (я пишу преимущественно на Python), мне кажется, многие идеи этой статьи актуальны для любого проекта на любом языке.

Вы тоже устали вручную заполнять Dockerfile и docker-compose.yaml под каждый новый проект?

Я всегда задумывался, применяю ли я известные best practices, когда пишу конфиг для Docker, и не занесу ли я случайно какие-нибудь уязвимости, вручную заполняя конфиг-файлы.

Что же, теперь мне больше не придется беспокоиться об этом, благодаря добрым людям из Docker, которые недавно реализовали инструмент для этого - docker init .

Интересно, как экономить время и быстро генерировать конфиги, даже если вы не профи в Docker? Прошу под кат.

Привет, Хабр!

Это исследователи из NSS Lab ИТМО и создатели сообщества ITMO.OpenSource. Мы считаем, что важно делать не просто науку, а открытую науку, результатами которой можно легко воспользоваться. Поэтому пишем об открытом коде, проводим митапы «Scientific Open Source» и разрабатываем научные решения с открытым кодом. Эта статья написана на материале исследования, которое мы презентовали на последнем митапе. В ней поговорим об открытом научном коде, посмотрим, как с ним обстоят дела в разных организациях, и поделимся подборкой репозиториев, которые могут решать различные научные задачи.