«Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов».»
— Пол Грэм, разработчик, инвестор, эссеист.

Мне было любопытно познакомиться с прогнозом основателя самого влиятельного бизнес-инкубатора кремниевой долины (Y combinator). Спустя 15 лет с момента публикации эссе Пола Грэма, благодаря компании Edison и отличным людям с Хабра, руки дошли до перевода. Для тех, кому интересно, как происходило зарождение нового продукта и как три программиста бодались с гигантами индустрии, добро пожаловать под кат.



Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод спасибо Щекотовой Яне)

Читать первую часть главы.

Подход к делу

Иметь возможность выпускать программу незамедлительно — существенный мотиватор. Часто по пути на работу я думал об изменениях, которые мне хотелось внести в приложение, и вносил их в тот же день. Это также работало и для более крупных фич. Даже если на написание чего-то требовалось две недели (а на некоторых проектах и того больше), я знал, что смогу увидеть результат как только все будет реализовано.

Если бы мне приходилось ждать год до следующего релиза, я бы большинство таких идей отложил в долгий ящик, по крайней мере, на некоторое время. Дело в том, что, все-таки, идеи приводят к другим идеям. Вы когда-нибудь замечали, что, как только вы садитесь что-то написать, половина воплощенных в работе идей — это те идеи, которые посетили вас в процессе? То же самое происходит и с программами. Работа над реализацией одной идеи дает вам еще больше идей. Поэтому за откладывание вы заплатите не только задержкой в реализации своей идеи, но также и всеми идеями, к которым вы придете на данном этапе. На самом деле, откладывание препятствует появлению новых идей: как только вы начинаете размышлять о каком-то новом функционале, вы вспоминаете про свой «ящик» и думаете: «Но у меня же уже куча фишек для реализации в следующем релизе».

Крупные компании вместо реализации фич планируют их. По этой причине мы в Viaweb иногда сталкивались с трудностями. Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов». У нас были общие представления о том, что бы мы хотели улучшить, но если бы мы знали как, то уже давно бы это сделали. Что мы собираемся делать с течении следующих шести месяцев? Все, что могло бы привести нас к максимально выигрышному положению. Не знаю, осмелился бы я когда-нибудь так ответить, но такова была правда. Планы — это всего лишь синоним к слову «идеи». Когда нас посещали хорошие идеи, мы реализовывали их. Читать дальше →

«Для Viaweb мы часто делали три-пять версий в день.»
— Пол Грэм, разработчик, инвестор, эссеист.

Мне было любопытно познакомиться с прогнозом основателя самого влиятельного бизнес-инкубатора кремниевой долины (Y combinator). Спустя 15 лет с момента публикации эссе Пола Грэма, благодаря компании Edison и отличным людям с Хабра, руки дошли до перевода. Для тех, кому интересно, как происходило зарождение нового продукта и как три программиста бодались с гигантами индустрии, добро пожаловать под кат.


Пол Грэм, Роберт Моррис и Тревор Блэквел в 1995

Очередная глава книги «Хакеры и художники» (которая уже почти полностью переведена на русский)

Другая дорога в будущее

Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод плюсик в карму knagaev)

(Эта статья объясняет почему многое в ПО следующего поколения может быть реализовано на серверной стороне, что это будет значить для программистов, и почему этот новый вид ПО будет хорошей возможностью для стартапов. Источниками статьи были диалоги в BBN Labs.)

Летом 1995-го я со своим другом Робертом Моррисом (Robert Morris) решили запустить стартап. PR-кампания перед IPO Netscape тогда шла полным ходом, и в прессе было полно разговоров об электронной коммерции. На тот момент в сети уже было порядка тридцати реальных электронных магазинов, и все они были сделаны вручную. Если в скором времени в сети должно было появиться множество онлайн-магазинов, была потребность в ПО для их разработки, и мы решили такое написать.

Сначала, где-то около недели мы думали, что это будет обычное приложение для ПК. Но потом у нас возникла идея разработать приложение, которое будет исполняться на нашем веб-сервере, с использованием браузера в роли пользовательского интерфейса. Мы попробовали переписать приложение для работы в Вебе, и стало понятно, что это правильное направление. Если мы писали наше ПО для исполнения на сервере, это было удобнее как для пользователей, так и для нас.

Оказалось, что это был отличный план. Теперь, как Yahoo Store, это ПО является самым популярным конструктором онлайн-магазинов, с ним работает порядка 14 тысяч пользователей.
Читать дальше →

Отказ от претензий: не используйте описанные ниже патчи на продакшене; пользуйтесь специально подготовленными тестовыми площадками.

* * *

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

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

Вводная

История началась с того, что меня попросили провести подробный аудит довольно популярного интернет-магазина. Всё приложение вертелось на двух балансировщиках, нескольких бэкэндах и двух серверах БД. Нагрузка — 1-4 тысячи запросов в минуту. Стек близок к классическому: PHP(-fpm), Mysql, Memcached, Sphinx, Nginx. Иногда обстоятельства складывались так, что вся система вставала колом, при этом прямой корреляции с нагрузкой не было. И даже с выкладкой нового кода (и соответствующими перезапусками демонов) — не всегда.

Читать дальше →

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


А ведь ничего не предвещало беды...

Мы продолжаем публиковать в нашем блоге авторские статьи на темы разработки приложений. Встречайте первую статью от Андрея StealthDogg Веселова — опытного веб-разработчика и Microsoft MVP.

Не секрет, что в большинстве веб-браузеров есть инструменты для разработчиков. С их помощью можно получить информацию о DOM, состоянии выполняемых скриптов, времени загрузки страницы и т.д. Но существуют ситуации когда они отсутствуют или не доступны. Например, в мобильных или IoT устройствах. Тогда на помощь приходит Vorlon.js.

Что такое Vorlon.js

Vorlon.js это бесплатный инструмент, который позволяет получить и отобразить в браузере разработчика различную отладочную информацию от клиентов отлаживаемого веб-приложения. Он использует node.js и написан на языке TypeScript, который является надмножеством JavaScript. Таким образом, его можно применять для отладки веб-приложений практически на любой платформе.

Посмотрим на возможности Vorlon.js. Его окно внешне схоже с окнами инструментов разработчика в браузерах:



Слева в окне расположен список клиентов, подключенных к отлаживаемому веб-приложению. Определить, какая строка соответствует каждому из них, можно нажав кнопку "Identify a client". После этого их браузеры выведут на экран свой индекс.
Читать дальше →