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

[Из песочницы] Как enum доступным всем сделать, да в мета-тип записать

Исследование гра­фи­чес­кого напря­же­ния на ос­нове модели элек­тро­маг­нит­но­го по­ля

Переносите домен? Готовьтесь к неприятностям

[Перевод] Давид Хейнемейер Ханссон: День, когда я стал миллионером

Уязвимость Account Manager в Android, о которой необходимо знать

Приветствую тебя, дорогой читатель!
Многие приложения используют возможности Account Manager(AM) в своих приложениях. Да и с одной стороны правильно делают, ведь этот инструмент позволяет упростить некоторые вещи. Он позволяет хранить пароль, токен, да и в принципе любые строковые данные юзера. Так же позволяет автоматически обновлять токен, если тот протухает, да и много других вещей. Но у этого удобства есть и другая сторона — безопасность. Из-за этого собственно я и написал данный текст.

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

Вообще для работы с AM в приложении нужно сделать несколько телодвижений и создать два компонента — наследника AbstractAccountAuthenticator и Service (подробней тут). Последний придется зарегистрировать в манифесте приложения таким образом

        <service
            android:name=".account.AuthenticatorService"
            android:exported="false">
            <intent-filter>
                <action android:name="android.accounts.AccountAuthenticator" />
            </intent-filter>

            <meta-data
                android:name="android.accounts.AccountAuthenticator"
                android:resource="@xml/authenticator" />
        </service>

А еще, если вы заметили, то нам надо создать в ресурсах некий xml файл с именем authenticator.xml. Хотя название тут не важно, а важно содержимое. Оно то и играет ключевую роль рассказа. Выглядит файл внутри вот так

<account-authenticator 
    xmlns:android="http://ift.tt/nIICcg"
    android:accountType="@string/account_type"
    android:label="@string/app_name" />

Параметр label — отвечает за название в списке аккаунтов в настройках девайса, а самое интересно несет в себе accountType. Без него приложение не сможет добавлять и получать аккаунты. А еще с помощью этого параметра можно перехватить аккаунты другого приложения даже на девайсах без рута. Давайте посмотрим, как это может произойти.
На устройстве существует приложение А с accountType = «someType», это приложение создает акаунт, добавляет в него токен, пароль и прочую информацию. В один прекрасный момент на устройство устанавливается приложение B с таким же accountType = «someType». И вот если удалить приложение A, то все созданные аккаунты перейдут во власть приложения B с полным доступом. Обратное тоже верно, аккаунты приложения B передадутся приложению A, если удалить B.

пример на видео

Опережая вопросы про подписи apk, это не зависит от того, каким ключем было подписано приложение, релизным или дебажным, передача произойдет в любом случае. Ужасно, правда?
Все это можно проделать в плоть до API версии 23. Исправлено только с выходом андроид 7.0(API 24). Печалит в этой ситуации ничтожно малый процент устройств с этой версией андроида. Кстати, узнал я об этой проблеме из доклада по безопасности в андроид. К сожалению в тексте, пересказе презентации, об этом ничего нет вообще, а вот в видео об этом упомянули вскользь, не придав особого значения.

Так же что же ты предлагаешь? — можете спросить вы. А я предлагаю вам два варианта решения проблемы. Первый — продолжать пользоваться AM, но хранить в нем все важные данные в зашифрованном виде. Если вы перестали доверять AM, можно продолжать им пользоваться, но не хранить в нем важные данные и воспользоваться AM в связке со вторым вариантом. Второй — вообще отказаться от AM и пользоваться хранилищем, которое можно шифровать. Например SQLite в связке с sqlcipher или Realm, который поддерживает шифрование из коробки. Я выбрал последний. Тут пример для realm, где показано, как генерировать и хранить ключ шифрования.

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

Let's block ads! (Why?)

Усиленный ботнет Aidra заразил 3500 устройств меньше, чем за неделю

Данные о новой атаке появились из блога пользователя с ником Unixfreakjp. В его публикации идет речь о новом, более мощном, чем Mirai, ботнете интернета вещей. Ему удалось заразить около 3500 устройств в срок за пять дней. На сегодня эта атака стала самой «удачной» из подобных за последнее время. Благодаря высокой скорости атаки, количество затронутых бот-клиентов достигло такого уровня с момента обнаружения загрузочного файла. После атаки на Dyn это происшествие, вероятно, станет только началом грядущих более неприятных событий для всего интернета.

В этой заметке мы раскрываем подробности того, как работает червь и рассказываем, кого подозревают в организации атаки.

Что за зверь

Вредоносное ПО получило название Linux/IRCTelnet. Программа буквально сшита из кусков кода от нескольких, известных и до последней атаки, вредоносных приложений, атакующих подключённые к интернету устройства по всему миру.

Linux/IRCTelnet можно считать новой версией исходного кода ботнета Aidra. Логику сканирования Telnet вредительский Linux/IRCTelnet позаимствовал у ботнета Bashlight. Как результат, Linux/IRCTelnet содержит список некоторых 60-ти широко используемых комбинаций логина и пароля, использованных в Mirai. А продолжается все при помощи добавления кода на сайты, находящиеся под атакой. Эти веб-платформы обычно работают с интернет-протоколом нового поколения IPv6.

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

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

Родительский код

Об Aidra впервые заговорили в ходе весьма смелого и этически спорного исследования, проведенного компанией Guerilla. Изначальной целью его было измерить уровень безопасности всего интернета. В процессе было инфицировано более 420 000 Linix-машин, подключенных ко всемирной сети. Вот так Guerilla создала воистину эпический ботнет со способностью сканировать миллиарды ip-адресов. Из анонимного источника известно, что Aidra захватила зараженные устройства для осуществления множества DDoS-атак. Однако это сработало на ограниченном количестве гаджетов (примерно 30 000 устройств).

Подробности

В блоге «Malware must die!» Unixfreakjp сделал очень интересный и подробный анализ. Ниже приведены некоторые выдержки из него.

Установлено, что атаки происходили через протокол Telnet с айпи-адресов из списка ниже.

Они начинались как грубая попытка авторизоваться в системе и, если это получалось, то вызывались системные команды shell, sh, free. Они отправлялись со следующей однострочной командой для загрузки и установки программы-вредителя.

А после этого оператор атаки ботнета выполнил команду /etc/firewall_stop для закрытия сессии. Согласно зафиксированной попытке атаки, все это произошло менее, чем за одну секунду. Имеется в виду только отправка загрузчика по протоколу Telnet. Продолжительность процесса загрузки не учитывается.

Ниже показан скрипт установщика вредоносного ПО.

Бинарный анализ Linux/IRCTelnet показал, что ELF (троянский скрипт для DDoS-атак линукс-устройств) в основе имеет С++. По большей части скомпилирован при помощи uClibc, кроме бинарного ARM, за которым стоит GCC-компиляция. В целом это не масштабный проект. Еще одно интересное замечание — хардкод ELF содержит сообщения на итальянском языке.

Можно предположить, что комментарии со скриншота выше должны что-то значить для других. Но это не так — сообщения нужны для осуществления вредоносной активности ботнета. Автор анализа предполагает, что за атакой может стоять итальянский хакер, которого можно найти по адресу d3m0n3 or eVil (d4rk3v1l) из IRCNet канала #hack.it

У Linux/IRCTelnet нет никакого постоянного автостарта или руткита, или чего-то еще, что может повредить ваш гаджет, подключенный к интернету. Скрипту ELF свойственно помещать вредительскую схему out-of-the-box для того, чтобы заразить заново: перезагрузить бота, даже обновить старые версии и удалить конкурирующие ботнеты. Для достижения этой цели замечательно подходит протокол Telnet, который как посредник заражает кодом загрузчика выбранную сеть устройств, а уж сеть запускается и выполняет свою вредительскую функцию. Помните, что как только ботнет заражен, консоль сервера CNC получает список последних зараженных узлов, так что человек, контролирующий атаку, может послать команду повторного заражения так быстро как он поймет, что один или больше специфических бот-клиентов убраны, удалены или неактивны.

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

Что дальше

Молчание Брайана Кребса только подтверждает уровень существующих проблем в современной сети. Дело в том, что эта простота, с которой на сеть обрушиваются новые волны DDoS-атак приводит нас к мысли, что взломать то, что два года назад было никому не нужно, очень легко для последующей успешной атаки на авторитетные интернет-платформы. Подводя итоги, Linux/IRCTelnet — это первый гонец эпохи вредоносного ПО нового поколения, которое с готовностью подтверждает свои немалые способности вредить. То, как быстро увеличивается количество подключенных к интернету умных устройств, подтверждает, что проблемы не за горами. Очень много координированного вреда можно причинить открытом глобальному сервису Telnet.

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

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

Let's block ads! (Why?)

Компания Canonical выпустила новую версию Ubuntu Core для IoT-приложений

Из Firefox 52 удалят API уровня заряда аккумулятора для сохранения приватности пользовательских данных

Security Week 44: zero-day в Windows, уязвимость в ботнете Mirai, серьезные дыры в MySQL

Вашу игру пройдут немногие, так стоит ли тратить время на концовку?

Microsoft отказывается от поддержки EMET

[Перевод] Дональд Кнут: про Ричарда Фейнмана, награды и алгоритм КМП

Кнут — первый, кто получил премию имени Грейс Мюррей Хоппер. Еще среди его ачивок — медаль фон Неймана, Тьюринга, премия Киото и Национальная научная медаль США.

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

Важность наград и Премия Киото (87/97)

Для меня стало важным получение Национальной научной медали США, врученной президентом Картером, что стало для меня неожиданностью. Также я получи привилегию сидеть с Ричардом Фейнманом, когда он получил свою Национальную научную медаль США. И перед тем как подняться за своей наградой, он толкнул меня плечом и сказал: «Хорошо Дон. Это твой важный момент». Он был моим героем. Я знал его с Калифорнийского технологического института, и этот день стал по-особому важным для меня.

Также я получил другие награды, представляя компьютерные науки, как, например, Премия Харви в Израиле. Опять же, эти награды доступны не только для компьютерных специалистов, но и для химиков, физиков, биологов. Людям из разных научных сфер. Некоторые награды были доступны и для гуманитариев, и я рад признать, что я получил ещё и Доктора Гуманитарных Наук за работу над языком программирования METAFONT. Это то, что удовлетворяет мою душу и даёт силы идти дальше.

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

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

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

Nob Yoshigahara

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

Ох, да, вы правы. Приз Киото так же сопровождается денежной наградой. Конечно это не Нобелевская премия, но достаточно велика, чтобы убедить мир в том, что они подумали дважды, прежде чем вручить её. Приз составил около $400.000 и мы с Джилл не хотели что бы это разрушило нашу жизнь.

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

Donald Knuth receives Kyoto Prize, the Japanese «Nobel»

Алгоритм Кнута-Морриса-Пратта (92/97)

У меня есть история, о которой я никогда не писал, хотя я писал довольно много, и при этом она довольна интересна.

Алгоритм стал довольно популярен, хотя лично я не уверен, что использовал его за последние лет 20. Впрочем, он упомянут во многих учебниках и является действительно хорошим способом поиска слова в объемном тексте. Например, ища слово «t-h-e», глупо искать само слово в тексте. Ну, или давайте рассмотрим на примере слова “d-i-k-r-a-n”. Начнем с любой точки в тексте и проверяем: Это ‘d’? Да. Рассматриваем следующую букву. Это ‘i’? Да. Следующая ‘k’? Нет, потому что это слово, например, “direction”. Теперь мы переходим к следующему слово, вновь проверяем. Первая буква ‘I’, a не ‘d’? Тогда пропускаем слово, переходим к следующему и опять проверяем…

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

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

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

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

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

Это маленькое чудо — алгоритм Кнута-Морриса-Пратта (КМП)

Перевод: Никита Шаврин

Читать еще

• Дональд Кнут: Я сидел на задних партах и травил шутки, а учителя смирились и не часто били по заднице (1,2,3,7/97)
  
• Дональд Кнут: «Мой совет молодым» (93/97) и «Ощущая потребность самоутвердиться» (9/97)
  
• «Сюрреальные числа»: Я творил шесть дней, а на седьмой отдыхал (40,41,42/97)
  
• Дональд Кнут: Как создавалось «Искусство программирования» (33,38,39/97)
  
• Дональд Кнут: Когда же, наконец, выйдет четвертый том
• Дональд Кнут: Как я провел лето с компьютером, а не с девушками (19,20,21,22/97)
• Дональд Кнут: про ассемблер, транслятор и грамотное программирование

Список 97 видеороликов с историями Дональда Кнута

Плейлист на Youtube

1. Family history
2. Learning to read and school
3. My mother
4. My parents' finances
5. Interests in high school
6. Being a nerd of nerds at high school
7. My sense of humor
8. The Potrzebie System of Weights and Measures
9. Feeling the need to prove myself
11. University life: my basketball management system
12. University life: the fraternity system
13. Meeting my wife Jill
14. Bible study at university and a time of personal challenge
15. Extra-curricular activities at Case
16. Taking graduate classes at Case
17. Physics, welding, astronomy and mathematics
18. My maths teacher at Case and a difficult problem
19. My interest in graphs and my first experience of a computer
20. How I got interested in programming
21. Learning how to program on the IBM 650
22. Writing a tic-tac-toe program
23. Learning about Symbolic Optimum Assembly programs
24. The Internal Translator
25. Adding more features to RUNCIBLE
26. Wanting to be a teacher and why I chose to go to Caltech
27. Writing a compiler for the Burroughs Corporation
28. Working for the Burroughs Corporation
29. Burroughs Corporation
30. My interest in context-free languages
31. Getting my PhD and the problem of symmetric block designs with…
32. Finding a solution to an open problem about projective planes
33. Inception of The Art of Computer Programming
34. 1967: a turbulent year
35. Work on attribute grammars and the Knuth-Bendix Algorithm
36. Being creative in the forest
37. A new field: analysis of algorithms
38. The Art of Computer Programming: underestimating the size of the...
39. The successful first release of The Art of Computer Programming
40. Inspiration to write Surreal Numbers
41. Writing Surreal Numbers in a hotel room in Oslo
42. Finishing the Surreal Numbers
43. The emergence of computer science as an academic subject
44. I want to do computer science instead of arguing for it
45. A year doing National Service in Princeton
46. Moving to Stanford and wondering whether I'd made the right choice
47. Designing the house in Stanford
48. Volume Three of The Art of Computer Programming
49. Working on Volume Four of The Art of Computer Programming
50. Poor quality typesetting on the second edition of my book
51. Deciding to make my own typesetting program
52. Working on my typesetting program
53. Mathematical formula for letter shapes
54. Research into the history of typography
55. Working on my letters and problems with the S
56. Figuring out how to typeset and the problem with specifications
57. Working on TeX
58. Why the designer and the implementer of a program should be the…
59. Converting Volume Two to TeX
60. Writing a users' manual for TeX
61. Giving the Gibbs lecture on my typography work
62. Developing Metafont and TeX
63. Why I chose not to retain any rights to TeX and transcribed it to…
64. Tuning up my fonts and getting funding for TeX
65. Problems with Volume Two
66. Literate programming
67. Re-writing TeX using the feedback I received
68. The importance of stability for TeX
69. LaTeX and ConTeXt
70. A summary of the TeX project
71. A year in Boston
72. Writing a book about the Bible
73. The most beautiful 3:16 in the world
74. Chess master playing at Adobe Systems
75. Giving a lecture series on science and religion at MIT
76. Back to work at Stanford and taking early retirement
77. Taking up swimming to help me cope with stress
78. My graduate students and my 64th birthday
79. My class on Concrete Mathematics
80. Writing a book on my Concrete Mathematics class
81. Updating Volumes One to Three of The Art of Computer Programming
82. Getting started on Volume Four of «The Art of Computer...
83. Two final major research projects
84. My love of writing and a lucky life
85. Coping with cancer
86. Honorary doctorates
87. The importance of awards and the Kyoto Prize
88. Pipe organ music is one of the great pleasures of life
89. The pipe organ in my living room
90. Playing the organs
91. An international symposium on algorithms in the Soviet Union
92. The Knuth-Morris-Pratt algorithm
93. My advice to young people
94. My children: John
95. My children: Jenny
96. Working on a series of books of my collected papers
97. Why I chose analysis of algorithms as a subject

Let's block ads! (Why?)

Настройка UEFI-загрузчика. Самое краткое руководство в мире

[Перевод] Большинство игроков не пройдёт вашу игру, и это нормально

Розкомнадзор: держим ухо востро. Как вовремя заметить внесение в список

Как мы строили свой мини ЦОД. Финансы, ценообразование

В продолжение Части 1 — Colocation
В продолжение Части 2 — Гермозона
В продолжение Части 3 — Переезд

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

Сначала поговорим о дата-центре. Было очень много вопросов, например: Откуда средства? Сколько потратили? Привлекали ли инвестиции? Рентабельно ли? Постараемся ответить на эти вопросы. Свою работу мы начали с ноября 2015 года, и за этот месяц заработали всего 36 долларов. Не много, но для новичка на рынке это уже результат. Далее, путем привлечения клиентов (в том числе и корпоративных) мы вышли не неплохой оборот, с которого и покупали собственное оборудование. И вот, его стало уже достаточно, для того чтобы претендовать на собственный дата-центр (ну а о реальных причинах вы знаете и без нас).

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

Мы сэкономили огромное количество средств при постройке, на модульности. А именно, мы купили столько ресурсов — сколько нам нужно. Генератор — 5 кВт, ИБП — 5кВТ и т.п. Больше — всегда можно доставить, а вот «солить» не нужные ресурсы — не целесообразно для нашего проекта. Вот уже сейчас к нам едет новый ИБП, который мощнее старого и будет работать с ним в «паре», хотя нагрузка у нас еще не дошла до порога.

Из чего же состоит стоимость услуги? Как мы это видим?

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

• 1. Оборудование и его амортизация. Мы закупаем серверы компании HP б.у., для того чтобы снизить конечную цену для потребителя. На деле — серверы в отличном состоянии, с гарантией от нашего поставщика и с конкурентными процессорами. Более того, оборудование HP имеет очень низкое энергопотребление, но об этом позднее.
• 2. Электропотребление. Тут нам повезло больше. Небольшой сервер HP потребляет до 100 Вт. В сутки это 2,4 кВт. В месяц это 72 кВт. А в деньгах это 144 грн. ~ или 6$. Для сравнения сервер старой конфигурации C2Duo или C2Quad потребляет в несколько раз больше.
• 3. Кондиционирование и фрикулинг. Необходимо учитывать расходы на кондиционирование и фрикулинг в холодное время года. Наш кондиционер потребляет 10 кВт в среднем при кондиционировании, в сутки это 240 кВт, и 7200 кВт в месяц. А это 14400 грн. или 576$ ~. Не мало, правда? Фрикулинг в этом плане потребляет в разы меньше, около 1-2 кВт. Если разделить эту сумму на весь цод — не критично, но он пока не весь заполнен. И это еще не все.
• 4. Обслуживание помещения, охрана, и прочие мелочи, еще съедают приличную сумму. Порядка 200-300$/мес.
• 5. Поддержка — львиная часть расходов. Стоит учесть что работа поддержки у нас разделена на три смены. 7-15, 15-23, 23-7. Выходные тоже должны быть перекрыты, а плюс еще — старший администратор который должен быть доступен 24/7. Итого 3+1 человека в сутки. Плюс 2 в резерв когда у первой смены выходные. Плюс фин отдел. Итого выходит на зарплатный фонд минимум 2000$, а в пиках доходит и до 3000$.
• 6. Интернет-каналы. А их два плюс 1 резервный. Это еще часть средств, которые нужно заложить в оборудование. А именно, 1 мегабит в среднем стоит 1$. 2 канала по 1000 мегабит = 2 000$. Конечно за счет опта это чуть дешевле, но все-же. Что касается резервного — там оплата по трафику, там проще.

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

• — Сервер стоимостью 1000$ с окупаемостью скажем на 24 месяца. 41$
• — Кондиционирование + энергопотребление, еще 10$ ~
• — Помещение еще 3-5$
• — Поддержка, еще 20$ в стоимость
• — Интернет-канал еще где-то 15$

Получаем сумму минимальной сдачи в аренду — 91$. При этом реально сдаем мы такой сервер за 55-70$. И все это, при условии что мы «имеем» 100 постоянно загруженных серверов.

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

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

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

Собственно сам блейд C7000

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

Let's block ads! (Why?)

Экономика пацанской IT конторы

Уходим глубже в Underground: история одного экстремального дизайна игры

Разработка ядра Linux держится на электронной почте

Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 15 тыс. разработчиков и 222 компании вносят более 12 тыс. изменений между релизами или 7 / 8 правок каждый час? Чем пользуются создатель кернела Линус Торвальдс, мейнтейнера стабильной ветки Грег Кроа-Хартман (GKH) и другие товарищи, чтобы успешно координировать работу проекта и обеспечивать своевременный выход каждой новой версии?

Этим чудо-инструментом является текстовый клиент электронной почты: Mutt у GKH и Alpine у Линуса Торвальдса. Третий по рангу разработчик ядра Эндрю Мортон, также вовсю использует электронку для управления mm веткой.

With the wide variety of more “modern” development tools such as github, gerrit, and other methods of software development, why is the Linux kernel team still stuck in the 1990’s with ancient requirements of plain text email in order to get patches accepted? This talk will discuss just how the kernel development process works, why we rely on these “ancient” tools, and how they still work so much better than anything else.^[1]

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

Долгий путь к Git

Вспомним, как все начиналось. 25-го августа 1991 г. никому неизвестный финский студент написал письмо в новостную группу comp.os.minix, в котором анонсировал свою работу над свободной операционной системой и скорое ее завершение. В октябре того же года он выложил версию 0.0.2 на ftp в директории Linux, известил об этом комрадов хакеров и понеслось...

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

Linus doesn't scale, and his current way of coping is to silently drop the vast majority of patches submitted to him onto the floor. Most of the time there is no judgement involved when this code gets dropped. Patches that fix compile errors get dropped. Code from subsystem maintainers that Linus himself designated gets dropped. A build of the tree now spits out numerous easily fixable warnings, when at one time it was warning-free. Finished code regularly goes unintegrated for months at a time, being repeatedly resynced and re-diffed against new trees until the code's maintainer gets sick of it. This is extremely frustrating to developers, users, and vendors, and is burning out the maintainers. It is a huge source of unnecessary work. The situation needs to be resolved. Fast.

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

-rw-r--r-- 1 root root 36604 янв 11  2016 /usr/src/linux/Documentation/SubmittingPatches
-rw-r--r-- 1 root root 11186 янв 11  2016 /usr/src/linux/Documentation/email-clients.txt

Тем не менее к 2000 г. стало понятно, что нужна система контроля версий. Народ стал роптать, что разработка тормозится из-за механического способа работы Линуса. Это было сущей правдой, и тогда команда взяла на вооружение BitKeeper, который в то время являлся закрытым программным продуктом, предоставляемым бесплатно разработчикам открытых программ. Прагматичному Линусу это было до лампочки, но в команде были и принципиальные ребята, не глухие к голосу Ричарда Сталлмана, готовому без устали гвоздить все то, что содержит хоть байт закрытого кода. Alan Cox — программист написавший первый приличный сетевой стэк для ядра, был одним из них.

Какое-то время все шло вроде бы неплохо, BitKeeper значительно облегчил жизнь разработчикам. Им не надо было больше заботиться о том, кто имеет права на какие изменение, каждый из них мог работать в своей ветке древа исходников, возможность распределенных слияний^[2] исходного кода давала значительную экономию усилий для всех. Подспудно, назревал кризис, который и привел к созданию Git.

Затем автор Самбы Tridge (Andrew Tridgell) захотел сделать то, что умел делать лучше других — осуществить обратную разработку BitKeeper, чего по условиям лицензии деть было нельзя ни в коем случае. Разгорелся конфликт, Линус пытался его погасить, но не преуспел в том. И тогда он взял и за один день написал Git. Что было дальше — всем известно: в таком деликатном и консервативном сегменте ПО как VCS, Git сумел всего за несколько лет опрокинуть конкурентов.

Основное преимущество — широчайшая доступность

Недавно мейнтейнер стабильной ветки Linux ядра Грег Кроа-Хартман, выступая на одной конференции, выложил свои доводы за текстовую электронную почту и против использования систем совместной разработки, инспекции исходного кода, таких как GitHub или Gerrit.

Перечислив те очевидные достоинства, благодаря которым GitHub обрел огромную популярность среди разработчиков, докладчик несколько раз подчеркнул, что тот отлично работает для небольших проектов, но для крупных не годится, так как плохо масштабируем. В доказательство этого тезиса он привел Kubernetes, с 4600 открытыми заявками и около 600 pull request-ами. В презентации эти цифры были на 10% ниже.

Другие претензии GKH к Гитхабу:

• Требует постоянного доступа к интернету, но не все разработчики имеют к нему доступ.
• Pull request-ы и рассылки сами по себе.
• Внутренние проверки трудноосуществимы.
• Претензии к UI, мучительно трудно отслеживать заявки.

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

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

1. Простота
2. Широчайшая аудитория
3. Масштабируемость
4. Способствует росту сообщества
5. Внутренние проверки без проблем
6. Локализация и перевод текста
7. Быстрый обзор патчей
8. Возможность удаленной проверки
9. Отсутствие менеджера проекта

Первые три пункта на самое деле разные грани одного и того же: емайл прост и доступен каждому. Слепому, а по словам GKH в проекте есть ряд классных, но слепых программистов, электронная почта доступна а WWW — нет. Тем, кто сидит за корпоративным файрволом, git недоступен, а с электронкой никаких проблем нет. Мейнтейнеры часто путешествуют, выступают на конфах меняют пароли и явки и им проще дождаться подключения к сети интернет, скачать и отправить письма, нежели найти время и место, чтобы проверить статусы заявок в Gerrit. Кто-то умудрялся подолгу путешествовать на велосипеде по Африке и таки присылать патчи по расписанию.

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

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

Я получаю много писем

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

Overall, in 24 hours I received 18,799,115 bytes (18Mb) of email in 2067 individual messages:

Из них, как минимум, 237 живых писем в рассылку, Грег читает их все.

237 emails to mailing lists that I read everything that is posted. This includes a number of openSUSE mailing lists, systemd, linux-usb, linux-pci, linux-hotplug, IP, and a variety of other lower traffic lists.

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

Причем, эти цифры постоянно растут! Судя по всему GKH неплохо масштабируется.

О том как должен выглядеть образцовый патч написано в Documentation/SubmittingPatches. Никаких MIME и прочих глупостей, только plaintext. Патч должен содержаться в теле письма, а не быть к нему прикреплен.

6) No MIME, no links, no compression, no attachments.  Just plain text.
-----------------------------------------------------------------------

Linus and other kernel developers need to be able to read and comment on the changes you are submitting.  It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code.

For this reason, all patches should be submitted by e-mail "inline".
WARNING:  Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch.

Do not attach the patch as a MIME attachment, compressed or not.
Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code.  A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted.

Exception:  If your mailer is mangling patches then someone may ask you to re-send them using MIME.

See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched.

Как будто не сложно, но на самом деле не все почтовые программы справляются. В числе главных неосиляторов MS Outlook, Gmail (Web UI) и Lotus Notes.

(5:534)$ grep -A2 Lotus /usr/src/linux/Documentation/email-clients.txt

Lotus Notes (GUI)
Run away from it.

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

Помимо всего прочего, в числе 16 правил четко определены формат темы и содержания сообщения.

The canonical patch subject line is:
    Subject: [PATCH 001/123] subsystem: summary phrase

The canonical patch message body contains the following:
- A "from" line specifying the patch author (only needed if the person sending the patch is not the author).
- An empty line.
- The body of the explanation, line wrapped at 75 columns, which will be copied to the permanent changelog to describe this patch.
- The "Signed-off-by:" lines, described above, which will also go in the changelog.
- A marker line containing simply "---".
- Any additional comments not suitable for the changelog.
- The actual patch (diff output).

Зачастую, с письмами случаются странные казусы. Линус жалуется, что KMail Дмитрия Торохова надо сжечь к чертям, так как он портит пробелы и табуляции, из-за этого копипаста выдает мусор.

I cannot just cut-and-paste the whole line, because your tabs and spaces aren't tabs and spaces, they are some horrible abomination.

What looks like a tab above, when I save it and look at it with "od", it shows it true nasty life: it's not a tab, and it's not even eight spaces, it's four copies of the byte sequence '\302\240 ' ('\xC2\xA0\x20'), ie some horrid nasty three-byte sequence where one character is a space, and the previous two characters are some utf-8 abomination.

А вот Линус отчитывает техподдержку GMail за то, что их спамбот лажается в 20% случаях.

Еше могут возникнуть проблемы взаимопонимания между программистом и мейнтейнером. Комментарий на LWN в переводе.

Проверка патчей в письмах — отстой по сравнению c push --force. Станет мейнтейнер брюзжать, если я пришлю в ответе v2 одного из патчей в обработке или наоборот, он станет брюзжать, если вместо этого я целиком пришлю свежий v2 одним блоком? Заметит ли он v2, чтобы применить ту что нужно, я ведь не могу поменять статус своего pull request-а. Как мейнтейнер, смогу ли я в такой же ситуации верно применить корректировку?

Общий баланс и выводы

Трудно отделаться от впечатления, что Линус со товарищи канонизировали свои старые привычки 1990-х. Это и есть субъективная фактор, но он же упирается в фактор объективный. Хакеры, создавшие ядро Linux 25 лет назад, благодаря чему сообщество открытого ПО обрело материальную силу и нравственное лидерство, умеют с большой отдачей созидать именно таким способом. Если взять талантливых выпускников [МГУ Бауманка MIT Berkeley ваш_любимый_ВУЗ] и полностью заменить ими всех мейнтейнеров, то через год-два они сами перейдут на GitHub, или напишут что-то свое и будут на слайдах доказывать, насколько повысилось их продуктивность. Доказательством могут служить наличие сопоставимо крупных проектов, которые спокойно творят без патчей в теле текстовых писем. Также Гугл использует Gerrit, для разработки Android а Docker.

В качестве резюме, предлагаю комментарий на LWN.

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

А что думает по этому поводу Хабр?

Использованные материалы

1. Why kernel development still uses email
2. 10 Years of Git: An Interview with Git Creator Linus Torvalds
3. Слайды презентации GKH

---

1. ↑ Почему, при всем богатстве выбора «современных» средств разработки, таких как: github, gerrit и т. д., программисты ядра Linux застряли в 1990-х со своими дремучими правилами оформления патчей в теле простого текстового электронного сообщения? Вы узнаете как осуществляется разработка кернела, почему мы полагаемся на «древние» орудия труда и чем они настолько превосходят всех остальных. Со страницы анонса выступления GKH,
2. ↑ Distributed merge.

Let's block ads! (Why?)

[Из песочницы] Правила, которые помогают мне выжить в новом коллективе и запустить систему. Начало

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

Из истории с пометкой «секретно»:

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

Но это всё взгляд автора, то есть субъективно и подлежит сомнению. Это и будет первое правило, которое я для себя усвоил в процессе входа на проект и знакомства с предприятием.

Никому не верить на слово, пока не подтвердят фактами. Сомневаться до последнего

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

— Есть исключения? — прозвучал мой вопрос.

— Нет… — пауза. — Хотя, есть один особый VIP-клиент, который присылает заявки напрямую по электронной почте Наталье Степановне. Это наш старший менеджер.

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

В процессе получения сведений требуется убедиться в полноте представленных данных. Чек-лист на этот случай:

1. Переданы все копии используемых бумажных документов, файлов.
2. Получены показания свидетелей. Проводить беседу лучше с группой сотрудников — исполнителей процессов, ведь коллективный разум чаще вспоминает детали, в которых и обитает дьявол, согласно известной английской пословице («The devil is in the detail»).
3. Составлены эскизы процессов и реестр.
4. Проведён устный повтор всех действий сотрудника, которые я пометил в своём блокноте. Словно официант перед оформлением заказа.
5. Важно. Поставлена подпись сотрудника(-ов) в протоколе интервьюирования с указанием эскиза бизнес-процесса, документооборота, реестра операций и т.д. Перед подписью, как правило, собеседник начинает заново пробегать глазами по написанному тексту в попытках отыскать упущенное. Подпись добавляет ответственности.
6. Интуиция подсказывает, что от вас ничего не утаили.

Почему сомневаться? Так, помимо прочего, человеку свойственно ошибаться и не со злым умыслом.

Не бойтесь показаться въедливым — это положительная черта любого аналитика (исследователя)

Практический пример:

— Весь выпуск, помимо программы, мы отражаем в журналах по выпуску продукции, — сообщил сотрудник.

— А почему я вижу 3 журнала? — задаю я вопрос.

— Ну, для регистрации продукции А в журнале 1, продукции Б, В, Г в журнале 2, остальной продукции в журнале 3.

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

— А почему не используется один журнал для всей продукции? — спрашиваю я, узрев, что структура всех журналов схожая.

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

— Зачем их искать?

— Если получен запрос от директора по производству, диспетчеров, мастеров. Или произвели брак.

— Но вы же вносите данные в программу. Они могут увидеть требуемую информацию там?

— Да.

— Тогда зачем вы делаете это?

— Вот такие у нас ****** правила! У них вся информация есть, но не хотят...

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

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

На этапе обследования старайтесь выдерживать нейтральные отношения

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

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

• Он предложит вам множество функций и идей, которые могут не укладываться в концепцию проекта. При вашем отклонении их у него может возникнуть обида.
• Ваш приятель будет ждать с нетерпением, чтоб передать весь свой профессиональный опыт и знания. Но вам это не требуется для проекта.
• «Серёж, смотри! Сделай тут кнопочку зелёного цвета. Ещё зеленей! И левее.» (это не дизайнерская задача). Если это не спонсор/заказчик проекта, то смелый игнор. Если спонсор, то вы попадаете на риск, который я описывал в этой публикации, как неправильная технология внедрения.

При любом отношении рекомендую задать вопросы для собственного анализа:

• Почему такая позиция данного сотрудника?
• Затрудняет ли это достижение локального и глобального результата?
• Какие существуют риски и каковы возможности их минимизации? (внесите в личную карту рисков)

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

Let's block ads! (Why?)

Анонс Форума Dell EMC Forum 2016

Друзья, приглашаем всех, кто интересует процессом развития цифровой экономики, её влиянием на нашу жизнь и работу, посетить Форум Dell EMC Forum 2016, который пройдёт в Москве 9 ноября 2016. Подробности — под катом.

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

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

После регистрации вы сможете создать свою персональную программу Форума, выбрав интересующие вас сессии:

• Современная инфраструктура. Познакомьтесь с основами современного центра обработки данных, от серверов и СХД до сетевого оборудования, и узнайте подробнее об основах современной инфраструктуры — флэш-памяти, горизонтальной масштабируемости, облачных системах и программной определяемости.
• Конвергентные системы. Узнайте, как упростить ИТ и увеличить производительность с использованием конвергентных и гиперконвергентных систем.
• Облачные решения. Откройте для себя гибкие и масштабируемые архитектуры, решения для автоматизации обслуживания и услуги ITaaS, которые ускоряют бизнес-результаты в современном облачном мире.
• Трансформация рабочих мест. Узнайте, как модернизация клиентских рабочих мест и использование новейших технологий помогут расширить возможности ваших сотрудников и повысить уровень обслуживания ваших заказчиков.
• Аналитика больших данных. Испытайте новейшие технологии аналитики, которые позволят вашей организации выйти на новый уровень понимания бизнеса, предоставлять необходимые услуги и быстро развиваться.

Также на Форуме вы сможете пройти сертификацию для получения статуса Dell EMC Proven Professional. Первые 50 зарегистрированных участников смогут сдать сертификационный экзамен абсолютно бесплатно, остальные участники получат скидку 50%. Подробнее >>

Наконец, во время вечерней программы Форума вас ждёт выступление легендарной группы «Браво».

» Подробная программа на сайте Форума.
» Регистрация на участие в Форуме

Дата проведения: 9 ноября 2016.
Место проведения: выставочный комплекс «ЭКСПОЦЕНТР».

Let's block ads! (Why?)

[Перевод] Локализация инди-игр в Unity: неявные затраты

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

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

Сейчас я расскажу о моём личном опыте локализации инди-игры в Unity. Наша команда Mega Dwarf выпустила первую игру God of Word в Steam. В игре было доступно семь языков: английский, французский, итальянский, немецкий, испанский, польский и бразильский португальский. Логика выбора этих языков была следующей: английский был родным языком нашей команды, поэтому весь текст изначально писался на нём. Никто из нас не знал в совершенстве других языков, но после нескольких лет в Монреале мы немного владели французским. Остальные шесть языков мы выбрали потому, что создавали игру со словами, которая поддерживала только буквы латиницы, поэтому мы не могли бы обеспечить поддержку русского или китайского. Шесть выбранных нами иностранных языков были самыми популярными из использующих латиницу.

Самые очевидные затраты из перечисленных выше — это цена: денежная стоимость локализации игры. Сначала мы решили прикинуть, сколько слов нам нужно перевести во всей игре. У нас не было в тот момент полного списка, но мы хотели как можно точнее приблизиться к окончательному количеству, чтобы цена не оказалась для нас неожиданностью. Кроме подсчёта всего уникального текста в игре нам нужно было убедиться, что мы не пропустили hardcoded-текста. В идеале его вообще не должно быть, но у меня он всё-таки появился. Позже я расскажу об инструменте, который значительно снизил связанные с таким текстом проблемы. Затем нужно решить, будете ли вы переводить свою страницу в магазине Steam, достижения, описание игры и т.д. Об этом массиве текстов очень легко забыть, а его полный перевод может стоить довольно много. Будет более профессионально, если вы создадите качественно написанную на других языках страницу, чтобы потенциальные покупатели могли понять, о чём же игра.

Итак, прикинув в уме стоимость, мы стали сравнивать расценки различных сайтов переводов. Мы получили расценки более чем 10 сайтов локализации, а потом сравнили их по цене, срокам выполнения и отзывов клиентов. В результате мы остановились на Mogi Group, потому что он предложил нам лучшую цену, сроки и имел самые хорошие отзывы. Могу сказать, что нам тоже понравилась его результат. Он не только очень дёшев, но и перевёл около 1000 слов всего за два-три рабочих дня.

Были ещё две составляющие, связанные с локализацией, которые стоили нам денег, и обе они относились к Unity. Первая — это ассет Text Mesh Pro. В нём можно заниматься не только локализацией, но там есть и функции, чрезвычайно полезные при локализации игры. Сейчас Text Mesh Pro стоит в Unity Asset store 95$, и, по нашему мнению, вполне оправдывает свою цену. Другой ассет — это I2 Localization, специализированный инструмент для локализации. Честно говоря, я не уверен, удалось ли бы нам локализовать нашу игру без этого инструмента за 45$. Он фактически необходим для локализации любого проекта Unity.

Одна из самых больших статей расходов, связанных с локализацией игры — затраты на подгонку локализуемого текста под размер текстовых полей. В немецких и французских текстах часто получалось гораздо больше символов, чем в английских, что могло привести к выходу за границы текста или появлению различных визуальных проблем. Здесь нам и помог Text Mesh Pro благодаря его функции автоматического масштабирования текстов (Text Auto-Sizing). Она автоматически масштабирует текст, чтобы он помещался в текстовое поле, поэтому нам не пришлось волноваться об оплате работы над укорачиванием фраз или мучиться с перекомпоновкой текстовых полей и UI.

Ассет I2 Localization сам по себе удивительный инструмент для локализации, но я сосредоточусь на паре его функций, которые нам сильно помогли. Первое и главное — это возможность импорта данных непосредственно из Таблиц Google даже после выпуска игры. Это чрезвычайно полезно, потому что большинство компаний-локализаторов отдаёт результаты в файле Excel, который можно быстро перенести в Таблицы Google и импортировать все данные. Вторая функция, которую я люблю, позволяет обрабатывать hardcoded-текст в коде. Вместо того, чтобы создавать конструкции из циклов или switch, можно использовать единственную строку для перевода текста: I2.Loc.ScriptLocalization.Get("");.

Временные затраты на локализацию понятны сами по себе: как и остальные задачи при разработке, локализация требует времени, а время, как говорится — деньги. Мы не знаем точного времени в часах, потраченных на локализацию игры, но можете поверить, она заняла больше 100 часов. Подготовка таблиц Excel для компании-локализатора, внедрение полученных переводов, тестирование и отладка проблем с локализацией — всё это вносило свой вклад в затраты на проект. К тому же, обычно это довольно монотонная работа. Не забывайте, что если вы решили локализовать игру, то на эту задачу будет потрачено множество времени и энергии, которые можно было применить для реализации или улучшения других аспектов игры.

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

Во-первых, простой пример: шрифт. Наша игра основана на греческой мифологии, поэтому мы нашли очень красивый шрифт в греческом стиле. Но возникла проблема: шрифт отлично выглядел на английском, но не поддерживал многие символы других языков. Всё не так просто, как можно подумать, это не только символы с диакритическими знаками, в других языках используется другая пунктуация, нестандартная для большинства шрифтов. Для нас было открытием, что в других языках используются другие символы для цитирования или даже штрихи. Если шрифт не поддерживает их, при переводе в таких случаях появлялись огромные предупредительные знаки. В этой ситуации приходится искать шрифты, которые поддерживают все нужные символы, или даже создавать собственные. Так можно получить огромные файлы шрифтов размером 4 МБ. В результате вы можете прийти к использованию шрифта, который не очень подходит к игре, но содержит все необходимые символы других языков.

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

И наконец, сами возможности игры. У нас была мысль создать бестиарий для каждого врага в нашей игре, чтобы придать ей глубину через греческие мифы. Есть довольно много подробностей в мифах, которые обычный человек может не знать (например, что Минотавр был убит во сне, или что ящик Пандоры на самом деле больше похож на кувшин). Однако это очень большой объём текста, который при переводе будет стоить кучу денег. Поэтому нам оставалось не так много вариантов: сделать эту функцию только для английской версии и расстроить других игроков; стиснуть зубы и оплатить всю локализацию; совсем отказаться от этой функции, потому что мы не можем её себе позволить и не хотим, чтобы игра была урезанной для иностранных игроков.

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

Дочитав до этих строк, вы наверно уже думаете: «Если затрат так много, стоит ли сообще локализовать маленькую инди-игру в Unity?» Исходя из моего опыта, могу ответить утвердительно. Это не очень сложно, просто занимает много времени. Это даже не очень дорого (в среднем 10 центов за слово), плюс два вышеупомянутых ассета примерно за 150$. На самом деле, одна из самых важных целей создания игр для нас в том, чтобы люди играли в них и получали удовольствие. Так почему бы не потрудиться и не позволить насладиться ею как можно большему количеству игроков?

Наша игра God of Word уже выпущена, и хотя я не могу назвать точные цифры продаж, я покажу процентное соотношение всех продаж по странам.

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

Одна из самых сложных задач для независимой игровой компании — быть замеченной. И локализация игры — отличный способ получить такую известность. Я просмотрел 100 случайных новых инди-игр в Steam, чтобы проверить, какие из них локализованы и на какие языки. Результаты были следующими:

Как видите, только 25% новых инди-игр в Steam локализовано на несколько языков, включая английский. Это значит, что когда не владеющие английским игроки ищут игры на своём языке, у них будет гораздо меньший выбор для покупки. И если внимательно посмотреть на список конкретных доступных языков, выяснится, что из 100 инди-игр ни на одном языке нет больше 15 игр. Инди-игре не так легко выделиться, и локализация игры определённо даёт вам преимущество в этом.

Но учтите, что быть замеченными не значит только то, что игроки смогут найти вашу игру в Steam. Ещё один важный фактор — заставить прессу заинтересоваться игрой. При разработке God of Word мы отправили 64 писем на различные сайты обзоров и видеоигр. И 33% из этих 64 сайтов, были на иностранных языках: французском, итальянском, немецком, испанском, бразильском португальском и польском (потому что эти языки поддерживает наша игра). Это огромный рынок, незатронутый нелокализованными играми.

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

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

Спасибо за прочтение, если у вас есть вопросы о локализации, разработке игр или о God of Word, оставляйте комментарии или связывайтесь с нами напрямую, мы будем рады пообщаться.

Вкратце и по пунктам

• Соберите как можно более полные тексты, в том числе страницу в Steam, прежде чем узнавать расценки компаний-локализаторов.
• Сверьтесь с опросом о конфигурации компьютера в Steam для получения свежей статистики о локализации.
• Text Mesh Pro и I2 Localization — отличные ассеты Unity для локализации.
• Локализация игры стоит денег, времени и влияет на качество игры.
• Локализация, с учётом тестирования, наиболее вероятно займёт более 100 часов.
• Не все шрифты поддерживают символы из других языков.
• Только 25% новых инди-игр в Steam локализовано на английский и другие языки.
• Не забывайте ориентироваться на иностранных игроков в YouTube и прессу.

Let's block ads! (Why?)

[Перевод] Дональд Кнут: про ассемблер, транслятор и грамотное программирование

Михаил Грачев: «Информация — это сила в автогонках»

Если вы увлекаетесь автогонками, то наверное слышали о TCR International Series. И если вы знаете о TCR International Series, то наверняка слышали и о шведской команде WestCoast Racing. А если вы знаете о WestCoast Racing, то вам знакомо имя гонщика Михаила Грачева. И если вы слышали о Михаиле Грачеве, то понимаете, что это один из лучших гонщиков серии — в этом сезоне он уже одержал четыре победы.

Спонсором Михаила Грачева в малазийском раунде TCR International Series, прошедшем одновременно с Гран-при Малайзии Формулы 1 на трассе Сепанг стала компания Acronis. Вот что рассказал сам гонщик о роли данных в автоспорте и важности использования самого быстрого решения для защиты этих данных.

Михаил, не могли бы Вы рассказать нам о роли информационных технологий в TCR?

Успех в TCR International Series, как и в других современных гоночных состязаниях,  во многом зависит от собранных на трассе данных. Информация — это сила в автогонках. В нашей команде около 20 человек — это гонщики, механики и инженеры, которые рассчитывают наши следующие шаги на основе информации, собранной в ходе гонки.

Большая часть этих данных поступает от телеметрических датчиков, установленных в наших автомобилях. В моей Honda Civic Type-R TCR более 50 таких датчиков. Каждый датчик запускается автоматически сразу же, как только я завожу свой автомобиль. После окончания гонки наши инженеры переносят данные из автомобиля на компьютер для их обработки и анализа. Кажется, что 50 датчиков — это немного, но они генерируют огромное количество данных!

Все системы в рабочем состоянии. Пять минут до гонки.

Передаются ли также телеметрические данные Вашим инженерам непосредственно во время гонки?

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

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

Мы используем программы от MoTeC Engine Management & Data Acquisition Systems (управление двигателем и системы сбора данных). Одни из них работают в автомобиле, другие — на компьютере. Это отличныe инструменты телеметрического анализа. У них много каналов сбора и обработки различных типов данных в зависимости от потребностей.

В каких телеметрических данных заинтересованы лично Вы, как гонщик?

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

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

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

Готовы к гонке. TCR International Series на трассе Сепанг в Малайзии.

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

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

Гонка начинается. Инженеры WestCoast Racing заняты делом.

Если TCR International Series поддерживают гонки Формулы 1, пользуетесь ли Вы на гоночной трассе какими-либо стандартными услугами FIA?

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

Каков тип ИТ-инфраструктуры в вашем гараже?

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

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

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

Михаил Грачев и его Honda Civic Type-R TCR.

P.S. Герои Формулы 1 в МФТИ!

17 ноября состоится встреча с пилотом «Формулы 1» Даниилом Квятом, одним из самых молодых гонщиков команды Scuderia Toro Rosso, и руководителем команды Францем Тостом. Такой подарок к 70-летию своей альма-матер и всем физтехам решили сделать выпускники МФТИ Сергей Белоусов (генеральный директор компании Acronis) и Станислав Протасов (сооснователь и глава разработки ПО компании Acronis).

Во время уникального public talk Сергей и Даниил расскажут о роли современных информационных технологий в мире «Формулы 1», технологиях, которые пришли в нашу жизнь из автоспорта и будущем автомобилестроения и ИТ. А также о том, какую роль во всем этом может играть блокчейн уже в ближайшем будущем.

У гостей будет возможность почувствовать себя пилотом «Формулы 1». В холле КЗ будут установлены симуляторы боевых болидов Scuderia Toro Rosso, на которых все желающие смогут испытать невероятные эмоции от скоростей на трассах по всему миру, будь то Сингапур, Малайзия, Токио или Сочи.

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

Приходи, попробуй свои силы и узнай, что современные гонки и ИТ ближе, чем ты думаешь!

» Встреча состоится 17 ноября 2016 г в КЗ МФТИ.
» Начало мероприятия в 18:00 (согласовали, ставим чуть раньше, чтобы собрались люди).
» Вход свободный, необходима предварительная регистрация.
» Но не забывайте, что число мест по приглашениям в зале ограничено.

Оригинал статьи

Let's block ads! (Why?)

Погружение в технологию блокчейн: Децентрализованная нецензурированная система доменных имён

Продолжаем цикл статей, посвященных технологии блокчейн. Прошлая статья из серии «Секреты EmerCoin» завершилась кратким описанием NVS (Name-Value Storage) – распределённым хранилищем записей на базе блокчейна Emer. Подробности об этом вы узнаете в материале ниже.

Цикл статей «Погружение в технологию блокчейн»

1. Серия материалов, посвященных технологии Emer:
1.1. Секреты EmerCoin.
1.2. Децентрализованная нецензурированная система доменных имён.
1.3. Loading…
2. Быстрые и безопасные транзакции.
3. Экосистема цифровой стоматологии.
4. Loading…

Введение

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

За основу NVS был взят код из Namecoin, в котором существует подобное хранилище для поддержки распределённой доменной зоны *.bit. Но если хранилище от Namecoin предназначено только для обслуживания единственной доменной зоны, а для загрузки других типов данных надо предпринимать дополнительные шаги, то NVS сразу было реализовано как хранилище данных общего назначения, используя которое можно создавать различные распределённые сервисы.

Что такое emcDNS и зачем он нужен

Исторически первым сервисом EmerCoin стал сервис доменных имён, похожий на emcDNS от Namecoin. По мере роста атак на классическую доменную систему как со стороны криминала, так и от локальных властей, такой сервис становится всё более востребованным. Подробнее об этом можно прочитать здесь.

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

В системе emcDNS доменной записью, также как любой другой NVS-записью, может управлять только её владелец, точнее – владелец кошелька, в котором находится данная запись. Только он может её изменить или удалить. Следует учесть, что так как запись находится в блокчейне, её копии находятся в каждом Emer-узле. То есть каждый узел содержит информацию обо всех NVS-записях, включая и доменные. Это позволяет делать поиск такой записи локально, не запрашивая внешние сервера, что приводит как к высокой скорости разрешения доменных имён, так и к высокой надёжности и безопасности – ваш провайдер не узнает, какие сайты вы сейчас ищете, особенно если доступ к сайтам будет по https.

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

— Поздравляем! Вы изобрели файл hosts!
— Да. В каком-то смысле так и есть. Но только наш файл hosts:

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

Отличия от Namecoin

При проектировании сервиса подход Namecoin был пересмотрен, и был внесён ряд улучшений, которые сделали этот сервис более привлекательным и практичным. Рассмотрим их детально.

Несколько доменных зон вместо одной

Если Namecoin обслуживает только фиксированную доменную зону *.bit, аналогичный сервис Emer позволяет обслуживать несколько зон одновременно, причём новые зоны вводятся просто записью в config-file. Это открывает возможности создавать на базе emcDNS собственные «ведомственные» доменные зоны, которые будут распознаваться только соответственно сконфигурированными Emer-узлами. В настоящее время система обслуживает четыре публичные доменные зоны, доступные через сервера OpenNIC:

• *.coin – основной альтернативный домен, в первую очередь связанный с крипто-монетами и прочими деньгами;
• *.emc – домен для сервисов, связанных с EmerCoin;
• *.lib (от liberty и library – для политических движений за всё хорошее, против всего плохого) – для библиотек различного содержимого;
• *.bazar – для различных торгово-обменных сайтов.

Возможность задать срок аренды записи

В отличие от Namecoin, где срок аренды записи составляет примерно 200 дней, и её надо регулярно продлять, в NVS можно указать срок аренды, и он может составлять столетия. Более долгий срок аренды будет стоить дороже, но ненамного. Этот подход позволяет упростить администрирование, и снижает риск потери контроля над записью, который возможен в случае истечения записи и перехвата её другим пользователем сети.

Возможность удалить запись

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

Встроенный DNS-server rfc1035

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

Каждый кошелёк EmerCoin имеет встроенный DNS-сервер, который обрабатывает стандартные запросы интернет-формата rfc1035, и отвечает в том же формате, который используется во всем Интернете. Это позволяет говорить о подлинной децентрализации доменной системы, когда каждый кошелёк является DNS-сервером, а не только выделенные сервера-шлюзы. Эта стандартизация также облегчает интеграцию emcDNS с другими подсистемами.

Управление поддоменами

Этот момент очень важен в «плоской» доменной сети, в которой отсутствует древовидная структура серверов, обслуживающих ту или иную доменную зону. Рассмотрим атаку типа «захват поддомена».

Представим, что отсутствует механизм защиты или управление поддоменом, и существует сервер victim.emc. Владелец домена создал ещё одно имя, www.victim.emc, которое назначил на тот же сервер. Однако злоумышленник может создать имя www1.victim.emc, и назначить его на свой вредоносный сервер. Формально, это два разных имени, которые никак не связаны. Однако в соответствии с парадигмой построения Интернет-имён и классической сети DNS, пользователь своё доверие к серверу victim.emc перенесёт и на www1.victim.emc, вследствие чего, например, может «подарить» злоумышленнику свой пароль.

На момент анализа кода Namecoin, в не было механизма управления поддоменами. То есть, для создания и управления поддоменами сайт должен держать собственный NS-сервер, который и разрешает эти поддомены. Все записи доменов 3-го уровня данной системой просто игнорируются.

В системе emcDNS существуют два правила:

1. Все запросы на доменное имя любого уровня, кроме «разрешённых исключений», разрешаются как доменные имена второго уровня. То есть, если запись victim.emc не содержит исключений, то запросы к любым поддоменам будут в ней разрешаться как к victim.emc. Например, запрос на разрешение имени hey.give.me.victim.emc будет полностью эквивалентен запросу на имя victim.emc.

Если в value имени указан специальный тэг SD, то его значение интерпретируется как список разрешённых исключений, которые обслуживаются системой. Рассмотрим в качестве примера emcDNS-запись библиотеки Флибуста:

"name" : "dns:flibusta.lib",
"value" : "A=81.17.19.227|SD=static,cn|TXT=Flibusta Library",

Здесь мы видим тэг SD, содержащий два исключения – static, cn. Значит, что система emcDNS разрешает имена static.flibusta.lib и cn.flibusta.lib, а не редуцировать их до flibusta.lib. Записи этих имён также могут содержать тэг SD, и таким образом, можно будет строить доверенные доменные имена любого уровня. Не доверенные записи будут редуцированы до имени второго уровня.

Полезные ссылки о практическом применении

1. В настоящее время, эта система доменных имён используется рядом онлайн-библиотек и торрент-трекеров. Подробнее можно узнать здесь.
2. Краткое описание с примером и картинкой, как создать запись.
3. Полное же описание системы.
4. Чтобы стать клиентом системы, можно либо подключиться к любому серверу OpenNIC, либо же на своей локальной машине или в локальной сети развернуть шлюз в emcDNS. Инструкция о том, как подключить доменные зоны emcDNS через OpenNIC. Этот способ не требует от вас установки ни кошелька EmerCoin, ни каких-либо внешних программ или плагинов. Но недостатком этого способа является использование внешнего DNS-сервера, что частично дискредитирует идею полной децентрализации.
5. Описание других способов подключения к системе, с полным функционалом. Смотрите раздел Integration into a regular DNS tree. Рекомендуемые рецепты заключаются в том, что в локальном компьютере или локальной сети устанавливается кошелёк EmerCoin, и создается точка сопряжения, которая «смешивает» доменные зоны ICANN и emcDNS. Сопряжение производится посредством любой DNS Cache программы. В примерах приведены BIND, DNSMASQ, Acrylic.

Let's block ads! (Why?)

Интервью с Иваном Козловым, вице-президентом мобильных продуктов Aviasales.ru

Мы начинаем публиковать бизнес-интервью с экспертами из мобильной индустрии о продуктах, мобильном продвижении, аналитике, user acquisition и бизнесе в целом.

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

Привет! Хочется начать неожиданно. Мы много знаем про Aviasales, но у вас же есть и второй продукт по бронированию отелей — Hotellook. Про него информации доступно мало. Расскажи, что с ним? Какие отличия и что общего у этих двух продуктов?

Говорим про Hotellook меньше, так как сам проект на данный момент меньше. Сейчас идет фаза активного роста, за это лето мы очень сильно выросли. Принципиальное отличие от Aviasales всего одно: Hotellook —про отели, а Aviasales —про билеты. В остальном все схоже: это тот же поиск, с теми же проблемами, что и в билетах. Но есть несколько позитивных отличий: в отелях выше маржинальность в 3-4 раза, и это международный проект, так как все наши партнеры: Booking.com, Agoda.com, Hotels.com и др. — международные игроки, которые способны продавать отели по всему миру, а не только в России. Выходить на зарубежный рынок с Hotellook намного легче чем с Aviasales.

То есть, Hotellook уже готов, чтобы продвигаться за рубежом?

Продукт готов достаточно давно, и сейчас доля зарубежных продаж составляет около 30-35%.

Ты имеешь ввиду зарубежных покупателей или бронирование зарубежных отелей?

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

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

Да, верно, практически все это сделано с помощью органики: ASO и прочего.

Зарубежные продажи Hotellook

А вы с самого начала планировали, что у вас продукт за рубежом будет так востребован?

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

А вы не страдаете от того, что у бренда Hotellook пока плохая узнаваемость на фоне грозного во всем мире Booking-а? С Aviasales история другая, этот бренд в России знают все, его продвигать легче. Насколько это меняет картинку для вас?

Да, Booking.com это, конечно, глобальный гигант, практически, синоним понятия «отель», и чрезвычайно сложно соперничать с ним, учитывая бюджеты, которые там есть. Но у нас есть некоторые УТП. Например, Booking.com с точки зрения своей ценовой политики не всегда выгодный сервис, и наши пользователи это понимают, поэтому пользуются нашими услугами. Что касается Aviasales, бренд, действительно, очень известный, и, с одной стороны, продвигать его легче, а с другой, ты сам прекрасно знаешь, что наш оффер выгорел уже несколько раз, и находить под него мобильный трафик в России с каждым днем всё сложнее и сложнее.

Рост установок Hotellook за 2016 год

Да, это правда. А если говорить о маркетинговых метриках, ты достаточно много говорил, что в Aviasales тяжело посчитать unit-экономику, и пользователь не сразу делает покупку после установки. В Hotellook все примерно также, или есть свои особенности?
Примерно все также: время осуществления первой транзакции тоже самое, что и в авиабилетах, кардинальных отличий нет. С точки зрения географии все тоже самое, что и в авиабилетах: топовые города поиска по России — Москва, Санкт-Петербург и Сочи, но есть нюанс — маржинальность существенно больше.

Ты как-то говорил, что в Aviasales для вас считается нормальным, если за год с платного трафика вернулось 50%, с учетом всех возможных потерь. В Hotellook примерно также?

Нет, в Hotellook лучше. Тут немного сложнее считать, так как в авиабилетах все просто: купил авиабилет, прошла транзакция, букинг есть и партнеры платят в течение отчетного периода. В отелях все по-другому, там букинг не предполагает получения денег сразу, так как возможна и бесплатная отмена, много различных нюансов, а деньги от партнеров мы получаем только через какое-то время, после того, как гость выехал из отеля, поэтому экономика считается по-разному. Но, в целом, то, что мы видим по марже, unit-экономика у Hotellook лучше.

Aviasales установлен в каждом шестом смартфоне в России

Следовательно, так как отели продавать выгоднее, вы агрессивно стараетесь допродать их тем, кто покупает билет на самолет. Насколько эффективно вам это удается? Легко ли перетянуть юзеров на Hotellook? Много ли пользователей злятся за это на вас?

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

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

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

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

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

А кто вообще прибыльный сейчас на рынке продаж авиабилетов и отелей, ну, естественно, кроме вас?

Провокационный вопрос :-). Честно, я не знаю, судя по всему, игроки которые присутствуют на рынке 3-5 лет смогли нащупать какую-то нишу, в которой могут работать достаточно успешно, по крайней мере, без убытков. С моей стороны, называть конкретно компании было бы не корректно, но прибыльные игроки однозначно есть.

Слушая тебя, кажется, что рынку тяжело. Ну а что делать travel-стартапам, который хотят запустить метапоиск? Можно что-нибудь заработать?

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

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

Push-уведомления работают. Вопрос в том, «как просить» или «что посылать». В рамках Aviasales (в Hotellook нет push-уведомлений) мы аккуратно спрашиваем пользователя о том, хочет ли он получать уведомления. Мы отправляем ему информацию об изменении цен по тем маршрутам, которые ему интересны. Push до сих пор работает, просто конверсия от него никогда не была колоссально высокой. Открытие приложений есть, де-факто Retention увеличивается, но прямой связи с конверсией и покупкой практически не наблюдается.

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

Конечно, мы пробовали мобильный ретаргетинг, так как с нашим текущим install base эта вещь абсолютно необходимая. Что-то получается лучше, что-то хуже, пока самой основное беспокойство связано с тем, что лучшая эффективность получается на очень маленьком объеме, и как-то разогнать эту историю с ходу у нас не выходит. Но мы активно работаем над этим. Сейчас обдумываем ретаргетинг в Facebook, у нас будет пара запусков в ближайшем месяце, и мы рассчитываем, что их инструменты позволят привлечь старых пользователей.

Круто! Мы в Mobio очень верим в мобильный ретаргетинг и в бете с некоторыми клиентами уже тестируем наш новый продукт GetLoyal, минутка рекламы :-). Но вернемся к вопросам. В Aviasales мобильное подразделение, по сути, отдельный бизнес-юнит. У вас даже офис находится отдельно. Достаточно много компаний так делают: Яндекс и Яндекс Такси, Mail.ru и Maps.me. Вам это как-то помогает? Какие есть минусы у такого подхода?

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

Расскажи про команду: много ли людей работает в питерском офисе, что это вообще за люди, что они делают

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

А как устроены процессы? Есть ли циклы разработки, еженедельные совещания?

Все зависит от продакт-менеджера и его договоренности внутри команды. Какие-то команды работают по Scrum, какие-то по Kanban. Мне по большому счету все равно, главное — результат. А так, у нас есть все стандартные атрибуты разработки: планирование, перспектива, демо, ежедневные короткие планерки, всё есть.

Ты сам лично насколько погружен в процесс?

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

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

Сложно ответить на этот вопрос. Все-таки я пока не очень долго работаю, всего 4 года :-) Продуктов у нас больше десяти. Они совершенно разные, с разной целевой аудиторией, скучать просто некогда. На самом деле за 4 года мобильная индустрия сильно изменилась, был совершенно другого рода рынок, и участвовать в его трансформации чрезвычайно интересно. Если бы я работал в вебе, я бы, наверное, заскучал. Эта система уже давно устоялась, какие-то изменения происходят, но с небольшой динамикой.

Напоследок, что советуешь почитать, людям интересующимся индустрией? Что сам читаешь?

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

Спасибо, что согласился пообщаться. Ждем от Aviasales и Hotellook громких анонсов!

Let's block ads! (Why?)