Близкое знакомство с возможностями терминала — один из признаков человека, который хорошо разбирается в Linux. Хотя некоторые вещи запомнить сложно, есть довольно-таки простые, но эффективные приёмы, которые способны повысить качество и скорость работы в терминале. Пожалуй, каждый пользователь Linux рано или поздно обзаводится собственным списком ценных мелочей. Надеемся, некоторых из тех десяти приёмов работы в командной строке Linux, которыми мы хотим с вами поделиться, попадут в ваш личный список полезных команд.

Я расскажу о такой проблеме, как хеширование паролей в веб-сервисах. На первый взгляд кажется, что тут все «яснопонятно» и надо просто взять нормальный алгоритм, которых уже напридумывали много, написать чуть-чуть кода и выкатить все в продакшн. Но как обычно, когда начинаешь работать над проблемой, возникает куча подводных камней, которые надо обязательно учесть. Каких именно? Первый из них — это, пожалуй, выбор алгоритма: хоть их и много, но у каждого есть свои особенности. Второй — как выбирать параметры? Побольше и получше? Как быть с временем ответа пользователю? Сколько памяти, CPU, потоков? И третий — что делать с computational DoS? В этой статье я хочу поделиться некоторыми своими мыслями об этих трех проблемах, опытом внедрения нового алгоритма хеширования паролей в Яндексе и небольшим количеством кода.

Attacker & Defender

Прежде чем переходить к алгоритмам и построению схемы хеширования, надо вообще понять, от чего же мы защищаемся и какую роль в безопасности веб-сервиса должно играть хеширование паролей. Обычно сценарий таков, что атакующий ломает веб-сервис (или несколько веб-сервисов) через цепочку уязвимостей, получает доступ к базе данных пользователей, видит там хеши паролей, дампит базу и идет развлекаться с GPU (и, в редких случаях, с FPGA и ASIС).

При балансировке нагрузки важный вопрос — сохранение сессии клиента. Особенно, если за балансировщиком стоит какой-то интерактивный backend. И тем более, если захотелось сделать A/B тестирование и гибко регулировать порции клиентов к различному содержанию. "Nginx plus" предлагает такие возможности, но что делать, если хочется дёшево и быстро?

На помощь приходит возможность расширить функционал Nginx с помощью Lua.

Недавно мы выпустили GitLab 9.0, через 18 месяцев после выпуска версии 8.0. За это время мы сделали множество значительных изменений в GitLab, выпуская новую версию 22 числа каждого месяца. Давайте кратко подведем итоги, к которым мы пришли с выпуска 8.0, и посмотрим, как старые фичи соотносятся с новыми из 9 версии. Или вы можете перейти к фичам, появившимся в 9.0.

Сейчас вы прочитаете увлекательную историю моего превращения из разработчика в тимлида. Это было долгое путешествие со множеством шагов назад, которое всё же закончилось уверенным шагом вперёд. Устраивайтесь поудобнее, берите попкорн… Поехали!

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

Итак, возможные преимущества, которые можно выкатывать на сайте, чтобы цеплять потенциальных клиентов:

В этой статье рассматривается простой способ создания и тестирования образов docker. По ходу повествования, используя Goss, мы напишем тесты, с помощью которых можно проверить официальный образ Nginx всего за ~0,5 с.

Историю нашумевшей технической ошибки «Додо Пиццы», партнера Яндекс.Кассы, нам рассказал системный архитектор компании Андрей Моревский — сразу передаю микрофон автору.

Еду я в «Сапсане» на открытие первой в Санкт-Петербурге пиццерии «Додо», как вдруг получаю оповещение о множественных отменах оплаченных заказов. И не просто множественных — наша система за час умудрилась откатить якобы оплаченные заказы на 8 миллионов рублей!

Сейчас эта история вызывает только улыбку, но в то утро было совсем не смешно. Поэтому хочу поделиться некоторыми техническими подробностями инцидента и сделанными выводами, а заодно немного рассказать про систему обработки заказов «Додо Пиццы».

UPD. CardInfo больше не работает. Используйте BinKing.

Гайд по использованию: https://habr.com/ru/post/527796/
Сайт сервиса: https://binkng.io

Всем кто верстал, верстает или будет верстать форму для приёма банковских карт дарю плагин CardInfo.js, с помощью которого можно сверстать вот такую форму:

Плагин по номеру карты определяет один из 49 российских банков (потом и прочие страны добавлю), выдаёт вам логотип банка, цвета для фона, ссылку на сайт банка, определяет тип карты, его логотип и прочее. С этими данными делаете что хотите, верстаете любую форму.

Поиграться с формой можно на демо странице. Код плагина и инструкции по установке на гитхабе.

Под катом:

• Пара слов о плагине;
• Про базу банков, и почему их 49, а не 50;
• Про логотипы банков;
• Про логотипы типов;
• Несколько моих вопросов к читателям;

В кластере Kubernetes нода может умереть или перезапуститься.

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

Однако вы можете заметить: когда нода падает, поды сломанной ноды на протяжении какого-то времени всё ещё запущены и получают запросы, которые уже не выполняются.

И по умолчанию это время, как мне кажется, слишком велико — его можно уменьшить. На него влияют несколько параметров, настраиваемых в Kubelet и Controller Manager.

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

Сразу оговорюсь, что данный текст — это не сухая выжимка основных идей с красивыми графиками и обилием технических терминов (такой текст называется научной статьей и я его обязательно напишу, но потом, когда нам заплатят призовые $20000, а то, не дай бог, начнутся разговоры про лицензию, авторские права и прочее.) (UPD: https://arxiv.org/abs/1706.06169). К моему сожалению, пока устаканиваются все детали, мы не можем поделиться кодом, который написали под эту задачу, так как хотим получить деньги. Как всё утрясётся — обязательно займемся этим вопросом. (UPD: https://github.com/ternaus/kaggle_dstl_submission)

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

Адаптация статьи REST WORST PRACTICES, © Jacob Kaplan-Moss. Статья написана применительно к Django, но информация будет актуальна для широкого круга специалистов.

Думаю что лучший способ понять как нужно делать, изучить как делать НЕ нужно. Представляю вашему вниманию вредные советы проектировщикам REST API.

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

Если вы как я долгое время считали, что JavaScript – это такой «игрушечный» язык на котором пишут анимашки для менюшек и падающие снежинки на форумах под новый год, а потом очнулись в 2016 году с мыслями WTF: react, flux redux, webpack, babel,… не отчаивайтесь. Вы не одиноки. Материалов по современному фронтенду в сети много, даже слишком много. Под катом еще одно альтернативное мнение о том, каково это учить JavaScript в 2016 году.

Мы уже три года делаем сервис «Кнопка». У нас отличные сотрудники, клёвый офис, приятные клиенты, милый кот и неплохая маржинальность. Нет, правда, мы привыкли думать, что мы молодцы. Недавно нам пришлось поменять эту привычку и научиться жить совсем в другом мире: где мы регулярно ошибаемся и на этих ошибках нужно учиться.

Источник фотографии

Все умеют считать, но не все умеют считать быстро. В этой статье мы подробно рассмотрим методы оптимизации count в PostgreSQL. Существуют приемы, которые могут позволить ускорить подсчет количества строк на порядки.

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

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

Мы проанализируем решения для каждой конкретной ситуации, а также сравним их скорость и потребление ресурсов. Разобрав ситуацию с централизованной БД, мы воспользуемся Citus, чтобы продемонстрировать параллельное выполнение count в распределенной базе данных.

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

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

Упрощенно задача выглядела так — нужно соединить микроконтроллер с мобильным приложением через интернет. Пример — нажимаем кнопку в приложении зажигается светодиод на микроконтроллере. Тушим светодиод на микроконтроллере и кнопка в приложении соответственно меняет статус.

Так как мы стартовали проект на кикстартере, перед запуском сервера в продакшене у нас уже была довольно большая база первых пользователей — 5000 человек. Наверное многие из Вас слышали про известный хабра эффект, который положил в прошлом многие веб ресурсы. Мы, конечно же, не хотели повторять эту участь. Поэтому это отразилось на подборе технического стека и архитектуре приложения.

Сразу после запуска вся наша архитектура выглядела так:



Это была 1 виртуалка от Digital Ocean за 80$ в мес (4 CPU, 8 GB RAM, 80 GB SSD). Взяли с запасом. Так как “а вдруг лоад пойдет?”. Тогда мы действительно думали, что, вот, запустимся и тысячи пользователей ринут на нас. Как оказалось — привлечь и заманить пользователей та еще задача и нагрузка на сервер — последнее о чем стоит думать. Из технологий на тот момент была лишь Java 8 и Netty с нашим собственным бинарным протоколом на ssl/tcp сокетах (да да, без БД, spring, hibernate, tomcat, websphere и прочих прелестей кровавого энтерпрайза).

Все пользовательские данные хранились просто в памяти и периодически сбрасывались в файлы:

try (BufferedWriter writer = Files.newBufferedWriter(fileTo, UTF_8)) {
  writer.write(user.toJson());
}

В данной статье я вкратце опишу процесс получения сертификата начинающего андроид разработчика. Разработкой под андроид я занимаюсь уже более 4-х лет, но до настоящего момента так и не удосужился обзавестись никаким соответствующим сертификатом, хотя парочкой сертификатов по Java я обзавелся. А сложилось так по одной простой причине — сертификаты андроид разработчиков выдавали какие угодно компании, кроме собственно компании разработчика этого самого Android. Вышеупомянутые Java сертификаты были выданы компанией Oracle, что делает их наличие хоть немного осмысленными.

И вот наконец свершилось — Google открыла свою программу сертификации андроид разработчиков. Но и тут не обошлось без ложки дегтя — пока доступен только сертификат начинающего андроид разработчика. Мне он в общем-то без надобности, но любопытство и тяга к коллекционированию подтолкнули меня к его получению. Полезность получения сертификатов как таковая является отличной темой для холивара. Я немного затрону этот вопрос в конце статьи, а пока перейду к описанию процесса.

В этой заметке я расскажу о нашей демонстрационной базе данных для PostgreSQL: почему она важна для нас и как может пригодиться вам, как устроена схема и какие данные в ней содержатся.

Сразу приведу ссылку на полное описание (там же написано, где взять демо-базу и как ее установить).