Здравствуйте!

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

Кого заинтересовала данная тема — прошу под кат.

Привет, Хабр!

Буквально совсем недавно мы рассказали об обновленном интерфейсе нашей Эвитерры (с помощью которой можно дешево и быстро покупать любые авиабилеты).

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

Вдобавок, после обновления интерфейса многие стали нас спрашивать: «А зачем вам такой календарь?», «А зачем вам такая большая карта, если на ней показывается только путь от пункта отправления в пункт назначения?».

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Мы уже писали о методах (Mobile First и Response Web Design), которые используем при разработке нашего сервиса. В этой статье я хочу поделиться с вами нашим опытом. То, что в теории кажется простым, на практике порой оборачивается кошмаром. Речь пойдет о том, как нам удается создавать универсальный веб-сервис, способный работать на большом количестве устройств.

Начнём с описания ifttt.com

ifttt.com — это очень перспективный стартап, который в двух словах: Lets You Hack Together Web Apps, Without Coding Skills. Если детальнее, то это сервис позволяющий пользователям, без погружения в API огромного количества сервисов и каких либо знаний о разработке\языках программирования смешивать и автоматизировать различную активность друг с другом. В начале 2012 года получили посевные инвестиции в размере $1.5M.

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


Экран задач выглядит так

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Здравствуйте!

Это вторая из трех статей о техниках анализа проблем и принятия решений (первая здесь).

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

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

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

Всех заинтересовавшихся прошу под кат.

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

Доброго дня всем!

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

Как проекты попадают на витрину App Store, почему разработка под iPhone – это не дешево и не быстро, зачем нужны апдейты и о многом другом рассказал Эмерик Тоа, креативный директор и со-основатель независимой студии The Game Bakers, разработавшей ролевую игру SQUIDS.

Миф первый: повсюду так много iPhone-ов и iPad-ов, что приличная игра уж точно тебя озолотит



Легко ошибиться, когда делаешь серьезные расчеты, сидя за чашечкой кофе со своим приятелем: «Так, в App Store 200 млн юзеров. Тебе нужно заинтересовать своим приложением за 1 бакс всего 0,1% от них, и у тебя в кармане будет 200 тысяч зеленых».

На самом деле все несколько иначе.

Была предпринята попытка сохранить оригинальную орфографию, шутки и пунктуацию. И, да, данный пост — перевод статьи создателя Canabalt, не думайте, что игру создал я.



[Эта статья рассматривает технические особенности, соотношения и размеры Flash версии игры Canabalt. Читатель, будь осторожен, статья содержит спойлеры и большое количество цифр!]

Друзья часто спрашивают меня: думал ли я о том, чтобы выложить исходный код моей Flash игры Canabalt в интернет на растерзание и изучение. Они думают, что для людей будет полезно увидеть, как в игре организована физика и другие вещи. Но я отношусь с опасением к этой идее, на это у меня есть несколько причин, например: исходный код игры написанный за 5 дней, представляет из себя кошмарный и отвратительный спагетти-код, который вряд ли поможет кому-нибудь. Поэтому, из чувства гордости по поводу первого дня рождения Cannabalt, я подумал: «почему бы не написать статью, в которой бы рассказывалось о том, как внутри всё устроено?»

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

Боевая задача.

Предположим нам хочется захостить небольшой проектик где-нибудь в надежном и не особо тормозящем месте. А поскольку сайт небольшой, то не будем заморачиваться и захотим от хостинга что-нибудь самое простое. Для наших целей вполне хватит PHP, MySQL и доступа по FTP.
Для решения этой задачи идеально подходит Веб сервис от Амазона в котором удивительным образом сочетается способность выдерживать большие нагрузки с бесплатным пакетом ресурсов на первый год после регистрации. В бесплатный пакет входит много чего, но в данный момент нас будут интересовать:

• Виртуальный сервер в формате micro на основе Linux с доступом по SSH.
• 30Гб места в Elastic Block Storage плюс 1Гб под бэкапы.
• 15 Гб трафика в месяц.
• Выделенный внешний IP адрес.

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

Добрый день, Хабр.

Я хочу написать цикл статей о создании расширений для Google Chrome. К этому меня побуждает, во-первых, практическая польза самого процесса разработки и последующего использования: вы сами определяете, какие ещё задачи хотите решить не выходя из браузера и, во-вторых, отсутствие каких-либо внятных гайдов, туториалов и справочников на русском языке, за исключением, пожалуй, этой и вот этой статей на Хабре. Основная цель цикла — систематизировать разрозненную информацию и облегчить поиск потенциальным разработчикам, благо индексируется Хабр хорошо :)

В первой (этой, то бишь) статье, на примере простейшего расширения, будут рассмотрены все основные моменты, связанные с разработкой, отладкой и использованием расширения, конфигурационный файл manifest.json и начала chrome.* API. Первая же статья, думаю, будет не очень полезна опытным разработчикам (это дисклеймер).

Оплата покупки на сайте — необходимый атрибут любого хорошего интернет-магазина. Это не просто правило хорошего тона, это значительное повышение оборотов. Способов оплаты в рунете много — электронные валюты Яндекс.Деньги, Киви, WebMoney, RBK Money, а также банковские карты, счета мобильных телефонов, смс микроплатежи и т.д. Как дать покупателям возможность оплачивать покупки любимым способом?
Для своего сервиса мы решили не заморачиваться и воспользовались услугами одного платежного агрегатора. Но по мере роста накопилось большое количество замечаний. Стало понятно, что агрегатор — временное решение, и рано или поздно от него придётся отказаться.

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

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

В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.

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

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

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

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

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

Заметил я как-то, что на моём компьютере карты в WoT загружаются очень долго — больше минуты. Заходишь, бывает, в бой, а он уже секунд 30 идёт. А иногда вообще обнаруживаешь свой танк уже в виде горящих обломков. Компьютер мой, конечно, старенький и давно просит апгрейда, но вначале можно попытаться сделать что-то программным путём.

Совсем недавно вышла первая beta php 5.4, а пока я писал топик подоспела и вторая. Одно из нововведений в 5.4 – это traits (типажи). Предлагаю разобраться во всех деталях в том, что же типажи из себя представляют в php.

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

//определение типажа
trait Pprint 
{
    public function whoAmI()
    {
        return get_class($this) . ': ' . (string) $this;
    }
}

class Human 
{
    use Pprint; //подключаем типаж, ключевое слово use

    protected $_name = 'unknown';
    
    public function __construct($name)
    {
        $this->_name = $name;
    }

    public function __toString()
    {
        return (string) $this->_name;
    }   
}

$a = new Human('Nikita');
echo $a->whoAmI(), PHP_EOL; //=> Human: Nikita

Как видно, к классу Human было добавлено поведение из типажа Pprint.

Но во всём есть свои детали.