Перевод: Роман Юрьев, toodoo– социальная сеть сайтофанантов, специально для Хабрахабра.

Соучредитель и генеральный директор Weblogs Inc., Джейсон Калаканис (Jason Calacanis) недавно прослушал демо 200 компаний в качестве запросов на участие в приближающейся конференции TechCrunch50. Я соглашаюсь со всеми приведенными ниже позициями на основе собственного опыта общения с тысячами представителей стартапов за последние три года. Если вы проталкиваете компанию в прессе, на конференции, перед потенциальным инвестором или работодателем, отметьте как-то для себя эти пункты. Иначе пожалеете, что не сделали этого.



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

А вот и письмо Джейсона к просителям.

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

В рамках поддержки блога разработки под Mac OS X, я представляю свою статью о низкоуровневой разработке под Mac OS X. Обычно тема разработки драйверов не столь популярна, однако и здесь Mac OS X выгодно выделяется из ряда прочих операционных систем. Да, писать драйвера для Mac O S X – просто! Проще чем когда-либо ранее!

Статья Michael Cerda о том, чего не стоит забывать на этапе создания стартапа.

Уровень подготовки читателя: низкий — средний.

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

Продукт: ваш продукт должен быть обезболивающим, а не витаминами.

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

Моя первая статья, не судите строго...

Приветствую вас, уважаемые хабрадевелоперы!

Многие из вас знают о прекрасном легковесном веб-сервере nginx.
Некоторые также знают, что он умеет работать с memcached.
Но лишь немногие в курсе, при чём здесь SSI и как его можно использовать в связке с nginx и memcached.

Как известно, новое — это хорошо забытое старое. Каждый названный инструмент и технология вам наверняка известны. Я же хочу рассказать о том, как и зачем свалить всё это в одну кучу :)

Полная авторская верcия из моего блога. Оригинал материала написан специально для Developers.org.ua

Наверное любой современный веб-проект сложно себе представить без… без контента! Да, именно контент в разных его проявлениях сегодня «правит бал» в различных веб-проектах. Не так важно — создаваемый пользователями или получаемый из других источников автоматически — информация является основной любого (ну, или почти любого) проекта. А раз так — то вопрос поиска необходимой информации стоит очень остро. И острее с каждым днем, ввиду стремительного расширения количества этого самого контента, в основном за счёт создаваемого пользователями (это и форумы, и блоги и модные нынче сообщества, вроде Habrahabr.ru). Таким образом, любой разработчик, реализующий сегодня какой-либо проект, сталкивается с потребностью реализовать поиск в своём веб-приложении. При этом требования к такому поиску уже намного сложнее и шире, чем даже год-два назад. Конечно, для каких-то проектов вполне подойдёт и простое решение, к примеру, вполне можно использовать Custom Google Search. Но чем более сложное приложение, и чем сложнее структура контента, если требуются особые виды поиска и обработки результата, или же просто количество или формат данных в вашем проекте особый, вам потребуется собственная поисковая система. Именно своя система, собственный поисковый сервер или сервис, а не сторонний, пусть даже гибкий и настраиваемый. Но что же выбрать, и вообще — какие сейчас на рынке есть поисковые проекты, которые готовы для использования в реальных проектах, не исследовательских или научных, а реальных бизнес-приложениях? Далее мы кратко рассмотрим различные варианты поисковых решений, пригодных для встраивания в ваше веб-приложение или развёртывания на собственном сервере.

Сегодня поговорим о стартапах. Инициатором этой статьи стал материал от известнейшего венчурного инвестора, Поля Грехема (Paul Graham), который руководит уже известным нам фондом Y Combinator (о котором мы писали, да и в России уже появились фонды, в той или иной мере копирующие его бизнес-модель, например, addVenture, JumpIDEA, inVenture). Теперь он описал своё виденье рынка и указал на тридцать тем или скорее очертил круг интересов и рынков, в которые они готовы вкладывать. Впрочем, как правильный и успешный инвестор, он не ограничивается ими и готов рассматривать любую интересную идею (о чем и указывает в конце материала). Далее я переведу и попробую самостоятельно проанализировать эти рынки, а также позволю себе добавить и свои взгляды, указав на дополнительные интересные и перспективные направления. Это не дословный перевод, поэтому для тех, кто хочет изучить именно оригинал, вот ссылка на англоязычный источник.

Про регистры в Vim уже писали в предыдущих постах, но я решил собрать инфу воедино и немного дополнить. Прочитав эту статью, вы станете настоящими мастерами копи-пастинга (в хорошем смысле этого слова) :)

Сложно представить себе работу в редакторе без использования операций скопировать/вырезать/вставить. Vim предоставляет очень мощные средства, для этого. Итак, регистры — это то, куда Vim складывает те куски текста, которые вы копируете с помощью y или удаляете с помощью c или d, но не только. Есть ещё несколько специальных регистров, куда Vim помещает, например, текст, который вы искали с помощью / или текст, который вы drag-n-dropнули в окно редактора. Чтобы указать, что вы хотите скопировать или удалить текст в определенный регистр, нужно указать его имя перед командой. Например, «ayy скопирует строку целиком в регистр »a. Но не во все регистры можно писать, некоторые из них только для чтения (и даже есть один только для записи).

Ещё немного особой, Vimовской магии, связанной с регистрами, для затравки, чтобы было не лень дочитать до конца:
— Vim хранит небольшую историю удалений, так что вы можете вставить удалённый ранее текст, даже если после этого вы удаляли или копировали другой текст.
— Vim предоставляет вам 26 именованных «буфера обмена», в которые можно надолго складывать текст и он не будет потерян при операциях копирования или удаления.
— Vim может копировать или удалять текст, не затирая содержимое регистра, а дополняя его.

«Для меня vi это Дзен.
Использование vi — это практика дзена.
Каждая команда является коаном.
Полный смысла для пользователя,
Бессмысленный для непосвященного.
Вы познаете истину каждый раз когда вы его используете.»
--reddy@lion.austin.
на сколько хорошо ты знаешь язык vim?
посмотри на клавиатуру,
можешь ли ты сказать что выполняет каждая буква?
как много ты знаешь?
как много используешь?

Наверняка вы видели на многих сайтах свешивающиеся в начале строк кавычки и скобки. И хотя на бумаге такое полное свешивание в простых текстах (не заголовках) как минимум спорно, на вебе это выглядит отлично. Такое поведение текста называется «висячая пунктация», и на текущий момент есть ровно один способ её реализации в (X)HTML/CSS — добавление парных стилей. Этот способ, скажем, применён на сайте Артемия Лебедева.

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

В CSS прописаны парные стили: .h[symbol] и .s[symbol], например, .slaquo и .hlaquo. Для каждого из них прописан отвес через margin. При использовании свешивающихся символов в тексте к пробелу перед символом добавляется стиль s[symbol], а к самому символу — h[symbol]. Соответственно, когда и пробел, и символ, находятся в одной строке, отвесы взаимно компенсируются, и текст выглядит как обычно. А когда свешивающийся символ по каким-то причинам сносится на следующую строку — первый стиль (балансирующий второй блок) остаётся на предыдущей строке, поэтому нужный символ свешивается влево на заданный отвес.

Реализация по сути хорошая, с одним «но» — шрифты. Для каждого шрифта отвес, скажем, открывающей кавычки-ёлочки или открывающей скобки разный. Да, конечно, мы можем его вычислить вручную и прибить в таблице стилей гвоздями (так и сделано у Лебедева на сайте), но для этого придётся быть уверенным, что как минимум у 90% посетителей сайта будет именно этот шрифт. В случае, если браузер покажет это каким-то иным шрифтом, начнутся проблемы с разъезжающимися строками.

Что было сделано?

Мне было интересно почитать, наверняка кому-то тоже пригодится.

• Как организованы кластеры Google
  www.slideshare.net/ultradvorka/google-cluster-innards
  
  Как строить дизайн системы с тэгами на Mysql, а также как
  проектировать базу MySQL с Master/Slave, чтобы распределять нагрузка
  на узлы веб-фермы (от майсиквелиста) — с примерами SQL
  www.slideshare.net/jonathanbaij/building-a-tag-system-with-mysql
  
  Как оптимизировать вызовы Javascript/AJAX на сайтах (от гуглиста)
  www.slideshare.net/souders/web-20-expo-even-faster-web-sites
  
  Как организован DIGG (PHP + MYSQL)
  www.slideshare.net/epee/mysql-2007-tech-at-digg-v3
  
  Как оптимизировали Fotolog (самое большое сообщество по фото
  блоггингу) MySQL, JAVA, PHP, Memcached, дизайн БД
  www.slideshare.net/frankmashraqi/fotolog-scaling-the-worlds-largest-photo-blogging-community
  
  Как оптимизировать БД MySQL
  www.slideshare.net/techdude/how-to-kill-mysql-performance
  
  Как организован Flickr (PHP, PEAR, ImageMagic, Perl, Java, XML)
  www.slideshare.net/coolpics/flickr-44054
  
  

Примечание: ниже перевод статьи «On Streaming, Chunking, and Finding the End», в которой авторы рассматривают процесс передачи информации по HTTP-соединению и возможности для ускорения этого процесса. Мои комментарии далее курсивом.

Два способа передачи

Как и в большинстве механизмов передачи данных, в HTTP существует два основных способа отправить сообщение: «все и сразу» или «по частям». Другими словами, в HTTP есть возможность отправлять данные до тех пор, пока еще есть хотя бы что-то, что можно отправить, либо отправить все данные как одну логическую единицу, указав предварительно ее размер.

Если вы занимаетесь веб-разработками достаточно продолжительное время, скорее всего, вы уже знаете, как работает сброс буфера (flush) на стороне сервера. Этот метод позволяет начать отправку части данных пользователю, в то время как скрипт может продолжать выполнять некоторые, достаточно медленные, действия (скажем, ресурсоемкий запрос к базе данных). Если вы уже применяли эту возможность, тогда вы, вероятно, использовали преимущества потокового (streaming) механизма, хотя могли и не знать всех деталей работы HTTP-протокола.

читать дальше на webo.in →

Если вы разработчик AJAX приложений или интерфейсов, то вам это окажется полезным. Если приходится хранить некоторые достаточно обьемные данные в структурированном виде на стороне клиента, то каким образом это оптимально сделать? Конечно, вам могут помочь обычные массивы (тип данных или, скорее, встроенный обьект Array), и он даже предоставит базовые функции для управления массивом данных и основные операции над ним, но это очень, скажем так, низкоуровневое решение, часть функционала может зависеть от реализации JS-движка в конкретном браузере. Кроме этого, что-то делать с сохраненными данными нужно писать достаточно много собственного кода, и в конце концов ваш код превращается в такое нагромождение вызовов, функций и переменных, что разобраться в этом ой как сложно.

Да, выход из этого есть. В частности, самым лучшим решением (в теории) является использовать специальных плагинов для расширения функциональности браузера, для примера, в Google Gears встроена полноценная СУБД (SQLite), и вы получаете в свое распоряжение все ее возможности прямо в JavaScript коде (самое ценное, по моему, кроме хранения большого обьема данных, является полнотекстовый поиск). Аналогичные инструменты можно встретить в спецификации HTML 5, да и в последних версиях Mozilla Firefox будет встроена база данных в качестве клиентского стораджа, в среде Adobe AIR также используется встроенная база SQLite. Но что делать, если все эти радости по какой-либо причине недоступны либо их использование ограничено, а удобное хранение и работа с данными нужно иметь уже здесь и сейчас, и без дополнительных надстроек. Выход, конечно же есть!

Вашему внимание предлагается достаточно большой отрывок статьи «Levels of HTML knowledge», написанной Роджером Йоханссеном 30 Мая 2006 года.

Прим. переводчика: Изначально я опубликовал этот пост в виде юмористических выдержек из трех статей, написанных тремя разными авторами и озаглавленных схожим образом: «Уровни владения HTML», «Уровни владения CSS» и «Уровни владения Javascript». Что, конечно же, было довольно глупой затеей. Осознание допущенной ошибки пришло через 5 минут и два минуса к посту и карме. Исправляюсь. Перевод «Уровней владения CSS» ждите завтра.

Однажды вечером я почувствовал, что пришло время расширить 97‐ й параграф «Ководства» Артемия Лебедева.

На клавиатуре одна чёрточка, она обычно правее нуля и повыше букв «З» и «Х». Неосведомлённые люди называют её попеременно то дефисом, то минусом, то тире. Лебедев объясняет нам, что это четыре (учитывая две разновидности тире) различных символа. На самом деле их как минимум девять, и об этом я и расскажу вам сейчас.

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

Основы масштабирования

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

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров — обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности — это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке — сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.