-Поиск по дневнику

Поиск сообщений в rss_rss_hh_new

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 51

Habrahabr/New








Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://habrahabr.ru/rss/new/.
Данный дневник сформирован из открытого RSS-источника по адресу http://feeds.feedburner.com/xtmb/hh-new-full, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

От b2b-приложений к массовому сервису по всему миру

Пятница, 16 Июня 2017 г. 14:18 + в цитатник

image


Привет, Хабр! Меня зовут Евгений Лисовский, я руковожу проектом MAPS.ME — это международный проект, интересный и очень амбициозный. Наша задача — конкурировать с Google, Apple и несколькими компаниями второго эшелона. Сегодня я кратко расскажу о своём трудовом пути, чтобы затем подробнее остановиться на самых интересных этапах.


До института я подрабатывал, собирал компьютеры на заказ. А свой компьютер у меня появился в 1995 году, в 13 лет — спасибо родителям, это было реально очень круто. В институте я начал сам изучать PHP, MySQL, соорудил собственный движок для интернет-магазина. Сделал три сайта, брал по 300 долларов за каждый. С 2004 года я работал в международной компании Radmin.com, которая создаёт b2b-продукт для удалённого управления компьютерами, там я провёл шесть лет. Потом ломанулся в стартапы: KupiBonus, детские товары BabyBoom. Там было интересно! Важны не только успешные проекты, но и фейлы: надо хорошо анализировать, почему они происходили. Потом был Litres. Очень интересный бизнес — продавать электронные книги при уровне пиратства 96 %. В 2015 году мы заработали 15 млн долларов, с 2011 года выручка выросла в 18 раз. Затем я вместе с партнерами запустил собственный проект MoikaMoika.ru. Не то чтобы основатели сразу стали миллионерами, но это интересный опыт. Проект жив и развивается. А дальше про всё это — более подробно.


Институт


Я писал на С++ программную часть дипломной работы, а мой партнёр делал аппаратную часть. По сути, печатную плату. Прибор был очень простой: снимал ЭКГ с трёх отведений — правой руки, левой руки, левой ноги — и формировал электрокардиограмму. Она снималась простым аналого-цифровым преобразователем, плюс частотный модулятор на звуковой частоте, и передавалась через звуковую плату компьютера. Поскольку звуковая карта есть во всех компьютерах, то это самый простой способ ввести данные в цифровом виде. Потом я программно снимал огибающую, которая и представляет собой ЭКГ. По высоте зубцов и расстоянию между ними можно определить разные типы заболеваний, отметить определённые паттерны, сравнить их с базой и сделать вывод о диагнозе.


image


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


Первая компания


После института я начал искать работу веб-программистом, программистом на PHP, MySQL или сисадмином. Для последней должности навыков не хватало, я даже собеседовался в Лабораторию Касперского, но это оказалось очень сложно. Да и с PHP-программированием было не особо. Я пришёл, а мне говорят: вот блокнот, напиши нам плагинатор. И ты думаешь: зачем блокнот, когда есть DreamWeaver, в котором все теги подсвечиваются.


Потом меня пригласили в софтверную международную компанию Radmin интернет-маркетологом. У меня был свободный английский. Погоняли всякие IQ-тесты, позадавали вопросы, я на всё ответил, и мой будущий руководитель говорит: «Я вижу, что ты нормальный парень, но слишком молодой. Если сразу во всё быстро вникнешь и за шесть дней вольёшься в работу, то мы тебя берём. Ты маркетингом занимался?» Я думаю: сайты делал, SEO делал — ну конечно, маркетинг — это моё вообще, любимое. Он: «Google Adwords знаешь?» А я в контекстной рекламе — вообще ни в зуб ногой. Но мне деньги были очень нужны, у меня только сын родился. Говорю: «Ну конечно!»


Так я и устроился на работу. Мне повезло. Этот опыт дал мне, инженеру, огромный профит. Мне стало очень легко общаться с разработчиками. Знаете, есть классическое противостояние между разработчиками и маркетологами. Приходит маркетолог, говорит: сделай мне такую красивую красную кнопку, чтобы всё хорошо работало. А инженеры отвечают: да иди ты куда подальше… И всё, начинается обособление. А когда ты приходишь и говоришь: чувак, всё нормально, я тоже кодил на С++, то IT-директор сразу выдыхает с облегчением. И становится гораздо проще общаться. Ведь практически все современные IT-проекты — это симбиоз разработки и маркетинга продукта, они неотделимы друг от друга. И когда их искусственно разделяют, то получается не очень хорошая ситуация.


В этой компании я работал с контекстной рекламой ещё в 2004 году, когда в России было очень мало интернет-маркетологов. Очень интересный опыт. Я ездил по разным международным конференциям, где уже тогда обсуждалось тестирование лендинговых страниц. В США и Европе А/В-тестирование, оптимизация конверсий и прочие методики были отработаны на высшем уровне. До нас это докатывалось с задержкой примерно в пять лет.


Я не могу сказать, что сделал много за время работы в Radmin. Уйдя в стартап KupiBonus — купонный проект, — я за полгода сделал больше, чем за шесть лет в предыдущей компании. Возможно, динамика жизни в интернете была немного ниже или я боролся с собой: мне казалось, что пора уходить, но я оставался, потому что это хорошая надёжная компания. Я думал: приду на позицию интернет-маркетолога, дорасту до маркетинг-директора — и вот оно, счастье. На самом деле счастье — это достижение целей в создании каких-либо продуктов.
В кризисный 2009 год мне удалось перепозиционировать продукт. Я объездил всю Россию, все федеральные округи, провёл большую работу с продажниками, которые потом распространили нашу систему оптимизации бизнес-процессов по всей стране. И в итоге в кризисный год получилось поднять выручку в России на 30 %.


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


Первые стартапы


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


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


Было очень приятно, когда президент компании, француз, бывший (до 1998 года) владелец OZON.ru подходил и говорил: Евгений, маркетинг — это ключевое. Это так. Я не мог заснуть ночью, пока не придумывал, как бы выполнить план. А план у нас был конский. Я пришёл из компании с бюджетом в 100 тыс. долларов в год в купонный бизнес с бюджетом 200 тыс. евро в месяц. И нам крайне не хватало лидов.


Затем был проект BabyBoom — классический ретейл. Мой совет: не работайте с неподходящими людьми, увольняйте слабых, нанимайте сильных. Например, в BabyBoom и Litres я собирал команды с нуля и зачастую делал выбор в пользу, может, не самого опытного человека, но готового быстро обучаться. В маркетинге нет ничего суперсложного, всё можно освоить за месяц, если нормально подойти к процессу. В итоге гораздо проще выучить людей, чем нанять очень опытных и дорогих. Также у меня был пунктик, чтобы это была именно моя команда.


Но тут есть одна проблема. Boss Cap — Friend Cap. Это то, чему я научился в BabyBoom, стартапе по продаже детских товаров. Сначала мы подняли 1 млн долларов инвестиций, начали увеличивать оборот, выросли в пять раз. Но логистика в детских товарах очень сложная: часто встречаются крупногабаритные товары. Хотя средний чек достаточно большой, маржинальность доходила до 30 %, однако крупногабаритные товары просто убивали бизнес-модель. Логистика сжирала всю маржу. Добавьте сюда далеко не полную информацию об остатках на складе. К сожалению, у нас не получилось закрыть второй раунд инвестиций из-за слишком большого количества рисков. В итоге проект развалился, и я пошёл в Litres.


Growth Hacking


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


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


image


Команда — это основа успешности проекта. Ключевая компетенция руководителя — подбор сотрудников. Я сам искал людей, не прибегая к услугам кадровиков. Я тратил много времени, но оно того стоит. Как обычно я выбирал работников? Я смотрел в их добрые глаза и рассказывал о проекте. Представьте: 2011 год, электронные книги — кто их покупает? Это как продавать мороженое эскимосам. Я рассказывал, что в США электронные книги занимают уже 20 % всего книжного рынка, и сейчас мы будем круто расти. Если у собеседника расширяются глаза, он наливается румянцем — значит, правильный человек, ему это интересно.


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


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


image


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


Во время работы приходится очень много анализировать. Если человек не умеет пользоваться Excel — скорее всего, у него несистемное мышление, а это значит, что мы не сработаемся. Я не требовал от людей технического образования, главное, чтобы кандидаты понимали базовые принципы. Один пример. В BabyBoom я нанял парня на партнёрские программы, заниматься женскими форумами. Я ему говорю: есть сотни сайтов, давай выберем самые крупные, отранжируем. Сделай мне табличку — и посмотрим, как будем дальше работать. Он пошёл думать, с утра приносит табличку. А в ячейках с рейтингом записаны не цифры 4/5, а «четыре из пяти баллов». Я говорю: а как ты автофильтр включишь? Это же просто символы, а не цифры. Но он меня даже не понял.


Моя ошибка: я недостаточно подробно его расспрашивал на собеседовании. После этого я всем кандидатам давал такое задание: «Представьте, что вы — менеджер партнерской программы в Litres. Существует 10 000 сайтов о книгах. Ваша задача — запартнёриться со всеми этими сайтами. Как вы будете действовать?» Мне важно оценить, как человек понимает бизнес-процессы. Мыслит ли он структурно: «Занесу в табличку, отсортирую по убыванию трафика, возьму топ-20, которые, скорее всего, будут генерировать 80 % трафика, и начну в первую очередь с ними работать». По сути, Excel и Google Docs Spreadsheets — это своеобразные CRM. У меня всё на них сделано и отработано на куче стартапов, никакая система управления проектами не нужна.


Создавая у себя в голове структуру команды и нанимая людей, я всегда давал им понять, где они могут оказаться. Например, кандидату, который пришёл на партнёрские программы, я сказал: «У меня есть план структуры компании на два года вперёд, и здесь есть позиция — руководитель партнёрских программ. Я ничего не гарантирую, но если ты будешь активно расти и развиваться, ты сможешь быть там». В итоге он действительно занял эту должность. И мне это очень приятно. Я люблю, когда сотрудники растут. Также я открыто объясняю, что карьера — это не безоблачный полёт, когда всё ровно и гладко, каждый может забуксовать. Но либо человек движется вперёд, либо мы расстаемся. Есть два состояния: падение и рост. Без вариантов.


О продукте


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


Понадобилось это как-то продвигать. У меня не было опыта в мобильном маркетинге, и я договорился о взаимном консалтинге с компанией Alawar Entertainment, с подразделением мобильных игр. Я консультировал их по классическому вебу, а они меня — по мобильному сегменту. Так я набрался знаний, и мы начали продвигать свою читалку. В 2012 году выручка выросла на 120 %. Тогда в России мало кто занимался мобильным маркетингом так же активно. Мы просто скупали кучу трафика. Как только в AdMob, впоследствии Facebook, появилась реклама, мы были одними из первых в России, кто начал её активно скупать.


Если бы мы в 2011 году решили сначала сделать суперклассный продукт с кучей возможностей и запустили бы его на год позже, то мы бы прозевали решающий 2012 год. Когда я пришёл в Litres, то один из моих знакомых вёл сделку с Dream Industries. Проект Bookmate. И в конце 2011 года эти ребята подняли 30 млн долларов. А у меня бюджет на маркетинг в 2012 году был 9 млн рублей. Как вы думаете, какие у меня появились мысли? А я проработал в Litres только месяц. Прибегаю к генеральному директору: «Серега, что делать?» — «Ну, работать».


Как мы работали? Как лошадям закрывают глаза шорами, чтобы они не видели, что происходит вокруг, так и мы просто понеслись вперёд. Прошёл год, оборачиваемся — а что-то и не видать никого сзади. Time to Market — вовремя сделанный продукт и хороший маркетинг решили судьбу проекта.


image


Само ничего не взлетит. Многие думают, что достаточно сделать превосходный продукт, выложить в App Store или Google Play, и оно попрёт как на дрожжах. Это уже давно не работает. Сейчас необходим системный отлаженный маркетинг, привлечение трафика с кучи разных каналов, анализ конверсий и когорт, внутренняя аналитика. Не надейтесь, что кнопочка «Рассказать друзьям» даст вам мощнейший виральный эффект.


Системный маркетинг


image


Здесь отображён базовый подход к маркетингу. Есть показы, клики, установки и т. д. Допустим, вы покупаете трафик на Facebook. Думаете, что если поставить CPI 50 центов, то Facebook принесёт вам кучу установок. Такого не будет, потому что Facebook берёт на себя все риски за плохой креатив, за плохой лендинг, за плохие описания, низкий рейтинг и т. д. Естественно, что при этом он будет завышать планку. Покажу на примере контекстной рекламы. Проводя собеседования на должности в маркетинге, я задавал простой вопрос: «Объясни, как работает контекстная реклама?» Кандидат говорит: «Вот, есть система ранжирования…» — «А зачем она нужна?» — «Чтобы рекламодатели нормально друг с другом, чтобы была честная сортировка…» Всё не так.


Представьте, что я — коммерческий директор Яндекс.Директа. Моя задача — увеличить выручку на тысячу показов с контекста. Каким KPI можно это выразить? И CPM, выручка на тысячу показов. Как его максимизировать? Алгоритм ранжирования в Яндекс.Директе — это формула, максимизирующая выручку на тысячу показов, и ничего более. Это не система, которая позволяет уравнять в правах рекламодателей. Это система, максимизирующая выручку. Там есть несколько факторов: CTR, CPC. Если у тебя высокий CTR, то на сторону рекламодателя идёт больше трафика, а значит, больше денег.


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


Напоследок приведу пример того, что мы делали в купонных системах. Это из разряда growth hacks, как можно хакнуть систему. Тогда на рынке была компания Darberry, потом её купил «Групон». У них было размещение на Mail.Ru Group за 300 тыс. рублей в день. Очень дорого, как мне тогда казалось. Такими бюджетами я управлял впервые. CTR был достаточно низкий, а стоимость за лид получалась 86 рублей, хотя по модели она была около 50. Дороговато, ещё и женская аудитория. Что делать? У меня был сотрудник, который отвечал за макеты баннеров. Он в шесть вечера часов заявляет, что ему пора бежать на учёбу. А мне до одиннадцати надо отправить макет. Я говорю: «У меня кампания стартует, а ты уходишь». — «Ну, сорян». Потом я его уволил, но в тот вечер пришлось сесть и подумать, как быть.


Я просто открыл Paint и нарисовал баннер, написал на белом фоне «–90 %», максимально растянув на весь экран, без окантовки. Не знаю, как тогда это пропустили. Позже, кстати, запретили делать баннеры без окантовки и сделали заливку градиентом. Но тогда это прокатило. Я отправил. Есть книга Стива Круга «Don’t make me think». Надо всё упрощать — чем проще, тем лучше. Благодаря этому примитивному баннеру CTR вырос более чем в восемь раз. Естественно, конверсия в регистрацию упала, но на выходе я всё равно получил стоимость за лид в 34 рубля.


Правда, потом к нам пришла юридическая служба Mail.Ru Group и сказала, что у вас тут написано «–90 %», а на сайте такой акции нет. Действительно, не было. Потом мы начали подбирать акции под такие большие размещения.


Свой стартап


В 2014 году мы с партнёрами решили запустить стартап MoikaMoika. Это запись на мойку без очереди. И звучит неплохо, и рынок приличный. Действительно, есть такая проблема — очереди на мойку. Здесь существует определённая сезонность, но мы рассчитали бизнес-модель, всё прикинули. В 2014 году начали разработку, в феврале 2015-го выпустили на iOS и Android и взялись за маркетинг. Я придумывал всевозможные креативы. Потом, кстати, их блокировали, но какое-то время они работали.


image


Вот пример того, что если поработать над креативом, над CTR, эффективностью, если сделать биндинг по CPI, то результат будет гораздо хуже.


Начальный капитал стартапа — примерно по 300 тыс. с каждого из основателей. Пример расчёта бизнес-модели MoikaMoika с когортами, конверсиями, примерным подходом:


image


MAPS.ME


Что касается MAPS.ME, то сегодня проект где-то на шестом месте в мире по размеру аудитории, при этом мы не пытаемся быть Google Maps, у нас своя ниша и свои пользователи. Сейчас мы — карты для путешественников: лёгкие, быстрые и надёжные, созданные для работы без интернета. В этом сегменте мы лидеры, поскольку основная масса навигаторов «старой гвардии» вообще не рассчитана на пешеходную навигацию, а туристов, передвигающихся без автомобиля, — около 70 %. По оценкам Google, 40 % путешественников предпочитают использовать офлайн-карты.


image


Именно за этот сегмент рынка мы боремся. В год в мире порядка 1,3 млрд путешественников, нам их вполне достаточно :) Однако перед нами стоит задача бороться также за ежедневное использование MAPS.ME, для чего мы активно работаем над функционалом, который позволит лучше удерживать аудиторию. К примеру, в декабре 2016 года мы запустили пробки по 38 странам мира, что позволило поднять уровень дневной аудитории среди автомобилистов и конвертировать пользователей из туристического сценария использования в ежедневный. При этом мы внедряем в весь добавляемый функционал простоту и надёжность: пробки эффективно сжимаются и потребляют в четыре раза меньше мобильного трафика, чем приложения конкурентов, что позволяет использовать нашу навигацию с пробками даже в роуминге. Также весь функционал — поиск, авто-, вело- и пешая навигация, закладки, заметки — работает без интернета. Это не значит, что наши пользователи вообще обходятся без него: по нашей статистике, более 80 % подключаются к интернету в течение дня, что позволяет нам зарабатывать на партнёрских программах с туристическими гигантами вроде Booking.com, с которыми мы за полгода вошли в топ-10 партнёров по объёму бронирований. Интеграция Booking.com для нас — это не только возможность заработать, но и востребованный функционал поиска отелей на карте. Он весьма удобен, если вам важно видеть, где находится отель и как далеко он расположен от транспортных узлов и основных достопримечательностей.


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


Если коротко говорить о нашей долгосрочной стратегии, то в рамках туристического сегмента стоит задача расширить применение MAPS.ME, превратить его из инструмента «добраться из точки А в точку В» в полноценный помощник путешественника. Поэтому мы планируем добавлять функционал, востребованный среди туристов: UGC (user-generated content) — рейтинги, отзывы, чтобы туристу было легче выбрать ресторан или любое другое заведение; поиск интересных мест; покупку билетов в музеи и на различные местные активности. Мы убеждены, что карта — это инструмент базовой регулярной потребности, вокруг которого можно надстраивать дополнительный комплементарный функционал, расширяющий сценарии туристического использования. При этом востребованность офлайн-карт будет только расти, особенно в развивающихся странах, где мобильный интернет стоит дорого и имеет плохое покрытие.


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


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



Полезные материалы


Я выложил все свои наработки в открытый доступ бесплатно для любого использования (некоммерческого/коммерческого): www.lisovskiy.ru/edu. Там есть шаблоны примеров расчёта бизнес-моделей в табличках, презентации. Есть подробный обучающий курс: в 2016 году я постарался собрать воедино весь свой практический опыт. Надеюсь, кому-то это пригодится и поможет в запуске новых проектов и развитии существующих.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331052/


Метки:  

[Перевод - recovery mode ] Сперва сторифреймы, потом вайрфреймы

Пятница, 16 Июня 2017 г. 14:07 + в цитатник
Буквально на днях я рассказывал дизайнеру пользовательского опыта из нашей команды о простой технике, которой пользуюсь уже много лет и которую никогда не воспринимал именно как «технику» — скорее, просто как интуитивный подход человека, который спроектировал столько веб-страниц, что давно им счет потерял.



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

Какие программы я для этого использую?

Текстовый редактор.

Google Doc. Или Microsoft Word. Или Apple TextEdit. Любой сойдет.

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

Главный вопрос, который я задаю себе, прежде чем открыть текстовый редактор и «написать» страницу — это «Как бы я объяснил другу в письме или личной беседе, что представляет собой эта идея/тема/продукт/история, которую я пытаюсь донести?».

Интерфейс — это история


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

Практически любая веб-страница в Сети пытается рассказать нам какую-то историю.

  • Домашняя страница Dropbox рассказывает, что это сервис, как он появился и какое место может занимать в вашей жизни.
  • Домашняя страница NY Times рассказывает, что происходит в мире с точки зрения редакции.
  • Домашняя страница AirBNB рассказывает о компании и приводит примеры услуг, которые она предлагает.

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

Если делать скачок из брифа прямиком в дизайнерскую программу, которой вы отдаете предпочтение (Sketch, Photoshop, InDesign, Axure, Principle, неважно), скорее всего, вы в итоге потратите много усилий на то, чтобы отполировать форму при том, что история еще не готова.

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

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

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

Пример сторифрейма


Сторифрейм выглядит как блок текста, в котором основное внимание уделяется иерархии и структуре страницы; это не макет и не финальная версия текстового наполнения. В качестве небольшого примера: вот как выглядит домашняя страница Dropbox в формате сторифрейма:


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

1. Для начала запишите все.

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

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

Обычно на этот упражнение уходит минут 15 и пол-кружки кофе.

2. Будьте лаконичны.

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

«Я написал бы короче, но у меня не было времени». — Марк Твен

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

3. Попробуйте разные истории.

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

4. Покажите другим.

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

И только после этого можно переходить к вайрфреймам и визуальным мокапам.


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

Сторифреймы: предельно низкая достоверность


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

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

  • В каком виде лучше отобразить эту информацию?
  • Какие части текста можно объединить в один модуль?
  • В каких частях истории текст можно заменить за изображение, видео или короткую анимацию?
  • Для каких частей текст следует дополнить вышеперечисленными материалами?
  • Какие конкретные факты вы приведете в качестве доказательства тех или иных утверждений?
  • Каких действий вы ждете от посетителей, после того как они ознакомятся с историей, которую рассказывает ваш вебсайт?
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331058/


Метки:  

11 вопросов к администраторам баз данных PostgreSQL

Пятница, 16 Июня 2017 г. 14:02 + в цитатник
Он оперативен, но в то же время спокоен. Он умен, аналитически мыслит и всегда сосредоточен. Это основные качества, благодаря которым можно достичь успехов специалисту DBA.

В перерывах между докладами, в кулуарах конференции PG Day’16 мы буквально на пару минут отвоевали внимание опытных администраторов и задали вопросы о том, что они думают о своей профессии, какие досадные ошибки они допустили в работе и какие советы дали бы новичкам. Антон Бушмелев, Александр Чистяков, Дмитрий Васильев, Михаил Тюрин и Брюс Момжан вспомнили истории на старте своей карьеры и рассказали, сколь тернист оказался их путь.


Кто такой администратор баз данных, и чем он отличается от других «айтишников»?



image altАлександр Чистяков: Администратор баз данных – это человек, который умеет читать план запросов. В основном, этим он и отличается от других айтишников. На самом деле, человек, который умеет читать план запроса, немного печален, потому что он хотел бы, чтобы другие айтишники тоже так могли, но они такого не могут. Он пытается их сподвигнуть на это, но они не хотят. Возникает некий конфликт. Человек, который не хочет быть тем, кем он является, но вынужден.

image altАнтон Бушмелев: Администратор баз данных – эксперт в своем деле. Это должен быть человек с опытом. Желательно, с background в разработке, чтобы с ходу замечать косяки при “накате” релиза. Администратор должен быть самым квалифицированным человеком в команде. За ним большая ответственность, он один отвечает сразу за много баз. Чем отличается от остальных “айтишников”? Он должен быть фанатом своего дела, любить свою работу!


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


image alt
Михаил Тюрин: Администратор баз данных отличается от других “айтишников” тем, что его сложно найти. Чрезвычайно редкий специалист. К нему повышенные требования. Большая редкость – найти человека, который одновременно понимает, что такое транзакция и bаsh-скрипт.


image altБрюс Момжан: Администратор работает с запросами, которые пишут разработчики приложений, и настраивает БД таким образом, чтобы производительность не падала, работа была надежной, вовремя происходили обновления. Он также устанавливает дополнительные пакеты, делает резервные копии и т.д. – есть множество задач на бэкенде, которые выполняет администратор баз данных, чтобы помочь разработчикам приложений. Этот человек отвечает за то, чтобы все таблицы были созданы, управляет правами пользователей, контролирует, как всё работает и следит за производительностью.



Что главное в профессии?



image altАлександр Чистяков: Четкость. Я думаю, что необходимо помнить, как мы оказались в текущей ситуации, чтобы не быть виноватым. Хорошая память нужна.

image altАнтон Бушмелев: Спокойствие, без этого очень тяжело. Должна быть нацеленность на результат. Не надо говорить разработчикам: «Ваш софт – г*вно!», для них это не будет составлять интереса. Надо показывать им: «Ребята, если делать так и так, будет быстрее. Давайте попробуем переделать!» – такой подход у хорошего ДБА должен быть.

image altДмитрий Васильев: Способность к аналитике, рассудительность, умение избегать принятия быстрых, необдуманных решений.

image altМихаил Тюрин: Если совсем не философствовать, а говорить о конкретных навыках, это понимание алгоритмов и структур, которые заложены в основу баз данных. И навыки скриптового программирования, как внутри базы данных, так и на языке общего назначения.

image altБрюс Момжан: Умение честно признать то, кем ты являешься на самом деле, и не пытаться прыгнуть выше своей головы. 19 лет назад я считал себя хорошим разработчиком приложений, пока не начал работать на международном уровне и не познакомился с людьми, которые намного круче меня. Тогда я понял, что это надо принять, и выбрал путь – эмоционально мотивировать людей, создавать такую атмосферу, в которой каждый был бы максимально продуктивен и чувствовал свою принадлежность к чему-то важному.



Расскажите о самой своей досадной ошибке.



image altАлександр Чистяков: Моя самая досадная ошибка была, когда я удалил в режиме реального времени продакшн-базу заказчика. Я приехал из Тверской области, очень мало спал и не то чтобы я перепутал базы… Я не помню, что точно было, но примерно 30% базы заказчика мы не смогли восстановить. Остальные 70% я восстановил, потому что хорошо знал, как работает база. А то он бы потерял 100%. А я бы потерял заказчика, больше ничего. Дело в том, что системный администратор – это такой человек, который может 600 человек оставить без зарплаты и ничего не потерять.

image altАнтон Бушмелев: Это был банк, дело было утром, я делал definition (база Oracle), и все было хорошо. После definition бьются индексы. Я проверил, что индексы отребилдились. Это были глобальные индексы по партициям и субпартициям. Я все проверил, кроме субпартиций. Благополучно уснул.

В 8 часов начались проблемы с блокировками, так как индексы по субпартициям все-таки оказались инвалидными, и банк стоял 2 часа. Минус 20% дали потом. После этого случая очень пристальное внимание уделяю мониторингу, чтобы все это отлавливалось. Ночью можно что-то забыть, а мониторинг работает постоянно.

image altДмитрий Васильев: Когда меня только пустили за консоль суперпользователем базы данных, я, не прочитав документации по команде TRUNCATE, выполнил ее для самой большой таблицы с логами, из-за чего продакшн встал на несколько часов.

image altМихаил Тюрин: Ну, DROP DATABASE я не делал, потому что нельзя сделать DROP DATABASE на нагруженной системе. Коннекты идут, и она не дропнется просто так. Досадные ошибки – это ошибки организации работы: что-то можно было бы сделать более эффективно, если бы я смог с кем-то договориться, заранее что-то решить до внедрения.

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

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

image altБрюс Момжан: Первые несколько лет оставляли желать лучшего мои способности к оценке трудозатрат. Я говорил: «Сделаю это за день!», а три дня спустя всё ещё работал над той же задачей. Потом понял, что даю оценки, исходя из сценария, где всё идёт идеально. Но ничего никогда не бывает идеально. Поэтому стал удваивать оценку времени и добавлять ещё 10% на форс-мажоры. Так что если раньше я называл 2 дня, то теперь стал говорить 4, 5. Пришлось много времени потратить на то, чтобы вывести эту формулу, но сейчас она отлично работает.


Что бы вы посоветовали тем, кто хочет заниматься базами данных и думает, не стать ли дба?



image altАлександр Чистяков: Ходить на наши конференции и хорошо прислушиваться к тому, что делается в сообществе. Это бизнес, здесь есть свои тренды, и нужно их чувствовать.

image altАнтон Бушмелев: Начать с концептов и азов, не гоняться за «халтурами», не искать серебряную пулю для решения проблем. Когда будет хорошая база, все остальное пойдет быстрее.

image altДмитрий Васильев: Я сам не сразу пришел к ДБА. Разное, многое перепробовал. Все вещи интересные, но специфика базы данных заключается в том, что это немножко другой мир, он движется в ином темпе из-за ответственности, которая лежит на инженерах БД. Но это не означает что он не интересный. Приходится знать железо, и как вообще все устроено. Хватает времени, чтобы разобраться досконально, в чем проблема. Словно японский дзен, нужно созерцать и понимать, что же на самом деле там происходит.

image altМихаил Тюрин: Расширять кругозор. Когда говорят про ДБА, это как в том анекдоте – ты же программист, иди разберись! Все, что касается данных, отправляют к ДБА, а на самом деле ДБА при этом вынужден решать задачи организации и архитектуры широкого стека приложений. Данные вовлечены во все взаимодействия внутри системы, и те решения, которые ДБА примет, скажутся на всех уровнях стека обработки запросов от конечного пользователя. Надо понимать как устроены другие уровни системы, которую поддерживает ДБА. Это поможет ему понять проблемы, возникающие у людей, которые пишут клиентов к базе данных.

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

image altБрюс Момжан: Если вы любите всё упорядочивать, вам понравится работать с базами данных. Языки программирования и технологии приходят и уходят, а базы данных остаются. Это такая фундаментальная часть разработки, затрагивающая вещи, влияющие на эффективность крупных организаций. Я бы рекомендовал изучать Постгрес. Это не тот проект, который вдруг возник и скоро исчезнет. В США специалисты по Постгресу очень ценятся, и в России тоже, потому что их недостаточно. Они являются кем-то вроде суперзвезд в своих компаниях, и было бы здорово, если бы больше людей это понимали и стремились стать такими специалистами. Те, кто стремится узнавать новое, учиться, обязательно достигнут карьерных высот.

Продолжение следует…
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331024/


Метки:  

Для ИТ-ишников. Если у вас устают глаза, покраснения, раздражение. Возможно эта статья для вас

Пятница, 16 Июня 2017 г. 14:00 + в цитатник


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

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

Далее я попрошу не читать тех, кто и так все знает и тех, кому не нравятся “не медицинские” термины :)

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

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

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

Далее кому стало вовсе скучно прошу покинуть эту аудиторию :)

Это простые упражнения, которые занимают 3-5 мин. Вам понадобятся только чистые руки и спокойная обстановка.

Подготовка

— Разотрите ваши ладошки до горяча.
— Затем накройте пальцы одной руки, пальцами второй, чтобы угол между “лодочками ладоней” был прямым.
— После, как “очки” наденьте на нос. Ладошки должны быть немного вогнутыми, чтобы при моргании вы не касались ресницами ладоней, но при этом так, чтобы свет не пробивался сквозь щели (можете делать в темноте).
— Все упражнения выполнять медленно и до приятной боли. Глаза держим открытыми.

Упражнение 1

Далее смотрим до упора вправо, на вдохе возвращаем глаза к центру и на выдохе смотрим до упора влево. Посмотрим по 10 раз в каждую сторону

Упражнение 2

Далее смотрим до упора вверх, на вдохе возвращаем глаза к центру и на выдохе смотрим до упора вниз. Посмотрим по 10 раз в каждую сторону

Упражнение 3

Далее смотрим до упора в правый верхний угол по диагонали, на вдохе возвращаем глаза к центру и на выдохе смотрим до упора в нижний левый угол. Посмотрим по 10 раз в каждую сторону

Упражнение 4

Далее смотрим до упора в левый верхний угол по диагонали, на вдохе возвращаем глаза к центру и на выдохе смотрим до упора в нижний правый угол. Посмотрим по 10 раз в каждую сторону

Упражнение 5

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

Упражнение 6

Аккуратно и на выдохе выпячиваем немного глаза. Повторяем 5 раз

Упражнение 7

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

Упражнение 8

Быстро-быстро моргаем в течении 5-7 сек.

Завершение

Теперь немного поддержим руки на месте, глаза открытыми в течении 10-15 сек. Затем открываем глаза. Если все краски стали ярче, а света в помещении больше, то упражнение, вы сделали правильно. Пробуйте и пусть ваше зрение всегда будет отличным!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331062/


Метки:  

Технологии платных скоростных дорог: настоящее и недалекое будущее

Пятница, 16 Июня 2017 г. 13:59 + в цитатник

«Классический» пункт взимания платы на обходе Воронежа — один из крупнейших в Европе

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


Счастливого пути, или Шлагбаум в лобовуху



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

На платных дорогах тариф зависит от класса ТС, определяемого по правилам ГК Автодор, которые в свое время были срисованы у французских консультантов. Правила выделяют 4 класса ТС: ТС высотой до 2 метров, ТС высотой от 2 до 2.6 метров, ТС выше 2.6 метров с двумя осями и ТС выше 2.6 метров с 3-мя и более осями. Как видите, в последних двух классах фигурируют оси, автоматический подсчет которых оказался непростой задачей в наших условиях. Дело в том, что в Европе для подсчета осей применяются оптические датчики, размещаемые у поверхности дороги. В совокупности с индуктивной петлей, которая чувствует наличие чего-то большого и железного наверху, эти датчики довольно эффективно считают оси. Но проблема заключается в том, что климат у нас такой, что одно межсезонье плавно переходит в другое, и все, что находится ниже 2-х метров, через пару часов может покрыться слоем воды и грязи (а на скоростных трассах грязь взлетает на все 10). Поэтому было принято решение считать оси с использованием видеокамер и софта машинного зрения, который сразу определял и габариты, и число осей. И тут возникли проблемы, свойственные уже системам машинного зрения: дождь, снег, зловещие тени, недостаточная освещенность, блики от фар — все это сбивает видеоклассификатор с толку. Сейчас уже никто не возьмется судить, что лучше — регулярно чистить оптические датчики или разгадывать ребусы шалящего в непогоду машинного зрения. Рассматривается и третий вариант с использованием альтернативных счетчиков осей на основе автономных магнитных датчиков в толще бетона или на основе недорогих лазерных сканеров (лидаров), подвешенных сбоку на высоте 2 метров. Для установки лидаров не нужно штробить бетон, они также отлично справляются с замерами габаритов, не боятся темноты и непогоды и могут стать полноценной заменой дорогостоящему оборудованию классификации.


3D профайлер на основе лазерных сканеров и пример получаемого облака точек

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

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

В рамках ИС были выделены следующие роли:
  • Эмитент транспондеров, предоставляющий списки выпущенных транспондеров;
  • Поставщик услуг, регистрирующий параметры транспорта, проезжающего по быстрым полосам ПВП

Архитектура ИС межоператорского взаимодействия основана на распределенном кластере первичных узлов, каждый из которых содержит копию всех данных, включающих списки транспондеров, ключей безопасности, записей о проездах с использованием транспондеров, различных корректировок, произведенных операторами и т.п. От оператора платной дороги, желающего подключиться к системе, теперь требуется только привести свои данные к стандартизованному виду, реализовать протокол обмена и залить «роуминговые» ключи на свои антенны DSRC для того, чтобы они могли корректно регистрировать проезды «чужих» пользователей. Так как базовое содержимое памяти транспондеров закреплено стандартом ISO 14906, который свято чтится всеми участниками, основные проблемы возникли в области корректировок данных и в общем недоверии операторов друг другу (что, собственно, и породило похожую на blockchain архитектуру репликации данных).

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

Гость из будущего



Мобильный и стационарный посты контроля системы «Платон»

Судьба проекта системы взимания дорожного сбора с 12-тонников (aka «Платон») драматична и наполнена болью, начиная от отмененного в 2014 году конкурса с участием мировых технологических грандов и крупнейших банков и заканчивая героическим вводом системы в эксплуатацию буквально годом позже силами структур Ростеха. Тем не менее, если закрыть глаза на ошибки и недочеты, чисто технологически «Платон» стоит на вершине горы систем взимания платы. Что одновременно и хорошо, и плохо, и дальше я объясню почему. Кстати, матчасть можно вспомнить тут: раз, два.

Технологическая новизна «Платона» и подобных систем заключается в идее полного отказа от использования наземной стационарной инфраструктуры для целей взимания платы. Вместо этого данные об использовании платных дорог формируются на основе привязки GPS треков к дорожному графу. Преимуществом подобного подхода является возможность покрытия режимом платности целой дорожной сети. Например, «Платон» покрывает все 50 000 км. федеральных дорог. При этом можно менять конфигурацию сети, добавлять или исключать сегменты, вводить разнообразные тарифы: за пробег, за участок, за часть участка и т.п. Можно даже объединять несколько сетей и нескольких операторов в рамках одной системы, например, федеральную сеть и региональные сети (структурированный подход к определению контекста взимания платы приведен в стандартах серии ISO 17575-*).


Стандартная архитектура гибридных систем взимания платы

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

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

В «Платоне» же, видимо, по причине экономии средств, было решено отказаться от добавления модулей DSRC в трекеры. Задача опознания нарушителя в заляпанном грязью грузовике, проносящемся посреди ночи под порталом контроля кардинально усложнилась — ведь теперь не стало двух независимых средств идентификации. В плохую погоду читаемость номерных знаков падает с обычных 96-97% до 60-70%, а в снегопад и после него зачастую читается только каждый третий номерной знак. Откуда взять вторичный источник достоверных идентификационных данных? Можно, например, взять частично прочитанный номерной знак и сверить его с базой данных зарегистрированных пользователей. Но каждый, кто занимался технологиями распознавания номерных пластин, только посмеется над этим, так как пластина обычно загрязняется или равномерно вся, или снизу вверх, поэтому результаты распознавания проседают сразу по всей пластине. По базе можно попытаться восстановить только номера любителей заклеивать отдельные цифры, но они погоды не делают.


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

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

Вообще говоря, привязка трека к карте с целью расчета пробега — та еще задачка! Особенно если от точности привязки напрямую зависит качество выставляемого счета. В условиях плотной дорожной сети, где платные и бесплатные сегменты находятся близко друг от друга (например, бесплатный дублер параллельно платной дороге) скачки GPS трека могут приводить к ошибочному выставлению счета. В горной местности, в тоннелях, под эстакадами, на развязках, в лесу, рядом с высотными зданиями или вблизи Кремля данным GPS вообще нет никакого доверия, и разработчики софта изощряются как могут, пытаясь удержать ТС на маршруте по косвенным данным. В подобных условиях без дополнительных «маячков» на дороге нельзя ничего гарантировать. На помощь приходят все те же DSRC антенны, которые формируют аккуратное «пятно» на дороге. Стандарт ISO 13141 описывает сервис LAC (Localisation Augmentation Communication), позволяющий устанавливать недорогие автономные маячки DSRC, единственной функцией которых является запись фиксированного блока данных с координатами и таймстампами в память БУ, что является 100% свидетельством того, что ТС пересело пятно маяка. Логика БУ использует эти данные для уточнения GPS трека.


Пример данных DSRC по стандарту ISO 13141, дополняющих GPS трекинг

Ближайшее будущее технологий платных дорог



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

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

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


ЦКАД — первая платная дорога в РФ, которая, скорее всего, будет обходиться без шлагбаумов

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


Сравнительные параметры технологий взимания платы (via).

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

Вот как технологии распределяются в зависимости от типа проекта.


Карта выбора технологий. (via)

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


Выбор технологии в зависимости от количества дорожных сегментов и количества пользователей платной дороги (via)

Как мы видим, на платных скоростных дорогах, где малое количество сегментов и большое количество пользователей, таких как ЦКАД (у которого, несмотря на длину, будет не более 30 сегментов), имеет смысл использовать порталы с DSRC антеннами для оплаты проезда и с видеокамерами для контроля нарушений. Это одновременно эффективно и технологически, и в плане стоимости создания и эксплуатации. Тем более, что по ЦКАДу поедут пользователи существующих платных дорог, которые к тому времени в подавляющем большинстве перейдут на единый DSRC транспондер. При этом крайне желательно обязать всех пользователей ЦКАД использовать транспондеры (их можно отдавать ниже себестоимости или вообще бесплатно вместе с абонементом, все равно окупятся десять раз). Для легковых ТС можно распространять «транспондеры в пакете» — готовое к использованию решение, позволяющее создать временную регистрацию пользователя с начальным балансом при первом проезде под порталом. Такие «заряженные» транспондеры можно продавать на заправках или даже через вендинговые автоматы.

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

А как же RFID, могут спросить меня коллеги, его же тоже используют для идентификации транспорта? Разумеется, RFID, также как и DSRC, является перспективным направлением и на нем тоже делают платные дороги (например, в США и в ЮВА). По плюсам и минусам могу сориентировать в комментариях, но, вкратце, если у нас уже создана и уже 10 лет работает инфраструктура для DSRC, введен в действие единый транспондер, технологическая поляна расписана в серии стандартов, сам девайс стоит не больше 10 евро (что сопоставимо по стоимости со скоростными автомобильными RFID метками) и имеет батарейку на 7 лет, то о чем еще можно думать? А еще — DSRC транспондер умеет пиликать и мигать лампочкой, сообщая о статусе операции! Мне кажется, поезд RFID в части отечественных платных дорог ушел. А вот идентификация транспорта в целях контроля (aka электронные номерные знаки) — задача как раз для RFID меток. Но это уже совсем другая история.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330876/


Метки:  

[Перевод - recovery mode ] Самое простое руководство по иконографике

Пятница, 16 Июня 2017 г. 13:50 + в цитатник
Светлана Шаповалова, редактор «Нетологии», перевела руководство по иконографике от Tidjane Tall, рассказав о самых простых базовых иконках и объяснив, почему иллюстрация стоит тысячи слов.

Сколько в среднем времени надо дизайнеру на создание одной пользовательской иконки? Пару минут? Десять? Час, два или три? А что если мы покажем, как сделать 10 крутых иконок менее чем за 10 минут?




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

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

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



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

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

Главное в дизайне логотипов или иконок — это ничего не усложнять.

С помощью этого руководства вы сможете создать 10 разных иконок за 10 секунд, использовав при этом простые геометрические фигуры.

Важно: я использовал Adobe Illustrator, но вы получите такой же результат в любом другом редакторе: Sketch или Figma. Точки на фигуре мы добавляли и удаляли инструментом «Перо» (Pen Tool), выбирали и двигали — «Частичным выделением» (Direct Selection Tool).

Глаз (Eye Icon)


image

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

Совет: чтобы не использоваться белые круги, воспользуйтесь палитрой «Обработка контуров» (Pathfinder) и вычтите две окружности из нижнего круга.

Стрелка (Arrow Icon)


image

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

Совет: как вариант, просто нарисуйте тонкую линию и придайте ей форму стрелы.

Батарейка (Battery Icon)


image

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

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

Маркированный список (Bullet List Icon)


image

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

Совет: замените квадраты на круги — и вид иконки смягчится.

Облако (Cloud Icon)


image

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

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

Перемотка вперед (Forward Play Icon)


image

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

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

Воронка (Funnel Icon)


image

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

Совет: поставьте два прямоугольника друг на друга и просто растяните край верхнего.

Воспроизведение/Пауза (Play/Pause Icon)


image

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

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

Навигационная стрелка (Position Arrow Icon)


image

Это видоизмененная иконка локационного сервиса из гифки Моргана. Просто нарисуйте квадрат, а затем потяните за нижний левый угол в направлении противоположного угла.

Совет: Если работаете в Illustrator, зажмите клавишу Shift, чтобы получить строго диагональное направление.

Метка геолокации (Position Pin Icon)


image

Внутри большего круга создайте маленький, используя палитру «Обработка контуров» (Pathfinder). Опустите нижнюю точку на нужное расстояние и заострите получившийся кончик: переключитесь на инструмент «Перо» (Pen Tool), затем щелкнете по точке, зажав клавишу Shift.

Совет: можете не заострять угол полностью — просто немного округлите его, выбрав точку и изменив значение «Радиус скругления» (corner radius) в палитре «Трансформирование» (Transform).

Иконка звука (Sound Icon)


image

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

Совет: просто скопируйте воронку и разверните её по часовой стрелке.

Волна (Wave Icon)


image

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

Совет: чтобы линия стала еще мягче, округлите её концы.

Хорошая иконка стоит тысячи слов


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

Умение создавать наборы простых и полезных иконок всегда пригодится. В статье мы как раз показали, как легко и быстро сделать иконки из базовых фигур.

10 правил иконографики:

  • Делайте иконки символическими и осмысленными.
  • Рекомендация, которую вы, вероятно, слышали уже сотни раз: не усложняйте. Не жертвуйте считываемостью иконки в угоду внешнему виду.
  • Работайте осознанно и вдумчиво. Прежде чем начать, хорошо всё обдумайте.
  • Убедитесь, что иконка правильно выглядит в разных размерах.
  • Выдерживайте единый стиль.
  • В векторе, пожалуйста!
  • Используйте разные цвета осторожно и только при необходимости.
  • Знание основ геометрии очень помогает.
  • Помните, что с первого взгляда должно быть понятно, для чего нужен тот или иной элемент дизайна — то есть помните про так называемый аффорданс.
  • Язык иконографики должен быть универсальным.
  • На самом деле английский алфавит — это всего лишь набор из 26 иконок, а русский — из 33.

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

Рекламный абзац от редакции


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

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

Спасибо за внимание!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331050/


Метки:  

Data Science meetup в офисе Avito 24 июня

Пятница, 16 Июня 2017 г. 13:46 + в цитатник
image

24 июня мы собираем специалистов по Data Science в нашем офисе, чтобы обменяться опытом в создании рекомендательных сервисов. На встрече мы подведём итоги проходившего на площадке Dataring.ru конкурса Avito на построение рекомендательной системы для объявлений: наградим победителей и попросим их подробнее рассказать о своих решениях. Кроме того, в программе интересные доклады от представителей Яндекс.Дзена, OZON.ru и, конечно же, Avito. Подробности под катом!


Доклады


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

Машинное обучение в Дзене


image
Первыми выступят спикеры из Яндекса: Евгений Соколов и Дмитрий Ушанов. Евгений — руководитель группы качества рекомендаций и анализа контента Яндекс.Дзена. Дмитрий — старший разработчик сервиса Дзен, а до этого занимался разработкой лингвистических компонентов поиска: поисковых колдунщиков и объектных ответов.

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

Рекомендации в OZON.ru


image
Ведущий аналитик OZON.ru Ксения Бокша, не вдаваясь сильно в математику, расскажет про различные виды рекомендаций, которые предоставляет маркетплейс своим пользователям: связанные товары, аксессуары, бандлы, персональные рекомендации, рекомендуемые категории товаров по запросам, рекомендуемые поисковые запросы, рекомендации в корзине. Кроме того, из доклада вы узнаете о стеке технологий, который использует команда, а также о ближайших планах.

Какие задачи решает команда рекомендаций в Avito


image
На одной из прошлых встреч руководитель юнита рекомендаций Василий Лексин уже рассказывал, что под капотом у рекомендаций в Avito. В этот раз вместе с аналитиком Михаилом Каменщиковым они расскажут о том, какие задачи решает юнит рекомендаций, зачем был организован конкурс на построение рекомендательной модели, какие результаты они ожидали получить по итогам соревнования, что из этого удалось, а что нет. Кроме того, они поделятся своим опытом участия в RecSys Challenge 2017.

Конкурс


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

Пару слов о самом конкурсе. В этом датаринге участникам предлагалось построить свою рекомендательную систему для объявлений на основе истории активности около 600 000 пользователей в течение 6 дней. После получения обучающей выборки участникам предстояло предсказать события взаимодействия пользователя с объявлением, которые могли быть 4-х типов: клик по объявлению, отправка сообщения продавцу, добавление объявления в избранное и запрос контакта продавца. Правильные предсказания событий разных типов имели различный вес.
Финальные результаты конкурса уже опубликованы на портале DataRing.ru, а решения призеров проходят валидацию.
image

Регистрация


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

Стартуем доклады в 12:30 и планируем завершить встречу к 16:00. В перерыве можно будет перекусить воком.

Адрес: Лесная, 7, 15 этаж (БЦ “Белые Сады”). Вход с Лесной улицы. Ближайшая станция метро — Белорусская кольцевая.

До встречи!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331054/


Метки:  

[Из песочницы] Страх и ненависть в MiddleWare

Пятница, 16 Июня 2017 г. 13:07 + в цитатник
Мы были неподалёку от JavaScript, когда нами одолел php. Я помню сказал что-то вроде: Что-то у меня голова кружится. Может лучше тебе повести проект.



Внезапно, вокруг нас раздался ужасный бум… И весь WEB кишал этими статьями про LAMP…
Казалось, что они были написаны под любые нужды. Они разрастались и поглощали задачи для которых ранее пользовался perl, bash и даже С. Нет смысла говорить об этих статьях, подумал я. Все и так это знают.

У нас был пятый IE, немного Netscape, Opera и целое море разношёрстных cgi модулей на perl. Не то что бы это был необходимый стек технологий. Но если начал собирать дурь, становится трудно остановиться. Единственное что вызывало у меня опасение — это студент, употребляющий PHP. Нет ничего более беспомощного, безответственного и испорченного, чем это. Я знал, что рано или поздно мы перейдем и на эту дрянь.


В начале было не было


Когда-то JS между браузерами отличался как конь от пробки, а XMLHttpRequest возможен был исключительно через ActiveX. Выхода особо не было. Что на корню вырубало динамический веб. IE 6 казался революцией. Но если вы хотели кросплатформености — ваш путь пролегал через объемный MiddleWare. А большое количество статей по php, инструментов и сопутствующих новоиспеченных библиотек делали своё дело.

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

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

Конечно же, я пал жертвой повального увлечения. Обыкновенный уличный бездельник, который изучал все, что попадало под руку. В воздухе витали идеи о едином языке для Web разработки. Погоди, вот увидишь эти изменения в новом обличие, мужик.
— Давай Node.js посмотрим.
— Чего? Нет!
— Здесь нельзя останавливаться. Это толстый Middle.
— Садись.
Что за чушь они прут, не знаю сколько нужно писать на JavaScript чтобы найти сходство между Front, Middle и BackEnd? Это неподходящий вариант. Слишком толсто для выбранной цели.


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

Я почувствовал чудовищный протест против всей ситуации.

Есть же СУБД, такие как PostgreSQL, позволяющие невообразимо оперировать данными через встраиваемые функции. Бизнес логика внутри базы! Настоящий BackEnd. Не нравиться бизнес логика в СУБД и ей там не место? А такие прямые потоки данных нравится?


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

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

Множественность запросов в одной сессии к СУБД ведёт к неизбежному апофеозу кончины скорости — многопроходности по таблицам базы.



Для исключения этих факторов, логику приходится переносить ближе к данным, т.е. в СУБД!
И это наиболее оптимальный способ вывести скорость на новые величины!

Становление идеи


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

Эти наивные разработчики полагали, что можно обрести душевный мир и понимание, изучив один из оплотов старого Middle, а результат — поколение толстого слоя, так и не понявших главную, старую как мир ошибку IT индустрии. Упустив убеждение, что Кто-то или Что-то может обладать фатальным недостатком.
К тому времени начал работать nginx, и уже не оставалось вопросов с чем нужно готовить предполагаемую мысль. Это больше была не идея. Теперь это было состязание программиста с ленью. Сама мысль, попытаться как-то описать архитектуру традиционным образом, через apache, казалась абсурдной.

В 2010 на github подоспел модуль ngx_postgres. Задание запросов в конфигурационном файле и выдача в JSON/CSV/ЧТОТОЕЩЕ.
Для конфигурации достаточно было простого SQL кода. Сложный можно было обернуть в функцию, которая потом вызывалась из конфига.

Но этот модуль не умел загружать тело http запроса в СУБД. Что накладывало серьезные ограничения на данные, оправляемые к серверу. URL же явно подходил только для фильтрации запроса.
Cериализация выходных данных проводилась средствами самого модуля. Что, с высоты моего дивана, казалось бессмысленным переводом ОЗУ — сериализовать умел и PostgreSQL.
Возникла мысль поправить, переписать. Я стал копать в коде этого модуля.

После бессонной ночи поисков многим хватило бы ngx_postgres. Нам нужно было что-то посильнее.
Мадам, сэр, детка, или как вас… вариант есть, вот, держите ngx_pgcopy.



NGX_PGCOPY


После эксперимента экспериментов и анализа анализов, возникла мысль переписать всё практический с нуля. Для ускорения загрузки были выбраны запросы COPY, которые перегоняют данные в базу на порядок быстрее инсертов и содержат собственный парсер. К сожалению, ввиду скудности описания подобного типа запросов, сложно сказать как будет вести СУБД при особо массовых вызовах данного метода.

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

Вместе с COPY-requests мы автоматом получили сериализацию в CSV по обоим направлениям, что избавило от необходимости заботы о преобразовании данных.

Начнём с примитива, отправка и получение всей таблицы в CSV по URL:
http://some.server/csv/some_table

CSV часть import.export.nginx.conf

pgcopy_server db_pub "host=127.0.0.1 dbname=testdb user=testuser password=123";

location ~/csv/(?<table>[0-9A-Za-z_]+) {
    pgcopy_query PUT db_pub "COPY $table FROM STDIN WITH DELIMITER as ';' null as '';";
    pgcopy_query GET db_pub "COPY $table TO STDOUT WITH DELIMITER ';';";
}



На текущий момент PostgreSQL не может в JSON и XML через COPY STDIN. Я надеюсь, что наступит день смирения с табами в код-стиле слона и я, или кто-нить, найдёт время и прикрутит этот функционал к COPY методам. Тем более, что в СУБД обработка этих форматов уже присутствует.

Однако! Способ применения здесь и сейчас всё же есть! Конфигурируем nginx на client_body_in_file_only on c последующим использованием в запросе переменной $request_body_file и передачей её в функцию pg_read_binary_file…
Разумеется придется это обернуть в COPY метод, т.к. работать будет только с моим мопедом, по причине полного body_rejecta у ngx_postgres. Других мопедов я пока не встречал, а ngx_pgcopy еще не созрел для дополнительного функционала.

Рассмотрим как это выглядит для json/xml в import.export.nginx.conf

client_body_in_file_only on;
client_body_temp_path /var/lib/postgresql/9.6/main/import;

location ~/json/(?<table>[0-9A-Za-z_]+) {
    pgcopy_query PUT db_pub 
        "COPY (SELECT * FROM import_json_to_simple_data('$request_body_file')) 
            TO STDOUT;";
    pgcopy_query GET db_pub 
        "COPY (SELECT '['||array_to_string(array_agg(row_to_json(simple_data)), 
            ',')||']' FROM simple_data) TO STDOUT;";
}

location ~/xml/(?<table>[0-9A-Za-z_]+) {
    pgcopy_query PUT db_pub 
        "COPY (SELECT import_xml_to_simple_data('$request_body_file') TO STDOUT;";
    pgcopy_query GET db_pub 
        "COPY (SELECT table_to_xml('$table', false, false, '')) TO STDOUT;";
}

Да, client_body_temp_path придётся выставить в директорию базы, а пользователю дать ALTER SUPERUSER. В ином случаем Postgres отправит наши желания за горизонт.
Экспорт, представленный в методах GET, использует встроенные функции, включённые в стандартную поставку Postgres. Все COPY выводят в STDOUT, на случай если мы захотим известить клиента о результатах этих действий. Импорт в фиксированную таблицу(simple_data) выглядит немного объемнее экспорта, посему вынесен в определяемые пользователем процедуры СУБД.

Часть из 1.import.export.sql для импорта в фиксированную таблицу

CREATE OR REPLACE FUNCTION import_json_to_simple_data(filename TEXT)
RETURNS void AS $$
BEGIN
    INSERT INTO simple_data
    SELECT * FROM 
        json_populate_recordset(null::simple_data, 
            convert_from(pg_read_binary_file(filename), 'UTF-8')::json);
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION import_xml_to_simple_data(filename TEXT)
RETURNS void AS $$
BEGIN
    INSERT INTO simple_data
    SELECT (xpath('//s_id/text()', myTempTable.myXmlColumn))[1]::text::integer AS s_id,
           (xpath('//data0/text()', myTempTable.myXmlColumn))[1]::text AS data0
    FROM unnest(xpath('/*/*', 
        XMLPARSE(DOCUMENT convert_from(pg_read_binary_file(filename), 'UTF-8')))) 
    AS myTempTable(myXmlColumn);
END; 
$$ LANGUAGE plpgsql;

Функция импорта с гибким выбором таблицы для JSON особо не отличается от приведённой выше. А вот подобная гибкость для XML порождает более монструозное поделие.
Часть из 1.import.export.sql для импорта в произвольную таблицу
CREATE OR REPLACE FUNCTION import_vt_json(filename TEXT, target_table TEXT)
RETURNS void AS $$
BEGIN
    EXECUTE format(
        'INSERT INTO %I SELECT * FROM 
            json_populate_recordset(null::%I, 
                convert_from(pg_read_binary_file(%L), ''UTF-8'')::json)', 
        target_table, target_table, filename);
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION import_vt_xml(filename TEXT, target_table TEXT)
RETURNS void AS $$
DECLARE
    columns_name TEXT;
BEGIN
    columns_name := (
    WITH
        xml_file AS (
            SELECT * FROM unnest(xpath( 
                '/*/*',
                XMLPARSE(DOCUMENT 
                    convert_from(pg_read_binary_file(filename), 'UTF-8'))))
    --read tags from file
        ), columns_name AS (
            SELECT DISTINCT (
                xpath('name()', 
                      unnest(xpath('//*/*', myTempTable.myXmlColumn))))[1]::text AS cn
             FROM xml_file AS myTempTable(myXmlColumn)
    --get target table cols name and type
        ), target_table_cols AS (  --
            SELECT a.attname, t.typname, a.attnum, cn.cn          
            FROM  pg_attribute a
            LEFT JOIN pg_class c ON c.oid = a.attrelid
            LEFT JOIN pg_type t ON t.oid = a.atttypid
            LEFT JOIN columns_name AS cn ON cn.cn=a.attname
            WHERE a.attnum > 0
                AND c.relname = target_table --'log_data'
            ORDER BY a.attnum
    --prepare cols to output from xpath
       ), xpath_type_str AS (
        SELECT CASE WHEN ttca.cn IS NULL THEN 'NULL AS '||ttca.attname 
                    ELSE '((xpath(''/*/'||attname||'/text()'', 
                            myTempTable.myXmlColumn))[1]::text)::'
                         ||typname||' AS '||attname
               END 
            AS xsc
        FROM target_table_cols AS ttca
       )
      SELECT array_to_string(array_agg(xsc), ',') FROM xpath_type_str
    );

    EXECUTE format('INSERT INTO %s SELECT %s FROM unnest(xpath( ''/*/*'',
             XMLPARSE(DOCUMENT convert_from(pg_read_binary_file(%L), ''UTF-8'')))) 
             AS myTempTable(myXmlColumn)', target_table, columns_name, filename);
END;
$$ LANGUAGE plpgsql;


В приведенных примерах, наименование table_name в импортируемом файле не влияет на целевую таблицу назначения, заданную в nginx. Применение иерархии xml документа table_name/rows/cols обусловлено исключительно симметрией со встроенной функцией table_to_xml.

Cами наборы данных…
simple_data_table.sql
CREATE TABLE simple_data (
    s_id    SERIAL,
    data0   TEXT
);

data.csv
0;zero
1;one

data.json
[ {"s_id": 5, "data0": "five"}, 
  {"s_id": 6, "data0": "six"}  ]

data.xml
<simple_data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <row>
        <s_id>3</s_id>
        <data0>three</data0>
    </row>
    <row>
        <s_id>4</s_id>
        <data0>four</data0>
    </row>
</simple_data>

Мы тут отдалились, поэтому вернёмся к истокам чистого COPY…

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



Думаю я поймал страх.
Ерунда. Мы пришли, чтобы найти MidleWare мечту.
И теперь, когда мы прямо в её вихре, ты хочешь уйти?
Ты должен понять, мужик, мы нашли главный нерв.


Да, это почти так! Это отказ от CRUD.
Разумеется, многих возмутит как какой-то тип в паре предложений перечеркивает результаты работы Калифорнийских умов, стилизуя коротенькую статейку под диалоги наркоманского фильма. Однако, ещё не всё потеряно. Есть вариант передавать модификатор данных вместе с самими данными. Что всё равно уводит от привычной архитектуры RESTfull.

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

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

Точка входа


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

Мы отправляем данные в средний слой, который без обработки пересылает их в базу.
СУБД их парсит и кладёт в таблицу, выполняющую роль журнала/лога. Регистрация всех входных данных.

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

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

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



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

Код из 2.jrl.log.sql:

Таблицы
CREATE TABLE rst_data (   --Output/result table 1/2
    s_id        SERIAL,
    data0       TEXT,     --Operating Data
    data1       TEXT,     --Operating Data
);

--Service variable with prefix s_, ingoring input value, it will be setting from trigers
CREATE TABLE jrl_data (   --Input/journal table 2/2
    s_id        SERIAL,   --Service variable, Current ID of record
    s_cusr      TEXT,     --Service variable, User name who created the record
    s_tmc       TEXT,     --Service variable, Time when the record was created
    p_trid      INTEGER,  --Service variable, Target ID/Parent in RST_(result) table, 
                          --    if exists for modification

    data0       TEXT,
    data1       TEXT,
);

CREATE TABLE log_data (  --Input/output log table 1/1
    s_id        SERIAL,
    s_cusr      TEXT,
    s_tmc       TEXT,
    pc_trid     INTEGER, --Service variable, Target ID(ParentIN/ChilrdenSAVE) 
                         --    in CURRENT table, if exists for modification

    data0       TEXT,
    data1       TEXT,
);

Триггер для журналов
CREATE OR REPLACE FUNCTION trg_4_jrl() RETURNS trigger AS $$
DECLARE
    update_result    INTEGER := NULL;
    target_tb        TEXT :='rst_'||substring(TG_TABLE_NAME from 5);
BEGIN
--key::text,value::text
    DROP TABLE IF EXISTS not_null_values;
    CREATE TEMP TABLE not_null_values AS
        SELECT key,value from each(hstore(NEW)) AS tmp0
	     INNER JOIN 
	     information_schema.columns
	     ON information_schema.columns.column_name=tmp0.key
	     WHERE tmp0.key NOT LIKE 's_%'
	       AND tmp0.key <> 'p_trid'
	       AND tmp0.value IS NOT NULL
	       AND information_schema.columns.table_schema = TG_TABLE_SCHEMA
	       AND information_schema.columns.table_name   = TG_TABLE_NAME;

    IF NEW.p_trid IS NOT NULL THEN
	EXECUTE (WITH keys AS (
	    SELECT (
	      string_agg((select key||'=$1.'||key from not_null_values), ','))
              AS key)
		SELECT format('UPDATE %s SET %s WHERE %s.s_id=$1.p_trid', target_tb, keys.key, target_tb)
		    FROM keys) 
        USING NEW;
    END IF;

    GET DIAGNOSTICS update_result = ROW_COUNT;
    IF NEW.p_trid IS NULL OR update_result=0 THEN
	    IF NEW.p_trid IS NOT NULL AND update_result=0 THEN
	        NEW.p_trid=NULL;
	    END IF;
    
        EXECUTE format('INSERT INTO %s (%s) VALUES (%s) RETURNING s_id', 
                       target_tb, 
                       (SELECT string_agg(key, ',') from not_null_values), 
                       (SELECT string_agg('$1.'||key, ',') from not_null_values))
		USING NEW;
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Триггер для логов
CREATE OR REPLACE FUNCTION trg_4_log() RETURNS trigger AS $$
BEGIN
    IF NEW.pc_trid IS NOT NULL THEN
        EXECUTE (
        WITH
             str_arg AS (
		SELECT key AS key,
		       CASE WHEN value IS NOT NULL OR key LIKE 's_%' THEN key
		       ELSE NULL
		       END AS ekey,
		       CASE WHEN value IS NOT NULL OR key LIKE 's_%' THEN 't.'||key
		       ELSE TG_TABLE_NAME||'.'||key
		       END AS tkey,
		       CASE WHEN value IS NOT NULL OR key LIKE 's_%' THEN '$1.'||key
		       ELSE NULL
		       END AS value,
		       isc.ordinal_position
	        FROM each(hstore(NEW)) AS tmp0
		INNER JOIN information_schema.columns AS isc
		     ON isc.column_name=tmp0.key
		WHERE isc.table_schema = TG_TABLE_SCHEMA
		AND isc.table_name = TG_TABLE_NAME
		ORDER BY isc.ordinal_position)
	SELECT format('WITH upd AS (UPDATE %s SET pc_trid=%L WHERE s_id=%L)
	               SELECT %s FROM (VALUES(%s)) AS t(%s) 
	               LEFT JOIN %s ON t.pc_trid=%s.s_id',
	               TG_TABLE_NAME, NEW.s_id, NEW.pc_trid,
	               string_agg(tkey, ','), 
	               string_agg(value, ','), 
	               string_agg(ekey, ','),
	               TG_TABLE_NAME, TG_TABLE_NAME) 
	FROM str_arg
	) INTO NEW USING NEW;
	NEW.pc_trid=NULL;
    END IF;
    
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

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

Триггеры вызываются в порядке текстовой сортировки по имени. Я рекомендую использовать префиксы trg_N_. От trg_0 до trg_4 считать служебными, обслуживающими только целостность общей логики и входящую фильтрацию. А с 5 до 9 использовать для прикладных расчетов. Девять триггеров будет достаточно всем!

Так же стоит сказать, что их нужно устанавливать на BEFORE INSERT. Так как в случае c AFTER, служебная переменная NEW будет положена в таблицу до модификации триггером. В принципе, если целостность в некоторый степени не критична, подобное решение может быть хорошим ускорителем пользовательских запросов, проходящих через журнал. Это не повлияет на значения результирующей таблицы.

Еще, при AFTER, мы не сможем вернуть ошибку, если пользователь не имеет прав на изменение. Но корректный FrondEnd и не должен проводить запрещенные сервером операций. Соответственно, подобное поведения скорее свойственно взлому, который мирно будет зафиксирован в журнале.

ProФильтрацию и маршрутиризацию




Маршрутиризируем URL стандартными средствами nginx. Тем же способом фильтруем запрос от инъекций. После удвоения проблем, код похожий на результат асимметричного шифрования загоняем в директиву map nginx.conf для получения удобоваримого и безопасного SQL запроcа. Которым, в последующем, фильтруем данные.

Есть некоторые сложности. Они вызваны отсутствием в nginx синтаксиса регулярок для множественной замены по типу sed s/bad/good/g. В результате мы…

Попадаем прямо в гущу этого ебаного террариума. И ведь у кого-то хватаем ума писать эти чёртовы выражения! Еще немного и они разорвут мозг в клочья.

до 4х фильтров эквивалентности по URL
http://some.server/csv/table_name/*?col1=value&col2=value&col3=value&col4=value
Horrowshow part of filters.nginx.conf
#Составляем фильтр SQL
map $args $fst0 {
   default "";
   "~*(?<tmp00>[a-zA-Z0-9_]+=)(?<tmp01>[a-zA-Z0-9_+-.,:]+)(:?&(?<tmp10>[a-zA-Z0-9_]+=)(?<tmp11>[a-zA-Z0-9_+-.,:]+))?(:?&(?<tmp20>[a-zA-Z0-9_]+=)(?<tmp21>[a-zA-Z0-9_+-.,:]+))?(:?&(?<tmp30>[a-zA-Z0-9_]+=)(?<tmp31>[a-zA-Z0-9_+-.,:]+))?(:?&(?<tmp40>[a-zA-Z0-9_]+=)(?<tmp41>[a-zA-Z0-9_+-.,:]+))?"    "$tmp00'$tmp01' AND $tmp10'$tmp11' AND $tmp20'$tmp21' AND $tmp30'$tmp31' AND $tmp40'$tmp41'";
}

#Проверяем на корректность
map $fst0 $fst1 {
   default "";
   "~(?<tmp0>(:?[a-zA-Z0-9_]+='[a-zA-Z0-9_+-.,:]+'(?: AND )?)+)(:?( AND '')++)?" "$tmp0";
}
map $fst1 $fst2 {
   default "";
   "~(?<tmp0>[a-zA-Z0-9_+-=,.'' ]+)(?= AND *$)" "$tmp0";
}

#Если контроль корректности пройден, дописываем WHERE
map $fst2 $fst3 {
   default "";
   "~(?<tmp>.+)" "WHERE $tmp";
}

server {
    location ~/csv/(?<table>result_[a-z0-9]*)/(?<columns>\*|[a-zA-Z0-9,_]+) {
        pgcopy_query GET db_pub 
            "COPY (select $columns FROM $table $fst3) TO STDOUT WITH DELIMITER ';';";
    }
}

C фильтрацией кириллиц в URL, через конфиг nginx, тоже не всё гладко — нужна нативная конвертация из одной переменной с base64 в другую, с человеко читаемым текстом. На текущий момент, такой директивы нет. Что достаточно странно, ибо в исходниках nginx, функции перекодировки присутствуют.
Как-нить обязательно соберусь с мыслями и ликвидирую это упущение, как и проблему с sed, если коллектив nginx inc этого не решит.

Можно было бы отдавать url строку с аргументами в СУБД, для внутренней генерации динамического запроса в прямом вызове функции или вызове через тригер лог таблицы. Но так как такие данные уже логируются в nginx-access.log — эти инициативы избыточны. А с учетом того, что подобные действия могут увеличить нагрузку на планировщик базы, еще и вредны.

Smokeall FAQ


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

— Работать через диск(client_body_in_file_only) — медленно!
Да прибудет с вами RAM Drive и пророк его — кэш файловой системы.

— Что с правами для пользователей?
Авторизация с plain http пробрасывается в постгрес. Там разруливаете встроенными средствами. В общем полный BackEnd.

— А шифрование?
Модуль ssl через конфиг nginx. На текущем этапе может не взлететь из-за сырости кода ngx_pgcopy.
Соединение nginx c postgres, при разнесении серверов, параноики могут прокинуть через ssh.

— Нахрена символы JS в отражении очков, в начале? Где JavaScript?
JS идёт на FrontEnd. А это уже совсем другое кино.

— Есть ли жизнь на клиенте с отключенным JS?
Как вы вероятно успели заметить ранее, в примерах, Postgres может в xml. Т.е. получить на выходе готовый HTML не составляет проблемы. Как с использованием спагетти кода, так и через xsl схемы.
Это ужасно. Тем не менее, всё будет хорошо. Вы всё правильно делаете.

— Как ресайзить картинки, паковать архивчики и считать траекторию лептонов на GPU?



И так, чтобы попроще.

Может, мне лучше поболтать с этим парнем, подумал я.
Не подходи к FastCGI!
Они только этого от нас и ждут.
Заманить нас в эту коробку,
Cпустить в подвал. Туда.

Говорим ngixу client_body_in_file_only on, берём в охапку $request_body_file и plperlu, с доступом к комадной строке. И адаптируем что-нить из:

CREATE OR REPLACE FUNCTION foo(filename TEXT) RETURNS TEXT AS $$
    return `/bin/echo -n "hello world!"`;
$$ LANGUAGE plperlu;

— Это похоже на CGI. А CGI не безопасен!

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

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

Ссылки


-> ngx_pgcopy
-> PostgreSQL COPY request
-> slim_middle_samples (примеры из статьи + сборка демонстрации)

WARRNING


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

PS. На самом деле, CRUD без проблем реализуется через хранимые процедуры, либо по журналу на метод, к логам не применимо. Еще я метод DELETE в модуль забыл добавить.



В статье использованы кадры и цитаты из х/ф «Страх и ненависть в Лас-Вегасе» 1998г. Материалы применены исключительно с некоммерческими целями и в рамках стимулировании культурного, учебного и научного развития общества.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331056/


Метки:  

[Перевод] Go без глобальных переменных

Пятница, 16 Июня 2017 г. 12:24 + в цитатник

Перевод статьи Дейва Чини — ответа на предыдущий пост Питера Бургона "Теория современного Go" — с попыткой провести мысленный эксперимент, как бы выглядел Go без переменных в глобальной области видимости вообще. Хотя в некоторых абзацах можно сломать язык, но пост достаточно интересный.


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


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


Почему глобальные переменные в пакетах это плохо?


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


Как недавно написал Питер Бургон:


tl;dr магия это плохо; глобальные состояние это магия -> глобальные переменные в пакетах это плохо; функция init() не нужна.

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


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


Ошибки


Одно из самых частых использований глобальных var в публичных пакетах это ошибки — io.EOF, sql.ErrNoRows, crypto/x509.ErrUnsupportedAlgorithm и т.д. Без этих переменных мы не сможем сравнить ошибки с заранее предопределёнными значениями. Но можем ли мы их чем-то заменить?


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


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


Регистрация


Паттерн регистрации используется в нескольких пакетах стандартной библиотеки, таких как net/http, database/sql, flag и немного также в log. Обычно он заключается в глобальной переменной типа map или структуре, которая изменяется некой публичной функцией — классический синглтон.


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


Регистрация также поощряет повторение бизнес-логики. К примеру, пакет net/http/pprof регистрирует себя и, как побочный эффект, net/http.DefaultServeMux, что не совсем безопасно — другой код теперь не может использовать мультиплексор по умолчанию без того, чтобы не светить наружу информацию, которую выдает pprof — и зарегистрировать его на другой мультиплексор не так уж тривиально.


Если бы глобальных переменных в пакетах не было, такие пакеты как net/http/pprof могли бы предоставлять функцию, которая регистрировала бы пути URL для заданного http.ServeMux, и не зависеть от неявного изменения глобального состояния другого пакета.


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


Проверка удовлетворения интерфейса


Есть такая идиома для проверки на принадлежность типа интерфейсу:


var _ SomeInterface = new(SomeType)

Она встречается по крайней мере 19 раз в стандартной библиотеке. По моему убеждению, такие проверки это, по сути, тесты. Они не должны вообще компилироваться, чтобы потом быть убранными при сборке пакета. Их нужно вынести в соответствующие _test.go файлы. Но если мы запрещаем глобальные переменные в пакетах, это относится также и к тестам, так как же мы можем сохранить эту проверку?


Одним из решений было бы вынести это определение переменной из глобальной области видимости в область видимости функции, которая по-прежнему перестанет компилироваться, если SomeType вдруг перестанет удовлетворять интерфейсу SomeInterface


func TestSomeTypeImplementsSomeInterface(t *testing.T) {
       // won't compile if SomeType does not implement SomeInterface
       var _ SomeInterface = new(SomeType)
}

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


func TestSomeTypeImplementsSomeInterface(t *testing.T) {
       var i interface{} = new(SomeType)
       if _, ok := i.(SomeInterface); !ok {
               t.Fatalf("expected %t to implement SomeInterface", i)
       }
}

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


Но не всё так просто


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


Реальные синглтоны


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


package os 

var (
        Stdin  = NewFile(uintptr(syscall.Stdin), "/dev/stdin")
        Stdout = NewFile(uintptr(syscall.Stdout), "/dev/stdout")
        Stderr = NewFile(uintptr(syscall.Stderr), "/dev/stderr")
)

С этим определением есть несколько проблем. Во-первых, Stdin, Stdout и Stderr это переменные типа *os.File, а не io.Reader или io.Writer интерфейсы. Это делает их замену альтернативами достаточно проблематичной. Но даже сама идея их замены это как раз та магия, от которой наш эксперимент пытается избавиться.


Как показал предыдущий пример с константными ошибками, мы можем оставить сущность синглтона для стандартных IO дескрипторов, так чтобы пакеты вроде log и fmt могли использовать их напрямую, но не объявлять их как изменяемые глобальные переменные. Что-то вроде такого:


package main

import (
        "fmt"
        "syscall"
)

type readfd int

func (r readfd) Read(buf []byte) (int, error) {
        return syscall.Read(int(r), buf)
}

type writefd int

func (w writefd) Write(buf []byte) (int, error) {
        return syscall.Write(int(w), buf)
}

const (
        Stdin  = readfd(0)
        Stdout = writefd(1)
        Stderr = writefd(2)
)

func main() {
        fmt.Fprintf(Stdout, "Hello world")
}

Кеши


Второй самый популярный способ использования неэкспортируемых глобальных переменных в пакетах это кеши. Они бывают двух типов — реальные кеши, состоящие из объектов типа map (смотри паттерн регистрации выше) или sync.Pool, и квазиконстантные переменные, которые улучшают стоимость компиляции (прим. переводчика — "шта?")


В пример можно привести пакет crypto/ecsda, в котором есть тип zr, чей метод Read() обнуляет любой буфер, который ему передаётся на вход. Пакет содержит единственную переменную типа zr, потому что она встроена в другие структуры вроде io.Reader, потенциально убегая в кучу каждый раз, когда она объявляется.


package ecdsa 

type zr struct {
        io.Reader
}

// Read replaces the contents of dst with zeros.
func (z *zr) Read(dst []byte) (n int, err error) {
        for i := range dst {
                dst[i] = 0
        }
        return len(dst), nil
}

var zeroReader = &zr{}

Но при этом тип zr не содержит встроенный io.Reader — он сам имплементирует io.Reader — поэтому мы можем убрать неиспользуемое поле zr.Reader, сделав тем самым zr пустой структурой. В моих тестах этот модифицированный тип можно инициализировать явно без потерь в производительности:\


csprng := cipher.StreamReader{
    R: zr{},
    S: cipher.NewCTR(block, []byte(aesIV)),
}

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


Таблицы


И последнее самое частое использование приватных глобальных переменных в пакетах это таблицы — например, в пакетах unicode, crypto/* и math. Эти таблицы обычно кодируют константные данные в виде целочисленных массивов или, чуть реже, простых структур или объектов типа map.


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


Слишком далеко зашли


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


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


  • Во-первых, от использования публичных var определений лучше отказаться. Это не какая-то спорная тема, и она точно не уникальна для Go. Синглтон паттерн лучше не использовать, и мутная публичная переменная, которая может быть изменена в любой момент любым, кто знает её имя — это автоматически сигнал "стоп".
  • Во-вторых, если уж где-то публичная переменная и определятся, то нужно быть крайне внимательным к её типу и постараться, чтобы это было как можно более простая конструкция. Не должно быть такого, что тип, по идее, используется on per instance basis (прим. переводчика — не знаю как это правильно интерпретировать), а мы присваиваем его переменной в глобальной области видимости пакета.

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


  • Приватные переменные с публичными сеттерами (функциями Set()), которые я называю "registries" по сути имеют тот же эффект, что их их публичные аналоги. Вместо того, чтобы регистрировать зависимости в глобальной области видимости, они должны передаваться во время создания с помощью функций конструкторв, литералов, структур с конфигурацией или функций для опций.
  • Кэши в виде переменных типа []byte часто могут быть определены как константы без потерь производительности. Не забывайте, что компилятор очень хорошо оптимизирует вызовы вроде string([]byte) там где они не выходят за рамки функции.
  • Приватные переменные, содержащие таблицы, вроде как в пакете unicode — это неизбежное следствие отсутствия типа константного массива в Go. До тех пор пока они приватные, и не дают никакого способа их менять, их можно считать фактически константами в рамках этого обсуждения.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331048/


Метки:  

У вас есть право на анонимность. Часть 3. Правоприменительная борьба с инструментами анонимности

Пятница, 16 Июня 2017 г. 12:23 + в цитатник
image
В первых двух частях нашего аналитического труда по теме анонимности в интернет-среде и правам граждан при сетевых коммуникациях (ч.1, ч.2) мы поговорили в целом про виды соответствующих цифровых прав нового времени, а также про российские законодательные нормы, которые, к сожалению, всё больше вносят не стимуляцию развития современных технологий и взаимодействия всех субъектов в онлайн-среде, а, наоборот, ведут к их закрепощению и нивелированию.

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

Когда люди не могут доверять законам, они всё больше доверяют технологиям. Наряду с прокси-серверами виртуальные частные сети VPN и луковичная сеть Tor являются самыми популярными средствами достижения анонимности в сети.

Публичный Wi-Fi

Согласно Постановлению Правительства РФ от 31 июля 2014 года № 758 все корпоративные клиенты обязаны предоставлять операторам связи, обеспечивающих доступ к интернету, сведения о лицах, использующих оконечное оборудование (списки работников). Кроме того, Постановлением Правительства от 12 августа 2014 года внесены изменения в правила доступа в интернет в рамках Универсальной услуги связи оператор этой услуги. То есть, к примеру, «Ростелеком», должен будет собирать данные пользователей – ФИО, реквизиты основного документа, удостоверяющего личность, а также объем оказанных ему услуг и время.

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

Действующим законом ответственность за отсутствие идентификации пользователей предусмотрена лишь для оператора связи, который не будет соблюдать новых правил. В марте 2016 года Минкомсвязи предложило дополнить КоАП новым положением о возложении ответственности на администрацию юридических лиц и индивидуальных предпринимателей за «нарушение порядка идентификации пользователей услугами связи по передаче данных и предоставления доступа к информационно-телекоммуникационной сети интернет и используемого ими оконечного оборудования» (штраф для юр.лиц от 100 тыс. до 200 тыс. рублей), однако закон так и не был принят.

Однако, туманность положений Постановлений Правительства, и отсутствие законной обязанности у лиц, не являющихся операторами, осуществлять идентификацию пользователей, не помешало органам прокуратуры начать собственную практику и начать массовое штрафование владельцев открытых Wi-Fi-точек. Владельцев ресторанов и кафе начали еще в 2015 году штрафовать по ч.2 ст.6.17 КоАП РФ, а также выносить в отношении них прокурорские представления об устранении нарушений закона. Формальный повод — это несоблюдение законодательства о защите детей от информации, причиняющей вред их здоровью и развитию. Кроме того, владельцам бизнеса вменяется несоблюдение требований ФЗ «О противодействии экстремистской деятельности».

Инструментарий и анонимайзеры

Как сообщается в тексте заключения Минкомсвязи по делу о блокировке страницы “РосКомСвободы” “понятия «сайт-анонимайзер» и «прокси-сервер» отсутствуют в действующем законодательстве и их применение является юридически некорректным. «Сайт-анонимайзер» и «прокси-сервер» — оценочные определения программ, функционал которых позволяет обойти блокировку сайтов”.

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

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

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

С 2014 года сначала судами южных округов, а затем и многими другими судами по всей территории России по искам региональных прокуроров в защиту неопределенного круга началась массовая практика по блокировке анонимайзеров. Одним из пионеров в списке заблокированных ресурсов стал раздел “Инструментарий” сайта общественной организации “РосКомСвобода”. По решению Анапского городского суда Краснодарского края 13 апреля 2015 года этот раздел был заблокирован. В решении указано, что страница rublacklist.net/bypass является анонимайзером и “с помощью указанного сайта граждане могут получать неограниченный доступ к запрещенным материалам, в том числе и экстремистским, путем анонимного доступа и подмены адресов пользователей”.

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

Множество анонимайзеров (далеко не все!) в реестре запрещенных сайтов можно найти, например, по ключевым словам в написании их доменов:

«proxy»: reestr.rublacklist.net/search/?q=proxy;
«anonim»: reestr.rublacklist.net/search/?q=anonim;
«anonym»: reestr.rublacklist.net/search/?q=anonym.

Наибольшее число решений о блокировках доступа к анонимайзерам вынесли Железнодорожный суд Красноярска и Учалинский районный суд Уфы (Башкортостан). Эти суды приняли, в общей сложности, десять и шесть судебных актов по данной тематике соответственно (по одному решению на каждый анонимайзер). Октябрьский районный суд Ставрополя одним решением постановил заблокировать доступ сразу к 17 анонимайзерам. Ряд анонимайзеров удостоились сразу нескольких судебных решений о блокировке доступа к ним. Так, Jahproxy.com был запрещен решениями Калининского районного суда Уфы, Кировского районного суда Саратова и Ульяновского районного суда Ульяновской области. Аналогичным образом Katvin.com был заблокирован решениями Ульяновского районного суда Ульяновской области, Железнодорожного районного суда Красноярска и Октябрьского районного суда Ставрополя.

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

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

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

Пресс-секретарь Роскомнадзора Вадим Ампелонский.

VPN

VPN (Virtual Private Network) является технологией, позволяющей создать защищённую сеть или туннель внутри незащищённой сети Интернет. VPN представляет собой туннель из VPN-клиента, установленного на компьютере пользователя, и VPN-сервера. В рамках данного туннеля технология VPN позволяет осуществлять защиту, шифрование и изменение данных, которыми обменивается компьютер пользователя и веб-сайты или веб-сервисы в сети Интернет.
Определение из полученного нами письма Минкомсвязи.

Массовые блокировки коммерческих и бесплатных VPN-сервисов пока еще не начались. Однако, известны случаи различного давления на администраторов VPN-сервисов. К примеру, об изъятии собственных серверов сообщил один из крупнейших VPN-провайдеров Private Internet Access (PIA). PIA один из самых популярных VPN-сервисов на рынке. Он предлагает пользователям более 3000 серверов в 18 странах. Сам сервис расположен в США, но управляется через компанию Trust Media Inc, расположенную в Лондоне. Компания разослала пользователям сообщение, где предупредила о скором уходе с российского рынка ввиду принятия “пакета Яровой”.

Сайт сервиса HideMe.ru (ранее HideMy.name), предоставляющего услуги VPN-доступа, был заблокирован по решению Учалинского районного суда Республики Башкортостан от ноября 2016 г., однако сразу доступ к проекту не ограничивался. Изначально решение касалось сервиса анонимизации, расположенного на сайте, который администрацией сайта во исполнение решения суда был удален для пользователей с российских IP-адресов. Но Роскомнадзор, по словам генерального директора компании, предоставляющей сервис, не спешил отзывать блокировку, так как пытался добиться от сервиса VPN HideMe.ru, чтобы он ограничил доступ к ресурсам, внесенным Роскомнадзором в список блокировки, как это делают операторы связи. После отказа это делать, доступ к ресурсу был ограничен.

TOR

Tor (The Onion Router) представляет собой открытое программное обеспечение, позволяющее при помощи системы прокси-серверов устанавливать анонимное сетевое соединение. Использование данной технологии образует анонимную сеть, в рамках которой передача данных осуществляется в зашифрованном виде (пакеты данных шифруются в три этапа, при переходе к каждому новому узлу), что обеспечивает конфиденциальность передачи данных и сетевых соединений”.
Определение взято опять-таки из письма Минкомсвязи.

В России, в отличие от Китая, до настоящего времени не осуществляется блокировка сайта torproject.org, с которого можно скачать дистрибутивы, а также иных служебных серверов Tor и не применяются какие-либо специальные меры контроля и лицензирования к промежуточным и выходным реле, которые запускают сами пользователи. Нет и каких-либо законодательных ограничений для использования технологии луковичного маршрутизатора и использования .onion-сети.

Организация Electronic Frontier Foundation (EFF) обращает внимание, что хотя полагается, что эксплуатация Tor-узла является абсолютно законной, «статистически вероятно, что реле выхода в какой-то момент будет использовано в незаконных целях, что может привлечь внимание частных сторон или правоохранительных органов».

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

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

На одном из российских сайтов в сети мы нашли сообщение от 2015 года, что владельца exit-node приглашали побеседовать из ФСБ. Дело касалось электронного сообщения о заложенном в аэропорту Внуково взрывном устройстве. После предоставления ноутбука на добровольной основе был сделан рапорт, что ничего не обнаружено. Ноутбук был возвращен владельцу, уголовного преследования не состоялось. Некоторые шифропанки из сообщества cypherpunks.ru также сообщали, что им неоднократно задавали вопросы силовые структуры в связи с использование выходных узлов Tor и даже привлекали к таким делам в качестве экспертов для разъяснения особенностей работы сети.

Однако в апреле 2017 в рамках рейда по предотвращению незаконного массового мероприятия внезапно был осуществлен арест администратора одного из 37 выходных узлов в России математика Дмитрия Богатова, который дал понимание, что российская правоприменительная практика по использованию и поддержке Tor не такая уж безобидная. Он был задержан за организацию массовых беспорядков и за призывы к терроризму, к которым по факту он не имеет никакого отношения. Несмотря на обоснованное расследование независимого исследователя, и множество обстоятельств, указывающих на то, что Дмитрий точно не является “Айрат Башировым”, с аккаунта которого размещались публикации, следствие продолжает игнорировать факты и держит Богатова под стражей.

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

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

Публикации:

Часть 1. Введение и мировая практика
Часть 2. Законодательство против анонимности
Часть 3. Правоприменительная борьба с инструментами анонимности
Часть 4. Мировой опыт борьбы с Tor и VPN
Часть 5. (в разработке)

Подготовлено:
Саркис Дарбинян, Артём Козлюк, Алёна Рыжикова для Центра защиты цифровых прав
Стоит ли выделять и регламентировать в законе право граждан на анонимность?

Проголосовало 53 человека. Воздержалось 6 человек.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330978/


Android Excellence на Google Play

Пятница, 16 Июня 2017 г. 12:22 + в цитатник
Кейси Фэи, отдел маркетинга для разработчиков, Google Play

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

Чтобы особенным образом отметить лучшее на Google Play, мы решили запустить Android Excellence. В новых коллекциях будут представлены игры и приложения, которые дают непередаваемый пользовательский опыт. Они сформированы на основе наших лучших практик и оптимизированы для различных устройств, а также отличаются прекрасным дизайном, производительностью и качественным переводом.

Коллекции Android Excellence будут обновляться раз в квартал. Их можно найти в разделе Выбор редакции в Google Play. Он включает приложения и игры, отобранные нашей командой. Взгляните на первую группу игр и приложений Android Excellence.

Чтобы добиться успеха в Google Play, следуйте нашим рекомендациям по качеству. С последними новостями и видео для разработчиков можно ознакомиться в тестовой версии приложения Playbook for Developers.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331046/


Метки:  

[Из песочницы] Лайфхаки редактора Unity 3D. Часть 1: Атрибуты

Пятница, 16 Июня 2017 г. 11:36 + в цитатник


Предисловие


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

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

Встроенные атрибуты


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

Атрибуты к методам


Элемент меню

Скриншотики


[MenuItem("Tools/Initialization Project")]

Позволяет создать меню для доступа к статическому методу. Через “/” указывается иерархия. Можно располагать новые кнопки в стандартном главном меню движка, указывая путь, например “File/Create New Asset”.

Всего может содержать три параметра.

string path //полный путь в меню
bool valudate //является ли данный метода валидатором функции (делает пункт меню неактивным)
int order //порядок расположения элемента в рамках одной иерархии

[MenuItem("Tools/Initialization Project", true)]
public static bool Initialization()
{
    //просто проверка на то, что выделен любой объект
    return Selection.gameObjects.Length > 0;
}

[MenuItem("Tools/Initialization Project")]
public static void Initialization()
{
    //do something...
}

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

Атрибуты к переменным


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


Ограничение вводимого значения

[Range(float min, float max)]

Можно сказать, это кастомный редактор для атрибута, который позволяет задать границы задаваемого значения через инспектор. Не клампит в реалтайме — только в инспекторе. Полезно, если задаете, например, вероятность выпадения предметов от 0 до 1 или от 0 до 100.

Подпись

[Header(string title)]

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

Отступ

[Space]

Задает отступ в инспекторе.

Всплывающая подсказка

[Tooltip(string tip)]

Задает подсказку в инспекторе при наведении на сериализуемую переменную.

Сериализация переменных

[SerializeField]

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

Запрет сериализации

[NonSerialized]

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

Скрытие переменной в инспекторе

[HiddenInInspector]

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

Атрибуты к классам


Исполнение в редакторе

[ExecuteInEditMode]

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

Например, в качестве инициализатора сериализуемых полей встроенных типов, типа transform, renderer, rectTranform и т.п. Не рекомендовал бы повсеместно, лучше требовать ручной инициализации, либо написать редакторский скрипт, но иногда удобно.

Необходимость существования другого компонента

[RequireComponent(System.Type type)]

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

Новый элемент в меню добавления компонента

[AddComponentMenu(string path)]

Добавляет подменю в выпадающий список в меню Components ->… и AddComponent. Удобно, если у вас большая библиотека кода и нужно организовать её в редакторе.

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

Кастомные атрибуты (CustomPropertyDrawer)


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

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

public class IntAttribute : PropertyAttribute
{
    private string path = “”;

    public IntAttribute(string path)
    {
        this.path = path;
    }
}

Во-вторых, после этого создаем скрипт редактора, в котором будем рисовать этот самый новый класс. Его нужно унаследовать от PropertyDrawer, а также написать к нему атрибут CustomPropertyDrawer.

[CustomPropertyDrawer(typeof(IntAttribute ))]
public class IntAttributeDrawer : PropertyDrawer
{
}

Я называю классы наиболее общими наименованиями, дабы просто показать принцип использования настраиваемых.

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

Например, у вас есть база эффектов, у которой есть соответствие id -> эффект. Вы храните где-то эту базу, неважнов ScriptableObject’e или на каком-то префабе. Вот простейшая реализация “хранилища”

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

Код


Для классов, с которыми я взаимодействую “извне”, я всегда пишу интерфейс. У каждого свой подход к этому моменту, но данный подход легко позволит, в случае чего, подменить класс только в одном месте на другой, а остальные так и будут работать с интерфейсом. Тем более, юнити поддерживает работу с интерфейсами в таких методах, как GetComponent(s)…, GetComponent(s)InChildren и т.п.

Интерфейс и класс эффекта

public interface IResource
{
    int ID
    {
        get;
    }
 
    string Name
    {
        get;
    }
}
 
[System.Serializable]
public class Effect : IResource
{
    [SerializeField]
    private string name = “”;
    [SerializeField]
    private int      id = 0;
 
    public int ID
    {
        get
        {
            return id;
        }
    }
 
    public string Name
    {
        get
        {
            return name;
        }
    }
}

Интерфейс и класс контейнера

public interface IContainer
{
    IResource[] Resources
    {
        get;
    }
}
 
public abstract class ResourcesContainer : MonoBehavior, IContainer
{
    public virtual IResource[] Resources
    {
        get 
        {
            return null;
        }
    }
}
 
public class EffectsContainer : ResourcesContainer 
{
    [SerializeField]
    private Effect[] effects = null;
    
    public override IResource[] Resources
    {
        get 
        {
            return effects;
        }
    }
}

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

Редактор
Осталось дописать редактор:

[CustomPropertyDrawer(typeof(IntAttribute ))]
public class IntAttributeDrawer : PropertyDrawer
{
    protected string[]  values = null;
    protected List idents = null;
 
    protected virtual void Init(SerializedProperty property)
    {
        if (attribute != null)
        {
            IntAttribute intAttribute = (IntAttribute)attribute;
            //можно ввести проверки на null, но, я думаю, вы сами справитесь
            IResource[] resources = Resources.Load(intAttribute.Path).Resources;
            values = new string[resources.Length + 1];
            idents = new List(resources.Length + 1);
           
            //добавляем нулевой элемент для назначения -1 значения
            values[0] = “-1: None”;
            idents.Add(-1);
            for (int i = 0; i < resources.Length; i++)
            {
                values[i+1] = resources[i].ID + “: ” + resources[i].Path;
                idents.Add(resources[i].ID);
            }
        }
    }
 
    public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
    {
        if (property == null)
        {
            return;
        }
 
        Init(property);
        EditorGUI.BeginProperty(position, label, property);
 
        // Draw label
        position = EditorGUI.PrefixLabel(position, GUIUtility.GetControlID(FocusType.Passive), label);
 
        // Don't make child fields be indented
        int indent = EditorGUI.indentLevel;
        EditorGUI.indentLevel = 0;
 
        // Calculate rects
        Rect pathRect = new Rect(position.x, position.y, position.width - 6, position.height);
 
        int intValue = property.intValue;
        intValue = idents[EditorGUI.Popup(pathRect, Mathf.Max(0, idents.IndexOf(intValue)), Values)];
        property.intValue = intValue;
 
        EditorGUI.indentLevel = indent;
 
        EditorGUI.EndProperty();
    }
}

Располагаем префаб или ScriptableObject по нужному нам пути (я расположил в Resources/Effects/Container). 

Теперь в любом классе объявляем целочисленную переменную и атрибут к ней с путем до префаба.
 
public class Bullet : MonoBehavior
{
    [SerializeField]
    [IntAttribute(“Effects/Container”)]
    private int effectId = -1;    
}

Скриншот с атрибутом


Заключение


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

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

CustomEditor;
CustomPropertyDrawer;
EditorWindow;
Класс Debug и как его едят;
Класс Gizmos.

А также дополню примеры окном и пользовательским редактором. Пишите в комментариях, нужны ли подобные статьи или можно обойтись тем, что уже есть на Хабре.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331042/


Метки:  

Использование SpreadsheetCloudAPI для написание приложений и облегчения жизни

Пятница, 16 Июня 2017 г. 11:31 + в цитатник

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


image


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


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


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


В процессе обдумывания идеи приложения, нам под руки попался сервис, который бы написан нашими клиентами, с использованием нашего же Spreadsheet Document Server: SpreadsheetCloudAPI. Он по сути позволит использовать наш текущий Excel файл, как базовую часть приложения, и вообще не думать над хранением данных и логикой вычислений. К тому же он бесплатный.


Итак, что нам надо получить от приложения:


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

В итоге UI, который нам хочется получить должен выглядеть примерно так:


image


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


Расчет расходов


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


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


Реализация


Backend


По сути наш бэкэнд не будет делать ничего, кроме общения со SpreadsheetcloudAPI сервисом: он передает введенные данные в него, и принимает пересчитанные части документа обратно. Для реализации серверной части был выбран php.


Для общения с сервисом нам необходимо всего три параметра:



Для удобства работы мы собрали их все в один класс:


class PrivateConst {
     const Base_Url = 'http://spreadsheetcloudapi.azurewebsites.net/api/spreadsheet';
     const API_KEY = 'API_KEY';
     const File_Name = '3D.xlsx';
}

Общение с сервисом будет происходить по Web API. В принципе API там достаточно простое и нормально документировано. Например, для добавления ячеек в таблицу (что нам надо при создании новой записи о печати) надо просто послать JSON вида:


{
"id": "some_id",
"filename": "test",
"extension": "xls",
"sheetindex": 0,
"sheetname": "Sheet1",
"startrowindex": 0,
"startcolumnindex": 0,
"endrowindex": 3,
"endcolumnindex": 5,
"mode": "ShiftCellsDown",
"formatmode": "FormatAsPrevious"
}

на /api/spreadsheet/insertcells через PUT запрос.


При получении данных нам удалось даже схалявить, так как сервис умеет сам отдавать нам требуемые ячейки в HTML формате (Export to HTML). В результате нам даже не приходится задумываться о том, как отображать данные из документа. Получение этого HTML тоже трудностей не составляет:


function getSessionHtml($id, $sheetName, $rowLimit, $columnLimit){
        $params = array(
            'id' => $id,
            'sheetname' => $sheetName,
        );
        if($rowLimit > -1){
            $params['endrowindex'] = $rowLimit;
        }
        if($columnLimit > -1){
            $params['endcolumnindex'] = $columnLimit;
        }
        $request = get($params, '/exporttohtml');
        return $request;
    }

где get, это наш метод, отправляющий GET запрос с переданными параметрами на переданный адрес.


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


Frontend


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


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


image


Конечно же данные можно редактировать:


image


Колонка «Cost» редактироваться не будет, она будет вычисляться непосредственно на сервисе и заполняться при экспорте.


На вкладке «Materials» никаких вычислений не производится, мы только задаем значения:


image


image


На вкладке «Users» единственный параметр который мы будем создавать и изменять — это имя пользователя. Колонка “Full Cost” будет вычисляться и не предназначена для редактирования. Вишенкой на торт мы решили показать чарт, который наглядно отображает, кто же у нас самый печатающий. Чарт тоже рисуется Excel-ем, а мы его грузим просто картинкой с сервиса.


image


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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331032/


Метки:  

Чем отличается Ubuntu от Debian

Пятница, 16 Июня 2017 г. 11:10 + в цитатник
Что выбрать для личного использования? Debian или Ubuntu, это зависит от ваших личных предпочтений, поддержки вашего аппаратного обеспечения, ваших навыков по настройке системы, простота использования и другие ключевые вопросы.

Debian и Ubuntu — это наиболее влиятельные из когда-либо существовавших дистрибутивов. Из 285 активно использующихся дистрибутивов 132 основаны на Debian и в том числе 67 на Ubuntu. Тем не менее использование обоих этих дистрибутивов очень сильно отличается. Поэтому сделать выбор Ubuntu или Debian не так то просто.

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

Точно так же Ubuntu считают более простой в настройке из-за ее дизайна. Но это не совсем правильно.

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

Отличия в процессе установки


Ваш выбор может зависеть от используемого оборудования. Debian поддерживает около 13-ти аппаратных архитектур начиная от самой распространенной 32 и 64 битной для процессоров AMD и Intel до ARM и PowerPC. Ubuntu же поддерживает 32 и 64 битные версии, как отдельные редакции дистрибутива, а также работает на ARM версией для планшетов и смартфонов.

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

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

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

Отличия в администрировании и управлении пакетами


Не удивительно, что Debian и Ubuntu используют учетную запись суперпользователя для администрирования и обычную учетную запись для повседневного использования системы. Но выбранные модели безопасности это заметное отличие debian от ubuntu.

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

Есть три основных репозитория пакетов в Debian: тестовый (Testing), стабильный (Stable) и нестабильный (Unstable). Все новые пакеты поначалу находятся в тестовом репозитории, а уже после проверки и тестирования переводятся в стабильный. С каждым официальным релизом пакеты из репозитория Testing переносятся в репозиторий Stable.

За последние несколько лет было добавлено еще несколько официальных и неофициальных репозиториев: Backports, Experimental, Security, Old Stable, и Update. Тем не менее использовать в большинстве случаев лучше только три основных.

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

Ubuntu же берет свои пакеты из тестового или нестабильного репозитория Debian. В отличие от Debian репозитории Ubuntu организованы немного по другому принципу. В Главном (Main) репозитории находятся пакеты, поддерживаемые Canonical, в репозитории Universe — программное обеспечение, поддерживаемое сообществом, Restricted — содержит проприетарные драйвера, а Multiverse программное обеспечение с несвободными лицензиями.

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

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

Различия в окружении рабочего стола


Ubuntu и Debian по умолчанию используют различные окружения рабочего стола. Ubuntu использует по умолчанию Unity, оболочку рабочего стола от Canonical — корпоративного спонсора Ubuntu, который поддерживает ее развитие на протяжении многих лет. Если у Canonical получится завоевать рынок мобильных устройств, возможно, в будущем вы сможете использовать Unity также на смартфонах и на планшетах.

Тем не менее и Ubuntu и Debian, поддерживают несколько окружений рабочего стола. Ubuntu распространяется в нескольких редакциях: Xubuntu, с рабочим столом Xfce, Kubuntu — с KDE также есть Ubuntu GNOME и Ubuntu для планшетов.

В Debian можно выбрать те же самые окружения, но развиваются они не настолько отдаленно от стандартного Debian.

За исключением Unity, все программы, написанные для Ubuntu, доступны и для Debian. Правильно и обратное — все программы, написанные для Debian — работают в Ubuntu, поскольку ее пакеты берутся из репозиториев Debian. В Debian, цикл разработки намного медленнее, поэтому в Ubuntu, всегда свежее программное обеспечение, но зато Debian лучше протестирован и более стабилен.

Замечание. Не думайте, что общее происхождение пакетов делает их кросс-совместимыми для Ubuntu и Debian. Около 20% всех пакетов Ubuntu несовместимы с Debian из-за различного расположения файлов.

Различия сообществ


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

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

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

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

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

Так что же выбрать?


Эксперт или новичок? Свободное ПО или проприетарное? Простота использования или полный контроль? Поддержка платформ? Шаткая грань или стабильность? Unity или GNOME? Контролируемое но вежливое сообщество или резкое, но демократическое?

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

Независимо от того, какой дистрибутив вы выберите, помните Ubuntu и Debian не просто так стали самыми популярными дистрибутивами.



Оригинал статьи. M.el Khamlichi
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331040/


Метки:  

[Перевод] Метрика загруженности процессора (CPU utiliztion) — это не то что вы думаете

Пятница, 16 Июня 2017 г. 10:24 + в цитатник

Всем привет. Предлагаю вашему вниманию свой перевод поста "CPU Utilization is Wrong" из блога Брендана Грегга.


Метрика загруженности процессора (CPU utiliztion), которую все мы привыкли использовать, обычно понимается неправильно. Что такое загруженность процессора? То насколько процессор сейчас занят работой? Нет, это не так, и да, я говорю о метрике %CPU, которая используется всегда и везде, в каждой утилите мониторинга производительности, например в top(1).


Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже?



Вот что это значит на самом деле:



Stalled, то есть "приостановлено" значит, что в данный момент процессор не обрабатывает инструкции, обычно это означает, что он ожидает завершения операций ввода/вывода связанных с памятью (здесь и далее речь о RAM, а не дисковом вводе/выводе). Соотношение между "занято" и "приостановлено" (busy/stalled), которое я привел выше, это то что я обычно вижу в продакшене. Вероятно, что ваш процессор тоже большую часть времени находится в stalled состоянии, но вы об этом и не догадываетесь.


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


Что такое нагрузка на процессор на самом деле?


Метрика, которую мы называем нагрузкой на процессор (CPU utilization) на самом деле это "не-idle время", то есть время, которое процессор не выполняет idle-тред. Ядро вашей операционной системы (какую бы ОС вы не использовали) обычно следит за этим во время переключения контекста. Если не-idle тред запустился, а затем спустя 100 милисекунд остановился, то ядро посчитает, что процессор был использован в течение всего этого времени.


Эта метрика так же стара как и системы совместного использования времени (time sharing systems). В бортовом компьютере лунного модуля Apollo (это пионер среди систем совместного использования времени) idle-тред назывался "DUMMY JOB" и инженеры мониторили циклы выполняющие его в сравнении с реальными задачами, это было важной метрикой измерения нагрузки. (Я писал об этом ранее).


Что же с этой метрикой не так?


В наши дни процессоры работают значительно быстрее памяти, поэтому время ожидания памяти доминирует в метрике "нагрузка на процессор". Когда вы видите большие значение %CPU в top(1), вы, должно быть, думаете, что процессор является бутылочным горлышком, когда на самом деле проблема в DRAM.


Со временем все становится только хуже. Долгое время производители процессоров увеличивали тактовые частоты своих процессоров быстрее чем производители памяти уменьшали задержки доступа к памяти (CPU DRAM gap). Примерно в 2005 году процессоры достигли частот в 3 GHz и с тех пор мощность процессоров растет не за счет увеличения тактовой частоты, а за счет большего числа ядер, гипертрединга и многопроцессорных конфигураций. Все это предъявляет еще больше требований к памяти. Производители процессоров пытались снизить задержки связанные с памятью за счет больших по размеру и более умных CPU-кешей, более быстрых шин и соединений. Но проблема со stalled-состоянием все еще не решена.


Как понять, что процессор на самом деле делает


Сделать это можно используя Performance Monitoring Counters (PMC-счетчики): хардверные счетчики, которые могут быть прочитаны с помощью Linux pref (пакет linux-tools-generic в Линуксе) и других утилит. Для примера понаблюдаем за всей системой в течение 10 секунд:


# perf stat -a -- sleep 10

 Performance counter stats for 'system wide':

     641398.723351      task-clock (msec)         #   64.116 CPUs utilized            (100.00%)
           379,651      context-switches          #    0.592 K/sec                    (100.00%)
            51,546      cpu-migrations            #    0.080 K/sec                    (100.00%)
        13,423,039      page-faults               #    0.021 M/sec                  
 1,433,972,173,374      cycles                    #    2.236 GHz                      (75.02%)
         stalled-cycles-frontend  
         stalled-cycles-backend   
 1,118,336,816,068      instructions              #    0.78  insns per cycle          (75.01%)
   249,644,142,804      branches                  #  389.218 M/sec                    (75.01%)
     7,791,449,769      branch-misses             #    3.12% of all branches          (75.01%)

      10.003794539 seconds time elapsed

Ключевая метрика здесь instructions per cycle (insns per cycle: IPC, число инструкций за один цикл), которая показывает сколько в среднем инструкций было выполнено за каждый такт. Чем больше, тем лучше. В примере выше значение 0.78 кажется очень неплохим (нагрузка 78%?) до тех пор пока вы не узнаете, что максимальная скорость процессора это IPC 4.0. Такие процессоры называют 4-wide, это название пошло от особенностей пути извлечения/декодирования инструкций в процессоре (подробнее об этом в Википедии).


Это означает, что процессор может выполнить 4 операции за каждый такт, поэтому значение 0.78 для 4-wide системы означает, что процессор работает на 19,5% от своих возможностей. Новый процессор Skylake от Intel — это 5-wide процессор.


Существуют сотни PMC-счетчиков, которые позволяют детальнее разобраться с производительностью системы, например, посчитать число приостановленных циклов по типам.


В облаках


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


Как интерпретировать и что делать


Если ваш IPC < 1.0, то вероятнее всего, процессор приостановлен из-за медленной памяти, поэтому нужно оптимизировать софт так, чтобы он требовал меньше операций с памятью, совершенствовать кеширование в процессоре и локальность памяти, особенно в NUMA системах. Оптимизация железа в таком случае подразумевает использование процессоров с большим объемом кешей, более быстрой памятью, шинами и соединениями.


Если ваш IPC > 1.0, то вероятно, вы ограничены числом инструкций, которые может выполнять процессор. Попробуйте найти способ уменьшить число выполняемых инструкций: уменьшить число ненужной работы, кешировать операции и т.п. CPU flame графы — отличная утилита для этих целей. С точки зрения тюнинга железа, попробуйте использовать процессор с большей тактовой частотой и большим числом ядер и гипертредов.


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


Что инструменты мониторинга производительности должны сообщать вам?


Каждая такая утилита должны показывать IPC вместе с нагрузкой на процессор. Или разделять нагрузку на процессор на instruction-retired и циклы stalled циклы, то есть, %INS и %STL.


Кроме утилиты top(1) для Линукса есть утилита tiptop(1), которая показывает IPC для каждого процесса:


tiptop -                  [root]
Tasks:  96 total,   3 displayed                               screen  0: default

  PID [ %CPU] %SYS    P   Mcycle   Minstr   IPC  %MISS  %BMIS  %BUS COMMAND
 3897   35.3  28.5    4   274.06   178.23  0.65   0.06   0.00   0.0 java
 1319+   5.5   2.6    6    87.32   125.55  1.44   0.34   0.26   0.0 nm-applet
  900    0.9   0.0    6    25.91    55.55  2.14   0.12   0.21   0.0 dbus-daemo

Другие причины почему CPU utilization вводит в заблуждение


Проблема со stalled-циклами может быть не только в задержках связанных с памятью:


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


Заключение


Нагрузка на процессор (CPU utilization) это обычно неправильно интерпретируемая метрика, так как она включает циклы, потраченные на ожидание ответа от основной памяти, которые могут доминировать в современных нагрузках. Вы можете понять что на самом деле стоит за %CPU используя дополнительные метрики, включая число инструкций за цикл (IPC). Если IPC < 1.0, то вероятно вы упираетесь в память, если IPC > 1.0, то в скорость процессора. Я писал про IPC в своем предыдущем посте, в том числе написал и о использовании PMC-счетчиках, необходимых для измерения IPC.


Инструменты мониторинга производительности, которые показывают %CPU должны показывать PMC-счетчики, чтобы не вводить пользователей в заблуждение. Например, они могут показывать %CPU с IPC и/или число instruction-retired и stalled циклов. Вооруженные этими метриками разработчики и админы могут решить как правильнее тюнинговать их приложения и системы.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331004/


Метки:  

История разработки и жизни одной маленькой игры. Начало

Пятница, 16 Июня 2017 г. 10:08 + в цитатник
Мне нравиться читать подобные статьи, иногда в них удается почерпнуть хорошие идеи, иногда они вдохновляют, а иногда просто приятное пятничное чтиво про таких же разработчиков. Я решил поведать о своем тернистом пути инди разработчика и рассказать о создание своей небольшой игры и поделиться крупинками опыта.

Шел 2013 год, я был искушен разработкой игр, я был молод и любил велосипеды…
На тот момент у меня уже была одна игра в моем активе, но это было не серьезно. Эта игра была написана с одной целью – довести её до релиза и этой цели она достигла.
Видео игры




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

У меня уже был не плохой опыт в XNA по части 2д, а также в мобильной разработке на платформе Windows Phone. Разработку новой игры я решил начать с изучения Windows Phone Marketplace, на предмет вакантных мест, с подходящим уровнем сложности. Выбор мой пал на игры подобные «Hill Climb Racing». На тот момент – октябрь 2013 года, «Hill Climb Racing» в магазине приложений не было, были аналоги с убогой графикой и очень примитивные. После небольших раздумий, было решено делать игру с похожей механикой «Hill Climb Racing», но с измененным геймплеем в сторону грузоперевозки, игроку нужно перевезти из точки А в то Б некий груз.
Создание подобной игры, требует использование или создание удобного редактора физики. Unity тогда была как-то не на слуху, да и другие игровые движки стоили денег, которых не было. Ну и конечно зачем брать готовые решения, когда можно все сделать самому?!
При этом Windows Phone обновился до 8 версии, да и разработка под WinRT казалась очень привлекательной. Поэтому я решил мигрировать с XNA на Monogame.

План был такой:
• Конец октября, разработанный концепт игры, начало работ над игровым прототипом.
• Ноябрь, привлечение дизайнера и работа над игровым прототипом. Рисовать к сожалению я вообще не умею, а один из упоров в игре я собирался делать на графический контент.
• Конец ноября, готовый прототип игры.
• Начало декабря, создания музыкального контента, создание игрового процесса, создание игрового контента, тестирование игры, работа над балансом в игре.
• Середина декабря, подключение платежных систем, предрелизная подготовка, создание обзоров и подготовка к рекламной компании.
• Крайний срок релиза 20 декабря.

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

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

Если с физическим движком я определил сразу – им стал Farseer. То вот с GUI под XNA было все намного сложнее, существующие решения оставляли желать лучшего, с одной стороны их было довольно много, а с другой у них у всех были своя куча минусов. В результате я решил написать свою, а за основу взять подходы библиотеки generalhi GPF и XAMLite, основная причина по которой я взялся за это – куча различных наработок, опыт прошлой игры, где все было самописное. В первую очередь, мне было жалко свои труды, и я хотел объединить их в одно целое и продолжил развивать. За пару очень сложных месяцев я получил:
Редактор физики




Система частиц




GUI (на видео вторая версия GUI)




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

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

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

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



эскизы первых блоков




Запускать игру без серверной части я посчитал плохой идей, а основная цель развития игры была в сторону реал-тайм заездов с другими игроками. В качестве базы данных была использована MongoDB, а в качестве транспорта был использован UDP. Был написан свой бинарный протокол общения с сервером. Сервер был максимально заточен на производительность. На момент релиза он отвечал за регистрацию пользователей, за сбор игровых логов о заездах и на основе их формируется рейтинг, за начисление ежедневного бонуса, за начисления и разблокировки игрового функционала.
В целом сервер сыграл свою роль в решении негативных ситуаций с пользователями, путем начисления компенсации игровой валютой, а также сбор аналитики.
Серверный проект был разделен на две части: общую, которую можно будет использовать для других проектов, с возможностью расширения и добавления своих типов данных и их обработчиков и для текущего проекта, и частную для данной игры.
В ходе тестирование сервера на ботах, нормальное максимальное время выполнения серверного тика 100мс, в среднем это обработка около 500 пакетов в тик, что позволяет обрабатывать больше 10 000 единовременных подключений.

Весь графический контент рисовался в векторе, а уже после нарезался под разрешение 1280*768 и упаковывался в текстурные атласы. И уже на конечной стадии разработки стало понятно, что мы вышли за в 90мб для устройств WP71 и поэтому пришлось выходить только на WP80. Сделать графический контент под разрешение 800*480 не проблема, но вот все переупаковывать, переписывать ключи, убило бы кучу времени, поэтому решили отказаться от WP71. А в 2014 году процент устройств WP71 был довольно большой.
проработка первой карты


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

Тернистый путь разработки удалось завершить только в сентябре 2014 года.
Игра вышла в свет на платформе WP8 с 5 ландшафтами, в последствии их количество было доведено до 7. За заезд начисляются монеты, размер полученной прибыли зависит от количества перевезенных камней, от вида камней, от времени прохождение, как далеко были увезены камни и еще нескольких факторов. Так же мы сделали 9 различных машин, которые можно купить за игровую валюту, но их нельзя было как-либо модифицировать, посчитав, что это не нужных функционал, но об этом в следующей статье…
промо игры




Выводы:
Как можно меньше цепляйтесь за старое, оно может тянуть вас назад, старайтесь смотреть вперед, если что-то хорошо на текущий момент, то возможно через n месяцев разработки оно будет не актуально.
Как говорится —
дорога ложка к обеду
На конец 2013 года данная игра была востребована, а вот на конец 2014 – уже мало, тк летом 2014 вышел «Hill Climb Racing» и другие игры.
Я конечно получил бесценный опыт, но хотелось немного большего…

Пишите в комментариях каким аспектам стоит уделить больше внимания или вообще рассказать подробно.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330790/


Метки:  

О потребителях и типах Threat Intelligence

Пятница, 16 Июня 2017 г. 09:50 + в цитатник

Раз в два-три года в «информационно-безопасном» мире появляется панацея от всех бед, которая защитит и от киберпреступников, и от киберактивистов, от промышленного шпионажа и APT-атак. Все установленные ИБ-системы объявляются морально устаревшими и никуда не годными, их предлагается срочно заменить. Естественно, не бесплатно. За чудо-лекарством выстраиваются очереди, лицензий на всех не хватает. А потом продавец просыпается.


Очень похожая ситуация сейчас складывается с Threat Intelligence. Это очень модно, драйвово, молодёжно, но провайдеры, пользователи и покупатели зачастую понимают под TI совсем разные вещи.



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


Что такое Threat Intelligence


Threat Intelligence — это регулярно и системно собирать информацию об угрозах, улучшать и обогащать её, применять эти знания для защиты и делиться ими с теми, кому они могут быть полезны. TI — это не только базы сигнатур для IDS или наборы правил для SIEM. TI — это процессы, у которых есть владельцы, цели, требования и понятный и измеримый (насколько это возможно) результат. TI я буду понимать именно в этом смысле.


Стоит сказать, что до 2014 года никакой threat intelligence не было. Ну, то есть была, конечно, но такое впечатление складывается, когда смотришь на темы выступлений более ранних RSA Conference.


А потом начался настоящий TI-бум! В моём списке компаний и организаций, которые предлагают приобрести или обменяться информацией об угрозах, злоумышленниках и вредоносном коде, 126 строк. И это далеко не все. Три года назад аналитики международных исследовательских компаний на вопрос о размере рынка TI отвечали: «Отстаньте! Нет такого рынка. Считать нечего». Теперь они же (451 Research, MarketsandMarkets, IT-Harvest, IDC и Gartner) оценивают этот рынок в полтора миллиарда долларов в 2018 году.


Прогноз 2013 2014 2015 2016 2017 2018 2019 2020 Годовой рост, %
451 Research 1,0 3,3 34,0
MarketsandMarkets 3,0 5,86 14,3
IT-Harvest 0,25 0,46 1,5 80,0
IDC 0,9 1,4 11,6
Gartner 0,25 1,5 43,1

Почему выгодно адаптировать процессы TI?


Ускоряет реагирование на инциденты информационной безопасности


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


Помогает расставить приоритеты


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


В 2015 году SANS Institute провёл исследование потребителей TI из различных отраслей, в котором участвовали 329 респондентов из Северной, Центральной и Южной Америки, Европы, Ближнего Востока и Австралии. Согласно этому исследованию, потребители TI фиксируют положительные изменения в нескольких направлениях обеспечения ИБ после внедрения процессов TI.


image


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


image

Только в 10% случаев в организациях нет планов развивать разведку киберугроз внутри компании или о таких планах не известно.


Типы Threat Intelligence


Глобально существует два типа TI — стратегическая и тактическая (или «техническая» — кому как нравится). Они сильно отличаются и по результатам, и по способам использования этих результатов.


Признак Стратегическая TI Техническая TI
Форма Отчёты, публикации, документы Наборы правил, параметры настройки
Создаётся Людьми Машинами или людьми совместно с машинами
Потребляют Люди Машины и люди
Сроки доставки до потребителя Дни — месяцы Секунды — часы
Период полезности Долгий (год и более) Короткий (до появления новой уязвимости или нового метода эксплуатации)
Допущения Гипотезы возможны, однако они должны основываться на каких-то данных Неприемлемы, поскольку машины не понимают нечётких инструкций
Фокус Планирование, принятие решений Обнаружение, приоритизация, реагирование

Потребители Threat Intelligence


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


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


Уровень управления
Операционный уровень
В долгосрочной перспективе
СТРАТЕГИ

Высшее руководство (Совет директоров)

Высокоуровневая информация об изменяющихся рисках


  • Финансовые аспекты вредоносной киберактивности, бюджетирование.
  • Тренды угроз и атак.
  • Киберриски.

ТЕХНИКИ

Архитекторы и сисадмины

Тактики, техники, процедуры (TTP)

  • Инструменты, ПО и «железки» атакующих.
  • Цели атак — конкретные объекты ИТ-инфраструктуры.
  • Эксплойты и методы защиты.
  • Рекомендации по приоритизации установки обновлений.

В краткосрочной и долгосрочной перспективе
ТАКТИКИ

Руководители служб ИБ

Детали конкретных готовящихся и проводимых атак

  • Что?
  • Кто?
  • Зачем? (Задачи атакующих)
  • Чего хотят? (Защищаемые информационные ресурсы)
  • Где?
  • Когда?
  • Какими ресурсами и возможностями располагают?
  • Как общаются между собой?
  • Как маскируются?
  • Какие события, которые могут повлиять на окружение организации, произошли или могут произойти?
  • Способы выявления угроз.
  • Способы противодействия актуальным угрозам.

ОПЕРАТОРЫ

Сотрудники ИБ, персонал SOC (Центра мониторинга), группа реагирования на инциденты, forensics-персонал

Индикаторы атак и компрометации

  • Образцы вредоносного или подозрительного кода.
  • Хэш-суммы образцов вредоносного или подозрительного кода.
  • YARA-rules.
  • Изменения ключей реестра.
  • Появление файлов, связанных с активностью вредоносного кода.
  • Фиды вредоносных IP-адресов.
  • IP-адреса и домены Command & Control.
  • Данные о репутации IP и доменов.
  • Узлы анонимных сетей.
  • Почтовые индикаторы (темы писем, адреса, домены).
  • Векторы атак.
  • Изменения количества ресурсов, используемых для атак.
  • Стадии развития атак.
  • Способы совершения преступлений.


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


Провайдеры Threat Intelligence


image


Большое количество СЗИ-вендоров и мейнтейнеров open-source проектов поставляют на регулярной основе индикаторы, сигнатуры и правила обнаружения атак для межсетевых экранов, антивирусов, IPS/IDS, UTM. В некоторых случаях это сырые данные, в других — дополненные оценкой риска или репутации. Индикаторы угроз критичны для технического уровня TI, но часто не предоставляют контекста для реагирования на инцидент.


Технологические вендоры и ИБ-компании предоставляют свои фиды угроз. Они включают в себя проверенные и приоритизированные индикаторы угроз и технический анализ образцов вредоносного кода, информацию о ботнетах, DDoS-атаках и других инструментах и видах вредоносной активности. Часто такие фиды дополняются статистикой и прогнозами: например, «ТОП-10 шифровальщиков» или «Список крупнейших ботнетов» и т.п.


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


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


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

Наслаждение общением — главный признак дружбы


Так сказал Аристотель. А для безопасников общение — способ объединить усилия, чтобы противостоять злоумышленникам. Есть даже более-менее устоявшийся англоязычный термин — «beer intelligence». Это когда безопасники собираются и делятся своими находками и подозрениями друг с другом в неформальной обстановке. Так что да, можно заниматься разведкой и за бокалом пива тоже.


Четвёртый принцип из определения TI — «и делиться ими с теми, кому они могут быть полезны» — как раз про обмен информацией. И организовать его можно не только по схеме Б2Б (безопасник-безопаснику), но и с помощью доверенной третьей стороны (организации), которая собирает, верифицирует, обезличивает и рассылает информацию об угрозах всем участникам сообщества. Такие сообщества поддерживаются государственными или общественными организациями (например, CiSP), волонтёрами (Vulners) и коммерческими компаниями (AlienVault Open Threat Exchange).


Так стоит ли внедрять в своей организации процессы threat intelligence? Стоит, но только если вы знаете: 1) где применять и как оценивать результаты TI; 2) как TI помогает процессам обеспечения ИБ; 3) кто будет отвечать на вопросы, поставленные перед «разведчиками», и можете сформулировать требования к TI.

Какое у вас отношение к Threat Intelligence?

Никто ещё не голосовал. Воздержавшихся нет.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/319666/


Apache Spark как ядро проекта. Часть 2. Streaming, и на что мы напоролись

Пятница, 16 Июня 2017 г. 07:29 + в цитатник
Привет коллеги.
Да, не прошло и три года с первой статьи, но проектная пучина отпустила только сейчас. Хочу с вами поделиться своими соображениями и проблемами касательно Spark streaming в связке с Kafka. Возможно среди вас есть люди с успешным опытом, поэтому буду рад пообщаться в комментариях.
Итак, в нашем проекте есть потребность принимать решения в режиме реального времени. Мы успешно используем Spark, для пакетной обработки данных, и поэтому для реалтайма решили использовать его же. Это даёт нам единую технологическую платформу и единую кодовую базу.
Workflow выглядит так: Все события приходят в очередь (Apache Kafka), а затем вычитываются и обрабатываются потребителями на базе Spark streaming. Потребители должны решить две задачи:

  • Роутинг данных (перенаправлять потоки данных в различные хранилища)
  • Принятие решений в режиме реального времени.


Данные которые приходят в Kafka, в конечном итоге должны попасть в HDFS в виде “сырых” лог файлов, конвертированных в паркет, и в HBase, в виде атрибутов пользовательских профилей. В своё время, для похожего роутинга мы довольно успешно использовали Apache Flume, но в этот раз решили поручить это дело Spark streaming. Spark из коробки умеет работать и с HDFS и с HBase, кроме того, разработчики гарантируют “exactly once” семантику. А вот теперь давайте немного подробнее разберемся с семантикой доставки данных (Message Delivery Semantics).
Их существует три вида:

  • At most once — Сообщение может быть потеряно, но никогда не доставлено более одного раза.
  • At least once — Сообщение никогда НЕ может быть потеряно, но может быть доставлено более одного раза.
  • Exactly once — Это то, то что люди хотят. Сообщение может быть доставлено только один раз, и не может быть потеряно.


И вот здесь кроется самое большое недопонимание. Когда разработчики Spark говорят об exactly once семантике, они имеют ввиду только Spark. Т.е если данные попали в процесс спарка, то они обязательно будут единожды доставлены до всех пользовательских функций участвующих в обработке, в том числе расположенных на других хостах.
Но как вы понимаете полный workflow не состоит из одного лишь спарка. В нашем процессе участвуют три стороны, и семантику стоит рассматривать для всей связки.
В итоге мы имеем две проблемы — доставка данных из Kafa в Spark, и доставка данных из Spark в хранилище (HDFS, HBase).

Из Kafa в Spark


Теоретически* проблема доставки данных из Kafka в Spark решена, причем двумя способами.

Способ первый, старый (Receiver-based Approach)


В спарке реализован драйвер, который использует Kafka consumer API для трекинга вычитанных данных (offsets). Эти самые офсеты по классике жанра хранятся в Zookeeper. И всё бы ничего, но существует ненулевая вероятность доставки сообщения более одного раза, в моменты сбоев, а это At least once.

Способ второй, новый (Direct Approach (No Receivers))


Разработчики реализовали новый спарковский драйвер, который сам занимается трекингом офсетов. Информацию о вычитанных данных он хранит в HDFS, в так называемых чекпойнтах (checkpoints). Этот подход гарантирует exactly once семантику, и именно его мы используем.

Проблема #номер раз


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

Проблема #номер два


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

Из Spark во внешнее хранилище


Здесь дела обстоят не так хорошо. Заботится о гарантиях доставки данных из спарка во внешние хранилища должен сам разработчик, что привносит не слабый оверхед в разработку и архитектуру. Если на данном уровне нужна exactly once семантика, то придется не хило заморочиться. К слову сказать мы так и не решили проблему в этой части системы, и довольствуемся At most once семантикой.

Итоги:


По моим ощущениям использовать Spark streaming можно, но только в том случае если ваши данные не имеют особой финансовой ценности и вы не боитесь их потерять. Идеальный случай — это когда данные гарантированно попадают в хранилище с помощью какой то другой, более надежной подсистемы, а Spark streaming используется в виде грубого инструмента, помогающего сформировать какие то грубые выводы или не точную статистику, но в режиме реального времени, с последующим уточнением в режиме пакетной обработки.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330986/


Метки:  

Законы и проекты, которые изменят лицо российского IT. Часть I

Пятница, 16 Июня 2017 г. 06:26 + в цитатник
Делаю эту публикацию, так как после предыдущих вопросов возникло много: у разных людей и по разным поводам. Этот пост призван в первую очередь:

  1. Помочь начинающим коллегам, которые только начинают путь в it-юриспруденции (название весьма условное)
  2. Рассказать тем, кто работает в IT, что и когда их ждёт
  3. Оставить онлайн-заметку о том, что же думаю по этому поводу я здесь-и-сейчас, в 2017 гг. или даже раньше
  4. Познакомить апологетов «жёсткого государственного регулирования» с иным взглядом на право, которое есть связующее звено между управленцами и управляемыми
  5. Рассказать подписчикам (коих не много) и постоянным читателям (их уже несколько сотен) о том, как же я вижу положительные возможности в законотворчестве it-сектора



1. Нарушение тайны связи

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

  1. Блокировки Роскомнадзора, материал можно найти здесь, здесь и, безусловно, на сайте Роскомсвободы
  2. Ограничение VPN/TOR/Proxy
  3. А также закон, который уже прошёл первое чтение (быстро, как всегда) — «о мессенджерах»

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

2. Авторское право и абсурд

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

И порой — в очень интересных проявлениях.

Так, например, скоро наступит знаменательная дата: 01.07.17, к которой мы ещё не раз вернёмся. Так вот: «согласно изменениям, внесенным Федеральным законом от 01.05.2017 № 87-ФЗ в Федеральный закон от 27 июля 2006 г. № 149-ФЗ „Об информации, информационных технологиях и о защите информации“, с 1 июля 2017 года на владельцев аудиовизуальных сервисов в Интернете будут возложены следующие обязанности по контролю за распространяемым ими контентом:».

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

Одним из последних дел из п. 3 можно назвать вот это: «Матч ТВ» выиграл первый суд против Sports.ru по иску о фрагментах матчей ФНЛ. Замечу, что в деле речь идёт о фрагментах матчей, которые ласково, но на английский манер называют хайлайты. Мне видится это странным, но dura lex… Впрочем, всё больше людей считают, что «просто дура». И в этом смысле ГК РФ с его новациями недавних лет — как раз подводит чёткую черту.

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

Думаю, весьма интересным будет работа этого закона, когда в полную зафункционируют сервисы формата http://bitrad.io. Точнее — они уже есть, но о них — ещё будет отдельный разговор.

И да: все ИР должны стоять на учёте в Роскомнадзоре. Думаю, аналогия с реализацией ФЗ №152 «О персональных данных» очевидна?

Но на подобных изыскания право копирайта не останавливается.

Так, например, есть проект Федерального закона N 198171-7 «О внесении изменения в статью 1252 Гражданского кодекса Российской Федерации». В частности, «согласно законопроекту, в случае если права на соответствующие результаты или средства индивидуализации принадлежат одному правообладателю, общий размер компенсации за нарушение прав на них с учетом характера и последствий нарушения может быть снижен судом ниже пределов, установленных Гражданским кодексом РФ… При этом в законопроекте сохраняется общее правило о том, что если одним действием нарушены права на несколько результатов интеллектуальной деятельности или средств индивидуализации, размер компенсации определяется судом за каждый неправомерно используемый результат или средство».

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

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

Поясню на примере ниже.

3. Онлайн-кассы — абсурд на абсурде и абсурдом погоняет

Прежде — короткий ликбез
  1. Общее понимание «нужности» онлайн-касс
  2. Онлайн-кассы и агрегаторы
  3. Новый тип касс и первые итоги

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

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

Из этого же разряда — как раз закон выше: нормы, содержащиеся в творении Ирины-Алексея-Надежды-Виктора откладывали не раз. Изначально даже звучали даты 2019-2023 гг. Но главное — он не нравится никому: ни операторам, ни гражданам. Возникает резонный вопрос: а как же ст. 3 Конституции? Впрочем, в нынешнее время это не интересует даже Конституционный Суд РФ, что говорить о других.

4. Товарные агрегаторы — продолжение банкета

Начну, пожалуй, с главного: «представители интернет-бизнеса уже предложили скорректировать порядок, сроки и условия возврата предоплаты по товарам, также они просят увеличить минимум вдвое срок рассмотрения агрегатором требования пользователя. Да и сам термин „товарные агрегаторы“ также вызвал вопросы». Для пользователей же, на первый взгляд, этот закон положительный. Но, как я уже писал, только на первый взгляд.

Ведь по факту это:
  1. увеличит возможности для потребительского терроризма (и, поверьте, Яндекс.Маркет будет не первым в списке нападающих)
  2. создаст ещё одного игрока рынка, где и так игроков множество и по итогу обычные пользователи будут искать правды ещё больше и дольше: отличный пример — это SMS-авторизация и действия операторов сотовой связи, которые сами хотели «забрать весь рынок», а по итогу — не дают обычным клиентам даже хранить деньги в обычных банках
  3. наконец, это уже порождает множество вопросов: как быть с досками объявлений? с децентрализованными сервисами? двойным возмещением ущерба (впрочем, этот вопрос, возможно, решат)?

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

Вот несколько основных принципов, которые помогут оптимизировать этот процесс:
  1. До принятия глобального регулирования по всей стране (не стоит забывать, что мы — Федерация и регионы сильно отличаются по экономическим и другим параметрам: для примера, можете взять соседние — Иркутскую область и Бурятию или ещё лучше Москву и ...) необходимо тестирование в ряде регионов. При этом тестирование должно быть стрессовым. Поверьте, в разработке это помогает и в праве тоже будет полезным.
  2. Должна быть технологическая основа оценки законопроектов (сейчас есть петиции, но они идут почти все постфактум, да и по формату фактически игнорируются властью: скажем, разные петиции против пакета Яровой собирали свыше 500 000 голосов и при 109 млн избирателей — это не так мало. Общий показатель в 1 000 000 сравним с целыми регионами: Смоленская область 813 926, Тамбовская область 867 229, Тверская область 1 142 192, Томская область 764 671, Тульская область 1 259 994, Тюменская область 1 052 983. И это — просто случайная выборка. Думаю, не стоит напоминать, что значит для России выделенное мнение одного региона (скажем, в 1994 году)?
  3. Прежде, чем принимать специализированный закон, нужно дать возможность функционировать рынку самостоятельно. Что же мы видим сегодня? Возьму лишь два примера очевидных: сначала мы запретили с помощью письма ЦБ РФ рынок криптовалют, а потом — одумались. Но ведь по существу три года рынок работал только в серо-чёрной схеме. Кому это было выгодно? Кому угодно, но не государственной власти в РФ, т.к. никаких налогов и проектов, которые эти бы налоги платить могли, она не получила. Второй пример — электронные деньги. До 2012 года этот рынок жил и работал вполне себе (с 1998 года, когда в разгар кризиса появилась система WebMoney). В итоге ФЗ №161 приняли в той редакции, которая была пролоббирована операторами сотовой связи и банками. Но в итоге: получила ли гос. власть новые доходы? По факту — нет, т.к. мелких игроков закрыли, а от крупных люди ушли в криптомонеты и зарубежные сервисы. И это парадокс: чем больше хочет получить публичная власть, закручивая гайки нормативов, тем меньше она получает.
  4. У нас есть множество технопарков в РФ (правда, какие из них функционируют — отдельный вопрос). Так почему бы не тестировать ряд новаций, спорных по крайне мере, именно там, да ещё под всеобщим контролем: есть ведь общественное обсуждение законов (опять же — развитие его и влияние — вопрос, и вопрос сильный), реализовать, соответственно, можно это уже и в прикладном уровне. Тем более, что Иннополис и иже с ним развивать, развивать и ещё раз развивать нужно.

При этом по наблюдениям за рынком с 2007 по 2017 гг., то есть — в течение 10 лет, могу сказать, что: в России очень большой серый сегмент экономики, что удивительно при существующей форме УСН в 6% (а то и в 1%, как было, например, в Чечне, или как есть при «доходы-минус-расходы» в случае убытков). Ведь физ. лица, скажем, при продаже товаров или услуг также платят агрегаторам %. Но платят они потом и за вывод. Или, например, взять криптосферу — там обменные пункты берут до 10-15%, что в принципе выше налогов. Почему так? Потому что заплатив государству один раз человек остаётся не уверен: вдруг, что-то оформлено не верно? Что-то перечислено на день позже? Что-то новое, чего не знаем…

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

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

P.S. В конце — обращение к дочитавшим: если знаете проекты, которые достойны внимания, пишите ниже. Попробую изучить и обсудить: по крайне мере мы можем привлечь внимание (как было с законами о Биткоине) и не дать реализоваться самым уж чёрным тенденциям.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331028/


Метки:  

[Перевод] Разработчики, которые используют пробелы, зарабатывают больше, чем те, которые используют табы

Пятница, 16 Июня 2017 г. 00:15 + в цитатник
Это с определенной точки зрения «священная война» среди разработчиков программного обеспечения, эта тема стала предметом множества дебатов и шуток. Я использую пробелы и никогда не задумывался о важности этого момента. Но сегодня мы публикуем исходные данные опроса разработчиков Stack Overflow 2017 и некоторые аналитики считают, что этот выбор имеет большее значение, чем я ожидал.

Пробелы приносят больше денег чем табы


Было опрошено 28 657 респондентов, которые выразили свое предпочтение табам или пробелам и считали себя профессиональным разработчиками (ученики и бывшие программисты не учитывались). В этой группе 40,7% используют табы и 41,8% пробелы (17,5% используют оба метода). Из них 12 426 оставили информацию о своей зарплате.

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



Среднестатистический разработчик, который использует пробелы, имеет зарплату в 59 140 долларов, в то время как разработчик использующий табы имеет зарплату в 43 750 долларов. (Обратите внимание, что все результаты были конвертированы в доллары США из валюты респондента). Результаты разработчиков, которые выбрали вариант «Оба», как правило, неотличимы от тех, кто выбрал «Табы».

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

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



Данный эффект наблюдался в наименьшей степени в Европе, а наибольший разрыв был зафиксирован в Индии, но, тем не менее, он проявляется в каждой стране.

В качестве другой гипотезы мы знаем, что разработчики из разных сфер часто используют разные пробелы (например, разработчики DevOps с большей вероятностью используют пробелы, а мобильные разработчики более вероятно используют табы), часто потому что они используют разные редакторы и языки. Участвующие в опросе, также оставили информацию о том, какие языки программирования они используют (Python, Javascript и т. Д.) и в какой сфере работают (web developer, embedded developer и т. д.).



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

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

Если мы проверили все факторы, которые, как мы подозреваем, могли бы повлиять на зарплату, какой эффект в реальности будет иметь выбор табов/пробелов?

Чтобы ответить на этот вопрос, я подхожу к линейной регрессии, прогнозируя зарплату на основе следующих факторов:

  • Табы/пробелы
  • Страна
  • Годы опыта
  • Тип разработчика и язык программирования
  • Уровень образования (бакалавриат, магистр, докторантура)
  • Вносят ли они вклад в открытый исходный код
  • Будут ли они программировать в качестве хобби
  • Размер компании


Использование пробелов вместо табов приводит к увеличению зарплаты на 8,6% (доверительный интервал (6%, 10,4%), P-значение <10 ^ -10). Иными словами, использование пробелов вместо табов приравнивается дополнительным 2.4 годам опыта.

Заключение

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

Корреляция не является причинно-следственной связью и мы никогда не можем быть уверены, что мы учли все факторы в наборе данных. Если вы статистик или аналитик, я рекомендую вам загрузить исходные данные опроса и изучить их самостоятельно. Здесь вы найдете код для воспроизведения анализа. В любом случае нам было бы интересно услышать ваши гипотезы.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331026/


Метки:  

Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 1009 1008 [1007] 1006 1005 ..
.. 1 Календарь