Разработчик
Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.
Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.
За этот долгий срок проект пережил несколько слияний и разделений компании, означающих серьезные потери людей, знаний, и даже исходников от некоторых сервисов по юридическим соображениям.
На проекте были благополучные периоды, когда были созданы очень крутые и амбициозные вещи. Но были также периоды, когда команды еле хватало на выполнение самых срочных задач. И в это время многие сделанные или не доделанные большие штуки изрядно обветшали.
Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.
Но за три прошедших года мы с командой кардинально изменили ситуацию. В этой статье я расскажу про самую значимую перемену — простую, но кратно снизившую и накладные расходы, и риски. А это уже открыло дорогу сотням маленьких изменений, в итоге преобразивших проект.
Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?
Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?
Тогда вам сюда:
«Effective Kafka: A Hands-on Guide to Building Robust and Scalable Event-Driven Applications», «Kafka: The Definitive Guide» и другие издания.
В этой статье я расскажу, как изучал Apache Kafka и с какими трудностями столкнулся. Я очень надеюсь, что мои наблюдения помогут тем, кто ещё только приступает к знакомству с платформой. Здесь мы обсудим полезные ресурсы, в основном, книги, которые я прочитал, и мой опыт с платформой#nbsp;— до чтения книг и после.
Как говорил доктор Хаус: Все врут.
Я решил написать данный текст после прочтения недавнего поста на хабре от "скептика" а так же после длительных дискуссий с разными людьми, которые уверены что все это фейк и даже больше. В данном тексте я не оцениваю политизированность темы, ошибочность принятых решений или необходимость каких-то действий. Цель данного текста исключительно в развеивании мифов, которыми люди бросаются либо из-за невежества, лени, злости или с целью ввести оппонента в заблуждение. Я так же стараюсь не касаться вопросов кому это нужно и какова цель, так как прекрасно понимаю, что если у вас параноя, то это не значит, что за вами не следят.
Текст разделен на две части: Ковид в частности и вирусология в общем.
Если у вас есть дополнения или исправления, пожалуйста - пишите их в комментариях с аргументацией и, если необходимо с приведением источников.
Если у вас есть вопрос или утверждение которое вы хотите добавить, постарайтесь написать его в таком же формате (вопрос, объяснение, источники) и так же оставляйте во комментарии я постараюсь добавить все по мере возможностей.
Довольно давно я хотел сделать свою вытесняющую ОС для микроконтроллера, но не нашел стоящего мануала, или плохо искал, хз. В результате разобрался что к чему, что для этого нужно и решил написать пост об этом, вдруг кому-то пригодится.
Короче говоря, надеюсь это будет полезно, или хотя бы интересно, для людей, ищущих ответы на вопросы на формах и статьях на Pikabu Хабре, а не в патентах, документации и прочих унылых источниках, где нет вставок с мемами.
Представьте человека, который изучает алгоритмы. Чтобы понять как они работают, приходится разбираться в их коде и представлять, как компьютер будет его выполнять. Это странно — почему мы должны учиться думать как компьютер, вместо того, чтобы заставить его помогать нам? Какая-то сильная технозависимость.
На мой взгляд, потеть должна машина, а человек учиться, не выворачивая мозги наизнанку. Поэтому я подумал, а почему бы не визуализировать работу алгоритмов? Визуализации помогли бы не закапываться в код, а наглядно показали бы как работают алгоритмы и позволили бы понять их. Что у меня получилось — читайте в этой статье.
Возможно Вам доводилось слышать про протокол журнала событий syslog, в котором можно насчитать аж 8 уровней важности: emergency, alert, critical, error, warning, notice, info, debug. Наверняка Вы, как и я какое-то время назад, думаете, “зачем столько”? А что если я скажу, что количество уровней там просто идеально? И использовать можно все - даже debug - для продакшн. Во всяком случае, каждому из них можно придать формальный критерий. Это особенно иронично для меня самого, так как всего пару месяцев назад я написал статью в духе “зачем так сложно!”. Так что если Вам интересно посмотреть на пример технического “переобувания” или оценить строгий алгоритм ранжирования уровней важности событий в системе - прошу.
Увлекательный пересказ того, как компилятор C++ находит правильную функцию, которую надо вызвать, когда в коде вызывается функция. По сути, это просто сжатое объяснение алгоритма, уже описанного на cppreference.com, который, в свою очередь, является сокращенной версией стандарта C++.
Хочу поделиться своим опытом реализации микросервисной архитектуры поверх actor-model фреймоворков, таких как AKKA и Microsoft Orleans.
Моя гипотеза: если использовать один стек для реализации микросервисов, то можно:
О… Похоже на «серебряную пулю»! Давайте разберемся, так ли это.
Некоторое время назад у нас появился объект, где в техническом задании стояло требование: «Протокол Ethercat». В процессе поиска информации я полез на хабр и с удивлением обнаружил, что там разбора этого протокола нет. Да и вообще информация о нем довольно фрагментирована (забегая вперед — я просто не там искал). Проект мы сделали, а эта статья — для «более молодого меня», попытка сэкономить время кому-нибудь еще, кто собирается использовать или просто интересуется этим протоколом.
Единственный нюанс — я опишу довольно низкий уровень работы протокола (Data Layer в терминологии EtherCAT). Потому что именно он нам понадобился и им мы ограничились. Неописанными (пока?) останутся Application Layer протоколы типа CanOPEN-over-EtherCAT (CoE).
Я продолжаю выразительно пересказывать документацию Ансибла и разбирать последствия её незнания (ссылка на предыдущую часть).
В этой части мы обсуждаем инвентори. Я обещал ещё и переменные, но инвентори оказалась большой темой, так что посвящаем ей отдельную статью.
Мы будем разбирать каждый элемент инвентори (кроме host_group_vars plugin) и обсуждать зачем он, как его использовать правильно, и как неправильно.
Оглавление:
inventory_hostname vs ansible_hostansible_user — писать или не писать?
У некоторых людей возникает необходимость передать небольшие сообщения. Но как это сделать, если вы пользуетесь различными социальными сетями и мессенджерами, в безопасности передачи данных через которые вы сомневаетесь.
Некоторые люди для этого используют сервисы самоуничтожающихся шифрованных записок. Но тут встает вопрос можно ли доверять этим сервисам и действительно ли они уничтожают записки после прочтения.
Для решения этой проблемы мы напишем свой сервис самоуничтожающихся шифрованных записок на языке Python с использованием модуля cryptography и фреймворка Flask и развернем его на облачном сервисе Heroku.
Изучая рунет, я не смог найти ни одной статьи, которая описывала бы ВСЕ этапы разработки и производства корпуса устройства.
Ни одной. Всё, что есть в интернете, касается лишь одного или двух аспектов этого процесса. Ну например: давайте набросаем корпус и распечатаем на 3D-принтере. Или купим типовой и насверлим в нём отверстий. Хотя на Хабре и есть пара материалов, но они тоже не так полны информацией, как могли бы быть.
Но так, чтобы были расписаны все этапы, от идеи до серийного производства, — я такого не нашёл. Поэтому решил написать своё руководство, максимально наполненное фактами, картинками и примерами.