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


Вот так выглядит ленточное хранилище (наше было поменьше) и библиотечный робот (наш такой же). Китаец в комплект не входит.

Часть 1. Коробка

Помню, стояли последние дни ноября. Уже думая об окончании рабочего дня, я планировал свой вечер, когда вдруг мне сообщили, что в славном сибирском городе N у нашего заказчика сломалась ленточная библиотека. Запчасть сразу же отправили транспортной компанией, но вот уже 3 дня, как она все еще была в пути. Транспортная компания невнятно объяснялась и хмыкала в телефон, а заказчик стал не в шутку нервничать. Прогнозы были неопределенные, поэтому было принято решение везти еще одну запчасть своими силами на самолете. Сотрудник склада вручил мне габаритную коробку весом килограмм десять, обклеенную штрих-кодами и стикерами, и радостно хлопнул меня по плечу со словами: «Только не вздумай в багаж сдавать — помнут».

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

Вот уже много лет пользователей Nginx мучает один и тот же вопрос: «Как можно ограничить скорость в целом для IP адреса независимо от числа сессий (соединений)? Почему Nginx этого не умеет? Почему разработчики Nginx так упорно не хотят реализовать этот простой функционал?» И ответить мне им нечего, о чём думают разработчики Nginx — не понятно и известно, наверное, только господу богу.

Бороться с этим можно по разному, кто-то использует скрипты на подобие htb.init, кто-то пишет скрипты шейпинга самостоятельно и делится удачным опытом на Хабре, а некоторые и вовсе используют PHP для ограничения скорости отдачи файлов. Только представьте себе, каким будет оверхед и расход памяти, при использовании PHP в подобных целях.

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

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

4. Мастера на все руки

Взаимодействие между клиентом и сервером как правило устроено очень просто и опирается на довольно примитивный инструментарий. Это не создает проблем само по себе, но зачастую даже небольшое усложнение поставленной задачи плохо укладываться в привычные подходы, порождая не слишком изящные решения-заплатки. Многие задачи решаются в каждом новом проекте заново, бессистемно и независимо друг от друга. К подобным задачам относятся, например:

• Batch-запросы
• Передача даты в составе сложной структуры данных
• Обозначение кастомных типов данных
• Проброс round-trip данных, которые сервер должен вернуть в ответе
• Дополнение запроса и ответа метаданными
• Обработка ошибок, пришедших в ответе

Разработчики тратят немало времени, раз за разом создавая неказистые велосипеды на серверной стороне, после чего их приходится поддерживать еще и на стороне клиента.

jsonex представляет собой попытку объединить решение упомянутых выше и многих других задач в рамках простого единого подхода, основанного на концепции вычислимых данных (callable data).

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

• Секреты управления программистами
• Как стать менеджером в IT
• Черная книга менеджера
• Белая книжная полка менеджера
• Управленческие инструменты

Получить все книги бесплатно (нужна регистрация) можно вот здесь:

5 управленческих книг Стратоплана >>

Чуть ниже — об истории создания всех этих книг

Всем привет!

Друзья, не мне вам рассказывать, да и сами вы знаете о том, как делается backend для серверных/клиент-серверных приложений. В нашем идеальном мире всё начинается с проектирования архитектуры, затем выбираем площадку, затем прикидываем нужное количество машин, как виртуальных, так и нет. Затем происходит сам процесс поднятия архитектуры для разработки/тестирования. Всё готово? Ну поехали писать код, делать первый коммит, обновлять код на сервере из репозитория. Открыли консоль/браузер проверили и поехало. Пока всё просто, а что дальше?

^{Мыс Доброй Надежды}

С английским у меня беда. Дело в том, что учил я его по MS-DOS и Паскалю, а потом по фильмам. Поэтому читать и переводить в нашу сторону научился хорошо, а вот строить предложения на лету для разговора – нет. А оно сильно надо, потому что у Мосигры всё больше и больше партнёров в Европе. Думаю, у вас такие проблемы не возникают, но вот желание заправить трактор иногда появляется — и живой английский реально нужен почти каждому.


^{Мой заезд: Швейцария, Эмираты, Германия, Канада, Франция}

Поэтому я недолго думая отправился в Южную Африку. Быстрых по визе вариантов с тёплой погодой было три: Мальта (где среди учеников сплошь китайцы, а сам остров можно обойти за два дня), Дублин (с очень интересным акцентом) и Кейптаун (колония Великобритании). Поэтому – вниз, за экватор, и на самый край обитаемого мира. В Африку, к пушистым слонам и пингвинам, копающим норы.

Если названия «Rework» и «37signals» вам хорошо знакомы, то на вашей улице наступил маленький праздник — совсем недавно на русском языке вышла их новая книга «Remote: Office Not Required» (в русском издании — «Remote: Офис не обязателен»). Книга доступна как в печатном варианте, так и в электронной версии.

Компания 37signals — создатель фреймворка Ruby on Rails, нескольких инструментов для управления проектами (из которых известнее всего Basecamp) и нескольких книг-бестселлеров (Rework и Getting Real), посвященных принципам построения успешной компании-разработчика. Год назад была анонсирована их новая книга, посвященная преимуществам и организации удалённой работы — ее анонс проскакивал на Хабре. На полках западных магазинов Remote появилась осенью, поэтому многие уже успели прочитать ее на языке оригинала — в том числе и основатель Хабрахабра Денис Крючков, который дал ей краткую положительную оценку.

С тех пор 37signals успели переименоваться в Basecamp (с целью повысить узнаваемость компании, они назвались по имени своего самого успешного продукта), а на этой неделе «Remote: Офис не обязателен» наконец-то появилась в продаже на русском языке. На оригинал у меня времени не нашлось, поэтому, дождавшись солнечного утра субботы, я отправился в книжный магазин, и спустя пару часов погрузился в чтение в электричке. Опасений насчет русского издания не было никаких: за дело снова взялось издательство бизнес-литературы Манн-Иванов-Фербер, выпустившее у нас предыдущий бестселлер 37signals — Rework. На моей книжной полке эта книга давно занимает почетное место; вот и с Remote история повторилась — оригинальное оформление книги было полностью сохранено, замечательные иллюстрации снова на месте, качественный перевод прилагается — впрочем, от МИФ другого и не ожидалось.

Давно не видел статей о BitTorrentSync, и очень удивляюсь: ведь это такой полезный инструмент. Буквально на днях вышла новая версия*, и я решил рассказать, как применил это решение на работе.

Начало

Однажды в нашей компании наступил момент, когда встала необходимость обмениваться довольно тяжёлыми файлами — макетами продукции и упаковки (100-500 мегабайт) между офисами в Москве, Екатеринбурге и офисом в провинции Чжэцзян, КНР. Сложность была в катастрофически низкой скорости и надёжности связи РФ — Китай.

Когда я обратил внимание на проблему, царил полный разброд и шатание:

Сообществу Angular требуются свежие туториалы и учебники с простыми примерами на последних версиях библиотек. Правила, которые работали в Angular v0.X, уже не все действуют, в чём легко убедиться, а хочется разобрать что-то более сложное, чем фильтр из учебника на сайте и TODO-лист из примеров реализации (как, например, найденный для v1.0.3: jsfiddle.net/dakra/U3pVM ). Когда такие примеры покажутся слишком простыми, хочется посмотреть на развитие постановки задачи и приближенное к реальности приложение с некоторым оформлением стилей.

Предлагается вниманию пример приложения — работы с телефонной книгой в 2 списках: основного и «spam». Каждый из списков подвержен фильтрации (ну это — самое простое и встроенное в фреймворк), редактированию элементов, добавлению новых и удалению имеющихся. Одним кликом переносятся элементы из одного списка в другой, а подсветки элементов сделаны в стиле Bootstrap v.3.

Примерно раз в месяц приходят письма с несколькими сотнями получателей. За праздники их вообще собралась целая стопка. Чаще всего — это поздравления с праздниками или «прощальные письма» менеджеров рекламных агентств. Общий смысл: «Здравствуйте друзья, я ухожу на новое место работы, вот Вася, он за меня».

Единственный прогар – люди просто сливают всю свою базу клиентов. Ну, конечно, в прощальных письмах это может быть и намеренным, но…

В общем, я всегда нажимаю на «Ответить всем» и пишу вот так:



И дальше начинается веселье.

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

• Количеством транзакций порядка 5'000 — 10'000 в секунду
• Объемом примерно в 100ГБ (который бодро растёт)
• Примерно равным количеством операций на чтение/запись
• Преимущественно мелкими транзакциями

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

Я опишу некоторые проблемы, с которыми мы сталкиваемся, и применённые решения. Если кто-то сочтёт это полезным — ради Бога. Если кто-то поправит — я буду только рад обнаружить уязвимость в используемых подходах и увеличить эффективность работы БД. Описанное может быть применено без вмешательства в логику приложения, исключительно путём модификации схемы БД.

Введение

Я – пользователь бытовых погодных станций со стажем, и в этом скрыта двойная катастрофа. Во-первых, я уже настолько привык к тому, что погода внутри и вне дома мне известна, что отсутствие этой информации вводит меня в состояние когнитивного диссонанса. Во-вторых, с погодными станциями мне хронически не везет. Две из них сломались и, как в таких случаях говорят про всяческие индикаторные приборы, стали «показывать погоду», только с точностью до наоборот, показывали они что угодно, только не погоду. Из Штатов привез с собой третью, которая прослужила мне верой и правдой целый год, и я начал было потихоньку расслабляться, но тут у случайно забежавших (и давших нам с женой возможность временно возложить на их плечи заботу о сыне и выбежать из дома) родителей случился приступ принужденной заботы, в свою очередь, вызвавший острое желание помыть окна. Результат тщательного натирания окон – не только сверкающие окна, но и прыгнувший вниз датчик погодной станции. Этаж второй, так что датчик разбился бы вряд ли, но, как известно, непосредственно под окнами каждой многоэтажки есть невидимая пространственно-временная сингулярность. Не знаю, можно ли этот феномен описать в рамках Стандартной Модели, но то, что в основе сингулярности лежит принцип «что упало, то пропало», сомнений нет. Так что датчик я не нашел.
Естественно, в полный рост встала нужда менять девайс, но мысль о том, что ни одна из «бывших» не продержалась у меня дома больше года, настораживала. И тогда в голову забрела идея «а не сделать ли самому?».

Некоторое время назад я писал вводную статью о хуках (что это, зачем нужно, Hello world). Статья задумывалась простой, минималистичной и, вроде бы, такой и получилась. Единственный упрёк, который я услышал в комментариях — «Зачем же брать библиотеку Microsoft Detours, которая для коммерческого использования стоит 10 000$ ?». Замечание справедливое. В этой статье я приведу тот же пример с использованием другой библиотеки ценой примерно в 20 раз меньше (что уже вполне себе в рамках разумного) — madCodeHook.

Для лучшего понимания данной статьи рекомендуется сначала прочитать первую часть.

Семнадцать дней назад (19 января 2014 года) вышла новая версия (2.0.0) джаваскриптовой библиотеки Keypress, предназначенной для удобного программирования реакций браузера на события, поступающие от нажатий (и от отпусканий) клавиш на клавиатуре.

Опубликованный на Гитхабе список изменений позволяет уверенно огласить вот что: важнейшим из достоинств новой версии стала возможность ловить события не только во всём окне в целом, но и для одного или нескольких отдельных элементов DOM. Теперь и при программировании различающихся реакций у различных элементов на веб-страницах мы можем с удобством прибегнуть к библиотеке Keypress вместо тех её более ранних и более популярных аналогов (например, jQuery.Hotkeys), которые уступают Keypress по богатству возможностей.



Возможности же эти вот каковы:

• Реакция на нажатие и отпускание одной или нескольких клавиш. Поддерживаются синонимы кросс-платформенные (например, "meta" означает "cmd" или "ctrl" в зависимости от системы) и шифтовые (например, "@" означает сочетание Shift и двойки).
   
• Программируемые сочетания клавиш могут включать в себя не только классические модификаторы ("meta", "alt", "option", "ctrl", "shift", "cmd"), но и какие угодно другие клавиши. Например, программируя WASD-управление пошаговою бродилкою, нетрудно достигнуть того, чтобы нажатие и отпускание клавиши «W» означало шаг вперёд, но «W» и «D» совместно — шаг по диагонали вперёд+направо.
   
• Возможно указание сочетаний клавиш, состоящих не из одновременных, а из последовательных нажатий клавиш. Это такие сочетания, как код Конами, например.
   
• Специальные «считающие» комбинации позволяют программировать такие ситуации, в которых нажатие основной клавиши обнуляет некоторый счётчик, а каждое нажатие дополнительной клавиши (при удержании основной) увеличивает этот счётчик на единицу. David Mauro (автор Keypress) приводит в пример такое сочетание Tab+Space, при котором нажатие Tab тотчас же открывает первую вкладку в некотором наборе вкладок, а каждое нажатие на пробел (при удержании Tab) перебрасывает на следующую вкладку — на вторую, на третью, на четвёртую…

Для каждой одиночной клавиши (или для комбинации) возможны дополнительные настройки. Эти настройки позволяют при необходимости сделать вот что:

На одном из давних тренингов мы отрабатывали кейс “Сотрудник не присылает вовремя отчеты”. Кейс абсолютно не привязанный к реальной жизни — ведь такого же не бывает, чтобы люди не присылали вовремя отчеты, верно?

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

Моим собеседником оказался молодой человек, назовем его Егор, технический директор небольшой компании.

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

— Александр, как же так, почему Вы не присылаете мне отчеты?

Я стоял, думал-думал, чего сказать. И потом ляпнул первое, что пришло в голову:

— Егор, а чего ты хочешь, если ты такой хреновый менеджер?!

Каюсь, я тогда был не в курсе про тяжелые манипуляции. Зато их влияние смог ощутить на себе в полной мере. Егор покраснел, потом пошел пятнами:

— Что значит “хреновый менеджер”?!!! Это недопустимо — так разговаривать с руководством…

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

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

Добрый день, хабровчане. Сегодня я хотел бы рассказать о Location APIs в общем и о геозонах (geofences) в частности, которые были представлены на Google I/0 2013 (видео и презентация). Не смотря на то, что событие произошло более полугода назад, на хабре до сих пор нет вменяемой информации об этом (только одно упоминание). Постараюсь немного исправить ситуацию.

Не так давно в boost-1.53 появился целый новый раздел — lockfree реализующий неблокирующие очереди и стек.
Я последние несколько лет работал с так называемыми неблокируюшими алгоритмами (lock-free data structures), мы их сами писали, сами тестировали, сами использовали и втайне ими гордились. Естественно, у нас немедленно встал вопрос, переходить ли с самодельных библиотек на boost, и если переходить, то когда?
Вот тогда у меня и возникла в первый раз идея применить к boost::lockfree кое-какие из методик которыми мы испытывали собственный код. К счастью, сам алгоритм нам тестировать не придется и можно сосредоточиться на измерении производительности.
Я постараюсь сделать статью интересной для всех. Тем кто еще не сталкивался с подобными задачами будет полезно посмотреть на то что такие алгоритмы способны, а главное, где и как их стоит или не стоит использовать. Для тех кто имеет опыт разработки неблокирующих очередей возможно будет интересно сравнить данные количественных измерений. Я сам по крайней мере таких публикаций еще не видел.

О чем топик?

В этой статье я расскажу о реализациях разного функционала (преимущественно, на веб-сервисах) для обеспечения безопасности пользователей на примере «гигантов» современной IT индустрии. Данный материал будет полезен разработчикам, архитекторам, тим-лидам и менеджерам при постановке задач схожего функционала. Реализации в статье разработаны командами профессионалов, проверены временем и сотнями миллионами пользователей (а также большим количеством хакеров), хоть и никаких гарантий, что именно данный вариант реализации — абсолютно правильный и 100% безопасный, конечно же нет. Информация основана на личном анализе этих ресурсов.

Вас приветствуют разработчики статического анализатора кода PVS-Studio. Мы разработали новый программный продукт — CppCat. Разработан он так. Мы представили, что у нас нет PVS-Studio, но есть опыт в разработке инструментов статического анализа для языка Си/Си++. И мы с чистой головой разработали новый статический анализатор таким, каким бы хотели его видеть. Мы сделали инструмент простым и лёгким. И что многих обрадует, он будет стоить $250 за одну инсталляцию.