Примечание: здесь рассказано о создании с нуля небольшого, прибыльного SaaS-сервиса и о доведении его до состояния, когда он стал приносить 1 000 долларов в месяц. Это не имеет никакого отношения к многомиллиардным стартапам единорогов; я просто описываю мой опыт такой работы. Речь идёт о простом, надёжном и прибыльном инструменте, который может сделать для себя любой человек. И последнее — этот веб-сервис был сделан для внутреннего рынка России, поэтому я перевёл всё на английский и в доллары для удобства. Но, с другой стороны, этот опыт является довольно универсальным и может быть применён везде (ссылка на сервис).

Всё началось с моего другого SaaS-сервиса с названием Postio, который я сделал, чтобы облегчить людям поиск и публикацию контента на их страницах и в их группах в социальных сетях. В рамках своей маркетинговой стратегии я приобрёл и опубликовал на своём блоге десяток статей по различным темам, ориентированных на аудиторию веб-сервиса, чтобы получить дополнительный трафик с поисковых систем.

Потом вдруг Postio начал получать относительно большой трафик от Google и Яндекс (русская поисковая система) с ключевыми словами, которые не имели ничего общего с самим Postio.


Аналитическая статистика Гугл по суточному трафику

Здесь-то и начинается фактическая история.

оригинал на xkcd

Топ-3 повседневных вопросов программиста:

• как сделать Х,
• почему работает так, а не эдак,
• как назвать переменную.

С третьим вопросом всё понятно — он неразрешим в принципе. С первыми двумя интереснее.

Чтобы получить ответы, программисты девяностых читали исходники и руководства. Программисты двухтысячных начали активно гуглить. А затем в 2008 появился Stack Overflow, и стал «внешней памятью» для разработчиков. Теперь на 95% вопросов есть готовый ответ: первая ссылка из гугла на Стек.

В статье «Данные снаружи и данные внутри» 2005 года Пэт Хелланд размышляет о данных в сервис-ориентированных архитектурах. В настоящее время СОА принято считать «микросервисной архитектурой», состоящей из «микросервисов». Хелланд показывает, что для инкапсулированных данных и данных, которыми обмениваются сервисы, требуются совершенно разные подходы. Переход от монолитной структуры к микросервисам более глубокий, чем просто рефакторинг кода в удобные, независимо развёртываемые модули:

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

Как выглядит реализация данного шаблона, и чем он опасен? Давайте разберемся.

На сегодняшний момент лишь мессенджеры (и, частично, игры) показывают стабильный рост аудитории на фоне падения всех статистических показателей классических мобильных приложений. WhatsApp заявляет об 1 миллиарде активных пользователях, Facebook Messenger – 900 миллионов, WeChat – 700 миллионов, а мессенджеры уже обогнали социальные сети по активной аудитории.

Для миллионов людей Facebook Messenger может стать первым местом, где они столкнутся с чатботами. И если люди начнут ими пользоваться, то это может стать новым Клондайком для разработчиков программного обеспечения — впервые после того, как компания Apple открыла App Store.

The Verge

В начале этого года мы в HeadHunter начали проект, нацеленный на автоматизацию различных HR-процессов у компаний-клиентов. Архитектурой этого проекта на фронте выбрали React-Redux стек.

За 9 месяцев он вырос из небольшого приложения для тестирования сотрудников в многомодульный проект, который сегодня называется “Оценка талантов”. По мере его роста мы сталкивались с вопросами:

• хранения стейта, его нормализации;
• построения масштабируемой архитектуры проекта, удобной иерархии — как в структуре, так и в бизнес-логике.

Это проявлялось в изменении подхода к построению компонентов, архитектуры редьюсеров.

Давайте поговорим о том, как мы развивали проект и какие решения принимали. Некоторые из них могут оказаться “холиварными”, а другие, напротив, “классикой” в построении большого проекта на redux. Надеюсь, что описанные ниже практики помогут вам при построении react-redux приложений, а живые примеры помогут разобраться, как работает тот или иной подход.

Раньше наш рабочий процесс прерывался из-за ряда неразрешенных вопросов:

• А кто из нас лучше всех играет в настольный футбол?
• С кем бы мне сейчас пойти поиграть?
• Кого надо уволить, потому что он не работает а только играет?

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

Ясной инструкции по сборке webpack для продакшена я не нашел. Поэтому решил написать эту статью. Надеюсь, пригодится.
Существует множество сборщиков скриптов. Я выбрал для себя Webpack по таким критериям:

• Гибкость настройки
• Большое количество плагинов и лоадеров
• Lazy loading
• Использование es6 и es7 синтаксиса с помощью babel-loader

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

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

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

Бывает, что проведёшь день на работе, вроде ничего не сделал, а все равно устал. Виной этому, как правило, рутина. Куча мелких срочных, иногда не очень срочных, но все равно важных, поручений и повседневных обязанностей. Из-за этих дел не успеваешь делать какие-то другие, более важные вещи. Знакомая ситуация?

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

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

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

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

Мысли Криса Койера

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

От переводчика

Всем привет, с вами Максим Иванов, и сегодня мы поговорим на довольно острую тему в сфере веб-разработки. Как утверждает Крис Койер, frontend-разработчик должен разбираться в очень многих вещах, о которых не все даже и задумываются. Конечно, мы должны понимать, что frontend-разработчик не главный в процессе разработки любого онлайн-сервиса или ПО в целом. На ту же позицию frontend-разработчика вы найдете больше откликов на вакансию, чем на позицию backend-разработчиком. Но почему же тогда Крис Койер считает, что работать frontend-разработчиком сложнее, ибо ты должен специализироваться во всем. Конечно, ситуаций в жизни очень много, разные компании по-разному используют своих специалистов, но в чем наверняка должен разбираться frontend-разработчик? Об этом мы сегодня и поговорим. Жду комментариев на эту тему, а сейчас приступим.

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

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

Здравствуйте, меня зовут Дмитрий Карловский и я… многозадачный человек. В смысле у меня много задач и мало времени, чтобы их все уже, наконец, закончить. Отчасти это и к лучшему — всегда есть чем заняться. С другой стороны — пока ты разрываешься между проектами, мир катится куда-то не туда и некому забраться на броневик и призвать толпу остановиться и немного подумать. А вопрос-то серьёзный — долгое время мир JS был погружён в ад обратных звонков и с ними не только не боролись — их боготворили. Потом он чуть менее чем полностью погряз в обещаниях. Сейчас к ним с разных сторон усиленно вставляют подпорки разной степени кривизны. А света в конце тоннеля всё не видать. Но обо всём по порядку...

Теория многозадачности

Сперва определимся с терминами. В процессе работы, приложение выполняет различные задачи. Например, "скачать файл с удалённого сервера" или "обработать запрос пользователя".

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

Запустить подзадачу мы можем синхронно, и тогда текущая задача заблокируется в ожидании завершения подзадачи. А можем запустить асинхронно, и тогда текущая задача продолжит своё выполнение не дожидаясь завершения подзадачи.

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

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

С такими фреймворками как Backbone, было принято синхронизировать сами данные и представление данных – для этого приходилось вручную подписываться на нужные события dom. Такой способ был подвержен ошибкам и вынуждал использовать слишком много типового кода. Пришел Angular и исправил это с помощью автоматизированного двустороннего биндинга.

Но сейчас все движется в другом направлении.

Отображение списка (множества) элементов на странице — это стандартная задача для практически любого web-приложения. В этом посте я хотел бы поделиться некоторыми советами по повышению производительности.

Для тестового примера я создам небольшое приложение, которое рисует множество «целей» (кругов) на элементе canvas. Я буду использовать redux как хранилище данных, но эти советы подойдут и для многих других способов хранения состояния.
Так же эти оптимизации можно применять с react-redux, но для простоты описания я не буду использовать эту библиотеку.

Данные советы могут повысить производительность приложения в 20 раз.

Кент Бек — разработчик программного обеспечения, создатель таких методологий разработки ПО как экстремальное программирование (XP) и разработка через тестирование (TDD); в данный момент работает на Facebook. Вашему вниманию предлагается перевод набросков идей о том, как можно было бы сделать свою работу эффективнее. Разделение программистов на мастеров и подмастерьев, используемое на протяжении статьи, взято Кентом Беком из книги «Программист-прагматик» Эндрю Ханта и Дэвида Томаса.

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

Ниже представлены способы, при помощи которых эффективные программисты каждый день выжимают максимум из своих драгоценных 3e9 секунд на нашей планете.

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

Flexbox является стандартом CSS, оптимизированным для проектирования пользовательских интерфейсов. Используя различные свойства Flexbox мы можем построить нашу страницу из небольших блоков, которые затем с легкостью сможем перемещать и изменять размеры, как нам угодно. Адаптивные веб-сайты и приложения пользуются огромным спросом в нынешней веб-индустрии.

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

Обработка ошибок в JavaScript — дело рискованное. Если вы верите в закон Мёрфи, то прекрасно знаете: если что-то может пойти не так, именно это и случится! В этой статье мы рассмотрим подводные камни и правильные подходы в сфере обработки ошибок в JS. А напоследок поговорим об асинхронном коде и Ajax.

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

Все примеры будут рассмотрены применительно к клиентскому JavaScript. В основу повествования легли идеи, озвученные в статье «Исключительная обработка событий в JavaScript». Название можно перефразировать так: «При возникновении исключения JS проверяет наличие обработчика в стеке вызовов». Если вы незнакомы с базовыми понятиями, то рекомендую сначала прочитать ту статью. Здесь же мы будем рассматривать вопрос глубже, не ограничиваясь простыми потребностями в обработке исключений. Так что когда в следующий раз вам опять попадётся блок try...catch, то вы уже подойдёте к нему с оглядкой.