Что-то вроде предисловия

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

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

В самом Model View Controller шаблоне нет ничего плохого. Он решает ту проблему, для которой его придумали — это разделение логики обработки запроса пользователя и логики представления информации.

Хочу рассказать Java-сообществу Хабра о небольшом, но очень полезном (на личном опыте) фреймворке под названием Green-forest. Данный фреймворк можно использовать как самостоятельно, так и в контексте JEE или Spring.

Как с помощью него можно упростить код приложения узнаем под катом.

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.

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

Помимо улучшения вашего приложения путем добавления в него всяких «завитушек», есть одна вещь, которую все хорошие разработчики должны сделать со своим кодом – обработать его утилитой Instruments!

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

А что такого можно написать на Scala, чего нельзя на Java?
(из разговора с одним моим знакомым другом, человеком и программистом)

The best reason to learn a new programming language is to learn to think differently.
Chad Fowler

Хочу рассказать не о простоте конструкций Scala по сравнению с Java и не о том, что в 1 строчку Scala я могу уместить 20 строк Java. А наоборот, копнуть поглубже, уронить устои ООП и посмотреть на реакцию благородной публики.

Событийно-ориентированная логика в Objective C держится на трех китах — протоколы, notification center и key-value observing. Традиционо протоколы используются для расширения функционала базовых классов без наследования, key-value observing – для взаимодействия между визуальной и логической частью приложения, а notification center — для обработкий событий пользователя.

Естественно, все это благообразие можно спокойно использовать для построения сложных приложений. Никакой реальной необходимости в изобретении собственных велосипедов, конечно же, нет. Однако мне, как человеку пришедшему в разработку Objective C приложений из мира .NET, показалось очень неприятным то, что notification center, который я планировал использовать для событий, разраывает стек приложения, записывая произошедшее событие в очередь в UI thread, а протоколы в классическом представлении не слишком удобны, посему для удобства я решил соорудить себе механизм, который был бы гораздо больше похож на то, чем мы привыкли обходиться в мире .NET. Так родился родилась идея реализации модели множественных подписантов через специальный класс, названный AWHandlersList.

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

Многие, вероятно, знают, что при работе с событиями изменения свойств с помощью key-value observing существует очень удобный механизм, предотвращающий появление в приложении «метрвых» объектов, которые представляют собой получателей вызовов. В действительности, первый же мертвый объект «валит» приложение, при поступлении ему события — это закономерно, так как объект уже не существует и никаких методов вызвать у него уже не получится.

Поиск таких объектов мог быть затруднен, если бы не замечательная в отладке вещь под названием NSKVODeallocateBreak, которая позволяет прервать выполнение приложения в момент, когда уничтожается объект, подписанный на события, чтобы отследить время его жизни и убрать проблему.

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

Данная статья рассчитана на разработчиков, имеющих опыт работы с платформой и знающих, каким образом определяется жизненный цикл объекта. Если у вас есть определенные пробелы в этой области (а я неоднократно встречал даже опытных разработчиков, которые не знают, каким образом работает счетчик ссылок и не представляющих, во что разворачивается @synthesize), то вы можете прочитать мою старую статью, посвященную исследованию данного вопроса. Остальных прошу к столу.

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

Boost.Python во всех отношениях замечательная библиотека, выполняющая своё предназначение на 5+, хотите ли вы сделать модуль на С++ для Python либо хотите построить скриптовую обвязку на Python для нативного приложения написанного на С++.
Самое сложное в Boost.Python — это обилие тонкостей, поскольку и C++ и Python — два языка изобилующие возможностями, и потому на стыке их приходится учитывать все нюансы: передать объект по ссылке или по значению, отдать в Python копию объекта или существующий класс, преобразовать во внутренний тип Python или в обёртку написанного на C++, как передать конструктор объекта, перегрузить операторы, навесить несуществующие в C++, но нужные в Python методы.
Не обещаю, что в своих примерах опишу все тонкости взаимодействия этих фундаментальных языков, но постараюсь сразу охватить как можно больше частоиспользуемых примеров, чтобы вы не лазили за каждой мелочью в документацию, а увидели все необходимые основы здесь, или хотя бы получили о них базовое представление.

История и краеугольные принципы Google Chrome.

Google Chrome был представлен во второй половине 2008 года, как бета версия для Windows платформы. Код Chrome, авторство которого принадлежит Google, был сделан доступным под либеральной BSD лицензией — как и Chromium проект. Для большинства заинтересованных, такой поворот событий стал сюрпризом — война браузеров возвращается? Сможет ли Google сделать свой продукт действительно лучше других?

«Это было столь хорошо, что заставило меня изменить свое мнение..» — Эрих Шмидт, первоначально не желающий принимать идею Google Chrome.

Данный пост был задуман после того, как на некоторые важные вопросы не было найдено внятных ответов. Я отнюдь не претендую на то, что стал крутым программистом. Нет, всё ещё впереди, но период высиживания уже пройден. Это статья из цикла «Не умеешь сам — научи другого». В смысле, чтобы что-то лучше понять нужно это что-то, кому-то объяснить. Мопед не мой, эта фраза встречалась мной раньше в публикациях на Хабре. Некоторые вещи очень сложно понять. И люди, которые понимают, обычно не могут объяснить начинающему. Может быть меня тоже это ждёт. Это как разговор взрослого и ребёнка. Практически конфликт поколений. Пока мой уровень не перерос в профессионала, нужно изложить моё текущее видение.

Прежде чем отправить в AppStore ваше приложение, вы долго тестируете его, чтобы убедиться, что ваше приложение работает безупречно. Оно отлично работает на вашем устройстве, но после того, как приложение попало в App Store, некоторые пользователи сообщают, что оно «вылетает»!

Если вы похожи на меня, то вы хотите, чтобы ваше приложение было на пять с плюсом. Значит, вы возвращаетесь в свой код, чтобы исправить сбой… а куда надо смотреть?

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

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

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

Предисловие

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

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

Проблема

Перфект должен быть во всем

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

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

Вот, к примеру, что советует президент Microsoft в России для борьбы с нехваткой времени:

• Планируйте график таким образом, чтобы решать как можно меньше второстепенных срочных задач, а важные — решать до того, как они станут срочными;
• Занимайтесь любимым делом с максимальной вовлечённостью;
• Рассматривайте принцип жизненного баланса как важную личную и менеджерскую задачу.

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

Процесс глобализации необратим. Глобализация затрагивает все сферы IT технологий, в том числе и разработку мобильных приложений. Если раньше рынок мобильных платформ делили как минимум 5-6 компаний (Symbian, Blackberry OS, Android, Palm, iOS, Bada и т.д.), то на текущий момент можно выделить только 2 основные платформы: iOS и Google Android, которые делят около 90% всего рынка. Кстати доля Google Android на четвертый квартал 2012 года достигла 75%, т.е. три из четырех смартфонов, работают под управлением мобильной платформы от Google.



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

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

Набирающее популярность понятие CSS4, на самом деле, взялось из ниоткуда, точно так же, как мы в своё время привыкали к реальности CSS3, который-таки будет с нами ещё некоторое время (на самом деле ещё долгое время). Производители браузеров прилагают огромные усилия для реализации передовых функций стандарта, а «фронтэндщики» (фронтэндеры?) создают новые и новые инструменты для более эффективной работы с таблицами стилей. Но сейчас, слыша о CSS4, вы думаете: «Эй, а что там насчет CSS3? Он ещё жив?»

Некоторое время назад мною был написан Бизнес-план, Дизайн документ и Концепт документ по созданию игры.
К сожалению информация 2011 года, но думаю полезна коллегам.
Система показателей оценки геймплея придумана собственно мной, так что этот бизнес-план, целиком моё субъективное видение.

1. Введение

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

2. Возможности рынка

Для начала надо просто делать бизнес в русском интернете — это один из самых быстрорастущих рынков. Если говорить о конкретных бизнес-направлениях, большой потенциал — у проектов электронной коммерции и сервисов, основанных на социальных связях. И конечно, игры, игры, игры. Играть начинают люди, которые раньше играми не интересовались — например, на мобильном телефоне. Игры привлекают все новых и новых пользователей, и это продолжится. Просто оказалось, что среди огромного разнообразия контента наибольшей популярностью пользуются игры. Комбинация общения и развлекательных сервисов (особенно игр) очень хорошо работает.(1)
Российский интернет-рынок — один из немногих рынков, не переставших расти в кризис, по всем показателям: реклама, домены, хостинг, объем аудитории. Сегмент веб-разработки — не исключение.
Сегодня в 2011 году Интернет населяют 43 млн. россиян (39% населения). Из них активной аудиторией Рунета является 35 млн. человек, а 25 млн. посещают русскую сеть ежедневно. При этом 92% пользователей зарегистрированы хотя бы одной социальной сети, где ежемесячно бывает 25 млн. человек и 16 млн. — ежедневно. Доля пользователей Интернета в стране в среднем составляет: 92% в категории 12-24 года, 76% в населении 25-44 лет, 25% в населении от 45 лет и более.(2)

Рисунок 1 Пользуются интернетом хотя бы один раз.

1 Глава Mail.ru Group Дмитрий Гришин в интервью для Forbes Russia.

2 По данным TNS Russia – лидера в предоставлении комплексной медиа- и маркетинговой информации.

Развернулась дискуссия среди венчурных инвесторов и ангелов о провалах стартапов, нацеленных на мобильные проекты. На эту тему можно почитать посты Фреда Вилсона и Ома Малика. Я же, будучи сооснователем стартапа, который запускался с мобильным приложением, хочу поделиться своими соображениями. На данный момент мы подняли $3.65M и запустили два бесплатных мобильных социальных приложения. Тем не менее наше следующее приложение мы запустим сперва под веб.

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