Сегодня я бы хотел поделиться информацией о компоненте для yii, который позволяет отправлять смс рассылки через сервис sms.ru.

Полгода назад команда из нескольких энтузиастов открыла в Питере коворкинг-центр Зона действия. За прошедшее время по всей стране открылся еще десяток центров. Мы решили поделиться своими знаниями со всем нынешними и будущими создателями рабочих пространств. По нашим оценкам, к концу 2013 года, в России будет более 100 коворкинг-центров.

Команда

• Основные роли которые нужно распределить между участниками команды: администратор, дизайнер пространства, технические вопросы, продвижение, ивенты, сообщество, спецпроекты.
• Как правило, в основной команде будет 4-8 человек и еще 5-20 волонтереов или друзей проекта.
• Зарплаты с первого дня. Несколько сильных профессионалов на старте значительно улучшат результат по сравнению с полностью волонтерской командой.
• Коворкинг — это бизнес тысячи мелочей. Все в голове не удержишь, так что нужно использовать вики, гугл-доки или Trello/Basecamp/Asana.

Успеваете ли вы делать всё, что планируете? Храните ли сотни невыполненных задачек пылящимися на полке, или решаете одну за одной? Чувствуете ли вы в целом удовлетворение в достижении своих желаний (и неважно каких, рабочих или личных)?

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

Это вторая часть доклада, который я прочитал на Dribbble Meetup 2013 в Москве. В первой части я подробно описал свой процесс интеграции дизайна под платформу Android. Эта часть — про интеграцию дизайна под iOS и Windows Phone, а также я вскользь упомяну про Samsung Bada 2.0. Дальше — много картинок.

Реборн, реюнион, ревивал, перезапуск – все это частные случаи Возрождений. Либо перекладывание старого на новый мотив, либо следующая часть призванная вернуть жизнь игре. Можно было бы сказать «но в наше время мы живем реалиями…» и солгать. Потому, что нет «нашего времени» в отношении понятия рынок. Вернее время то есть, но рынок вне времени. Он существовал задолго до нас, задолго до чеканки монет и появления денежных знаков. Он будет существовать и после. Не вечно, но до тех пор, пока на Земле не останется один человек. Двое – уже могут «толкать» друг дружке, как речи, так и вещи.

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

Вам что-нибудь говорит имя Flashback? Chaos Engine?

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

Каждая игра представляет собой бизнес-процесс, определённый рядом характеристик и параметров. На входе мы задаём средства, необходимые для разработки и продвижения проекта. На выходе имеем прибыль от его оперирования.


Рассмотрим по пунктам каждый элемент структуры затрат этого бизнес-процесса.

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

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

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

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

Эта маленькая библиотека позволяет очень просто создать пошаговое введение для сайта или приложения. Достаточно добавить атрибуты data-intro и data-step с описанием и номером шага соответственно к нужным элементам страницы. Вот так:

<a href='http://google.com/' data-intro='Hello step one!' data-step='1'></a>

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

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

Пройдемся по дизайну, серверным решениям, тестированию и аналитике.

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

На хабре есть много тем по специфичным аспектам менеджмента проектов. Но именно основы менеджмента до сих пор не были освещены.

Попробуем закрыть этот пробел.

Кратко обозначены, выделены и пояснены основные, наиболее важные моменты.

UPD. Пост про менеджмент, а не про менеджеров.

Все чаще приходится слышать: "Работай на результат!"

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

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

"Обязательна ориентированность на результат!" — напишет пожилая кадровичка «ГорАвиаВагонМорСтроя» в требования к кандидату на должность помощника бухгалтера, будучи уверенной в том, что раз все так пишут, то и ей надо.

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

Культ карго. Мало кто из произносящих эту фразу может внятно объяснить, какой смысл в неё вкладывается. Люди верят в неё, как в волшебную формулу, заклинание, они пихают её куда ни попадя, надеясь, что она придаст им уникальность, выделит их из толпы таких же неудачников. Организации, Компании, конторы да и откровенные «шараги» не мыслят себя без этого лозунга. Как же это, «Рога и копыта» работают на результат, а мы, что, хуже?



А хуже ли?

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

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

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

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

Меня всегда интересовал геймдев. Несколько лет назад я сделал шаг и окунулся в этот мир. Меня поражал успех Энгри Бердс (Angry Birds), взлёт и падение Зинги (Zynga), и одна мысль мне не давала спать — «Как же они сделали такие классные игры?».

Прошло немало времени, накопился ящик опыта, в закромах образовались какие-то отрывочные записи и комментарии. Я решил все структурировать и систематизировать, стараясь ответить на один из краеугольных вопросов — «Почему же пользователь вернётся в игру?».

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

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

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

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

Установка копирайта и публикация в портфолио

Очень часто при общении с заказчиком при запуске нового проекта конфликтным моментом становится размещение «марки» студии на сайте («Сделано в XXX » и пр.). Если данный момент никак не обозначен в договоре, то убедить заказчика прислушаться к вашим доводам бывает сложно. Часто проблемы возникают в самый последний момент, даже если изначально лейбл присутствовал и на макетах, и на тестовой зоне: «Ой, а мы не думали, что так и пойдет на основную версию сайта». Итак, что рекомендуется сделать:

^{Бизнес-ангел часто смотрит на стартаперов с недоумением}

Предположим, вы придумали какое-то железо, и теперь хотите начать его производство. У вас уже есть прототип: вот он, в руке, коряво выглядит, в 4 раза больше нормального размера и из него торчит провод. Но он работает. У вас горят глаза: ведь осталось только «допилить» его и начать производить по всему миру. Из маркетингового плана у вас есть только «запостить про железку на Хабр – и всё закрутится».

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

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

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

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

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

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

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

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

Заголовок получился достаточно желтый, но он лучше всего передает суть поста: можно создать свое вычислительное облако, которое будет на порядок дешевле, чем предлагает Amazon EC2. Есть множество нюансов, из-за которых подобное “дешевое облако” может не подойди, но, на мой взгляд, для многих задач оно вполне подходит и справляется с ними отлично.

Далее я хочу рассказать о нашем опыте использования OpenStack, развернутого у Hetzner’a, и привести расчеты стоимости подобного облака.

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

На тот момент у меня был ZX Spectrum (чьих 128 Kb явно не хватало на запуск чего-то похожего на ИИ) и много (думаю лет 10) свободного времени. Благодаря последнему факту, я благополучно дождался эры виртуализации. Можно было снять хоть 10K VPS, установить между ними канал связи и начинать создавать ИИ. Но мне хотелось заниматься программированием, а не администрированием/конфигурацией grid-системы, и я разумно начал ждать, когда вычислительные ресурсы начнут предоставляться как сервис.

Моей радости не было конца, когда появились облачные сервисы. Но радость длилась недолго: стало понятно, что пока прямые коммуникации между отдельными вычислительными инстансами – это фантастика код, который нужно писать самому (то есть с большой вероятностью он работать не будет). Попереживав пару лет по этому поводу, я (мы все) дождался Hadoop, сначала «on-premises», а потом и эластичного «on-demand». Но и там, как оказалось, не всё так эластично гладко