Под катом перевод огромной статьи, написанной Майклом Чёрчем и посвящённой стартапам. Статья вызвала необыкновенное бурление… мнений, скажем так, на разных сайтах и агрегаторах, поэтому я решил её перевести на русский и посмотреть на реакцию. Текст ОЧЕНЬ длинный, но также и очень интересный. И несколько пояснений перед чтением: в статье речь идёт об инженере в стартапе, именно с этой позиции всё рассматривать; некоторые финансово-экономические термины, возможно, не очень адекватно удались и я буду рад любым конструктивным поправкам.

То, о чём я хочу рассказать, справедливо для июля 2012 г. 15 лет назад необязательно было так же, и не факт, что будет справедливо через год. Но в данный момент это абсолютно верно для большинства людей в достаточной степени, так что я считаю обязанным высказаться. Нынешний мир ИК-стартапов (ИК=инвестиционный капитал / venture capital) — я его нежно называю ИК-стан — является, мягко говоря, тотально напрасной тратой времени для большинства вовлечённых людей.

В новом Eclipse Juno (версии 4.2) появилась новая модель построения интерфейса, основанная на UI-плагинах и CSS-подобных стилях оформления. И если раньше часть действий по тюнингу интерфейса можно было делать из настроек, то сейчас там девственно пусто:



Поэтому придётся копаться в CSS-стилях оформления интерфейса (именно CSS-подобные стили сейчас используются в этой среде).

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

Сразу предупрежу, что на API 15 описанный способ не работает, там маркет приложения не скачивает, хотя и ставится.

Сначала краткое описание процедуры:

• создаём виртуальный девайс на основе Google API образа;
• запускаем эмулятор девайса шаманским образом;
• удаляем «лишние» пакеты;
• достаём пакет с маркетом из имеющегося телефона через USB-кабель;
• закачиваем пакет с маркетом;
• финальное шаманство.

Все происходит в линуксе, но в других операционках всё абсолютно так же.

XMind — отличная программа для майндмаппинга, однако быстро начать с ней работать не так просто, почему то никто не озаботился вводным курсом. Поэтому в процессе осваивания интерфейса нарисовал такую вот диаграмму (с упором на использование клавиатуры). Может, ещё кому-то пригодится.



Картинка выше является ссылкой на полную картинку.

Bulkloader — это интерфейс в Google App Engine для загрузки данных из/в хранилище на серверах Google. Bulkloader удобно использовать для бэкапа/восстановления/миграции данных приложения, однако документации и примеров использования катастрофически мало, а на сложном приложении придётся натыкаться на разнообразные проблемы и баги. Сам я довольно долго раскапывал разные источники информации, копался в исходном коде SDK, читал баги, писал свои воркараунды; и теперь готов представить некоторые плоды в виде подробной статьи.

Статья очень большая, имейте в виду.

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

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

И вот хотелось бы понять, какими вообще принципами руководствуются разработчики хрома? Как я понимаю, им глубоко плевать на юзеров, так для кого же браузер делается? Можно, конечно, написать патч и самому собирать (опенсорц же), однако вот такая непонятная и необъяснимая упёртость не делает чести продукту.

Поэтому предлагаю всем, кто желает видеть этот баг пофиксенным, пойти по указанной ссылке и проголосовать за этот баг. Никакого (вообще никакого) обоснования, почему эта фича не будет реализована от разработчиков не поступило, однако количество комментариев явно говорит, что фича востребована. Ещё лучше оставить комментарий с обоснованием, почему это нужно пофиксить именно внутри хрома (там есть весьма развёрнутый комментарий под номером 79 про это). Большое количество «звёзд» на баге уже труднее игнорировать.

btw, на минусы не обращайте внимания, это какие-то озлобленные дети обгадили страницу, пока она у меня висела в персональном блоге.

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

Update по мотивам комментария ниже. Смысл семантической разметки текста (а вики-разметка часто является именно такой) состоит в том, что сразу убиваются как минимум два зайца:

* во-первых, семантическая разметка позволяет генерить из текста что угодно, а html требует дополнительных усилий, например, при глобальной смене дизайна (упрощённо говоря, из разметки сразу получаем что угодно, а из html сразу что угодно не получим при всём желании)
* во-вторых, разметка позволяет использовать единый стиль для всех постов: отступы, цитаты, списки — _всё_ выглядит единообразно.
* в-третьих, разметка легко читается и легко пишется, в качестве примера можно посмотреть редактор комментариев на [Stack Overflow](stackoverflow.com)
* в-четвёртых, текстовая разметка позволяет легко сравнивать версии документов, для хабра это неактуально, но тем не менее.

P.S. абзац выше написан с использованием текстовой разметки. Читается и пишется ГОРАЗДО лучше html.

Мой перевод статьи Сары Шерд “Life Cycle of a Silver Bullet”, 2003 г.

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

---

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

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

Update Почему-то для некоторых читателей общая идея статьи оказалась непонятной, поэтому пропишу явно: идея в том, чтобы показать некоторые конкретные примеры применения известных атак (если можно это назвать «атакой», конечно) в именно linux-окружении. Linux — ничуть не безопаснее в некоторых аспектах, чем другие системы.

По какой-то загадочной причине imap.gmail.com отдаёт результаты запроса группами по 100 штук, делая паузы между группами в несколько секунд. Выжимают imap-клиентов что ли? Получение хедеров папки из 10 000 писем занимает минут пять.

Давно уже наблюдаю дикие тормоза работы imap-клиентов с гмылом, но только сейчас дошли руки посмотреть, что же там творится на самом низком уровне. А творятся там тормоза. Информация отдаётся пачками по сто записей ровно.

Негодую.

Оператор сравнения (==) в JavaScript не является транзитивным. Переводя с математического, это означает, что из того, что a==b и a==c не следует, что b==c.

Простой пример:

var a = "строка";
var b = new String(a);
var c = new String(a);

alert(a==b); // true
alert(a==c); // true
alert(b==c); // false

В чём же дело? А дело в том, что переменные b и c — это объекты (причём разные), а a — примитивное значение (строковой литерал). Две переменных-объекта считаются неравными, если они ссылаются на разные объекты. При сравнении же примитивного значения и объекта используются другие правила — всё приводится к строкам и затем сравнивается.

Чем это чревато? Чревато очень трудноуловимыми ошибками. С точки зрения программиста примитивное значение типа string и объект, созданный из строки конструктором String(), практически неотличимы, и даже во многих книгах этот момент упоминается мимоходом, без конкретных примеров.

Аналогичная ситуация и с другими примитивными типами и соответствующими объектами, например, Number.

Так что будьте осторожны при сравнивании двух переменных!

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

Собственно главных целей две: актуальная информация о совместимости и удобный для правки и обновления формат исходных текстов документации. Побочные (но тоже важные) цели: стилистическая единообразность всех текстов, корректные и многочисленные примеры использования, отдельно выделенные разнообразные тонкости и возможные грабли.

Предварительный набросок можно посмотреть тут:

morg.regolit.com/js-ref/core/array.html

Ну, и самая мажорная цель — совместная работа над материалом. Хостинг есть, mercurial уже настроен. Однако объём работы титанический, один из самых геморройных моментов — определение межбраузерной совместимости. Стоит ли вообще игра свеч?

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

П.П.С.
Пока в персональном блоге, поскольку идея пришла в голову буквально несколько часов назад и ещё толком не оформилась.

Написал в своём блоге детальный мануал, как создать и вывести в веб через apache2 собственный mercurial-репозиторий на сервере с debian. Наверное, сгодится и для убунты.

Постараюсь по возможности обновлять одновременно и в блоге и тут, но блог приоритетней. Сразу прошу прощения за нераспарсенные блоки <code>, в блоге markdown, а тут html, парсер не хочет понимать сгенерённый html, так что не обращайте внимания на <code> и </code>

Так, на всякий случай, вдруг кому где пригодится.

Средствами юникода существует четыре способа написать букву «ё».

Во-первых, по-русски: ё. В юникоде символ обзывается U+0451 CYRILLIC SMALL LETTER IO.

Во-вторых, не по-русски: ë. В юникоде: U+00EB LATIN SMALL LETTER E WITH DIAERESIS

Ну, и в-третьих, можно использовать комби-символ на русской (е) или латинской (e) буквах: ё ë. Выглядит малость неряшливо, но иногда способно прокатить.

Уже и не знаю, что делать. Какой-то фантастический маразм. Хабр практически неработоспособен в опере на eee pc 900. На главном ноуте и на ееепц практически один набор софта (debian linux testing), вот только на ноуте хабр работает, а на ееепц — нет. Самая частая проблема — не работают гиперссылки. Чуть менее частая — молча не добавляются комментарии. Отключение жаваскрипта делает ссылки опять рабочими, так что очевидно, что проблема где-то с жаваскриптом. Но, почему на ноуте этих проблем нет?!

Проявляется как в девятой, так и в десятой версиях.

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

xkeyboard-config с версии 1.5 содержит дополнительный уровень с полезными юникодными символами, который можно прилепить к любой раскладке. Собственно, я поучаствовал в процессе его добавления туда. Этот набор символов был написан несколько лет назад под впечатлением от раскладки Ильи Бирмана, потом постоянно переделывался и стабилизировался.

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

Охвачены практически все аспекты: планирование проекта, вижн, сбор требований, разработка, дизайн и архитектура системы, реализация, тестирование, установка, техподдержка и сопровождение. Шаблоны созданы в очень ясном XHTML/CSS формате.

Хотя все шаблоны и документированы, они довольно компактны и требуют некоторых начальных знаний по процессам разработки. Существует также PRO-версия проекта, в ней шаблоны сконверчены для использования в MS Office форматах, а также добавлены несколько дополнительных документов.

Ресурс чрезвычайно полезный. Всё по-английски. BSD License.

Стартап.

Белая страница. В верхнем левом углу логотип и название стартапа. В верхнем правом углу фамильярное, с претензией на йумор предложение залогиниться или зарегистрироваться. Если стартап илитный, то фраза про инвайты.

Посередине страницы прямоугольные ссылки на блоки стартапа с иконками. Справа колонка: сначала теги контента стартапа, потом ещё теги (типа top-30 херушек), затем блок с аватарами юзеров.

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

p.s.
Это всё к чему: меня достали все эти постоянные анонсы о «стартапах». Хоть фильтр для браузера пиши, чтобы этот поток фильтровать.

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

Upd 1: изменил несколько категоричное утверждение о несходстве паттерна Декоратор и одноимённой языковой конструкции на более мягкое.