На днях мне пришёл крутой девайс — Flipper Zero.
Flipper Zero — это электронный гаджет, который запустил на Kickstarter два года назад русский специалист по компьютерной безопасности Павел Жовнер. Кампания была супер успешна и собрала почти $5 млн! Об этом даже писали в Forbes, а автора приглашали на разные интервью и айти подкасты. Скорее всего, если вы айтишник, то слышали о проекте, а может даже купили себе Flipper.
В ходе кампании проект столкнулся с чудовищными сложностями. Пандемия и остановки производств. Кризис микрочипов. Дефекты сборки. Ребятам приходилось несколько раз менять сборочные линии, перепроектировать плату, искать для компонентов аналоги. Это при том, что вообще сам Кикстартер официально не работает с россиянами, а с китайцами по многочисленным рассказам не так просто договориться до подходящего уровня качества, если заказ не типовой. Отсюда много задержек, первая крупная партия была выпущена, кажется, на год позже, чем заявлено. Но даже в более мягких условиях очень многие проекты не выживают, не справляются с финансовым менеджментом, не просчитывают риски. А тут авторы очень круто везде среагировали и даже в некотором смысле вышли за границы возможного, чтобы выполнить свои обязательства. Моё уважение.
Базово Flipper это небольшой микропроцессор с оснасткой в виде радиомодулей и других средств беспроводной коммуникации. Глобально в этом нет ничего принципиально нового, что-то подобное и раньше мог собрать любой фанат электроники. Но есть несколько нюансов, которые делают устройство крайне любопытным.
Во-первых, кампания велась образцово. Привлекательная затравка и маркетинг «Flipper это тамагочи для хакеров!», регулярные обновления с подробными интересными статьями на радиолюбительские и программистские темы. По этой кампании можно учиться как в принципе презентовать и продвигать электронику на крауд-площадках, особенно в условиях задержек и кризисов.
Во-вторых, качество сборки и компоненты. Здесь лучшее железо по соотношению цена/функциональность, его подбирали люди, которые очень глубоко шарят в теме. Отличный UI/UX и эргономика. Оптимизированное энергопотребление.
В-третьих, что, наверное, самое важное: открытый исходный код прошивки и акцент на комьюнити, где энтузиасты могут писать всякие разные приложения.
На борту две RFID антенны на разные частоты, ИК-приёмопередатчик, субгигагерцовый радиопередатчик, контакты для iButton (у нас это называют "магнитный ключ" или "таблетка", типа как от домофонов), а также многофункциональные порты ввода-вывода GPIO. Из коробки устройство может, например, скопировать и повторить незашифрованный сигнал управления. Конечно, автомобиль вы так не откроете (странно было бы, если бы могли), но, например, на своих умных шторах я уже проверил: Flipper может записать сигнал от пульта штор на частоте 433МГц, а потом воспроизвести его, и шторы открываются! Ещё можно сохранять 125 кГц RFID электронные карты доступа и брелоки. У меня такой, например, от гаража. Что касается высокочастотного RFID (домофоны в новых домах, в паркингах), то есть нюансы, об этом я расскажу попозже.
Прямо сейчас каких-то фантастических функций всё же нет. Думаю, маркетинг частично сыграл злую шутку: некоторые купившие жалуются, типа, где тут кнопка "взломать всё", как в игре Watch Dogs? Даже при росте софтварной оснастки нужна определённая техническая грамотность, чтобы понять, что и как можно делать. Первые устройства только недавно поступили людям на руки, комьюнити разгоняется, документация пишется. Ещё нет ни SDK, ни толком хороших примеров. Персонально я считаю серьёзным недостатком, что в качестве места для сообщества выбран Discord: он совершенно не подходит на роль базы знаний, на закреплённых сообщениях далеко не уедешь.
Но потенциал у вещицы достаточно большой, как мне кажется. Буду писать иногда о своих экспериментах.
#gadgets#dev
Подумал о том, что у сезонного бизнеса куча времени на техдолг. Вот что делают программисты какого-нибудь Whoosh с ноября по март? Увольнять их и искать новых каждый сезон неэффективно. Зарплату им тоже на эти месяцы не снизишь, так как сами сбегут тогда. Да, они могут заниматься исследованием новых фич, но всё равно остается уйма времени на шлифовку всего существующего и разбор техдолга. Они в этот период даже могут выпустить в прод кривой билд приложения, и это никак не ударит по бизнесу. Мало где есть такие условия с этой точки зрения. Тем страннее, конечно, наличие сырых неработоспособных фич, по которым запущен маркетинг.
#dev
Yandex Cup это феерическое унижение, конечно. Набрал 229 баллов из 500, понятно что в финал не выйду.
Думаю мой реальный предел где-то 350-400. Но потратил слишком много времени вот на что:
1. В задаче А (на хеширование) быстро придумал решение, но сотню баллов мне система не выдавала. На каких-то краевых случаях тесты валились, в итоге я набрал 70, потом 75, потом 88. Надо было бросать и идти дальше, в таблице у многих участников эта задача не на 100. Но потерял лишний час, то есть 20% времени.
2. Задача D заключалась в угадывании мыслей авторов. Я обсудил её позже с одним из участников, попавшим в топ-10, и он сказал то же самое. Просто он мысли угадал, а я нет, хотя концептуально я правильно решал. И тоже залип на ней, поскольку было ощущение, что я не учёл какую-то мелочь, и тесты падают из-за этого, а не потому, что она тупо сформулирована.
В итоге впопыхах взялся за задачу С на сложный SQL-запрос и не успел, хотя понимал, как. За частичное решение получил 21/100. Ну и задача B на алгоритм расстановки — единственное, что далось на максимум и без задержек, однако в ней я, как мне кажется, считерил, потому что придумал как захардкодить кейсы вместо алгоритмического перебора.
В целом, если исключить откровенно непродуманную задачу D, то, пожалуй, претензия у меня такая: в реальной жизни вы можете выяснить, по какой причине в конкретном случае программа не работает, а здесь не можете, и нужно гадать. И тут очень сильно решает опыт предыдущего участия, знание того, как мыслят авторы, и так далее.
Не знаю, буду ли пробовать в следующем году. По итогу впечатления скорее негативные, но и отыграться хочется.
#dev
Поучаствовал в квалификации Yandex Cup в блоке Backend. Сдал первую и последнюю задачу на максимум баллов (последнюю вообще с первого раза). А остальные две принципиально не стал решать, потому что меня бесит, когда путают бэкенд-разработку и алгоритмы. У них есть отдельная секция "Алгоритмы", куда я не пошёл, потому что не люблю олимпиадное программирование (вот тут писал в конце причины). Но нет же, давайте в бэкенд тоже засунем душноту про модульную арифметику.
В общем, дальше как судьба распорядится. Если все поленились или плохо сделали, пройду в полуфинал, иначе нет.
#dev
В этом году снова ездил на AtomSkills. Решил написать подробнее на Хабре о том, что там и как, уже с точки зрения члена жюри.
https://habr.com/ru/companies/rosatom/articles/824888/
#dev
Все новости трубят о том, как хакеры положили СДЭК. Хакерская группировка проникла на сервера компании и зашифровала все данные. Пишут, что якобы бэкапы делались раз в полгода, и вообще в сети обсуждают низкие зарплаты у СДЭК для специалистов по информационной безопасности. Не знаю, насколько это правда (не то, что СДЭК лежит -- это уже подтверждено, а то, что там всё плохо с ИБ). Косвенные признаки намекают, что проблемы есть, потому что восстановиться они не могут уже пару дней как.
Во-первых, это показывает, почему нужно госрегулирование. В чистой рыночной экономике больше зарабатывает та компания, которая эффективнее вешает лапшу на уши своим пользователям, но вот для высоких доходов совершенно не обязательно, чтобы внутренние процессы были правильными, честными, безопасными, этичными итд. Брендовую одежду шьют голодные дети во Вьетнаме, люди из-за этого не перестают её покупать. Даже больше — при прочих равных конкуренцию как раз выиграет именно та компания, у которой шьют дети, а не та, которая оплачивает взрослым сотрудникам ДМС со стоматологией. И это хорошо, что хотя бы некоторые процессы государство может (пусть даже номинально) взять под контроль и заставлять бизнес что-то делать. Хотя объём бардака в этом регулировании отрицать не приходится.
Во-вторых, никакой бизнес (и вообще никакой масштабный процесс) не существует с выполнением всех правил. Он просто не будет работать. Собственно, поэтому есть понятие "итальянская забастовка", и вполне действенное. Хороший бизнесмен должен идти на такой уровень риска, который, с одной стороны, позволит бизнесу работать и зарабатывать, но с другой не приведёт в какой-то момент к масштабной проблеме. Wildberries пожалел денег на пожарную безопасность и потерял склад с кучей товаров. Зимняя Вишня поленилась поставить по охраннику у каждого выхода, из-за чего двери были закрыты, и люди погибли. Вот теперь и СДЭК, судя по всему, пожинает плоды экономии на DevOps и DevSecOps. Что сейчас думает тот самый директор, который подписывал распоряжение о зарплате девопсам или, например, о сокращении расходов на инфраструктуру?
#dev
P.S. Сегодня пришёл пуш:
Посмотрел у Rozetked краткую выжимку с презентации Google IO, где они 90% времени хвалили свою нейросетку Gemini. И что подумал: задач для просто болтовни с ИИ в чате не так много. А вот научить робота делать за тебя всякую рутину это уже гораздо интереснее. И тут огромное преимущество Гугла над OpenAI — у Гугла уже полно очень популярных сервисов, на которые можно навесить ИИ-функциональность.
В презентации так и показывали, например почта с нейросеткой — Gemini залезает в каждое ваше письмо и даже читает вложения, а затем, например, может вам сказать, сколько вы денег (по чекам в почте) потратили на определённую категорию товаров за какое-то время. Ну, пример немного вырожденный, но если нейросетки за нас научат надёжно пользоваться веб-сервисами и приложениями, это будет по-настоящему полезным применением. Я бы хотел рассказать экселю обычным человеческим языком, какая мне нужна таблица, и чтобы он её сделал.
Ребята из GigaChat, тем временем, показали мне function calling — как раз попытку поженить машинный интерфейс и языковой процессор. И мне даже хочется попробовать сделать что-то простое.
Можете накидать идей в комментах. Нужен какой-то сервис с API, который я смогу вызывать, либо другая формализованная машинная работа. И к ней какая-то рутинная задача, которая может быть создана из текстового запроса на естественном языке. Что бы это могло быть?
#dev
Порассказывал в нашем корпоративном подкасте о нюансах айти в атомной промышленности. Технических деталей и внутренней кухни особо нет, но по верхам нормально прошлись.
💙ВКонтакте
🎵Яндекс Музыка
🌐Mave
#dev
В C# есть модификатор доступа internal, который закрывает свойство или метод для всего, кроме текущей сборки (сборка это по сути группа пространств имён). И это чертовски удобно для построения правильной архитектуры по DDD — ты делаешь домен отдельной сборкой без внешних зависимостей, у сущностей закрываешь сеттеры и другие поля модификатором internal, а бизнес-правила с открытыми методами уже пишешь в агрегатах, которые содержат эти сущности. Агрегаты объявлены в той же сборке, так что они могут с сущностями делать что угодно, но слой приложения уже сможет вызвать только метод агрегата.
Пример. Есть бизнес-процесс, который включает в себя две сущности: письмо и прикреплённый к нему документ. У каждой из этих сущностей разные жизненные циклы, но письмо можно отправить только в том случае, если статус документа "Согласован". Мы делаем агрегат "письмо с документом" и там public-метод отправки письма сначала проверяет статус документа, а потом вызывает internal-метод отправки в сущности письма. Снаружи (вне домена) вызвать сразу отправку письма невозможно.
Но как эту задачу решают разработчики на других языках? Я совершенно не понимаю, как сделать хорошую архитектуру без internal. Окей, в некоторых языках вообще нет вменяемого ОПП и системы типов, но и к таким ребятам я бы не подходил с вопросами об энтерпрайз-архитектуре. Однако, многие серьёзные проекты пишутся на Java или, скажем, Go, что делают разработчики там? Может, кто-нибудь знает, и расскажет мне в комментариях?
#dev
Обновил ноут, так что для истории выложу крышку старого. По наклейке на каждый конкурс, хакатон и айти-конференцию, где я принял участие, выиграл, был жюри и так далее. Целые слои истории. Смотришь и вспоминаешь то бессонную ночь в Салехарде на хакатоне ЯНАО, то кофе с чак-чаком в Казани на финале Цифрового Прорыва, то огромный призовой фонд в SmartMarket и ещё бОльший в "Код Петербурга"...
Новый ноут побольше и на крышке у него места пока очень много, будем продолжать :)
Кто не знает, почти со всех интересных хакатонов и конкурсов я пишу рассказы, например:
• С первого раза взяли гран-при
• Cамый большой хакатон в мире
• Крупнейший европейский хак Junction
• Конкурс для разработчиков на 2.5 млн рублей
и другие
#dev
Два дня был экспертом на хакатоне по разработке для студентов. Участники, как правило, 4-5 курс, бакалавры и магистры. Многие ребята очень сильные, показали отличный результат, получше, чем у некоторых взрослых программистов с резюме и зарплатой.
Так вот, заметил интересный эффект. Студенты — даже очень компетентные — не могут побороть желание переусложнять систему и использовать чуть ли не все известные им фреймворки и технологии. Даже не знаю, какую аналогию привести — представьте что терапевт делает вам 20 различных видов осмотра на приёме и просит сдать 20 анализов на разные виды вирусов и других болезней, которые ему известны. Вроде и плохого ничего, но и не нужно. С архитектурой приложений аналогично: надо не только знать, что и когда применить, но и чувствовать, что и когда НЕ применять. Это, конечно, приходит с опытом.
Справедливости ради, многие энтерпрайз системы, которые делаются состоявшимися специалистами, тоже переусложнены: условному Твиттеру, конечно же, не нужна никакая тысяча микросервисов. Но там на разработку еще и бизнес влияет и избыток ресурсов, а здесь у студентов тяга к умножению сущностей проявилась особенно ярко и характерно. Например, команда крутых технарей из Бауманки сделала чат-бота на 40 контейнерах, девопс там конечно красавчик, но к дедлайну до конца соединить не успели (хотя всё равно заняли призовое место).
#dev
По теме мне особенно нравится вот эта картинка: