На различных Q&A-сайтах и форумах, связанных с разработкой, я провёл времени больше, чем хотелось бы признавать. Там я ответил на тысячи вопросов. Как правило, вопросы остаются в границах таких форумов. Но после того, как вопросы начали сыпаться на мой личный почтовый ящик, я подумал, что надо написать об этом.

Эти электронные письма и сообщения обычно поступают от людей, с которыми я никогда раньше не общался — все они просто знают, что я «отвечаю на вопросы или решаю проблемы». Всё обычно выглядит примерно так:

• Я написал вопрос по ссылке {здесь}. Могли бы вы исправить ошибку?
• Привет, пожалуйста, помогите здесь {ссылка}.
• У меня есть серьёзное домашнее задание со сроком сдачи сегодня в 5 вечера, и мне с ним не справиться. Могли бы вы скачать его здесь {ссылка} и сделать так, чтобы к тому времени оно работало?

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

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

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

Джефф Этвуд, возможно, самый читаемый программист-блоггер, опубликовал пост против использования памяти ECC. Как я понимаю, его доводы такие:

1. В Google не использовали ECC, когда собирали свои серверы в 1999 году.
2. Большинство ошибок ОЗУ — это ошибки систематические, а не случайные.
3. Ошибки ОЗУ возникают редко, потому что аппаратное обеспечение улучшилось.
4. Если бы память ECC имела на самом деле важное значение, то она использовались бы везде, а не только в серверах. Плата за такого рода опциональный материал явно слишком сомнительна.

Давайте рассмотрим эти аргументы один за другим:

Если вы желаете что-то сделать, то есть два способа этого достичь.

Первый, более распространённый и в значительной мере неправильный вариант — попытаться мотивировать себя.

Второй, весьма непопулярный, но абсолютно правильный выбор — воспитание дисциплины.

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

В чём же разница?

Это реальная история, она — не только про Google. Я нередко получаю письма от рекрутёров Amazon, Facebook, а также небольших стартапов Кремниевой долины. Они как-то находят меня — наиболее вероятно через этот блог, через мои книги или через аккаунт на GitHub. Они всегда начинают с фразы: «Ваш профиль нас сильно впечатлил», — а заканчивают: «Давайте назначим собеседование». Я всегда отвечаю одинаково, а они всегда после этого исчезают, возвращаясь нередко через несколько месяцев под другим именем. Попробую здесь объяснить мои соображения. Возможно, вы будете делать то же, и мы сможем изменить ситуацию.


«Охотник на оленей» (1978), режиссёр Майкл Чимино

Эксперименты — одна из центральных функций научного подразделения сайта потокового видео Twitch. Мы работаем в тесном контакте с менеджерами по продукции, чтобы тестировать новые идеи и функции. В прошлом мы использовали собственные инструменты для проведения А/В-экспериментов в сети и на наших мобильных приложениях. Недавно мы попробовали новый подход для проведения экспериментов на нашем приложении для Android, используя функцию поэтапного развёртывания из Google Play.

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

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

Обратная связь «магазин/наём -> оценка -> вознаграждение» стала просто неотъемлемой частью некоторых систем. Многие интерактивные торговые площадки включают эти операции обратной связи в рейтинги, которые затем становятся оценкой, влияющей на перспективы оцениваемой персоны.

И вот здесь-то и начинаются проблемы.

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

В этой статье я хотел бы поделиться своим опытом создания SaaS-сервиса на базе LAMP стека, Postio и доведения сервиса до состояния, когда он стал приносить 3 700 долларов ежемесячно (до обрушения рубля было почти 7 000). Сразу надо сказать, что эта история не имеет ничего общего с инвесторами, с золотой лихорадкой Кремниевой долины и с какой-то сверхсовременной технологией. Просто незамысловатая история от независимого разработчика о создании прибыльного SaaS-сервиса, который может сделать любой. Этот веб-сервис был сделан для внутреннего рынка России, поэтому я перевёл всё на английский и в доллары для удобства (пожалуйста, обратите внимание, что это перевод моей статьи, которая изначально была написана для англоязычной аудитории). Но, с другой стороны, этот опыт является довольно универсальным и может быть применён везде. По сути, это инструкция по созданию проектов такого рода.

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

Наверное, я должен немного отвлечься и сказать, что VK.com имел и до сих пор имеет процветающую «экосистему» таких групп, которая приносит прибыль их владельцам. Это — своеобразный рынок, который Facebook прикрыл уже давно. И этот базар является прекрасной средой для обучения и экспериментов.

Участие в стартапе по эмоциям напоминает езду по американским горкам, когда в какой-то момент вы чувствуете, что владеете миром, а через секунду — что всё рушится. Это руководство может помочь в запуске стартапа.

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

В течение 6 лет я работал исключительно в стартапах. Я был «программистом» — специалистом, которого нанимали для преобразования идей в «реальный» бизнес. У меня никогда не было желания запустить моё собственное дело: стоит ли рисковать комфортной жизнью ради идеи, которая может не сработать?

Затем 4 года назад я взялся за трудное дело, основав стартап — 5-дневные курсы обучения программированию в Лондоне под названием Steer. Через два года я оставил Steer, запустив SuperHi.

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

Создание программного обеспечения для стартапов — серьёзная задача. Не потому, что само написание программного обеспечения является довольно трудным, а потому, что у большинства стартапов места для выполнения такой работы далеки от оптимальных. За свои более чем 10 лет опыта разработчика ПО для стартапов я научился не доверять способности работодателей обеспечить мне адекватную рабочую среду, и это мешает мне выполнять работу для них наилучшим образом. Я, по своей природе, амбициозный, энергичный, и я не хочу ничего более, чем выдать на том месте, где я работаю, лучшее из того, что я могу. Я отдаю себя на 100% компании, в которой я работаю. Но в большинстве мест, где я работал, было сделано немало, чтобы воспрепятствовать мне в этом. Вот почему в какой-то момент времени я занял чёткую позицию: отныне я буду работать только «удалённо».

Ограничение ответственности: настоящая статья написана анонимно. Упомянуто несколько конкретных компаний, но лишь в качестве общего примера.

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

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

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

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

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

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


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

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

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

Итак, как сделать новый Trello и разбогатеть на этом? Но, конечно, не создавая клона Trello. Почему? Trello — классический пример подрывной инновации. Когда речь идёт о подрывной инновации, инициатор получает всё. Компания Atlassian приобрела Trello за 425 млн. долларов не из-за бренда или пользовательской базы этого сервиса, а из-за опасности, которую Trello породил для будущего этой компании. По этой же причине Гугл и другие компании делают аналогичные приобретения. Если желаете сделать стартап на 400 млн. долларов, разработайте что-нибудь простое. Эта статья объяснит почему!

Почему разработчики не могут написать безопасный код? Мы не говорим здесь очередной раз про «чистый код». Мы говорим о большем с чисто практической точки зрения — о надёжности и безопасности программного обеспечения. Да, потому что небезопасное программное обеспечение в значительной степени бесполезно. Посмотрим, что значит «небезопасное» программное обеспечение:

• Полёт №501 ракеты «Ариан-5» Европейского космического агентства был прекращён через 40 секунд после старта (4 июня 1996 г.). Экспериментальная ракета-прототип стоимостью 1 млрд. долларов США самоликвидировалась из-за ошибки в бортовом ПО управления.
• Ошибка в программе, управлявшей установкой лучевой терапии Therac-25, стала прямой причиной смерти, как минимум, пяти пациентов в 80-х годах, когда она задавала чрезмерные дозы рентгеновского облучения.
• Программная ошибка в зенитном ракетном комплексе MIM-104 «Patriot», вызывавшая уход его системных часов на одну треть секунды за сто часов, привела к его неспособности обнаружить и перехватить летящую ракету. Иракская ракета попала в воинскую часть в г. Дахран, Саудовская Аравия (25 февраля 1991 г.), погибло 28 американцев.

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

Примечание: первоначально эта статья была написана для сайта Fuel Your Coding back в мае 2010 года. К сожалению, этот сайт сейчас не работает, поэтому я публикую статью здесь, чтобы сохранить её для потомков. Я собирался обновить её, учитывая последние веяния, но решил оставить так, как она была написана. Те части, что подустарели, могут показаться немного смешными, но да ладно. Получайте удовольствие…

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

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

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

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

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

Системный администратор / Разработчик ПО


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

Финансовый директор Alphabet г-жа Рут Порат желает сосредоточиться на Маунтин-Вью. Сможет ли Moonshot factory — исследовательская лаборатория «прорывных проектов» — приспособиться к новым условиям?

Ранее в этом году, Астро Теллер, учёный с оригинальной причёской «конский хвост» и писатель-фантаст, дал интервью изданию TED.

Оно было первым для Теллера, но не для Х-лаборатории (или Google X), поскольку исследовательская лаборатория, которую он возглавляет, довольно известна. Эта лаборатория постоянно присутствовала в цепи связи многие годы. В 2011 году Себастьян Тран, основатель Х-лаборатории, вышел на сцену TED и выдал прогноз, что автомобили без водителей положат конец дорожно-транспортным происшествиям с летальным исходом. В 2013 году Сергей Брин, соучредитель Google, продемонстрировал разработанный в Х-лаборатории носимый компьютер Google Glass, утверждая, что закрепляемые на лице устройства являются естественным преемником смартфона. В 2015 году Крис Армсон, технический руководитель программы автономных транспортных средств в Х-лаборатории, провозгласил, что автомобили-роботы должны работать вообще без человеческого надзора. В феврале 2016-го подошла очередь Теллера.

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

С 2008 года количество жалоб на дискриминацию по возрасту выросло до 25 000 в год. Можно возразить, что мы везде вынуждены «крутиться» сейчас и всегда найдётся кто-то, кто пожалуется на какую-то несправедливость. Конечно, ОК! Давайте не будем принимать во внимание жалобы. Просто посмотрим на средний возраст сотрудников известных IT-компаний. Фейсбук: 28. LinkedIn: 29. Гугл: 30. Чтобы увидеть объективно — средний возраст работника в США составляет 42 года. Это намного выше среднего возраста в названных выше компаниях. Даже сам Марк Цукерберг однажды публично высказался на каком-то мероприятии в Стэнфорде: «Я хочу подчеркнуть важность быть молодым и технически подготовленным. Молодые люди просто умнее.»

Введение

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

«Если вы можете кэшировать всё очень эффективным способом, то вы часто можете изменить правила игры»

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

• Метаданные продукта в интернет-магазине
• Метаданные документа в поисковой машине
• Метаданные фильмов и ТВ-шоу

Сталкиваясь с этим, мы обычно выбираем один из двух путей:

• Хранение этих данных в каком-то централизованном хранилище (например, реляционная СУБД, информационный склад NoSQL или кластер memcached) для удалённого доступа пользователей
• Сериализация (например, как json, XML и т.д.) и распространение среди потребителей, которые будут хранить локальную копию

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

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

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

Но так ли это? Давайте не будем просто воспринимать на веру слова некоторых парней в интернете, как библейское откровение, а проведём небольшой эксперимент и выясним.