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

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

Поделюсь своей историей о том, какой путь прошёл и что нового узнал.

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

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

Уже сто пятьдесят лет никто не решается массово заредизайнить клавуа, у Эпл последняя выглядит вот так. Давайте немного подвигаем кнопки и посмотрим как можно сделать лучше.

Я Android-разработчик и хотел бы сам решать, какие задачи мне делать, а какие нет. У вас бывало такое желание? Можно ли так делать на работе? Мой краткий и возможно, интригующий ответ — можно. Ключ к этому — погружение в бизнес.

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

Всем привет! Недавно я написал Discord бота для World of Warcraft гильдии. Он регулярно забирает данные об игроках с серверов игры и пишет сообщения в Discord о том что к гильдии присоединился новый игрок или о том что гильдию покинул старый игрок. Между собой мы прозвали этого бота Батрак.

В этой статье я решил поделиться опытом и рассказать как сделать такой проект. По сути мы будем реализовывать микросервис на .NET Core: напишем логику, проведем интеграцию с api сторонних сервисов, покроем тестами, упакуем в Docker и разместим в Heroku. Кроме этого я покажу как реализовать continuous integration с помощью Github Actions.

От вас не потребуется никаких знаний об игре. Я написал материал так чтобы можно было абстрагироваться от игры и сделал заглушку для данных об игроках. Но если у вас есть учетная запись в Battle.net, то вы сможете получать реальные данные.

8 июня 2009 года Фил Шиллер выступил на WWDC. Всего 36 секунд он неловко говорил о VoiceOver, Zoom, White on Black (с  iOS 6 называется Invert Colors) и Mono Audio. Это были первые реальные специальные функции на платформе iPhone OS, как её тогда называли. Однако, они не произвели большого впечатления — 36 секунд закончились, а потом не было никакой демонстрации или аплодисментов, и Шиллер просто перешел к описанию приложения Nike+.

Но в сообществе людей с проблемами зрения всё было иначе. Казалось, что время остановилось где-то после 1:51:54. Произошло нечто совершенно удивительное, и только несколько человек, казалось, понимали, что это значит.

В какой-то момент у нас стало много хотфиксов — стабильно больше половины деплоев на проде были хотфиксы или откаты. Мы решили анализировать каждый хотфикс, чтобы понять причины, найти системные закономерности и устранить их, не допуская два раза одних и тех же ошибок. Как говорил Джейсон Стейтем (Стэтхэм? Стэтэм?): «Не страшно ошибаться, страшно повторять одну ошибку 2 раза». Ну и мы решили не повторяться и внедрить постмортемы. В статье расскажу как мы анализируем хотфиксы и другие критичные проблемы, что у нас получается, а что нет, с какими сложностями столкнулись и как их решали.

Когда я смотрю фантастические фильмы или ролики о том, какие гаджеты и техника нас будет окружать через 10-20-30 лет, то чаще всего вижу разные прозрачные экраны, голограммы или проекции на руку, лоб или пупок. Чтобы всем этим управлять нужен всего-то один палец. Всё выглядит красиво и фантастично. Но что, если я скажу вам, что подобные концепции, возможно, ложные?

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

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

Почти нет примеров когда некитайская продуктовая компания вышла в WeChat с собственной мини-программой, да ещё с in-house разработкой вне Китая. Поэтому мы  познавали все нюансы разработки самостоятельно, от устройства китайской цифровой экосистемы и мини-приложений в WeChat, до вывода продукта на китайский рынок. Об этом и расскажем в этом большом «разборе» китайских приложений.

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

В начале 2019 мы собрали аналитику по адресам в заказах и увидели, что бо́льшая часть клиентов заказывает доставку на одни и те же адреса и не устанавливают отложенное время. Они хотят получить заказ «туда же, куда и в прошлый раз и как можно быстрее». Но сделать это не так просто. Поэтому мы решили поменять флоу оплаты заказа и максимально его упростить именно для таких клиентов. Мы назвали этот проект Бриллиантовый чекаут™ и планировали сделать за 2 месяца. А закончили через 9.

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

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

Мы тоже использовали Realm — 3 года подряд. Сначала он помогал, потом раздражал, пару раз выстрелил и в конце чуть не вогнал команду в депрессию. В итоге мы удалили Realm из проекта. Это сложный инструмент — простота интеграции обманчива, а за все удобства придётся расплачиваться.

Если бы сбылись предсказания футурологов и фантастов «космической эры», вроде Кларка или Азимова, мы бы жили в совсем другом мире. Базы на Луне и колонии на Марсе, к которым мы летим на ракетах с фотонными двигателями, антропоморфные роботы-помощники, подземные города, освоенная Арктика и вечная весна — вот будущее, что мы «потеряли». Но потеряли ли? Могло ли вообще сбыться это «будущее»? 

В Domain-Driven Design выделяют стратегические и тактические паттерны. Например, первые — это Единый язык, а вторые — Агрегаты. Я много раз слышал от коллег, что со стратегией всё понятно, но когда дело доходит до перехода на тактический уровень (до кода) — всё в тумане. Это приводит к некорректным техническим решениям, которые не могут компенсировать даже правильный настрой и близость к бизнесу. Для успеха проекта крайне важно освоить тактические паттерны, особенно Агрегаты. Всё потому, что Агрегаты инкапсулируют в себя почти всю бизнес-логику, это основа вашего приложения. В этой статье я и расскажу про Агрегаты, как они могут помочь и почему важно их освоить. Но...

Когда говорят «Open Source», обычно первые ассоциации — это Ричард Столлман и Линус Торвальдс. Но Open Source начался не с них, а зародился в 50-х, когда учёные и инженеры писали ПО и безвозмездно обменивались результатами своего труда. Мы попробовали разобраться в истории Open Source, какие события способствовали его развитию и почему без Open Source IT не был бы таким, какой он есть: программы для «Оборонного калькулятора», коммерциализация UNIX, письмо Билла Гейтса, манифест GNU, Linux и миллиардные сделки покупок Open Source компаний.