Дано: собственные и аутсорс-проекты, некоторые участники работают удаленно.

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

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

Изначально сервисов было более 100, но постепенно список сокращался, и мы остановили наш выбор на трех, удовлетворяющих вместе наши нужды лучше всего: Jira, Slack и GanttPro. Но, если вдруг эти сервисы не помогут вам в планировании задач и работы с командой, делюсь с вами полным списком:

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

Часто ли вам приходилось слышать фразы “я не собираюсь тратить ни копейки на продвижение”, “хорошая игра сама себя продаёт”, “у тех парней получилось, и у меня получится”, а чуть позже — “игра не пошла”, “на рынке нет места независимому одиночке”, “золотое время инди-игр прошло”?

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

Мне никогда не нравился такой подход, поэтому на старте мы немного потратились на неумелый “диванный” маркетинг. И наша первая игра не провалилась. Отбила затраты, заработала сверху, получила отличные отзывы — 5 звезд в (AppStore) и 4.7 в (GooglePlay), и даже спустя 9 месяцев не спешит отправляться в “Долину Смерти” приложений. Но сейчас, видя такой отклик аудитории, появляются сомнения — а действительно ли был толк в нашей небольшой “PR-кампании” или нам просто повезло? Ошибка выжившего? Совпадение? Может, попав в топ новинок GooglePlay, мы бы и так нашли своих игроков?

Я изложу факты, покажу графики и цифры, а выводы предлагаю сделать вместе в комментариях — раскрутилась бы игра сама или всё-таки без продвижения никто бы о ней не узнал?

Аналитика приложений в большинстве случаев сводится просто к мониторингу основных метрик: DAU, MAU, WAU, ARPU, ARPPU и другие аббревиатуры. Базовые метрики аналитики — это как раз те 20% функционала аналитических систем, которые дают 80% результата. Но достаточно ли вам этих 80%?

Если нет, то наша статья для вас. Мы расскажем о некоторых метриках, которые тоже стоило бы иметь в виду, если вы хотите полностью понимать все процессы, которые происходят в вашем приложении.

Каждый месяц мы устраиваем AMA (ask me anything) сессию на reddit — отвечаем на любые вопросы об аналитике приложений. Мы решили отобрать самые интересные вопросы, и привести ответы на них здесь. Для каких типов игр нужна аналитика? Как правильно проводить эксперименты? Как увеличить retention? Ответы на эти, и многие другие вопросы — под катом.

Для тех кто пропустил мои посты:
Consulo — это форк IntelliJ IDEA Community Edition, который имеет поддержку .NET(C# на текущий момент, и на этот сектор пока идет большой акцент), Java, Javascript(NodeJS).

Здравствуй Хабр. В моих предыдущих постах (тык, тык), я показал хорошие возможности плагина C#, да и сама платформа вполне стабильно работает. Можно было выйти в реализ, но — это не только написать код. Нужен как минимум сайт, что бы не отдавать Night Builds пользователям, но увы — имею ограниченные возможности.

Вступление

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

Введение

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

Тонкий однородный стержень массы m = 2 кг, длины AB = 2l = 1 м в точке A шарнирно прикреплен к невесомому ползуну, перемещающемуся в горизонтальных шероховатых направляющих. В начальный момент времени стержень расположен вертикально, затем его отклоняют от вертикали на ничтожно малый угол и отпускают без начальной скорости. Необходимо составить уравнения движения данной механической системы и найти закон её движения. Коэффициент трения между ползуном и направляющими равен f = 0,1.

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

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



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

Для того чтобы запрос шел мимо cdn серверов ютуба надо заблокировать диапазон ip адресов (в роутере или на компьютере).

173.194.55.0/24 и 206.111.0.0/16

снизу фотографии настоящих жуков, сверху — моя реализация

Продолжение предыдущей статьи, на этот раз пишем шейдер.

Примечание от переводчика: если вам позволяет знание английского языка, то я настоятельно рекомендую ознакомиться с оригиналом. Её автор — один из основателей студии Mode 7, которые выпустили Frozen Synapse. Статья очень большая по объёму текста, поэтому, если у вас не получится осилить её за 1 подход, я бы предложил отложить на потом, и продолжить в другой день.

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

Ниже будет перевод статьи.

disclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали!

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

От распределенного сервиса блокировок разумно требовать:

1. работоспособность в условиях моргания сети (первое правило распределенных систем — никому не говорить о распределенных системах сеть ненадежна)
2. отсутствие единой точки отказа

Создать подобный сервис нам поможет ZooKeeper

В википедии написано, что ZooKeeper — распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами:

• пространство ключей образует дерево (иерархию подобную файловой системе)
• значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
• между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
• возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
• все данные должны помещаться в память
• устойчивость к смерти некритического кол-ва узлов кластера

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

Дисклеймер: для понимания этой статьи требуются начальные знания теории графов, в частности знание поиска в глубину, поиска в ширину и алгоритма Беллмана — Форда.

Введение

Наверняка вы сталкивались с задачами, которые приходилось решать перебором. А если вы занимались олимпиадным программированием, то точно видели NP-полные задачи, которые никто не умеет решать за полиномиальное время. Такими задачами, например, является поиск пути максимальной длины без самопересечений в графе и многим известная игра — судоку, обобщенная на размер . Полный перебор крайне долгий, ведь время его работы растёт экспоненциально относительно размера входных данных. Например, время поиска максимального пути в графе из 15 вершин наивным перебором становится заметным, а при 20 — очень долгим.

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

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

Вас ждет много анализа и немного частных производных. Код прилагается.
Прошу под кат!

В этой статье я расскажу, как создать групповую среду разработки сайтов через git с помощью git-хуков. Статья рассчитана на опытных системных администраторов, я лишь опишу алгоритм.
Многое на эту тему уже обсуждалось, а я добавлю, как автоматически создавать или удалять сайты при создании/удалении бранчей в git-репозитории. Такая возможность может пригодиться, к примеру, если над разными частями сайта работают разные программисты и нужны разные площадки (бранчи). После основной разработки и тестирования выполняется merge в основную ветку, а бранчи и тестовые сайты удаляются или архивируются.

Введение

Итак, у меня есть собака.
Краткое резюме:
Кличка: Белка
Окрас: Белый с рыжим
Порода: Западносибирская лайка с кем-то еще
Происхождение: Дворянское
Стоимость: 0р 0к

Собака была приобретена в собственном подъезде за еду и кров. Была выброшена какими-то негодяями без еды и воды в картонной коробке без фирменных логотипов породы и адреса завода-изготовителя. Ну да не важно, мы и с менее качественным товаром имели дело, а тут такая рыжая морда, и совсем бесплатно. Берем!
Пришлось принимать товар как есть, NO-NAME. Скорее всего, сделано в Китае. Гарантийные претензии тоже непонятно, кому предъявлять, а они были — в собаке водились глисты длиннее ее самой. К счастью, все это в прошлом. Зверюга подросла. Доказала свою преданность и послушность, за что получила возможность гулять без веревки на шее. Поскольку это не просто собака, а настоящая собака-гуляка, которая привыкла к полноценной четырёхразовой прогулке без поводка (она у меня совсем не агрессивная, но очень любознательная и послушная), ей потребовался своеобразный маячок, чтобы наблюдать ее похождения даже в темноте, и не нервничать, куда ж она подевалась. А подеваться ей есть куда — ее любимое занятие — приносить палки хозяину, и требовать, чтобы он ее кинул. Ну а найти-уж ее дело. Но это ж не простая собака, а собака, у которой папка — программист и немножко электронщик. Впрочем, даже простой ошейник с DealExtreme приковывает взгляды окружающих, особенно радуются дети. Разве это не стоит того? Но начнем с начала. Под катом много текста!

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

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

Новый инструмент Intel Advisor XE поможет вам распараллелить приложение, потратив на это минимум сил и времени.

Advisor XE вышел в свет в сентябре этого года в составе пакета для разработчиков Intel Parallel Studio XE 2013. Дословный перевод названия – «советчик» — довольно ёмко описывает его предназначение. Инструмент помогает программисту проанализировать возможности распараллеливания кода: найти наиболее подходящие для этого участки и оценить предполагаемый полезный эффект – а стоит ли вообще за это браться? Кроме того, Advisor XE подскажет, где могут возникнуть ошибки, такие как гонки данных. И всё этого без реальной модификации программы! Но обо всём по порядку.

Бывают SQL-инъекции! А возможны ли NoSQL-инъекции? Да! Redis, MongoDB, memcached — все эти программные продукты относятся к классу нереляционных СУБД, противоположному популярным MySQL, Oracle Database и MSSQL. Так как интерес к перечисленным базам данных в последнее время значительно возрос, хакеры всех мастей просто не могли пройти мимо них.

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

Для простоты, будем рассматривать 2D случай, частицы круглые, радиус частиц у всех одинаковый.

Содержание

1. Обзор алгоритмов
1.1. Полный перебор
1.2. Sweep & Prune
1.3. Регулярная сеть
2. Некоторые оптимизации
2.1. Sweep & Prune
2.2. Регулярная сеть
3. Сравнение скорости выполнения
4. Приложение (программа и исходный код)
5. Заключение