Привет, Хабр! Решил представить тут небольшое и дешёвое устройство, которое на данный момент умеет:
1. Пинговать заданный IP
2. Смотреть пакеты с помощью tcpdump
3. Сканировать сеть через ARP
А главное, всё это работает полностью автономно на Raspberry PI 2 без GUI и потребляет всего 50 Мб ОЗУ!
В статье будет: описание самого устройства и идеи; описание различных приколов и багов в процессе разработки; инструкция как сделать такое самому; и вопрос знатокам, нужно ли это вообще кому-нибудь :)
Привет, Хабр. В этой статье я расскажу про своё видение работы с цветом при визуализации графиков. Буду показывать все на примерах — уверен, они вам понравятся.
Я покажу не только картинки было-стало, но и приведу примеры кода, а также объясню логику принятия решений: как использовать ту или иную палитру в конкретной задаче. И что самое главное, дам пошаговые советы, как сделать график логичнее и понятнее для заказчиков.
Меня зовут Саша, сейчас я работаю в Lamoda Tech старшим бизнес/дата-аналитиком. До этого я несколько лет был специалистом по данным в другой компании и регулярно представлял совету директоров анализ и прогноз физических и бизнес-показателей. Умение донести результаты исследования до заказчика, особенно если он не погружен в работу с данными — это важный аспект моей профессии. Надеюсь, моя статья с этим немного поможет.
Это было еще до пандемии: мы активно добавляли на платформу фотоотзывы. Тестирование одного макета шло больше трех часов, а их были десятки. Чтобы сравнить сборку с макетом, тестировщику приходилось проверять каждый пиксель, учитывая их плотность. На это уходило много времени.
В один момент тестировщик позвал на помощь дизайнера. Тот попросил тестовый телефон, протестировал всю функциональность за 10 минут и нашел пять недочетов!
Наметанный глаз дизайнера способен заметить тончайшие детали, которые легко упустить при ручном тестировании. Поэтому тестирование UI с участием дизайн-команды показалось нам необходимым шагом.
Меня зовут Наташа Филиппова, я руководитель группы разработки в Lamoda Tech. После запуска дизайн-ревью жизнь команды разделилась на «до» и «после», поэтому в этой статье я опишу наш опыт подробнее.
Хабр, привет! Меня зовут Костя Козин, я старший PHP-разработчик Lamoda Tech. За 17 лет в коммерческой разработке я писал на JS, PHP, и теперь на Golang. Сегодня в Lamoda Tech мы учим PHP-разработчиков писать на Go, и под это создали целый онбординг. Довольно часто в локальных обсуждениях я слышал, как тяжело дается переход с PHP на Go, а у некоторых первые месяцы работы с Go вовсе отбивают желание работать с языком. Поэтому я поделюсь подводными камнями, которые ожидают вас при переходе с одного языка на другой, и с которыми сталкивался я сам и мои коллеги. Если знать о них заранее, то смена стека может пройти не так болезненно, а знакомство с Golang станет более предсказуемым.
«Работает — не трогай!» — знакомая фраза? Звучит как девиз стабильности. Но в наше время все меняется со слишком большой скоростью, а такой подход может стать настоящей ловушкой Джокера. Оставленный без внимания проект рискует превратиться из мощного инструмента решения проблем в неподъемный багаж, неспособный соответствовать новым требованиям.
Как же понять, когда «не трогать» становится опаснее, чем «поменять»? Как определить момент, когда старый код начинает замедлять развитие, а не поддерживать его? Сегодня я хочу поговорить с вами о рефакторинге — о том, как найти баланс между работоспособностью и необходимостью изменений, как сохранить проект конкурентоспособным и жизнеспособным, и как, наконец, сделать этот самый рефакторинг.
Если вы не помните, что именно хранится в вашей аптечке, не знаете, какие лекарства просрочены, а какие — нет, если названия препаратов вам мало о чём говорят, а хотелось бы посмотреть их назначение и противопоказания без долгих поисков в интернете и если вас не смущает сомнительный юмор, то эта статья (и разработанный нами сервис) может оказаться вам полезной.
Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.
Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.
После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.
С 2019 года я занимаюсь разработкой open source инструмента под названием pg-index-health, который позволяет анализировать структуру БД и находить потенциальные проблемы.
Все эти годы pg-index-health эволюционировал и развивался. За 2024 год мне при поддержке нескольких контрибьюторов удалось решить большинство остававшихся «детских болячек» и довести проект до состояния, когда он готов к масштабной экспансии.
В этой статье я хочу подробно рассказать об идеях, которые стоят за этим инструментом, и как его использовать в ваших проектах.
Мы постоянно слышим хайповые заявления: «ИИ нас всех заменит», «экспертиза больше не является ограничением», «мы уже знаем как создать AGI» итп. Под влиянием медиа и общественных ожиданий многие воспринимают потенциальные или прогнозируемые технологии как уже существующие.
В этой статье мы разберём, какие задачи искусственный интеллект реально решает уже сегодня, и как их можно разделить на категории: Инженер, Аналитик, Рассказчик и Ассистент. Мы также рассмотрим текущее распределение задач между этими категориями и спрогнозируем, какие изменения произойдут в ближайшие годы.
Далее мы погрузимся в технологии, лежащие в основе ИИ, и разберём их зрелость с помощью Wardley Map — как для классического машинного обучения, так и для генеративных моделей. Особое внимание уделим Retrieval‑Augmented Generation (RAG), одной из наиболее применимых в бизнесе технологий.
Наконец, мы ответим на два практических вопроса: как понять, что бизнесу пора внедрять ИИ, и как выбрать подходящий метод машинного обучения для конкретных задач.
Живя в сложное время, наша психика пытается найти способы объяснить происходящее и успокоить себя. Я научился воспринимать наш мир через философию русского сатирика-постмодерниста Виктора Пелевина. Сразу скажу, что я воспринимаю мир сугубо материалистически, но чтобы не умереть от тревоги, я научился благодаря книгам Виктора относиться к событиям с иронией, а к нашему миру как симуляции (что не отменяет диалектической логики вещей).
Я подумал, если я применяю этот инструмент в качестве мировоззрения, то скорее всего невольно эта дзен-буддистская философия перекочевала и в мой код. Поэтому давайте проанализируем вместе, каким образом мы можем применить эти идеи в нашей повседневной работе, чтобы повысить эффективность и бонусом не сойти с ума от происходящего.
Задавались ли вы когда-нибудь вопросом, можно ли полноценно программировать при помощи директивы #define в языке C? Полнота по Тьюрингу шаблонов C++ известна весьма широко, например, люди пишут трассировщики лучей, делающие все вычисления во время компиляции (вместо времени исполнения). А как обстоят дела с препроцессором C? Вопрос оказался сильно нетривиальнее, и эта история является, на мой вкус, отличным анекдотом для курса лекций по теории компиляторов, что я готовлю в данный момент. В частности, для лучшего понимания происходящего здесь, рекомендую ознакомиться со второй статьёй, которую я опубликовал параллельно этой: лексер и парсер.
Чтобы не было обманутых впечатлений, предупрежу сразу, что рейтрейсера не будет, но про́клятый код будет очень даже! Итак, поехали. Для начала, почему я вообще задался этим вопросом? Если обычный код компьютерной графики вам скучен, следующий раздел можно пропустить, перематывайте до последней картинки.
В этой статье я поделюсь своим опытом разработки юнит-тестов внутри базы данных под управлением PostgreSQL. А также расскажу, зачем мне потребовалось доработать расширение pgTap.
pgTap – это расширение PostgreSQL для разработки юнит-тестов. Сами тесты, как, собственно, и pgTap, пишутся на plpgSQL, что означает низкий порог вхождения для разработчиков PG.
Уверен, что читатель, по крайней мере, знаком с техникой разработки через тесты. Поэтому не буду пускаться в описание теории юнит-тестирования. Благо литературы на эту тему более чем достаточно. Тем не менее, чтобы быть понятым, приведу некоторые детали ниже.
Самое главное – не добавляйте превью к статье. Основную мысль тоже не раскрывайте здесь – не стоит сразу выкладывать все карты
Представьте себе страшный сон тестировщика и в целом вашей команды – пользователи пишут в поддержку, что пуши не приходят, сообщения не доходят, а вы никак не можете воспроизвести проблему и у вас даже нет понимания: а как это воспроизводить, от чего вообще зависит доставка пушей?
Посмотрев русскоязычные и англоязычные ресурсы про тестирование, я так и не смог найти полноценного материала, который бы гарантировал достаточные знания для того, чтобы понимать как пуши и уведомления работают, как их тестировать и что не маловажно как искать и разбираться с проблемами, когда пуши не доходят до пользователей.
Поэтому эта статья перед вами!
Последние несколько лет я являюсь клиентом Т-Банка (в девичестве Тинькофф Банк) и использую их Android-приложение, наверное, каждый день. В декабре я обновил его из Huawei AppGallery, и что-то изменилось в моём пользовательском опыте… Мне стало казаться, что меня стали как-то слишком редко спрашивать отпечаток или PIN после запуска приложения тапом по иконке или по уведомлению. Так произошло раз, два, пять, и я невольно обратил на это внимание. А поскольку моя работа связана с информационной безопасностью, я решил немедленно настучать на плохое поведение разработчикам, тем более у них есть программа bug bounty.
Сказано – сделано. Это было кринжевато, так как я не был на 100% уверен в своих словах, но я всё же написал о том, что меня как-то редко стали спрашивать отпечаток/PIN. У меня была включена опция «Быстрый вход», которая в приложении объяснена так: «Если вы используете отпечаток пальца или скан лица, у вас будет 5 минут, чтобы зайти в Т-Банк без авторизации». Без этой опции поведение было ожидаемым: каждое открытие приложения просило отпечаток/PIN, а вот с ней… Когда я думал, что отпечаток/PIN не нужен, то он не был нужен; когда я думал, что он нужен, он обычно почему-то был не нужен.
Стал я экспериментировать, чтобы у меня был более членораздельный отчёт. Мой телефон разблокировался по отпечатку пальца или PIN, и внезапно оказалось, что «Быстрый вход» в приложении Т-Банка означает не то, что я думал. Я-то, наивный, рассуждал просто: залогинился в приложение – можешь его закрыть, но в течение 5 минут тебя пустят обратно без вопросов (кэширование аутентификации в рамках приложения). Мне казалось, что приложение раньше всё время так и работало, примерно до декабря. А теперь я наблюдал своими глазами нечто иное: если ты предъявил отпечаток для разблокировки телефона, то внезапно приложение Т-Банка будет пускать тебя внутрь без вопросов в ближайшие 5 минут!
Привет, Хабр! Я Женя, ведущий продуктовый дизайнер в Ozon, и за 10+ лет в дизайне повидала всякого: ошибок в макетах (своих и чужих), недостаточно полных спецификаций, неучтённых корнер-кейсов, сотни сообщений в тредах с разработкой и переносы релиза из-за досадных багов.
Стало понятно: спроектировать макеты в Figma может каждый, но докатить их до прода так, как было задумано, — целое искусство, в котором дизайн и разработка должны идти рука об руку. Понимают ли они друг друга? Я запустила анонимный опрос в командах: что радует и что раздражает разработчиков в макетах дизайнеров — и наоборот. И в этой статье хочу порефлексировать над его результатами.
Заодно поделюсь полезными практиками, которые помогут наладить взаимодействие дизайна и разработки: чек-лист для подготовки макетов, поиск корнер-кейсов, спецификация, груминг, саппорт, дизайн-ревью и прочие заклинания. Поэтому статья будет полезна не только дизайнерам, но и разработчикам, QA-инженерам, продактам и всем, кто заинтересован в качестве конечного решения на проде.
Осторожно, количество мемов в статье зашкаливает