Привет. Самый известный инкубатор полным ходом представляет своих птенцов, предлагаю вам обзор лучших по мнению TechCrunch.

65 стартапов были продемонстрированы на традиционном демо дне Y Combinator, мы ознакомились с 39 предложениями и готовы рассказать свои впечатления вам. После ознакомления с командами и техническими особенностями, TechCrunch готова выбрать TOP-10. Меняющие принципы коммерции, помогающие нам общаться и многое для вашего телефона.

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

Понимание процессов происходящих «под капотом» DirectX всегда было сопряжено с некоторыми трудностями и вынуждало применять дополнительные инструменты, например такие как Pix. Но прогресс не стоит на месте, многие идеи и готовые решения теперь внедрены в Visual Studio 11 beta. Этот инструментарий позволяет значительно упростить отладку DirectX приложений и дать программисту возможность детально разобраться в тех процессах, которые формируют изображение. Теперь каждый пиксель может быть досконально изучен, и получена вся история его жизни.

Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.

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

В качестве примера взял иконку из текущего проекта.
Сервис Rizzoma — это система коллаборации, альтернатива Google-wave.
В ходе работы над сайтом родилась идея сделать красивые иконки для каждого блока с преимуществами сервиса. Улитка символизирует контекстные сообщения и по сути своей является продвинутым символом @

При работе с текстом часто возникает потребность корректно расставить переносы. Задача на первый взгляд не такая уж очевидная, нужно учитывать особенности каждого языка, чтобы решить, в каком месте разорвать слово. Как правильно формализовать такие требования, и как потом применить их в алгоритме? Одно из самых распространенных на сей день решений предложил Франклин Марк Лян, студент известного профессора Дональда Кнута. Алгоритм так и называется – «Алгоритм Ляна-Кнута», он применяется в издательской системе TeX, автор которой опять же Д. Кнут.

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

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

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

Мы будем под кэшированием понимать сохранение результатов вычислений в ответ на некоторые запросы. То есть, повторный результат запроса не всегда вычисляется заново, но иногда берется из таблицы, называемой кэшем. Сложно переоценить роль кеширования в современных системах. При этом часто возникает проблема, связанная с недостатком памяти. Действительно, что делать, если запросов много, а памяти хватает лишь для хранения ограниченного числа результатов? В этом случае, как правило, кеш стрится следующим образом. Фиксируется размер кэша, пусть будет N, и сохраняются результаты только для N самых «популярных» запросов.

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

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

Множество удобных инструментов, найденных командой популярного онлайн журнала SmashingMagazine, приводится под катом

Мы все знаем, что в мире создано несколько тысяч языков программирования. Один только список программ Hello, world с сайта Wikibooks включает в себя 230 категорий (полный список на сегодня состоит из 402 элементов). При этом известный рейтинг TIOBE подтверждает очевидное соображение: основная масса этих языков скорее мертва, чем жива. Уже на долю первого десятка языков приходится 76,77% всех учтённых TIOBE проектов. Второй десяток увеличивает эту долю до 85,61%. Стало быть, на оставшиеся 30 языков (TIOBE учитывает лишь первые 50 языков при расчёте процентов) приходится менее 15% упоминаний.

Понятно, что рейтинги заключают в себе некоторую долю лукавства, поскольку даже непопулярный по общим цифрам язык может быть крайне важен для какой-либо узкой сферы. Возьмём любимый здесь многими Erlang или Haskell (39-е и 41-е места рейтинга) или ещё более очевидные Simulink и LabVIEW, вообще не попавшие в Top 50, но незаменимые в своих областях. С другой стороны, очевидно, что языки действительно приходят и уходят, и популярность, скажем, Паскаля обречена на снижение, поскольку на смену идут более прогрессивные языки, метящие в ту же нишу. (Не будем упоминать здесь Delphi, в котором от Паскаля остался разве что базовый синтаксис. У традиционного паскалиста листинг на Delphi может вызывать такой же ступор, какой у меня вызвала первая увиденная мною программа на Visual Basic 6, с этими Private и Public, Option Strict и Dim As, напрочь отсутствовавшими в родном Бейсике ZX Spectrum.)

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

Как проекты попадают на витрину App Store, почему разработка под iPhone – это не дешево и не быстро, зачем нужны апдейты и о многом другом рассказал Эмерик Тоа, креативный директор и со-основатель независимой студии The Game Bakers, разработавшей ролевую игру SQUIDS.

Миф первый: повсюду так много iPhone-ов и iPad-ов, что приличная игра уж точно тебя озолотит



Легко ошибиться, когда делаешь серьезные расчеты, сидя за чашечкой кофе со своим приятелем: «Так, в App Store 200 млн юзеров. Тебе нужно заинтересовать своим приложением за 1 бакс всего 0,1% от них, и у тебя в кармане будет 200 тысяч зеленых».

На самом деле все несколько иначе.

Думаю, многим разработчикам на управляемом коде всегда интересовало: сколько же байт занимает экземпляр объекта? А каков лимит размера одного объекта в CLR? Существуют ли различия в выделении памяти между 32-битными и 64-битными системами? Если данные вопросы для Вас не пустой звук, тогда прошу под кат.

Какие проекты становятся самыми успешными на App Store и почему, зачем нужно фичерение, и что такое «джекпот»-игра, – обо всем этом в нашем новом материале.

UPD: статью можно послушать в виде подкаста здесь

Мы продолжаем публиковать самые любопытные отрывки из статьи Эмерика Тоа, креативного директора и со-основателя независимой студии The Game Bakers. В своем объемном материале Эмерик делится наблюдениями о рынке мобильных приложений на iOS.

Отладка любой программы сложна сама по себе и что бы, ее хоть как то облегчить – можно воспользоваться визуализаторами для Visual Studio (Debugger Visualizers).

Визуализатор – это компонент пользовательского интерфейса отладчика Visual Studio. Он создает диалоговое окно или другой элемент интерфейса, в котором переменная или объект отображается осмысленным образом, подходящим для этого типа данных. Например, HTML-визуализатор интерпретирует строку HTML и отображает результат в том виде, в каком она будет выглядеть в окне обозревателя, визуализатор точечных рисунков распознает структуру точечного рисунка и отображает его и т. д. Некоторые визуализаторы позволяют не только просматривать, но и редактировать данные.

Отладчик Visual Studio содержит четыре стандартных визуализатора. Это визуализаторы текста, HTML и XML, которые работают со строковыми объектами, и визуализатор наборов данных, который работает с объектами DataSet, DataTable и DataView.

Кроме стандартных визуализаторов из поставки Visual Studio, существуют еще и другие — вот о них и пойдет речь дальше.

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

В этой статье мы хотим поделиться нашим впечатлением и опытом о разработке двух интерактивных книг для детей: «История о Мисс Моппет» и «Сказка о Котёнке Томе».

Начнём с того, что отметим: самое важное в книге – это текст. Именно поэтому для книг очень важным является перевод, а применительно к приложениям на App Store: для книг-приложений, очень важна качественная локализация.

Читая книгу-приложение, дети и родители больше всего внимания обращают на интерактивность, на анимацию, на красочность и яркость картинок, и в последнюю очередь на буквы. Однако в отличие от англоязычных детей, для которых стараются разработчики всего мира, русские дети не так избалованы наличием на App Store интерактивных книг на русском языке с озвучкой, то есть книг для самых маленьких, где подсвечивается читаемый текст, и можно послушать каждое слово по отдельности, или даже отдельную букву в слове! Такие книги помогают изучать языки.

Мы решили делать интерактивные книги на русском языке с озвучкой текста.

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

Всем хочется кушать.

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

Небезызвестный в среде инди разработчиков Маркус Перссон aka Notch, после своего ухода с поста главного разработчика Minecraft, решил принять участие в стартовавшем два дня назад конкурсе Ludum Dare 22 по созданию игр на заданную тему. Темой 22-го конкурса стало «одиночество».

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

Для 2011 года здесь нет ничего удивительного, но чтобы создать такую простую и эффективную систему как Ecwid нам потребовалось пятьдесят лет исследований и разработок. Каждый учебник по ресторанному делу начинается с простой тайны всех рестораторов. Подача блюда – это 50% его цены и успеха. Посетители приходят в ресторан за атмосферой в той же степени, что и за едой. Это правило применимо и к магазинам, ведь они тоже относятся к индустрии развлечений.

В конце ноября сего года на платформе Android и, неделей позже, на iOS вышла наша игра под названием Voltage (Android, iOS, Gameplay Video). Небольшой историей её создания я и хочу поделиться с сообществом. Следует сразу предупредить, что это не «success story», не инструкция по обращению с издателями и уж точно не теоретическое введение в разработку игровых приложений.

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

В первой части разработки тетрисоподобной игры Impressive Solids мы реализовали основную часть геймплея, уделив минимальное внимание внешнему виду приложения. Мы и OpenGL-то почти не использовали, всего и делали, что рисовали цветной прямоугольник. Пришла пора заняться оформлением, а также реализовать подсчёт очков и хранение рекорда (high score). Ну что, поехали дальше.

Picture This

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

Но сперва отмечу один очень важный нюанс. До версии OpenGL 2.0 каждый из размеров текстуры обязан был быть равным степени двойки (т. е. 64×64, 512×256; это POT-текстуры, от англ. power of two). Если текстуры произвольного размера (NPOT-текстуры) не поддерживаются видеокартой или драйвером видеокарты, такая текстура не будет работать. Это имеет место, например, для встроенных видеокарт Intel под Windows XP.

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