Парсер Хабра: 2013-08-18

суббота, 24 августа 2013 г.

Переезд на работу в Данию

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

О себе: мне 31 год, я из Севастополя (да, на Хабре земляков всё больше), окончил СевНТУ. У меня красавица-жена и семилетний сын. До переезда в Данию мы 6 лет жили в Киеве.

Причины переезда

Мы не "поравалитики". В целом, нам отлично жилось вна Украине. Конечно, мы понимали, что кругом многим не сладко. Так или иначе, сбежать из страны, прихватив трактор, не тянуло.

Вся идея изначально исходила от жены, её доводы были таковы:

посмотреть мир,

дать сыну возможность выучиться в мультиязычной среде.

Доводы хорошие, но меня убедили совсем другие вещи:

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

переломным моментом стало прочтение статьи о Куренёвской трагедии: в 1961 году в Киеве прорвало дамбу завода, и ранним мартовским утром 14-метровая волна грязи и песка залила целый район Киева и похоронила тысячи людей (она долго оставалась засекреченной — письма люстрировались, советские самолёты облетали место трагедии, и так далее). Я подумал, что потом вот случился Чернобыль, а теперь на носу повсеместно предсказываемый прорыв дамбы Киевского моря, уже очень дряхлой (тут подробнее на эту тему). Причинами всех этих техногенных катастроф, я считаю, является плохой менеджмент, а поскольку проблесков в этом вопросе у нас пока не видно, я решил хотя бы несколько лет переждать ситуацию где-то подальше. Можете считать меня параноиком, и слава богу, что я оказался не прав в этом году, но так ли уж не прав?

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

В какой-то момент у меня даже был выбор между Данией и Англией, но, во-первых, Дания показалась мне какой-то более активной, технологичной. Во-вторых, датская виза позволяла свободно путешествовать по всей Европе, а английская — только по Объединённому Королевству.

Визовые вопросы

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

Предложение было таково:

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

компания оплачивала весь процесс оформления визы, включая меня и жену с сыном,

так же оплачивали перелёт и перевоз вещей,

разумеется, жильё я должен был оплачивать сам, но обещали помочь в поиске жилья (тут это проблема, тоже ниже)

Шеф прислал мне предзаполенную форму; я вписал в неё свои данные, доложил сверху ещё макулатуры и сдал в визовый центр. Временную визу на 90 дней дали через 3 недели. По деньгам вышло 315 грн ($40) визовому центру и 2112 грн ($260) датскому консульству с каждого человека.

Лёгкость получения визы была связана с тем, что программисты входят в так называемый white list — список профессий, представители которых приветствуются в этой стране. Помимо инженеров, туда входят врачи и учителя. "Наша праця прекрасна, і она нужна людям". Чтобы попасть в white list, нужно приложить диплом по профессии (минимум 3 года обучения) — это был первый раз в жизни, когда мне реально пригодилась «корочка».

Помимо этого, получить визу и вид на жительство проще тем, у кого высокий уровень зарплаты. Справка: зарплата выше 31200 крон считается высокой, а минимальная зарплата веб-разработчиков как раз чуть-чуть выше этой цифры.

Жена и сын подавались на визу, когда я уже был в Дании, и вот тут началась неразбериха. Их документы постоянно терялись. Жена с одной стороны звонила в украинское посольство (те уже выучили наизусть нашу фамилию и узнавали жену по голосу), я со своей стороны дёргал датчан. Посольства обмениваются визовыми документами по емейлу, и отправить и получить сразу 2 файла (пакеты документов на жену и сына) у них вышло только с третьего раза, и каждый раз после очередной попытки нужно было ждать пару недель. Этот процесс занял 4 месяца с постоянными звонками от нас.

Как я уже сказал, даётся временная виза на 90 дней — просто штамп в загранпаспорте. Помимо этого, мне выдали документ, где был указан мой код налогоплательщика — всесильный ID в Дании, как оказалось.

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

Зарплата, налоги

Финстрип делать не буду, но вы можете узнать среднюю зарплату по профессии на JobIndex: введите в строке поиска «webudvikler» («веб-разработчик») и вы увидете такую картину. Можно попробовать настраивать возраст, опыт и дислокацию — всё, как на ДОУ.

Иллюстрация 1 — средние зарплаты веб-разработчиков в Дании

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

Перевоз вещей

Пока я был в Дании, мои домочадцы погрузили наши пожитки (вещи, книги — разумеется, никакой мебели) в десяток картонных коробок, переправили «Новой почтой» из Киева в Севастополь, а там компанией TNT всё это через Германию уехало в Копенгаген.

По деньгам Севастополь-Копенгаген вышло где-то €320.

Шло около недели. Мне позвонили из курьерской службы, и мы договорились, когда я буду дома. Когда я пришёл с работы, у подъезда уже стоял большой деревянный поддон, а на нём наши коробки, крепко замотанные плёнкой. Удивительно, но всё было на месте — такие порядки. За полчаса я перетаскал вещи в квартиру.

Жильё

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

В Дании всё наоборот: квартиры улетают за час, и на них реально очередь. Выглядит это так: есть специальные сайты недвижимости, где владельцы размещают объявления о жилье (предполагаю, что бесплатно). Желающие оставляют заявку на сайте. Через какое-то время мы поняли, что владельцы нас тупо игнорируют и не перезванивают. Тогда мы купили платную подписку (что-то порядка $20 за квартал), и нам стал виден прямой телефонный номер владельца, и я стал звонить. На том конце провода меня обычно ждала голосовая почта, и я выдавал уже заученный текст, составленный с помощью коллег: мне рекомендовали упомянуть, откуда я и какой у меня состав семьи, а также что у меня есть работа в Копенгагене. Одни говорили, что иностранцам сдают охотнее, другие наоборот. Так или иначе, квартиру я начал искать в июле, а въехали мы в ноябре (семья в это время получала визу в Украине).

При этом совсем не важно, далеко ли от центра квартира, до метро 5 минут или 15. Связано это на мой взгляд с тем, что здесь богатство распределено равномерно. Как сказал мой друг Сергей Комар, «выезжаешь за Копенгаген — и везде у них маленький Копенгаген». Везде есть вело-дорожки, парки, скамейки; чисто. Единственное, что, на мой взгляд, может сильно влияет на цену, это вид на море. Что ещё интересно, фашисты не бомбили Данию, поэтому новостройки котируются наравне с домами конца XIX века.

На первые 2 месяца моя компания подыскала мне квартиру, потом я жил в DanHostel в комнате с 5-7 туристами и туристками, сменявшимися каждый день. В Европе в июне-июле — пора путешествий выпускников, так что было весело. За 3 недели ничего у меня не пропало, хотя я уходил гулять каждый вечер и оставлял MacBook под подушкой. Один раз рядом с книгой Аксёнова меня ждала записка: "Кто ты, русский? Ты приходишь, когда мы уже спим, и уходишь, пока мы ещё спим". Это было мило.

Хостел в центре города обходился 150 крон в сутки ($30) в комнате на 8 человек, 170 крон в комнате на шестерых. В любом случае это не так страшно, как кажется — кровати двухярусные, ощущения конюшни нет, наоборот, у всех отпускное настроение. В хостеле есть кухня, wifi, стиралка. За месяц выходило чуть больше 5000 крон ($1000) — при вселении приходится покупать годовую карточку их сети и комплект постельного белья. Очень рекомендую, DanHostel — один из лучших; требуйте угловой номер на 11-14 этажах, не пожалеете. Он очень в центре города.

Иллюстрация 2 — вид из окна DanHostel на центр Копенгагена.

Ещё я снимал отдельную комнату в Фредериксберге (неплохой район) за 5500 ($1100). Все варианты квартир, которые мы смотрели, были около 8000 крон ($1380) — но это были или небольшие двушки, или далеко, или совсем не феншуй. Свежеотремонтированную квартиру размером с нашу трёшку в Амагере (хороший прибрежный район) мы сняли не торгуясь за 10 000 крон ($1700). Амагер (по-датски просто «Ама») всегда привлекал меня близостью моря и современной датской архитектурой, так что, хоть и дороговато, но нам нравится.

Иллюстрация 3 — район Amager: пляж Amager Strand с видом на ветряки

Иллюстрация 4 — район Amager: знаменитое студенческое общежитие университета ITU (элитное даже для местных)

Иллюстрация 5 — район Amager: то же общежитие, вид изнутри

Интернет

Заявку на подключение к провайдеру Fullrate мы подали перед Новым годом, а подключили нас уже в середине января. Ежемесячная плата составляет 199 крон ($34). Ещё с нас единоразово списали 99 грн за какое-то оборудование, 299 крон за подключение, зато wifi-роутер был гордо заявлен бесплатным.

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

Школа

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

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

Подготовительных школ в городе — одна или две. Чтобы решить для нас, родителей, вопрос логистики и безопасности детей, детей из дому в школу возят на такси. Это очень, ну очень дорогое удовольствие оплачивает коммуна — районное управление, смесь райкома с ЖЭКом, только адекватное. Выглядит это так: каждое утро ровно в 7:27 к нашему дому подъезжает стандартного вида местное такси — новый мерседес с водителем-индусом, за год такси не опаздало ни разу. В 8 часов сын в школе, в час дня учителя рассаживают их по машинам. Привезя ребёнка домой, таксист ждёт, пока мы покажемся с балкона и помашем ему рукой, мол, мы дома, всё окей.

В классе у сына 6 человек: помимо моего русака — японка Санксан, индус Обищак, негр-сомалиец Обилахе, поляк Демиен и араб Мохамед. Учительница — турчанка, в платке, английского не знает, только турецкий и датский; она вежливая, но строгая, сыну она очень нравится.

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

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

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

Выплаты на ребёнка

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

Цифры на 2013 год таковы:

0-2-летний ребёнок: 4299 датских крон за квартал

3-6 лет: 3402 крон за квартал

7-14 лет: 2679 крон за квартал

15-17 лет: 893 крон в месяц.

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

от 6 месяцев — вам платят 25% от этой суммы,

через 1 год — 50%,

через 1.5 года — 75%,

через 2 года — 100%.

Это называется принципом начислений, который относится и к иностранцам, работающим в Дании.

Медицина

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

В Дании 2 слоя медицинского обслуживания: назовём их Передний Фронт и Настоящая Медицина соответственно.

Передний Фронт — это врач, к которому вы идёте с любыми вопросами: болит, чешется, беспокоит. Эти терапевты — очень спокойные люди, и основной ответ: «Само пройдёт». Ну могут порекомендовать больше пить чаю (при этом датчане смотрят на тебя во все глаза, если ты кладёшь в чай малиновый джем). Серьёзно, складывается ощущение, что задача Переднего Фронта — не допустить вас к Настоящей Медицине; похоже, так экономят деньги налогоплательщиков. При этом их компетенция оставляет желать лучшего — у кого-то врач, делая укол, чихнула в ладонь, не помыла руки и не протёрла место укола спиртом, у кого-то врачи лечили аллергическую сыпь как простые прыщи, у кого-то ребёнок проболел простудой 4 недели (они ходили к 3 врачам, послушали «само пройдёт» и кажется нашли русского специалиста).

Иллюстрация 6 — Передний Фронт. Приёмная.

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

Иллюстрация 7 — медкарта

Зато Настоящая Медицина — это белые халаты и новейшая аппаратура.

Интересный момент. На регистратуре вам говорят, как пройти к нужному кабинету так: «Следуйте по зелёной линии на полу» — от стойки расходятся 5-6 разноцветных линий. На этаже — автомат с бесплатным кофе, картины.

Иллюстрация 8 — клиника

Датчане — закалённый народ. Они ходят в футболках тогда, когда мы ходим свитерах с горлом. Я слышал про детские садики, где дети в любую погоду круглый год спят в тихий час на свежем воздухе — конечно, закутанные и под навесом, но всё равно круто.

Не подумайте, что упоминаю вскользь — работа

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

Работают в основном с 9 до 17, после 17 народ активно расходится по домам. Перерыв на обед полчаса. Распространена доставка обедов в офис: 50% оплачивает сам сотрудник, остальное — компания.

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

Датчане — в чём-то националисты, и они твёрдо верят, что датские разработчики лучше всех. Я считаю, что вопрос национальности мало влияет на профессиональные навыки.

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

Счастье на работе

Интересно, как слова в определённом языке передают духовные ценности его носителей.

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

В Дании не так. На работе должно быть хорошо и приятно работать. Это они называют специальным словом «arbejdsglæde» («арбайдэ», как известно, «работа», а «glæde» — калька английского слова «glad», радость то бишь). В отличие от греков, которых удовольствие привело к экономическим проблемам, варяги используют эндорфины для увеличения продуктивности работы.

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

Чтобы иностранцы могли проникнуться духом этой идеи, был создан специальный сайт What the heck is arbejdsglaede!?. Посмотрите, там минималистическое видео о том, что это такое и как это достигается.

В качестве итога скажу: за границей, конечно, хорошо, но как только мой проект в Дании придёт к логическому завершению, я планирую всей семьёй вернуться жить домой на украинские просторы — у нас лучше. Почему? Читайте в следующей статье «Дания. Сравнительная характеристика».

Сссылки на закуску:

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 fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html

Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю №71 (18 — 24 августа 2013)

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

Пометьте топик понятными вам метками, если хотите

Метки лучше разделять запятой. Например: общение, социальные сети, myspace.com, подростки, мердок

или закрыть

Написание своего Web-приложения на Go

Когда я задумался о написании Web приложения с использованием Go, я преследовал лишь желание попробовать нечто новое для себя. В последствии я понял, что Web оболочку можно использовать как кросплатформенную GUI библиотеку, чем и воспользовался в своем проекте[1].

Вступление

Отличием данного урока от остальных то, что я буду рассматривать только стандартные пакеты Go. Для моей задачи этого было более чем достаточно, да и разбираться в каких-то фреймворках (к примеру Revel[2]) у меня не было желания. Так-же я затрону тему запросов. Опять-же, четкого примера по загрузке файла на сервер в интернете, на данный момент, нет. Поэтому я решил написать статью, которая позволит создать скелет, для дальнейшей разработки.

В программе я не буду обрабатывать ошибки, по причине уменьшения объема кода. Так-же я не буду описывать тривиальные вещи, вроде очевидных аргументов функций (узнать подробности можно в официальной документации[3][4]). Некоторые моменты, для ясности, могут быть описаны не строго формальным языком, или не совсем верно.

Начало

Начнем с простой программы «Hello World». Для этого нам нужно описать функцию обработчик (handler):


func index(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-type", "text/plain")
        w.Write([]byte("Hello World!!!"))
}

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

Дальше нам нужно уже «привязать» данный обработчик к паттерну:


func main() {
        http.HandleFunc("/", index)

        http.ListenAndServe(":80", nil)
}

С помощью HandleFunc мы привязываем функцию обработчик к паттерну, а c с помощью ListenAndServe уже непосредственно запускаем сервер. Паттерн может быть любым: «/», «/page0», «/page0/page01». Но все что после паттерна, будет относится к нему. К примеру у нас зарегистрированы два паттерна: «/» и «/page0». Если в адресной строке написать «/page», то обращение будет к «/», а если «/page0/page», то к «/page0». Полностью код выглядит так:


package main

import (
        "net/http"
)

func index(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-type", "text/plain")
        w.Write([]byte("Hello World!!!"))
}

func main() {
        http.HandleFunc("/", index)

        http.ListenAndServe(":80", nil)
}

Компилируем, запускаем (или сразу запускаем), в браузере переходим по адресу где запущен сервер (на локальной машине это localhost – 127.0.0.1) и видим нашу строку.

Используем шаблоны

«Вшитый» html-код в программу выглядит крайне уродливо и крайней неудобен для редактирования (особенно в больших проектах):


fmt.Fprintf(w, "<h1>Editing %s</h1>"+
        "<form action=\"/save/%s\" method=\"POST\">"+
        "<textarea name=\"body\">%s</textarea><br>"+
        "<input type=\"submit\" value=\"Save\">"+
        "</form>",
        p.Title, p.Title, p.Body)

Поэтому мы воспользуемся пакетом template, для улучшения читаемости и простоты редактирования. Для начала напишем «костяк» нашей страницы (я буду ориентируясь на стандарт HTML5):


<!DOCTYPE html>

<html>
        <head>
                <meta charset="utf-8">
                <title>{{.Title}}</title>
        </head>
        <body>
                <p>{{.Msg}}</p>
        </body>
</html>

Title и Msg в последствии превратятся в текст, но об этом чуть позже. Для начала нам нужно описать структуру данных, которую мы потом передадим функции:


type page struct {
        Title string    //имена переменных должны совпадать с тем, что мы написали выше!
        Msg string              //и переменные обязательно должны быть глобальными!
}

Теперь напишем функцию обработчик:


func index(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-type", "text/html")

        t, _ := template.ParseFiles(“index.html”)
        t.Execute(w, &page{Title: "Just page", Msg: "Hello World"})
}

ParseFiles – загружает указанный файл (или файлы), Execute обрабатывает шаблон, подставляя данные, и пишет их в w.

Обработка событий

Осталось последнее, это сделать страницу с какой-нибудь кнопкой, загрузкой файла и т.п. В примере, сервер примет файл с изображением, конвертирует его в JPEG с качеством 0 (так будет ясно видно что все работает), и вернет обратно.

Изменим наш html-шаблон, добавив в него форму с методом POST:


<form target="_blank" action="/exec/" enctype="multipart/form-data" method="post">
        <input type="file" name="imgfile" />
        <input type="submit" name="button" value="Execute" />
</form>

Напишем функцию обработчик:


func index(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-type", "text/html")

        title := r.URL.Path[len("/"):]

        if title != "exec/" {
                t, _ := template.ParseFiles("index.html")
                t.Execute(w, &page{Title: "Convert Image"})
        } else {
                imgfile, fhead, _ := r.FormFile("imgfile")

                img, ext, _ := image.Decode(imgfile)

                w.Header().Set("Content-type", "image/jpeg")
                w.Header().Set("Content-Disposition", "filename=\"" + fhead.Filename + "." + ext + "\"")
                jpeg.Encode(w, img, &jpeg.Options{0})
        }
}

В переменной title будет то, что находится после паттерна. К примеру если адрес «http://localhost/qwe/», то в title будет «qwe/». Дальше мы смотрим, если мы не на «exec/», то загружаем, обрабатываем и выводим обычную страницу, если же мы на «exec/», то обрабатываем входной файл. FormFile — возвращает файл с указанным ключом (если таких форм несколько, то первый из них) и немного информации о файле. Мы устанавливаем тип контента (как «image/jpeg»), имя файла (сервер пошлет ответ браузеру с этим именем) и записываем изображение.

И еще один момент, если вы в своем шаблоне используете какой-нибудь локальный файл (например файл с изображением), то вам придется написать обработчик или использовать FileServer из пакета http. В первом случае у вас будет нечто подобное:


func logo(w http.ResponseWriter, r *http.Request) {
        file, _ := ioutil.ReadFile("img/logo.png")
        w.Write(file)
}

<...>
        http.HandleFunc("/img/logo.png", logo)
<...>

А во втором все проще, т.к. не потребуется описывать каждый отдельный файл:


<...>
        http.Handle("/img/", http.FileServer(http.Dir("img")))
<...>

Заключение

Таким образом, я показал насколько просто и понятно на Go можно написать свое Web-приложение. Преимущества Go, это простота самого языка, простота пакетов для работы с http-протоколом, возможности использования шаблонов, а так-же независимость кода, написанного на чистом Go, от архитектуры и операционной системы. Go, на данный момент, поддерживает: FreeBSD (x86, amd64, arm), NetBSD(x86, amd64), GNU/Linux (x86, amd64, arm), MacOS X (x86, amd64), Windows (x86, amd64).

[1] mapitemeditor.sourceforge.net/

[2] habrahabr.ru/post/162115/

[3] golang.org/doc/

[4] golang.org/pkg/

РосВыборы Опасносте

сегодня в 20:05

Здравствуйте, господа инженеры.

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

Составить представление о системе с точки зрения разработчика можно прочитав публично доступные сценарии использования. Проект реализуется на ruby on rails, на момент написания поста готова и переведна в продуктив примерно половина сценариев.

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

Коллеги, нам срочно нужны инженеры, профессионально разрабатывающие на ruby on rails, и готовые ближайшую неделю полностью посвятить себя этому проекту. Фактический заказчик проекта — гражданское общество, каждый из нас, из тех, кто понимает необходимость в результатах выборов, в точности соответствующих галочкам, поставленным избирателями в бюллетенях. Это не самый богатый на свете заказчик, поэтому мотивация «за деньги» здесь не сработает, сработает только желание сделать всё возможное для достижения означенной цели.

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

Developers, stick with Russians – work in London

Переводы с

карты на карту

Переводы

через QR-Код

Новая функция

«Мой контроль»

Возьми Lumia 925 на тест-драйв сейчас.

Впечатляющие возможности

в стильном тонком корпусе из металла

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

«Россия-1» обнаружила дефицит айфонов в Москве

Вы пытаетесь открыть публикацию, написанную пользователем sultee, однако статья скрыта в черновики (самим автором или НЛО).

Особенности парсинга блочного HTML-кода программами экранного доступа

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

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

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

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

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

Фактически речь идёт о том, что пользователю предоставляется возможность последовательно читать содержимое страницы.

Проблема кроется именно в «последовательности», так как она субъективна. Современный web-дизайн отошёл от структурирования информации подобно обычному тексту. Используется структурирование в две колонки, три колонки и прочее.

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

Для примера рассмотрим следующую страницу:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
        <head>
                <title>Заголовок страницы</title>
                        <style type="text/css">
                                .header, .sidebar, .content, .footer {
                                padding: 10px;
                                border: solid 1px #000000;
                                background: #FFFFFF;
                        }
                        .header, .footer {
                                font-size: 24px;
                        }
                        .layout {
                                margin: 15px 0;
                                overflow: hidden;
                                min-width: 800px;
                                max-width: 1200px;
                        }
                        .sidebar {
                                width: 100px;
                                float: left;
                        }
                        .content {
                                margin-left: 135px;
                        }
                </style>
        </head>
        <body>
                <div class="header">Верхний колонтитул</div>
                <div class="layout">
                        <div class="sidebar">
                                <h2>Меню</h2>
                                <ul>
                                        <li><a href="link1.htm">Ссылка 1</a></li>
                                        <li><a href="link2.htm">Ссылка 2</a></li>
                                        <li><a href="link3.htm">Ссылка 3</a></li>
                                </ul>
                        </div>
                        <div class="content">
                                <h1>Заголовок страницы</h1>
                                <p>Абзац 1.</p>
                                <p>Абзац 2.</p>
                                <p>Абзац 3</p>
                        </div>
                </div>
                <div class="footer">Нижний колонтитул</div>
        </body>
</html>

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

Далее можно проделать небольшой эксперимент, переставив местами блоки боковой панели и основного содержимого:


                <div class="layout">
                        <div class="content">
                                <h1>Заголовок страницы</h1>
                                <p>Абзац 1.</p>
                                <p>Абзац 2.</p>
                                <p>Абзац 3</p>
                        </div>
                        <div class="sidebar">
                                <h2>Меню</h2>
                                <ul>
                                        <li><a href="link1.htm">Ссылка 1</a></li>
                                        <li><a href="link2.htm">Ссылка 2</a></li>
                                        <li><a href="link3.htm">Ссылка 3</a></li>
                                </ul>
                        </div>
                </div>

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

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

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

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

[Перевод] Правительство Германии предостерегает ведомства страны от использования Windows 8

Если верить «утечке» документов из германской Федерального Ведомства по Информационной Безопасности (BSI), опубликованных Die Zeit, IT-эксперты считают, что Windows 8 — новая, заточенная под тач-скрин, супер-пуперская, но слабо продающаяся ОС от Microsoft — несет в себе серьезную угрозу для безопасности данных. Она позволяет Microsoft удаленно взаимодействовать с компьютером через встроенный бекдор. Ключи от этого бекдора, по всей вероятности, есть у NSA, а также — что довольно иронично — и у китайцев.

Бекдор называется "Trusted Computing" — это технология, разработанная и продвигаемая альянсом Trusted Computing Group, основанным десять лет назад исключительно американскими компаниями AMD, Cisco, HP, IBM, Intel, Microsoft и Wave Systems. Его ключевые элементы — чип (Trusted Platform Module, TPM), и операционная система, разработанная с учетом возможности взаимодействия с данным чипом, такая как Windows 8. В Trusted Computing Group разработали спецификации взаимодействия чипа и ОС.

Целью (официально декларируемой) этого механизма является поддержка DRM (управление правами на цифровой контент) и защита компьютеров. Система определяет, какой контент или софт получен легально и получит право на воспроизведение (выполнение) на данном компьютере, а какой (например, нелегальный контент или вирусы) должен быть заблокирован. Весь процесс будет координироваться Windows (а через удаленный доступ — Microsoft).

Недавно опубликованная новая версия спецификации TPM: TPM 2.0. В то время как TPM позволял пользователям компьютеров решать, включать или не включать его использование, TPM 2.0 включается по умолчанию в момент запуска ПК и не может быть выключен пользователем. Microsoft решает, какие программы могут запускаться на ПК, и пользователь компьютера не может никак повлиять на эти решения. При этом, пользователь не имеет никакой информации об активности Microsoft на его ПК. В сущности, пользователи Windows 8 теряют контроль за своим ПК в момент первого включения.

Для Microsoft или производителей чипов не представляет никаких проблем передать ключи доступа к бекдору в NSA и тем самым позволить агентству [тоже] управлять пользовательскими системами. НЕТ, Microsoft никогда так не поступит !! — протестуем мы. Увы, как мы могли понять из недавного потока разоблачений, Microsoft информирует правительство США об обнаруженных уязвимостях в своих продуктах задолго до того, как будут выпущены «заплаты», так чтобы правительство могло успеть воспользоваться этими сведениями и выяснить все, что ему необходимо.

Эксперты в BSI, Министерстве Экономики и Федеральной Администрации, единогласно предостерегают от использования компьютеров с Windows 8 и поддержкой TPM 2.0. Один из документов, датированных началом 2012-го года, утверждает: «Из-за потери суверенитета в области информационных технологий, достижение целей „конфиденциальности“ и „целостности“ более не может быть уверенно обеспечено». Помимо прочего, документ констатирует: «Это может иметь серъезные последствия в области безопасности IT Федеральной Администрации». И, как резюме: «Использование [технологии] Trusted Computing в этой форме… неприемлемо для Федеральной Администрации и для операторов критически важной инфраструктуры».

Другой документ утверждает, что Windows 8 в сочетании с TPM 2.0 «уже… не применимо». Однако, «Windows 7 может безопасно использоваться вплоть до 2020-го года». К этому сроку необходимо найти приемлемое решение для ИТ-систем Администрации.

Из документов также следует, что германское правительство пыталось повлиять на содержание спецификаций TPM 2.0 — общепринятая практика для процессов, которые длятся годами — однако было проигнорировано ключевыми участниками. Другие же добились того, чего хотели, как пишет Die Zeit. Например, NSA. На одной из последних встреч TCG и других заинтересованных лиц, кое-кто проговорился: «в NSA согласны».

Рюдигер Вайс, профессор Университета Технологии им. Бойта (Берлин), и в то же время — эксперт в области криптографии, имеющий многолетний опыт в работе с технологией TPM, рассказал в интервью Die Zeit, что Microsoft пытается «полностью изменить сущность ИТ за счет внедрения специальных чипов слежения в каждое устройство». С помощью такого чипа и компонентов Windows 8, в частности, Secure Boot, «пользователи, по большому счету, теряют контроль за собственным аппаратным и программным обеспечением».

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

И что еще более зловеще, добавляет он: «Еще одним фактором, добавляющим проблем пользователем, является то, что производители чипов находятся в Китае».

Apple вышел из проекта TPM в 2009-м году. Linux не соответствует стандартам, и ПК с Linux не могут использовать эту технологию. Microsoft же приводит все мыслимые аргументы в свою защиту. «TPM активируется по умолчанию», говорят они, «потому что большинство пользователей принимают все настройки „по умолчанию“. Если бы пользователям пришлось активировать функцию в ручную, подавляющая их часть осталась бы с менее защищенной системой». И, естественно, правительственные распоряжения, требующие, чтобы у пользователей была возможность отключить данную технологию, Microsoft находит «не вполне правильными».

Вместо этого, говорит Microsoft, производители железа могли бы поставлять ПК с деактивированными чипами. Если вы хотите сами контролировать свой ПК, вот что вам нужно приобретать. Другим вариантом было бы приобретение ПК под управлением Linux, — подобный проект муниципалитет Мюнхена начал примерно 10 лет назад и планирует завершить до конца текущего года. Такой конец NSA-скандала вряд ли приведет к росту акций Microsoft.

Мозг программиста

Спасибо за статью habrahabr.ru/post/191210/! Хорошую тему подняли.

Поделюсь и своим опытом. Ниже — идентичное содержание и первой, и заключительной лекции в программе подготовки стажеров.

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

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

Станочник ознакамливается с конструкцией станка до начала работы. Автомобилист изучает устройство автомобиля, его механику и физику, хотя бы на базовом уровне. Швея изучает швейную машинку. Многие художники практически знакомы с поведением ворса на различных видов кистей в различных условиях, с разной силой нажима и углом прикосновения…

Для создания программ ЭВМ программист помимо прочего использует устройство /dev/brain, также известное в миру как головной мозг.

Помимо аналитической части, принципы работы которой до сих пор малоизвестны и сомнительны, основные функциональные части /dev/brain – это каналы восприятия и память. В том числе “оперативная память”, работу которой можно ассоциировать с мышлением.

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

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

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

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

Кинестетическая память

Самая сильная. В детстве будущего физиолога Павлова укусила собака. Собака укусила и позабыла. А Павлов вырос и не позабыл…

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

Визуальная память

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

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

Для решения задач программирования – вполне приемлемые, и даже отличные параметры.

Аудиальная память

А здесь у разных людей по разному. У кого-то она развита хорошо, а у кого-то не развита вовсе. Но всем полезна. Каким образом – покажу ниже.

Абстрактная память

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

Имеет самый маленький объем! Человек в состоянии одновременно удерживать в голове от 3 до 7 абстрактных фактов. Если его фамилия не Вассерман – в тот момент, когда он попытается учесть восьмой фактор в анализируемой системе – из области логической видимости пропадет один из ранее актуализированных.

И все это можно и нужно учитывать.

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

Тупить в монитор

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

Как избавиться от проблемы тупления в монитор?

Весьма просто. Достаточно поместить часы в область зрения, и каждые 20 минут обязательно покидать рабочее место на 10 минут. Хорошая идея – занять это время физическими занятиями или общением.

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

Нарисовать картинку

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

Есть академические приемы использования этой методики. Во-первых, это прекрасный UML. Во-вторых, это методы XP (экстремального программирования) и SCRUM. Эффективность этих методов неоспорима.

Про XP можно почитать в википедии, а про UML отмечу немедленно некоторые из его замечательных свойств:

Легко позволяет управлять уровнями абстрагирования и контролировать детализацию при разработке любого рода решений при программировании. Практически это единственный метод для действительно эффективного решения задач по декомпозиции (“Разделяй и влавствуй!”).

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

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

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

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

Вообще визуальные методы – самые эффективные для обучения. Помните девочек-отличниц из средней школы? (Осторожно, сейчас будет разновидность юмора — сарказм) Большинство из них – дуры… Но ничто не мешает им систематически получать пятерки. Если вы заглядывали в их тетради – информация всегда хорошо структурирована, и представлена ЦВЕТНОЙ графикой. Поэтому они отлично запоминают материал, и легко используют его даже для абстрактных выводов.

Умные не зубрят. Они конспектируют и рисуют.

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

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

Обсудить с коллегами

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

Что происходит при этом?

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

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

Яркие примеры многие из читателей сотни раз встречали в курилках и на планерках у талантливых руководителей.

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

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

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

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

Спасибо за внимание и удачи всем!

Как начать разрабатывать игры даже если до этого вы были бухгалтером

До того как я стал разработчиком игр, я (да и все в моем окружении) считал себя дизайнером сайтов.

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

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

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

Шаг 0. Станьте разработчиком игр

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

Как это сказать себе и другим?

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

Первое, что надо сделать, чтобы стать разработчиком игр:

Начать посещать сайты, связанные с тематикой игр и разработкой игр.

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

Купить пару книг в “киндл” на амазоне, например, о игровом дизайне.

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

Шаг 1. Найдите себе применение как разработчику игр

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

Слова “найти проект” для каждого разработчика игр значат разное, вот список популярных способов поиска проектов:

Выйти из состояния “поиска проекта” нужно как можно быстрее, и желательно выйти в состояние “делаю проект” и делать проект с шансами на успех: релиз и популярность.

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

Вот некоторые советы для прохождения этого шага:

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

Например, я сделал маме подарок на НГ — 3д-игру по психологической методике: [embedded content]

У меня не было опыта разработки на C# и программировать я особо не умел (немного знал python) и никогда до этого не моделил.

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

Найдите себе единомышлеников. Мне в моем развитии очень сильно помогли: скайп-чатик разработчиков социальных игр _{(теперь уже создатели: Голос Припяти 3D, Tanks Heroes, Contract Wars, Батла и многие другие)}, а также одногруппники из Scream School по курсу гейм-дизайна. Их успех будет вас подталкивать, а обмен опытом ускорит процесс развития.

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

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

Шаг 2. Помогите себе закончить хотя бы ОДИН проект!

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

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

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

Вгоните себя в экстремальные условия, а выходом из них сделайте релиз. Поставьте себе реальный, но очень сжатый срок на релиз, например, 48 часов или неделю, но спать будете по 4 часа в день. Это даст сильный толчок, заставит оптимально использовать время и сфокусироваться на результате.
- Сжатые сроки
  
  Сжимая сроки, не оставляйте себе время на риск. Сжимайте до последнего, пример с 48 часами — хороший.
- Отсутствие сна
  
  Полное или почти полное отсутствие сна хороший мотиватор, но не доходите до крайностей. Практика показывает, что даже молодому организму надо давать отдых.
- Менеджмент времени
  
  Не стоит выделять много времени на тайм-менеджмент, но не забывайте ставить себе вехи (milestone). Например, скажите себе, что через 5 часов вам надо сделать играбельный прототип.
  
  Например, в своем первом 48 часовом марафоне _{(на нем я только рисовал)}, я за первую треть времени нашел стиль игры, нарисовал основной, игровой экран и все спрайты врагов. И за оставшееся время сделал 170+ спрайтов анимации и дорисовал интерфейс.
  
  [embedded content]
- Конкурсы, особенно мероприятия, типа, HackDays или Ludum Dare, где нет времени на раздумья и надо сразу бросаться в работу, — отличное подспорье для пунктов выше.

Поставьте себе рамки. Для первого релиза, особено в сжатые сроки, критически необходимо знать рамки проекта. Выпишите себе минимум, что нужен для релиза, и не выходите из него. По необходимости:
- Урежьте список возможностей
  
  Было бы здорово сделать возможность летать на самолетах, но если вы делаете шутер про пехоту, сфокусируйтесь на стрельбе.
- Сократите время игры
  
  Вероятно, вы рассчитывали сделать синглплеер на 5 часов игры, но вы останетесь победителем с демкой на 20 минут.
- Уберите часть контента
  
  Конечно, дополнительная карта не будет лишней для вашего тактического шутера, но релиз останется релизом даже с одной картой.

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

Шаг 3. Сделать полноценный релиз

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

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

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

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

Два шага вперед, один в сторону. Какой бы разнообразной вы ни планировали игру, не стоит делать сразу 50 типов врагов и тысячи уровней. Сфокусируйтесь на реализации возможностей игрока, а не способах их проявлений. Делаете слешэр? — Реализуйте возможность рубить врага, а врагов клонируйте.

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

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

И главное… Не бойтесь вернуться на шаг 2. Возможно, еще не время для настоящего релиза.

Удачных вам релизов и быстрого развития.

[Перевод] Почему Windows 95 подвисала при форматировании дискеты?

Рэймонд Чен отвечает на известную шутку:

— Папа, покажи, какая винда многозадачная!

— Сейчас, сынок, только дискету доформатирую...

Кто же целыми днями форматирует дискеты? Оказывается, многие гики только этим и заняты. (Вообще-то, можно покупать дискеты уже отформатированными, только тссс!) Но почему Windows 95 подвисала при форматировании дискеты?

Всё дело в совместимости с MS-DOS.

Как мы видели немного раньше, MS-DOS в Windows 95 выступала как слой для старых 16-битных драйверов. Несмотря на то, что в итоге операции ввода-вывода обрабатывались 32-битной файловой подсистемой, все они проходили через 16-битный код, чтобы 16-битные драйверы, TSR и подобные обработчики видели «нормальные 16-битные операции» и работали в привычном им окружении.

В 16-битном мире форматированием занималось программное прерывание 13h, и многие программы использовали этот факт, перехватывая прерывание так, чтобы получать управление при форматировании дискеты. Так делали некоторые TSR, программы для бэкапов (программы для бэкапов, разработанные для Windows 3.0, включали в себя 32-битные драйверы под Windows 3.x, называемые VxD, для отслеживания операций с дискетами). Но это объясняет не всё. В конце концов, Windows 95 прогоняла весь дисковый ввод-вывод, а не только форматирование дискет, через 16-битный код. Почему же форматирование дискет так существенно влияло на систему?

Как я отметил в статье по ссылке выше, 32-битная файловая подсистема тщательно подделывала свидетельства, заставляя 16-битный код верить в то, что за всё ответственна MS-DOS, хотя это и было неправдой. Любой, кто занимался программированием TSR (ого, определение любой, кто занимался программированием TSR когда-то охватывало массу людей, а сегодня описывает несколько десятков бывалых программистов, большинство из которых хотели бы забыть это как страшный сон), знает всё про флаг INDOS. MS-DOS устанавливала этот флаг на время обработки запроса ввода-вывода. Поскольку MS-DOS не допускала вложенного вызова самой себя, TSR должны были тщательно отслеживать этот флаг, чтобы знать, безопасно ли обращаться к MS-DOS. Флаг INDOS был 16-битным отражением сущности, которую 32-битное ядро называло Главной Критической Секцией; 32-битное ядро держало главную критическую секцию и флаг INDOS в одинаковом состоянии, чтобы не вызывать один и тот же драйвер MS-DOS или TSR параллельно несколько раз. Когда одна виртуальная машина захватывала главную критическую секцию, любая другая виртуальная машина, попытавшаяся сделать то же самое, была вынуждена ждать, пока первая виртуальная машина не отпустит секцию. Таким образом, параллельные вызовы драйвера или TSR блокировались.

Как я уже отметил, в 16-битном мире собственно форматированием занималась ROM BIOS, и в целях совместимости форматирование дискет по-прежнему посылалось через 16-битное программное прерывание 13h, чтобы все TSR и драйверы могли увидеть происходящее. Многие BIOSы безумны, так что при запросе на форматирование дискеты 32-битное ядро проделывало большую дополнительную работу, чтобы BIOS получала именно то окружение, которого хотела. В частности, порты аппаратного таймера переходили от менеджера виртуальных машин под полный контроль BIOS, чтобы не влиять на работу циклов, используемых BIOS для задержек при форматировании, для которых критично время выполнения.

Итак, посчитаем итоговый урон. Пока дискета форматируется, таймер развиртуализован для точности циклов, используемых BIOS для задержек. Только виртуальная машина, форматирующая дискету, получает сигналы от таймера; остальным приходится ждать. Отсутствие сигналов таймера означает, что никто не вызывает планировщик с сообщением «пора дать поработать другому потоку». Далее, главная критическая секция заблокирована на время операции, что означает, что никакой другой поток не может начинать операции ввода-вывода. Всё это ещё усугубляется тем, что дискета — медленное устройство, и любая операция, ожидающая окончания работы с дискетой, вынуждена остановиться и подождать несколько секунд.

Хорошо хоть, что дискеты форматируются по дорожке за раз, и система блокируется не на всё время форматирования. BIOS подаётся команда отформатировать одну дорожку, и по окончании процесса таймер возвращается в нормальное состояние (что позволяет планировщику заняться своим делом), главная критическая секция разблокируется (и ожидающие операции ввода-вывода получают шанс на выполнение). Но потом возвращается программа FORMAT.COM и форматирует следующую дорожку, и система возвращается назад в состояние подождём, не будем отвлекать BIOS от работы.

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

Конечно, если бы Windows 95 не должна была поддерживать совместимость с 16-битными драйверами, TSR и сомнительными BIOS, она могла бы направлять запросы форматирования прямо в 32-битный драйвер дискет, не отвлекаясь на абсурдные операции с таймером и главной критической секцией. Но вообще-то у нас уже была система, отказавшаяся от совместимости с 16-битными драйверами, TSR, 16-битными Windows-программами с собственными 32-битными VxD-драйверами и сомнительными BIOS. Она называлась Windows NT.

Если вы хотели Windows NT, вы знали, где её найти.

[Перевод] Какую роль играла MS-DOS в составе Windows 95?

MS-DOS в составе Windows 95 использовалась для двух целей:

Она служила загрузчиком.

Она выступала в качестве слоя совместимости с 16-битными драйверами.

Когда Windows 95 стартовала, сначала загружалась специальная версия MS-DOS, именно она обрабатывала ваш файл CONFIG.SYS, запускала COMMAND.COM, который выполнял ваш AUTOEXEC.BAT и в конце концов выполнял WIN.COM, который в свою очередь начинал процесс загрузки 32-битного менеджера виртуальных машин VMM.

Эта специальная версия MS-DOS была полностью функциональна в той мере, в которой слова «полностью функциональна» вообще применимы к MS-DOS. По-другому и быть не могло, при выходе в режим эмуляции MS-DOS только эта версия и оставалась работать.

Программа WIN.COM начинала загрузку того, что большинство людей называют собственно «Windows». Посредством копии MS-DOS она загружала менеджер виртуальных машин, считывала файл SYSTEM.INI, загружала драйверы виртуальных устройств, затем выключала EMM386 (если таковой был) и переключалась в защищённый режим. «Настоящая Windows» с точки зрения большинства людей — именно защищённый режим.

В защищённом режиме драйверы виртуальных устройств творили свою магию. В числе их действий было вытаскивание всего состояния MS-DOS, перевод его в состояние 32-битной файловой подсистемы и отключение MS-DOS. Все дальнейшие файловые операции направлялись в 32-битную файловую подсистему. Когда программа обращалась к int 21h, ответственной за обработку оказывалась 32-битная файловая подсистема.

Здесь вступает в игру вторая роль MS-DOS. Видите ли, программы и драйверы MS-DOS любили встраиваться в глубины операционной системы. Они могли заменять обработчик прерывания 21h, они могли патчить код системы, они могли заменять низкоуровневые дисковые обработчики int 25h и int 26h. Они могли также творить умопомрачительные вещи с прерываниями BIOS типа int 13h, ответственного за работу с дисками.

Когда программа обращалась к int 21h, сначала запрос направлялся в 32-битную файловую подсистему, где проходил некоторую предобработку. Затем, если файловая подсистема обнаруживала, что кто-то перехватил вектор int 21h, она переходила назад в 16-битный код, чтобы позволить перехватчику выполниться. Замена вектора int 21h идеологически похожа на сабклассинг окна. Вы получаете старый вектор и устанавливаете новый вектор. Когда установленный вами обработчик вызывается, вы что-то делаете, а затем вызываете старый обработчик. После возврата из старого обработчика вы можете ещё что-нибудь сделать, прежде чем вернуть управление.

Одним из 16-битных драйверов, загружавшихся из CONFIG.SYS, был IFSMGR.SYS. Его задачей было перехватить MS-DOS первым, прежде чем все остальные драйверы и программы получат свой шанс! Этот драйвер был в сговоре с 32-битной файловой подсистемой, возвращаясь из 16-битного кода назад в 32-битный, чтобы файловая подсистема могла продолжить свою работу.

Другими словами, MS-DOS была всего лишь исключительно искусной подсадной уткой. 16-битные драйверы и программы патчили и перехватывали обработчики, которые для них выглядели совсем как настоящая MS-DOS, но в действительности были приманкой. Если 32-битная файловая подсистема видела, что кто-то купился на приманку, она заставляла подсадную утку крякать.

Начнём с системы без «злобных» драйверов и программ, внедрившихся в MS-DOS.

Это рай. 32-битная файловая подсистема оказалась способной проделать всю работу, не взаимодействуя с надоедливыми драйверами, творящими причудливые вещи. Обратите внимание на дополнительный шаг обновления переменных состояния MS-DOS. Хотя мы и извлекли их в ходе загрузки, мы поддерживаем их в актуальном состоянии, поскольку драйверы и программы часто «знали» о них, обходили операционную систему и работали непосредственно с переменными состояния. Следовательно, файловая подсистема должна была поддерживать иллюзию ответственности MS-DOS (несмотря на то, что на самом деле MS-DOS уже не работает), чтобы такие драйверы и программы видели то, что ожидали.

Обратите ещё внимание на то, что переменные состояния разные для разных виртуальных машин. (То есть каждый открытый сеанс MS-DOS получал свою собственную копию переменных состояния.) В конце концов, у каждого сеанса MS-DOS была отдельная текущая папка, отдельная таблица файлов и тому подобное. Впрочем, всё это было спектаклем, потому что настоящий список открытых файлов хранился в 32-битной файловой подсистеме. Иначе и быть не могло, поскольку дисковые кэши должны были быть согласованы, а ограничения совместного доступа к файлам должны были проверяться глобально. Если один сеанс MS-DOS открыл файл для монопольного доступа, то попытка программы, работающей в другом сеансе MS-DOS, открыть тот же файл должна была завершиться с ошибкой.

Хорошо, это был простой случай. Сложный случай: у вас был драйвер, перехвативший int 21h. Я не знаю, что этот драйвер делает, допустим, это сетевой драйвер, перехватывающий ввод-вывод для сетевых дисков и обрабатывающий его как-то особенно. Предположим также, что какая-то TSR-программа, запущенная в сеансе MS-DOS, перехватила int 21h, чтобы печатать на экран 1, когда int 21h вызывается, и 2, когда int 21h завершается. Проследим обращение к локальному диску (не сетевому, так что сетевой драйвер ничего не делает):

Заметьте, что всю работу по-прежнему делает 32-битная файловая подсистема. Вызов проходит по всей 16-битной цепочке только для поддержания иллюзии ответственности 16-битной MS-DOS. В 16-битном мире выполнялся только код, установленный TSR и драйвером, плюс маленький кусочек IFSMGR, связывающий компоненты. Никакой код 16-битной MS-DOS не выполнялся. 32-битная файловая система перехватила у MS-DOS всю работу.

Аналогичный танец «перехватить нормальную работу, но позволить необычные действия, если кто-то попросил необычные действия» происходил, когда подсистема ввода-вывода принимала управление вашим жёстким диском от 16-битных драйверов устройств. Если подсистема распознавала драйверы, она собирала их состояние и обрабатывала все операции так же, как 32-битная файловая подсистема обрабатывала операции вместо 16-битной MS-DOS. С другой стороны, если подсистема не распознавала какой-то драйвер, она оставляла его ответственным за диск. Компонент, передающий команды из 32-битной среды 16-битному драйверу, назывался RMM.

Если вам не повезло использовать RMM для какого-то диска, вы, вероятно, заметили, что производительность операций с этим диском ужасна. Причиной тому использование старого неуклюжего 16-битного драйвера вместо быстрого многопоточного 32-битного. (Пока 16-битный драйвер обрабатывал одну операцию ввода-вывода, невозможно было обрабатывать другой ввод-вывод, потому что 16-битные драйверы не были рассчитаны на многопоточность.)

RMM, как ни странно, оказался полезен своей ужасностью, потому что его использование было ранним признаком заражения вашего компьютера MS-DOS-вирусом. В конце концов, MS-DOS-вирусы делали то же, что и TSR и драйверы: они перехватывали векторы прерываний и получали контроль над вашим жёстким диском. С точки зрения подсистемы ввода-вывода, они выглядели в точности как 16-битные драйверы жёсткого диска! Когда люди жаловались «Windows внезапно начала ужасно тормозить», мы направляли их на страницу производительности системы в панели управления и спрашивали, есть ли там строка «Часть дисков работает в режиме MS-DOS» или «Все диски используют режим совместимости с MS-DOS». Если есть, то за диски отвечал RMM, и если вы не меняли «железо», это, вероятно, означало вирус.

Наконец, некоторые части MS-DOS не имели отношения к вводу-выводу. Например, были функции выделения памяти, разбора строки с возможными шаблонными символами в формат FCB и тому подобные. Такие функции по-прежнему обрабатывались MS-DOS, поскольку это всего лишь функции «вспомогательной библиотеки» и ничего не выигрывали от переписывания в 32-битном коде, кроме возможности сказать «да, мы это сделали». Старый 16-битный код прекрасно работал, и использование готового кода позволяло сохранить совместимость с программами, патчившими MS-DOS с целью изменить поведение таких функций.

Первый комментарий к оригинальной статье: «Больше всего впечатляет, что бо́льшая часть этого бо́льшую часть времени действительно работала (в основном).»

[Перевод] В App Store меняется алгоритм ранжирования

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

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

Ранее основным параметром для определения позиции приложения в чартах для App Store было количество загрузок. Сейчас, похоже, мнение пользователей так же начали принимать во внимание.

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

Еще одно изменение, замеченное Fiksu – частота обновления топов. В прошлом они обновлялись каждые 15 минут, что позволяло разработчикам практически в реальном времени наблюдать (и изменять) то, как влияют установки на позиции приложения. Сейчас позиции меняются раз в три часа.

Говорят, что это изменение поможет App Store бороться с теми, кто использует автоматизированные средства накрутки. Потенциально, замедление даст Apple время для определения «коротких пиков загрузок», объясняет Fiksu, которые обычно связывают с роботами и другими не органическими причинами скачиваний. В теории, задержка так же может позволить Apple изучить аномалии в том, как протекают загрузки, и предотвратить попадание в чарты тех приложений, которые их покупают.

Директор Appsfire Ориэль Оайон кроме того отмечает, что некоторые разработчики обнаружили то, что Apple начала учитывать возвраты и по-другому обрабатывать данные о деньгах для free-to-play игр. Он специально обратил внимание на изменения в Top Grossing Ranks, отметив, что Pandora и Rdio раньше никогда не достигали таких позиций.

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

Глава MobileDevHQ Ян Сефферман заметил еще одно изменение в App Store. Результаты поиска приложений для iPhone разнятся, если искать с iPad или с iPhone. Если учесть данные Fisku об изменениях, то можно предположить, что Apple наконец в общем занялась открытием приложений, а не просто улучшением чартов.

Нирен Хиро из SearchMan помимо этого докладывает о том, что разработчики в США и Японии говорили о влиянии вовлеченности пользователей (проведенное в приложении время, количество запусков и т.п.) на позиции в категории, и что с 5 августа эти изменения учитываются во всех странах.

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

...

суббота, 24 августа 2013 г.