Психология — интересная и иногда полезная наука. Многочисленные исследования показывают, что задержка в отображении веб-страницы дольше 300 мс заставляет пользователя отвлечься от веб-ресурса и задуматься: «что за хрень?». Поэтому УСКОРИВ веб-проект до психологически невоспринимаемых значений, можно ПРОСТО удерживать пользователей дольше. И именно поэтому бизнес готов тратиться на скорость: $80М — чтобы уменьшить latenсy всего на 1 мс.



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

GPON шагает по Москве. Распространяются и связанные с ним проблемы. В данной заметке я хочу поделиться опытом по лечению несовместимости МГТСовксого роутера с имеющимся телефонным аппаратом, проявляющуюся в случайных ошибках при наборе номера.

Протокол безопасной передачи данных SSL (Secure Sockets Layer) помимо обеспечения безопасной передачи данных так же позволяет реализовать авторизацию клиентов при помощи клиентских SSL сертификатов. Данная статья является практическим руководством по реализации данного вида авторизации в мобильных приложениях на IOS и Android.

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

Процесс авторизации выглядит следующим образом. При переходе клиента в закрытую область сервер запрашивает у клиента сертификат, если проверка прошла успешно то клиент получает доступ к закрытому контенту в ином случае клиент может получить ошибку “No required SSL certificate was sent”.

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

Как вообще становятся менеджерами по продукту? Кто этот человек на самом деле? Чем именно он занимается целыми днями, из-за чего переживает? Как, в конце концов, строятся его взаимоотношения с продуктом, коллегами, пользователями и объективной реальностью? Мы перевели для вас статью об этом.

Перевод статьи выполнен компанией-локализатором Alconost.

Введение

При работе с требованиями возможно применение различных методов их организации: от метода полного хаоса, до интеграции требований с программным кодом (статья Пять уровней зрелости требований). Постепенно улучшая работу с требованиями, обычно, в процесс начинают внедрять различные новые методологии и инструменты. Одним из классов инструментов, призванных упростить работу с требованиями, являются специально обученные «зверьки»: Системы Управления Требованиями (СУТ). Основными возможностями таких систем являются:

• Создание более простой, чем целый документ, единицы управления проектом (требование). Прочитать и подтвердить одно требование намного проще, чем согласовывать целое Техническое задание.
• Указание связей между требованиями. Такая возможность позволяет отслеживать изменения в связанных требованиях. Т.е. если что-то изменилось, то далее система может выделять все элементы, связанные с измененным, как подозреваемые на изменение.
• Выбор представления набора взаимосвязанных требований. При большом количестве требований иногда необходимо представить всю картину их взаимосвязи. Кому-то удобнее просмотреть эту информацию в виде таблицы (матрицы трассировки), кому-то в виде иерархического дерева, кому-то в виде сетевых графиков (статья Системы управления требованиями: что и зачем?).

Среди данных программ есть известные «Монстро-звери», такие как: IBM Rational DOORS, Borland Caliber, Polarion Requirements и др. с большим количеством функциональных возможностей. Такие системы, как правило, являются хорошо зарекомендовавшими себя, но дорогостоящими. Однако среди данного перечня есть маленькие, бесплатные, малоизвестные, но очень полезные «зверьки» типа Axiom.

По поручению известного автора Дмитрия Ландэ (например, «Поиск знаний в Internet», Интернетика. Навигация в сложных сетях: модели и алгоритмы) публикую одну из последних его работ.

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

Введение

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

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



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

Сейчас же я ожидаю гораздо более сильный по эмоциям шквал комментариев и сравнений меня с различными персонажами, вплоть до Геббельса. Надеюсь, все таки до этого не дойдет. Итак, «Фирменные стандарты» ИТ компании.

Как-то один из персонажей популярного сериала заявил «Все врут!». И это отчасти правда. И что уж 100% правда, что все лажают. Каждый может вспомнить, когда наши сотрудники не выполнили взятые на себя обязательства, сорвали сроки, что-то сделали — но совсем не то, а иногда лучше бы вообще не проявляли инициативу. К сожалению, лажают не только сотрудники, но и руководители. Самое печальное в этом то, что работают далеко не дураки, но бывают такие глупые epic fail, что и говорить не хочется.



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

Сколько времени уйдет у проектировщика на отрисовку прототипа интерфейса?

Мы накопили кое-какую статистику для типовых проектов – в основном в сфере электронной коммерции. И хотим ею поделиться.

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

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

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

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

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

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


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 (опционально)
    Если указать этот необязательный параметр, правила так же применятся ко всем поддоменам.

Привет Хабр!

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

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

В предыдущих своих заметках я описал основу, на которой строятся lock-free структуры данных, и базовые алгоритмы управления временем жизни элементов lock-free структур данных. Это была прелюдия к описанию собственно lock-free контейнеров. Но далее я столкнулся с проблемой: как построить дальнейший рассказ? Просто описывать известные мне алгоритмы? Это довольно скучно: много [псевдо-]кода, обилие деталей, важных, конечно, но весьма специфических. В конце концов, это есть в опубликованных работах, на которые я даю ссылки, и в гораздо более подробном и строгом изложении. Мне же хотелось рассказать интересно об интересных вещах, показать пути развития подходов к конструированию конкурентных контейнеров.
Хорошо, — подумал я, — тогда метод изложения должен быть такой: берем какой-то тип контейнера — очередь, map, hash map, — и делаем обзор известных на сегодняшний день оригинальных алгоритмов для этого типа контейнера. С чего начать? И тут я вспомнил о самой простой структуре данных — о стеке.

В этом посте я изложу свои мысли о голосованиях с точки зрения информационной безопасности… В первую очередь топик направлен на IT специалистов, которым хочется иметь стройную, понятную им, картину того, что такое честное голосование. Описанное применимо к выборам модератора, к голосованию жюри при вручении премий, к референдумам, к президентским «гонкам» и т.д. В подобных рассуждениях правильнее везде использовать слово «голосование», но для краткости и для борьбы с тавтологией я буду иногда писать «выборы».
Ниже мы взглянем на выборы по-итэшному, выделим основные принципы, цели, этапы, а также поговорим об уязвимостях систем голосований и об атаках на них.
Другими словами, выборы будем рассматривать как игру с определёнными правилами и ролями. Будем рассматривать также некоторую систему (программно-аппаратно-организационный комплекс) для проведения этой игры и продумаем защиту от читеров.
Замечу, что статья не про политику. Желающим обсудить что-нибудь политическое в контексте этой статьи настоятельно рекомендую заниматься этим не в комментариях, а где-нибудь ещё.

В прошлый раз мы написали довольно популярную статью: «Серьезное проектирование серьезного магазина. Часть 1. Исследования», эта статья её логическое продолжение. В этой статье и в последующих мы опишем почти 60 функциональных модулей топовых интернет-магазинов мира, а также подробно разберем интерфейс многих страниц.

На Хабре не раз поднимался вопрос автодополнения адресов в форме (раз, два, три).

Но вот и перед мной появилась задача реализовать такое автодополнение для небольшого интернет магазина. Критерии были такие:

• Автодополнение адресов только Москвы
• Автодополнение адреса одной строкой
• Решение должно быть бесплатно (лимит запросов не менее 1000 в сутки)
• Возможность подключить без дополнительных JS библиотек. (Я использую AngularJS Bootstrap-UI, в котором есть директива Typeahead, реализующая автодополнение формы)
• Стопроцентный uptime не обязателен

Но какой источник данных выбрать? Я выбрал целых четыре, и решил их сравнить: в одном углу ринга заморские Google Geocode и Google Autococomplete, а в другом отечественные КЛАДР в облаке и DaData подсказки.

DISCLAIMER: Автор никак не причастен к разработчикам ни одного из представленных сервисов.

Привет. Если Вы хотя бы раз сталкивались с задачей создания системы ключевых показателей эффективности (KPI) для сотрудников или проектов, то скорее всего согласитесь, что задача эта не из легких. Решения «в лоб» здесь не работают, многие очевидные показатели на проверку оказываются неинформативными, дают искаженное представление о ситуации или могут быть легко искажены сотрудниками.
Что бы сократить драгоценное время, сохранить нервные клетки здоровыми и дать «вдохновение», предлагаю ознакомится со списком популярных KPI для IT. Возможно некоторые из них помогут с решением вашей задачи.

Однажды, скучая на работе в ожидании решения далекого европейского руководства о выборе ПО для управления бизнес-процессами, мне пришла в голову мысль создать Скрипт. Скрипт должен был на основе модели бизнес-процесса анимировать его состояние в разные моменты времени и собрать результирующие данные, на основе которых можно принимать решения об эффективности планируемых изменений в деятельности организации. Так как под рукой на моей рабочей станции был IDE только в виде Блокнота, а корпоративной средой выполнения IE, пришлось писать Скрипт на вышедшем недавно jQuery. Так зарождался Сервис bpsimulator.com.

Сервис имитационного моделирования бизнес-процессов

В последнее время появилось множество устройств, использующих мобильный интернет. Это и системы охранной сигнализации, и автоматика, и автомобильные трекеры, и навигаторы с пробками. Все эти устройства потребляют мобильный интернет в очень маленьких количествах и нерегулярно. К примеру, у меня есть GSM-сигнализация, отправляющая по GPRS фото грабителя и не умеющая отправлять фото по запросу. Другой пример: автомобильный трекер отправляет несколько байт каждые 30 секунд во время движения автомобиля. Безлимитные тарифы для таких устройств совершенно не нужны. В обычных тарифах всех операторов мобильный интернет стоит около 10 рублей за мегабайт с округлением до 100 килобайт, поэтому та же работа автомобильного трекера обойдётся весьма недёшево.



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