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

Некий dypsilon выложил на GitHub огромную коллекцию ссылок на ресурсы по веб-разработке, за что ему огромное спасибо.

Список состоит из ссылок на библиотеки, руководства и статьи.

Frontend: github.com/dypsilon/frontend-dev-bookmarks
Backend: gist.github.com/dypsilon/5819528 (много node.js)

Ссылок много, но все — строго по делу и упорядочены по группам (пример для фронтенда):

1. Архитектура
2. Фреймворки
3. Cross Browser
4. Cross Device
5. Паттерны и сниппеты
6. Манипуляция с DOM
7. … и многое другое

matmuchrapna советует еще frontdesk Вячеслава Олиянчука.
Настоятельно рекомендуется добавить в закладки, а лучше — почитать.

Писать программки для смартфонов — мое хобби. Все началось с того, что я купил свой первый смартфон Nokia E51 на Symbian и мне очень нравилось что его функционал можно было расширить через установку дополнительных программ.
Но однажды я не нашел необходимой программы и решил написать ее сам. Так и началось мое увлечение программами для смартфонов.

После того как глава Nokia заявил, что дни Symbian сочтены, я решил изучить платформу Android.

Для лучшего усвоения материала я решил написать полезную, хотя бы для себя, программку. Но написать ее не по детски, когда куски примитивного кода копируются из документации, а по взрослому с разработкой архитектуры, и использованием современных технологий программирования TDD, MVP и IoС.

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

Здравствуйте! Моя основная область деятельности — разработка мобильных приложений (iOS, Android). И большая часть приложений, использует взаимодействие с другими пользователями, хранение данных и другие задачи требующие наличие единого сервера. Поэтому для большей части приложений приходится писать свой велосипедbackend. А так как я, в основном являюсь мобильным разработчиком, то написание этого сервиса всегда становится небольшой проблемой — приходится задействовать веб-разработчика или искать подходящий BaaS сервис, даже если надо написать всего пару запросов.
Поэтому было принято решение, попробовать найти инструмент, позволяющий в короткие сроки написать небольшой веб-сервис, который можно было бы использовать в мобильном приложении.

Поиск Google из мобильного браузера теперь работает быстрее, а конкретно, на 100-150 миллисекунд. Такое стало возможным благодаря внедрению новой функции, которая называется реактивная предварительная выборка. По-английски она звучит гораздо короче: reactive prefetch.

Когда вы нажимаете на одну из ссылок в результатах поиска, браузер начинает загружать страницу. И здесь есть один трюк, объясняет Илья Григорик из Google: одновременно браузер получает инструкцию, какие критические ресурсы следует загружать параллельными потоками при запросе веб-страницы. Такая параллельная загрузка сильно ускоряет общее время рендеринга страницы.

Нечто похожее на Око Саурона — это результат рендеринга статей из Википедии с построением связей между ними. Звёздные кластеры — тематически связанные между собой и залинкованные статьи. Такова идея автора проекта WikiGalaxy, французского студента Оуэна Корнека (Owen Cornec).

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

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

Всем привет! Сегодня мы расскажем о том, как самостоятельно зарегистрировать ООО.

Вопрос о создании своей компании обычно возникает, когда у вас есть идея для стартапа и вы готовы приступить к разработке. Если над проектом вы работаете один, то вам вполне достаточно статуса ИП. Если у вас есть партнёры или вы планируете привлекать инвесторов, то лучше с самого начала зарегистрировать ООО. Это самая распространённая форма для ведения бизнеса и, несмотря на некоторые ограничения, она лучше всего подходит для создания стартапа.

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



Инструкция по самостоятельной регистрации ООО от «Я люблю ИП»

Cтэнфордский курс CS183B: How to start a startup. Стартовал в 2012 году под руководством Питера Тиля. Осенью 2014 года прошла новая серия лекций ведущих предпринимателей и экспертов Y Combinator:

Выбор инструментов, которые так или иначе понадобятся при разработке – один из главных подготовительных этапов на старте нового Android-проекта.
В случае, если вы разрабатываете приложение, которое должно в том или ином виде хранить большое количество сущностей – вам не избежать использования баз данных. В отличие от коллег по цеху, разрабатывающих для iOS, у Android-программистов нет удобных инструментов, облегчающих хранение объектов вроде Core Data, предоставляемых платформой (кроме Content Provider, о том почему он не в счет, будет дальше). Поэтому многие Android-разработчики прибегают к использованию сторонних ORM-решений в своих проектах. О том, на что стоит смотреть при выборе библиотеки для вашего проекта, и пойдет речь в этой статье.

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

Под катом 16 методик: в большинстве случаев они предполагают 2 этапа – создание списка слов, имеющих отношение к вашему проекту, и смешивание этих слов, т.е. поиск «золотой» комбинации.

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



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

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

Всем привет, с вами снова Delfuego FM, и я наконец-таки созрел, чтобы выложить вторую часть статьи! Вследствие неоднозначной реакции на первую часть, была предпринята попытка выложить вторую на geek times, и… она успешно провалилась. Поэтому придётся совершить небольшой хабрасуицид и выложить её прямо тут! Итак, поехали!..

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

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

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

Схема успеха

Джон, мы потеряли два листа математических выкладок! Что делать?
Как обычно, Билл… напиши: «отсюда с очевидностью следует…»



Чтобы прочитать некраткую сопроводительную записку к схеме – добро пожаловать под кат.

В предыдущей статье я вывел формулу успешности приложения. Под приложением я понимаю простую, казуальную игру, разработанную под iOS. Что-то вроде тетриса, кроссворда, судоку, 2048, японского дурака, косынки. На создание которого уходит неделя программисткого труда. Для проверки формулы необходима достаточно большая статистическая выборка — порядка 10.000 честно загруженных приложений. Я попытался решить эту задачу при помощи обзоров на 4-х русских и 2-х зарубежных площадках. Кроме того, отследил в первой версии программы наиболее популярные нажатия на кнопки, убрал второстепенные элементы управления, учел замечания игроков и получил следующие результаты.

Яблочный рынок приложений, или Apple App Store, потребляет и порождает деньги. Чем больше Вы вкладываете денег, тем выше отдача. Однако, заработанное не всегда больше потраченного. С недавних пор в моей голове вдруг сформировался типичный график потраченных/полученных средств.



Зеленая прямая — график потраченных денег. На что потраченных? На покупку траффика. В результате Ваше приложение выходит в ТОП100, ТОП25 или (ого!!) ТОП10 США и начинает приносить деньги. Красная линия — это заработанное. Если заработанное больше потраченного, то красная линия на графике выше зеленой и Вы отдыхаете на Гавайях, пересыпая между ладоней белый песок Вайкики.

-Чему равна точка Ж?,- спросит сообразительный читатель.

В 2011 году она равнялась 5000 долларов, этого хватало войти в ТОП10. Приложение приносило не менее 1000 долларов в день. Те времена ушли. Теперь в 2014 году надо потратить 50000 долларов, приложения из ТОП10 зарабатывают в день не менее 10000 долларов в день.

Хочу заметить, что речь идет об успешных приложениях, которые после искусственного прыжка в ТОП, сами начинают поднимать свой рейтинг и держаться на гребне успеха не менее 5 дней. Математически красную параболу можно характеризовать показателем степени. Если показатель степени больше 1 — это круто, Вы и Ваше приложение — молодцы. Если меньше-равно 1 — получаем голубой график и дырку от бублика. То есть, сколько денег не вкладывай — дерево не вырастет.

Как же определить показатель степени для Вашего приложения? Для этого не надо тратить 50000 долларов.
Ловко я Вас заманил под кат?

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

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