Перевод статьи «The Art of Spending Minutes to Save Hours».

Радостные часы прошлой пятницы я провел, выслушивая признания своей коллеги по поводу ее абсолютной неприязни меню «Пуск» Windows Vista. «Система организована неверно. Нужные мне программы глубоко зарыты, а все удобные места занимают никогда мной не используемые. Я столько времени трачу, копаясь в меню,» — жаловалась она. «Но ты можешь просто переупорядочить их,» — ответил я. Она опустила глаза: «Знаю. Кто-то мне уже говорил это, но я не успела попробовать.»

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

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

Под катом я расскажу как мы тестируем мобильные приложения.

19 августа 2009 года, в 12:30 Том Леман написал первую строчку кода задуманного им проекта Rap Genius, посвященного трактованию рэп-текстов. А уже в 18:22 того же дня была готова первая версия веб-сайта. Менее шести часов потребовалось на то, чтобы создать сервис, куда сегодня каждый месяц заходят 40 миллионов новых пользователей, который привлек уже 17 миллионов долларов венчурных инвестиций, и вокруг которого недавно разгорелся интернет-скандал, разрешившийся в пользу проекта и сделавший его ещё более популярным.

В первый же день, разложив по полочкам песню Killa Cam в исполнении рэпера Cam’ron, Леман внедрил те функции, которые до сих являются самыми востребованными. Конечно же, мы были просто обязаны позвать его выступить на последней конференции Design+Startup, проходящей под патронажем фонда First Round. На этой встрече Леман поделился теми четырьмя словами, благодаря которым Rap Genius смог состояться.

«Первая версия Rap Genius была просто отвратительна. Но благодаря этой отвратительности я узнал секрет, как нужно делать вещи в интернете. Секрет простой: чем хуже, тем лучше».

Что же это значит на практике? Том Леман с удовольствием рассказывает нам об этом.

Как и у многих пользователей macbook в моей жизни настал момент когда мой MagSafe коннектор перестал корректно работать(только под определенным углом), а затем и вообще перестал заряжать.

Немного поискав по рунету нашел несколько инструкций по ремонту старых MagSafe адаптеров, про ремонт Г-образного толком нечего не было. Решил ремонтировать сам, так как стоимость нового у нас в районе 80$.
Подвожу итог: я сделал свой и позже еще 2 купленных по 15$ за каждый (один теперь на работе, 2-й который был почти новый подарил). Небольшая инструкция по ремонту внизу:

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

Zephir — Ze(nd Engine) Ph(p) I(nt)r(mediate). Зефир — это компилируемый высокоуровневый язык программирования, предназначенный для написания PHP расширений без использования C. Проект от создателей Phalcon (скомпилированный PHP MVC Framework). О Zephir на Sitepoint
   

JSDB.IO — большая и качественная база нужных скриптов/библиотек/фреймворков на JavaScript. Все распределено по категориям: Animation, Application, Audio, Video, Games и др. Дабы собрать все популярные .js воедино добавлю еще три ссылки: Microjs (множество маленьких полезностей до 5кб), а еще jsdelivr и cdnjs, которые позволяют добавлять собственные скрипты.

Snap.svg — продукт от Adobe Webplatform. Недавно я рассказывал про "достойного конкурента Raphaël" и в комментариях оспоривали эту фразу из за отсутствия поддержки такого же множества браузеров. В разработке Snap участвует автор Raphaël — Дмитрий Барановский, а причина создания новой библиотеки для работы с SVG — невозможность поддерживать все возможности SVG в старых браузерах.

At.js — очень юзабельный скрипт для автозаполнения (в демо используется Emojify). А еще есть более функциональная библиотека для автозаполнения — Typehead от Twitter.

$('.atwho-inputor').atwho({
  at: "@", data: ["one", "two", "three"],
});

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

UPD: получил инвестиции под свой проект в сфере обучения облачным технологиям

Здравствуйте уважаемые Хабравчане, особенно те, у кого есть идея своего стартапа! А вот с деньгами и осведомленностью похуже. Хочу Вам в помощь поделиться небольшой таблицей IT-инвесторов, которая была составлена для себя. Дело в том, что я также как и вы, обладаю минимум информации. Такие вопросы как: «к кому идти за деньгами», «как составить бизнес-план», и наконец «кому я вообще нужен со своей идеей» — давно стали навязчивыми.
Именно сейчас, после Новогодних праздников, самое время начать искать тех самых менторов, инвесторов, бизнес-ангелов, да и в целом зачитываться информацией на эту тему. Да, и у меня есть свой стартап, который перестал быстро развиваться и я активно ищу инвестора на дальнейшее развитие (О чем уже писал неделю назад).
Под катом таблица, со списком полезных ссылок, в помощь начинающим IT-компаниям.

На Хабре в свое время было несколько статей «Очень много полезных штук для AS3». Автор попытался собрать ссылки на самые полезные и интересные библиотеки. И т.к. в последнее время я разрабатываю под iOS, решил последовать его примеру и сделать то же самое, но для своей платформы. Описания почти прикладывать не буду, все есть на страничках проектов.

На Хабре уже были статьи про TestFlight (вот тут и тут), но в них речь шла главным образом про его использование и интеграцию/автоматизацию в процесс сборки. А мне всегда было интересно, как это работает изнутри:
• Как происходит сбор идентификаторов устройств? (Если вам непонятно, зачем собирать UDID’ы, пройдите по ссылкам выше)
• Как приложение устанавливается по переходу по ссылке?
• Как создается иконка на Home Screen?
• Все это хаки или легальные способы?

Если вы хотите построить свой TestFlight c блэк-джеком и всем остальным или просто интересуетесь, как сделано что-то из вышеперечисленного, – прошу под кат.

В компании где я работаю наступила пора корпоративов тестирования нашего iOS приложения, и т.к. мако тут только у меня, а все остальные разработчики и, что самое главное, QA работают под Ubuntu, <irony>а значит айфонов у них нет</irony>, то пришлось придумать решение проблемы и избавить себя от мук передачи личного айфона в руки тестеров.

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

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

Intro

До начала изучения Objective-C я программировал сначала на PHP, потом на Python и Ruby. Ruby мне понравился больше всего. Понравился своей простотой, лаконичностью, но в тоже время и мощностью. А около недели назад у меня наконец-таки получилось завести хакинтош на своем компьютере (сейчас у меня Macbook Early 2008 Black). Это оказался OS X Lion Golden Master. Я знал, что приложения для маков и айфонов пишут на Objective-C, даже пытался его выучить, но без OS X это было неприятно, что ли. Поставив Xcode 4.2 (я уже зарегистрированный iOS разработчик), написал несколько очень простых консольных приложений. И каждый раз когда я следовал какому-то туториалу, или просто пытался сам писать код, мне приходило в голову то, что, оказывается, Ruby и Objective-C имеют много общего (хотя это логично, так как оба языка были сделаны под влиянием Smalltalk), несмотря на то, что у этих двух языков совсем разные предназначения.
Итак, здесь я опишу некоторые вещи, которые помогут программистам на Ruby понять Objective-C, по большей части теоретические, без кода. Так же прошу прощения, если некоторые вещи будут объяснены не совсем по-сишному, я же пришел из мира Ruby.

Недавно я столкнулся с необходимостью реализовать небольшой чат в одном из Rails-проектов. Существует много способов решения данной задачи, начиная от периодических опросов сервера с помощью AJAX и заканчивая использованием готовых решений сторонних сервисов. С целью минимизации трафика и времени отклика системы было принято решение использовать WebSocket API – одну из частей стандарта HTML 5, позволяющую серверу инициировать передачу данных, не дожидаясь запроса клиента. К сожалению WebSocket API поддерживается достаточно ограниченным числом браузеров, среди которых Google Chrome, Safari 5, Mobile Safari в iOS 4.2 и выше и пожалуй все (если я ошибаюсь – поправьте меня в комментариях). Конечно же этого недостаточно для боевого приложения, поэтому необходимо предложить запасной вариант для браузеров без нативной поддержки WebSocket API. Удобнее всего в этом случае использовать Flash Sockets. С помощью WebSocket API и Flash Sockets приложение покрывает большую часть возможных случаев, включая как настольные системы (MS Windows, Linux, Mac OS X), так и мобильные (Android, iOS).

Доброго времени суток.
Многим web-программистам рано или поздно нужно работать с видео. Такая задача возникла и у меня.
В Интернете есть много статей на форумах и блогах, как на русскоязычных, так и на зарубежных сайтах. Но, проделавши, так же как и предлагалось в инструкциях — результата ожидаемого не дало. Что и послужило поводом для этой статьи. Думаю, она поможет таким же как и я многим начинающим.

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

Если вы сами проводили конкурсы и всё было ок — не читайте топик. Если где-то ждал облом — добро пожаловать под кат.

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

Бытует мнение, что программные системы, будучи объектом не совсем материальным, не поддаются старению. И если говорить о старении физическом, то действительно, шансы на то, что буковка “o” в имени класса вдруг от старости ссохнется и превратится в букву “c” – действительно малы. Но вместо старения физического, программные системы стареют морально.  Со временем накапливается груз ошибок за счет неточностей в исходных требованиях, непонимания требований самим заказчиком, архитектурных ошибок или неудачных компромиссных решений; да и ошибки поменьше, типа слабопонятного кода, его высокой связности, отсутствия юнит-тестов и комментариев делают свое черное дело. Все это приводит к накоплению технического долга (о котором шла речь в прошлый раз), из-за которого при добавлении новой возможности в систему приходиться платить «проценты» в виде более высокой стоимости реализации и более низкого качества получаемого результата.

Оригинал опубликовал Лео Бабаута на сайте Zen Habits. Я его вольно перевел и немножечко адаптировал. Сразу оговорюсь, я не претендую на точность перевода. Моей задачей было перевести не точно, а понятно. Приятного чтения и применения!

«Это про привычки и делание, а не про систему и инструменты»

Чтобы закрепить основы продуктивности и организованности, сохраняя всё настолько простым, насколько возможно, я разработал свою собственную систему продуктивности: Zen To Done (ZTD).

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

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