Рекомендации для Golang разработчиков, как использовать многоэтапную сборку, для создания более компактных Docker образов. Давайте, рассмотрим на примере, как многоэтапная сборка позволяет значительно уменьшить размер Docker образа.
Developer and tech writer
Знакомство с p-адическими числами. Часть 1
Изображение с сайта Mathematical Art Galleries
В этой серии из двух статей я приглашаю вас заглянуть в один любопытный и не самый популярный уголок математики, в котором обитают необычные создания — p-адические числа, а попутно хочу рассказать о написанной мной Haskell-библиотеке для работы с ними, а также о двух классных инструментах: о типах-литералах (type literals) и семействах типов (type families), приближающих нас к заветным зависимым типам.
Я люблю язык Haskell и, начиная с какого-то времени, мне стало комфортно думать на нём, особенно, на математические темы. Когда понадобилось освоить новый инструмент, — p-адические числа, оказалось, что в репозитории hackage, основном для Haskell-сообщества, нет инструментов для работы с ними, даже в таких серьёзных теоретико-числовых библиотеках, как arithmetic, arithmoi или factory. В конце концов, я написал и опубликовал свой модуль padic, и во второй части этой серии расскажу о некоторых деталях его реализации. А сейчас речь пойдёт о самих p-адических числах.
Как мы теперь договариваемся о новом бизнесе на берегу: юнит-тесты в реальном мире
Идея тестировать код постановкой его в неудобные ситуации появилась далеко не сразу. До этого не разработчик думал о том, как поломать код в разных тестах, а тестировщики пытались сделать это руками. Грубо говоря, предполагалось, что мудрый разработчик пронзит код мыслью и сразу представит все его состояния в квантовой суперпозиции.
Очень многие вещи из ИТ-сферы напрямую относятся к бизнес-процессам. Тойота в какой-то момент придумала промежуточные юнит-тесты на производстве в своей TPS («каждое следующее звено — внутренний заказчик с критериями приёмки»), но вот в областях типа переговоров истории сквозных проверок далеко не зашли. Вообще, в решении типовых переговорных ситуаций есть очень много гениальных механик вроде «русской рулетки» или «техасской перестрелки» при разделе имущества. Только мало кто договаривается подобное применять, потому что в конечном итоге нужно уметь декомпозировать ситуацию и отладить её.
Лет 7 назад я писал про очень простую модель того, как могут договариваться основатели небольшой компании на старте: кто за что отвечает, кто главный в ситуации клинча, как принимаются важные решения и так далее. Это была хорошая рабочая механика, но, как выяснилось за это время, случиться может вообще всякое. И все эти исключения надо обрабатывать. Например, я не думал, что у нас будет смерть соучредителя (и последовавшие проблемы для начала с почтой и доменом, зареганными на него, а потом ещё с кучей всего с наследством его доли).
И вот в какой-то момент к нам в гости завалился человек, который посвятил полжизни конфликтам учредителей. Первая мысль была: «Ну, это не про нас». А потом здравый смысл пересилил, и мы попробовали его механику договорки. И знаете, что? Отдаёт мазохизмом, но удивительно хорошо работает. В общем, давайте покажу, как выглядит очень далёкий, но всё же аналог юнит-тестов сотрудничества нескольких предпринимателей.
Head-of-Line Blocking в QUIC и HTTP/3: Подробности
Как вы могли слышать, после четырех лет разработки протоколы HTTP/3 и QUIC приблизились к официальной стандартизации. Предварительные версии уже доступны для тестирования на серверах и браузерах.
HTTP/3 обещает значительный прирост производительности по сравнению с HTTP/2, в основном благодаря смене транспортного протокола с TCP на QUIC over UDP. В этой статье мы подробно рассмотрим только одно улучшение, а именно — устранение проблемы блокировки начала очереди (Head-of-Line blocking, HOL blocking). Это будет полезно, так как я прочитал много заблуждений о том, насколько это решение полезно и как оно помогает на практике. Решение HOL blocking было основным мотивом не только HTTP/3 и QUIC, но и HTTP/2, и это дает фантастическое представление о причинах эволюции протокола.
Я расскажу о проблеме и ее формах на фоне истории протокола HTTP. Рассмотрим, как эта проблема влияет на системы приоритизации и контроля перегрузки сети. Цель данной статьи — помочь людям сделать правильные выводы об улучшении производительности в HTTP/3, которые (спойлер!) не всегда так хороши, как пишут в маркетинговых материалах.
Оптимизация микросервиса на Go на живом примере
Всем привет. Меня зовут Нещадин Иван, и я расскажу про оптимизацию одного из микросервисов Авито на Go. История построена вокруг различных инструментов, которые доступны в языке, и пойдёт от простых примеров к более сложным.
Правила дизайна иконок, которые стоит запомнить
Изображение стоит тысячи слов. Хорошо продуманное стоит еще больше. Мы видим их на дорожных знаках, в ресторанах, аэропортах и приложениях. Они могут сэкономить время, а могут создать путаницу.
Иконки считываются быстрее текста, их легче заметить, они занимают меньше места и требуют меньше усилий при переводе. Стена из текста сливается в кучу, а иконки различаются по форме и хорошо выглядят даже в группах. Несколько рекомендация по созданию эффективных иконок — в переводе под катом.
Как реализовать язык программирования на JavaScript. Часть 1: Парсер
Здравствуйте! Представляю вам любительский перевод руководства реализации своего языка программирования на JavaScript — PL Tutorial.
От переводчика
Мы создадим свой язык программирования — λзык (в оригинале — λanguage). В процессе создания мы будем использовать достаточно много интересных техник, таких как рекурсивный спуск, стиль передачи управления, базовые техники оптимизации. Будет создано две версии интерпретатора — обычный и CPS-интерпретатор, транс-компилятор в JavaScript.
Автор оригинала — Mihai Bazon, автор известной библиотеки UglifyJS (инструмент для минимизации и форматирования JS-кода).
Google Safe Browsing — пришла беда откуда не ждали
Гайд по автоматическому аудиту смарт-контрактов. Часть 3: Mythril
Warning
Данная статья — это не рейтинг эффективности автоанализаторов. Я применяю их к собственным контрактам, намеренно синтезируя ошибки, и изучаю реакции. Такое исследование не может являться основанием для определения "лучше-хуже", для этого имеет смысл провести слепое исследование на большой выборке контрактов, которое, учитывая капризный характер такого рода ПО, провести крайне сложно. Вполне возможна ситуация, когда небольшая ошибка в контракте может отключить большой кусок логики анализатора, а простейший эвристический признак может добавить анализатору огромное число очков за счет нахождения широко распространенного бага, который конкуренты просто не успели добавить. Также могут сыграть роль ошибки в подготовке и компиляции контрактов. Все рассматриваемое ПО является довольно молодым, и дорабатывается постоянно, поэтому не стоит воспринимать критические замечания как непоправимые проблемы.
Цель статьи — дать читателю понимание того, как работают методы анализа кода в разных анализаторах и умение их правильно использовать, а не "определиться с выбором". Разумный выбор — использовать сразу несколько инструментов, делая акцент на наиболее подходящем для анализируемого контракта.
Новый взгляд на изучение и документирование исходного кода
Проблема
Недавно я проводил опрос о главных проблемах с которыми мы сталкиваемся когда начинаем изучать исходный код большого проекта (если вы ещё не участвовали, то пройти опрос всё ещё можно тут).
DNS прокси на Node.JS своими руками
Понесло пакет по кочкам в дальний лес за DNS…
Л. Каганов "Гамлет на дне"
При разработке сетевого приложения иногда возникает необходимость запустить его локально, но обращаться к нему по реальному доменному имени. Стандартное проверенное решение — прописать домен в файле hosts. Минус подхода в том, что hosts требует чёткого соответствия доменных имён, т.е. не поддерживает звёздочки. Т.е. если есть домены вида:
dom1.example.com,
dom2.example.com,
dom3.example.com,
................
domN.example.com,
то в hosts нужно прописать их все. В отдельных случаях, домен третьего уровня не известен заранее. Возникает желание (пишу за себя, кто-то, возможно, скажет, что и так нормально) обойтись строкой вида:
*.example.com
Решением проблемы может стать использование собственного DNS-сервера, который будет обрабатывать запросы в соответствии с заданной логикой. Такие сервера есть, и вполне бесплатные, и с удобным графическим интерфейсом, например CoreDNS. Так же, можно менять DNS-записи на роутере. Наконец, воспользоваться сервисом наподобие xip.io, это не совсем полноценный DNS-сервер, но для некоторых задач отлично подойдёт. Словом, готовые решения существуют, можно использовать и не заморачиваться.
Но в этой статье описан другой путь — написание собственного велосипеда, стартовая точка для создания инструмента наподобие перечисленных выше. Мы напишем свой DNS-прокси, который будет слушать входящие DNS-запросы, и если запрашиваемое доменное имя есть в списке, вернёт заданный IP, а если нет — запросит вышестоящий DNS-сервер, и переправит полученный ответ без изменений запрашивающей программе.
Опытное производство электроники за минимальный прайс
Почитал я некоторые ранее опубликованные статьи о том, как жить славному молодцу, перед которым встала задача спаять 10-50-100 устройств из резисторов и микросхем, и взгрустнул, ибо во всех в них советы были даны если не вредные, то и не сильно полезные.
А вот, например, совет держать включённый паяльник за ручку — полезный!
В связи с этим хочу рассказать, как можно легко решить задачу, совершенно типичную для пары-тройки собравшихся вместе индивидуальных разработчиков-фрилансеров, небольшой компании по разработке электроники или опытного отдела в компании покрупнее:
- регулярно надо делать 5-10-50-100 плат с SMD-компонентами
- по возможности быстро
- по возможности дёшево
Если вы можете позволить себе — что по срокам, что по деньгам — услуги «Резонита» или «Компэла» (сотрудничающего, впрочем, с «Резонитом») по сборке модулей под ключ, то текст ниже в общем и целом не для вас. Однако, на практике даже в достаточно крупных компаниях люди, занимающиеся опытными образцами, часто собирают их сами — потому что это занимает пару дней вместо недели, потому что всегда можно на ходу что-то подправить, потому что не надо бегать между начальством и бухгалтерией со счетами и актами… В мелких же вопрос упирается попросту в деньги.
Тем более, что в наше время базовое оборудование, позволяющее делать подобные вещи достаточно быстро и достаточно дёшево, доступно даже любителю-одиночке.
Удешевление мелких серий электроники в России. Кейс интернет-радиоприемника WOLNA
Теория категорий на JavaScript. Часть 1. Категория множеств
Абстракция – это одна из основных техник в ИТ. Любой язык программирования или моделирования, любая парадигма программирования (процедурная, функциональная, ООП, …) дают ответ на вопрос, как и от чего нужно абстрагироваться. Причём, адепты каждого подхода предлагают какой-то свой вариант абстракции.
Если вы хотите увидеть истинную, универсальную абстракцию, то
Также немного говорится про классы, примеси и смеси в JavaScript.
Примеры из статьи можно посмотреть тут.
Как основать производственный кооператив. Руководство для фрилансера в ИТ-сфере (перевод)
Примечание переводчика
Для многих «кооператив» это что-то про строительство, гаражи или сельское хозяйство. Тем не менее, по этой модели в мире организованы многие компании в разных областях
https://ru.wikipedia.org/wiki/Кооператив
В последнее время я интересуюсь вопросами кооперации в ИТ и считаю, что, при определенных условиях, данная модель имеет существенные преимущества.
А что думаете вы?
- насколько данная модель применима в условиях России?
- Какие плюсы и минусы?
- Есть ли среди нас те, у кого был успешный или не успешный опыт создания ИТ-кооператива
Рекомендовано к прочтению не только фрилансерам, но и всем, кто думает о будущем, и возможных траекториях развития своей карьеры.
Содержание
Зачем создавать производственный кооператив группе фрилансеров?
Что такое производственный кооператив?
Как создать производственный кооператив в сфере IT?
Истории от производственных кооперативов технической сферы
Зачем создавать производственный кооператив группе фрилансеров?
На первый взгляд может показаться, что основание кооператива фрилансеров противоречит самой сути такого рода деятельности. В конце концов, быть независимым, боссом самому себе, свободно странствующем одиноким волком, является, вроде бы, главным мотивом фриланса.
Многие из нас, имея опыт как работы по найму, так и в статусе фрилансера, затем, став частью производственного кооператива, открыли для себя, что такая модель объединяет всё лучшее из обоих форматов занятости. Ты всё также пользуешься всеми привилегиями фрилансерства, и остаешься боссом самому себе, но тебе нет необходимости тянуть всё одному. Вот некоторые преимущества, которые открывает фрилансеру членство в производственном кооперативе:
Правильно «готовим» прототип. Технологии прототипирования корпуса
Пишем операционную систему на Rust. Страничная организация памяти
Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий запрос.
Аппликативные парсеры на Haskell
Мотивация
Когда я только начинала осваивать Haskell, меня очень раздражало повсеместное использование сложных абстракций вместо каких-то конкретных решений. Мне казалось, что гораздо лучше всегда следовать принципу KISS и писать велосипеды с использованием элементарных конструкций языка, чем разбираться во всех этих классах типов, чтобы где-то в итоге написать одну якобы удобную конструкцию.
Мне не хватало хорошего примера, где бы окупались усилия, потраченные на освоение "матчасти". Для меня одним из самых удачных таких примеров оказались парсеры. Теперь я довольно часто рассказываю про них, когда у меня спрашивают, для каких распространённых задач можно красиво использовать Haskell.
Я хочу предложить начинающим тоже пройти этот путь и создать с нуля небольшую базу функций для удобной реализации парсеров, а затем использовать её для написания собственного парсера, код которого будет практически дословно повторять грамматику, по которой осуществляется разбор.
Надеюсь, кому-то это поможет перебороть страх абстракций и научит уместно их использовать (да, я всё ещё считаю, что иногда бывает эффективней написать велосипед).
Анализ атак на ханипот Cowrie
Пиу-пиу! Начнём сразу с карты атак
Наша суперклассная карта показывает уникальные ASN, которые подключались к нашему ханипоту Cowrie за 24 часа. Жёлтый соответствует SSH-соединениям, а красный — Telnet. Такие анимации часто впечатляют совет директоров компании, что позволяет выбить больше финансирования на безопасность и ресурсы. Тем не менее, карта имеет некоторую ценность, чётко демонстрируя географическое и организационное распространение источников атаки на наш хост всего за 24 часа. В анимации не отражается объём трафика с каждого источника.
«Надежность и безотказность как в Google» — и не только: перевод статьи «Расчёт надёжности сервиса»
Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса и\или его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность