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

Поиск сообщений в 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 ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

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

В разрезе: новостной агрегатор на Android с бэкендом. Система контроля версий

Понедельник, 31 Июля 2017 г. 14:25 + в цитатник
Вводная часть (со ссылками на все статьи)

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

Вопрос применения системы контроля версий для создаваемого кода и артефактов при работе в одиночку открыт. В связи с этим предлагаю сыграть в игру – я буду писать ситуации, при которых использование системы контроля версий мне помогло и убедило меня в необходимости её использования, а Вы будете писать — как можно решить эту задачу без неё(если желающих не найдётся – я пойму):
  • подключение дополнительных членов команды к проекту и начало работ с единым репозиторем – при использовании системы контроля версий уже отработаны вопросы: какое хранилище, какие средства для работы с ним, как структурирован проект по репозиториям, как осуществляется именование веток и тэг. При отсутствии – придётся всё эти вопросы прорабатывать с начала и тратить на это время;
  • просмотр изменений (иногда просто для понятия как сильно изменился класс за последнее время);
  • оценка своей собственной продуктивности в количестве строк кода (субъективный показатель, но для меня иногда и он важен);
  • защита от случайного удаления файлов или внесение нежелательных результатов и возможность возврата всего к предыдущему состоянию;
  • проверка работы алгоритма с созданием отдельной ветки (в рамках которой меняются не только пара классов, а и конфигурационные файлы) и необходимость возврата к предыдущему варианту (в случае если надежды не оправдались);
  • необходимость временного представления доступа на чтение к актуальной версии исходных текстов;
  • дополнительные сценарии, которые редки для разработчика-одиночки и обязательны для группы или фирмы:
    • системы интеграционного тестирования, которые запускают тесты после обнаружения коммита в основной или специализированной ветке;
    • системы постоянной доставки обновлений, который так же запускают свою работу после обнаружения необходимых изменений в ветка для развёртывания;
    • иерархические системы внедрения кода в основные ветки, при которых подготовленные изменения проверяются более опытными или специально предназначенным специалистами по своим критериям (безопасность, простота, следование стандартам и прочее-прочее…) – хороший пример описания подобных подходов представлен тут (Распределённые рабочие процессы).



Небольшое отступление от очевидных вещей:


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

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

Интересные ссылки про git:
Книга ;
видео от Yandex.

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


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

Для тех, кому всё это кажется элементарными и очевидными вопросами я оставил пару вещей, аналога которых я не нашёл для других систем контроля версий и других git-хостингов:
  • Git submodules – Подмодули позволяют содержать один Git-репозиторий как подкаталог другого Git-репозитория. Это даёт возможность клонировать ещё один репозиторий внутрь проекта, храня коммиты для этого репозитория отдельно.
  • GitHub’s Deploy Keys – позволяют получать доступ к репозиторию на чтение / запись с помощью ssh-ключей, при этом каждому можно выдавать свой ключ и как результат — доступ отозвать по собственному желанию (просто-напросто убрав соответствующий закрытый ключ). В моём случае данный функционал используется для системы последовательной интеграции для получения необходимого доступа к репозиторию соответствующего модуля. Описание функционала так же доступно тут (blog.niyakiy.com).
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334514/


Метки:  

В разрезе: новостной агрегатор на Android с бэкендом. Вводная часть, идея, технологии

Понедельник, 31 Июля 2017 г. 14:25 + в цитатник
Так сложилось, что работу, которая мне нравилась и которую, как мне кажется, я делал хорошо, мне пришлось сменить на более стабильную и прибыльную, но уже не такую интересную – работу линейного менеджера в подразделении информатизации в крупном банке. Сказать, что эта работа полная противоположность прежней сложно, но в ней нет, того, что было в разработке: драйва, необходимость решения сложных задач, изучения новых технологий, что тут говорить – не было даже английского языка (знание которого терять не хотелось). Откровенно говоря, несмотря на заявляемую гибкость и передовые технологи, во многих банках царит IT-совок и ручной труд.

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

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

В качестве проекта была выбрана идея реализации новостного агрегатора (с клиентом на Android) и его серверной стороны для сбора, обработки, хранения и представления данных.



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


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

Схематически компоненты проекта можно представить так:
image

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

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

https://habrahabr.ru/post/334510/


Метки:  

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

Понедельник, 31 Июля 2017 г. 14:17 + в цитатник


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

Мы составили чек-лист по каждому из «болезненных» вопросов бизнеса в интернете: что нужно помнить при регистрации хостинга, домена, покупке прав на сайт? Как соблюдать права интеллектуальной собственности в сети Интернет? Что делать, если с вашего сайта скопировали контент или дизайн? Как избежать штрафов до 300 000 рублей за нарушение ФЗ-152 и 54-ФЗ?

О чем стоит помнить, приобретая хостинг


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

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

5 основных вопросов к вашему хостинг-провайдеру


  1. Какая контактная почта указана в договоре? Заключая договор, укажите несколько почтовых ящиков для получения уведомлений об оплатах, технических работах и т.д. — это сведет к минимуму неоплату из-за «человеческого фактора» (например, отпуска/больничного ответственного специалиста на момент оплаты).
  2. На кого заключен договор? Лучше заключать его не на физическое лицо, например, системного администратора или IT-специалиста, а на компанию.
  3. Есть ли лицензии на «Телематику» и «Передачу данных»? Отсутствие этих документов недопустимо.
  4. Где расположен дата-центр хостинга? Если вы планируете работать на Россию, то и дата-центр должен располагаться на территории РФ.
  5. Есть ли доступ к панели управления хостингом? Если ранее вам не были высланы доступы (например, по вине разработчиков сайта), то запросите их и организуйте правильное хранение учетной информации. Доступ – это всегда три строки данных: адрес хостера, логин и пароль.

Домен: часть нематериального актива компании


Доменное имя может быть объектом сделок. Его регистрация осуществляется после заключения соответствующего договора с компанией-регистратором. Урегулирование спорных вопросов, осуществляется в рамках российского законодательства.
  • Доменные имена .ru, .com, .net и т.д. — это домены первого уровня, они не продаются в обычном порядке. Такие продажи планируется начать только 2020 года.
  • Доменные имена второго уровня — это mersedes.com, sk.ru, web-canape.ru, yandex.ru, google.com и т.д.
  • Покупая домен второго уровня, вы приобретаете не один домен, а целый кластер: vash-domen.ru, vash-domen.ru, test.vash-domen.ru, test2.vash-domen.ru и т.д.

Права на домен дают:


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

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

О чем стоит помнить при покупке домена


  • Права на хостинг никак не связаны с правами на домен или сайт
  • Если даже домен «дается в подарок» при покупке хостинга уточните, кому будут принадлежать права на него, кто является регистратором и что будет, если вы решите переехать к другой хостинг-компании
  • Проследите за тем, чтобы домен юридически принадлежал вашей организации
  • Своевременно оплачивайте продление
  • В качестве контактного почтового ящика администратора укажите e-mail, не привязанный к доменному имени
  • Обратите внимание на название домена, оно не должно дублировать или содержать в своем названии чужую торговую марку. Так как ее владелец может у вас такой домен отсудить или запретить его использование в любой момент.

Права на сайт


Сайт может быть создан по одной из следующих схем:
  • конструктор — wix, ucoz, tilda и т.д. — вам принадлежит только наполнение сайта, которое вы разместили на шаблоне;
  • сайт на базе шаблона на бесплатной CMS, типа WordPress, Drupal, Joomla и т.д. — вам принадлежит наполнение, версия CMS с доработками;
  • сайт с индивидуальным дизайном на платной или коммерческой CMS — вам принадлежит лицензия, права на дизайн, права на программные модули, наполнение.

О чем стоит помнить, заказывая сайт


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

Какие существуют риски


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

Что нужно помнить?


  • Не использовать фото и тексты, взятые без согласования их владельцев
  • Графические материалы нужно готовить самостоятельно или закупать на специализированных биржах
  • Следует выяснить заранее, какие у вас есть права на лицензию CMS, на которой разработан сайт
  • Убедитесь, что соблюдены все авторские права на использование графического шаблона вашего сайта



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

Как отстоять свои права


  • Ставим на сайте знак Copyright
  • Создаем раздел, в котором описываем правила использования материалов с вашего сайта
  • При обнаружении копии пишем официальный запрос владельцам сайта на фирменном бланке
  • Пишем запросы о нарушении авторских прав в службу хостинга или конструктора, на котором размещается сайт, с просьбой заблокировать проект
  • Пишем запросы в Google
  • Все письма подкрепляем доказательной базой
  • Если не помогает — идем в суд


Уведомление о нарушении авторских прав

Что еще можно сделать


  • Регистрируем вновь создаваемые тексты в Яндекс.Вебмастер
  • Ставим программный модуль защиты от копирования текстов
  • Накладываем водяные знаки на авторские фото
  • Вносим в тексты скрытые ссылки, ведущие на ваш сайт

Когда копирование материалов нашего сайта бывает полезным?


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

Работа с персональными данными


С 1 июля 2017 года штрафы за нарушение закона повысились. В совокупности штраф может составить до 300 000 руб. Минимальный штраф вырос с 10 000 руб. до 75 000 руб.

Обязательно к исполнению
  1. Разработать и разместить на сайте раздел с политикой конфиденциальности, в которой вы описываете, какие данные собираются, кем собираются, с какой целью, какая доля ответственности вами принимается по хранению, защите и обработки этих данных
  2. Ссылка на раздел «Политика конфиденциальности» должна присутствовать на всех страницах сайта
  3. Во все формы сбора данных нужно добавить галочку «Даю свое согласие на обработку персональных» и активную ссылку на политику конфиденциальности
  4. Для посетителя, впервые открывшего сайт, разместить модуль с предупреждением о том, что на сайте установлены системы сбора информации из параметров браузера
  5. Разместить сайт на хостинге в России
  6. Назначить ответственных лиц и разработать пакет внутренних документов, регламентирующих процессы обработки и защиты персональных данных

Желательно
  • Данные из форм сбора информации фиксировать в CMS сайта, а не отправлять на e-mail
  • Приобрести SSL-сертификат для доменного имени и настроить работу сайта по защищенному https-протоколу

54-ФЗ: новый порядок применения ККТ


С 1 февраля 2017 года контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных — новые правила установлены в 54-ФЗ ст.2 п.2.

Юридическое лицо или ИП обязано приобрести фискальный накопитель, подключить on-line кассу, заключить договор с оператором фискальных данных и отправлять чеки в электронном виде в ФНС через оператора фискальных данных.


Схема работы online-оплаты согласно новому закону


  • На сайте формируется заказ, который передается на оплату.
  • Оплата происходит на стороне эквайринга (robokassa, yandex-касса, payanyway и т.д.)
  • Эквайринг передает информацию об оплате в online-кассу, которая формирует электронный чек
  • Электронный чек подтверждается у оператора фискальных данных
  • Подтвержденный чек фиксируется в фискальном накопителе, высылается покупателю на e-mail и заносится в базу оператора фискальных данных

1 или 2 раза в сутки все электронные чеки выгружаются в базу данных налоговой инспекции.

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


  • Штраф за каждую оплаченную, но не подтверждeнную online-чеком сделку — 10 000 руб.
  • Штраф — 10 000 руб., если подключенная online-касса не соответствует стандарту
  • Торговля без online-кассы — 30 000 руб.

Кого закон не касается до 1 июля 2018 года?


  • Тех, кто имел право работать без контрольно-кассовой техники
  • Тех, кто продает товары народных промыслов и имеет статус «народный промысел»
  • Продажа газет, журналов и прочих периодических изданий
  • Реализация предметов религиозного культа

Хотите узнать больше?


3 августа в коворкинге «Сколково» пройдет семинар «Интернет и закон: что нужно знать владельцам сайтов, чтобы избежать штрафов до 300 000 руб.» при участии экспертов в области юриспруденции и веб-разработки.

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

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

С уважением, компания WebCanape

Была ли эта статья полезна для вас?

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

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

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

https://habrahabr.ru/post/334524/


[Перевод] Аналоговый мир и его иллюзия

Понедельник, 31 Июля 2017 г. 14:01 + в цитатник
Обычно выбор в играх выглядит примерно так:



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

Вот другой пример выбора:



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

Super Mario создаёт этот выбор из самой работы базовой механики игры. Ещё один жанр, создающий выбор с помощью механики — это симулятор, но ему удаётся добавить в варианты больше философской глубины. Например, если игре-симуляторе акцент делается на выживании, то у вас может оказаться недостаточно еды для всех членов группы, и придётся выбирать кому жить, а кому умереть. При правильном дизайне такие моменты создают потрясающее впечатление, но чаще всего достичь его не удаётся. Умирающие от голода члены группы редко вызывают те же сильные чувства, что в сценах игр наподобие Walking Dead. Давайте разберёмся, почему так получается.

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

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

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

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

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

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

Лучший пример такого дизайна — сцена из Spec Ops: The Line. В один из моментов игры игрока окружают гражданские. Эти люди не слишком довольны присутствием главного героя и начинают бросать в него камни. Это очень опасная ситуация и игроку понятно, что нужно из неё выбираться. В этот момент игрок имеет в распоряжении только один простой глагол: «стрелять». Что же он может сделать? Он не хочет стрелять в гражданских, но и не хочет умереть. Здесь игрок на самом деле имеет два варианта. Первый — начать стрелять по гражданским, убить нескольких, а остальных заставить убежать. Второй вариант — просто выстрелить в воздух и отпугнуть их, не убив никого.



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

Благодаря таким выборам игровой процесс ощущается более «аналоговым». Внутри игры этот выбор такой же дискретный как и те, которые вы делаете в Walking Dead, но он ощущается совершенно иначе. Кажется, что существует большой спектр вариантов действий, большое пространство выбора, а не просто «одно или другое». Эта концепция ощущений «аналогового» выбора очень важна и ниже я подробнее расскажу о ней.

В Spec Ops: The Line есть с полдесятка выборов такого типа. Например, в одном случае игрок должен выбрать, кто из двух пленников должен умереть, выстрелив в него. Но игра не сообщает вам о ещё одном выборе: нацелить оружие на людей, захвативших этих пленников. Ещё один пример: игрок выбирает, стоит ли убивать военного преступника. И снова варианты выбора точно неизвестны. Игра просто ставит вас в ситуацию, в которой можно его убить. То есть игроку самому нужно догадаться о том, какие варианты выбора у него есть.

Ещё один интересный аспект игры Spec Ops: The Line заключается в том, как она обращается с последствиями выбора. Решение просто — никак. Она создаёт ситуации таким образом, что любой выбор логично связывается с дальнейшим развитием сюжета. Хотя я и не считаю, что всегда можно избавиться от демонстрации последствий, это может быть очень полезно для поддержания чувства «аналоговости». Потому что в тот момент, когда вы показываете последствия, становится понятно, что выбор был дискретным. Но если скрыть последствия, то пространство возможностей оказывается шире и игрок может свободно фантазировать о том, что произошло.

С этим стоит разобраться чуть глубже. Чем выбор в Spec Ops: The Line отричается от выбора в игре с явно показанными вариантами? Ключевое различие заключается в том, что в первом случае игрок находится в положении неопределённости. Нет чётко переданной информации, из которой нужно исходить, поэтому игрок вынужден заполнять пробелы собственным воображением. Когда варианты перечислены в явном виде, то это не требуется. Мозг всегда хочет оптимизировать, поэтому любая частица информации избавляет от предположений. Благодаря этому Spec Ops: The Line обеспечивает более богатую ментальную модель сцены. Не забывайте, мы играем в игру на основании того, что находится в нашей голове, а не во внутриигровых системах, то есть сама игра становится более интересным опытом.

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

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

В SOMA мы стремились, чтобы все выборы ощущались аналоговыми и использовали тот же подход, что и в Spec Ops: The Line. Мы создавали ситуацию, а потом использовали стандартные игровые действия для того, чтобы игрок сделал свой выбор. Идея заключалась в том, чтобы выборы ощущались встроенными в игровой процесс, и судя по полученным отзывам, подход сработал очень хорошо.

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

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



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

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

Думаю, вам стоит проверить это самим. Для начала попробуйте сыграть в обычную игру жанра. Рекомендую что-то типа Lost Pig, потому что она позволяет использовать множество команд, и показывает (особенно в начале), насколько это захватывающе — играть, вводя что угодно в пустую строку. После этой игры попробуйте Walker and Silhouette и используйте в игровом процессе только подсвеченные слова. Ощущения от двух этих игр сильно отличаются. Конечно же, последняя позволяет намного быстрее продвигаться и снимает часть раздражения. Но, с другой стороны, в ней исчезает то, что в первую очередь интересно в такой среде.

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

Существует множество других случаев, в которых ощущение аналоговости может стать полезным. Ещё один хороший пример — головоломки. Недавно я играл в 999, в которой есть головоломки в стиле «выход из комнаты». Хотя в них и довольно интересно играть, но реализованы они невероятно очевидно. Игра хочет, чтобы игрок воспроизвёл несколько определённых действий. В сущности, она требует, чтобы игрок понял замысел дизайнера и нашёл конкретную цепочку действий, ведущую к успеху. Это не ощущается особо аналоговым.



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

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



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

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

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

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

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

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

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

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

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

Думаю, можно получить множество преимуществ, размышляя о том, как сделать игровой мир более аналоговым. Также я думаю, что эта тема ещё далека от полного изучения. Очень часто люди берут системы с явными средствами выражения и придерживаются их. Создание сцен аналоговым способом требует гораздо больше труда, но оно может и вознаграждать гораздо больше. К тому же эту концепцию неплохо иметь в виду, объединяя нарративный подход с хорошим геймплеем. Аналоговые миры — базовая часть эволюции интерактивного сторителлинга.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334420/


Метки:  

Осторожно — майнеры-халявщики

Понедельник, 31 Июля 2017 г. 14:00 + в цитатник
Забавная история произошла в нашем облаке этим летом.
Приняв очередной звонок с сайта, наш менеджер, потирая руки, запросил 4, достаточно производительные, виртуальные машины для тестирования.
Конфигурация VM: 16 CPU, 32 GB, 100 GB SSD, Windows Server 2012 R2. Срок тестирования — 1 месяц.
Продолжение под катом.
Клиент — представился крупным хостинговым провайдером Казахстана, указав номер телефона и сайт компании. Сославшись на какие-то сложности в законодательстве, сообщил, что собирается переводить мощности на территорию РФ и сейчас выбирает IaaS-провайдера.
Среди перечисленных провайдеров были только крупные игроки рынка IaaS.
В этот же день мы подготовили и передали запрошенные VM для тестирования.
Ближе к середине второй недели «тестирования», менеджер решил уточнить детали — как проходит тестирование, требуется от нас помощь и т.д.
Мы долгое время пытались связаться с клиентом всеми доступными способами, в ответ — тишина… На электронную почту ответа не последовало, трубку не берут.
Но как показывает система мониторинга — «тестирование» идет полным ходом, с момента передачи виртуальных машин клиенту — загрузка CPU менее 96% не опускалась.
Общим решением постановили, что такое отношение не имеет общее с этикой тестирования ) и решили проверить, что же происходит.
Зашли на консоль VM
Логин и пароль они не потрудились поменять.
В не заблокированной консоли одной из VM, нас встретил улыбающийся интерфейс майнера nicehash :) Который прекрасно себе добывал криптовалюту Monero. На остальных VM нас ожидало такое же зрелище.
Судя по транзакциям, за время «тестирования», находчивые предприниматели-халявщики смогли заработать эквивалент нескольких долларов.
Лавочку мы тут же прикрыли.
Будьте внимательны и всегда проверяйте данные, которые предоставляет клиент. Кстати — сайт клиента оказался просто заглушкой, все ссылки вели на главную страницу.
Удачи :)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334526/


Метки:  

[Из песочницы] Нетривиальные проблемы с generic'ами и возможные решения

Понедельник, 31 Июля 2017 г. 12:52 + в цитатник
Привет всем! Любой программист, хоть немного знающий Java работал с такой штукой, как generic. Эта фича появилась аж в 5-ой версии Java и сегодня я хотел бы рассказать о некоторых нетривиальных проблемах, связанных с обобщенными типами, с которыми я сталкивался, а также о том почему они возникают и как их можно решить. В этой статье также будут затронуты всеми (не)любимые Hibernate и Spring.

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

1) Зачем нужен wildcard, extend, super

Wildcard (?) используется во время подстановки в обобщенный класс. Означает он, что нам не важно каким будет параметризованный тип или, если wildcard используется вкупе с ключевыми словами super и extend, то нам важно только, чтобы параметризованный тип был родительским или расширял определенный класс. Приведу понятный пример, как это используется на практике.

public void foobar(Map ms) {
    ...
}

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

public void foobar(Map ms) {
    ...
}

То есть во втором случае мы говорим, о том что нам не важно какого типа будет лежать value в мапе. Но это накладывает и свои ограничения, теперь у значений мапы мы сможем вызывать только методы класса Object. Если мы знаем, что значениями в этой мапе могут быть только объекты класса Number, то мы можем переписать сигнатуру метода так.

public void foobar(Map ms) {
    ...
}

Теперь у значений мапы нам доступны методы класса Number. Возникает вопрос, зачем же нам тогда ключевое слово super? Оно говорит о том, что параметризованный тип будет родителем для определенного класса, но это не дает возможность полиморфизма — вызывать метод какого-либо класса, кроме базового для всех — Object. Опять же приведу пример.

List

https://habrahabr.ru/post/334512/


Метки:  

«Работаю над проектами, объединяющими книгу и интерактив»: Кей Хорстманн о книгах и не только

Понедельник, 31 Июля 2017 г. 12:48 + в цитатник

Есть гигантское множество книг о Java — а есть несколько «тех самых» книг о Java. В их число входит «Core Java» (в русском издании «Java. Библиотека профессионала») Кея Хорстманна и Гэри Корнелла. Она появилась лишь годом позже самого языка, сразу став одним из главных источников информации по теме. А за последовавшие двадцать лет выдержала целых десять изданий, скрупулёзно пополняясь информацией о новых версиях Java, так что на ней выросло уже не одно поколение Java-разработчиков.

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

— То, что «Core Java» стала очень известной и значимой, как-то влияет на работу над ней? Например, ощущаете ли вы, что фактчекинг вам требуется проводить тщательнее других авторов?

— Спасибо за тёплые слова о «Core Java». Я надеюсь, что каждый автор как следует занимается фактчекингом, и про многих точно знаю, что это так. Но когда «Core Java» вышла впервые, конкуренцию ей составляли несколько книг, попросту повторявших документацию API, а документация тогда не всегда была верна. Мы обнаружили это, когда написали маленькие, но реалистичные программы (а не просто «игрушечные» примеры), которые пускали API в дело. Сейчас сложно представить себе, насколько это всё усложняло: stackoverflow.com ещё не было, а доступ к исходному коду Java был ограниченным.

Некоторые книги, вроде «Java Concurrency in Practice», написаны такими выдающимися экспертами, что сказанное в них можно принимать на веру без примеров кода. Но давайте признаем, что многие книги приходится писать в спешке, когда новая технология развивается. И в этом случае очень важно, чтобы авторы предоставили хорошие примеры. Когда я вижу книгу, где у классов названия животных, а методы выводят «Гав» и «Мяу», мне это не нравится. Я хочу видеть код в реалистичном контексте. Для меня эталон — классическая книга Кернигана и Ритчи по С, в которой почти каждый сниппет мог бы быть из рабочей программы.

Когда «Core Java» впервые была опубликована, и там было сказано, что многие вещи в Java API не вполне корректно работают или неудобны для программиста, на моего редактора накричали в Sun Microsystems. Но я думаю, что это очень помогло репутации книги. Теперь, когда я работаю над изданием, приуроченным к Java SE 9, я по-прежнему пытаюсь объяснить, что работает хорошо, а что не очень. К счастью, на моего редактора больше никто не кричит.

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

— Очень хороший вопрос. Когда я начал писать эту книгу, я был и автором учебников, и разработчиком, и для меня было естественным думать не просто об одной версии, а сразу и о последующих. Книга была рассчитана на то, чтобы расти вместе с языком и с API. Но мы сами были так же поражены, как и все, когда API разросся семимильными шагами, и «Core Java» превратилась в два толстых тома.

И да, работа над новым изданием ощущается как рефакторинг. Во многих случаях новый способ делать что-то делает другие подходы устаревшими, и мне надо разбираться с сотнями примеров кода. Я люблю использовать новые возможности во всех примерах, где они подходят, чтобы читатели не оказывались сбиты с толку смесью старого и нового. Простой случай — diamond operator, там требовалось просто найти выражения вида «new … <...>(...)». Но когда добавили лямбда-выражения, мне пришлось переписать больше половины программ-примеров, порой сильно их реорганизуя.

Мы не хотели, чтобы «Core Java» потолстела до трёх томов, так что в каждом издании какие-то вещи оказываются удалены. В числе таких — информация о багах в старых версиях, которые уже никого не волнуют, «обходные пути», которые устарели из-за улучшений в языке, и масштабные «выкосы» API. Когда-то у нас было очень подробное описание CORBA, и избавиться от этого было довольно лёгким решением. Когда удалили описание RMI, некоторые читатели расстроились, но слушайте, когда в последний раз кто-либо использовал это не в игрушечном примере? А теперь подбирается следующее сложное решение: что делать со Swing?

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

Ещё хлопот доставляет рост информации, относящейся к конкретной версии. «Если у вас Java 6 (бедняжка), можете делать так-то, начиная с Java 7, можете делать и так, а в Java 9 вы почти достигаете нирваны, потому что теперь можете делать что-то ещё». В книге «Core Java for the Impatient» я просто объясняю, как работает последняя версия Java, представляя себе программиста, уже владеющего, например, JavaScript. Это очень освежает. Но, разумеется, многие пользователи вынуждены иметь дело с различными версиями, так что классическая «Core Java» по-прежнему будет это учитывать.

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

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

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

— Когда пишешь о Java на протяжении многих лет и вдаёшься в детали, возникает ли ощущение «как многое в Java сделано совершенно неправильно»? Пробовали ли что-то улучшить?

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

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

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

В качестве примера: я однажды предложил, что нужна возможность запустить программу, вызвав конструктор (с параметром String[] или без аргументов) класса, указанного в командной строке, если этот класс не содержит метода main. Я даже имплементировал это — код запуска в VM не такой уж сложный. Почему мне вообще было до этого дело? Потому что это было бы манной небесной для студентов и преподателей, которым не пришлось бы иметь дело с public static void main в первой же лекции. «Hello, World!» выглядел бы так:

public class Greeter
{
   public Greeter()
   {
      System.out.println("Hello, World!");
   }
}

Вторая пробная программа могла бы сразу же нырять в объекты, не беспокоясь о «static».

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

Было ли моё скромное предложение одобрено? Отнюдь. Оно было отвергнуто как «слишком сложное» и «способное угрожать обратной совместимости».

Но как бы то ни было, со временем многие раздражающие особенности API оказываются исправлены. Возможно, из-за того, что людей в Oracle они раздражают так же, как и нас.

Также давайте не забывать, насколько мы избалованы качеством Java API. Я видел многие API в JavaScript, Python и C++, которые заставляли меня чесать затылок и диву даваться, почему кто-либо мог спроектировать API так.

— Приходилось ли вам слышать от Java-разработчиков, что ваши книги не только научили их Java, но и повлияли на их стиль программирования?

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

Есть исключение. Я написал книгу по Scala, где у меня довольно чёткая точка зрения: взгляд Java-программиста, который не хочет отказываться от своей объектно-ориентированности и переходить на чистое функциональное программирование. Тем читателям, которые разделяют мою точку зрения, понравилось. Тем, которые не разделяют — не очень.

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


— У вас на сайте в разделе «memorable quotes» есть цитата, подкалывающая Герберта Шилдта. Поскольку ваши книги о Java конкурируют, хочется узнать — это просто шутка, или у вас соперничество? :)

— С Гербом — нет. Я никогда его не встречал. Я даже не знаю, существует ли он. Может, это кодовое имя для программы с искусственным интеллектом. Шучу, Герб :-) Мне просто понравилась цитата.

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

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

— Вы участвовали в создании курса Intro to Java Programming на Udacity. Ощущаете ли вы, что будущее обучения программированию за онлайн-курсами? Становятся ли книги менее актуальны? Что бы вы посоветовали в первую очередь человеку, который хочет стать разработчиком: книгу или MOOC?

— Это тоже отличный вопрос. Когда я занялся MOOC-курсом, что произошло в рамках сотрудничества моего университета и Udacity, мне сказали: «Вы ничего не знаете, мы научим вас учить». И они научили меня полезным техникам. Ограничивать видеосегменты тремя минутами. Не давать ответ, а задавать вопрос. Делать всё визуальным. С точки зрения «первых шагов для человека, который хочет стать разработчиком» результат мне очень нравится.

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

Так что, если бы мне пришлось выбирать между видеокурсом (будь то MOOC или нет) и книгой, я бы всегда выбрал книгу. Но я сейчас работаю над проектами, где эти две части объединяются: интерактивная часть для первого контакта, а книга для более глубокого понимания и в качестве справочника. Возможно, вот к этому и идёт мир.

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

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

— Здесь кроется распространённое недопонимание. Студенты часто спрашивают что-то вроде: «Почему мне надо учить теорию автоматов? Что мне действительно нужно, так это курс по AngularJS».

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

Некоторые люди считают, что университеты заходят слишком далеко с преподаванием бесполезного материала, и им с их четырёхлетними программами не хватает гибкости. Вот поэтому появляются все эти «хакерские академии» и «nanodegree». Мне самому приходят в голову некоторые способы модернизировать учебную программу в computer science, и я также признаю, что некоторые из этих способов не будут внедрены из-за институциональных барьеров. Но нетрадиционные образовательные программы уходят в другую крайность, не предоставляя достаточно фундаментальных знаний. Они также отличаются от университетов в другом отношении: им требуется фокусироваться только на самых мотивированных людях, способных заполнить многие пробелы самостоятельно.

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

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

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

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

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

— Вы преподавали CS во всему миру — в США, Швейцарии, Вьетнаме и Макау. Чем вызван такой разброс?

— Мне просто нравится путешествовать.

— А с точки зрения вашей работы была ли какая-либо значительная разница между этими странами, или computer science и в Макау computer science?

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

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

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

История такая. В случае с C у нас есть стиль K&R и стиль Олмана:

if (args > 0) {
    printf(args[0]);
}


и

if (args > 0)
{
    printf("%s\n", args[0]);
}

Что мы хотим — сэкономить место, или выравнять фигурные скобки? А что, если хотим сразу и то, и другое? Вот тут и вступает в дело «стиль Хорстманна»:

if (args > 0)
{	printf("%s\n", args[0]);
}

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

— Недавно в Стэнфорде изменили свой вступительный курс по CS, решив вместо Java использовать JavaScript. Что вы думаете по этому поводу?

— Вступительный курс по computer science — это на самом деле не курс конкретного языка (во всяком случае, не должен им быть). Сложности у студентов возникают с циклами и массивами, с алгоритмами, декомпозицией и дебаггингом. Вне зависимости от того, используете вы Java, C++, Python или JavaScript, студенты скорее застрянут на цикле, чем на public static void main или на контринтуитивных особенностях JavaScript.

Так что не имеет особого значения, какой язык использовать, если только сам курс не акцентирует на этом внимание. Я видел курсы с C++, которые докучали студентам подробностями об указателях, и это не способствовало процессу. А в Стэнфорде всегда был первоклассный курс, с JavaScript они могут сделать его не хуже, чем с Java — но, думаю, и не лучше.

— Вы пишете о Java уже десятилетиями и видели, как всё менялось со временем. Что вы думаете о будущем Java? Она прошла свой пик и будет медленно терять в популярности? Или всё ещё впереди, а молодые JVM-языки вроде Scala и Kotlin помогут всей экосистеме?

— Вскоре после появления Java, во время её стремительного взлёта, было очень ясное ощущение, что Java станет «концом истории». От крошечной смарт-карты и до мощнейшего сервера — Java появилась, чтобы повелевать ими всеми.

Теперь мы знаем, что получилось совсем не так. Java укоренилась на серверах, но теперь ей в затылок дышит Node.js. Не по каким-либо техническим причинам, а потому что «фуллстековые» разработчики не хотят писать клиентскую сторону на JavaScript, а серверную на Java. Учитывая, что UI на Java сегодня редкость, это проблема. Если бы я был королём Java, я бы удостоверился, что Java останется языком для Android, а также продвигал Java-to-JavaScript технологию для браузеров. Но очевидно, что я не являюсь королём Java.

Я также вижу много энтузиазма вокруг Python в областях вроде data science. Нет никакой причины, по которой соответствующие библиотеки не могли бы быть написаны на Java, но они написаны не на ней. И на Kotlin их тоже не пишут. У Scala есть свои заметные территории, особенно Spark.

Моё предсказание очень скучное. Я думаю, мы увидим, как C/C++ продолжат терять позиции, Python и JavaScript будут расти, а новые приятные языки (и на JVM, и не только) будут заявлять о себе, но не достигать такой же популярности. И год за годом техническая пресса будет оказываться удивлена тем, что Java по-прежнему очень популярна, хотя её уже годами провозглашали как теряющую популярность.



На конференции Joker, которая состоится в Петербурге 3-4 ноября, Кей выступит с двумя докладами: «Java 9: the good parts (not modules)» и «Concurrency for humans».

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

https://habrahabr.ru/post/334502/


Метки:  

Мониторинг Raspberry PI

Понедельник, 31 Июля 2017 г. 12:48 + в цитатник

Возникла передо мной такая задача: сделать мониторинг Raspberry PI. И требования:


  • самодостаточность. Возможность показывать статус и исторические данные без доступа в интернет.
  • работа в Java Embedded compact1 profile. Это всё по следам Java и без 16Gb памяти?.


Анализ требований


Здесь и далее под мониторингом системы я буду понимать сбор time series данных. Например, JVM heap size или количество обработанных сообщений за интервал.


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


  • InfluxDB. Специальная база для хранения time series данных. Умеет делать аггрегации и data retention. Opensource версия не поддерживает кластеризацию, но для Raspberry PI и не нужно. Проблема с системными требованиями: CPU 2-4 ядра и RAM 2-4 Gb. Не подходит.
  • Graphite. Хранит данные в базе данных whisper, который, как уверяется, немного лучше RRD. В зависимостях Python 2.7 и Django. Имеет свой собственный интерфейс, который надо бы ещё интегрировать в существующую админку. Ну можно конечно же взять… Но когда на сервере сплошная Java, стоит ли тащить весь мир Python? Опять же запущенные WSGI процессы будут занимать дополнительную память.

Все остальные варианты найденные на просторах, не подошли либо потому, что надо вручную делать data retention, либо требовательны к ресурсам, либо уж совсем наколеночные.


А что если продолжить мысль про RRD и Java? Получается RRD4J. Эта библиотека на Java, которая полностью поддерживает все операции и возможности оригинального rrdtool. Единственное отличие — это несовместимость баз данных между rrdtool и RRD4J. Но с другой стороны это даже лучше. Базы, созданные оригинальным rrdtool, бинарно несовместимы между различными архитектурами.


Итак, RRD. Он идеально подходит для Raspberry PI:


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

Но и не без проблем:


  • не совместим с compact1 профайлом. RRD4J написан, похоже, в лихие 2000-е, когда шаблон visitor был очень модным, поэтому базовые классы зависят от org.w3c.*. Оказывается одной из фич оригинального rrdtool была возможность писать в XML вместо бинарного файла. И эту фичу RRD4J гордо скопировал. Решается просто: делается hard fork и удаляется все ненужное. Грязно, но работает.
  • создание графиков. С самой генерацией проблем нет. Графики действительно получаются красивые. Но вот шаблоны создания никуда не годятся. В те же лихие 2000-е, когда RRD был на пике популярности, вполне нормальным считалось добавление команды rrdgraph в crontab и выполнение с периодом в 5 минут. Заставлять генерировать .png графики на Raspberry PI — дело неблагородное. Слишком много ресурсов будет тратиться. А если учесть специфику проекта (вэб-админка, которая используется в лучшем случае раз в год), то видимо нужно придумать более хитрую схему.

RRD4J-js


И тут мне в голову приходит осознание. Мы же в 2017 году! Время, когда у нас есть стандарты на передачу бинарных файлов в браузер и разные мощные javascript библиотеки для рисования графиков. Что если передавать скачивать RRD базу с сервера как есть, вытаскивать из неё данные и рисовать уже какой-нибудь готовой и проверенной временем Javascript библиотекой?


Посидев несколько ночей в попытке понять как писать на Javascript и создать плагин для Jquery (а на нём ещё модно писать?), я создал rrd4j-js.


Суть проекта достаточно проста: скачивать RRD, парсить и передавать данные для отрисовки во flot. А уже плагинами flot добивать нужные стили и интерактив. В итоге, решение оказалось даже лучше, чем стандартные графики rrdgraph:


  • по наведению мышки в подсказке можно отображать значение точки в момент времени
  • растягивать, сжимать и изменять размер графика в зависимости от разрешения экрана
  • форматировать данные в зависимости от типа. Например, с помощью jquery.flot.byte можно форматировать данные в килобайты, мегабайты и гигабайты.


Библиотека получилась достаточно простая. Больше всего времени конечно заняло выяснение конвенций по оформлению кода, созданию классов (sic!) в javascript и попытке поделиться проектом с миром.


Я с самого начала решил сделать самодостаточную библиотеку, которую можно загрузить в npm. После нескольких попыток это сделать, у меня, конечно же, всё получилось. Но тут же выяснилось, что npm используется только для server-side разработки на nodejs. И нельзя просто так зарелизить библиотеку в правильный репозиторий. Да что тут стесняться: нельзя понять какой из репозиториев правильный. В итоге я остановился на npm. Может кто-нибудь сведущий подскажет как правильно?


Послесловие


С получившимся инструментом, уже можно было начинать творить. А именно периодически сохранять метрики в RRD4J. Обвязка в виде достаточно распространённых metrics работающая в compact1 — приятное дополнение. В итоге пришлось написать достаточно простой RRD4JReporter, который расширяет com.codahale.metrics.ScheduledReporter и пользоваться в удовольствие.

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

https://habrahabr.ru/post/334508/


Метки:  

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

Понедельник, 31 Июля 2017 г. 11:05 + в цитатник
В ходе этой истории было наделано столько глупостей, что описать их кратко не представляется возможным, поэтому я начну с конца: как уже было сказано в названии, несколько дней назад восемнадцатилетний парень был арестован за то, что якобы «взломал» новую систему по продаже электронных билетов на общественный транспорт в Будапеште, хотя он сразу же сообщил администрации об обнаруженной уязвимости.



История получила широкий отклик в прессе и социальных сетях, и возмутительные действия полицию вызвали бурную реакцию: на страницах Facebook организаций, вовлеченных в скандал, за эти дни появились десятки тысяч «однозвездочных» отзывов. Эти организации — Управление транспорта в Будапеште (оператор нового сервиса, который мы впоследствие будем называть BKK — аббревиатурой венгерского названия) и T-Systems Hungary, разработчики и мейнтэйнеры системы по продаже электронных билетов. T-Systems Hungary принадлежит компании Telekom Hungary, которая, в свою очередь, является дочерней компанией Deutsche Telekom. T-Systems также представляет бренд Deutsche Telekom и является достаточно крупным игроком, обслуживающим всю Европу. Кстати, поэтому отзывы размещались на главной (немецкой) странице организации, а не на странице венгерского отделения — у последнего не подключена соответствующая функция.

Все началось несколько недель назад, когда BKK объявила о запуске мобильного сервиса — системы по продаже электронных билетов. Все, и я в том числе, встретили эту новость со смесью энтузиазма и удивления. Мы знали, что они работали над системой на базе NFC и смарт-карт последние четыре года без каких-либо видимых результатов, невзирая на вложенные в эту инициативу миллионы (последняя статья на эту тему, которую я читал, называла сумму в девять миллионов евро). Первое, что пришло мне в голову, когда я услышал это объявление: «Как так вдруг, ведь до сих пор было тихо — ни слухов, ни новостей?» и «Интересно, что они предпримут, чтобы систему нельзя было обмануть, какие будут применять механизмы, чтобы не допустить копирование и обеспечить безопасность...».

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

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

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

  • Система хранит пароли в виде простого текста и по запросу высылает их на почту пользователям. Соответственно, во многих случаях тот, кто получает доступ к системе, получает и доступ к почте (давайте начистоту: большинство людей используют один и тот же пароль для всех сайтов);
  • После авторизации пользователи имели возможность просматривать данные других аккаунтов (новостная статья не уточнила, как именно, видимо, путем манипуляций с URL). То есть у приложения не была отлажена система разрешений. Многие утверждали, что таким образом получили доступ к профилям других пользователей. К слову, информация, которую нужно указать при регистрации, включает имя, адрес и данные идентификационного документа (национальной ID-карты, водительских прав или паспорта). Все это должно соответствовать действительности: проверяющие могут потребовать подтверждения, что билет действительно принадлежит вам.
  • Если просто вбить в адресную строку shop.bkk.hu, страница вообще не загружалась. Я сначала было подумал, что они отключили сайт, но оказывается, у них просто не был настроен редирект http -> https. И сайт провисел в таком состоянии несколько дней. Те, кто просто услышал где-то адрес, не могли на него попасть. Необходимо было именно кликнуть по ссылке — ведь среднестатистический пользователь не додумается добавить https в начале, мне и самому это не пришло в голову.
  • В Сафари на iOS устройствах билеты не отображались.
  • Кто-то выяснил, что пароль администратора — adminadmin и успешно зашел в систему под его аккаунтом.
  • Разумеется, копировать билеты оказалось плевым делом. В Сети выложили видео, на котором пассажиры проходят контроль раз за разом без каких-либо проблем. Кондукторы использовали устройство для считывания QR-кода только пару раз — у большинства их нет, да и с сервисом они не особо знакомы — и даже в этих случаях «зайцев» не вычислили. Я бы сказал, ничего удивительного.
  • Но самая смехотворная дыра в системе, которую, насколько мне известно, обнаружили первой — это то, что пользователь мог задавать цену за билет, который собирался купить.


Именно этот последний пункт списка открыл восемнадцатилетний господин, о котором я говорил в самом начале. По его словам, он еще даже не умеет писать код (осенью только начинает учебу в университете). Он просто использовал общедоступные инструменты для разработчиков из браузера, увидел, собираясь сделать покупку, что информация о цене отсылается на сервер и решил просмотреть, получится ли ее изменить. Проездной на месяц стоит 9500 форинтов (примерно 30 евро), он же поставил цену в 50 форинтов. Когда пришло подтверждение, что платеж засчитан, и проездной благополучно загрузился в приложении, он тут же написал в BKK (в отделение по управлению транспортом), что у них серьезная проблема. В ответ ему пришло оповещение, что его проездной признан недействительным, и больше ни слова. Зато через несколько часов, когда об этой и других вышеперечисленных ошибках стали говорить на каждом углу, BKK вместе с T-Sytems Hungary принялись отчаянно всеми возможными способами прикрывать тылы, по-другому не скажешь.

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

Также на пресс-конференции представитель T-Systems Hungary заявил, что они приветствуют оповещения об ошибках, а также, что они уже передали информацию об одной однозначно противозаконной попытке взлома в полицию. Хотя на той же пресс-конференции упоминалось что-то смахивающее на внедрение SQL-кода, я больше чем уверен, что речь шла об этом восемнадцатилетнем бедолаге-«хакере», которому хватило ума написать им. Представители BKK заверяли, что, хотя система постоянно подвергается хакерским атакам, все они безуспешны, так что необходимости закрывать сервис нет — вся информация в полной безопасности.

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

После бурной реакции, которой был встречен этот инцидент, в BKK запели по-другому — от обвинений и отрицания они перешли к позиции «жаль, что с ним так все получилось». Даже директор T-Systems, хоть и написал пост с чем-то вроде извинений, так и не признал, что заявлять в полицию было не лучшей идеей (только ссылался на внутреннюю политику компании, которая их к этому побудила) или что система не соответствует требованиям. Он говорил в основном о том, какая это неоднозначная ситуация и как она показывает, что в обществе сейчас нет единого мнения о том, когда взлом системы можно считать этичным действием. Пара интересных фактов: во-первых, раньше они прямым текстом называли действия парня неэтичными, так как он действовал без их ведома, во-вторых, достаточно посмотреть, как отреагировали на это происшествие IT-специалисты, чтобы убедиться, что единое мнение очень даже существует.

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

  • BKK заказала и одобрила систему с кучей примитивных ошибок. Серьезно, среднестатистический джуниор только-только из буткемпа за неделю-другую может сделать решение получше. А если вам кажется, что я преувеличиваю, то уж у опытного разработчика проблем с этим точно бы не возникло.
  • T-Systems Hungary согласились взять в работу (причем скорее всего с нереальными сроками) решение, которое никуда бы не годилось, даже если реализовать его как следует — я исхожу из того, что обеспечить защиту от мошенников и пресечь дублирование билетов было не их задачей. А потом сделали все так, как сделали. И какой-то менеджер сказал: «Все в порядке, выкатываем».
  • BKK платит T-Systems Hungary 80 000 евро в месяц на поддержание системы в рабочем состоянии. Звучит подозрительно, потому что одного такого платежа было бы достаточно, чтобы покрыть все расходы по разработке, даже при качественном воплощении идеи. Двух-трех хватило бы и на менеджеров, и на дополнительное тестирование, и на малую толику откатов. Я не включил в эти расчеты устройства для считывания QR и мобильные, которыми должны быть снабжены кондукторы, но на данный момент их раз-два и обчелся.


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

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

UPD: Оказывается, он находится под подозрением по другой статье — «Неправомерный доступ к компьютерной информации», но, внимательно изучив ее текст, я думаю, что и это не подходит к данной ситуации.

UPD2: Директор BKK сообщил прессе, что они не получили письмо с сообщением об ошибке, так как парень отправил его по неправильному адресу. Разумеется, он не замедлил предоставить скриншот, который опровергает это заявление.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334480/


Метки:  

Докеризация высокодоступного Postgres кластера

Понедельник, 31 Июля 2017 г. 10:31 + в цитатник

Приглашаю на летние открытые лекции по игровой индустрии в ВШБИ

Понедельник, 31 Июля 2017 г. 10:04 + в цитатник
Наступает последний месяц лета, и его можно посвятить не только отдыху, но и получению новых знаний, впечатлений и связей! В течение всего августа в Москве в рамках программы «Менеджмент игровых проектов» будут проходить разнообразные открытые лекции.

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

В программе:

  • 4 августа(пятница) 2017 лекция на тему «Игровая индустрия: менеджмент»
  • 7 августа(понедельник) 2017 открытая лекция на тему «Попади в геймдев! Особенности трудоустройства в игровую индустрию»
  • 9 августа(среда) 2017 день открытых дверей по программам игровой индустрии
  • 11 августа(пятница) 2017 года лекция на тему «Игровая индустрия: художник в компьютерных играх»
  • 18 августа(пятница) 2017 года лекция на тему «Игровая индустрия: маркетинг»
  • 23 августа(среда) 2017 года открытая лекция «Геймдизайн: игровые механики»


Под катом подробности про каждое мероприятие и ссылки на регистрацию.



4 августа 2017 лекция на тему «Игровая индустрия: менеджмент» в рамках проекта «Университет, открытый городу: Вышка на ВДНХ».
Зарегистрироваться



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

Лектор – Уточкин Вячеслав, директор образовательных программ по игровой индустрии ВШБИ НИУ ВШЭ. Запускал многопользовательский танковый экшн Armored Warfare, оперировал популярную русскоязычную клиентскую MMORPG Perfect World, браузерный шутер «Бумз!» и другие игры в Mail.Ru Group. Имеет персональный опыт создания браузерных онлайн-игр, мобильных игр и VR-игр.


Начало в 19:00.
Приглашаются все желающие.

Ссылка на электронную регистрацию.
Адрес: ст. м. «ВДНХ», проспект Мира, д. 123б, МВЦ «Рабочий и колхозница». Схема проезда

7 августа 2017 открытая лекция на тему «Попади в геймдев! Особенности трудоустройства в игровую индустрию»
Зарегистрироваться



ЛЕКЦИЯ БУДЕТ ИНТЕРЕСНА:
— Людям, интересующимся играми и рассматривающим возможность начать работать в игровой индустрии;
— Начинающим специалистам, желающим узнать больше о поисках работы в индустрии;
— Опытным специалистам, сотрудникам игровых компаний, продюсерам и другим работникам игровой индустрии, нацеленным на получение знаний о современных критериях подбора специалистов в геймдев.

РАССМАТРИВАЕМЫЕ ВОПРОСЫ:
— Разнообразие специализаций в игровой индустрии. Преимущества и недостатки профессий «программист», «художник», «продюсер», «комьюнити-менеджер» и т.д. Особенности порога входа для каждой из профессий неопытному/опытному кандидату.
— Специфика графика работы в геймдеве: фриланс, работа в офисе и работа над собственным проектом;
— Зарплаты в геймдеве.

Открытую лекцию будут вести директор по развитию и обучению персонала 101ХР – Олег Доброштан и HR Manager 101ХР – Юлия Ковалёва.



Начало регистрации: 18:30.
Начало мероприятия: 19:00.


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

9 августа 2017 день открытых дверей по программам игровой индустрии
Зарегистрироваться



9 августа (среда), в 19:00, пройдет день открытых дверей, посвященный осеннему набору на программу профессиональной переподготовки «Менеджмент игровых проектов» . Если вы любите игры, вам интересен процесс их разработки, запуска и продвижения, вы давно лелеете мечту о собственной игре, уже работаете в игровой компании или просто у вас есть вопросы про создание игр, то вам будет интересно и полезно посетить наш день открытых дверей по программам подготовки кадров для игровой индустрии!

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

Все участники могут рассчитывать на:
— Детальное описание программы, ее слушателей, преподавателей и образовательного процесса;
— Ответы на все свои вопросы касательно обучения на программах по игровой индустрии ВШБИ и игровой индустрии в целом;
— Общение в неформальной обстановке после дня открытых дверей с преподавателями и гостями мероприятия.



Начало в 19:00.

Ссылка на электронную регистрацию.

Место проведения: ул. Трифоновcкая, д.57, стр. 1 (ст. метро Рижская). Схема проезда
Пожалуйста, возьмите с собой документ, удостоверяющий личность.

11 августа 2017 года лекция на тему «Игровая индустрия: художник в компьютерных играх»
Зарегистрироваться



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

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

ЛекторВера Величко, преподаватель образовательных программ по игровой индустрии ВШБИ НИУ ВШЭ, основательница студии Owl Studio, рисует более 22 лет, восемь из них – в геймдеве. Руководила разработкой арта для множества проектов различной стилистики и жанров.


Начало в 19:00.

Приглашаются все желающие.
Ссылка на электронную регистрацию.
Адрес: ст. м. «ВДНХ», проспект Мира, д. 123б, МВЦ «Рабочий и колхозница». Схема проезда

18 августа 2017 года лекция на тему «Игровая индустрия: маркетинг»
Зарегистрироваться



Поздравляем вас! Вы сделали отличную компьютерную (или мобильную) игру! Но что толку, если об этом никто не узнает? В современном мире, где каждый день выходят тысячи игр, именно маркетинг определяет, достигнете ли вы успеха. Будет ли ваша игра на слуху или умрет в безвестности? Сможете ли вы получить поддержку магазинов и внимание прессы или предел вашей аудитории – друзья и коллеги по работе? Именно маркетинг игр сейчас как никогда актуален, ведь предложение, как правило, значительно превышает спрос.
Именно о том, как сейчас строится маркетинг игр, что нужно делать начинающим разработчикам, как продвигать своей проект (особенно если маркетинговый бюджет не особенно велик), и пойдет речь на лекции.
Как определить целевую аудиторию своей игры? Что такое «закупки трафика» и почему пресс-релизы больше не помогают привлечь должное внимание игровой прессы? Стоит ли показывать свой проект на игровых выставках и какие они вообще бывают? Обо всем этом узнаете в ходе лекции.
ЛекторСергей Зыков, преподаватель образовательных программ по игровой индустрии ВШБИ НИУ ВШЭ, профессионал и эксперт более чем с 12-летним стажем в игровой индустрии.



Начало в 19:00.
Приглашаются все желающие.
Ссылка на электронную регистрацию.
Адрес: ст. м. «ВДНХ», проспект Мира, д. 123б, МВЦ «Рабочий и колхозница». Схема проезда

23 августа 2017 года открытая лекция «Геймдизайн: игровые механики»
Зарегистрироваться



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

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

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

Открытую лекцию будет вести преподаватель дисциплины «Игровые механики» на программе «Менеджмент игровых проектов» — Сергей Гимельрейх. Продюсер, геймдизайнер, основатель студии ORC WORK.



Начало в 19:00.

Ссылка на электронную регистрацию.

Место проведения: ул. Трифоновcкая, д.57, стр. 1 (ст. метро Рижская). Схема проезда
Пожалуйста, возьмите с собой документ, удостоверяющий личность.

До встречи на наших мероприятиях!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334482/


Метки:  

Команда веб-студии: система роста, аттестация и мотивация

Понедельник, 31 Июля 2017 г. 10:03 + в цитатник


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

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

Семь поясов WebCanape, или матрица роста сотрудников


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

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



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

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

Прикрепляю пример системы роста для менеджеров отдела разработки сайтов.

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

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

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

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

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

Аттестация или экзамены на знание продуктов компании


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

Аттестация проходит 2 раза в год, как обычный экзамен. Два теоретических вопроса и один практический. Тексты билетов доступны всегда на сервере. Бери и готовься. Если не сдаешь экзамен, «сваливаешься» на ступеньку ниже. Не сдашь второй раз — поднимается вопрос о твоей профпригодности и необходимости дальнейшего сотрудничества.

Система мотивации или финансового стимулирования


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

Далее речь пойдет про расчет премии. Хочу отметить, что премия – это ПРЕМИЯ – награда за исключительный результат. За хороший результат сотрудник получает оклад, а за отличный – оклад+ премию. Многие считают премию чем-то естественным, само собой разумеющимся. Так не должно быть.

Премирование менеджеров разработки сайтов. Размер премиального фонда на менеджеров можете определять самостоятельно. Например, как % от прибыли или оборота. Между менеджерами эта потенциальная премия (фонд) распределяется в таком же процентном соотношении, как их вклад в общий котел. Иванов принес 70% дохода, Петров 30% дохода. Значит так же поделится премиальный фонд. Каждый менеджер должен сдать в месяц проектов на X денег. Это условие получения премии. Если сдал, значит ему положена премия, если нет — только оклад. Далее включаются понижающие коэффициенты, если нарушены показатели эффективности. Берутся средние коэффициенты по всем проектам за месяц и перемножаются. Формула простая:

  • Премия.факт = Премия.план*Нормативы*Сроки*Отзыв
  • Нормативы: 100% выполнения = 1, 90% выполнения = 0.9 и т.д.
  • Сроки: 100% выполнения = 1, 90% выполнения = 0.9 и т.д.
  • Отзыв: 1,2 – 0 (ноль), 3 – 0.8, 4-5 – 1


Чтобы менеджер получил 100% своей премии, все коэффициенты должны быть равны 1.
Это упрощенная система относительно той, что используется в WebCanape. Она может балансировать в ту или иную сторону за счет ввода коэффициентов или новых показателей, на которые вы хотите обратить внимание менеджеров. Есть мнение, что систему мотивации для линейных менеджеров следует менять один раз в 6 месяцев.

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

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

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

Команда WebCanape
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334458/


Китай ужесточает регулирование VPN

Понедельник, 31 Июля 2017 г. 10:00 + в цитатник
Правительство Китайской Народной Республики сообщило локальным провайдерам и телекоммуникационным компаниям о необходимости блокирования незаконного использования VPN частными лицами. Компании, работающие на территории страны, смогут продолжать пользоваться услугами официально зарегистрированных поставщиков VPN-сервисов.

/ Flickr / Surian Soosay / CC

Эти меры последовали сразу после очередных блокировок более 60 развлекательных сайтов и профилей в социальных сетях. Помимо этого был частично ограничен контент социального сервиса Weibo Corp, а компания заявила о готовности к более активной работе с государством.

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

Рынок китайских VPN-сервисов продолжал оставаться «серым» многие годы. Сейчас он может потерять основную аудиторию или полностью прекратить свое существование.

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

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

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

После сообщения о приостановлении работы GreenVPN и Haibei VPN их зарубежные аналоги вроде KeepSolid VPN, VyprVPN, ExpressVPN и PureVPN заявили о «наплыве» пользователей и подчеркнули, что не видят каких-либо проблем для работы с китайской аудиторией.

И сразу начали получать уведомления в том числе и от Apple о том, что приложение будет снято с китайской «витрины» Apple Store по запросу властей. Об этом представители ExpressVPN и VyprVPN рассказали журналистам The New York Times (кстати, приложение самого издания было аналогичным образом скрыто из китайской версии Apple Store).

Дополнительное чтение:


О чем еще мы пишем:

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

https://habrahabr.ru/post/334406/


Метки:  

grab'им караваны ЛитРес в ознакомительных целях

Понедельник, 31 Июля 2017 г. 09:42 + в цитатник

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


Право читать обошлось в 2/3 от стоимости бумажного носителя, если брать с сайта издательства.


Справедливости нет. есть только я

Смерть


И тут я решил написать grabber.


За основу взял QWebEngineView, что бы не заморачиваться с авторизацией. И внешне это выглядит так:


Sharing куков между QNetworkAccessManager и QWebEngineView


Для этого в Qt есть QWebEngineCookieStore и
QNetworkCookieJar


MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    m_ui(new Ui::MainWindow),
    m_store(nullptr),
    m_cookieJar(new QNetworkCookieJar (this)),
    m_networmManager(new QNetworkAccessManager(this)),
    m_try(0),
    m_currentPage(0),
    m_capches(1)
{
    m_ui->setupUi(this);

    m_store = m_ui->webView->page()->profile()->cookieStore();
    Q_ASSERT(m_store != nullptr);
    connect(m_store, &QWebEngineCookieStore::cookieAdded, this, &MainWindow::handleCookieAdded);
    m_store->loadAllCookies();
    m_ui->webView->load(QUrl("https://www.litres.ru/"));
    m_networmManager->setCookieJar(m_cookieJar);

    connect(m_networmManager, &QNetworkAccessManager::finished,
            this, &MainWindow::handleImage);
}

void MainWindow::handleCookieAdded(const QNetworkCookie &cookie)
{
    m_cookieJar->insertCookie(cookie);
}

Когда переходим на чтение книги и нажимаем на кнопку Grab, то берется url вида:


https://www.litres.ru/static/or3/view/or.html?art_type=4&file=26599915&bname=Разработка веб-приложений в ReactJS&cover=%2Fstatic%2Fbookimages%2F26%2F59%2F99%2F26599923.bin.dir%2F26599923.cover.jpg&art=22880082&user=Что-то&uuid=Что-то

Вытаскиваем id файла и название:


void MainWindow::onGrabButtonClicked()
{
    if(!parseUrl(m_ui->webView->url()))
    {
        return;
    }

    const auto paths = QStandardPaths::standardLocations(QStandardPaths::DownloadLocation);
    if (paths.isEmpty()) {
        qWarning()<<"There is no standard path to download";
        return;
    }
    downloadTo(*paths.begin());
}

bool MainWindow::parseUrl(const QUrl &url)
{
    const auto query = QUrlQuery(url.query(QUrl::FullyDecoded));
    if (query.isEmpty()){
        return false;
    }

    static const QVector fields = {
        "file", "bname", "uuid"
    };

    for (const auto& key: fields) {
        if (!query.hasQueryItem(key)) {
            qWarning()<<"Query hasn't param"<< key;
            return false;
        }
    }

    m_name = query.queryItemValue("bname", QUrl::FullyDecoded);
    m_file = query.queryItemValue("file");
    m_format = "jpg";

    return true;
}

MainWindow::downloadTo настраивает QPdfWriter и QPainter


void MainWindow::downloadTo(const QString &path)
{
    QDir dir(path);

    m_writer = std::make_unique(dir.absoluteFilePath(m_name+".pdf"));
    QPageLayout layout(QPageSize(QPageSize::A4), QPageLayout::Portrait,
                       QMarginsF(0,0,0,0));

    m_writer->setPageLayout(layout);
    m_writer->setResolution(96);
    m_writer->setTitle(m_name);
    m_painter = std::make_unique();
    m_painter->begin(m_writer.get());

    nextImage();
}

Скачивание страницы


Страницы скачиваются по url вида:


https://www.litres.ru/pages/read_book_online/?file=26599915&page=2&rt=w1280&ft=gif

Параметр Описание
rt отвечает за размеры, принимает значение w640, w1280
ft формат gif или jpg
page номер страницы
file идентификатор файла

Формат jpg применяется для страниц с графикой, в то же время gif для текста.
Если страницы по url: https://www.litres.ru/pages/read_book_online/?file=26599915&page=0&rt=w1280&ft=gif не существует, то следует запросить https://www.litres.ru/pages/read_book_online/?file=26599915&page=0&rt=w1280&ft=jpg


Получаем:


void MainWindow::nextImage()
{
    QUrlQuery query;
    query.addQueryItem("file", m_file);
    query.addQueryItem("rt", "w640");
    query.addQueryItem("ft", m_format);
    query.addQueryItem("page", QString::number(m_currentPage));

    QUrl url(BasePath);
    url.setQuery(query);
    m_networmManager->get(QNetworkRequest(url));
    ++m_currentPage;
}

void MainWindow::handleImage(QNetworkReply *reply)
{
    reply->deleteLater();

    if (reply->error() != QNetworkReply::NoError) {
        qWarning()<<"Network error"<errorString();
        if(m_try == 3) {
            m_painter->end();
            m_painter.reset();
            m_writer.reset();
            return;
        }

        if (m_format == "gif") {
            m_format = "jpg";
        } else {
            m_format = "gif";
        }
        --m_currentPage;
        ++m_try;
        nextImage();
        return;
    }
    m_try = 0;

    qDebug()<<"Write page"<url();
    std::string f;
    if (m_format == "jpg") {
        f = "JPEG";
    } else {
        f = "GIF";
    }
    const auto data = reply->readAll();
    const auto source = QImage::fromData(data, f.c_str());
    if (source.isNull()) {
        //handleCapcha(data, reply->url());
        --m_currentPage;
        nextImage();
        return;
    }

    m_ui->pages->setText(QString::number(m_currentPage));
    const auto dest = source.scaledToWidth(m_writer->width()/*, Qt::SmoothTransformation */);
    m_painter->drawImage(QPoint(0,0), dest);
    m_writer->newPage();

    nextImage();
}

Капча


Капча вроде бы есть, но в тоже время нет. Выскакивает не всегда


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

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


void MainWindow::handleCapcha(const QByteArray &page, const QUrl &url )
{
    ++m_capches;
    m_ui->webView->page()->setHtml(page, url);
    m_ui->captches->setText(QString::number(m_capches));
    QEventLoop loop;
    constexpr int duration = 1000*60*5;
    QTimer::singleShot(duration, &loop, &QEventLoop::quit);
    loop.exec();
}

Тут загружаем в WebView страницу с капчей. После чего, можем ввести капчу.


Итого


Книга объемом 256 страниц в PDF со страницами A4 и DPI 96 весит 51,7 МБ против 5,8 МБ зашифрованного документа.
Код доступен на GitHubGist

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

https://habrahabr.ru/post/334412/


Метки:  

Pygest #14. Релизы, статьи, интересные проекты из мира Python [18 июля 2017 — 31 июля 2017]

Понедельник, 31 Июля 2017 г. 09:35 + в цитатник
image Всем привет! Это уже четырнадцатый выпуск дайджеста на Хабрахабр о новостях из мира Python.

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

А теперь к делу!


Релизы


Python 3.6.2
Python 3.5.4rc1, Python 3.4.7rc1

Статьи


Яндекс открывает технологию машинного обучения CatBoost
О новом инструменте для машинного обучения от Яндекс

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

The 2017 Top Programming Languages
Python на первом месте в рейтинге языков от IEEE Spectrum

Refactoring with tests in Python: a practical example
О рефакторинге в Python

Efficient management Python projects dependencies with Docker
Об управлении зависимостями в Python проектах с использованием Docker

Introducing Dash. Create Reactive Web Apps in pure Python
Статья о том, как создавать реактивные веб-приложения на чистом Python

Revisiting Unit Testing and Mocking in Python
О юнит-тестировании и моках в Python

Dockerizing Django, uWSGI and Postgres the serious way
Туториал о том, как использовать Docker для разработки на Python

Django Anti-Patterns: Signals
Об одном из анти-паттернов в Django — сигналах

CPython Core Tutorial
Полный туториал о том, как контрибьютить в CPython

Интересные проекты


Quart
Асинхронный веб микрофреймворк с API как у Flask

Cranky Coin
Пример криптовалюты на Python

Dependency
DI-фреймфорк для Python

Видео


PyData Seattle 2017
Записи выступлений с конференции PyData Seattle 2017

Предыдущий выпуск дайджеста ищете здесь:

Pygest #13. Релизы, статьи, интересные проекты из мира Python [04 июля 2017 — 17 июля 2017]

Спасибо за внимание! Присылайте Ваши предложения для публикации в дайджесте!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334474/


Метки:  

[recovery mode] Работа с базами данных в среде разработки 3CX Call Flow Designer

Понедельник, 31 Июля 2017 г. 09:31 + в цитатник

Введение


В этой статье мы расскажем, как делать запросы к базе данных SQL Server из 3CX Call Flow Designer, используя компонент Database Access. Отметим, что компонент Database Access также может работать с базой PostgreSQL, которую использует 3CX Phone System.

Демо-проект этого голосового приложения поставляется вместе с дистрибутивом 3CX CFD и находится в папке Documents\3CX Call Flow Designer Demos. Если вы захотите им воспользоваться – просто укажите расположение вашей базы данных и учетные данные доступа.

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

Создание проекта


Для создания проекта CFD перейдите в File > New > Project, укажите папку размещения проекта и его имя, например, DatabaseAccessDemo.



Запрос ПИН-кода у пользователя


ПИН пользователя запрашивается с использованием компонента User Input. Добавим компонент в голосовое приложение:
  • Перетащите компонент User Input из набора компонентов слева в главный экран приложения. Выберите компонент и в окне Properties переименуйте его в requestPIN.
  • Дважды кликните по компоненту, чтобы открыть окно конфигурации, и установите следующие свойства:
    • Initial Prompts – укажите WAV файл, в котором у пользователя будет запрашиваться ПИН, например, “Введите ваш персональный идентификационный номер”. Формат WAV файла: PCM, 8 kHz, 16 bit, Mono.
    • Subsequent Prompts – укажите WAV файл с более подробными пояснениями по вводу. Он проигрывается только, если пользователь сделал неверный ввод или вообще ничего не ввел. Например, “Введите ваш персональный идентификационный номер. Допускаются цифры от 0 до 9 и длина — от 3 до 6 цифр”.
    • Timeout Prompts – укажите WAV файл с предупреждением о том, что ничего не было введено, например, “К сожалению, мы не получили ввод от вас”.
    • Invalid Digit Prompts – укажите WAV файл с предупреждением о некорректном (слишком мало цифр или они недопустимы), например, “К сожалению, вы некорректно ввели ПИН”.

  • Остальные опции настройте, как показано ниже, и нажмите OK для сохранения.



Проверка введенного ПИН в базе данных


После получения ПИН от пользователя, его следует проверить в базе данных. Для этого добавим компонент Database Access в ветвление компонента Valid Input, предполагающее верный ввод. Переименуйте компонент в validatePIN и дважды кликните на нем, чтобы установить свойства:
  • Database Type — выберите SqlServer.
  • Configure each property separately – выберите эту опцию, чтобы указать параметры подключения по отдельности. Однако, вы можете указать и строку подключения к базе данных.
  • Server – имя или IP адрес сервера базы данных. Это поле может быть и выражением, поэтому, если вы указываете константу, возьмите ее в кавычки.
  • Port – порт SQL сервера. При использовании стандартного номера порта, это поле можно оставить пустым.
  • User Name и Password – учетные данные подключения к базе данных. Значения также могут переменными.
  • Statement Type – укажите Scalar, т.к. требуется получить только одно значение из базы – количество записей о пользователе с данным ПИН.
  • Timeout – оставьте по умолчанию 30 сек. или измените, при необходимости.
  • SQL Statement – в этом поле указывается строка запроса к базе данных. Но предварительно добавим параметр в раздел Parameters, который используется в строке запроса. Параметр – это ПИН, введенный пользователем.
  • id – имя переменной, requestPIN.Buffer – значение, т.е. буфер ввода в компоненте User Input (который мы ранее назвали requestPIN)

Теперь введем строку запроса к базе. Используйте небольшую кнопку справа от окна ввода, чтобы вставить значение переменной id. Наша строка имеет вид:

SELECT count(*) FROM customers WHERE id={0}

Окно свойств компонента Database Access должно выглядеть примерно так:



Проверка результата SQL запроса и выбор дальнейших действий


Настроив компонент Database Access, перейдем к проверке ПИН. Для этого добавим компонент Create a Condition с двумя условиями (ветвлениями) – успешная и неуспешная валидация.

Перетащите компонент из левой части и переименуйте в validateDatabaseResult. Переименуйте ветвления в success и error. Окно среды разработки должно выглядеть примерно так:



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

EQUAL(validatePIN.ScalarResult,1)

image

После того, как вы указали условия для ветвления success, добавьте компоненты Prompt Playback для всех возможных ветвлений голосового приложения: ПИН найден, ПИН не найден и ПИН введен неверно допустимое количество раз (у нас в компоненте User Input Max Retry Count=3). В параметрах компонентов укажите соответствующие WAV файл уведомлений.

После этого в ветвление success добавьте компонент Transfer, который будет переводить вызов на сотрудника. Голосовое приложение будет иметь примерно такой вид:



Компиляция и установка приложения на сервер 3CX


Голосовое приложение готово! Теперь его следует скомпилировать и загрузить на сервер 3CX. Для этого:
  • Перейдите в меню Build > Build All, и CFD создаст файл DatabaseAccessDemo.tcxvoiceapp.
  • Перейдите в интерфейс управления 3CX, в раздел Очереди вызовов. Создайте новую Очередь вызовов, укажите название и добавочный номер Очереди, а затем установите опцию Голосовые приложения и загрузите скомпилированный файл.
  • Сохраните изменения в Очереди вызовов. Голосовое приложение готово к использованию.



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

Загрузки и документация


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

https://habrahabr.ru/post/334472/


Play with Docker — онлайн-сервис для практического знакомства с Docker

Понедельник, 31 Июля 2017 г. 09:28 + в цитатник


В конце прошлого года два капитана Docker представили свою разработку под названием Play with Docker (PWD) — «игровую площадку для Docker». Пользователям предлагается бесплатно поработать со сборкой и запуском Docker-контейнеров прямо в веб-браузере, а также выполнить лабораторные работы для знакомства с Docker с нуля и совершенствования своих навыков.

Игровая площадка


Основной сайт сервиса — play-with-docker.com, который после прохождения CAPTCHA пересылает на один из облачных хостов, где стартует 4-часовая сессия «игровой площадки» (playground). В ней вы можете создавать новые сущности (instances), т.е. узлы тестового Docker-кластера. Каждый из них — это инсталляция легковесного дистрибутива Alpine Linux (на данный момент версии 3.6.2 с ядром Linux 4.4.0) с редактируемым локальным IP-адресом. В них установлен Docker актуальной версии 17.06 Community Edition.

Вся работа происходит прямо в веб-браузере:



Для эмуляции терминала используется JavaScript-реализация xterm.js от SourceLair, которая поддерживает множество современных браузеров (Chrome 48+, Edge 13+, Firefox 44+, Internet Explorer 11+, Opera 35+, Safari 8+). Терминал весьма удобен в работе, поддерживает стандартные клавиатурные сочетания, автодополнение по — в том числе и для команд/аргументов консольной команды docker.

Количество создаваемых сущностей ограничено пятью. А помимо стандартного образа системы со стабильным Docker можно выбрать и dev-вариант (сейчас он на базе Docker 17.07.0 CE RC1), и специальный образ с решением для управления кластерами UCP (Universal Control Plane), что означает наличие соответствующих образов (docker/ucp, docker/ucp-agent, docker/ucp-auth, docker/ucp-swarm…) для запуска в контейнерах:
[node4] (local) root@10.0.7.6 ~
$ docker run --privileged docker/ucp
docker/ucp                   docker/ucp-controller:2.1.5
docker/ucp-agent             docker/ucp-dsinfo
docker/ucp-agent:2.1.5       docker/ucp-dsinfo:2.1.5
docker/ucp-auth              docker/ucp-etcd
docker/ucp-auth-store        docker/ucp-etcd:2.1.5
docker/ucp-auth-store:2.1.5  docker/ucp-hrm
docker/ucp-auth:2.1.5        docker/ucp-hrm:2.1.5
docker/ucp-cfssl             docker/ucp-metrics
docker/ucp-cfssl:2.1.5       docker/ucp-metrics:2.1.5
docker/ucp-compose           docker/ucp-swarm
docker/ucp-compose:2.1.5     docker/ucp-swarm:2.1.5
docker/ucp-controller        docker/ucp:2.1.5

К слову о кластерах: в рамках вашей тестовой инсталяции на Play with Docker можно сделать и кластер с Docker Swarm. Последовательность действий для этого будет выглядеть примерно так:
# На первом узле кластера, который станет менеджером:
[node1] (local) root@10.0.7.3 ~
$ docker swarm init --advertise-addr 10.0.7.3
Swarm initialized: current node (txh3ffph72xarxjeg9gmpra2s) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-698vpn9u804ik4xdc9by60ytdabx3kuzyxj3vzhtr74qvkdlja-7xa6pwit58xzun989tao2nis7 10.0.7.3:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
[node1] (local) root@10.0.7.3 ~
$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS
txh3ffph72xarxjeg9gmpra2s *   node1               Ready               Active              Leader

# Теперь перейдите к консоли другого узла (например, node2)
[node2] (local) root@10.0.7.4 ~
$ docker swarm join --token SWMTKN-1-698vpn9u804ik4xdc9by60ytdabx3kuzyxj3vzhtr74qvkdlja-7xa6pwit58xzun989tao2nis7 10.0.7.3:2377
This node joined a swarm as a worker.

# Вернитесь к консоли первого узла (он является менеджером кластера)
[node1] (local) root@10.0.7.3 ~
$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS
szx0qqvj5zwt6a4nho9an54yx     node2               Ready               Active
txh3ffph72xarxjeg9gmpra2s *   node1               Ready               Active              Leader

Более подробную пошаговую инструкцию по работе с Docker Swarm в рамках Play with Docker можно найти в этом видео (на английском языке).

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

Обучение в PWD


Обучаться работе с Docker предлагается в формате лабораторных работ, которые опубликованы по адресу training.play-with-docker.com.

Сделаны они как пошаговые инструкции с пояснениями + запускаемый в сервисе Play with Docker эмулятор терминала, где вы можете исполнять предлагаемые инструкции (команды даже необязательно полностью вводить — достаточно кликать на листинги из описания слева, и они копируются/выполняются на терминале справа):



Главная страница лабораторных Play with Docker предлагает два гида:
  1. Эксплуатация (Ops) — начало работы с Docker для ИТ-специалистов и системных администраторов: первое знакомство с Docker, его основными концепциями и возможностями; более глубокое изучение особенностей Docker (архитектура, интеграция с имеющейся инфраструктурой); использование в production;
  2. Разработка (Dev) — начало работы с Docker для разработчиков: базовые концепции Docker и как в нём собирать/деплоить простые приложения; работа с реестрами образов и применение в непрерывной интеграции; деплой в staging, управление Docker Swarm, безопасность приложений.

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

PWD как Open Source


Замечательный факт про Play with Docker — публикация его исходных кодов на GitHub под свободной лицензией MIT и открытость авторов к модификациям от сообщества. В описании репозитория проекта так и говорится: «Вы знаете PWD, вы используете его — время улучшать!»

Это также означает, что вы можете запустить локальную версию Play with Docker для проведения всех нужных экспериментов на своих ресурсах. Инсталляция требует Docker 1.13+ и Go 1.7.1+. Технически для запуска сервиса используется возможность DIND (Docker-in-Docker), позволяющая запускать Docker внутри Docker. Для этого по умолчанию используется готовый образ от разработчиков (franela/dind), но при желании его можно модифицировать (использовать свой базовый образ).

Развитие


На апрельском DockerCon в рамках сессии Moby Cool Hack авторы Play with Docker представляли своё детище (доступно видео).

Там же они рассказывали о некоторых новых возможностях PWD:
  1. Драйвер для Docker Machine, позволяющий управлять PWD-хостами через терминал и подключаться к ним через SSH.
  2. Функция загрузки файлов с локального компьютера простым drag-n-drop в открытый терминал PWD в веб-браузере (предназначено для Dockerfile).
  3. Шаблоны для сессий, позволяющие развернуть Swarm-кластер из 5 узлов буквально за несколько секунд.
  4. Расширение для Chrome «Play with Docker», добавляющее кнопку «Try in PWD» для запуска популярных образов из DockerHub в этом онлайн-окружении, а также возможность встраивать подобную кнопку на своих сайтах (для своих образов):
  5. Новые лабораторные работы на ресурсе обучения (включая работу с multi-stage builds, которые появились в Docker 17.06).
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334470/


Метки:  

Интерфейс vs interface

Понедельник, 31 Июля 2017 г. 09:01 + в цитатник

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


Часто сложность в понимании принципа "программируйте на уровне интерфейса" кроется в концентрации на инструменте, а не на смысле. Из-за наличия в Java ключевого слова interface, происходит искажение понимания принципа, и он превращается в "программируйте, используя interface". Так как в Python инструмент в виде ключевого слова interface отсутствует, некоторые питонисты пропускают этот принцип.


В книге Банды Четырех примеры приводятся на Smalltalk и C++. Оба этих языка не имеют ключевого слова interface, но это не мешает авторам применять принцип, используя имеющиеся в распоряжении конструкции языка:


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


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

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


Реальный мир


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


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

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


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


Мир программного кода


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


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


class UserCollection:
    # Код инициализации пропущен
    def linear_search_for(user: User) -> bool:
        for saved_user in self._all_users:
            if saved_user == user:
                return True
        return False

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


class UserCollection:
    # Код инициализации пропущен
    def includes(user: User) -> bool:
        ''' Любая необходимая реализация '''

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


from utils import DatabaseConfig
# DatabaseConfig предоставляет доступ к конфигу,
# который хранится в БД

def is_password_valid(password: str) -> bool:
    min_length = DatabaseConfig().password_min_length
    return len(password) > min_length

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


# Зависимость от DatabaseConfig больше не нужна
def is_password_valid(password: str, min_length: int) -> bool:
    return len(password) > min_length

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


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


# utils.py
class DatabaseConfig:
    ''' Инициализация класса создает соединение с базой данных '''

config = DatabaseConfig()

# В этом же файле лежит функция с хорошим интерфейсом
def is_password_valid(password: str, min_length: int) -> bool:
    return len(password) > min_length

# user.py
from utils import is_password_valid
# В момент импорта происходит инициализация
# DatabaseConfig и подключение к БД

class User:
    def __init__(self, name: str, password: str):
        self.name = name
        self.password = password

    def change_password(self, new_password: str) -> None:
        if not is_password_valid(new_password, min_length=6):
            raise Exception('Invalid password')
        self.password = new_password

Импорт класса User в интерпретатор или тест, если необходимая БД не запущена, снова закончится ошибкой, которая раскрывает реализацию. Изменять интерфейс класса нет смысла, так как причиной бед в данном случае является выражение from utils import is_password_valid, а именно глобальная переменная, которая создается во время импортирования. Еще один недостаток глобальной переменной — она может стать причиной невозможности программировать на уровне интерфейса. Решить возникшую проблему можно с помощью создания экземпляра DatabaseConfig в момент старта приложения и явной передачи экземпляра всем заинтересованным объектам.


Отсутствие неявных зависимостей и отражающие суть названия, защищая нас от деталей реализации, все еще не позволяют получить все преимущества программирования на уровне интерфейса. Самое время обратиться к программированию строго через интерфейс абстрактного класса. Кент Бек в книге "Smalltalk Best Practice Patterns" пишет:


There are a few things I look for that are good predictors of whether a project is in good shape.



Replacing objects — Good style leads to easily replaceable objects. In a really good system, every time the user says “I want to do this radically different thing,” the developer says, “Oh, I’ll have to make a new kind of X and plug it in.”

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


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


# weather.py
from typing import List, NamedTuple

class Weather(NamedTuple):
    max_temperature_с: int
    avg_temperature_с: int
    min_temperature_c: int

class WeatherService:
    def get_today_weather(self, city: str) -> Weather:
        raise NotImplementedError

    def get_week_weather(self, city: str) -> List[Weather]:
        raise NotImplementedError

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


# test.py
from client import WeatherWidget
from weather import Weather, WeatherService

class FakeWeatherService(WeatherService):
    def __init__(self):
        self._weather = Weather(max_temperature_с = 24,
                                avg_temperature_с = 20,
                                min_temperature_c = 16)

    def get_today_weather(self, city: str) -> Weather:
        return self._weather

    def get_week_weather(self, city: str) -> List[Weather]:
        raise [self._weather for _ in range(7)]

def test_present_today_weather_in_string_format():
    weather_service = FakeWeatherService()
    widget = WeatherWidget(weather_service)
    expected_string = ('Maximum Temperature: 24 °C'
                       'Average Temperature: 20 °C'
                       'Minimum Temperature: 16 °C')
    assert widget.today_weather == expected_string

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


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

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

https://habrahabr.ru/post/332578/


Метки:  

Собеседования, рынок труда и прочее в городе Москве обр. лета 7525

Понедельник, 31 Июля 2017 г. 08:02 + в цитатник
Внезапно вечером в одном из форумов по готовым рецептам зашел разговор о кадрах. Что /b/ уже не тот. Но, как писал один таки умный человек - не говори: «отчего это прежние дни были лучше нынешних?», потому что не от мудрости ты спрашиваешь об этом, поэтому решено было написать статью, и выслушать мнение сторон. Или стороны. Или кого получится.
Мысли немного спутанные, но уж вышло как вышло.

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


Общеэкономическое
Рынок труда в РФ в целом.
Рынок труда в ИТ в Москве за 10 лет – с докризиса 2007 до осени 2008 и сейчас.
Зарплаты в технической части.
Новые интересные подходы к найму на примерах.

Кадровое.
Проблемы на рынке ИТ в Москве в целом, качество персонала.
Проблемы на рынке ИТ в Москве в нижнем звене (эникей).
Проблемы на рынке ИТ в Москве в среднем звене (продвинутый эникей – младший админ).
Проблемы на рынке ИТ в Москве в старшем звене (ведущие специалисты).
Проблемы на рынке ИТ в Москве в найме(HR).
Проблемы на рынке ИТ в Москве в руководящем звене.

Типовые проблемы админов
Админы и бухгалтерия.
Админы и сейлы / ПМ / РП.
Админы и попытка выйти на международный рынок.

Общеэкономическое

В. Путин на встрече с парламентской фракцией КПРФ заявил, что «доверие к Соединённым Штатам как к лидеру свободного мира и свободной экономики, доверие к Уолл-стрит как центру этого доверия подорвано, я считаю, навсегда. Возврата к прежней ситуации уже не будет

Рынок труда в РФ в целом.
Рынок труда в РФ в целом очень интересен. С одной стороны – РФ до сих пор умеет делать ракеты, котлеты, балеты, перекрывать Енисей, и даже гражданские самолеты вполне себе получаются (только дорогие очень, особенно в эксплуатации, даже в кредит по карте Мир). Микрон делает микросхемы на старом индейце с кладбища степперах AMD, это конечно не Rizen и не 1080, но для доставки мирнолетящих конусов, входящих в плотные слои атмосферы по баллистической траектории вроде хватает. Проверять не хочется.
С другой – средняя (медианную не публикуют) зарплата по РФ – 20-25 тысяч рублей, а рынок кадров на 2/3 (может и больше) представлен госструктурами, бюджетом, армией, полицией, налоговой и прочими вариантами ФГУП.
С третьей стороны – для РФ слишком часто проявляется клановость, кумовство, и назначение и продвижение детей кого надо и просто мальчиков из хорошей семьи на руководящие посты. Не то чтобы это хорошо или плохо, но приводит к сильному перекосу зарплат и перспектив в сторону «у простого парня перспектив не очень много». К этому я вернусь поздней.

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

1. В деревне Гадюкино не нужны админы с VCAP (The VMware Certified Advanced Professional) – там нет такой работы. В райцентре в 20 километрах от Гадюкино – ситуация та же. Разве что в сельсовете есть 1С и интернет. Вот если бы некоторые товарищи с VCAP бар открыли (там, или где теплее) – это было бы совсем другое дело. В районном центре тысяч на 50 населения ситуация схожа.

2. В областном центре тысяч аж на 300-500 населения ситуация получше. Правда, там чаще всего ИТ живет в очень ограниченном количестве мест – старом (или обновленном) заводе, порой двух. Местной администрации, и в местном представительстве Ростелекома плюс большой сотовой тройке (или уже двойке – МТС это уже Роснефть или еще нет?). В РЖД, внезапно. Может еще немного в местном нефте/газе/переработке, ГИБДД и полиции. Региональные филиалы банков, особенно зеленого. Подразделение ЦБ. Налоговая. Пенсионный фонд… слегка. Может франчайзи 1с и консультанта (и то еще вопрос – где там ИТ). Все. Остальной бизнес представлен разного рода купи-продай лавками, которые мало чем отличаются от сельсовета – разве что 1С будет не файловой, а SQL. В лучшем случае. Ну да, может быть будет какой-то домен в такой организации – чисто чтоб было. Мелкий бизнес – до 200 человек и до 3 подразделений по городу. Вплоть до какого-то макдака на аутсорсе.

3. Серьезное ИТ, средний и крупный бизнес — от, условно, 500 хостов/рабочих мест*. — в РФ фактически размещен:
– в европейской части – Москва, Санкт-Петербург, Нижний Новгород. Немного Казань и Ростов на Дону.
— В Сибири – Новосибирск, наверное, Екатеринбург (тот же Наг). Внезапно Пермь (особенно Пермские моторы и Авиадвигатель)
Остальные… да, что-то есть. Вопрос в том, что и сколько. И какого масштаба. Есть, конечно, и толковые разработчики и в Сибири – Денис Попов, Алексей Бабушкин.
Наслышан и о работе целого института чего-то водства(не в Сибири).

Прочие исключения конечно есть, но тем не менее — крупное ИТ находится в крупных городах.**

4. Конечно, есть отдельные области деятельности – это крупные магазины (ритейл), это современные АСУ ТП, которые как раз наоборот – массово существуют вне Москвы, но это немного другая специфика. Хотя стоны про отсутствие кадров в регионах в ритейле я слышу достаточно часто. Что не удивительно, как будет видно ниже.

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

** Какое открытие.

Вывод отсюда ровно один: хотите развиваться как ИТ-специалист (само собой с ростом зарплаты) – переезжайте в город покрупней. Не хотите переезжать и развиваться – см. известную статью «Я бы рад, но…»

— это лично ваш выбор. Учтите, что вы скоро (или уже) упретесь в потолок применимости технологий в регионе/городе – проще говоря, ООО Вектор не нужны динамические ИБП и Vxlan(RFC 7348)/ NVGRE (RFC 7637) или еще какой Vmware FT. Тяжелого межделмаша тоже не так чтобы есть, скорее нет (хотя может и быть — в том же авиа и двигателестроение, например АЛ-100 в Рыбинске).

Обратная сторона проблемы – кадровая. Основная масса кадров со знаниями и мотивацией к развитию – из регионов уезжает. На одной из прошлых работ на 6 человек в отделе у меня было 2 (двое) из Москвы. Остальные – Тамбов, Саратов, Ярославль, и кажется, Новосибирск. О соседних с Москвой областях – Тула, Рязань – я вообще молчу, оттуда по моему в Москву уехали все, кто хоть чуть-чуть хотел. Остаются кадры, скажем так, не очень заинтересованные. Конечно, опять же, есть исключения, до какого-то уровня можно расти и в регионе – например, местном телекоме. Есть и уже вернувшиеся, у кого в Москве почему-то не взлетело, а сил пробовать еще раз – нет.

Третья сторона проблемы, или ее ребро – это хакеры всех видов. Когда у тебя шансов на хорошее место и оклад нет в принципе, в армию и полицию не берут по конкурсу* или по здоровью, работать на единственном градообразующем предприятии за все те же 20-25 тысяч не хочется, и при этом есть не самое плохое образование (скорее самообразование) и доступ в интернет – то перспектива достаточно интересная. Многих ловят. Многих не сразу. Самых умных ловят и отправляют работать куда надо, что тоже неплохая перспектива для парня из глубинки.
Более того, злые языки распространяют слухи, что Fancy Bear – это вообще в/ч 26165/ИКС, сидящая в подмосковье, с отличным техническим оснащением, кадрами и прочая. Однозначно врут, но если бы так было – то тоже неплохая карьера для парней из глубинки.

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

*конкурс на поступление на отдельные факультеты и в отдельные вузы – та еще тема. Причем в рамках даже одного вуза, например города Э-Р-ска, на разные факультеты могут быть очень и очень разные условия. Официально, конечно, все равны, но злые мелкие языки клевещут и очерняют.
Часто перспектив действительно нет – или остатки колхоза «100 лет без урожая», или такой же завод, или армия. Причем в армии приходиться проситься на боевые, иначе там тоже не очень интересно в плане денег. Хотя там есть военная ипотека, и много чего еще. Сейчас. Еще недавно не было.
Примечание: конечно, зависит и от дополнительных выплат за все подряд, за дополнительные умения. В хорошем полку, даже без боевых, ЗП уровня сержанта (с октябрьского городка, ЕВПОЧЯ) – порядка 35-40 тысяч.

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

Рынок труда в ИТ в Москве за 10 лет – с докризиса 2007 до осени 2008 и сейчас.
Зарплаты в технической части.
Новые интересные подходы к найму на примерах.

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


На волне нефти за сто и даже двести за бочку – рынок и труда и ИТ рос с 2002 по 2008 год с огромной скоростью. Такого числа и качества облачных сервисов еще не было, аутсорс был непопулярен, поэтому ИТ-специалисты были нужны везде и много. Такого числа кадров просто не было, и зарплаты росли быстрей рынка. В Москве зарплаты росли еще быстрей, и кадры приезжали отовсюду. На лето-2007, при средней зарплате в регионе в 10 тысяч рублей – нижний уровень ставок (для ИТ и вообще) в Москве был 25 т.р., а средний в районе 50-70 т.р. При долларе 23-25 (на 01 августа 2008 г. курс доллара ЦБ РФ был 23.42) это было почти 2 тысячи – 120 т.р на текущий счет.

Потом случилась осень-2008.
Закрылось не все, но слишком многое. Нижний уровень почти не просел, эникеи были нужны, но верхний и средний уровни сжало вниз, с 70 до 35-40.

Начиная с 2011 – 2012 года рынок опять пошел вверх (казалось бы, причем тут нефть), но в 2014 году случилось что случилось, и рост зарплат (особенно с ноября-декабря 2014 и завоза доллара в магазин «все по сто») опять остановился.

Текущие кадровые проблемы в ИТ (в Москве) произрастают с нескольких сторон.
С одной стороны, денег в экономике стало гораздо меньше, чем в 2002-2008. Зато Крым наш.
С другой стороны, технологический порог входа резко снизился. Подешевело серверное оборудование, подешевело сетевое. Настройка сетевого оборудования упростилась, гигабитные (а то и 10G) сети и SSD диски стоят везде. Отлажена массовая установка ПО методом далее-далее. Поднять домен на 2016 сервере – задача (просто поднять) на полчаса, виртуальные машины на нем – еще час. И все будет работать. Причем даже в конфигурации Hyper-V на контроллере домена (и там же TMG).
Правда, потом технет и порой ЖЖ будут забиты стонами вида «я жал далее-далее, а оно не заработало».

Примеры (будут ниже еще раз, но пусть и тут будут)
Раз
Два
Три
Четыре
Пять
Шесть

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

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

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

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

Зарплаты в технической части.
Табличка 01
Рынок труда и рабочих мест в Москве на лето-2017 можно представить в виде таблички.


* Часто нужен intermediate уровень английского разговорного языка. Примерно 4.5-5 баллов по IELTS. Чем выше позиция – тем выше требуемый уровень, до upper.

** В июне 2017 года одна маленькая кампания в Крылатском искала Premium Support Engineer на зарплату «до 150 до вычета», что составляет 130 т.р. «на руки». Злые языки говорят, что вообще-то речь идет про 110-120.

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

Эникей (40R) — 100/180
Младший админ (60R) — 50/120
Системный администратор (90R) — 20/50
Ведущий/опытный системный администратор (110R+) — Вакансии в открытом виде практически не публикуются. Или без указания оклада, или долго ищут «из засады».
О причинах, как я их понимаю, тоже позже.

Реальное число вакансий примерно соответствует этим цифрам, но. Есть несколько но.
1. Часть вакансий просто не публикуется, например вакансии 100+. Или публикуется без указания заработной платы.
2. Часть вакансий – это все те же «хотим восьмирукого семиглазика и чтоб все умел». Восьмирукие семиглазики есть, и на такое место могут искать работника год. Просто потому, что таких людей (как работодатели хотят) или нет совсем, или не за такие деньги.
3. Часть вакансий просто задублирована. Видел вакансии, взятые HR методом copy-paste с оригинальной вакансии.

Что касается ранее помянутого – где AntonVirtual пишет:

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

— Тут ситуация чуть сложней.
Да, наверное, суммарно, за квартал, не закрытых не публичных вакансий по Москве на 100+ наберется сто штук. Вопрос в том, что на них часто требования на, условно, 150+, и вакансии не публичные.
150+ в том смысле, что с этой позиции человек на 150+ и ушел, а условные 100+ — это когда 3 года было 80, потом стало 110. Что там будет надо на таких местах – в самом конце.

Новые интересные подходы к найму на примерах.
Недавно вышла отличная статья – «Антипаттерны для поиска соискателей»

В дополнении к вот этой
Собеседование на junior позицию. Антипатерны собеседующих

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

попытка сказать что не все эйчары таковы — Вот эта , и вот эта , и еще вот эта
— не очень удалась. Ну да, не все. Но их есть.

Особо следует отметить свежее расхождение позиции HR во вопросам надо фото / не надо фото.
Вот тут есть мнение о причинах такого расхождения.

А вот тут есть хладная былина о том, на что может пойти HR для найма. Сдается мне, сие былина.

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

Однако, политика найма «в целом» определяется не ими, не они решают — кого искать, на какие требования и на какой оклад, здесь проявляется проблема именно руководящих кадров и экономической ситуации. Отсюда и растет все перечисленное и реально встречающееся вещи в вакансиях:
— Не указание зарплат. Или же указание до/от. Или указание гросс (до вычета НДФЛ). Или указание с учетом премии с максимально недоступным KPI. Или с годовой премией. Или как-то еще, что всплывает только после собеседования.
— Поиск одного специалиста с задачами на троих. Плюс с требованием 24/7/365.
И так далее по тексту и комментариям.

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

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

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

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

Из примеров отличной работы руководящих и не только кадров – всей связки. В том числе и HR
Кот с лампой.жпг
Дано: контора ООО ААА, новый тендер на саппорт.
Выигрывает некая вновь образованная фирма, которая провалилась на N миллионов рублей по сравнению с остальными.
ВНЕЗАПНО выясняется, что в тендер то они вписались, а вот людей — варьщиков и админов — нет совсем.
Сажают на обзвон каких-то граждан, которые дозваниваются до людей, которые раньше эти гайки крутили.
Предлагают «выйти прям щаз, детали потом»
Когда до деталей доходит начинается веселуха — потому что человеку, крутящему варю на 50 + хостов, цитриксоиду и вообще отличному парню предлагают — 35к. Рублей. В месяц. В Москве. В 2016 году.

Кадровое.
Проблемы на рынке ИТ в Москве в целом, качество персонала.
Проблемы на рынке ИТ в Москве в нижнем звене (эникей).
Проблемы на рынке ИТ в Москве в среднем звене (продвинутый эникей – младший админ).
Проблемы на рынке ИТ в Москве в старшем звене (ведущие специалисты).
Проблемы на рынке ИТ в Москве в найме(HR).
Проблемы на рынке ИТ в Москве в руководящем звене.

Для начала надо определиться с терминами.
Эникей.
Ничего не умеет сам, кроме работы, требующей минимум знаний по ИТ. Это протяжка кабеля по месту, прозвон кабеля, умение набрать ipconfig и продиктовать цифры по телефону. Плюс умение читать инструкцию по стандартным ситуациям / STC и действовать по ней.
Картриджи, застрявшая бумага, подключение к Wifi, настройка почты – примерно такой уровень.
Винду тоже может переставить, и даже настроить роутер с вайфай.
Но при этом эникей не понимает, почему права на общедоступные папки отличаются, и при чем тут NTFS.
Пример 01.

Бывает хуже – когда такому сотруднику доверяют главный руль.


Тогда бывает так, Или вот так

Младший админ / продвинутый эникей.
Кроме перечисленного — немножко умеет создавать юзеров в AD, немножко умеет (ICND1) сети, очень немножко Exchange 2007/2010/2013 (например, коннекторы не умеет). Может даже слышал про архивацию, и может даже запускал powershell. Два раза. И поставил дома Ubuntu.

Ведущий системный администратор.
Такое длинное название должности, ИМХО, растет из СССР с системой специалист\ведущий специалист \ еще кто-то там. По факту тут может быть что и кто угодно, но в данном случае это пока еще универсальный специалист, который одинаково плохо умеет сети (ICND2), где-то в середине трека MCSA: Windows Server 2012 (– 70-410/70-411/70-412), или трека MCSA: Windows Server 2016 2016 – 70-740/70-741/70-742.VCP бонусом.
Ключевым моментом здесь становится наличие реально сданных экзаменов через Person VUE. Бонусом идет знание FC (говорим FC — подразумеваем Brocade, хотя оно есть и у Cisco — Cisco MDS 9148 Multilayer Fabric Switch, и у QLogic — SB3810-08A, SB5800V-08A, однако начинать се равно надо с FC 101-WBT Introduction to Fibre Channel Concepts — Zoning, вот это все.). Россыпью — Juniper, HPE, Kaspersky, Veeam VMCE — Veeam Certified Engineer, и прочая прочая. Порой еще телефония – Asterisk, и еще всякое по мелочи на 3 группу электробезопасности, о чем я поминал тут Действия при приходе на работу — прием дел, актуализация, документирование, аудит и вот тут — Инженерные системы малого офиса и вопросы к ним для само (и не само) проверки
После этого уровня «знания всего по чуть чуть» начинается уже большое взрослое ИТ.
Главное не путать специалиста со специалистом уровня «только MVP и еще немного психолог».*

* Если вы знаете о чем эта шутка, конечно.

В последнее время появилась три отдельные области.
Первая — Configuration as code. Если кто не знает, это там где Terraform, Consul, Serf, Vault, Vagrant / Otto. Или же там, где Kubernetes, Docker Swarm, OpenShift. И еще местами страшный синий кит с осьминогом.


Вторая — там где TOGAF, CISSP-ISSAP, SABSA и прочие страшные слова.

Третья – где слова еще страшней, SDN/SDS, Vxlan / nvgre/ stt / и даже network namespaces/ Windows Container Networking. Там в обоих случаях свой собственный мир. Интересный, но свой.

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

Ситуация: вменяемых эникеев полно, они работают и развиваются до младших админов (если, конечно, не майнят, ЕВПОЧЯ), но есть и проблемные кадры. Хорошо, если человеку такая работа интересна (по своим причинам), плохо если она ему еще и не интересна, если он хочет получать, а не зарабатывать*.
Часто наличие таких кадров, черных овец, служит скорее симптомом другой болезни, с руководящими кадрами.

*Прямая цитата из речи одного кандидата.

Проблемы на рынке ИТ в Москве в среднем звене (продвинутый эникей – младший админ).
Внезапно, но проблем с кадрами в этом звене я не видел. Возможно потому, что это переходный уровень, когда человек еще развивается, но еще не успел набрать самомнения как специалист по установке винды и сборке ПК из запчастей с рынка.
Вот разве что страха перед факапом у них нет, как и опыта подстилания соломки везде. Вообще, совсем везде. Например, опыта планировать наилучший, обычный, и наихудший исходы. Или полезной практики проверять идеи модернизации в лабораторной сети и на лабораторном оборудовании.
Интересно, но факт. Сейчас стенд для лаборатории под Vmware можно собрать за 40 (сорок) тысяч рублей, считал конфигурацию в июне. Но слишком многим это дорого, даже в Москве.
Есть еще одна сложность, для кадров (HR) и руководства – как не перепутать младшего системного администратора с эникеем и их обоих с MVP/психологом. Разные волшебные слова знают все, вот только подход к ИТ у них разный. Маркер разделения — модели поведения. Поискать-и-почитать против сразу-спросить-решение-не-читая.

Проблемы на рынке ИТ в Москве в старшем звене (ведущие специалисты).
По моему мнению, это самый проблемный контингент из всех, особенно для HR*. Дело в том, что их сравнительно немного, они это знают и вообще не нервничают по поводу работы и возможного увольнения. Зато нервничать приходится их руководителям – если, конечно, в организации все хорошо с руководителями ИТ отделов и ИТ-директорами, а это как раз совсем не так.
Некоторые же несознательные личности из таких вообще вот так берут, и угоняют трактора. Как вообще таким людям можно доверять, где те старые кадры, что поют песни про заводскую проходную, что в люди вывела…?
Отдельно можно писать истории, как условного архитектора пыталась прожать девочка из HR. Типа «вы плохо сдали психологический тест».

*Исключение – если специалист женат на HR. Слышал я несколько публично озвученных офигенных историй такого плана.

Интересный факт. Почему администратор по тексту почти всегда «он». Соотношение м/ж в сфере СА – примерно 50/1. За все время работ я видал всего пяток девушек в администрировании. В 1с, в программировании, техподдержке по телефону, управлению монтажниками и не только – гораздо больше. При этом уровень второй линии поддержки местами ничуть не уступает квалификации младших (а то и средних) админов, но ситуация именно такова. Не знаю почему так, может потому что микролифт (для серверов) в РФ еще поискать, а сервера в стойки все же ставить надо, иногда? Не секрет, что женщины в среднем уступают по физподготовке, но есть ли тут связь?
Кто сомневается в состоянии физподготовки –
«А это смотря какая бабель» — часть I
«А это смотря какая бабель» — часть II

Проблемы на рынке ИТ в Москве в найме(HR).
Первая проблема кадров и кадровых агентств, с которой я столкнулся – это самомнение сотрудников HR. Властелины судеб, с шаблонными тестами и ожиданием шаблонных ответов. Как вы видите себя в нашей кампании через пять лет. Назовите три свои три хороших качества. Что вы знаете про наш ООО Вектор, его долю на рынке, миссию и корпоративные ценности?
Работать в нашем банке – большая честь, вот это все.

О майн готт, о чем вы вообще? У вас там что, все на ARM и Росе? Эльбрусы сверху? Коммутаторы собственной разработки на своей ОС? Арвиды? Особо прекрасные условия? Не возьмете к себе, возьмут в следующую по собеседованию организацию. Любопытно, что есть некоторая зависимость (не линейная) – чем ближе контора к уровню DNIWE, тем более пафосные там HR. Самая пафосная сотрудница, которую я видел за десяток лет, была в каком-то стартапе, 20-с-чем-то лет, и не знала ничего о самой работе.
Самое интересное, о котором я читал – саентологическое(!) кадровое агентство. Сайт кадрового агентства набит отменным буллшитом всех видов, и не содержал никакой конкретики.

Вторая проблема – работа на процесс, а не на результат. В том смысле, что работают, как будто договор составлен на поиск 10 любых сотрудников, а не 1 нужного. Как следствие, начинаются качели вида «вы сначала придите к нам поговорить, а потом мы вам, если вы понравитесь, скажем и про деньги, и про работу. Хотя бы название фирмы». Иногда, конечно, интересно сходить, и иногда может повезти. А иногда окажется, что все, что написано в опубликованной вакансии – вранье.

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

Проблемы на рынке ИТ в Москве в руководящем звене.
Проблемы есть, причем очень разные проблемы.
Писать про «все хорошо» — не интересно. Про АА ВСЕ ПЛОХО — куда веселей.

Проблема 1. Старые / опытные / проверенные кадры.
Проблема 2. Дети хороших родителей – мальчики из хорошей семьи, и прочие приведённые за ручку.
Проблема 3. Я начальник, а вы все дураки, всегда так делали и вообще вы зажрались, с сегодня все будет по моему.
Проблема 4. Бизнес-требования.

Проблема 1. Старые / опытные / проверенные кадры.
Упрощая, это то что раньше называлось «номенклатура». Хотя почему раньше? Ситуация не настолько изменилась. Это уже немолодые (50+), видевшие жизнь сотрудники, которые могут работать хоть директором по ИТ, хоть заместителем по кадрам, хоть начальником транспортного цеха. Вообще работать с такими кадрами не так плохо, но нужно грамотно выбирать подход. Зачастую подход бюрократизирован, но иногда это не так уж и плохо – научишься считать бюджет и обосновывать свои хотелки, заодно понимать пользу от каких-то покупок для самого бизнеса.
Нормальный подтип таких начальников — Мне все равно, чем вы занимаетесь, я тут самолетики клею, и мне доработать осталось 3 года, так что ничего не сломайте.

Проблема 2. Дети хороших родителей – мальчики из хорошей семьи, и прочие приведённые за ручку.
Второй по уровню «плохости» вариант (первый — ниже). Эта проблема, но пока что (хотя где как) не в руководящем звене – скорее этого мальчика (или девочку) приведут в отдел и скажут «вот сын хорошего человека, посмотрите какой у него уровень побед!». Ну да. Топовые танки, не вопрос. Только вот не умеет ничего, и работать не хочет. Получать – не возражает.
Самый удобный вариант – отказаться от такого кадра. Если отказаться не вышло, то научить и принудить обслуживать кофемашину, а для опытов (если уж ему неймется) – выделить отдельный ПК, или даже сервер (в отдельном влане, само собой. С порезанным каналом в инет).
Исключения бывают, но крайне, крайне редко.
Вот когда такому кадру сходу доверяют руководство проектом – вот тогда начинается DNIWE.
Шансы завалить с попыткой спихнуть ответственность – 146 %.

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

Мартышка полощет очистки банана в реке. Плывёт крокодил:
— Мартышка, чего это ты делаешь?
— Дай рубль — скажу.
Крокодил дал ей рубль.
— Ну, говори.
-Очистки от банана полощу, не видишь, что ли?
— Ну и дура!
— Дура дурой, а свой тридцатник в день имею!


Несколько раз начинал этот фрагмент и стирал – все время получалась фигня. Ну да, бывают что начальники в жизни не очень хорошие люди. Но если вы такой умный (а они такие нутупые) — If you're so smart, why aren't you rich?
Но вопрос то не совсем про это (хотя и про это тоже).
Вопрос в том, что являются ли они плохими (но надежными. Или ненадежными, но нужными) руководителями с точки зрения руководства. Или же поставленные (генеральным директором) задачи «общего плана» выполняются по приемлемой цене (совокупная стоимость кадров — ФЗП, плюс стоимость владения) и в приемлемый срок, и проблемы именно у вас, с не пониманием реальных методов и задач руководства.
Понятно, что руководство всегда решает свои личные задачи (а сотрудники — свои), и задачи руководства, в том числе и прикрыть зад, имеют место быть.
Внезапно, но хорошо/плохо — это ваше личное мнение, которое (судя по тому, что данный руководитель еще тут, а вы уже заявление написали) не соотносится с мнением генерального.
В том смысле, что например конторе дешевле (совокупно) нанять 4 студентов по 40 тысяч, чтоб бегали по людям, и одного админа на полставки, чем одного нормального админа 8*5 и трех студентов. Потому что задачи бизнеса не требуют постоянного админа и сложных схем, например. Или по еще ряду причин.

Однако плохое руководство — проблема, встречаемая слишком часто. Не важно, почему так сложилось, реальное решение одно – заявление по собственному желанию на стол. Хотя можно пожевать соплей и попробовать убедить себя, что время сложное, учиться поздно, другой работы нет, все такое. Мне то проще – я знаю про руководителя, у которого в кабинете висел диплом на право управления Як-52.
Получил он его в 65 лет – это немного поздновато для учебы, да?

Типовые маркеры такого проблемного руководителя:
  • — Зачем нам еще инженеров, эти недозагружены!
  • — Это не наша зона ответственности
  • — На совещании я поднял вопрос о .., и меня заверили в…
  • — Миша слегка обнаглел, давайте его уволим и за половину его зп возьмем студента. Оптимизация расходов. Я себе премию выпишу
  • — Будем делать вот так! (робкие голоса из зала – но ведь упадет же)
  • — Один за всех, и все за одного! Премию за всех получу я, а при моем факапе получите все.
  • — Когда я работал в нефтегазмяссервисе 10 лет назад, у нас и то было лучше сделано!
  • — Вы все не эксперты, вот я-то работал в газмясе, там у меня такие орлы были, эээх! А вы — слёзы. Пойду, отдам всю работу на аутсорс, с вами, дураками, разве кашу сваришь.
  • — Соберем совещание и обсудим, а я приму мудрое решение.
  • — Сделайте завтра и хорошо!
  • — любовь к пустым мотивационным речам (мыкаманда), сочетаемая с такими же пустыми угрозами (выменяподвели, всехуволю). Иногда с обещанием премии, процентов и прочих КПИ-коэффициентов. Вот только 50% от 0 – ноль.
  • -нам нужен ребенок через месяц, так что женщин будет девять.
  • -да у меня племянник друга такое делал за месяц
  • -я точно знаю что так можно.
  • -я с этого начинал, там всё просто


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

Проблема 4. Бизнес-требования.
Она же — Админы и руководство.
Тут проще всего сослаться на хорошую книгу — Терри Уайт. Чего бизнес на самом деле хочет от ИТ., или на хорошую статью — Менеджмент vs Cисадмин. Ссылок не будет, гуглите сами.

Типовые проблемы админов.
Админы и бухгалтерия.
Админы и сейлы / ПМ / РП.
Админы и пользователи.
Админы и международный рынок.

Админы и бухгалтерия
Бухгалтерия не любит признавать себя источником проблемы, в классическом виде «я ничего не нажимала».
Решение: software restriction policies + выделенный VLAN + PVLAN + прочие сегментирования и ограничения. Чтобы с машин бухгалтерии (и особенно банк-клиентов) не работало ничего, кроме КЛАДР, 1с и еще пары сайтов. Нужен интернет и прочие радости – отдельный ПК, чтобы занимало поменьше места – KVM.
Бухгалтерия не очень любит списывать всякую старую мелочь. Раньше (кажется до 2015 года) были еще всякие ограничения по малоценке и списанию кабелей и расходников, сейчас проще.
Только надо этим заниматься. Админу. Чтобы на нем не висело 100 тонн кабелей.

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

Админы и сейлы / ПМ / РП.
История из жизни.
Прибегает ПМчик, и говорит: «Дорогой друг! есть контора А, вот надо нам короче так посчитать им бюджет на аутсорс наш, чтобы было красиво. Сейчас они тратят на своих гопников Н десятков мульенов». Задаю вопрос — а что у них есть, мониторинг, заявки, сд, инвентаризация. Нет, отвечают радостно и ссутся в штаны, ничего у них нет, они голодранцы! Это у нас все есть, мы их за руку приведем к светлому будущему!!! Нам главное- на бумажке сделать магию цифр и показать, что они СЭКОНОМЯТ если возьмут нас. Мол, выгоду им показать надо, понимаешь? И приходится этому дебилу объяснять очевидное. Что мониторинг — это отдел людей. Что заявки, сд, инвентаризация — это еще больший отдел. Что все в месте это мешок денег в сервисе получается. И внезапно открываются бездны и свой уютный ит отдельчик (в котором даже нет ничего ослепительного) — дешевый, кондовый, и родной. Но это все фигня


Потому что кто надо кому надо уже все перетер и брать мы их будем все равно.

Админы и пользователи.
По моей личной оценке — проблемных именно пользователей примерно 5/1000. В остальных случаях надо пробовать лезть глубже в фактическую проблему. Простой пример: пользователь жаловался на медленный 1с. Внезапно оказалось, что проблема и в сетевой карте (точнее проводах — сеть встала на 10 M), и в обработке 1с сложных правил кому-чего-куда-почему.
Главное не пускать к такому пользователю специалиста-эникея, и тем более не выдавать эникею ничего стеклянного — мало того что разобьет…

Админы и попытка выйти на международный рынок.
Ничего лучше статьи Особенности национального рекрутинга/найма я не видел. Читайте, думайте. Заодно можете обновить профиль хотя бы на Linkedin. Не можете? Тогда о каком выходе на международный уровень можно говорить?

Вот вроде и все, хотя и спутано-перепутано.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334442/


Метки:  

Magento Dare to Share — Открытая Площадка для докладов о Magento, PHP и eCommerce

Понедельник, 31 Июля 2017 г. 07:56 + в цитатник


20 Июля в Киевском офисе Magento прошло открытое мероприятие под названием Magento meetup «Dare to Share», которое могли посетить и в котором могли принять участие любые желающие кому интересна платформа Magento 2 и тема электронной коммерции (eCommerce).

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

  1. Игорь Миняйло, Magento (@iminyaylo on ) — Magento Community Engineering
  2. Макс Пронько, The Irish Store (@max_pronko on ) — Автоматизация релизов для Magento 2. Опыт компании The Irish Store
  3. Вячеслав Кравчук, Atwix (@slkra on ) — Story of a Transformation (Укр.)
  4. Андрей Кравец, Gymgrossisten (@Winfle on ) — Dynamic caching of personalised data in Real Life (Укр.)
  5. Александр Козырь, Magecom (@kozyr1av on ) — SOLID-ное программирование на Magento 2

Тезисы докладов можно прочитать под Катом


Тезисы Докладов



Magento Community Engineering


Magento Open Source — не просто ребрендинг CE, а новый подход в работе с сообществом.
Как Magento помогает сообществу, и чем она может помочь Вам.
Как Вы можете помочь Magento, и что вам за это будет.
Первые шаги. С чего начать.

Автоматизация релизов для Magento 2. Опыт компании The Irish Store


Реализация техники Blue-Green deployment для проектов на платформе Magento 2, чтобы уменьшить риски даунтайма и сократить время релиза с 6 часов до 15 минут.

Story of a Transformation


Доклад посвящен изменениям бизнес процессов в IT компании. О том как происходит трансформация от одной бизнес модели к другой. Как это влияет на саму компанию и на людей в ней. Социальная составляющая изменений и потребности меняться.
История компании Atwix, которая работала централизовано и перешла к модели распределенной разработки, и как это на нее повлияло.

Dynamic caching of personalized data in Real Life


На сколько важна персоналиация eCommerce.
Кеширование с помощью динамических блоков с помощью ESI (Varnish и Akamai),
которые вычисляются для каждого отдельного клиента системой поиска и рекомендаций.

SOLID-ное программирование на Magento 2


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

Заявки на участие


Если вы хотите выступить на будущих ивентах посвященных Magento или eCommerce, пообщаться с представителями Magento сообщества, обсудить ваши проблемы и истории успеха, поделиться опытом и задать вопросы core-разработчикам — отправляйте заявки на имейл Community Engineering <engcom@magento.com>
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334390/


Метки:  

Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 1072 1071 [1070] 1069 1068 ..
.. 1 Календарь