Более 50 лет назад автор популярных статей о математике в журнале Scientific American Мартин Гарднер предложил читателям задачу: «Можете ли вы разместить семь сигарет таким образом, чтобы каждая из них соприкасалась со всеми остальными?»

Каждый день грузовики, нагруженные документами, заезжают в бывшую известняковую шахту возле городка Бойерс, штат Пенсильвания. Здесь, на глубине 70 метров под землёй, организован крупнейший центр по обработке пенсионных документов госслужащих США. Более 600 сотрудников вручную перебирают документы, вводят данные в компьютер и распечатывают, носят бумаги из одного хранилища в другое, сверяют цифры: процедура практически не изменилась с 1977 года.

Всем привет!
Хотелось бы рассказать вам историю создания одного простенького развлекательного сервиса по записи gif’ок с веб-камеры при помощи HTML5 и JS. О том как решение на коленке на базе опенсорсных решений в одночасье произвело пусть хоть и маленький, но всплеск популярности волны от которого уже на протяжении полугода приносят небольшое количество посетителей которым полезен этот сервис.

А началось все просто

В конце лета обычным рабочим днем бороздя просторы GitHub я наткнулся на довольно интересный скрипт (facetogif) на нативном JS и HTML5 позволяющий записывать ролики с веб-камеры в gif-анимацию. Была приложена даже рабочая демка заливающая готовые ролики на сервис imgur или позволяющая сохранить их сразу на жестком диске.
Эта идея показалась мне очень интересной и я решил с небольшими переделками реализовать ее в виде самостоятельного сервиса.
Сказано — сделано. В тот же вечер я форкнул репозиторий, зарегистрировал домен «вгиф.рф», поднял VPS (самый дешевый тариф за 5$) на DigitalOcean и написал простейший скрипт на php складирующий ролики прямо там на сервере.
Для экономии ресурсов на сервер установил только Nginx и PHP-FPM.

Это руководство для WPF-разработчиков, стремящихся добиться максимально чёткой картинки в своих приложениях. Графическая система WPF до мозга костей векторная, но конечным результатом её работы по-прежнему является растр. Если не уделить этому факту должного внимания, можно столкнуться с различными сортами «мыла» — паразитными артефактами растеризации. В такой ситуации важно не терять присутствия духа, причины их возникновения вполне рациональны, а методы борьбы достаточно просты и эффективны.

Ещё в 2010 году Леонид Каганов (как известно — большой затейник) поделился с читателями своего блога идеей кормушки для птиц с веб-камерой и досыпанием зерна путем отправки платных SMS. Идея мне понравилась. И вот, прошло 4 года, наступили новогодние праздники 2014, я достал из стола завалявшиеся arduino uno, роутер tp-link 3020 и вместе с bitl (ака админом городского сайта) приступил к реализации проекта.


Под катом много фото.

История: Эта статья впервые появилась в журнале Better Software в марте 2006. Она была переведена на несколько языков.

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

Чем больше я пользовался TDD, тем больше я понимал, что не столько оттачиваю своё мастерство, достигая новых его вершин, сколько то, что это было движение в слепую. Я помню, как мне все чаще приходила мысль: «Эх, вот бы мне кто-нибудь сказал это раньше!», чем мысль: «Отлично, дорога ясна». Я решил, что нужно найти способ обучать TDD, показывающий, как верно работать с ним сразу и без ошибок.

И этот способ — это программирование через поведение. Оно выросло из выработанных agile практик и призвано сделать их доступнее и эффективнее для команд, незнакомых с ними. Со временем, BDD стало включать в себя agile анализ и автоматическое приемочное (прим. acceptance) тестирование.

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average. Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

Внимание к мелочам рождает совершенство,
а вот совершенство уже не мелочь.

Микеланджело Буонарроти


C 2012 года администраторам веб-ресурсов стала доступна новая технология HTTP Strict Transport Security (HSTS) — механизм, активирующий форсированное защищённое соединение по HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение, вместо использования HTTP. Механизм использует особый заголовок HTTP Strict-Transport-Security, для переключения пользователя, зашедшего по HTTP, на HTTPS-сервер [1].
HSTS направлен на закрытие следующих уязвимостей к атакам:

Пользователь помещает в закладки или набирает в адресной строке http://example.com/ и становится жертвой атаки «man-in-the-middle»	HSTS автоматически преобразует HTTP-запросы в HTTPS для целевого домена
Веб-приложение, предполагаемое к использованию строго по HTTPS, по небрежности содержит HTTP-ссылки или отдает контент по HTTP	HSTS автоматически преобразует HTTP-запросы в HTTPS для целевого домена
Атакующий «man-in-the-middle» пытается перехватить трафик жертвы используя поддельный сертификат в надежде, что пользователь не обратит внимания на сообщение о невалидном сертификате	HSTS не даст пользователю пройти дальше сообщения о проблемах с сертификатом

Включается данная технология проще простого, необходимо возвращать пользователю HTTP-заголовок «Strict-Transport-Security» в тот момент, когда он заходит на сайт по HTTPS:

Strict-Transport-Security: max-age=expireTime [; includeSubdomains]

expireTime
    Время в секундах, на которое браузер должен запомнить, что данный сайт должен посещаться исключительно по HTTPS. includeSubdomains (опционально)
    Если указать этот необязательный параметр, правила так же применятся ко всем поддоменам.

Пост — резюме

Думаю, начать стоит с того, что в последнее время все больше заказчиков обращаются не только за тестированием на проникновение, но и за проверкой устойчивости их сервисов к атакам на отказ в обслуживании, чаще всего — веб-сайтов. И на нашей практике пока не было ни одного случая, чтобы реальный работающий сайт (не заранее подготовленная площадка) не вышел из строя, в т.ч. находящийся под разными защитными системами. И этот пост — резюмирование текущего опыта (D)DoS тестирования разными методами совершенно разных инфраструктур (от банков до типичных корпоративных сайтов).

На днях в Сеть утекла весьма интересная информация, полученная так называемой «Сирийской Электронной Армией» (Syrian Electronic Army). Насколько можно судить по документам, корпорация Microsoft, чьи счета попали в руки взломщиков, получает от ФБР деньги за выполнение каждого официального запроса по предоставлению информации конкретного пользователя.

При этом за разные запросы ФБР платит 50-200 долларов за запрос, а общая сумма средств, получаемых корпорацией за подобную работу, достигает сотен тысяч долларов в месяц. И да, еще раз подчеркну, что деньги перечисляются за выполнение официального запроса властей, тут никакого криминала, все вроде как легально.

Рядовые программисты обычно всё это прекрасно знают. А вот менеджерский состав нередко считает, что совершенно не обязательно разбираться в игровой экономике, клиент-серверной архитектуре и психологии игрового комьюнити. Ведь есть же крутая команда спецов, которые обо всём позаботятся.
Итог очевиден: трудно вспомнить хотя бы один крупный MMO-проект, выпущенный за последние два года, который избежал бы стандартного набора граблей. Такое ощущение, что MMO-индустрия не способна учиться на своих ошибках.
Итак, список вопросов, ответы на которые должен знать каждый, от топ-менеджера до работника техподдержки крупного MMO-проекта.

Привет Хабр!

Изначально хотел назвать статью «HTML по ГОСТ`у», но потом выяснилось что у большинства программистов не было предмета «Метрология и стандартизация» и о «стандартизации», «сертификации», «унификации» не все слышали.

В i-Free я много занимаюсь разработкой веб-приложений. А поскольку их много, они разные и работают в разных условиях, то само собой приходится задумываться о стандартизации. Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/), в котором разработчики решили создать идеальный шаблон странички. Он мне очень нравился, и все свои проекты я начинал именно с него. Но, исправляя баг за багом, делая все новые и новые приложения, я пришел к выводу, что многого в нем не хватает. В этой статье я хотел бы рассказать о том, что обычно пропускают при написание страничек и веб-приложений и показать, чем и зачем я прокачал свой шаблон пустой странички.

В результате профилирования моей софтины я сделал вывод о необходимости оптимизации функции сравнения буферов.
Т.к. CLR не предоставляет стандартного способа сравнить два куска памяти, то функция была написан на скорую руку самостоятельно (лишь бы работало).
Погуглив по фразе «Best Way to Compare Byte Arrays in .Net», я пришёл в замешательство: в абсолютном большинстве случаев люди предлагали использовать либо LINQ, либо Enumerable.SequenceEqual(), что практически одно и тоже. Даже на StackOverflow это был самый популярный ответ. Т.е. катастрофически популярно заблуждение вида:

«Compiler\run-time environment will optimize your loop so you don't need to worry about performance.» Отсюда.

Именно оно впервые навело меня на мысль написать этот пост.
Я провёл сравнительное тестирование пяти способов сравнения буферов, доступных из C#, и на основании результатов тестирования дал рекомендации в выборе способа.
Кроме того, я декомпилировал некоторые функции, и проанализировал код, генерируемый JIT-компилятором для конфигурации x86, а так же сравнил машинный код, генерируемый JIT-компилятором, с машинным кодом функции CRT аналогичного назначения.

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

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

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

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

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



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

Один из участников проекта OpenPandora провёл реверс-инжиниринг игры StarCraft и портировал её на ARM-платформу. Ему удалось сделать это, несмотря на отсутствие исходного кода в открытом доступе.

В репозитории выложен перекомпилированный бинарник, для установки которого на игровую приставку «Пандора» нужно еще скопировать несколько файлов с ПК-версии игры.

Данный пост является продолжением применения lua в nginx.

Там обсуждалось кеширование в памяти, а тут lua будет использоваться для фильтрации входящих запросов в качестве этакого фаервола на nginx-балансере. Нечто подобное было у 2GIS. У нас свой велосипед :) В котором разделяем динамику и статику, стараемся учесть NAT и белый список. И, конечно же, всегда можно навернуть еще специфичной логики, что не выйдет при использовании готовых модулей.
Данная схема сейчас спокойно и ненапряжно (практически не сказывается на использовании cpu) обрабатывает порядка 1200 запросов/сек. На предельные величины не тестировалось. Пожалуй, к счастью :)

Продолжая тему использования связки Nginx + Lua решил поделиться небольшой инструкцией подсчета загрузки статических данных и учетом всего этого в Google Analytics.

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

В этом посте nginx используется как «горячий кеш» неких постоянно пополняемых данных, запрашиваемых клиентами по интервалу с опциональным группированием (некий аналог BETWEEN и GROUP BY/AGGREGATE из SQL). Подгрузка данных в кеш осуществляется самим же lua+nginx из Redis. Исходные данные в Redis складываются ежесекундно, а клиенты хотят их от сих до сих (интервал в секундах, минутах, часах...) с агрегацией по N (1<=N<=3600) секунд, отсортированные по дате и в json формате.
С хорошим hitrate на имеющейся машине получается обеспечить 110-130к «хотелок» в секунду, правда с плохим — только 20-30к. Что, в общем-то, тоже приемлемо для нас на одной инстанции nginx.