Часть 4

— Фонтан на горизонте! — раздается с мачты.
— Где? — спрашивает капитан.
— Три румба под ветер, сэр.
— Лево руля! Так держать!
— Есть так держать, сэр!
— Эй, дозорный! А сейчас ты его видишь?
— Да, да, сэр! Их там целое стадо кашалотов! И фонтаны пускают, и из воды скачут.
— Как что увидишь — подавай голос!
— Есть, сэр. Вон фонтан! Еще — еще — еще один!
— Далеко ли?
— Мили две с половиной.
— Гром и молнии! Так близко! Свистать всех наверх!"

Дж. Росс Браун.
«Зарисовки во время китобойного плаванья», 1846

Во время работы над стартапом вам придётся столкнуться с большими компаниями. Ищете вы партнёрство, возможность дистрибуции, инвестиции, хотите ли организовать рекламный альянс. Время от времени вам требуется получить одобрение большой компании. Или компания приходит к вам с предложением купить ваш стартап. Самое важное, что следует помнить, идя на переговоры в такую компанию: вы – капитан Ахав, а большая компания – Моби Дик.

Часть 3

Статья о том, что наиболее важно для стартапа. Для начала – немного теории.

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

Начинаешь задумываться, что больше влияет на успех – команда, продукт или рынок? Или, проще говоря, в чём рецепт успеха? Или, наоборот, что наиболее опасно – плохая команда, слабый продукт или дохлый рынок?

Руководство по созданию стартапов, часть 3: «Но у меня нет знакомых инвесторов!»

Часть 2

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

Я могу разделить ваши чувства – когда я в университете Иллинойса работал над Mosaic, слова «венчурные инвестиции» для меня значили не больше, чем «klaatu barada nikto». Я никогда не встречал инвестора, инвестор никогда не разговаривал со мной, и я не распознал бы инвестора, даже если б споткнулся о его чековую книжку, лежащую на тротуаре. Я не уверен, что без помощи Джима Кларка смог бы найти финансирование для запуска такой компании, как Netscape, даже если б мне пришла в голову мысль основать компанию.

Часть 1

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

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

Данное руководство – серия считающихся классическими постов блога человека с ником pmarca, а в жизни – Марка Андреессена, создателя браузера Mozaic, из которого вырос Netscape, а затем и Mozilla.
Ссылки специально даются на старые версии сайтов, современные статьям, сохранённые в интернет-архиве.

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

Мой опыт в данной области собран при работе в трёх компаниях, в которых я был со-основателем: Netscape, продана America Online в 1998 за $4.2 миллиарда; Opsware (бывш. Loudcloud), софтовая компания с капитализацией порядка $1 миллиарда; Ning, интернет-компания, предоставляющая платформу для социальных сетей.

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

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

В давние времена разработки мобильных сайтов и приложений отладка была сложной задачей. Да, можно было заполучить устройство и быстренько проверить работу – но что было делать, если ты обнаруживал баг?

При отсутствии инструментов отладки приходилось полагаться на разные хаки. В целом они сводились к попыткам воспроизвести баг в десктопном браузере и затем отловить его при помощи Chrome Developer Tools или где-то ещё. К примеру, можно было уменьшить размер окна браузера или поменять user agent.

Грубо говоря, эти хаки не работали. Если ты правишь баг на десктопе, ты не уверен, что он исправлен на мобильном устройстве (МУ). Поэтому приходилось постоянно метаться между устройством и десктопом.

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

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

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

Делайте то, что нужно людям

Мы все знаем, что построили что-то довольно полезное: практически любая команда, перешедшая на Slack, получит преимущество. То есть, у нас есть что-то, что нужно людям.

Тем не менее, большинству из них невдомёк, зачем им нужен Slack. Да и откуда им знать? Они никогда про него не слышали. И исчезающее малое количество из них придумали что-то похожее. Они хотят чего-то другого (если вообще чего-то хотят). Они точно не ищут Slack. Ну так, никто не искал самоклеющиеся листочки или GUI, пока их не изобрели.

MaidSafe – интересная распределённая система передачи и хранения данных. Мне понравилась эта идея и я захотел поделиться с общественностью. Компания MaidSafe зарегистрирована в Шотландии, и разрабатывает свой проект при поддержке спонсоров.

Обзор платформы

MaidSafe состоит из двух главных компонентов – сеть и клиентские приложения. Сеть находится в разработке, и планируется к выходу к концу 2014 года (уже доступны исходники для компиляции на github. Также готовятся к выпуску приложения, которые на примере покажут использование SAFE API и позволят всем создавать свои собственные приложения.

В 2008 мы с партнёром закончили обучение по специальности «компьютерная инженерия» в университете в Аргентине.

На старших курсах мы проходили стажировку в таких компаниях, как HP, IBM, Intel. Именно тогда мы заметили недостаток в их работе. Мы не могли понять, почему люди без технических знаний говорят программистам, что им делать, и кроме того, проверяют, как именно они это делают.

Поэтому, когда мы делали Project eMT, сравнительный поисковик для Латинской Америки, мы решили работать по-другому: без менеджеров проектов. Через шесть лет у нас в команде было 34 инженера из Чили, Бразилии, Мексики и Колумбии, и мы всё ещё работаем без использования традиционных структур и рабочего графика, а наш ежегодный рост составляет 204%.

Что самое главное для бизнеса? Деньги! А как их получить? От клиентов! Нет клиентов – нет доходов, и способность привлекать клиентов – это то, что отличает успешный бизнес от провального.

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

Прямая трансляция презентации iPhone 6 и Apple Watch с самого начала не задалась. У многих пользователей, включая меня, были проблемы с её просмотром. Вначале я грешил на проблемы у облачного сервиса Akamai, но исследование страницы сайта Apple показало, что больше всего проблем возникло из-за того, как они настроили Amazon S3 и кое-каких других элементов сайта.

В отличие от предыдущей прямой трансляции, в этот раз они решили при помощи JSON добавить интерактивности в страничку, и показывать твиты, относящиеся к событию, внизу страницы. В результате этого страница обновлялась несколько раз в секунду. Из-за решения использовать JSON (прим. перев. – мне кажется, что автор путает JSON и Ajax) сайт перестал кешироваться. Обычно, Apple используют кеширование от Akamai для таких трансляций, однако в этот раз кэшировать страницу было нельзя, что привело к сильному проседанию скоростей загрузки страницы и отображения видеопотока. А так как в Apple вставили видео в страницу, тормоза страницы привели к тормозам видео. В Akamai не захотели комментировать эту проблему, но судя по коду страницы, у них всё равно не получилось бы её кэшировать. Из-за этого также у менял падал Safari, когда я пытался открыть страницу с презентацией на iPad.

Прекрасный продукт, решающий проблему, которая никому не нужна – провалится. Уродливый продукт, решающий реальную проблему, может стать успешным.

Пост, разъясняющий некоторые вопросы по статье "Дриббблификация дизайнеров"

Существует замкнутый круг непонимания дизайна

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

Примечание: Dribbble — сервис, где графические дизайнеры хвастаются друг перед другом своими работами.


Лишь одно из этих погодных приложений пытается решить насущную проблему.

В сообществе дизайнеров наблюдаются расходящиеся тенденции. С одной стороны мы наблюдаем интересные блоги от Райана Сингера и Джулии Жуо, которые развивают наше ремесло. С другой стороны, всё большее количество народу постят свои работы и обсуждают их на Dribbble, что в целом двигает наше ремесло в обратную сторону. Этот пост – не про Dribbble, как таковой, он про то, что ценит это сообщество. Я буду использовать термин «дизайн продукта», но также буду иметь в виду дизайн пользовательских взаимодействий с продуктом.

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

Не так давно Apple представила iPhone 5S, и сайт с презентацией, где страница была поделена на секции, и каждая секция описывала одну из особенностей продукта. Я подумал, что это – замечательный способ представления продукта, исключающий возможность пропустить ключевую информацию.

Я отправился на поиски подходящего плагина, и к удивлению, не обнаружил такового. Так и родился плагин постраничной прокрутки.

Часть 1

Техники сжатия данных

Для сжатия данных придумано множество техник. Большинство из них комбинируют несколько принципов сжатия для создания полноценного алгоритма. Даже хорошие принципы, будучи скомбинированы вместе, дают лучший результат. Большинство техник используют принцип энтропийного кодирования, но часто встречаются и другие – кодирование длин серий (Run-Length Encoding) и преобразование Барроуза-Уилера (Burrows-Wheeler Transform).

Тем временем, в штате Миннесота «коренной американец» Андрей Руденко раздвигает границы 3D-печати, а именно: у себя на заднем дворе методом трёхмерной печати из бетона возводит модель средневекового замка на площади 3х5 метров. В процессе работы прототип бетонного принтера улучшается и обновляется.

Создавая один из самых больших объектов в области 3d-печати, изобретатель хочет прийти к надёжному способу построения реальных жилых домов, способных выдержать различные погодные условия. Андрей имеет инженерное и архитектурное образования, что позволяет ему экспериментировать и находить интересные решения на пересечении архитектуры и 3d-печати. Замок одновременно представляет собой интересную сложную задачу и прекрасную демонстрацию возможностей принтера.

Часть 1

Книга 4

Кодим

И сказал Великий Программист: «Хорошо написанная программа сама себе Рай. Плохо написанная программа сама себе Ад»

4.1

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

Программа должна следовать правилу «наименьшего удивления». Это значит, что программа должна отвечать на действия пользователя способом, наименее удивительным для него.

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

Если программа не удовлетворяет этим требованиям, это ведёт к беспорядку и путанице. Остаётся лишь переписать её заново.

На прошлой неделе в Калифорнии, США, был рассмотрен проект закона, по которому любой смартфон, проданный с июля 2015 года в Калифорнии, должен иметь возможность удалённо отключаться по команде — да так, чтобы даже hard reset не помог.

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

Кстати, как характерно расположились на карте страны, согласно отношению к BTC…

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

Итак – чем же хороши BTC.

Часть первая – историческая.

Введение

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