Microsoft советует воздержаться от установки обновления MS14-045

сегодня в 22:32

Компания Microsoft рекомендует отказаться от установки обновления MS14-045 (KB2982791), которое вышло на этой неделе в рамках patch tuesday. После установки этого обновления компьютер пользователя может оказаться неработоспособным, в частности, функционирование Windows может происходить с BSOD или «синим экраном смерти», который не позволит нормально загрузить компьютер. Пользователям, которые установили данное обновление и столкнулись с проблемой, компания предлагает инструкции по ее решению. Так ли иначе, ссылка на это обновление была удалена с веб-сайта Microsoft.

Обновление MS14-045 (Vulnerabilities in Kernel-Mode Drivers Could Allow Elevation of Privilege) исправляет три уязвимости типа Elevation of Privelege в системных драйверах всех поддерживаемых версий Windows. Речь идет об исправлении драйверов подсистемы Windows (win32k.sys) и DirectX (Dxgkrnl.sys). У пользователей с установленным обновлением могут происходить постоянные BSODы, кроме этого у Windows может нарушиться нормальная работа со шрифтами (неправильное их отображение).

After you install this security update, fonts that are installed in a location other than the default fonts directory (%windir%\fonts\) cannot be changed when they are loaded into any active session. Attempts to change, replace, or delete these fonts will be blocked, and a «File in use» message will be presented.

Если вы столкнулись с данной проблемой воспользуйтесь инструкциями раздела Mitigations в этой статье поддержки компании (потребуется перезагрузка в безопасном режиме).

Только зарегистрированные пользователи могут оставлять комментарии.

Войдите, пожалуйста.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Нововведения в PHP 5.6 beta 3

Так как PHP — развивающийся язык, то я расскажу об уже реализованных возможностях в третьем бета релизе версии 5.6. По сути, эта публикация — дополнение к предыдущей: "Функции в PHP 5.6 — что нового?".

Магический метод __debugInfo().

Возвращает массив, в котом содержится любая информация добавленная разработчиком. Вызывается в том случае, когда объект передается в качестве аргумента, например, в функцию var_dump().

Пример:

namespace Application;

class Test
{
    public $prop = 200;

    public function __debugInfo()
    {
        return [1];
    }
}

var_dump(new Test);

Результат выполнения:

object(Application\Test)#2 (1) {
  [0]=>
  int(1)
}

Примечание:

Если в возвращаемый массив поместить переменную $this, то вы войдете в бесконечный цикл. :)

Экспоненциальный оператор **.

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

Пример:

$exponent = 2 ** 4;
var_dump($exponent); // int(16)
$exponent **= 2;
var_dump($exponent); // int(256)

unset($exponent);

$exponent = ~2;
var_dump($exponent); // int(-3)
$exponent **= 2;
var_dump($exponent); // int(9)

Примечание:

Также это работает и с GMP.

Пример:

$base = gmp_init(2);
var_dump($base ** 3); 

Результат выполнения:

object(GMP)#3 (1) {
  ["num"]=>
  string(1) "8"
}

Языковые конструкции use function и use const.

Импорт функций и констант (из пространств имен) — это как импорт классов — круто. На первый взгляд. Когда доходит до дела, то работает оно, по крайней мере сейчас, плохо.

Пример:

namespace Application
{
    const TEST = 2 * 4;
    function test()
    {
        return TEST;
    }
}

namespace
{
    use const Application\TEST;
    use function Application\test;

    var_dump(test(), TEST);
}

Результат выполнения:

int(8)
int(8)

Вроде бы и неплохо, но нет автозагрузки — она реализованна только для классов. Так что данное «улучшение», сейчас, только добавляет необходимость использовать дополнительный синтаксис. Отныне, если указано пространство имен, то к функции невозможно обратиться даже выполнив include (или require) файла в котором она содержится и придется еще дописать use function Name\Space\the_func. А если функций много..?

Улучшенная автозагрузка классов.

Это, правда, было исправлено еще в версии 5.5, но упомянуть стоит.

Пример:

spl_autoload_extensions('.php');
spl_autoload_register();

Ранее, вышеприведенный код работал бы только на компьютере под управлением ОС семейства Windows. Но почему? Все просто. Разделитель вложенности у пространств имен — это символ "\", а в win-системах это еще и разделитель директорий и он отличается от оного в unix системах. По этому-то ранее приходилось делать что-то подобное:

spl_autoload_register(function ($class_path) {
    require_once str_replace('\\', '/', $class_path) . '.php';
});

Указана кодировка по умолчанию.

Отныне, input_encoding, output_encoding и internal_encoding, по умолчанию имеют значение "UTF-8".

Обо всех реализованных возможностях можно прочесть перейдя по ссылке: http://ift.tt/1v1wDeN

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Разработать приложение за 48 часов

сегодня в 21:27

Добрый день, уважаемые читатели Хабрахабра!

На дворе лето, в головах ветер, в сердце покой, а мы, в нашем скромном кругу Бессвязного Девелопа, решили устроить еще один хакатон по разработке мобильных приложений за 48 часов. За следующие 2 дня мы постараемся разработать приложение для Нелли Ермолаевой и Екатеринбург Экспо.

В программе трансляции:

• Cocoa-pods — долгое время мы отказывались от использования подов из-за призрачной грязи в проектах. Однако совсем недавно мы решили исправиться и поднять работу с этой технологии в рамках хакатона


• Layer — инновационный движок мгновенных сообщений от создателей iMessages


• Synx — программа-сортировщик для файлов проекта в Xcode


• Alcatraz — менеджер расширений Xcode


• Работа с VK, Instagram, Twitter API


• Разработка нестандартных элементов UI


• Приложения от нуля и до релиза


• Веселье, хорошая музыка и многое другое!

Ссылка на трансляцию.

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

Сегодня с вами:

• Олег — великолепный iOS программист, автор множества внутренних инструментов и политики структуризации кода студии


• Денис — замечательный дизайнер, закончивший гигантское количество проектов


• Никита — просто веселый iOS программист, который повелся на бесплатные печеньки и кофе всем участникам хакатона

А пока вы раздумываете, смотреть наш хакатон или нет — обязательно поучаствуйте в нашем конкурсе фотографий на 5000 рублей ;)

До скорых встреч!

Только зарегистрированные пользователи могут оставлять комментарии.

Войдите, пожалуйста.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

ТОП 10 московских стартапов

http://ift.tt/1m5BuGs

Посмотрел ТОП 10 московских стартапов. Уровень инноваций зашкалил и я решил немного написать.

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

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

Знаете, стартап-индустрия сформирована по тем же принципам, по которым формуется индустрия развлечений.

«Хочешь изменить мир? У тебя отличная идея? Надоело работать в офисе? Будь ярче!»

За Цукербергом, Джобсом, Ельциным, Че Геварой стояли очень и очень серьезные люди в строгих костюмах. Их образ всего лишь трюк. Каждый образ трюк в своей индустрии.

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

Вы не обращали внимание что в СМИ проекты оцениваются не по технологичности и полезности, а по количеству привлеченных денег и закрытых инвестиционных раундов? Это потому что у тех, кто пишет эти статьи нет других метрик в оценке. Я не говорю, что люди плохие. Просто у них работа такая. Это нужно понимать. Помните, как было c национальной, принципиально новой операционной системой которую написал школьник и назвал ее BolgenOS? Вот почти те-же люди пишут про технологии и стартапы. Те, кто понимает в технологиях и бизнесе — занимаются технологиями и бизнесом.

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

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

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

Если вы сами не можете сделать проект доходным — чужие деньги не помогут. Это значит, что в самом фундаменте, в основе проекта есть брешь. Эту брешь не закроют деньги. Ее закроет ваше переосознание.

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

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

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

Но где корень этого бинарного дерева, эликсира успешного бизнеса?

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

Есть хороший способ получать эти навыки и еще получать деньги за это.

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

Стимулируйте все, что делает ваше намерение и волю железными. И уходите от всего что делает вас слабыми.

PS

Специалисты с минусами, умными словами и прочие диванные аналитики, которые заработали целый миллион.

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

Если этот пост сэкономит кому-то хоть день его нелегкой жизни — это будет действительно важно.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Филдсовскую медаль по математике впервые в истории получила женщина

37-летний профессор математики Мариам Мирзахани (Maryam Mirzakhani) из Стэнфордского университета стала первой женщиной, которая получила Филдсовскую премию — самую престижную награду в области математики.

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

Филдсовская премия и медаль (Fields Medal) вручаются один раз в 4 года на каждом международном математическом конгрессе двум, трём или четырём молодым математикам не старше 40 лет. Поскольку Нобелевская премия математикам не вручается, то Филдсовскую премию часто называют «Нобелевской премией для математиков».





Профессор математики Стэнфордского университета Мариам Мирзахани

Филдсовская премия отличается от Нобелевской тем, что её вручают с возрастным ограничением в 40 лет. Это объясняется тем, что премия должна являться не только признанием заслуг, но и стимулом для продолжения дальнейшей работы.

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

В старших классах Мариам хотела доказать, что может быть лучше самых талантливых мальчиков (в Иране до сих пор существуют отдельные женские школы — в такой и училась Мариам — и другие «дискриминации» к слабому полу). До неё никогда в сборной страны для Международной математической олимпиады не было девочек, и молодая Мариам неделями сидела за учебниками, чтобы решить задачи с Олимпиады и доказать свою пригодность.

Четырёхлетняя Мариам вообще не интересовалась математикой. Да и потом её больше интересовали книжки о приключениях: она хотела прочитать все книги в библиотеке

В 1994 году, в возрасте 17 лет Мариам со своей подругой Роей Бехешти (сейчас профессор математики в Вашингтонском университете) стали первыми в истории Ирана девочками, попавшими в национальную команду для Международной математической олимпиады. Команда завоевала золотую медаль.

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

Даже сейчас, говорят коллеги, Мариам «производит впечатление 17-летней девочки, которая абсолютно восхищена всей математикой, что происходит вокруг неё».

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

В начале 2000-х многие относительно простые свойства плоскостей Лобачевского, открытых 150 лет назад, оставались неизвестными. Например, что будет с прямыми линиями (геодезическими) на такой плоскости. В своей докторской диссертации Мариам элегантно ответила на этот вопрос, так что её решение «словно просится в учебник», со слов коллег.

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

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

Другие лауреаты Филдсовской премии 2014 года

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

Манджул Бхаргава (Manjul Bhargava) за разработку ярких новых методов в геометрии чисел, которые он применил к подсчёту колец малого ранга и к границам среднего ранга эллиптических кривых.

Мартин Хайрер (Martin Hairer) за выдающийся вклад в теорию стохастических уравнений с частными и, конкретно, за создание теории регулярности структур для таких уравнений.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

На кого работает дизайнер?

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

Конфликт интересов

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

• Задача заказчика: извлечение максимально возможной коммерческой прибыли.


• Задача пользователя: эффективное удовлетворение актуальной потребности.

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

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

Внутренний конфликт дизайнера

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

На кого работает дизайнер?

Дизайнер — всегда работает на пользователя, дизайнер несет полную социальную ответственность за то, что он создает.

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

P.S. Все изложенное в этой статье — субъективное мнение автора, основанное на собственном опыте и наблюдениях.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] 10 самых распространённых ошибок при программировании на JavaScript

Сегодня JavaScript лежит в основе большинства современных веб-приложений. При этом за последние годы появилось большое количество JavaScript-библиотек и фреймворков для разработчиков Single Page Application (SPA), графики, анимации и даже серверных платформ. Для веб-разработки JavaScript используется повсеместно, и поэтому качество кода обретает всё большее значение.

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

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

Например, выполнение этого кода:

Game.prototype.restart = function () {
    this.clearLocalStorage();
    this.timer = setTimeout(function() {
        this.clearBoard();    // что здесь "this"?
    }, 0);
};

Приводит к ошибке:

Uncaught TypeError: undefined is not a function

Почему это происходит? Всё дело в контексте. Когда вы вызываете setTimeout(), то на самом деле вызываете window.setTimeout(). В результате, анонимная функция, передаваемая в setTimeout(), определяется в контексте объекта window, который не имеет метода clearBoard().

Традиционное решение, совместимое со старыми браузерами, предполагает простое сохранение ссылки на this в переменной, которая может быть сохранена в замыкании:

Game.prototype.restart = function () {
    this.clearLocalStorage();
    var self = this;   // сохраним ссылку на 'this', пока это все еще 'this'!
    this.timer = setTimeout(function(){
        self.clearBoard();    // все в порядке
    }, 0);
};

Для новых браузеров можно использовать метод bind(), позволяющий связать функцию с контекстом исполнения:

Game.prototype.restart = function () {
    this.clearLocalStorage();
    this.timer = setTimeout(this.reset.bind(this), 0);  // связываем 'this'
};

Game.prototype.reset = function(){
    this.clearBoard();    // возвращаемся в контекст правильного 'this'!
};

Разработчики часто считают, что JavaScript создаёт новую область видимости для каждого блока кода. Хоть это и справедливо для многих других языков, но в JavaScript этого не происходит. Посмотрим на этот код:

for (var i = 0; i < 10; i++) {
    /* ... */
}
console.log(i);  // что здесь выведется?

Если вы думаете, что вызов console.log() повлечёт за собой вывод undefined или ошибку, то вы ошибаетесь: будет выведено «10». Почему? В большинстве других языков этот код привёл бы к появлению ошибки, потому что область видимости переменной i была бы ограничена блоком for. Однако в JavaScript эта переменная остаётся в области видимости даже после завершения цикла for, сохраняя своё последнее значение (такое поведение известно как «var hoisting»). Надо заметить, что поддержка области видимости на уровне блоков введена в JavaScript начиная с версии 1.7 с помощью дескриптора let. Утечки памяти практически неизбежны, если во время работы вы не будете их сознательно избегать. Существует немало причин для появления утечек, но мы остановимся лишь на самых частых.

Ссылки на несуществующие объекты. Проанализируем этот код:

var theThing = null;
var replaceThing = function () {
    var priorThing = theThing;  // hold on to the prior thing
    var unused = function () {
        // 'unused' - единственное место, где используется 'priorThing',
        // но 'unused' никогда не вызывается
        if (priorThing) {
            console.log("hi");
        }
    };
    theThing = {
        longStr: new Array(1000000).join('*'),  // создаем 1Mб объект
        someMethod: function () {
            console.log(someMessage);
        }
    };
};
setInterval(replaceThing, 1000);    // вызываем 'replaceThing' каждую секунду

Если запустить выполнение этого кода, то можно обнаружить массивную утечку памяти со скоростью около мегабайта в секунду. Создается впечатление, что мы теряем память выделенную под longStr при каждом вызове replaceThing. В чём причина?

Каждый объект theThing содержит свой собственный объект longStr размером 1Мб. Каждую секунду при вызове replaceThing, функция сохраняет ссылку на предыдущий объект theThing в переменной priorThing. Это не проблема, ведь каждый раз предыдущая ссылка priorThing будет перетерта (priorThing = theThing;). Так в чём же причина утечки?

Типичный способ реализации замыкания — это создание связи между каждым объектом-функцией и объектом-словарем, представляющим собой лексическую область видимости для этой функции. Если обе функции (unused и someMethod), определенные внутри replaceThing, реально использоуют priorThing, то важно понимать, что они получают один и тот же объект, даже если priorThing переписывается снова и снова, так как обе функции используют одну и ту же лексическую область видимости. И как только переменная используется в любым из замыканий, то она попадает в лексическую область видимости, используемую всеми замыканиями в этой области видимости. И этот маленький нюанс приводит к мощной утечке памяти.

Циклические ссылки. Рассмотрим пример кода:

function addClickHandler(element) {
    element.click = function onClick(e) {
        alert("Clicked the " + element.nodeName)
    }
}

Здесь onClick имеет замыкание, в котором сохраняется ссылка на element. Назначив onClick в качестве обнаботчика события click для element, мы создали циклическую ссылку: element -> onClick -> element -> onClick -> element…

Даже если удалить element из DOM, то циклическая ссылка скроет element и onClick от сборщика мусора и произойдет утечка памяти. Как лучше всего избегать возникновения утечек? Управление памятью в JavaScript (и в частности сборка мусора) в значительной степени основано на понятии достижимости объекта. Следующие объекты считаются достижимыми и известны как корневые:

• ссылки на которые содержатся в стеке вызова (все локальные переменные и параметры функций, которые в настоящий момент вызываются, а также все переменные в области видимости замыкания);


• все глобальные переменные.

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

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

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

// Все эти сравнения выдадут 'true'!
console.log(false == '0');
console.log(null == undefined);
console.log(" \t\r\n" == 0);
console.log('' == 0);

// И эти тоже!
if ({}) // ...
if ([]) // ...

С учётом последних двух строк, даже будучи пустыми, {} и [] фактически являются объектами. А любой объект в JavaScript соответствует булевому значению true. Однако многие разработчики считают, что значение будет false.

Как показывают два приведённых примера, автоматическое преобразование типа иногда может мешать. Как правило лучше использовать === и !== вместо == и !=, чтобы избежать побочных эффектов преобразования типов.

Кстати, сравнение NaN с чем-либо (даже с NaN!) всегда даст результат false. Таким образом, нельзя использовать операторы равенства (==, ===, !=, !==) для определения соответствия значения NaN. Вместо этого нужно использовать встроенную глобальную функцию isNaN():

console.log(NaN == NaN);    // false
console.log(NaN === NaN);   // false
console.log(isNaN(NaN));    // true

В JavaScript можно легко работать с DOM (в том числе добавлять, изменять и удалять элементы), но часто разработчики делают это неэффективно. Например, добавляют серии элементов по одному за раз. Однако операция добавления элементов весьма затратна, и последовательного её выполнения нужно избегать.

Если нужно добавить несколько элементов, то, в качестве альтернативы, можно использовать фрагменты документа:

var div = document.getElementsByTagName("my_div");

var fragment = document.createDocumentFragment();

for (var e = 0; e < elems.length; e++) {
    fragment.appendChild(elems[e]);
}
div.appendChild(fragment.cloneNode(true));

Также рекомендуем сначала создавать и модифицировать элементы, а потом уже добавлять в DOM, это также существенно повышает производительность. Рассмотрим пример кода:

var elements = document.getElementsByTagName('input');
var n = elements.length;    // предположим, у нас есть 10 элементов
for (var i = 0; i < n; i++) {
    elements[i].onclick = function() {
        console.log("This is element #" + i);
    };
}

При клике на любом из 10 элементов появлялось бы сообщение «This is element #10». Причина в том, что к тому времени, когда onclick вызывается любым из элементов, вышестоящий цикл for будет завершён, а значение i будет равно 10.

Пример правильного кода:

var elements = document.getElementsByTagName('input');
var n = elements.length;    // предположим, у нас есть 10 элементов
var makeHandler = function(num) {  // внешняя функция
     return function() {   // внутренняя функция
         console.log("This is element #" + num);
     };
};
for (var i = 0; i < n; i++) {
    elements[i].onclick = makeHandler(i+1);
}

makeHandler немедленно запускается на каждой итерации цикла, получает текущее значение i+1 и сохраняет его в переменной num. Внешняя функция возвращает внутреннюю функцию (которая также использует переменную num) и устанавливает ее в качестве обработчика onclick. Это позволяет гарантировать, что каждый onclick получает и использует правильное значение i. Удивительно много разработчиков не имеют ясного понимания механизма наследования через прототипы. Рассмотрим пример кода:

BaseObject = function(name) {
    if(typeof name !== "undefined") {
        this.name = name;
    } else {
        this.name = 'default'
    }
};

var firstObj = new BaseObject();
var secondObj = new BaseObject('unique');

console.log(firstObj.name);  // -> в 'default'
console.log(secondObj.name); // -> в 'unique'

Но если бы мы написали так:

delete secondObj.name;

то получили бы:

console.log(secondObj.name); // -> в 'undefined'

Но не лучше ли вернуть значение к default? Это можно легко сделать, если применить наследование через прототипы:

BaseObject = function (name) {
    if(typeof name !== "undefined") {
        this.name = name;
    }
};

BaseObject.prototype.name = 'default';

Каждый экземпляр BaseObject наследует свойство name своего прототипа, в котором ему присвоено значение default. Таким образом, если конструктор вызван без name, свойство name по умолчанию будет default. И точно так же, если свойство name будет удалено из экземпляра BaseObject, будет произведен поиск по цепочке прототипов и свойство name будет получено из объекта prototype, в котором оно по-прежнему равно default:

var thirdObj = new BaseObject('unique');
console.log(thirdObj.name);  // -> в 'unique'

delete thirdObj.name;
console.log(thirdObj.name);  // -> в 'default'

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

var MyObject = function() {}

MyObject.prototype.whoAmI = function() {
    console.log(this === window ? "window" : "MyObj");
};

var obj = new MyObject();

Для удобства, создадим ссылку на метод whoAmI:

var whoAmI = obj.whoAmI;

Выведем значение нашей новой переменной whoAmI:

console.log(whoAmI);

В консоли будет выведено:

function () {
    console.log(this === window ? "window" : "MyObj");
}

А теперь обратите внимание на разницу при вызовах obj.whoAmI() и whoAmI():

obj.whoAmI();  // выведет "MyObj" (как и ожидалось)
whoAmI();      // выведет "window"

Что пошло не так? Когда мы присвоили var whoAmI = obj.whoAmI;, новая переменная была определена в глобальном пространстве имён. В результате значение this оказалось равным window, а не obj, экземпляру MyObject. Таким образом, если нам действительно нужно создать ссылку на существующий метод объекта, необходимо сделать это в пределах пространства имён этого объекта. Например:

var MyObject = function() {}

MyObject.prototype.whoAmI = function() {
    console.log(this === window ? "window" : "MyObj");
};

var obj = new MyObject();
obj.w = obj.whoAmI;   // в пространстве имен объекта

obj.whoAmI();  // выведет "MyObj" (как и ожидалось)
obj.w();       // выведет "MyObj" (как и ожидалось)

Само по себе это не является ошибкой. И дело тут не только в производительности. Дело в том, что когда вы передаете строковую переменную первым аргументом в setTimeout или setInterval, она будет передана конструктору Function для преобразования в новую функцию. Этот процесс может быть медленным и неэффективным.

Альтернативой является использование функции в качестве первого аргумента:

setInterval(logTime, 1000);   // передаем функцию logTime в setInterval

setTimeout(function() {       // передаем анонимную функцию в setTimeout
    logMessage(msgValue);     // (msgValue здесь всё ещё доступна)
}, 1000);

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

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


• Предотвращение случайного появления глобальных переменных. Присвоение значения необъявленной переменной автоматически создаёт глобальную переменную с таким именем. Это одна из наиболее распространённых ошибок в JavaScript. В «строгом режиме» это приведёт к появлению сообщения об ошибке.


• Запрет на дублирование названий свойств или значений параметров. Если при включённом «строгом режиме» у объекта обнаруживается дублирование названий свойств (например, var object = {foo: "bar", foo: "baz"};) или названий аргументов у функции, то будет выведено сообщение об ошибке. Это позволяет быстро обнаружить и устранить баг.


• Уменьшение потенциальной опасности eval() . В «строгом режиме» переменные и функции, объявленные внутри eval(), не создаются в текущей области видимости.


• Получение сообщения об ошибке при ошибочном использовании оператора delete . Этот оператор не может быть применён к свойствам объекта, у которых флаг configurable равен false, и при попытке это сделать будет выведено сообщение об ошибке.

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

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Back to the Scala Future

Добрый вечер господа читатели. Сегодня мне хотелось бы пролить немного света на такую замечательную часть scala core под названием Future . Собственно существует документация на официальном сайте, но там идет объяснение как работать с ним при помощи event driven подхода. Но при это Future является также и монадой. И в данной статье я хотел привести примеры и немного растолковать как их надо использовать в этом ключе (а точнее свое видение этого вопроса). Всех желающим ознакомится с вопросом прошу под кат.

Чего здесь не будет

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

Что будет

А писать я буду как раз про функции которые дают Future поведение монады.

map

Итак обратимся к api:

def map[S](f: (T) ⇒ S)(implicit executor: ExecutionContext): Future[S]

Что же делает map ? При удачном исполнении Future, будет выполнена функция f с переданным в нее результатом. То есть:

Future(5) map (2*) map println

В конечно итоге этот код выведет 10 на экран как и ожидалось. Если же результат будет Failure, то функция не будет исполнена:

Future(5) map (_ / 0) map println

Вторая функция выбросит исключение и ничего не будет выведено на экран.

Итак для чего же стоит использовать map ? — для последовательных операций, которые требуют результат предыдущей.

flatMap

Искушенный читатель понимает что монада может быть внутри монады и надо это дело как то исправлять:

def flatMap[S](f: (T) ⇒ Future[S])(implicit executor: ExecutionContext): Future[S]

flatMap берет функцию, которая возвращает другой Future , и возвращает его.

def f(a: Int): Future[Int] = Future(a * 5)
Future(2) flatMap (f) map println

На экран будет выведено число 10. В случае с неудачным исполнением, поведение такое же как и в map .

flatMap следует использовать в случае цепочных операций, которые возвращают Future.

for

Не надо лететь и гневно писать, что for это не функция, а синтаксическая конструкция. Да, я знаю, но не рассказать про нее было бы глупо

Коль уж мы рассмотрели map и flatMap , нужно рассмотреть использование с for-comprehensions .

Давайте рассмотрим некоторые плохой и хороший примеры использования for с Future:

//Плохо
for {
 a <- longComputations1()
 b <- longComputations2()
 c <- longComputations3()
} yield a*b*c

//Лучше
val f1 <- longComputations1()
val f2 <- longComputations2()
val f3 <- longComputations3()
for {
 a <- f1
 b <- f2
 c <- f3
} yield a*b*c

Результат обоих операций будет одинаков, но…

Почему плохо?

Ну на самом деле ответ прост:

for {
 a <- longComputations1()
 b <- longComputations2()
 c <- longComputations3()
} yield a*b*c

развернется в:

longComputations1().flatMap { a =>
 longComputations2().flatMap { b =>
  longComputations3().flatMap { c =>
   a*b*c
  }
 }
}

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

zip

Ранее была рассмотрена проблема использования нескольких Future одновременно. Что же, zip решает эту проблему. Он берет два Future и упаковывает их результаты в Tuple2. И вот наш пример сверху как запишется теперь:

longComputations1() zip longComputations2() zip longComputations3() map { 
 case ((a, b), c) => a * b * c
}

Лично по моему, все куда чище и проще.

filter и withFilter

def filter(p: (T) ⇒ Boolean)(implicit executor: ExecutionContext): Future[T]
final def withFilter(p: (T) ⇒ Boolean)(implicit executor: ExecutionContext): Future[T]

Тут все логично, берем результат, тестируем его, и если оно не подходит то дальше будет Future с Failed, в котором будет запаковано NoSuchElementException .

recover и recoverWith

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

def recover[U >: T](pf: PartialFunction[Throwable, U])(implicit executor: ExecutionContext): Future[U]

def recoverWith[U >: T](pf: PartialFunction[Throwable, Future[U]])(implicit executor: ExecutionContext): Future[U]

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

Future(5) map (_ / 0) recover { case _ => 0 } map println

Тут у нас будет обработано исключение и выведется 0.

forEach

По сути представляет из себя map , только результат не пакуется в новый Future, а просто возвращается Unit:

def foreach[U](f: (T) ⇒ U)(implicit executor: ExecutionContext): Unit

По сути предыдущие примеры не совсем корректны и лучше было бы написать:

Future(5) map (2*) foreach println

Тут мы избежали одного лишнего создания Future.

Более общий пример

Итак мы имеем:

def f1: Future[Double]
def f2: Future[Double]
def f3(a: Double): Future[Double]
def f4: Future[Double]
def f5(a: Double, b: Double, c: Double): Future[Double]

Мы знаем, что в f3 должен быть передан результат выполнения f2, а в f5 должны быть переданы результаты выполнения f1, f3 и f4. И в конце результат должен быть выведен в стандартный поток вывода. Также известно, что f3 может выбросить исключение, и в этом случае должен быть возвращен 0.

Поехали:

val r1 = f1()
val r2 = f2() flatMap (f3) recover { case _: Exception => 0 }
var r3 = f4()
for {
 a <- r1
 b <- r2
 c <- r3
} yield f5(a, b, c)

Я же предпочитаю:

(f1 zip f4)
 .zip(f2() flatMap (f3) recover { case _: Exception => 0 }) flatMap {
 case ((a, b), c) => f5(a, b, c)
}

А как бы записали вы?

Послесловие

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

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

Спасибо за внимание.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Как я вышел на рынок мобильных игр, постоял и ушел. Семинар в Яндексе

Привет, меня зовут Всеволод Шмыров. В Яндексе я занимаюсь разработкой интерфейсов. Но этот пост посвящен тому, как я just for fun попробовал выйти на рынок игр под Windows Phone. Я разработал небольшую игру-арканоид. Примерно год назад я подготовил небольшой доклад об этом и представил его своим коллегам. Доклад охватывает все четыре стадии, которые мне пришлось пройти: подготовка, разработка, публикация и после публикации. Сегодня я хочу поделиться этим рассказом с вами. Сразу оговорюсь, что это не история успеха. Популярной моя игра так и не стала, так что идею заработать на ней я забросил и сделал игру бесплатной.

Для начала представлю свою игру. Она называется Pixelnoid. Геймплей абсолютно классический для арканоида: игрок управляет платформой, отбивает мячики, мячики сбивают блоки. Цель каждого уровня – уничтожить все доступные блоки. Игра обладает очень необычной графикой, вместо мячика пиксель, вместо блока пиксель побольше, все пиксели разноцветные, и поэтому получается составлять вот такие простые писксельные изображения, как на заглавной картинке. На самом деле там используется всего лишь 400 пикселей. Игра доступна для платформы Windows Phone, начиная с версии 7.5. Изначально она стоила около 1$, хотя был триал и бесплатная лайт-версия, но об этом я чуть позже расскажу на этапе «после публикации». Игра разрабатывалась с апреля по июнь 2013 года, в августе я производил всякие обновления, чинил баги и пытался хоть как-то распространить игру.

Под катом вы найдете рассказ по мотивам доклада, его видеозапись и слайды.

Подготовка

Стоит рассказать, почему я вообще начал это делать. В марте я купил телефон на базе Windows Phone и сразу заметил, что в маркете игр почти нет, особенно арканоидов, а это мой любимый жанр. И как программист я сразу решил исправить это. Некоторые арканоиды были, но по большей части они были портированы с Windows Mobile, и это было ужасно. У меня есть опыт разработки игр, это мое хобби с давних про, но публикации до этого еще не было. Я постоянно сам себе клепал мелкие игрушки и в них играл. Плюс у меня есть некоторый опыт, скажем так, промышленной разработки игр: в предыдущей фирме я два года разрабатывал игры для социальных сетей. Также мне еще была знакома среда разработки (Visual Studio), платформа .NET, язык C# и технология XNA.

XNA — это набор инструментов, который упрощает процесс разработки игр. Не готовый игровой движок, а именно удобный интерфейс для того, чтобы взаимодействовать с двухмерными спрайтами, трехмерными моделями, звуками и прочими элементами, которые могут понадобиться в играх. XNA последние несколько лет очень активно используется для разработки в основном для инди-игр в основном для платформ Windows и Xbox. Туда входит framework, который работает в связке с .NET и специальная версию редактора XNA Game Studio edition.

На XNA было создано множество игр. Например, Torchlight (обе части), Bastion, FEZ. Но так как это Microsoft, я очень быстро столкнулся с реальностью. Я узнал, что технологию XNA могут через некоторое время закрыть. Там была довольно мутная история. Официально XNA рекомендовался разрабатывать под платформу Windows Phone 7, а под платформу Windows Phone 8 появилось какое-то странное сообщение о том, что Microsoft не рекомендует использовать эту технологию, и что она будет работать в режиме совместимости для приложений под Windows Phone 7. Там похожая проблема была с технологией Silverlight, в какой-то момент ее отменили. Но, тем не менее, это мнение никак не помешало, потому что я очень быстро нашел проект нашел проект Mono Game. Это свободная реализация XNA, интерфейсно все выглядит точно так же, по сути я просто отключил от проекта библиотеки XNA и подключил проект Mono Game. Все сразу же заработало, никакой разницы нет. И Mono Game, в отличие от XNA, поддерживается большим количеством платформ (Windows, Linux, OS X, Android, iOS, QUYA, PlayStation). Эта технология потенциально позволяет мне без особых усилий выйти на другие мобильные рынки.

Разрабатывал я все в Visual Studio по сути под Windows Phone 7 в эмуляторе. Для разработки под Windows Phone 8 потребуется Windows 8 с Visual Studio 2012. В начале я пытался все это запустить в эмуляторе, но у меня это не заработало, потому что требовалась поддержка виртуализации. В некоторых случаях я шел по наиболее быстрому пути. И тут наиболее быстрым путем мне показалось поставить 90-дневную Windows 8 на ноутбук и дебажить приложение на моем телефоне. Так я и сделал, хотя потом все же купил полноценную Windows 8 Professional.

Теперь немного про сам магазин. Этап подготовки достаточно длительный. Прежде чем приступить непосредственно к разработке, я примерно 3 недели собирал данные по поводу того, что можно и нельзя сделать, и что в конечном итоге мне это может принести. Магазин Windows Phone так же как и App Store проверяет приложения перед публикацией, в отличие от Google Play. Приложений там было достаточно много, но большинство из них — просто треш, поделки на коленке. Годовая подписка разработчика на тогда стоила 99$ а сейчас стала 19$ в год. Проверяют обычно от 4 до 7 рабочих дней. В принципе, это не так много, особенно по сравнению с магазином приложений Apple. Мне не хотелось платить 99$ поэтому я стал искать лазейки как это можно совершить.

И я очень быстро нашел программу DreamSpark — это такой небольшой лайфхак. Программа от Microsoft, которая предоставляет студентам возможность публиковать приложения в различные магазины Microsoft. Эта программа действует год, как и сама подписка. Была одна тонкость в том, что я не студент, на тот момент я уже полтора года как получил диплом. Я снова начал искать лазейки и снова нашел.

Я все провернул через сайт Интуит — этот сайт каким-то образом получил возможность раздавать ключи. Чтобы получить ключ, достаточно было пройти несколько тестов, которые утвердили в Microsoft. Я там сдал основы HTML 5, пару тестов по C# и по базовому JavaScript. Я на этом сайте давно зарегистрирован, поэтому мне нужно было пройти всего лишь 3 теста, новому пользователю нужно пройти 6 или 8 тестов, и это до сих пор работает, они так же продолжают раздавать ключи.

Плюшки Dreamspark:

• возможность публиковать приложения (я этим воспользовался);


• бесплатное или со скидками ПО (мне это не пригодилось, т.к. я все разрабатывал в экспресс-версиях);


• и последнее, наверное, самое главное — возможность обновить Windows 8 до версии Pro за 2000 рублей вместо 9900.

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

Следующий этап — это разблокировка телефона. Это последнее препятствие перед самой разработкой. Делается это очень просто. После разблокировки телефона появляется возможность устанавливать .xap-файлы не из магазина приложений, а с SD-карточки. Этим пользуются пираты. На моей модели телефона HTC 8X не было слота для SD-карточки, поэтому я все проворачивал, подключая кабель к ноутбуку, и каждый раз собирал проект. Мне это не мешало.

Разработка

Наконец, мы подходим к самому веселому этапу — разработке. Делал я все с апреля по июнь, в основном в свободное время, в праздники, выходные и во время отпуска.

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

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

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

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

Архитектура игры

Игра в плане программного кода не очень большая. Я не использовал паттерн MVC. Вообще это самый популярный паттерн в играх, например, есть тысяча юнитов, которые выглядят по-разному, но ведут себя одинаково. У меня есть некая сущность, которая похожа на представление. Она описывает цвет элемента. Все элементы в игре обладают каким-то определенным цветом и простой геометрической формой. В общем-то, контроллер от модели у меня редко отличался в том плане, что у мячика есть определенный квадрат, который используется и для детектинга коллизий, и для отрисовки этого мячика на экране. Архитектурно XNA-игры выглядят примерно одинаково. Я говорю XNA, а не MonoGame, т.к. интерфейс и основные принципы были изначально заданы именно в ней. XNA сама предоставляет технологию «тика»: два метода Update и Draw в базовом классе. Первый метод отвечает за обновление данных по «тику», а второй — за отрисовку. XNA не предоставляет сущность «игровой элемент», а только инструменты для работы с графикой, звуком и текстом. У меня есть базовый элемент уровня, базовый элемент интерфейса, не все сделано хорошо, но, тем не менее, это работает. Не могу сказать, что во время разработки у меня возникали проблемы с негативными результатами из-за изначально неправильной архитектуры.

Есть один момент, который я хотел бы выделить. При разработке игр почему-то очень часто многие допускают такую простую ошибку: на каждый «тик» сдвигают игровые элементы на определенное расстояние. Например, Марио бежит к топору, чтобы разрубить мост и сбросить Боузера в лаву. В играх необходимо всегда не на какую-то константу сдвигать персонажей каждый «тик», а всегда задавать какую-то скорость умноженную на дельту между текущим и предыдущим тиком. Это нужно на случай, если вдруг на каких-либо устройствах ваша игра будет тормозить. В производительных играх это очень важно. Если у кого-то было 10 FPS, а у кого-то — 30, игроки увидят разный результат. Например, Марио не добежит до топора и не спасет принцессу.

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

Position.X += Direction.X * Speed;
Position.Y += Direction.Y * Speed;
…
double ballDirection = Math.Atan2(ball.Direction.Y, ball.Direction.X);
newBall.Direction.X = Math.Cos(ballDirection + Math.PI / 8);
newBall.Direction.Y = Math.Sin(ballDirection + Math.PI / 8);
newBall.Position.X = ball.Position.X;
newBall.Position.Y = ball.Position.Y;

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

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

Уровни я просто рисовал в редакторе, получались картинки 20 на 20 пикселей. Их я подключал к проекту и при первом создании уровня парсил изображение. Каждый цвет пикселя соответствует определенному типу блока, нужно было обработать всего лишь 400 пикселей. Это очень быстрая операция. Нельзя сказать, что в каком-то месте в плане производительности игра проседала в каком-то месте при обработке данных.

Еще в описание уровня включается XML-файл, который описывает всякие данные, которые не очень удобно обозначать графически: положение мячей на платформе от 0 до 1 и расположение бонусов в уровне. Бонусы бывают статические (всегда жестко привязаны к позиции в сетке) и динамические (случайно раскидываются по плиткам без бонусов при запуске уровня).

Цвета пикселей

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

Я это делал программно, в игре не использовалось спрайтов. Если быть точным, есть один спрайт размером 1 на 1 пиксель, который я программно растягивал до определенного размера и подкрашивал нужным мне цветом. Цвет получал при помощи достаточно простой функции. В примере ниже как раз проставлены значения именно для получения белого блока: от белого до серого.

r1 = g1 = b1 = 170;
r2 = g2 = b2 = 255;
…
public static Color GetColor(byte r1, byte r2, byte g1, byte g2, byte b1, byte b2)
{
    if (rand == null)
        rand = new Random((int)DateTime.Now.Ticks);
    float fRand = (float)rand.NextDouble();
    Color result = new Color();
    result.R = (byte)(r1 + ((r2 - r1) * fRand));
    result.G = (byte)(g1 + ((g2 - g1) * fRand));
    result.B = (byte)(b1 + ((b2 - b1) * fRand));
    return result;
}

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

При разработке мне нужно было поддерживать все разрешения экрана, которые на тот момент встречались на платформе Windows Phone:

• 800x480 (wvga);


• 1280x720 (720p);


• 1280x768 (wxga).
  
  Очевидно, что с таким набором разрешений мне также нужно было поддерживать два соотношения сторон. Все подходят к этой проблеме по-разному. Лично я скейлил картинку всю по ширине экрана. На картинке ниже видно, как снизу обрезалось изображение. У меня под платформой было достаточно большое пространство под палец, чтобы игрок, управляя платформой пальцем не перекрывал себе картинку. Я этим пространством немного пожертвовал, для того чтобы картинка хорошо выглядела и с шириной 720, и с шириной 768. Красной линией как раз показано то, что на левом экране платформа чуть ниже находится, чем на экране с другим соотношением сторон.

Пара слов о музыке и звуках. Музыки у меня в игре нет, потому что у меня руки не дошли ее сделать. Звуки в игре есть, они использовались с моей любимой приставки — SNES. Я нашел 256 семплов и их использовал.

Публикация

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

Форма аплоуда приложения состоит из четырех этапов. На первом нужно заполнить самые основные данные: категория, подкатегория, название в Dev Center и цена (я поставил 34 рубля). Тогда у меня еще не было триал-версии, так что я загружал только платную игру.

На втором этапе происходит непосредственно загрузка XAP-файла. У их было сразу два, так как я одновременно загружал версию на чистом XNA и для WP7. В этой форме также указывается, какие версии платформы и разрешения экрана поддерживает приложение. Большая часть информации, в том числе и язык приложения, берется из настроек проекта. Нужно было также ввести описание, ключевые слова, загрузить иконку (300x300), фон (1000x800) и скриншоты под все поддерживаемые разрешения экрана.

Третий этап — возрастные рейтинги. Я проставил себе только два CSRR (Тайвань) и PEGI. В первом было достаточно выбрать нужный пункт из выпадающего списка, поэтому я его и заполнил. А PEGI мне был необходим, так как этот рейтинг используется во многих европейских странах, в России и США, а именно на эти рынки я и был нацелен. Это также было несложно. На сайте PEGI нужно было заполнить буквально одну форму (наличие насилия, эротики, наркотиков, алкоголя и тому подобного).

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

Последний пункт — это получение ключа к сервисам карт от Nokia. Мне он не понадобился.

После публикации

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

Сразу после публикации дела шли не очень хорошо, игру никто не покупал. Я начал искать варианты для продвижения игры. Первым делом я сделал группу на facebook. Залайкали ее только мои друзья. Я также залил ролики на YouTube, это тоже не принесло особого успеха. Далее я написал об игре на пару тематических сайтов (http://wpcentral.com, http://4pda.ru), где отнеслись с большим одобрением к тому, что автор сам пришел порекламировать свою игру. Просмотров там было, много, а вот с покупками как-то не срослось. Весь август я правил баги и вносил исправления в игру. Кроме того, я сделал триал-версию с 2, а затем и с 5 бесплатными уровнями. Для название с Pixelnoid на Pixel Arkanoid (Pixelnoid). Также я заменил казавшуюся мне красивой иконку на чуть менее приятную, но более понятную. Это принесло мне на 3–4 установки в день больше, люди стали понимать, что это арканоид.

Чуть позже я еще сделал бесплатную лайт-версию: ту же игру, но с другим набором уровней (их там всего 15). Там я сделал специальную кнопочку “more levels”, которая открывает магазин приложений с предложением купить полную версию. Естественно, эта игра стала гораздо популярнее оригинальной версии.

Windows Phone Store для каждого региона свой, ниже приведены результаты по запросу [arkanoid] в России, США и Британии. Как видно, выборка получается немного разная, хотя Pixelnoid Lite встречается везде.

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

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

Но скачивания и покупки — разные вещи. Купили игру за месяц всего 6 раз, т.е. не окупилась даже покупка Windows 8 со скидкой.

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

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

Лично я считаю, что экосистема WinPhone все еще остается «сыроватой». Хотя с прошлого года ситуация заметно улучшилась. В магазине появилось множество приложений и игр как от крупных издателей, так и от инди-разработчиков. Входной порог, кажется, все еще остается ниже, чем на Android или iOS.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Настройка GUI в линуксе для мониторов с High DPI

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

Причина этого — система думает что у Вашего монитора разрешение 96..100 dpi.

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

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

Ниже будет идти список где что поправить, все параметры привожу для своего монитора — 13,3" при 2560x1600, это даёт 226 dpi. Более высокое разрешение сейчас я видел только в ноутбуке Fujistu U904 — 262 dpi.

Параметры монитора: в xorg.conf в праметрах монитора дописать:

Option «DPI» «226 x 226»

# DisplaySize 286 179 # тоже самое In millimeters, но это не так удобно

Если у Вас нет xorg.conf и монотор у Вас только 1, то можно задать это монитору по умолчанию. Для этого в каталоге конфига иксов создаётся файл xorg.conf.d/90-monitor.conf с таким содержимым:

Section "Monitor"
    Identifier     "<default monitor>"
    Option        "DPI" "226 x 226"
EndSection

В ключи запуска иксов надо дописать -dpi 226, в kdm это строка параметра ServerArgsLocal

Для шрифтов в /etc/X11/Xresourse или ~/.Xresourse:

Xft.dpi 96 заменить на 226

После перезапуска исков можно проверить что это вступило в силу:

— в логе иксов должны быть такие строки /var/log/Xorg.0.log

intel(0): clock: 268.5 MHz Image Size: 286 x 179 mm

intel(0): DPI set to (226, 226)

— xdpyinfo | grep -B2 resolution

screen #0:

dimensions: 2560x1600 pixels (287x179 millimeters)

resolution: 227x227 dots per inch

— xrdb -query | grep dpi

Xft.dpi: 226

Но есть куча программ и GUI которые не смотрят на параметры иксов. Поэтому продолжаем.

Для KDE: Параметры системы => Основные параметры внешнего вида => Шрифты => Использовать другой DPI: 226.

Но значки придётся увеличить отдельно: Параметры системы => Основные параметры внешнего вида => Значки, вкладка Дополнительно.

Для Gnome: в gconf прописать в /desktop/gnome/font_rendering/dpi (нужно ли тут ещё что-то дополнительно — я не знаю, т.к. не пользуюсь Гномом).

Для Firefox: в about:config: layout.css.PixelsPerPx=2.26, layout.css.dpi=226.

Но нередко для броузере не нужно 100% соответствие, поэтому я себе чтобы больше влазило на экран прописал layout.css.PixelsPerPx=2. Хотя firefox и даёт при этом самое точное соответсвие картинке при 100 dpi, но использует странное масштабирование растровых изображений. Сначала внутри получает изображение которое должно было бы быть при 100 dpi, а потом растягивает в 2 раза. Из-за этого картинки получаеются мыльными даже если они имеют высокое разрешение

Для Opera: достаточно установить 200% мастабирование — опера это делает достаточно корректно.

Для Chrome в chrome://flags/ есть параметр «Режим высокого разрешения», но для linux он не доступен. Поэтому остаётся только поставить 200% и «очень крупный» размер шрифта. К сожалению, это не влияет на flash.

Но я у себя поставил в нём 120% и использую для просмотра карт (maps.yandex.ru, maps.google.ru) для высокой детализации картинки.

Konqueror пока не понимает high dpi, и масштабирует неверно, хотя akregator, используя тот же движок, показывает всё правильно без дополнительных указаний.

Проверить что Ваш dpi понят системой корректно лучше всего открыв страницу формата A4 в офисной программе, например OpenOffice, и при 100% масштабировании приложив бумажный лист. Если всё работает правильно, то размеры совпадут.

Так же в OpenOffice в настройках стоит поставить размер значков «большие».

После всех настроек нашлись конфликты жёстко заданных растровых картинок и увеличившихся шрифтов.

Я такое увидел в kdm и в Opera: работать можно, но выглядит не очень приятно — края букв вылазят за отведённые для надписей поля. Поэтому я в xorg.conf.d/90-monitor.conf и в Xresourse заменил 226 на 175. (Вообще странно что opera, считывая размер dpi для меню и других надписей, не использует этот же dpi для отображения html страницы).

PS Собиралось это изначально только для себя тут http://ift.tt/1rEvqry, но оказалось что сейчас такой вопрос появляется у многих. Буду рад если появится какие-то конструктивные дополнения.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Переезд электронщика в Шэньчжэнь

Очередная история переезда на чужбину в нескольких частях.

Кратко о авторе.

30 лет. Специальность — радиофизик. Специализация — Компьютерная электроника. Основное направление — разработка электроники и встраиваемого программного обеспечения. Опыт работы — 10 лет. Опыт фриланса — 4 года.

Предпосылки переезда

Многолетний опыт постоянного трудоустройства сформировал мнение о бесперспективности работы на дядю. Твои разработки всегда будут принадлежать заказчику. Дивидендов с разработки в большинстве мест не получишь. Кто-то скажет — найди другое место работы с лучшими условиями. Тут сказывается географическое положение.

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

Ярким примером может служить доставка печатных плат. Например, из Новосибирска. В некоторых случаях доставка выполняется по воздуху, но через Москву. Иногда по земле — грузовым автотранспортом. В обоих случаях доставка занимает от недели. Получается абсурдная ситуация — экспресс производство печатных плат из недели растягивается до двух с учетом доставки.

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

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

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

Значит нужно переезжать. Осталось решить, как и куда. На постоянное место жительство с семьей или набегами то здесь, то там.

Переезд в Москву

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

Дальнейшая информация по ценам и срокам приводится для дальнейшего количественно-качественного сравнения стоимости и сроков реализации проекта в Москве и Шэньчжэне.

Первоочередные расходы — добраться до места. Билет Иркутск-Домодедово стоимость на момент написания статьи от 11500 рублей плюс аэроэкспресс 400. Далее аренда жилья. Варианты хостелов даже не рассматривались. Аренда квартиры рядом с метро 40000 рублей плюс залог в размере одного месяца и сопутствующие расходы.

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

Производство печатных плат — множество мест от двух дней для двухсторонней платы. Нам заказ двух плат первой версии обошелся в 8000 рублей. Комплектующие — типовые нашлись с прошлых проектов. Транзисторы, подходящие по параметрам, пришлось подбирать 2 дня. Купили втридорого в Чип-Дипе. Второй прототип печатной платы обошелся в 4500 рублей. Приятным бонусом стала вторая бесплатная плата. Чтобы уложиться в два дня пришлось съездить в Зеленоград.

Переезд в Шэньчжэнь

Разработка шла своим ходом и начался выбор контрактных производителей. Размещение заказа в Москве как оказалось делало проект нерентабельным, поэтому приняли решение о переезде в Китай.

Первым делом нужно оформить визы. В сети представлено большое количество специализированных фирм. Возможно оформление различных вариантов визы. Для продолжительной работы оптимальной видится оформление многоразовой визы M60 сроком на год с сроком пребывания до 60-ти дней. Стоимость от 12800 рублей, оформление от 5-ти дней.

Шэньчжэнь граничит с Гонконгом. Наиболее удобным видится перелет в Гонконг с последующим трансфером в Шэньчжэнь. Билет Москва-Гонконг от 9000 рублей. Трансфер — микроавтобусы по 150 юаней до Shenzhen Bay. Далее общественный транспорт или такси. Все дальнейшие цены в юанях.

По прибытию в Китай задача номер один местная сим-карта с 3G/LTE и безлимитным интернетом. Я купил China Unicom с тарифом 76 юаней в месяц — 300 минут местных разговоров и 800Мб интернета. China Telecom под 3G понимает CDMA, соответственно такой вариант не годится. Как я понял в Китае всего два сотовых оператора с нормальным 3G. Далее в bing.com ищем baidu navigator и устанавливаем.

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

Отдельное слово про метро. Тихо, прохладно, работает связь.

Во всем общественном транспорте объявления остановок, схемы и надписи дублируются на английском.

Гостиницу стоит заказать на неделю заранее, например на booking.com. Лучше на неделю или две. Этого времени достаточно чтобы найти квартиру или другую гостиницу. Стоимость гостиницы от 100 юаней в хорошем месте. Некоторые месяцами живут в гостинице в downtown'е по 3500 юаней в месяц. Если снимать квартиру доступны варианты от 1000 юаней за 1 bed room в Bao'an рядом с фабриками до 4200 юаней в Shekou с видом на море. Соответственно больше квартиры дороже. Везде контракты на год и залог на два месяца.

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

Первым делом стоит определиться с местом аренды. Наш вариант — Bao'an — множество фабрик на которых можно организовать полный цикл производства. Далее просто идем в приглянувшийся дом, ищем домоуправление или местных риелторов и договариваемся. Во многих домоуправлениях есть собственные квартиры, которые вам тут же покажут.

Примерный вид с крыши в Bao'an. Фабрики да общаги… Исключительный день — весь смог раздуло, в обычные дни гор на горизонте не видно совсем.

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

Если цель много работать и ездить по фабрикам стоит приобрести мопед. Очень удобно локально ездить по фабрикам размещать и контролировать заказы. Запас хода у электрического мопеда 75км. На скоростные дороги выезжать нельзя, поэтому если ехать далеко — такси или общественный транспорт. Следующим этапом будет аренда или покупка автомобиля. Чтобы поставить машину на номера нужна постоянная виза. Для получения местных прав нужно иметь виз с сроком пребывания от 3 месяцев. Иначе нужно делать нотариально заверенный перевод и каждый месяц делать временные права в полиции.

Как только решен жилищный вопрос можно переходить к работе.

Заказ прототипа печатной платы обходится в 800 юаней за 5 штук. Трафарет в рамке для нанесения паяльной пасты стоит 200 юаней. Все детали в наличии в любом количестве можно приобрести в Segbuy на Huaqiang Rd. Цены на компоненты оптовые московские, но в розницу. Там же можно приобрести любой инструмент — осциллограф, паяльник, мультиметр и прочее. На минимальное обустройство потратили 2500 юаней.

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

Промежуточный итог

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

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

Спасибо за потраченное время!

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Школьная пора в Академгородке — впечатления

В Новосибирске ежегодно проходит довольно интересное мероприятие — Летняя Школа Академпарка (ЛША). Есть еще Зимняя, но на Зимней мы не были. Собственно, хотим поделиться опытом.

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

На деле это отличная возможность:

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


2. Получить очень много фидбэка различных уровней — от директоров крупных предприятий и фондов до… людей, которых представляют экспертами;


3. Найти ментора для своего бизнеса;


4. Найти клиентов для своего бизнеса;


5. Найти инвесторов для своего бизнеса;


6. Найти исполнителей для своего бизнеса;


7. Сделать бизнес;


8. Попасть во ФРИИ;


9. И многое другое.

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

Но это мы поняли не сразу.

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

Наш проект — mDiagnostics и мы делаем кое-что интересное в сфере мобильных приложений, о чем расскажем позже.

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

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

Ставшее стандартным, селфи проекта.

Официальная часть вступления закончилась инновационным школьным звонком на планшете и нас всех отпустили по секциям.

Как выяснилось, собеседование у нас вела Юля Титова, ведущая IT-секции. После вступительной части, она провела нам большую экскурсию по всем башням — признаться честно, работать там очень круто. Есть переговорки с удобными диванами, клево организованные рабочие места, красивый вид из окон. После прохождения ЛША, если ваш проект оказывается годным, вам бесплатно дают здесь резиденство. И эта информация серьезно ободрила многих.

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

И вот мы в лекционной на первом занятии. Что происходило у приборостроения и медицины мы не знаем, а вот нашу IT-секцию открывал человек-«вы все говно!» Глеб Тертычный. Вообще, это один из самых полезнейших и ценнейших экспертов, представленных в ЛША — если после его комментариев вы еще будете уверенны в своем проекте, то вы делаете что-то стоящее. Более-менее. На самом деле, Глеб серьезно помогает стартапам — он всегда открыт для связи и фидбэка, учит правильным и понятным вещам, а также представляет собой квазистенцию «саркастического» эксперта. Эдакий доктор Быков Летней Школы.

В целом, нам сказали, что суть нашего пребывания в летней школе — сформировать MVP до полуфинала —«минимальный продукт» — когда готов прототип, команда, есть первые продажи и подробным образом изучен рынок. Еще одна цель нашего пребывания — это пройти преакселератор ФРИИ, большое количество экспертов от которого выступали на ЛША. Собственно, как и сам Глеб.

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

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

Здесь же мы познакомились с Григорием Шином, представителем Radiance Production который серьезно помог нам с дизайном нашего проекта и вообще общей поддержкой. К слову, всем, кто заинтересован в 3D-2D-анимации, советуем посетить их сайт — достаточно крутые ребята.

И понеслось. «Интенсив» (как назвали лекционную часть до полуфинала) был реально интенсивным. За это время мы переобщались с большим количеством экспертов, два раза изменили концепцию своего продукта, придумали интересные фичи, познакомились с будущими инвесторами и партнерами. Узнали очень многое об очень многом. В частности, про знаменитые метрики.

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

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

В целом, в финал мы прошли. Сейчас идет «подготовительная работа» к финалу, где оценивают вообще все проекты по всем секциям, которые прошли в полуфинал.

Нам… Понравилось. Это было полезно и интересно, дало большие возможности и резкий скачек в развитии.

Фотографии для статьи мы украли с официального сайта ЛША, там же можно почитать информацию о проекте в целом. А мы пока готовимся к большому-большому финалу.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.