^{Бизнес-ангел часто смотрит на стартаперов с недоумением}

Предположим, вы придумали какое-то железо, и теперь хотите начать его производство. У вас уже есть прототип: вот он, в руке, коряво выглядит, в 4 раза больше нормального размера и из него торчит провод. Но он работает. У вас горят глаза: ведь осталось только «допилить» его и начать производить по всему миру. Из маркетингового плана у вас есть только «запостить про железку на Хабр – и всё закрутится».

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

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

Вступление

Приветствую, хабравчане!

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

Сразу предупрежу, что я стараюсь шагать в ногу со временем, поэтому примеры будут под iOS >=5.0 и использовать Storyboard и ARC, но ничего не мешает их портировать на 4.*.

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

Заинтересовавшимся — прошу под кат (Пост содержит скриншоты областей Interface Builder-а, поэтому предупреждаю о траффике).

Здравствуйте! Мы — команда ниндзя-разработчиков проекта ninjamock.com. Ninjamock.com — это еще один онлайн-дизайнер скетчей и прототипов. Проект полностью написан на javascript и HTML5, серверная часть — на ASP.NET MVC.

За год работы над проектом мы наступили на огромное количество граблей и накопили бесценный опыт разработки больших приложений на JavaScript, которым и хотим поделиться. В этой статье мы расскажем, как прототип из одного файла index.html перерос в полноценный проект с более чем 250 классами и 60000 строк кода (не считая сторонних библиотек). Также, в общих чертах опишем нашу архитектуру и детально опишем реализацию отрисовки на клиенте.


UPD: Следите за апдейтами на нашем твиттере или странице фб

В последнее время мои коллеги начинают знакомство с git'ом. И один из интересующих их вопросов — как откатиться до определённой ревизии. В интернете можно найти набор команд, но хочется, чтобы было понимание каждой из них. Баловство с комадами git'а без понимания может привести к потере истории разработки.

В этой статье я хочу рассказать о командах git checkout и git reset с ключами --soft и --hard.

Давно назревало желание написать парочку статей, в которых я смогу выложить свой опыт и знания на тему оптимизации игр под ARMv7 архитектуру CPU и PowerVR SGX 5 серию GPU, читай iOS платформу. Но все, или почти все, советы в равной степени применимы под другие системы с тем же железом, читай Андроиды. Данный материал в может быть применен не только в играх но и в большинстве ресурсоемких приложений — обработка изображений, аудио, видео и т.д. Начну свою первую статью с наиболее важной, ИМХО, оптимизации – векторизации кода под NEON.

Эта статья началась как доклад, на конференцию, которая состоится 24.11. Кладезь советов по оптимизации под iPhone можно найти здесь. Следующие статьи будут развивать в ширь и глубь темы материала из этой презентации.

Статья представляет собой вольный перевод руководства по работе с Apple Push Notification Service сайта raywenderlich.com и некоторые мои дополнения.

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

Но что если происходит что-то интересное и вы хотите сообщить об этом пользователям, даже если ваше приложение у них не запущено?

Объявлено новое соревнование 7400, и нужно сделать что-то новое. Нельзя ударить в грязь лицом после победы в прошлом году ;)

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

Я устроил мозговой штурм с моими товарищами: Педерсеном (Pedersen), Асбьёрном (Asbjørn) и Флеммингом (Flemming), которые тут же придумали множество смешных идей. И вот Флемминг упомянул RFID (он разработчик системы управления доступом, которая основана на RFID). А вот это уже мысль. Конечно, первые мысли были об RFID-считывателе, но мы уже собрали их довольно много, и это было скучно. Однако, появилась идея сделать RFID-метку. Я не знаю, кто упомянул это первым, и, как обычно в мозговом штурме, идеи рождаются коллективным разумом. Итак, решено сделать RFID-метку, собранную исключительно на 7400-ой логике.

Всем хабрапривет и хорошего начала продуктивной недели.

У нас для вас отличные новости – новый конкурс с классными призами! Основная тема конкурса – LG Smart TV App’s – то есть приложения для нашей платформы «умного телевидения». Принять участие в конкурсе могут как разработчики, так и простые пользователи подобных систем.

Конкурс для разработчиков на лучшее приложение – это шесть призовых мест и отличный способ убедиться, что платформа LG Smart TV – одна из лучших и одна из самых удобных как для разработчиков, так и для пользователей.
Конкурс для людей, не владеющих никакими навыками программирования – это конкурс актуальных и интересных идей, которые могут быть реализованы в рамках Smart TV и будут отлично дополнять функционал данной платформы.
Правила, подробности и всё самое вкусное – под катом.

Переход на iOS 6, как и выпуск iPhone 5, не совершил революции (разве что с помощью приложения Будильник), а, скорее, стал логичным шагом для развития App Store. Задача усложнилась как для разработчиков приложений, так и для рекламистов. Но когда отпадают одни инструменты, стоит побыстрее искать замену для них.В этой заметке я хочу кратко пройтись по изменениям в App Store и поделиться работающими рекомендациями по продвижению мобильных приложений.



Cогласно http://www.insidemobileapps.com в октябре 2012 года для попадания бесплатого приложения в Top 100 нужны 13 000 закачки в день. Условие попадания в Топ 10 – 54 000 закачки в день. Эта цифра ниже прежней благодаря массовой чистке ботов, но она довольно высока в любом случае (и, повторюсь, боты уже не выручат). Вместо того, чтоб тратить отсутствующие деньги на дорогую промо кампанию, стоит заставить ваше приложение появляться в поиске по первому запросу ключевых слов и радовать потребителя высоким качеством продукта.

Новый App Store заточен под дизайн. Запрос поисковика выдает пользователю несколько приложений, представленных названием, иконкой, звездочками ревью и первым скриншптом. Да, именно по этим параметрам юзер и выберет то, что он захочет скачать.

При выборе названия не останавливайтесь на “бренде” – нераскрученном словосочетании, потому, что оно ничего не скажет потребителю. Будьте лаконичны, понятны и интригующи.

Некоторые из вас, возможно, заметили, что viewControllers больше не запрашивают viewWillUnload и viewDidUnload в iOS6. Это происходит потому, что контроллеры больше не выгружают свои представления (view) автоматически.
Ваша первая мысль может быть «Окей, как я могу вручную выгрузить мое представление при предупреждении о недостатке памяти (low memory warning)? Это выглядит, как шаг назад.»
Затем вы ищите ответы и пишите что-то вроде:

- (void)didReceiveMemoryWarning
{
    [super didReceiveMemoryWarning];
    if([self isViewLoaded] && ![[self view] window]) {
        [self setView:nil];
    }
}

Как опытный менеджер проектов, я часто сталкивался с заявленными программистами сроками выполнения задачи, умножал их на Пи и брал следующий по счету порядок. Так 1 день превращался в 3.14 недель. Я познал на собственной шкуре, что программисты — никудышные оценщики.

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

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

Erica Sadun, The iPhone Developer's CookBook

Дисклеймеры

• Приведенные здесь куски кода работают на обычных iPhone (включая 4S) и iPad (включая new iPad) и не требуют jailbreak.
• Все решения написаны и протестированы на iOS 5. Все решения также протестированы на совместимость с iOS 4.3, т.е. работают с iOS 4, если не сказано обратное. Основная часть статьи была написана до выхода iOS 6, так что приведенные решения не тестировались на совместимость с iOS 6.
• Использование недокументированных API может привести к тому, что ваше приложение не допустят в AppStore. А может и не привести :-)
  Для тех, кому интересно, как Apple опрделяет использование приваетных API:«Как Apple узнаёт, что ты используешь приватные API?»
  
• Apple может изменить реализацию вместе со следующим релизом iOS, и в вашем коде что-то сломается. Впрочем, это решаемо, и ничем принципиально не отличается от реализации обратной совместимости для документированных API. Ниже я рассмотрел эту проблему чуть подробнее.
• Я не могу гарантировать, что у найденных мной API нет побочных эффектов. Используйте на свой страх и риск.
• Лицензионное соглашение Apple Developer Program запрещает реверс-инжинеринг iOS.
• Статья в процессе доработки. Конструктивная критика приветствуется!

Краткая инструкция по поиску в SDK

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

Думаю, во многих командах, так или иначе связанных с разработкой Flex-приложений, рано или поздно возникает вопрос об автоматизированном тестировании продукта. А так, как наша команда занимается разработкой AIR-клиента для online-покера, совершенно закономерно, такой вопрос возник и у нас.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

TryGit — интерактивный обучающий курс по Github в стиле Codecademy. Курс состоит из 25 мини-уроков, которые знакомят пользователя с базовыми понятиями и основными командами git, при этом ученик своими руками вводит команды в консоль, смотрит результат и читает сопровождающие надписи с объяснением происходящего.



Вот таким в будущем должно стать обучение в школах!

Конечно, 15-минутное введение не заменит полноценного учебника. Для обучения можно рекомендовать бесплатную книгу Pro Git и видеокурс Getting Git.

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

Последнее время на Хабре стали появляться статьи про OpenShift, что привлекло моё внимание, ведь платформа действительно интересна и грех в ней не поковыряться, да и так совпало, что я начал задумываться найти альтернативу моему уютному Dropbox-репозиторию Maven в связи с отменой возможности иметь прямые ссылки и папки Public в целом ( пруф: habrahabr.ru/post/145864 ).

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

Сегодня в новостях от CodeProject проскочила ссылка на интересный online-редактор. Позволяет написать написать псевдокоде и получить диаграмму.
Собственно ссылка на codeuml

Я программист. По крайней мере так написано в трудовой книжке. Почти всё своё рабочее время я провожу в консоли и текстовом редакторе. Мне очень нравится bash. Почти год я жил в zsh, прислушавшись к советам своих многочисленных коллег и знакомых, но в итоге я вернулся в bash и ни капельки об этом не жалею.



Zsh красив, приятен, чертовски функционален, но, признаюсь честно, я не смог совладать со всеми его многочисленными настройками. Я хочу работать, а не бороться со своим рабочим окружением. Простой пример: пару раз из-за автодополнения zsh я удалял все директории и файлы в текущей директории — zsh просто ставил пробел между автодополненной директорией и введённой мною звёзочкой (я хотел удалить всё в выбранной папке). Помните тот эпичный баг с пробелом и удалении директории /usr? У меня было то же самое. Спасибо гиту, выручил в который раз.

Впрочем, дело не в zsh — будь я чуточку умнее, я бы с ним обязательно справился бы, и всё было бы хорошо, но мы, суровые программисты, будем использовать bash и vim, а гламурные zsh и textmate оставим хипстерам и прочим модникам ;)

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

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

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

Но поскольку вы спросили, вот внутренние реализации каждой структуры данных Redis:

• Строки реализованы с использованием библиотеки динамических строк C, так что мы не платим (говоря асимптотически) за выделение памяти в операциях добавления. Таким образом мы получаем сложность добавления O(N), вместо, например, квадратичной.
• Списки реализованы как связные списки.
• Множества и Хэши реализованы как хэш-таблицы.
• Упорядоченные множества реализованы как списки с пропусками (особый тип сбалансированных деревьев)