OAuth — популярный протокол, который позволяет социальным сервисам интегрироваться между собой и дает безопасный способ обмена персональной информацией. OAuth может связать между собой 2 сервиса, каждый из которых имеет свою пользовательскую базу — именно их я в данном случае называю «социальными». Когда начинаешь работать с OAuth, первое ощущение — что протокол весьма сложен и избыточен. В этой статье я попытаюсь объяснить основы OAuth человеческим языком.

Пример кросс-авторизации

Вернемся в 2005-й год и представим, что мы пишем социальную сеть. В ней имеется форма импорта контактов из адресной книги GMail. Что нужно для доступа к контактам GMail? Конечно, логин и пароль от ящика. Но если мы попросим ввести их на нашем сайте, пользователь заподозрит неладное. Где гарантия, что мы не сохраняем на сервере введенные пароли? Поэтому нам хочется, чтобы пароль вводился только на сайте GMail, и после этого доступ к контактам через API GMail предоставлялся нашей социальной сети (возможно, на время).

Менее чем за десять лет Google изменила мир. Каких перемен стоит ожидать в следующие десять лет? “Спросите Google”, поручил .net Гари Маршаллу. Он спросил, и кое-что разузнал…

Ниже находится перевод статьи Джонатана Снука (Jonathan Snook) о преимуществах и недостатках двух популярных PHP фреймворков CakePHP и CodeIgniter.

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

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

Тимоти управлял своим собственным стартапом в Кремниевой долине. Такая работа вместе с увлечением танцами не способствовали формированию атлетического телосложения. Его вес был 65 кг. В конце концов, ему надоело быть худым парнем, и он решил поэкспериментировать с изменением тела.
После анализа исследований, посвященных мышечной гипертрофии, он разработал свою программу тренировок. В итоге он прибавил 15 кг мышц и потерял больше килограмма жира. И все это за 28 дней!

До: 66кг После: 80кг

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

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

Стоит отметить, что Qantas — это единственная авиакомпания среди многих,
у которой не случилось еще ни одной авиакатастрофы.

(П — проблема, описанная пилотом)
(Р — решение, принятое инженерами)

П: Основное внутреннее левое колесо почти требует замены.
Р: Основное внутреннее левое колесо почти заменено.

П: Пробный полет нормальный, за исключением слишком жесткой
автоматической посадки.
Р: В данной модели не предусмотрена система автоматической посадки.

П: Что-то в кабине разболтано.
Р: Что-то в кабине подтянуто.

Итак. Отбрасываем сомнения. Ставим перед собой портрет Брина в рамочке. Запасаемся "Дошираком" на полгода вперед и начинаем стартапить. На какую тему? Плевать — миллиарды баксов зовут нас вперед. Тем, кто готов, но к чему — не знает, посвящено это пособие.

Все началось банально. С аутсорса. Точнее с того, что нам надоело им заниматься. Захотелось создать что-то свое. И всё необходимое у нас было: хорошая команда, деньги, офис, отработанные на том же аутсорсе технологии.

И вот, не далее как прошлой осенью, у меня родилась идея проекта. Идея, в общем-то, простая: социальный календарь событий (web2.0 афиша). Т.е. сервис для поиска, создания, обсуждения и пиара самых различных событий. Начиная от концерта Мадонны в Москве, и заканчивая секретной сходкой хабраюзеров с целью устроить очередную Хабрареволюцию (sic!).

Идея в общем-то светлая и правильная: помочь людям вырваться из цепких лап Сети и больше времени тратить на «живое» общение.

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

Сначала, я считал, что первая сложность — это не сложность, а вовсе даже преимущество (первыми заявить о себе — всегда почётно). Но, как показало время, это все-таки сложность. Ведь всегда можно сделать очередной развлекательный портал и у пользователей не возникнет вопросов что с ним делать и зачем он вообще нужен.

Очевидно, что наш проект к такому типу не относился. Действительно, идея проекта не совсем тривиальная, ведь это не блог, не форум с фотогалереей, и даже не социальная сеть (по очередному объединению одноклассников)

В том что существует мировой заговор (тотальный контроль, технологии зомбирования и управления) кровавой гебни (массонов, мировой закулисы, ЦРУ, АНБ, RAND corp., нужное подчеркнуть) против пользователей Сети нет никаких сомнений. Так каким же образом мы можем отстоять оставшиеся крохи своей свободы? Так вот, мы не одиноки: есть сильные и смелые люди, бросившие вызов диктату корпораций и правительств. Рассмотрим типичные вторжения в нашу свободу и способы самосохранения.

Оптимизация для социальных медиа (SMO) — то же самое по сути, что и поисковая оптимизация (SEO), но предназначена не для поисковых машин, а для социальных сетей и блогов, чтобы привлечь оттуда трафик к себе на сайт.

Минимально жизнеспособный продукт (minimum viable product — MVP) – не всегда уменьшенная/удешевленная версия законченного продукта. Определение точки, в которой можно выпустить MVP, с самого старта может сэкономить вам много времени, денег и ваших слез.

Дроны в Хартленде

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

Поводом для написания этого поста стало столкновение с очередным случаем вопиющего дибилизма на странице оплаты: каптча в форме ввода данных банковской карты на сайте Ассиста.

Я примерно 3 года работал в отрасли электронной коммерции и был напрямую связан с приемом платежей. То что написано ниже — капитанские советы для тех, кто еще не устал бегать по граблям или пока не понял чего хочет (а в действительности НЕ хочет) делать потенциальный клиент. (Фродеры в отличие от потенциальных клиентов любят заполнять огромные формы!) Если вы не согласны, приводите контр-примеры в комментариях. Я и другие читатели будут вам благодарны.

Известный дистрибутив для пентестинга BackTrack меняет название на Kali Linux и переезжает с Ubuntu на Debian. Kali Linux является передовым Linux дистрибутивом для проведения тестирования на проникновение и аудита безопасности.

Kali является полной повторной сборкой BackTrack Linux, полностью придерживаясь стандартов разработки Debian. Вся инфраструктура была пересмотрена, все инструменты были проанализированы и упакованы, также используется Git.

К хорошим постам «Код в стиле «дамп потока сознания»» и «Микро-рефакторинг, о котором мы так часто забываем».

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

Конечно, многие из вас обнаружат, что предлагаемые ниже ответы на эти вопросы весьма знакомы, но возьмите эту статью на заметку, так как кидать линк зачастую все же существенно комфортнее, чем распинаться в объяснениях и доказательствах очевидного.

Splunk — это система хранения и анализа логов. В двух словах принцип работы можно описать так: есть сервер Splunk, который хранит, индексирует и позволяет анализировать логи, и есть рабочие машины (сервера), которые эти логи создают и передают на сервер Splunk. Сервер Splunk в свою очередь может быть кластером из нескольких физических машин, между которыми распределяется хранение информации, и которые используются для ее обработки по технологии MapReduce. Способов передавать логи с рабочих машин очень много: через специальную программу forwarder, которая умеет быстро и эффективно отсылать изменения логов на сервер, через технологии типа NFS/SMB, или SNMP, можно самостоятельно отсылать данные в Splunk по TCP/IP (например, вместо того, чтобы писать в файл). Под Windows Splunk умеет брать данные из Windows Events, Performance Counters или Реестра.

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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:

Потому что на десять сеньоров по статистике девять тупят.

Навеяно очередной прочитанной книгой по управлению проектами. Это «Scrum и XP: заметки с передовой» Хенрика Книберга.

Скрам – это круто и красиво. Особенно красиво (и, на мой взгляд, реально применимо только в этом случае), когда решены все инфраструктурные проблемы, когда усилия всей компании (а не только скрам-команды) направлены на выпуск качественного продукта вовремя и когда задача программистов – именно разрабатывать ПО (т. е. никто не будет выдёргивать разработчика «из потока» для выполнения фантастически несвойственных ему задач).

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

В другой книге («Человеческий фактор…» Тома Демарко и Тимоти Листера) написано, что в идеальном рабочем помещении для программиста должно быть по окну на каждого сотрудника (чтобы он мог более вдохновенно заниматься разработкой и потому, что мы работаем, чтобы жить, а вовсе не наоборот). А как насчёт комнат на 10-20 человек с двумя окнами каждая (выходящими на промпейзаж, куда и смотреть-то лишний раз не захочется)?

Обсудим отечественные реалии, которые убивают теорию уважаемых Демарко и Листера и практику не менее уважаемого Книберга на корню. Начнем с соцпакета.

Недавно разговаривал с коллегой – руководителем PMO из соседней программерской фирмы (PMO – это Project Management Office, само его наличие говорит о том, что фирма придерживается современных взглядов на управление проектами; у нас вот – классическая функциональная структура, в лучшем случае – слабая матрица, нам PMO не светит). Так вот, они в ближайшее время будут завозить в офис и давать сотрудникам неограниченно потреблять всякие перекусы и питьё: чипсы/орешки, печенье/булки, соки и т. п. Как сказал коллега: «Предположим, нашему программисту ближе к вечеру захотелось перекусить. И у него возникает сложная дилемма: уйти поесть или поработать всё-таки еще пару часов. Плюшки в офисе склонят его в пользу поработать». А действительно, рассмотрим дилемму повнимательнее. Итак, таблица (цифры взяты «с потолка», но я в них почти уверен):

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

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.

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

Я хочу представить сообществу нашу реализацию RESTful архитектуры, без дублирования кода и с минимальными изменениями существующей бизнес-логики. Или Как добавить в проект API за пять минут?

За 6 месяцев из PDF—презентации получился продукт. С привлечением посевных инвестиций, драйвом командной работы, путешествием в Нью-Йорк, изучением английского права, сложностями, открытиями, разочарованиями и вдохновениями. Вот так создавался Manifest.

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.