Речь в данном посте пойдет не о том, как непосредственно заработать. Этому посвящена добрая половина постов на хабре о стартапах. А тому, как люди ищут способы заработка и обогащения.
Однажды я ради интереса изучал спрос на «халявные деньги» в статистике Яндекса и Рамблера. Чтиво одной только статистики, надо заметить, очень веселое.

Примечание: ниже находится перевод статьи «Simply said...How To Blog», в которой автор описывает собственный успешный стиль ведения блога и дает несколько практических советов по организации работы.

Однажды я получил письмо от одной из своих читательниц (Celeste), в котором та писала:

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

Новое здание редакции NYTimes спровоцировало некоторых мыслителей на интеллектуальные дискуссии о том, как связаны архитектура офисных зданий и веб-дизайн информационных сайтов. Если подумать, то эти две сферы во многом пересекаются.

Интересно, что в обеих этих областях происходит бурный прогресс. Например, посмотрите на эволюцию первой страницы газеты LATimes.com с 2002 по 2006 годы. Видно, как резко возрастает количество графики (жёлтый цвет) и рекламы (оранжевый цвет) на страницах сайта.

Самые лучшие и самые худшие решения (часть первая).

Чтобы запустить свой новый блог, StartUpping, я задал многим успешным интернет-предпринимателей вопрос — чему они научились, открывая и поддерживая работу своих интернет-компаний. Я спросил об их самых лучших и самых худших решениях, и получил много практичных ответов. Вот первая серия ответов.

Известный программист и предприниматель Пол Грэхем, создавший в 1995 г. первое в интернете интерактивное веб-приложение (которые нынче считают приложениями Веб 2.0), дает советы о создании интернет-стартапов. Точнее, это предостережения об ошибках, которые не нужно совершать. На своем сайте он опубликовал список из 18-ти ошибок, которые смертельны для стартапов.

Предлагаю к прочтению очень интересную статью по поводу Веб 2.0 и его будущего.

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

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

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

Здесь нашел.
Чего нашел? А вот что:

AUDIO 2.0
Bebop — Compare music calendar against your iTunes catalogue. www.bebopular.com
Clickcaster — Record, license, publish & promote your radio show. www.clickcaster.com
Difm — Radio community. www.di.fm
Dottunes — Share your iTunes. www.dottunes.net
Enablr — Transcribe podcasts, Text2Snailmail,… www.enablr.com
Fluctu8 — Create & share your sourcelists. fluctu8.com
Gcast — Podcasting tools & hosting. www.gcast.com
Genielab — Explore, recommend & rate music. genielab.com
Ituneslove — Share your music tastes. www.ituneslove.com
Jamendo — Review, tag, rate & share music. www.jamendo.com/en
Lastfm* — Profile your taste, share, personalize your radio. www.last.fm

Компания Font Bureau разработала новое семейство шрифтов Input, важнейшим из которых в данном случае для нас является шрифт Input Mono. Кириллица присутствует. Для персонального использования шрифты бесплатны.

Перевод статьи «JavaScript insertAdjacentHTML and beforeend», David Walsh.

Если вы не знали: чертов DOM очень медленный. А по мере того, как наши сайты становятся все более динамичными и AJAX-использующими, нам становиться все важнее управлять DOM древом с наименьшим ущербом в производительности. Недавно я написал статью о DocumentFragment'ах. Это разумный подход к объединению списка дочерних элементов под неким «псевдо-элементом», для дальнейшего помещения в реальный DOM элемент. Еще один замечательный метод для работы с элементами insertAdjacentHTML: это способ добавлять элементы в родительский элемент не задевая других его потомков.

Образы Docker могуть быть очень большими. Многие превышают 1 Гб в размере. Как они становятся такими? Должны ли они быть такими? Можем ли мы сделать их меньше, не жертвуя функциональностью?

В CenturyLink Lab мы много работали над сборкой различных docker-образов в последнее время. Когда мы начали экспериментировать с их созданием, мы обнаружили, что наши сборки очень быстро раздуваются в объеме (обычным делом было собрать образ, который весит 1 Гб или больше). Размер, конечно, не столь важен, если мы говорим про образы по два гига, лежащие на локальной машине. Но это становится проблемой, когда вы начинаете постоянно скачивать/отправлять эти образы через интернет.

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

Пару лет назад на Хабре проскакивало две статьи, в которых упоминался интересный алгоритм. Статьи, правда, были написаны нечитабильно. В стилистике «новости»(1, 2), но ссылка на сайт присутствовала, подробно можно было разобраться на месте (алгоритм за авторством MIT). А там была магия. Абсолютно волшебный алгоритм, позволяющий увидеть незримое. Оба автора на Хабре этого не заметили и сфокусировались на том, что алгоритм позволял увидеть пульс. Пропустив самое главное.



Алгоритм позволял усиливать движения, невидные глазу, показать вещи, которые никто никогда не видел живьём. Видео чуть выше – презентация c сайта MIT второй части алгоритма. Микросаккады, которые приведены начиная с 29ой секунды, раньше наблюдались только как отражения установленных на зрачках зеркалах. А тут они видны глазами.
Пару недель назад я опять натолкнулся на те статьи. Мне сразу стало любопытно: а что народ сделал за эти два года готового? Но… Пустота. Это определило развлечение на следующие полторы недели. Хочу сделать такой же алгоритм и разобраться, что с ним можно сделать и почему его до сих пор нет в каждом смартфоне, как минимум для измерения пульса.

В статье будет много матана, видео, картинок, немного кода и ответы на поставленные вопросы.

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

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

Ошибка #1 — Идея

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

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

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

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

TL;DR — за два года маленькая команда из 2 человек (я как «строитель», и мой московский друг как главный конструктор) сумела спроектировать раму и механику дорожного электробайка, а так же построила его первый прототип. Собственно, на КПДВ — именно этот самый прототип, да. Видео тестовых покатушек — в конце статьи.

Если вам интересна история его создания — прошу под кат.

В продолжении популярного цикла статей о том, что 30 строк джаваскрипта достаточно каждому, предлагаю Вашему вниманию перевод статьи Мэтью P01 Генри о его последней работе:

Нельзя просто так взять и рассказать про progressive enhancement, не упомянув о graceful degradation. В чем же разница между этими понятиями? Как уже говорилось в более ранней статье, graceful degradation можно перевести, как отказоустойчивость. Это очень широкое понятие, но в контексте веба его можно понимать как отказоустойчивость клиентских веб-интерфейсов, серверной части сайтов и так далее. В этой статье graceful degradation будет пониматься как отказоустойчивость клиентских веб-интерфейсов.

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

Предисловие от переводчика

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

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

Статья будет полезна как для видавших виды «поваров», так и для новичков.

AutoCAD начала 80-х

Зум появился очень давно, на заре эры графических интефейсов, с первыми векторными редакторами.
Но с тех пор он не был использован почти нигде, кроме САПР и программ для работы с графикой. Про него вспомнили только когда появились мобильные устройства — на маленьком экране не умещались большие фотки и веб-страницы.
В мобильных интерфейсах зум стал вполне привычным и естественным и продолжает эволюционировать. Но на десктопе зум заброшен и, на мой взгляд, совершенно напрасно. Zoomable user interface (ZUI) даёт ряд преимуществ, позволяющих лучше решить актуальные задачи. Я решил описать эти преимущества по типам зума, с примерами.

Sortable.js — минималистичная библиотека для современных браузеров и touch-устройств, не требующая jQuery.

Как вы уже догадались из названия, библиотека предназначена для сортировки элементов при помощи drag’n’drop. Стандартным решением в таких случаях является jQuery UI/Sortable, а это ни много, ни мало 64 кб + 10 кб. Итого 75 кб gzipped в проекте, где jQuery не используется совсем. Относительно недавно на Хабре уже была статья о том, как реализовать похожий функционал, но опять же на jQuery, да и touch-устройства в предлагаемом решении не поддерживаются.