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

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

Конечная цель любой балансировки игры – увеличение возврата игроков или времени партии. То есть играбельности механики:

• Не должно быть однозначной ультимативной стратегии победы, иначе игра потеряет вариативность и интерес.
• Игрок должен чувствовать, что от его действий и навыков зависит игра. Иначе получится Mass Effect, который, скорее, фильм, нежели RPG.
• Баланс должен быть «амортизированным», то есть прощать некоторые ошибки – иначе запоздалый на миллисекунду клик в Starcraft по первому рабочему из-за «эффекта бича» вызывал бы проигрыш через 4 часа идеальной партии. Наша настольная формула – 5-7 важных решений за игру, в двух можно ошибиться.
• У настолок есть ещё социальное условие: игроки не должны выпадать по ходу пьесы – интересно должно быть всем и до конца.

Теперь – методы.

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

Именно под таким названием мы и провели вебинар — «Зачем нужна теория вероятностей в жизни».

В вебинаре мы не касались «жёлтых» тем типа "как выигрывать у казино" и "100% способ получить миллион без регистрации и SMS".

Наоборот, были затронуты более серьёзные. Вот сам вебинар:



Например, в индустрии статистики больше денег, чем в торговле оружием, наркотиками и людьми вместе взятыми. Один малоизвестный английский учёный в 18 веке использовал статистику длительностей жизни (так называемые актуарные таблицы, составленные ещё Галлеем, который ещё и комету Галлея открыл) и основал бизнес, который сейчас стал целой индустрией, бизнесом №1 в мире. И вы тоже в нём участвуете каждый день, сознательно или нет, например, когда едете на работу.

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

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

По статистике в американских AppStore и в Google play игры со встроенными покупками занимают около 92% всех игр. В Азии 90% игр на мобильных платформах используют монетизацию встроенных покупок. Монетизация f2p знакома многим слоям общества, поэтому она и послужила притоку в индустрию огромного количества клиентов.

Как же добиться такого игрового баланса, который будет позволять играть абсолютно всем и в то же время работать на приток денег от пользователей в ваш проект? Ответить на этот вопрос я постараюсь в статье.

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

Привет, меня зовут Александр Волков, я проектирую интерфейсы в компании Docsvision. Цель этой статьи — помощь разработчикам сложных программных продуктов. Ключевое слово — сложных. Спроектировать сайт-визитку сегодня может даже пятиклассник прямо на своем смартфоне, и при желании можно скачать зип-архив с готовым шаблоном блога или корпоративного сайта. Однако если ваше приложение посложнее обычного интернет-магазина, то, вполне вероятно, строить структуру и определять принципы навигации вам придется самостоятельно, наступая на разбросанные повсюду грабли. Здесь может пригодиться наш опыт. Я опишу один из возможных способов проектирования интерфейсов, который успешно опробован в нашей компании. Это делается легко и просто (практически в полуавтоматическом режиме) при помощи программы FlyingLogic.

Меня зовут Оксана Харчук, я работаю QA-инженером в DataArt чуть больше года. Расскажу, как в нашем проекте организован процесс работы, и как быть, если релиз каждый день.

Сначала, когда я только пришла в DataArt, слово «релиз» ассоциировалось у меня с чем-то страшным. Но, как оказалось, если процесс работы построен правильно, релизы даже каждый день — совсем не страшно, а очень даже удобно.Чтобы этого достичь, процесс разработки в нашем проекте построен на принципах непрерывной поставки (continuous delivery) и непрерывной интеграции (continuous integration).

Что такое Continuous delivery и Сontinuous integration?

Continuous delivery или непрерывная поставка ПО — набор практик и принципов, нацеленных на сборку, тестирование и поставку ПО быстрее и чаще. Непрерывная поставка качественного кода опирается, в свою очередь, на непрерывную интеграцию.

Сontinuous integration, или непрерывная интеграция — это практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Ведь ясно: если над разными частями кода работают несколько программистов, при интеграции этих частей возникает много трудностей. Непрерывная интеграция помогает справиться с ними.

Термин «конверсия» многие годы был связан с гражданской продукцией предприятий ВПК. Но у IT-специалистов скорее возникнет совсем иная ассоциация. Однако сейчас мы хотели бы поговорить о таком понятии, как конверсионный дизайн. Общепринятый подход к разработке сайта выглядит примерно так: есть блок по веб-дизайну, есть блок по вёрстке, по разработке и так далее. Но, в течение последних двух-трёх лет всё начало стремительно меняться. Сам термин «веб-дизайн» постепенно умирает, потому что кроме браузера у нас появился адаптивный дизайн. По большому счёту, веб-дизайн перестал существовать в таком однозначном виде. Появились всякие дополнительные терминологии, как сервисный дизайн — data-driven design, который, в том числе, является конверсионным. Этому явлению посвятили своё выступление на киевской партнёрской конференции «1С-Битрикс» управляющий партнер компании AIC Сергей Попков и руководитель отдела продуктовой аналитики AIC Виталий Черемисинов.

Hola chicos!

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

Обрел же я его, проработав 5 лет в московском филиале компании Glu Mobile (4.5 лет из них — дизайнером) и 7 месяцев в компании Social Point, где и продолжаю работать на данный момент. Также я общался со многими людьми, которые работали в таких компаниях, как Game Insight, Crazy Panda, Game Garden и другие.

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

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

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

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

Именно так на протяжение долгого времени люди представляли себе жизнь тех, кто занимается тестированием компьютерных игр – не как работу по 5-9 часов в день, а как мечту всех подростков. Кто бы не хотел сидеть на комфортном диване и целый день играть в игры с небольшими перерывами на «подтягивание» графики в третьем уровне?

Первая часть здесь.

Старый видеролик с рекламой колледжа Уэствуд стал чем-то вроде шутки в мире видеоигр. Два парня, с комфортом устроившись на диване, убивают в хлам контроллеры, увлеченно играя на Sony PlayStation. Входит девушка и говорит: «Эй, ребята, вы уже закончили тестировать эту игру? У меня тут еще одна». «Мы только прошли третий уровень, графику надо немного подтянуть», — отвечает один из парней. Затем, развернувшись к своему другу, он улыбается, как будто только что выиграл в лотерею: «Не могу поверить, что мы играем в игры, и нам еще за это платят». «Знаю, – отвечает ему второй. – И моя мама говорила, что это мое увлечение видеоиграми ни к чему хорошему не приведет».

Именно так на протяжение долгого времени люди представляли себе жизнь тех, кто занимается тестированием компьютерных игр – не как работу по 5-9 часов в день, а как мечту всех подростков. Кто бы не хотел сидеть на комфортном диване и целый день играть в игры с небольшими перерывами на «подтягивание» графики в третьем уровне?

О том, как работали спецслужбы в СССР, известно довольно много, хотя и не все. Тем не менее, достоверно известно, что в СССР существовала система прослушивания телефонов. Эта система была достаточно развернутой, прослушивали многих, пишет Cnews. Но насколько все это было эффективным?

Ответы даются на вопрос в недавно вышедшей в США книге Red Web. Конечно, стоит с определенной степенью осторожности относиться к такого рода литературе, но готовили книгу не дилетанты, а российские журналисты, хорошо знакомые с тематикой.

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

Историческая справка

Факт 1: Blizzard – американская компания — разработчик компьютерных игр, издатель легендарных «нетлеющих» серий Starcraft, Warcraft и Diablo (Lost Vikings не в счёт).

Пояснение: Основана 8-го февраля 1991 года тремя выпускниками Калифорнийского университета в Лос-Анджелесе (UCLA): Майклом Морхеймом, Алленом Адамом и Фрэнком Пирсом, до Blizzard компания называлась Silicon & Synapse, после слияния с издателем игр Activision – Activision Blizzard. До слияния с Activision компания полностью откупается от Vivendi. Что происходило между этими событиями, подробно излагает Википедия:

В 1994 году, компания меняет название на «Chaos Studios», однако вскоре обнаруживается, что такое название уже занято, поэтому студия меняет название на «Blizzard Entertainment». В том же году компания была приобретена дистрибутором Davidson & Associates, за 10 миллионов долларов. Некоторое время спустя, Blizzard выпускает первый хит — Warcraft:Orcs & Humans.

Затем владелец Blizzard менялся ещё несколько раз: Davidson был приобретён вместе с Sierra On-Line компанией под названием CUC International в 1996 году; в 1997 году CUC объединился с отелем, агентством недвижимости и прокатом автомобилей (англ. HFS Corporation) в компанию Cendant Software. Но в 1998 году обнаружилось, что до слияния компаний, CUC участвовал в крупных денежных махинациях. В течение следующих шести месяцев акции Cendant упали на 80 %. Компания продала филиалы, занимающееся разработкой программного обеспечения, включая Blizzard, французскому издателю Havas. Но в том же 1998 году, Havas был куплен компанией Vivendi.

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

Штаб-квартира: Ирвайн, Калифорния. Дополнительные офисы: Сан-Франциско, Остин (Техас), Версаль (пригород Парижа), Корк (Ирландия), Стокгольм, Сеул, Шанхай, Тайпей и Сидней.

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

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

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

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

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

Например, получаются вот такие странные штуки:

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