В 1935 году судья Дж. Сандерленд выразил принципиальную позицию Верховного Суда США:
«Право налогоплательщиков избегать налогов…
с использованием всех разрешенных законами
средств никем не может быть оспорено»

Я продолжаю маленький ликбез по правильной работе с законами нашей страны. Ранее я уже писал про юридическую безопасность ИТ бизнеса в СНГ. Как сказано в цитате выше, которую я совсем недавно где-то прочитал, у каждого есть право платить минимум налогов в рамках закона, и эта статья именно об этом. Как и в прошлой статье, я буду рассматривать одну работающую схему.

Сразу оговорюсь, чтобы вы понимали о чем будет идти речь: во-первых, я буду рассказывать только о законных методах минимизации налогов, во-вторых, моя схема создана специально для компаний определенного типа, а именно ИТ компаний, которые работают в сфере ИТ услуг и имеют, как правило, относительно небольшой оборот (до 10 миллионов долларов в год) и высокую маржинальность. Для компаний, которые не подходят под мое описание, будут несколько иные схемы минимизации, и почему – будет понятно из статьи ниже.

Немного о том, как все устроено

Для начала нужно понимать, что не платить налоги вообще – не получится. Можно и нужно платить минимум, но всё же платить. Любая предпринимательская деятельность в Украине должна регистрироваться, и с доходов от неё должны платиться налоги. Если вы до сих пор стараетесь работать в черную, должен вас предостеречь, с недавнего времени это стало опасно, чем именно расскажу ниже.
Если вы только начинаете свою деятельность, начать нужно с регистрации СПД или юр. лица. Даже если не планируете создавать транснациональную корпорацию, а банально фрилансите, это тоже считается предпринимательской деятельностью.
Если же предпринимательская деятельность уже идет, и все регистрации давно есть, всегда можно перейти на удобную систему налогообложения, такая возможность по закону дается каждый квартал.

Схема минимизации

Еще раз повторюсь, говорить я буду о законной схеме минимизации.

Так как карьера программиста тесно связана с процессором, неплохо бы знать как он работает.

Что происходит внутри процессора? Сколько времени уходит на исполнение одной инструкции? Что значит, когда новый процессор имеет 12, или 18, или даже 31-уровневый конвейер?

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

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

Эта статья рассказывает, как устроен вычислительный конвейер x86 процессора.

Непрерывная интеграция (continuous integration) — практика разработки, позволяющая добиться большей уверенности в стабильности и корректности работы любого проекта. Проекты с открытым кодом — не исключение.

Примерно два месяца назад, в апреле 2013 года комапания Sauce labs объявила о поддержке iOS / Mac для CI-сервера Travis. Сам сервис существует уже довольно давно, и пользуется довольно большой популярностью в open-source community благодаря поддержке большого количества языков и удобству использования. Cервис бесплатен для любого пользователя github и открытых репозиториев. На Хабре уже имеется пост о сервисе и его настройки для тестирования Ruby-проектов, поэтому в этой статье я хотел бы рассказать о более специфической стороне сервиса — настройке автоматической сборке билдов iOS проектов на Travis-CI. Основным фокусом этой статьи будет связка CocoaPods + Cedar + Travis CI, однако я постараюсь рассказать немного и о других связанных с темой вещах.

Итак, начнем.

В этой статье я собираюсь описать разработку приложения для iphone, которое будет в реальном времени обрабатывать видео с камеры устройства. Для этого мы будем использовать GPUImage фреймворк, напишем собственный шейдер на OpenGL ES и попробуем разобраться в том, что представляют из себя фильтры для обработки изображений.

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

Вступление

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

Итак, главный вопрос сегодняшней ночи – как сделать качественную тайл-текстуру за 5 минут? Хороший вопрос я думаю, и на него вполне можно потратить 5-10 минут вашего времени. Возможно после этого для ваших собственных прототипов вы будете использовать оригинальные тайлы, созданные вашими руками, не тратя времени на поиск художника или текстурщика, который смог бы вам помочь. Заманчиво?

Первым делом находим удовлетворяющую вас фотографию из тех, что не имеет копирайта (как правило на полях или по центру изображения). Внимательно следите за этим, потому что игровая индустрия богата курьезными ситуациями и эта далеко не последняя из могущих произойти с вами. Хотя. Что может быть веселее забыть в пред-релизной версии текстурной даты текстуру от игры Unreal Tournament? И такое случалось. Правда я не видел на лицах людей улыбок и не слышал их радостного смеха.

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

Сегодня, многие разработчики и большинство специалистов по продвижению мобильных приложений говорят об оптимизации ключевых слов для App Store. Хочу еще раз четко обозначить, что ASO в целом (длинную вводную статью про App Store Оptimization читать тут) и оптимизация ключевых слов в частности это не панацея. Но это обязательная вещь, которую вы можете освоить и выполнить самостоятельно, сэкономить кусочек маркетингового бюджета и радоваться примерно таким цифрам в статистике:

В данной статье я расскажу об алгоритме смешивания текстур, который позволяет привести внешний вид ландшафта ближе к естественному. Этот алгоритм легко может быть использован как в шейдерах 3D игр, так и в 2D играх.

Статья рассчитана на начинающих разработчиков игр.

Бизнес – это игра или нет? Я думаю да. А у любой игры должны быть правила.

Привет Хабр, меня зовут Александр. Сегодня я хотел бы поделиться с вами о том, как надо или не надо вести бизнес в сфере IT. Данные заметки я извлек из собственного опыта. Я не буду писать здесь книжными и в тоже время, зачастую, пустыми и скучными фразами. Здесь будет только то, что я почерпнул для себя работая на поприще самостоятельной работы, то есть не на дядю. Вся статья будет поделена на части. Во всех частях кроме первой, материал будет изложен в виде заметок, после каждой заметки я буду приводить пример из моей работы, чтобы не быть голословным. Поехали!

Эпоха путешествий во времени еще не наступила, а человечество уже давно пытается разрешить сопутствующие им парадоксы. Мы поговорим о самом очевидном из них: что же все-таки произойдет при вмешательстве в ход истории? Существует несколько вариантов того, как поток времени реагирует на действия путешественника из будущего. Эти модели можно увидеть в фантастических фильмах, о них все больше начинают говорить ученые, но какая модель ближе к истине — единого мнения пока нет. Мы только начинаем проникать в тайны времени, и еще не обладаем возможностью экспериментировать с перемещениями в прошлое. Что же можно прояснить в данном вопросе уже сейчас? Под катом нас ждет экскурсия по основам механики времени, мы порассуждаем о парадоксах, и проведем небольшой эксперимент. Да, это будет испытание виртуальной машины времени, построенной на основе алгоритма «Жизнь»!

Мотивом написания данной статьи в чем-то послужил другой хабратопик «О том, как выпустить отличное iOS приложение, которое никому не нужно». Я попробую рассказать о том как выпустить отличное приложение, которое кому-то все же нужно, но на котором не получилось заработать.

Еще один мотив — разложить для себя все по полочкам. Все же история достаточно объемная и пока не систематизируешь все на бумаге, осознать все свои ошибки весьма сложно. Постоянно будешь думать о том, что ты все сделал правильно, и будет казаться, что во всем виноваты нерадивые пользователи, которым жалко доллара. А свои просчеты мозг отодвинет на дальнюю полку. Ну и какие-то менее очевидные вещи, возможно, подскажет хабрааудитория.

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

Также для любителей цифр скажу — все цифры в статье будут. Расскажу сколько скачиваний, сколько заработано, сколько инаппов куплено и сколько раз их пытались сломать.

Этот алгоритм является улучшенным алгоритмом поиска пути A*. JPS ускоряет поиск пути, “перепрыгивая” многие места, которые должны быть просмотрены.  В отличие от подобных алгоритмов JPS не требует предварительной обработки и дополнительных затрат памяти. Данный алгоритм представлен в 2011 году, а в 2012 получил высокие отклики. Что из себя представляет данный алгоритм и его реализацию можно прочитать дальше в статье.

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

Как и многие разработчики, я не очень люблю писать много кода, особенно там, где это кажется не нужным — на ранних стадиях стараюсь придумать, как этот код оптимизировать и обобщить. Что касается непосредственно Core Data, мне всегда казалось, что все эти бесконечные фетчи и создания новых объектов можно упростить. Тогда я открыл для себя часто упоминаемый на хабре паттерн ActiveRecord и его очень хорошую (на мой взгляд) реализацию на Objective-C — MagicalRecord. Углубляться в описание не буду — все очень доступно описано на странице проекта.
Следующим шагом упрощения должен был быть маппинг данных, поступающих извне.

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

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

Приятного вам чтения!

Computer programs are the most complex things that humans make. It is also the nature of software to be extensively modified over its productive life. If we can read and understand it, then we can hope to modify and improve it.

Douglas Crockford, автор спецификации JSON

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

Есть много способов превращения JSON в Objective-C обьекты, однако многие из них имеют свои недостатки, которые мешают с ними работать. Есть известный и любимый многими RestKit, однако он, к сожалению, эффективно работает только при наличии идеального REST API. Шаг в сторону — и вы будете забивать гвозди микроскопом, не понимая, зачем нужно писать такие сложные конструкции для достаточно простых вещей. Есть решение от разработчиков GitHub — Mantle, однако с ним вы будете вынуждены наследоваться от базового класса Mantle и постоянно использовать NSValueTransformer — не самую популярную технологию в iOS/Mac OS разработке.

Я хочу рассказать о фреймворке, который недавно нашелся на просторах GitHub, и который позволяет достаточно просто и красиво преобразовывать JSON в Objective-C обьекты — EasyMapping.

Если заинтересовались, добро пожаловать под кат!

В первой части мы начали рассказывать о балансе юнитов в нашей игре жанра TD, которая неплохо себя показала, добравшись до топовых мест в своих жанрах US, RU и др. Appstore, получила фичеринг в разделе «Игры» в RU Google Play и в New&Noteworthy в 60 странах Appstore.
В данной статье мы затронем тему создания новых типов башен по принципу «от рассмотренной ситуации – к юниту», расскажем о расчете параметров крипов и дадим описание бонусов.

Проверьте свой проект: вы летите или думаете, что летите?

Ниже вопросы, которые стоит задавать себе на старте проекта и время от времени на его протяжении.

Контрольные вопросы на старте проекта:

1. Что конкретно нужно сделать на текущем этапе? В целом? Есть ли чётко определённые цели каждого этапа? Как вы определите, что цели достигнуты? Соответствует ли текущий статус заявленным планам и целям или их необходимо корректировать?
2. Реалистичны ли эти цели?
3. Что случится, если цели не будут достигнуты в срок? Каков план действий?
4. Насколько этот проект значим? Например, зависит ли от него место вашей компании на рынке?
5. Какую выгоду вам, обществу и инвесторам принесёт проект?
6. Достаточно ли хорошо спланирован проект? Все ли в вашей команде понимают пункты плана одинаково?
7. Нужны ли внешние эксперты, например, юристы?
8. Есть ли у команды опыт работы вместе? Кто будет координировать команду? Важно ли для проекта работать именно вместе — или возможен труд одиночек? Отвечает ли каждый член команды за работу всех остальных?
9. Можно ли сократить размер команды? Если нет, то почему? Если да, то почему это не сделано?
10. Как вы будете компенсировать форс-мажоры с персоналом, например, что случится, если ваш ведущий разработчик сломает руку?

Все мы слышали о 3D графике (далее просто 3D, не путать со способом отображения — голограммами, 3D-мониторами и т.п.), многие прекрасно знают, что такое 3D и с чем его едят. Но, все же, есть и те, кто смутно себе представляет, что кроется под этой короткой аббревиатурой. Статья рассчитана на тех, кто не имеет представления о компьютерной графике. Также будет немного экскурса в историю компьютерной графики (в следующих планируемых частях).
Почему именно 3D? Как нетрудно догадаться, речь идет о 3 Dimension, или о трех измерениях. И не обязательно при этом, чтобы и отображение было в 3D. Речь идет о способе построения картинки.

Год назад мы, украинская студия Room 8, начали делать свою первую игру под названием Cyto. Ни у кого в команде практически не было опыта гейм-девелопмента и разработки приложений под iOS, зато у всех были амбиции сделать что-то реально офигенное. Учиться всему пришлось буквально на ходу и иногда мы чувствовали себя слонами в посудной лавке:)

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



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