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

Расскажу, чему я учился у Кличко. Если вам этот рассказ пригодится, в любом виде – отлично. Программисты должны помогать друг другу.

Беседовал я как-то с техническим директором одного из крупнейших банков России. В какой-то момент речь у нас зашла о премировании сотрудников. Тогда я ему говорю, что у нас в компании есть премирование сотрудников за вовремя сделанные проекты и задачи. Тут он завис секунд на пять, долгое молчание, недоумение в глазах:
– Кхм… Так за это же программистам зарплату платят! – говорит он.
– Да, платят. Но если изучить статистику успешных проектов в IT, становится грустно и хочется платить премию за выполненные в срок задачи.

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

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

Подобные задания становятся УБИЙЦАМИ мотивации №1.

Лично я не хочу, чтобы мои ученики теряли мотивацию и сдавались на полпути. Поэтому я создал этот километровый список из 27 забавных идей для приложений, которые вы можете создать, пока обучаетесь использовать React на пару с Ruby on Rails.

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

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

Затрагиваемые в статье вопросы:

• Низкая компетенция разработчиков, и что с этим можно поделать?
• Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
• Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?

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

Здесь казалось бы для того что бы составить мнение о чем-то необходимо подходить к процессу с «холодной головой» («если уж и совершать глупость то по здравому размышлению»).

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

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

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



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

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

Стараясь оставаться в тренде и следуя веяниям моды веб разработки, последнее веб приложение я решил реализовать как набор микросервисов на ruby плюс “толстый” клиент на ember. Одна из первых проблем, вставших перед мной была связана с аутентификацией запросов. Если в классическом, монолитном, приложении все просто, используем куки, сессии, подключаем какой-нибудь devise, то тут все как в первый раз.

Архитектура

За базу я выбрал JWT — Json Web Token. Это открытый стандарт RFC 7519 для представления заявок (claims) между двумя участниками. Он представляет из себя структуру вида: Header.Payload.Signature, где заголовок и payload это запакованые в base64 json хэши. Здесь стоит обратить внимание на payload. Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея, лучше передавать там только ключ идентификатор, а сами данные хранить где-то в другом месте. В качестве хранилища данных можно использовать что угодно, но мне показалось, что redis будет оптимальным, тем более что он пригодится и для других задач. Еще один важный момент — каким ключем мы будем подписывать наш токен. Самый простой вариант использовать один shared key, но это явно не самый безопасный вариант. Коль скоро мы храним данные сессии в redis, ничто не мешает нам генерировать уникальный ключ для каждого токена и хранить его там же.

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

Здравствуйте, уважаемые читатели!

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

• высокая надежность хранения
• высокая доступность данных, то есть минимальное время простоя при авариях
• высокая скорость доступа и минимальные задержки
• низкая удельная стоимость хранения
• различные прикладные возможности: клонирование, снимки состояния и т.д.

Ни RAID-массивы, ни «железные» СХД не способны решить все перечисленные задачи одновременно. Именно поэтому все большее распространение в индустрии хостинга приобретает Software-defined storage. Одним из ярких представителей SDS является распределенное хранилище под названием Ceph.

Мы решили рассказать об этом замечательном продукте, который используется в CERN, 2GIS, Mail.ru и в нашем облачном хостинге.

Ранее мы уже рассказывали о дата-центре фотосервиса imgix, описывали детективную историю поиска проблем с SSD-дисками проекта Algolia, а сегодня представляем вашему вниманию обсуждение того, как команда стримингового сервиса SoundCloud перешла на использование микросервисов.

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

Содержание:

• Разработка через тестирование – что это?
• Три закона TDD
• Примеры применения
• Преимущества и недостатки
• Литература и ссылки

Разработка через тестирование – что это?

Разработка через тестирование (Test-driven development) — техника разработки программного обеспечения, которая определяет разработку через написание тестов. В сущности вам нужно выполнять три простых повторяющихся шага:
— Написать тест для новой функциональности, которую необходимо добавить;
— Написать код, который пройдет тест;
— Провести рефакторинг нового и старого кода.

Мартин Фаулер

В конце октября в Москве прошла наша первая конференция мобильных разработчиков #MBLTDev. 17 докладчиков из Англии, Германии, Голландии, Дании, России и США пришло послушать более 300 человек.

Мы будем постепенно выкладывать записи докладов с презентациями и начнем с доклада канадского блоггера Эша Фюрроу «Реактивное программирование на Swift». Помимо ведения блога, Эш является iOS-разработчиком онлайн галереи Artsy и автором нескольких книг про iOS-разработку.


Презентация

В своем докладе Эш познакомил аудиторию с основами фреймворка ReactiveCocoa, проиллюстрировав их примерами на Swift. Также, он рассказал о приложении, над которым он в данное время работает в Artsy с использованием этих инструментов. Приложение, что примечательно, с открытым исходным кодом и доступно на GitHub.

Каждый месяц Фонд развития интернет-инициатив проводит мероприятия для предпринимателей под названием «Бизнес-секреты». На этих встречах лидеры стартап-индустрии делятся со слушателями секретами увеличения прибыли проекта и дают советы по его продвижению. Такие мероприятия для их участников не только полезны, но и бесплатны – достаточно только зарегистрироваться и прийти на встречу в наш мультимедийный конференц-зал Сити Холл в БЦ Silver City.

В октябре на одном из таких мероприятий Артем Азевич, руководитель трекинга ФРИИ, рассказал о «дырах» стартапов или «узких местах», которые необходимо заделывать, чтобы в разы улучшить их бизнес-показатели. Данный материал на основе выступления, дополненный кейсами проектов, рассказывает об этапах развития IT-стартапа на ранней стадии и о самых распространенных проблемах предпринимателей, которые не дают им начать зарабатывать. Почему это происходит?

Ниже — вольный пересказ книги Running Lean, автор — Ash Maurya. Рейтинг Амазона — 4.8 из 5. Книга, насколько я знаю, на русский язык еще не переведена.

Здесь изложена суть книги в объеме меньшем 1% объема книги, по моей оценке. Все вопросы освещены так, как я их понял, что необязательно совпадает с тем, как их хотел донести автор.

Допускаю, что нарушаю чьи-то права: пересказ лицензии не требует, но иллюстрации взяты из книги. Автору я писал в попытке прояснить этот вопрос, но ответа не получил.

Блог автора кгиги: practicetrumpstheory.com.

Структура пересказа

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

В недавней статье на Хабре уже шла речь о том, как закупаться на Google Play в разделе Devices прямо из нашего захолустья. Тема бесспорно интересная: Nexus 7 пока в России и близлежащих странах вообще не водится, а Galaxy Nexus, скорее всего, просто обойдется вам значительно дороже, если, конечно, вы не живете в Москве или Питере. Проблема только в том, что рецепт оказался несколько нестабильный: лично меня Самая Добрая Корпорация небезосновательно заподозрила в подтасовке личных данных, а судя по комментариям – я такой оказался далеко не один.

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

Под катом новый рецепт и совсем чуть-чуть скриншотов.

Эта статья будет о моем интересном опыте А/В тестирования формы оформления заказа.

Вход:

• интернет магазин техники, Украина. Базируемся в Киеве, доставляем по всей стране;
• А/В тестирование проходило только для трафика с прайс агрегаторов;
• срок тестирования 3 недели.

Утверждение: хороша форма оформления заказа — это форма с двумя полями: имя и телефон.
И это утверждение верно лишь частично.

О торговле

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

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

После квартальных исследований, направленных на изучение поведения цен и рынка в целом, наряду со спросом и предложением, был выявлен третий фактор – «Фактор брокера».

Здравствуйте, меня зовут Сергей и я боюсь зомби.

Мне был 21 год, когда я устроился на свою первую работу. Предствьте себе, свой первый проект я написал на classic ASP. Это было классическое произведение быдлокодера:

— бизнес-логика? нет, не слышал
— в базе не было индексов
— ID генерился рандомно и проверялся селектом в таблице на уникальность
— монстроидальные ASP файлы, HTML вперемешку с VB Script