Что общего у разработчика, открывшего сайт интересной конференции, и ребёнка в магазине сладостей? Когда они смотрят и понимают «хочу!», зачастую не сами достают деньги из кармана, а обращаются для покупки к кому-то другому (разработчик — к работодателю, ребёнок — к родителю).

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

Представим ситуацию с двумя выдуманными персонажами из маленькой компании. Женя приходит к начальству в лице Саши, говорит «хочу на конференцию» и получает ответ: «То есть предлагаешь нам заплатить за то, чтобы оторвать тебя от работы? Зачем это нам?»

Значит, Жене нужно суметь обосновать, в чём тут выгода для работодателя. Кстати, а и правда, в чём? Она вообще есть, или Женя просто хочет на халяву поразвлекаться? Давайте разберёмся.

Привет, меня зовут Кирилл и я инженер, который превозмогал ковидные времена вместе с компанией JUG Ru Group. Мы делаем технические конференции, и в пандемию сделали собственный сайт для проведения онлайн-конференций. Тогда нам понадобились качественные видеозвонки на WebRTC, чтобы подключать через браузер спикеров из любой точки планеты.

Варианты «просто застримить Zoom или захватить Jitsi» нам не подошли. Стало ясно, что нужно делать своё решение, пусть и на основе чужого SDK. В результате перебрали разные варианты, накопили опыт. А ещё из-за вопросов вроде этого создали целую конференцию VideoTech, чтобы послушать других знающих людей.

И теперь хочу поделиться нашим опытом с Хабром, поговорив про WebRTC в целом и про конкретные реализации: P2P, Voximplant SDK, SDK VK Звонков.

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

В июне я выступил с докладом об этом на конференции Mobius, а теперь для аудитории Хабра публикую его текстовую версию. Если есть что добавить — пишите в комментариях!

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

Одни художники восхищаются открывшимися возможностями, другие недовольны, а общество в целом пока вроде бы не курсе той стремительно развивающейся технологической революции, которая происходит в сообществах на Twitter, Discord и GitHub. Возможно, синтез изображений приносит настолько же большие возможности, как изобретение камеры — или даже создание самого визуального искусства. Даже наше восприятие истории под вопросом, в зависимости от того, как всё утрясётся. В любом случае Stable Diffusion возглавляет новую волну творческих инструментов, основанных на глубоком обучении, которые намерены революционизировать создание визуального медиаконтента.

На Хабре уже описывали историю создания Python. Но мы решили не просто пересказать события ещё раз, а увидеть их глазами Гвидо ван Россума: что он сам думал об этом всём? Мы порылись в архивных текстах и нашли ранние высказывания, которые помогают лучше понять, почему Python стал именно таким и что определило его популярность.

Все началось с того, что в декабре 1989 года голландец Гвидо (Guido van Rossum) — будущий создатель одного из самых популярных языков программирования — искал хобби-проект, которому можно было бы посвятить рождественские каникулы… Сам Гвидо вспоминал это время так:

Зачастую JavaScript ассоциируют с формочками в браузере, а C++ с железом и суровыми оптимизациями. Но что, если не противопоставлять «формочки» и «железо», а объединить?

На недавней конференции HolyJS Никита Дубко показал, как с помощью WebHIDf можно подключаться из браузера к самым разным пользовательским устройствам. Вероятно, для «железячников» многое сказанное в докладе очевидно — зато для JS-разработчиков это, наоборот, возможность узнать что-то совершенно новое. Доклад понравился участникам, и теперь мы сделали для Хабра текстовую версию. Далее повествование идёт от лица спикера.

Для мира Unix эта новость — что-то в духе «появился Моисей и анонсировал дополнение к десяти заповедям».

AWK, язык программирования для анализа текстовых файлов, является ключевой частью Unix-систем — включая Linux, BSD и другие. Для того, чтобы OS могла считаться POSIX-совместимой, она обязана включать AWK. Впервые AWK появился в 1977-м и был включен в Version 7 UNIX в 1979-м — в последней версии UNIX от Bell Labs перед тем, как AT&T превратили его в коммерческий продукт.

В том, что он получает поддержку Unicode, заметнее даже не сама фича, а кто занялся её реализацией: канадский информатик Брайан Керниган.

Название AWK — аббревиатура, образованная по фамилиям трёх его создателей: Альфреда Ахо (обладателя премии Тьюринга), Питера Вейнбергера и Брайана Кернигана. Также Керниган — это буква «K» в названии «K&R C»: классической книге 1978 года «The C Programming Language», написанной Керниганом и великим Деннисом Ритчи.

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

Когда мы говорим «беспилотные автомобили», то, как правило, представляем стильные Tesla или футуристические Waymo. Кажется, что беспилотные машины — это недавняя технологическая разработка. Но исследования в этой области начались более 30 лет назад. Ученые из университета Карнеги — Меллона впервые попробовали силы в этом еще в 1984 году, когда начали работу над проектом Navlab 1. 

С 1984 года было создано 11 поколений автомобилей NavLab и подано более 140 заявок на патенты. Инженеры, работавшие над проектом, впоследствии перешли в Google (например, Себастьян Трун, Дж. О. Урмсон, Астро Теллер) или другие компании и внесли свой вклад в разработку беспилотных автомобилей.

В этой статье расскажем про незаслуженно обойденный вниманием проект Navlab и познакомимся с синим фургоном «Шеви».

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

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

Участники:
Роман Голофаев, Почтатех
Екатерина Батеева, Авито
Александр Сычев, СберЗдоровье
Александр Гузенко, Тинькофф
Павел Стрельченко, HeadHunter
Дмитрий Алиев, Райффайзен Банк

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

Но вообще-то тут есть о чём поговорить помимо этих спекуляций, причём разговор может быть куда предметнее. Как все эти разнообразные «copilot» вообще работают (вот сейчас, а не через десять лет)? Какие сложности возникают при их создании? Где эти сложности можно преодолеть, а где есть принципиальные ограничения формата?

На конференции Joker об этом рассказывали Никита Поваров allfather и Роман Поборчий p0b0rchy. На момент доклада оба работали в JetBrains, так что получилось не просто абстрактное описание вопроса, а «взгляд изнутри» со стороны тех, кто делает инструменты для разработчиков.

• Славное прошлое
• Фантастическое настоящее
• Счастливое будущее

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

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

На нескольких примерах покажем, как это происходит.

От редакторов: название «сага» для паттерна долгоживущих транзакций так прижилось, что уже есть даже в Википедии. А как возникли этот паттерн и его название? Благодаря работе 1987 года. Похоже, что она до сих пор никем не была переведена на русский, и теперь мы решили это исправить.

Долгоживущие транзакции (long-lived transactions, LLT) блокируют ресурсы баз данных в течение длительных промежутков времени и существенно замедляют выполнение более коротких и многочисленных транзакций. Чтобы решить эту проблему, мы предлагаем ввести понятие саги. LLT является сагой, если она может быть записана как последовательность транзакций, которые можно чередовать с другими транзакциями. При этом система управления базой данных должна гарантировать, что либо успешно выполняются все транзакции саги, либо выполняются компенсирующие транзакции, корректирующие частичное выполнение. И само понятие саги, и его реализация относительно просты, но с помощью них можно существенно повысить производительность. В этой работе мы анализируем различные вопросы реализации саг, в том числе запуск саг на системах, не поддерживающих их напрямую. Мы также обсуждаем приемы проектирования баз данных и LLT.

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

— Первая пара дней проходит в онлайне, спикеры выступают удалённо. А позже ещё один день происходит старый добрый офлайн на конференционной площадке.

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

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

Ничто не бодрит с утра лучше, чем большая техническая конференция по JavaScript. Восьмого июня в 11:40 стартовала онлайн-часть HolyJS. Получилось огненно (во всех смыслах), весело и познавательно. И тяжелое утро с HolyJS вышло совсем не тяжелым.

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

Сейчас мы готовимся к офлайн-дню 23 июня (и ещё не поздно решить поучаствовать в нём). А пока что поделимся ссылками на видеозаписи Community Day, расскажем о некоторых ярких докладах онлайн-части и озвучим дальнейшие планы.

В этом году Java-конференция получилась двухсоставной: онлайн-часть уже прошла, а вот офлайн-день ещё предстоит 24 июня в Санкт-Петербурге (и ещё не поздно решить в нём поучаствовать).

Причём несколько видеозаписей уже доступны всем желающим. Поэтому хотим этим текстом поймать трёх зайцев сразу:

— Порадовать Хабр этими Java-докладами без регистрации и смс 
— Написать, что ещё было в онлайновой части
— И рассказать, что будет в офлайне

В этом сезоне Heisenbug состоит из двух частей: уже привычный онлайн и давно желанный офлайн. Онлайн-часть сейчас позади, и видеозаписи некоторых её докладов мы уже открыли для всех — в этом посте делимся ими с Хабром.

А до офлайна остались считанные дни (21 июня в Санкт-Петербурге), и сейчас ещё не поздно решиться в нём поучаствовать.

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

В этот раз у DotNext непривычный формат: сначала два дня в онлайне, а позже офлайн-день в Петербурге (первая за два года возможность встретиться на DotNext очно!) Для тех, кто не может добраться до Питера, у последнего дня будет и интернет-трансляция.

С программой принципиальных изменений нет: она по-прежнему о всём том, что может быть интересно .NET-разработчикам. Новые тенденции, архитектурные подходы, производительность, best practices — а ещё нестандартные темы, позволяющие расширить кругозор. Однако отличия от прошлых лет есть и здесь.

Какие именно доклады будут? Под катом — и их описания, и мнения нескольких участников программного комитета.

Чем хороший специалист в разработке ПО отличается от плохого, что для него свойственно? Ответ во многом зависит от этапа его развития: для начинающих важны одни вещи, по мере получения опыта — совсем другие. Я попробовал собрать в одном материале свои соображения о разных этапах становления специалиста. Давайте выясним аспекты, формирующие человека, про которого потом можно уверенно сказать — вот «хороший специалист». Осторожно, под катом много картинок для лучшего ассоциативного запоминания.