Добрый день, друзья. Сегодня мы подготовили для вас перевод первой части статьи «Лямбды: от C++11 до C++20». Публикация данного материала приурочена к запуску курса «Разработчик C++», который стартует уже завтра.

Лямбда-выражения являются одним из наиболее мощных дополнений в C++11 и продолжают развиваться с каждым новым стандартом языка. В этой статье мы пройдемся по их истории и посмотрим на эволюцию этой важной части современного C++.



Вторая часть доступна по ссылке:
Lambdas: From C++11 to C++20, Part 2

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

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

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

Недавно мы перезапустили API Яндекс.Кассы – платежного сервиса с 15-летней историей. Я хочу рассказать, как решить такую амбициозную задачу. Материала набралось на серию статей, поэтому здесь я подробно расскажу о проектировании, переработке наших API, а также про наши инструменты и процессы.

Ключевые слова для оценки полезности: API, REST, OpenAPI, Swagger, рефакторинг взаимодействия систем.

В этой статье я не буду описывать преимущества и недостатки механических клавиатур. Одной единственной идеальной клавиатуры для всех не существует. Многие считают вершиной развития «островные» клавиатуры с ножничным механизмом, кто-то может комфортно печатать лишь на Topre, другие запаслись парой-тройкой IBM Model M на всю оставшуюся жизнь. Вокруг переключателей Cherry MX и их клонов диапазон предпочтений тоже весьма широк — одним подавай лёгкие линейные переключатели, другим нужны жёсткие MX Green с кликом. Речь пойдёт о компактной разновидности, так называемых «шестидесятипроцентных клавиатурах».

Это вторая часть статьи о создании инструмента, способного экспортировать все помещённые в Sketch-файл иконки: в разных форматах, для разных платформ, с возможностью A/B-тестирования каждой из иконок.

Первую часть вы можете прочесть по ссылке.



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

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

Для тех, кто администрирует серверы и/или веб-проекты остро стоит вопрос информированности о том, что же происходит с их «подопечными». На рынке существует масса решений об оповещении о сбоях, состоянии соединения и прочих параметрах, в том числе и с помощью СМС. Речь о MRTG, Twilio, F-Droid, сервисах Google и многих-многих других. Вот только проблема в том, что большинство из этих решений весьма узко специализированы, а повлиять на их функции не представляется возможным. MRTG отдаст информацию о трафике и соединении, Google пришлет СМС. Кое-какую свободу дает Twilio в плане написания скриптов на JavaScript под свои нужды, но простите, это же коммерческий проект. То есть «давай, плати бабло или проваливай».

Так вот, в этом семействе инструментов у нас есть open source пополнение: Gotify — простой клиент-серверный проект для получения и отправки пуш-уведомлений и команд, в том числе и через Android-приложение. И о нем определенно стоит рассказать чуть подробнее, думаю, это пригодится для тех, кто искал нечто похожее и при этом бесплатное, но в итоге завел собственный pet-project. Вполне возможно, эта публикация сэкономит пару сотен часов вашего времени.

Всем привет.

Некоторое время назад мы писали о том как нам удалось запустить SIP телефон на STM32F4-Discovery c 1 Мб ROM и 192 Кб RAM) на базе Embox. Тут надо сказать, что та версия была минимальной и соединяла два телефона напрямую без сервера и с передачей голоса лишь в одну сторону. Поэтому мы решили запустить более полноценный телефон со звонком через сервер, передачей голоса в обе стороны, но при этом уложиться в как можно меньший размер памяти.

Нередко при отладке ПО микроконтроллера возникает необходимость вывода отладочных сообщений, логов, захваченных данных и прочего на экран ПК. При этом хочется, чтобы и вывод был побыстрее, и чтобы строки отображались не где-нибудь, а прямо в IDE — не отходя от кода, так сказать. Собственно, об этом и статья — как я пытался printf() выводить и отображать внутри любимой, но не очень микроконтроллерной, среды Qt Creator.

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


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

В этой статье я расскажу о собственных изысканиях на эту тему. Поскольку я программирую в основном под STM32 и под Миландр 1986 — на них я и фокусировался.

«С опытом приходит стандартный, научный подход к вычислению правильного размера стека: взять случайное число и надеяться на лучшее»
— Jack Ganssle, «The Art of Designing Embedded Systems»

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

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

Отчасти это объясняется простотой учебных проектов, выполняемых при этом на отладочных платах с относительно жирными микроконтроллерами, на которых влететь в нехватку памяти, мигая светодиодом, довольно сложно — однако в последнее время даже у начинающих любителей мне всё чаще встречаются упоминания, например, контроллеров типа STM32F030F4P6, простых в монтаже, стоящих копейки, но и памяти имеющих единицы килобайт.

Такие контроллеры позволяют делать вполне себе серьёзные штуки (ну вот у нас, например, такая вполне себе годная измериловка сделана на STM32F042K6T6 с 6 КБ ОЗУ, от которых свободными остаются чуть больше 100 байт), но при обращении с памятью при работе с ними нужна определённая аккуратность.

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

Приветствую хабравчане. Хочу рассказать о том, как мы прикручивали Google Analytics к телеграмм-боту, с какими столкнулись проблемами, и что в итоге пока не получилось настроить.

По старинке Google Analytics устанавливается на сайт с доменом или в приложение с SDK. Погуглив тему, стало понятно, что примеров нет, поэтому решили сделать сами. В нашем случае не было сайта или мобильного приложения, но было желание отслеживать события в Телеграм боте. И частично это получилось сделать.

Проблема №1

Боты физически находятся по адресу t.me/benice_tools_bot. Это похоже на обычный сайт, но без прямого доступа к корневым файлам, для установки кода счетчика, и настройки событий.
Фронтенд в этом случает является сам Телеграм, к которому у нас нет доступа.

Наш бот работает с API Binance и API Телеграма, и соответственно есть бекэнд, через который стало возможно маневрировать c настройками аналитики.

На улице я часто слушаю аудиокниги и подкасты со смартфона. Когда прихожу домой, мне хочется продолжить слушать их на Android TV или Google Home. Но далеко не все приложения поддерживают Chromecast. А было бы удобно.

По статистике Google за последние 3 года, количество девайсов на Android TV увеличилось в 4 раза, а число партнеров-производителей уже превысило сотню: «умные» телевизоры, колонки, TV-приставки. Все они поддерживают Chromecast. Но в маркете ещё много приложений, которым явно не хватает интеграции с ним.

В этой статье я хочу поделиться своим опытом интеграции Chromecast в Android-приложение для воспроизведения медиа-контента.

Статья посвящена лучшим практикам написания кода Go. Она составлен в стиле презентации, но без обычных слайдов. Постараемся кратко и чётко пройтись по каждому пункту.

Для начала следует договориться, что значит лучшие практики для языка программирования. Здесь можно вспомнить слова Расса Кокса, технического руководителя Go:

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

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

Добрый день, друзья! Уже в этот четверг мы запускаем новый поток по курсу «Руководитель разработки». И сегодня хотим поделиться с вами транскрипцией открытого вебинара, который прошел на прошлой неделе.

Открытый вебинар «Работа: своя и чужая»

С одной стороны, фраза «это не моя работа» звучит отталкивающе: как-то не проактивно и некомандно. С другой стороны, всю работу сделать невозможно. То есть делать «не свою» работу — это равносильно НЕ делать свою работу! А это уже чревато…

Так как же отделить свою работу от не своей? Что считать своей работой? Что делать с не своей работой, если всё равно нас интересует конечный результат? Обо всём этом и многом другом мы поговорили на очередном открытом уроке курса «Руководитель разработки».



Преподаватель — Станислав Михальский, директор по разработке в компании «Биглион Технологии».

Работа и уровни деятельности

Формальное определение работы звучит так: «Работа — это деятельность человека, направленная на создание ценностей либо на удовлетворение потребностей других людей». Ключевое слово здесь — деятельность. Во-первых, любая деятельность предполагает наличие ресурсов (в нашем случае это время). Во-вторых, деятельность должна приводить к конечному результату. И эти два момента (ресурсы и конечный результат) всегда нужно строго контролировать.

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

Реверс-инжиниринг микросхем — головная боль производителей с самых первых лет существования микроэлектроники. Вся советская электроника в какой-то момент была построена на нем, а сейчас с гораздо большим размахом тем же самым занимаются в Поднебесной, да и не только в ней. На самом деле, реверс-инжиниринг абсолютно легален в США, Евросоюзе и многих других местах, с целью (цитирую американский закон) “teaching, analyzing, or evaluating the concepts or techniques embodied in the mask work or circuitry”.

Самое частое легальное применение реверс-инжиниринга — патентные и лицензионные суды. Промышленный шпионаж тоже распространен, особенно с учетом того, что электрические схемы (особенно аналоговые) часто являются ключевой интеллектуальной собственностью и редко патентуются — как раз для того, чтобы избежать раскрытия IP и участия в патентных судах в качестве обвиняющей стороны. Разумеется, оказавшись в ситуации, когда нужно защитить свою интеллектуальную собственность, не патентуя ее, разработчики и производители стараются придумать способы предотвращения копирования своих разработок.

Другое не менее (а то и более) важное направление защиты микросхем от реверс-инжиниринга — обеспечение безопасности информации, хранимой в памяти. Такой информацией может быть как прошивка ПЛИС (то есть опять-таки интеллектуальная собственность разработчика), так и, например, пин-код от банковской карты или ключ шифрования защищенной флэшки. Чем больше ценной информации мы доверяем окружающему миру, тем важнее защищать эту информацию на всех уровнях работы обрабатывающих ее систем, и хардварный уровень — не исключение.

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

Это оказалось очень нетривиальной задачей, и до конца мы её не решили. Но зато открыли много нового полезного в процессе. Например, мы уже поняли, что ИТ-отделов в компании должно быть два: тактический и стратегический. Тактический — это хелпдеск, железнячники, отслеживание ресурсов и лицензий, мониторинг и вообще всё то, что повторяется больше 2 раз. Стратегический — это реализация major-фич, планирование на 2-3 года вперёд и финансы.

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

Но давайте начну с методологии.

«Найди всему причину и ты многое поймешь»

Возможно, мои постоянные читатели (ну не может быть, чтобы их не было) помнят, что я как то в своем посте недоумевал по поводу того, что при описании регистров внешних устройств используется атрибут unsigned. В комментариях было предположено, что это сделано, чтобы избегать неопределенного поведения при сдвигах и я согласился. Как я недавно обнаружил, есть еще одна причина для подобного использования атрибута и она может быть приложена не только к регистрам, но и к обычным переменным.

Итак, мы начинаем.

0. Перед прочтением статьи

Данная статья преследует следующие цели:

1. показать, как работать конкретно с этой платой;
2. показать подход, с помощью которого можно написать программу мигания светодиодом, опираясь исключительно на документацию и логику;
3. изложить материал языком, понятным человеку, слабо знакомому с микроконтроллерами.

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

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




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

Написать эту статью меня сподвигло большое количество материалов о статическом анализе, всё чаще попадающихся на глаза. Во-первых, это блог PVS-studio, который активно продвигает себя на Хабре при помощи обзоров ошибок, найденных их инструментом в проектах с открытым кодом. Недавно PVS-studio реализовали поддержку Java, и, конечно, разработчики IntelliJ IDEA, чей встроенный анализатор является на сегодня, наверное, самым продвинутым для Java, не могли остаться в стороне.

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

Но волшебных эликсиров не бывает. Я хотел бы поговорить о том, о чём обычно не говорят в постах вида «вот какие штуки может найти наш робот»: чего не могут анализаторы, в чём их реальная роль и место в процессе поставки софта, и как внедрять их правильно.


Храповик (источник: википедия).