Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.

Я большая поклонница современной веб-разработки, хотя она мне напоминает некую «магию», со своими плюсами и минусами:

• Когда вы поймёте, как использовать волшебные инструменты (babel! бандлеры! вотчеры! и так далее!), ваш рабочий процесс становится быстрым, мощным и восхитительным
  
• Если вы не понимаете волшебные инструменты, всё ужасно запутанно
  
• …и попытки освоить магию слишком часто неудачны, если вам кто-нибудь не поможет продраться через джунгли жаргона, преувеличений и устаревшей информации в интернете

How to deploy Python Telegram bot using Webhooks on Google Cloud Platform

Вместо предисловия

— Напиши телеграм-бота. Сейчас даже школьники пишут, — сказала она.
— А почему бы и нет, — подумал я тогда ( — Ну, ну, — сказал бы я сейчас).

Мы сидели в Бине и за чашкой кофе обсуждали возможности тестирования идей с моделями искусственного интеллекта на близком и не очень круге друзей. Лена, моя бывшая коллега, и во всех отношениях не блондинка, только что закончившая магистратуру, рассуждала так. Создав бота, можно сэкономить силы и время на интерфейсе, сосредоточившись на ядре с машинным обучением. Согласитесь, что устоять против такой логики “спортсменки, комсомолки и просто красавицы” в то прекрасное воскресное утро было невозможно. Решено. Телеграм-бот, значит телеграм-бот.

Первым делом я залез в гугл и нашел большое число ссылок “как сделать бот за 30 минут”. Это меня настолько воодушевило, что дальше названий я не пошел и занялся созданием ядра. В самом первом приближении мне предстояло написать систему обработки поисковых запросов с использованием NLP (natural language processing). Написание ядра заняло некоторое, вполне разумное, время (все же опыт кока-колой не пропить). И через несколько дней я был готов к тому, чтобы за пару часов обернуть первую тестовую версию ядра в пару другую команд send-receive, запустив все это в Телеграме на благо моим друзьям. Но не тут-то было.

Неожиданно возник целый клубок проблем. Потратив пару дней на поиски в интернете и общение с коллегами по цеху, я понял, что очевидное не очевидно, и еще одна “инструкция” точно не повредит. Так и появилась эта статья.

Экосистема вокруг Google Ассистента развивается очень быстро. В апреле 2017 года пользователям были доступны всего 165 экшенов, а сегодня только на английском их – более 4500. Насколько разнообразным и интересным станет русскоязычный уголок этой вселенной, зависит от разработчиков. Дмитрий Чечёткин, руководитель стратегических проектов Just AI и автор «Да, милорд», одной из самых популярных игр для Ассистента не только в России, но и в мире (в нее сыграли уже больше 240 тысяч человек), делится важными лайфхаками по созданию экшенов для Google Ассистента. Зачем отделять код и контент от сценария? О чем нужно помнить, работая над разговорным интерфейсом? В общем, разбираемся, как запилить экшен мечты.

Взболтать, но не смешивать: роль сценария, контента и кода

В коде самых разных проектов нередко приходится оперировать временем — например, чтобы завязать логику работы приложения на текущее время у пользователя. Старший разработчик интерфейсов Виктор Хомяков victor-homyakov описал типичные ошибки, которые встречались ему в проектах на языках Java, C# и JavaScript от разных авторов. Перед ними вставали одни и те же задачи: получить текущую дату и время, измерить интервалы или выполнить код асинхронно.



— До Яндекса я работал в других продуктовых компаниях. Это не как фрилансер — написал, сдал и забыл. Приходится очень долго работать с одной кодовой базой. И я, собственно, смотрел, читал, писал много кода на разных языках и увидел много чего интересного. В итоге у меня родилась тема этого рассказа.

Скорее всего, вам известны следующие соотношения еще со школы:

$$

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

Полтора года назад, читая работы про уязвимости Meltdown и Spectre, я поймал себя на том, что не очень понимаю разницу между сокращениями i.e. и e.g. Т.е. по контексту вроде бы понятно, но потом вроде бы как-то и не совсем то. В результате я тогда сделал себе небольшую шпаргалку именно по этим сокращениям, чтобы не путаться. И тогда же появилась идея этой статьи.

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

История проекта Linux и ее лидера Линуса Торвальдса часто приводят в пример принципа меритократии в разработке программного обеспечения. Тем не менее было бы верхом наивности утверждать, что успех обеспечен исключительно усилиями энтузиастов, без всякого участия крупных корпораций, совершенно далеких от всякого альтруизма.

Майкрософт и Linux.

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

Первоначальная диспозиция

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

Предисловие

Из далекого 2012, на просторах Хабра мне запомнился коммент:

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

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

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

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

В 1985 году Институт инженеров электротехники и электроники (IEEE) установил стандарт IEEE 754, отвечающий за форматы чисел с плавающей запятой и арифметики, которому суждено будет стать образцом для всего железа и ПО на следующие 30 лет.

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

Вступление

Мне кажется, что нам надо использовать меньше тригонометрии в компьютерной графике. Хорошее понимание проекций, отражений и векторных операций (как в истинном значении скалярного (dot) и векторного (cross) произведений векторов) обычно приходит с растущим чувством беспокойства при использовании тригонометрии. Точнее, я считаю, что тригонометрия хороша для ввода данных в алгоритм (для понятия углов это интуитивно понятный способ измерения ориентации), я чувствую, что что-то не так, когда вижу тригонометрию, находящуюся в глубинах какого-нибудь алгоритма 3D-рендеринга. На самом деле, я думаю, что где-то умирает котенок, когда туда закрадывается тригонометрия. И я не так беспокоюсь о скорости или точности, но с концептуальной элегантностью я считаю… Сейчас объясню.

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

С другой стороны, элементы функционального стиля программирования уже проникли в промышленные языки программирования, такие как Swift и Kotlin. Разработчики этих языков прекрасно знакомы с функциональным программированием, поэтому смогли применить его «в малом», предусмотрев многие, хотя и не все, необходимые компоненты. Чем дальше — тем больше части ФП внедряются в промышленные ЯП, и тем качественнее и полнее реализуется поддержка.

Уметь программировать в функциональном стиле полезно, чтобы упрощать себе работу, и сейчас мы посмотрим, как этим воспользоваться!


Виталий Брагилевский — преподаватель ФП, теории алгоритмов и вычислений, автор книги «Haskell in Depth» и участник комитетов Haskell 2020 и наблюдательного комитета компилятора GHC.

Каждый Android-разработчик использовал RecyclerView для отображения списков и каждый сталкивался с проблемой обновления данных в списке, пока в 2016 году не появился магический класс DiffUtil. Я на пальцах объясню, как на самом деле он работает, и постараюсь рассеять его магию.

Отображение текстовой информации — наверное, самая базовая и важная часть многих Android-приложений. В данной статье пойдет речь о TextView. Каждый разработчик, начиная с «Hello World», постоянно сталкивается с этим элементом пользовательского интерфейса. Периодически в работе с текстом приходится задумываться о реализации различных дизайнерских решений или улучшении производительности при отрисовке экрана.

Я расскажу об устройстве TextView и некоторых тонкостях работы с ним. Основные советы были взяты из докладов прошедших Google I/O.

Всё больше и больше проектов и команд используют TypeScript. Однако просто применять TypeScript и выжимать из него максимум пользы — это очень разные вещи.

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

Работа, опубликованная в Nature Medicine учёными из National Cancer Institute (NCI), описывает новый тип иммунотерапии, который привёл к полному исчезновению опухолей у женщины с метастатическим раком молочной железы, которой осталось всего несколько месяцев жизни.

Результаты показывают, как естественные опухолевые инфильтрирующие лимфоциты (TIL) были извлечены из опухоли пациента, выращены вне её тела, чтобы увеличить их количество, и введены обратно пациенту для борьбы с раком. Пациент ранее получил несколько форм лечения, включая гормональную терапию и химиотерапию, но никакая из них не остановила прогрессирование рака. После лечения все опухоли пациентки исчезли, и через 22 месяца она все ещё находится в ремиссии.

Эта статья — краткое руководство для тех, кто хочет запустить свой собственный подкаст. Когда я вместе с моим нынешним соведущим год назад запускал подкаст “В бесконечность и далее”, я не смог найти ни одной по-настоящему всеобъемлющей статьи. Поэтому я решил попытаться заполнить этот пробел и написать руководство для себя из прошлого.

Немного о структуре — это руководство содержит 4 статьи:

1. Общая философия
   1.1. Зачем делать подкаст?
   1.2. Целевая аудитория
   1.3. Выбор жанра
   1.4. Формат
2. Технический базис
   2.1. Что такое подкаст с технической точки зрения
   2.2. Аудио-формат
   2.3. Про динамики, наушники и ламповый звук
   2.4. Про тихое помещение
3. Делаем покупки
   3.1. Покупаем микрофон
   3.2. Выбираем аудиоредактор
   3.3. Выбираем программу для записи звука
   3.4. Выбираем хостинг подкаста
   3.5. Сайт-визитка
4. Записываем и выпускаем
   4.1. Запись выпуска
   4.2. Редактирование выпуска
   4.3. Про джинглы и звуковые схемы
   4.4. Про фоновый шум
   4.5. Про фильтры
   4.6. Про Show Notes, а также про то, зачем слушать свой подкаст
   4.7. Публикация подкаста
   4.8. Монетизация
   4.9. Темы, которые есть, но о которых мы не говорили

Каждый раздел статьи содержит три блока

• Суть раздела — основная мысль, изложенная тезисно
• Детальное описание “что, зачем и почему”. Обычно — много букв, которые поясняют основную мысль, и находятся они в скрытой секции “Дополнительная информация”
• Ответ, который нашли мы

Интересно — читайте все. Нет времени — читайте первый и последний абзац.

1. Общая философия

1.1. Зачем делать подкаст?

Ответ может быть любым, но только не “потом посмотрим”, ”ещё не думал” или “не знаю”. Если ответа нет, весьма высока вероятность что

Введение

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

С этой целью попробуем изготовить на основе контроллера ATmega8 устройство, прикидывающееся USB-HID'ом. В отличие от распространенной литературы, мы пойдем не от теории к практике, от самого нижнего уровня к верхнему, от логических напряжений на выводах, и закончим «изобретением» той самой vusb, после каждого шага проверяя, работает ли код как ожидалось. Отдельно отмечу, что не изобретаю альтернативу этой библиотеке, а напротив, последовательно воспроизвожу ее исходный код, максимально сохраняя оригинальную структуру и названия, поясняя, для чего служит тот или иной участок. Впрочем, привычный для меня стиль написания кода отличается от стиля авторов vusb. Сразу же честно признаюсь, что помимо альтруистического интереса (рассказать другим сложную тему) имею и корыстный — изучить тему самостоятельно и через объяснение выловить для себя максимум тонких моментов. Отсюда же следует, что какой-то важный момент может быть упущен, или какая-то тема не до конца раскрыта.

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

Также отмечу, что рассматривается только low-speed USB, даже без упоминания, чем отличаются более скоростные разновидности.

Рождение концепции Remote Reality

История нашего «безумного» проекта началась три года назад, когда размышляя о будущих перспективах развития игровой индустрии, мой друг Леша сказал: «Представь себе будущее, в котором люди в виде развлечения, из любой части мира управляют на игровом полигоне настоящими роботами, как «аватарами»».

Идея изначально показалась нам достаточно интересной и не сложной в реализации. Мы тут же «засели» за поиски похожих проектов и с удивлением обнаружили, что никто, ничего подобного не делал. Это казалось странным, ведь идея лежала буквально «на поверхности». Мы нашли множество следов любительских проектов создания прототипов в виде шасси с камерой на основе Arduino, но никто так и не довел ни один проект до логического завершения. Позднее, преодолевая казалось бесконечные трудности и проблемы, мы поняли причину отсутствия аналогов, но изначально идея нам казалось крайне простой и быстро реализуемой.

Следующую неделю мы посвятили проработке концепции. Мы представляли себе десятки разновидностей роботов с разными возможностями и сотни игровых полигонов, между которыми игроки могут мгновенно перемещаться через «телепорт». Любой желающий, на основе нашего «решения», имел возможность построить свой собственный игровой полигон самого разного масштаба.

Мы сразу решили, что эти мысли укладываются больше в концепцию развлекательного аттракциона, а не компьютерной игры. Люди любят развлечения и хотят чего-то нового, и мы знали, что им предложить. Как и в любом бизнесе, сразу всплыл вопрос окупаемости, ведь на первый взгляд кажется, что наша физическая модель ограничена количеством роботов. Но умножив роботов на 24 часа и на цену часа в 5-10 долларов, сомнения отпали. Финансовая модель не являлось «Клондайком», но вполне окупалась даже при 10% загрузке.

Очень быстро у нас в голове появилось название новой концепции: Remote Reality, по аналогии с Virtual Reality и Augmented Reality.

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

RxJava используется в большом количестве android-приложений, но при этом многие не знают других источников событий, кроме Observable и, может быть, Flowable. Они забывают о специализированных классах Single, Maybe и Completable, которые зачастую способны добавить больше ясности в код.

Под катом вас ждёт шпаргалка по источникам событий, которые существуют в RxJava.