Измеритель уровня углекислого газа (CO2) наверное самый недооценённый прибор, который на мой взгляд должен быть в каждой квартире, ведь он показывает, насколько воздух пригоден для дыхания и с помощью него всегда видно, когда пора проветривать.

Такой измеритель в квартирах большая редкость прежде всего из-за высокой цены. Свой первый измеритель AZ Instruments 7798 CO2 datalogger я покупал за $139 и это была самая дешёвая модель на рынке.

Сейчас готовый измеритель CO2 стоит около 4000 рублей, а самодельный обойдётся вдвое дешевле.

В июле и августе 2020 года я, с подачи Григория Петрова, проводил для компании Evrone технические интервью на позицию Senior Golang Backend developer. И, видимо, буду вынужден продолжать проводить, о чём ниже.

Задача формулировалась как «найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go». То есть, сформулирована она была по-человечески, перевод на канцелярит — мой. Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько лет — старый был с жестким закосом под DevOps. Методику, которой я пользуюсь для создания опросников и количественной оценки соответствия кандидатов, я излагал в своем докладе «Техническое интервью как инженерная задача» на конференции Saint TeamLead 2019.

И вот что я хочу сказать вам, коллеги: вы меня огорчаете.

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.

Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.

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

Honey Tokens (англ. — «медовые приметы/признаки/идентификаторы») одна из разновидностей идеи Honeypot, приманки для злоумышленников, позволяющей обнаружить факт взлома или опознать его источник. Когда атакующий уже проник в систему, он, скорее всего, выполнит действия, несвойственные обычному пользователю. Это можно использовать как способ обнаружения взлома. В статье мы рассмотрим, как легко сделать собственные триггеры для обнаружения взлома на раннем этапе. Такие ловушки полезно использовать системному администратору и даже обычному пользователю, переживающему о приватности своих данных.

До изобретения газоанализаторов шахтеры брали c собой в шахту канарейку. Из-за маленького организма и быстрого обмена веществ, птицы намного раньше реагировали на опасные газы в воздухе и предупреждали шахтеров.

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

Я потратил довольно много времени на своё увлечение освещением и ĸамерами. А теперь хотел бы помочь вам — новым стримерам, подĸастерам, удаленным сотрудникам или всем, ĸто хочет повысить уровень их оборудования.

Оцените несколько разных вариантов для удаленной работы и трансляций.

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

Главная героиня нашего сегодняшнего интервью редко нуждается в представлении. Света Смирнова, инженер технической поддержки Percona, является экспертом по диагностике неполадок и оптимизации производительности MySQL, активным членом российского и международного Open Source сообщества, регулярным спикером на крупных профильных мероприятиях, автором одной из наиболее актуальных книг по MySQL — «MySQL Troubleshooting». На предстоящем летнем PG Day'17 Russia Света проведет интенсивный учебный курс по отладке производительности MySQL и прочитает лекцию, посвященную отладке репликации.

Накануне PG Day, мы побеседовали со Светой о тонкостях процесса репортинга и устранения багов в MySQL, последних тенденциях и трендах в мире популярных форков, истории внедрения функциональности поддержки JSON и подготовили подборку материалов, блогов и книг, полезных для всех специалистов, работающих с MySQL.

Эксклюзивно для PG Day, специальный раздел учебного курса будет посвящён Performance Schema. С её помощью можно отлаживать хранимые процедуры, отслеживать, где используется оперативная память сервера MySQL, просматривать текущие переменные отдельно для каждого соединения, отлаживать запросы, диагностировать блокировки и многое другое. Света расскажет, как настраивать Performance Schema и правильно выбирать входящие в нее инструменты для ваших задач.

В 2016-м я выступил на Highload с докладом про Vinyl, движок для хранения данных на диске в Tarantool. С тех пор мы добавили много новых возможностей, но хранение данных на диске — такая объемная тема, что основы, о которых идет речь в этой статье, совсем не изменились.

Содержание (чтобы удобно было ориентироваться):

• Почему мы написали новый движок?
• Алгоритм
  
  • Наполнение LSM дерева
  • Управление формой LSM-дерева
  • Поиск
  • Поиск по диапазону
  • Удаление
• Преимущества LSM
• Недостатки LSM и их устранение
  
  • Непредсказуемая скорость записи
  • Непредсказуемая скорость чтений
    
    • Компрессия и постраничный индекс
    • Bloom-фильтры
    • Кэширование
  • Управление сборкой мусора
• Расширенные возможности Vinyl
  
  • Upsert
  • Вторичные ключи
  • Транзакции
• Заключение

Привет!

Меня зовут Саша и я работаю архитектором в Тинькофф Бизнес.

В этой статье хочу рассказать о том, как преодолеть ограничение браузеров на количество открытых долгоживущих HTTP-соединений в рамках одного домена при помощи service worker.

Если хотите — смело пропускайте предысторию, описание проблемы, поиск решения и сразу переходите к результату.

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

Я согласен со всеми пунктами статьи кроме того, что касается САР теоремы. Она слишком всё упрощает и слишком многие понимают её неверно для того, чтобы использовать для определения характеристик системы. Так что я прошу перестать ссылаться на САР теорему, говорить о ней и дать ей уже спокойно уйти на покой. Вместо неё мы должны использовать более точную терминологию для обсуждения различных компромиссов.

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

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

В последнее время на Хабре стали чаще появляться посты о том, как хорош Telegram, как гениальны и опытны братья Дуровы в построении сетевых систем, и т.п. В то же время, очень мало кто действительно погружался в техническое устройство — как максимум, используют достаточно простой (и весьма отличающийся от MTProto) Bot API на базе JSON, а обычно просто принимают на веру все те дифирамбы и пиар, что крутятся вокруг мессенджера. Почти полтора года назад мой коллега по НПО "Эшелон" Василий (к сожалению, его учетку на Хабре стёрли вместе с черновиком) начал писать свой собственный клиент Telegram с нуля на Perl, позже присоединился и автор этих строк. Почему на Perl, немедленно спросят некоторые? Потому что на других языках такие проекты уже есть На самом деле, суть не в этом, мог быть любой другой язык, где еще нет готовой библиотеки, и соответственно автор должен пройти весь путь с нуля. Тем более, криптография дело такое — доверяй, но проверяй. С продуктом, нацеленным на безопасность, вы не можете просто взять и положиться на готовую библиотеку от производителя, слепо ему поверив (впрочем, это тема более для второй части). На данный момент библиотека вполне работает на "среднем" уровне (позволяет делать любые API-запросы).

Тем не менее, в данной серии постов будет не так много криптографии и математики. Зато будет много других технических подробностей и архитектурных костылей (пригодится и тем, кто не будет писать с нуля, а будет пользоваться библиотекой на любом языке). Итак, главной целью было — попытаться реализовать клиент с нуля по официальной документации. То есть, предположим, что исходный код официальных клиентов закрыт (опять же во второй части подробнее раскроем тему того, что это и правда бывает так), но, как в старые времена, например, есть стандарт по типу RFC — возможно ли написать клиент по одной лишь спецификации, "не подглядывая" в исходники, хоть официальных (Telegram Desktop, мобильных), хоть неофициальных Telethon?

В инструментах разработчика браузера хром есть вкладка «Audit». На ней расположился инструмент который называется Lighthouse, служит он для анализа насколько хорошо сделано веб приложение.


Недавно я решил протестировать одно приложение и ужаснулся результатам. Сразу по нескольким разделам оценка находилась в красной зоне. Я принялся изучать что же с моим приложением не то. И нашел в результатах анализа большой список очень полезных рекомендаций, выполнил их и получил 500 баллов. В результате приложение стало запускаться значительно быстрее, а я пересмотрел несколько концепций относительно метода построения приложений. А в этой статье я хочу поделиться самыми интересными решениями к которым я пришел.

Недавно вышел бесплатный онлайн-курс в трех частях под названием «Как работают создатели умных наночипов» (1, 2, 3). Он предназначен для профориентации школьников и отличается максимальной конкретностью: вот так выглядит распределение работы в команде проектирования микросхемы, вот на таких концепциях проектирования на уровне регистровых передач построена разработка, и вот такие алгоритмы используются для определения, на сколько мегагерц будет работать проектируемый процессор для компьютера или автомобильной электроники.

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

Прим. перев.: Эта статья написана Taurie Davis — дизайнером из GitLab, которая любит «выявлять проблемы, создавать надёжные решения и творить интуитивно понятные интерфейсы». В ней даются простые советы о том, как наладить коммуникации далеко не только в удалённых командах, но и в нашей повседневной жизни. Даже если они покажутся очевидными, их ценность проявляется тогда, когда мы не забываем их постоянно применять, формируя полезную и выигрышную для всех привычку.

У себя в компании («Флант») мы регулярно проводим performance review для всех инженеров (и не только) и постоянно работаем над тем, чтобы улучшать этот процесс. В частности, на них разбираются и сложности коммуникации — как общие, так и индивидуальные. Посему поднятые автором проблемы нам близки не только в теории: они отлично пересекаются с тем практическим опытом, что накоплен у нас. Надеюсь, их осмысление окажется полезным и для других.


xkcd #1028: «Communication» (см. также его расшифровку)

Коммуникация на рабочем месте может оказаться непростой проблемой. Недопонимания и напряжённость — обычное явление, особенно в случае «асинхронного общения» (возникает при использовании тикетов и электронной почты вместо онлайн-чатов — прим. перев.), где ещё меньше ключей к пониманию голоса и его тона. Прямая коммуникация может восприниматься как жёсткая или грубая. А когда ко всему этому добавляется ещё и упущенный контекст, то ошибки в коммуникации и эмоции могут превзойти саму суть разговора. Улучшить взаимопонимание и коммуникации с течением времени поможет сознательное отношение к потребностям команды и к вашим собственным потребностям.

Всем привет! Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. За это время прошел путь от разработчика до руководителя тимлидов. Работал в таких компаниях как Badoo, Lazada. С начала этого года я в Авито. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость.

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

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

Сегодня я хотел бы поделиться своим опытом поиска и найма тимлидов. Расскажу, с чего стоит начать, и к какому процессу проведения интервью я пришел.

Представляем вашему вниманию первые 5 занятий учебного курса по React для начинающих. Оригинал курса на английском, состоящий из 48 уроков, опубликован на платформе Scrimba.com. Возможности этой платформы позволяют, слушая ведущего, иногда ставить воспроизведение на паузу и самостоятельно, в том же окне, в котором ведётся демонстрация, экспериментировать с кодом. Курс показался нам интересным, мы решили перевести его на русский и преобразовать в формат традиционных публикаций.



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

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Это была славная охота.

Моя жизнь была посвящена ИТ-сфере. Я был инженером, создававшим интересные продукты для больших промышленных компаний. Моей географией была вся Россия, я вживую видел цеха КАМАЗа, ВАЗа и других автогигантов. Но всему в нашей судьбе настаёт предел, и я выгорел. О причинах расскажу как-нибудь в другой раз. Главное, что я, опытный разработчик и техник, ушёл на вольные хлеба и, поскольку у меня появилась семья, решил сделать бизнес — свой магазин товаров для детей, по особым принципам. В общем, как многие из программеров, сделать то, чего не достаёт мне среди предложений на рынке. И знаете, что? Я выяснил, что найти простейших, базовых, нужных профессионалов-подрядчиков очень сложно. Миллион фрилансеров и фирм, а выхлоп… Это был квест, и о нём я должен поведать миру. Не ходите по моим граблям.


Это самое лучшее, что описало моё состояние

“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc

Когда видишь описание инструментов Postman — захватывает дух, просыпается чувство всевластия над своим будущим детищем. Кажется, что и взрощенные в прошлом "монстры" наконец-то падут перед тобой!

В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.

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