UPD: в этом посте отражено субъективное мнение автора в 2016-ом году. Сейчас я работаю над своим проектом в сфере обучения облачным технологиям.

Мне не раз приходилось слышать: «Upwork — это же геморрой. Мне приходится тупо кликать мышкой, смотреть фильм на ноуте, чтобы побольше высидеть часов. Поэтому я ушел на XYZ...». Вот этот тезис, личные проблемы с продуктивностью, а также немалое количество self-help книг, побудили меня написать этот пост. Вся моя IT-карьера, связана с Upwork (который был oDesk). Это немного-немало 10,000+ часов работы, 10+ лет проведенных в этой системе, с короткими перерывами.

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

Каждому iOS разработчику нужен свой уголок с печеньками, плюшевой уточкой и шайтан-машиной на OSX.

В свете перехода на Swift, мощность железа стала особенно востребована. Чтобы комфортно разрабатывать под айфоны, нужен как минимум процессор с частотой 3+ ghz, SSD на 120-250Gb и оперативы гигов 16. Все это как раз для того, чтобы не было желания посмотреть футбол, пока запускается проект или открывается interface builder.

А знаете, что еще было всегда актуально? Сумасшедшие цены на яблочные устройства:

PC с таким же, плюс-минус, железом можно запросто собрать всего за 30.000 рублей! (инфа на ноябрь 2016). Многие, конечно, думают, что раз компания покупает железо, то значит финансы бесконечные, можно не стесняться в средствах. Если вы работаете в Google, то вам повезло и жизнь хороша. Но в остальных случаях это не так.

Что же делать? Не разрабатывать же под Android в конце концов?

Под катом мы узнаем о современном Hackintosh, его роли в разработке, способам безболезненной установки и настройки, услышим мнение людей, работающих на нем не первый год, и проведем тест на iOS инструментах.

Когда в 2005 году Apple перешла на платформу Intel, энтузиасты со всего мира задались целью установить MAC OS X на обычные PC (Хакинтош). На пути реализации этой затеи стояли четыре причины. 2 физические и 2 юридические. Дело в том, что для запуска компьютера MAC используется не привычный BIOS, а собственный EFI загрузчик. Вторая причина, это чип SMC который установлен в каждом компьютере Mac. Он генерирует ключи для запуска всех системных приложений MAC OS X. Благодаря нашему соотечественнику под ником Netkas, удалось обойти эти два ограничения созданием эмулятора загрузчика EFI (Chameleon, Chemera, Clover) и эмулятора чипа SMC (FakeSMC.kext). Этих двух программных решений достаточно, что бы установить MAC OS на PC.

Эта статья объясняет почему при разработке Win32-приложений механизм Slim Reader/Writer Lock (SRWL) часто более предпочтителен, чем классические критические секции.

Легковесность

SRWL-объект занимает в памяти всего 8 байт на x64-архитектуре, в то время как критическая секция — 40 байт. Критическая секция требует инициализации и деинициализации через вызовы функций ядра ОС, в то время как SRWL инициализируется простым присваиванием ему константы SRWLOCK_INIT, а затрат на удаление нет вообще никаких. Использование SRWL генерирует более компактный код и использует меньше оперативной памяти при работе.

Если у вас будет 100 000 объектов, требующих некоторой внутренней синхронизации, экономия памяти будет уже существенной. Прирост производительности от избегания лишних промахов кэша будет ещё более ощутимым. В современных процессорах (начиная с Intel Nehalem, вышедшего в 2008-ом) одна кэш-линия занимает 64 байта. Если вы используете на объект синхронизации 40 из них — это существенно ударит по производительности доступа к небольшим объектам в вашем ПО.

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

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

Используемые компоненты:

• REACT-CPP;
• AMQP-CPP;
• RapidJSON;
• LevelDB;
• Easylogging++.

Для примера буду делать микросервис для выдачи рейтинга игроков. От ядра системы в микросервис приходят следующие сообщения:

• player_registered(id,name);
• player_renamed(id,name);
• player_won(id, points).

Сервис раз в минуту должен отсылать сообщение с содержимым рейтинга.Рейтинг сортируется по набранным очкам за календарную неделю.

Привет, меня зовут Дэйв Блежа (Dave Bleja), я работаю в студии Volnaiskra. В течение последних 3 лет я создавал Spryke, увлекательный и проработанный платформер о глубоководной морской кибер-рыбе, исследующей чудеса суши.

Как единственный постоянный участник команды Spryke, я нёс ответственность за многие части творческого и технического процесса. Некоторые задачи нудны, но бóльшая часть — увлекательна. Моим любимым аспектом была анимация, и я хочу поделиться с вами пятью советами по анимации, которые выработались у меня за годы работы.

Я ясно помню тот день в далеком 2014 году, когда я решил заняться программирование под Android. Это оказалось лучшим решением, которое я принял в моей жизни. Уже прошло почти два с половиной года, и за это время у меня возможность кое-чему научиться.

Когда я только начал, я не знал никого, кто мог бы научить меня, показать, как правильно нужно делать. И я совершил МНОЖЕСТВО ошибок, в так же потратил кучу времени на то, чтобы потом их исправить.

Полтора года спустя, мне выпал шанс поработать с очень талантливыми и опытными Android-разработчиками, которые направляли меня и помогли мне привести все в порядок. Эти две составляющие научили меня многому. Я понял, что надо ДЕЛАТЬ, а самое главное, что НЕ НАДО.

И уже какое-то время я, как могу, стараюсь помогать другим разработчикам — прямо или косвенно. Вот мои профили: StackOverflow и Github.

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

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

App Store Optimization – самый недооцененный фактор при продвижении мобильного приложения.

У этого есть две причины:

1. По последним данным 60% от общего кол-ва органических (бесплатных) установок приложения получают именно из поиска в сторах.
2. Средний CTI (конверсия из просмотра страницы в установку) по рынку составляет 25%. Визуальная оптимизация странички приложения позволяет поднять CTI до 40-50%, что соответственно уменьшает стоимость установки в 2 раза.

В данной статье мы распишем каждый из шагов по ASO, как его настраивать, покажем примеры как нужно и как не нужно делать. Статья будет полезна новичкам в сфере ASO а также разработчикам, CTI которых ниже 20%.

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

Привет, Хабр! В этом топике, я хотел бы поделиться впечатлениями от игрового движка libGDX, рассказать о буднях обычного инди-разработчика и приоткрыть завесу тайны над игрой, которую я делаю последние несколько месяцев в свободное от офисного рабства время. Надеюсь, эти мои записки будут полезны тем кто только начинает что-то делать на libGDX или тем, кто выбирает движок для «игры своей мечты».

И извините за котов. Они совершенно никакого отношения не имеют к игрострою. Я тут параллельно учусь (пытаюсь учиться) рисовать и теперь эти мои тренировочные коты просто повсюду! Требуют чтобы их, бездельников, кому-нибудь показывали.

(Прим. пер.: 1. Spine — это проприетарный кроссплатформенный пакет для создания двухмерных скелетных анимаций с поддержкой различных игровых тулкитов.
2. Осторожно, в посте есть около 38 МБ gif'ок, все они спрятаны под кат.)

Как создать плавное переключение или поворот спрайтов?

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

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

Go — простой и забавный язык. Но в нём, как и в любых других языках, есть свои подводные камни. И во многих из них сам Go не виноват. Одни — это естественное следствие прихода программистов из других языков, другие возникают из-за ложных представлений и нехватки подробностей. Если вы найдёте время и почитаете официальные спецификации, вики, почтовые рассылки, публикации в блогах и исходный код, то многие из подводных камней станут для вас очевидны. Но далеко не каждый так начинает, и это нормально. Если вы новичок в Go, статья поможет сэкономить немало часов, которые вы бы потратили на отладку кода. Мы будем рассматривать версии Go 1.5 и ниже.

1. DZNEmptyDataSet

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

С этой библиотекой вам необходимо всего лишь соответствовать определённым протоколам и iOS сама позаботиться о просмотре коллекций и выделит необходимое особым шрифтом, в виде красивых сообщений для пользователя. Элементарное решение для каждого проекта под iOS.

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

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


Статья автора Ивана Короля, в рамках конкурса «Device Lab от Google».

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

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

В этой статье мы рассмотрим один из вариантов реализации поведенческого шаблона проектирования Acyclic Visitor без ипользования RTTI.

Splash Screen (прим.: тут и далее — экран загрузки) просто отнимает ваше время, верно? Как Android разработчик, когда я вижу экран загрузки, я тут же представляю как некоторые плохие разработчики добавляют трехсекундную задержку в коде.

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

Попалась небольшая задачка, где-то на 4 часа кодирования, которую счел занимательной.

Есть база пользователей 10 миллионов:

class User{
 int id; 
 time_t birthday; // дата рождения
 int gender;      // пол
 int city_id;     // место проживания
 time_t time_reg; // дата регистрации
};

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

• город;
• город, пол;
• пол, возраст.

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

Подсказка 1: СУБД не даст нужной скорости.
Подсказка 2: Вспомнить сложность операций со множествами, сложность стандартных алгоритмов.
Подсказка 3: Проверить время поиска реализованного алгоритма, неплохой результат это порядка 0.005 сек.

Язык — лишь малая часть того, что вам нужно знать. Может быть около 5%, а то и меньше.

Эта статья повторяет и дополняет содержание моего выступления «Что отличает джуниора от сеньора или как питонисту не иметь проблем с поиском работы» на последнем MoscowPython Meetup 39. Многие обращались ко мне после выступления с вопросами и я обещал опубликовать статью на Хабре и обсудить в комментариях.

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

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