Стартапы сейчас не делают только ленивые. А почему, собственно, не делают?

Дождливым вечером, за кружкой пива (все банально, как только может быть) у нас родилась идея создания социальной сети для творческих людей, ниша которой до сих пор не занята. Социальная сеть для художников, иллюстраторов, дизайнеров, аниматоров, etc… Вдохновение пришло от сайта с многовековой историей devianart.com, русскоязычных аналогов которому до сих пор нету.

С первых моментов, задумавшись над идей популяризации, мы решили завести себе блог, для функций привлечения заинтересованных людей и PR`а. Но чем больше пытались развернуть эту идею, тем глубже она уходила в дебри. Что получилось в итоге?

Примечание: ниже перевод статьи «Event delegation without a JavaScript library», посвященной обзору методов по назначению обработчиков событий в JavaScript и их возможной оптимизации, она дополнена моими комментариями и практической частью.

Большинство статей и примеров, которые я видел в последнее время по переопределению событий, основывались на какой-либо распространенной библиотеке. Например, в своей хорошо известной статье Chris Heilmann применяет YUI-библиотеку, а в прошлом месяце Dan Webb в своей презентации на media использовал prototype.

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

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

Том Лейн (Tom Lane) сообщил, что патч, интегрирующий полнотекстовый поиск (ранее выполненный в виде отдельного модуля, contrib/tsearch2) в ядро PostgreSQL, успешно внесён в CVS. Безусловно, это ключевой момент в сложнейшем процессе принятия патчей для версии 8.3

Примечание: ниже перевод статьи «Presentation Layer Performance Tuning», в которой затрагиваются основные аспекты оптимизации загрузки веб-приложений и предлагаются некоторые практические советы.

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

Эти процессы, однако, только частично затрагивают то время, которое клиент тратит на ожидание загрузки страницы в окне своего браузера. Большая часть времени тратится на загрузку, кеширование и отображение JavaScript, CSS и картинок (прим.: не-HTML файлов). Оптимизация производительности уровня представления (presentation layer) веб-приложений, на самом деле, сводится к двум простых условиям:

• Меньше данных
• Меньше запросов

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

Примечание: ниже находится перевод двух близких статей («Delay loading your print CSS» и «JS includes — the saga continues…») по оптимизации загрузки страницы при наличии нескольких файлов стилей или скриптов.

У вас есть два вызова CSS-файлов на странице, например:

<link type="text/css" rel="stylesheet" href="screen.css"
      media="screen" />
<link type="text/css" rel="stylesheet" href="print.css"
      media="print" />

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

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

Примечание: ниже перевод статьи «Ajax Best Practices: Don't Break Bookmarks», посвященной решениям, позволяющим пользователям корректно добавлять в закладки страницы сайта, сделанного при помощи AJAX-методов. Я постарался дополнить ее по мере сил, опираясь на обсуждение предыдущей статьи из серии.

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

 

Примечание: ниже перевод статьи «Reporting bugs — a how-to guide», в которой приводится ряд нехитрых действий, которые могут помочь как пользователю, так и разработчику справиться с ошибками на сайте или в веб-приложении. В свете постоянного появления в Рунете проектов со статусом «бета», статья может быть особенно полезна.

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

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

История успеха гениального американца Джеффа.

Примечание: ниже перевод статьи «Fixing The Web — Part 1», в которой поднимаются наиболее актуальные вопросы, касающиеся текущего положения вещей в Вебе.

Нуждается ли Веб в исправлениях?

История Веба насчитывает уже 16 лет. В первые 10 лет Веб-технологии развивались ошеломляюще быстро, но в последние 6 лет серьзных изменений в них не последовало. Насколько это хорошо или плохо? Существует ряд вполне понятных преимуществ существования стабильной среды разработки для любой технологии, но является ли Веб стабильным, или же он находится в застое? Постигнет ли Веб без инноваций такая же участь, как и любую другую технологию, что перестает следить за изменением пользовательских предпочтений и становится устаревшей?

Естественно, Веб играет роль, прежде всего, глобального информационного источника, но насколько хорошо при этом функционируют сами Веб-технологии? Чтобы ответить на этот вопрос, мы должны рассмотреть ряд проблем, которые существуют в Вебе:

Примечание: статья посвящена обзору проблемы неработающей кнопки «назад» в браузере при использовании AJAX-методов для передачи содержания страниц от сервера к клиенту. В статье рассматриваются основные принципы работы AJAX и возможные пути решения заявленной проблемы. Курсивом даны мои комментарии.

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

Интернет-бизнес всегда отличался молодостью тех, кто им занимается. Основатели Yahoo, Google и eBay — это всё недавние студенты, ребята чуть за 20 лет. Но, похоже, возрастной порог снижается ещё больше. В Америке появляются тинейджеры, которые основали успешный бизнес и заработали свой первый миллион в возрасте 16-17 лет.

Например, вот интервью с американкой Катрин Кук, которая в 17 лет сделала молодёжный сайт MyYearbook. Всего за полтора года аудитория сайта выросла до 3 млн человек в месяц, доходы от рекламы — до нескольких миллионов долларов в год. Только что появились и венчурные инвесторы, которые профинансировали стартап на $4,1 млн.

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

Почему? Потому, что тогда еще небыло Linux Media Center Edition.


linuxmce.org

В свое время я прибывал в уверенности, что код
js обычно не нужно писать так, чтобы он был
наиболее оптимальным. «Клиентская часть» — говорил я, — «на сервер никак не
повлияет, а посему, можно забить». К сожалению, оказалось, что это не совсем
так.

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

Примечание: ниже перевод статьи «How JavaScript is Slowing Down the Web (And What To Do About It)», посвященной, в основном, работе с виджетами: характерные проблемы и методы их решения.

Одна строка JavаScript является основой большинства текущих технологий, которые используют авторы блогов. Виджеты, средства (фото-/видео-)обмена, отслеживание посетителей, рекламные объявления. Во многих случаях единственная строка JavaScript — это все, что нужно автору, чтобы добавить в своей блог что-то новенькое. Проблемы начинаются тогда, когда много-много этих самых строчек собирается вместе...

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

Skype претерпел главный перерыв в обслуживании, который начался сегодня примерно в 14:00 часов по Московскому времени.

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

На www.dontclick.it предлагается вариант интерфейса без кликов. Представлены обоснования подхода и возможные варианты замены кликов обычными движениями мышкой. Ощущается необыкновенно легко.

Один чувак запостил это в рассылку по юзабилити GNOME. Что вы думаете насчёт такого интерфейса вообще? В вебе? На рабочем столе? При работе с прикладными программами?

Единственное, что имеет значение

Предыдущие части: Первая часть, Вторая часть, Третья часть

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

Но для начала немного теории.

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

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

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

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

И вот вы задаетесь вопросом — что же больше соотносится с удачей: команда, продукт или рынок? Или, если более точно, то что же ведет к успеху? Или, для тех из вас, кто является студентами в неудачах стартапов —

Компания HP совместно с исследовательским подразделением HP and the Economist Intelligence Unit (EIU) провели чрезвычайно любопытное исследование: сколько IT-проектов завершаются точно в срок. Результаты показаны отдельно по странам, и это очень интересные результаты.

Конечно же, дело не столько в недисциплинированности самих программистов, сколько в недостаточном профессионализме менеджеров. Именно менеджеры всегда виноваты в срыве сроков, а не программисты. Собственно, об этом говорит и анализ причин задержки проектов (под хабракатом).

Швеция — 44%
Швейцария — 24%
Чехия — 20%
Германия — 19%
Дания — 16%
Великобритания — 11%
Израиль — 8%
Финляндия — 8%
Франция — 6%
Бельгия — 4%
Испания — 4%
Италия — 4%
Нидерланды — 4%
Россия — 4%

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

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

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