суббота, 25 марта 2017 г.

пятница, 24 марта 2017 г.

Security Week 12: опасная фича в Windows, китайские хакеры сломали все вокруг, инспектировать HTTPS надо с умом

Интервью с разработчиком из Dropbox Леонидом Васильевым о работе и жизни в Ирландии

Site Reliability Engineer в Dropbox Леонид Васильев четыре года живёт и работает в Ирландии. Леонид рассказал, как переехал в Ирландию, почему перешёл из Amazon в Dropbox, как устроен их офис в Дублине, и каким он видит будущее DevOps.

До переезда Леонид отучился на мат-мехе УрГУ и пять лет проработал в Яндексе

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

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

— Чем отличается жизнь и работа разработчика в России и в Ирландии?

Главное отличие, которое меня удивило, — это то, что в Ирландии не принято перерабатывать. Все следят за балансом между личной жизнью и работой. Отпуск в Ирландии 25 дней, при этом выходные не учитываются, поэтому, если взять две полные недели отпуска, в счёт пойдут только 10 дней. Работают тут в основном на американские компании. Практически не видел тут маленьких веб-студий, интеграторов IT-решений и маленьких интернет-провайдеров.

— Значит ли это, что ирландские компании умеют более эффективно организовать рабочий процесс?

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

— Сталкивался ли ты с чем-то неожиданным/непривычным в плане организации работы, быта, менталитета? Как долго привыкал к местной жизни? Можно ли в Дублине найти гречку со сметаной или надо менять пищевые привычки?

Долго привыкал к тому, что пить воду из-под крана — это нормально :)

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

Дублин — небольшой и довольно уютный город, так что привык довольно быстро. В Ирландии много людей из Восточной Европы — Польша, Латвия, Литва и т.д. В Дублине есть сеть польских магазинов, где есть много сортов гречки и отличная сметана «Ромашка». Также там можно купить селедку и соленые огурцы.

— Как в Ирландии принято проводить свободное время?

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

Еще из Ирландии очень доступно путешествовать в Европу: местным лоукостером RyanAir (который базируется в Дублинском аэропорту) за 10 евро можно слетать в Лондон, а за 50 — в Португалию.

— Есть ли корпоративы, как они проходят? Отличаются ли от привычных в России?

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

В году обычно два больших корпоратива: в декабре перед Рождеством и летом (Summer Party). На Рождество обычно снимают какое-нибудь большое помещение (например, музей или ресторан), а летом все проходит в парке или на поле для регби. Dropbox также устраивает корпоративы в офисе на Halloween и St. Patrick’s Day.

— Возможно ли российскому разработчику устроиться в ирландскую компанию? Можешь дать какие-то советы?

Ирландских IT-компаний довольно мало, в основном тут филиалы компаний из Америки. Формат собеседований стандартный среди всех компаний. Приехать работать в Ирландию относительно легко, нет квот на рабочие визы (как, например, на H1B в США), не надо сдавать экзамен по английскому (как IELTS при получении рабочей визы в Великобританию). Чаще всего сюда привозят уже людей с опытом, которые могут работать в компании независимо и не требуют постоянного внимания от менеджера. Если в 2012 году сотрудников перевозили только большие и известные компании, сейчас это делают практически все.

— Расскажи об этом подробнее. Какие надо собирать документы и какие есть подводные камни? Как помогают работодатели с переездом? Если не секрет, какой релокационный пакет предложил тебе Amazon?

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

Весь процесс курирует работодатель, от меня требовалось только прислать документы (паспорт, подтверждение прошлых работ по специальности, перевод диплома) и подписать контракт на работу.

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

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

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

Айтишникам чаще всего оформляют разрешение на работу, которое называется Critical Skills Permit — по нему можно переехать сразу со всей семьей. Право на работу получает только тот, кому сделали оффер, остальные члены семьи могут просто жить в Ирландии, учиться или заниматься неоплачиваемым волонтёрством.

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

— Почему ты перешёл из Amazon в Dropbox?

В Amazon было интересно работать первые два года, после этого задачи стали довольно однообразными. Я хотел перейти из компании с тысячами разработчиков в компанию с сотнями. Изначально я заинтересовался Dropbox после того, как съездил на конференцию EuroPycon 2012, где узнал, что туда из Google перешел Guido van Rossum (создатель Python). Когда я решил перейти из Amazon в компанию меньшего размера, со мной связался бывший коллега из Яндекса и предложил пособеседоваться на позицию Site Reliability Engineer.

— Чем ты занимаешься в Dropbox?

Занимаюсь низкоуровневой инфраструктурой, автоматизацией и инструментами для наших дата-центров и AWS cloud. Также системами деплоя кода, конфигурацией кластеров и т.д. Иногда появляются задачи, которые нужно «протащить» по всему стеку Dropbox, от конфигурации ОС до клиента под MacOS.

— Расскажи, как в Dropbox все устроено? Как организована твоя работа? Ты ходишь в офис?

Dropbox довольно молодая компания, только недавно вышедшая из фазы стартапа, поэтому атмосфера в компании довольно неформальная. Я работаю в Дублинском офисе. В нём работает примерно 250 человек, разработчиков около 10. В компании довольно много ex-Яндекс. В моей команде всего 10 человек. Все, кроме меня, находятся в Нью-Йорке. Я работаю по Дублинскому времени, которое совпадает с UTC большую часть года :)

Я хожу в офис к завтраку, к 8-10 утра, большую часть работы над проектами делаю утром. Во второй половине дня обычно общаюсь с коллегами из Нью-Йорка и Сан-Франциско, обсуждаю задачи и планы. Раз в три недели я on-call, это значит, что в случае, если сервисы Дропбокса неисправны, мне приходит «page» (смс или звонок).

— Что является лучшей и худшей частью твоей работы?

Наверное, лучшей — это отсутствие тяжелых формальных процессов и открытость компании.
Также очень нравится программа, которую Dropbox проводит 2 раза в год — Hack Week. Во время Hack Week, который длится неделю, любой разработчик может работать над тем проектом, над которым хочет. Это может быть личный проект или относящийся к работе, иногда люди собираются в команды и делают что-то вместе. На прошлом Hack Week я экспериментировал с различными клиентами BitTorrent и форматом сжатия данных VCDIFF.

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

— Ты фактически занимаешься работой на стыке dev и ops с 2008 года, начал ещё до основного хайпа. Как ты думаешь, что глобально поменялось за эти десять лет?

Основные изменения — это, конечно же, освоение облачной инфраструктуры, переход от систем управления конфигурацией (CFengine, Puppet, Chef, etc.) в сторону контейнеров (LXC, Docker). Также SSD и NoSQL сильно изменили подход к обработке и хранению данных.

— Что первично — инфраструктурные инструменты или правильные практики? Бывает ли devops без фреймворков для оркестрации и подобных вещей?

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

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

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

— Куда вся эта движуха должна нас привести? Пофантазируй на тему «будни SRE через пять лет» :)

Количество различных сервисов будет расти по экспоненте, инфраструктура будет все более локальной, чтобы быть как можно ближе к пользователю. Все больше сервисов будут вынуждены поддерживать кластеры в разных странах и регионах из-за требования правительств. REST-API перестанет использоваться. Эпоха открытого веба подходит к концу. Контент будет храниться в различных сервисах зашифрованный и доступный только проверенным пользователям. Переход на IPv6 и HTTP/2.0 ускорится.

— Какие инструменты ты используешь для организации работы (в том числе для планирования времени, организации рабочего пространства и т.п.)?

В последнее время «Dropbox Paper» для планирования, часто записываю в блокнот на столе какие-то задачи или идеи, которые приходят в голову. Общаюсь в Slack и Google Hangouts. В основном я работаю в терминале на macbook’e, использую Vim около 10 лет. На личном ноутбуке использую OpenBSD и WindowMaker. Также использую Kinesis Advantage Keyboard и Contour RollerMouse.

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

Регулярно только «Hacker News». Слежу за программами нескольких конференций ACM и IEEE. Есть подписка на O’Reilly Safari Books. Я стараюсь изучать какую-то одну интересную мне тему, чем следить за всеми трендами в инфраструктуре.

— Удается ли тебе соблюдать work&life balance? Если да, то как, если нет, то надо ли оно тебе вообще?

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

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

— Расскажи про обучение в ирландской магистратуре. Как отличается процесс обучения? Почему выбрал именно эту программу?

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

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

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

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

14 апреля Леонид выступит на конференции DUMP в Екатеринбурге. Расскажет, как с точки зрения SRE в Dropbox реализована основа стабильной инфраструктуры, какие технологии используются в Dropbox, и с какими сложностями он сталкивается.

Спасибо нашим спонсорам, которые делают конференцию возможной: Генеральному спонсору — компании E-Soft, партнёрам конференции — СКБ Контур, Naumen, Сбербанк-Технологии.

Фотографии Дублина: Маша Васильева

Комментарии (0)

Let's block ads! (Why?)

[Перевод] В чем отличие UI и UX? Подробный разбор часто используемых терминов

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

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

UI ! = UX

Наиболее распространенное заблуждение, с которым вы скорее всего столкнетесь на рабочем месте, встрече с заказчиком либо в списке вакансий и требований, это непреднамеренная комбинация или взаимозаменяемость данных терминов. Во многих случаях, ошибкой является ожидание, что дизайнер интерфейса по умолчанию понимает либо фокусируется на UX, лишь только потому, что его работа напрямую связана с пользователями. Факт в том, что пользовательский интерфейс (UI) не является опытом взаимодействия (UX). Возможно, путаница возникает из-за буквы «U» в обеих аббревиатурах. Более вероятно, это происходит из-за совпадения набора навыков, требующихся для обеих дисциплин. Они безусловно связаны между собой, и, на самом деле, многие дизайнеры хорошо осведомлены и компетентны в обоих.

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

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

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

UI это инструмент

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

Неправильное использование это риск

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

Поиск подходящего дизайнера

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

Ответственность за проблему

UI или UX, это всегда дизайн. Дизайн — это решение проблемы. Когда роли четко определены и понятны всем и каждому, гораздо проще атаковать проблему, предложить решение и воплотить его. В случае с UI и UX, проблема как правило возникает, когда ответственность за оба аспекта ложится на плечи одного человека, который просто не сможет контролировать и то и другое.

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

Было бы довольно странно взвалить ответственность за все это на UI разработчика. Тоже самое касается и UX. Чтобы разработчик по праву взял на себя ответственность за проблему UX, он должен иметь возможность рекомендовать и вносить изменения, реализовывать решения проблемы и контролировать процесс. Понимание процесса зависит от возможностей и сосредоточенности дизайнера. Дело не в том, что одному дизайнеру не по силам справится с обеими областями. Речь идет об инструментах и способности решать задачи. Фактически, строитель не имея никаких материалов и инструментов — не сможет строить, как и человек без определенных навыков и знаний.

Вывод

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

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

Перевод статьи подготовлен по инициативе команды Pixli.

Комментарии (0)

Let's block ads! (Why?)

Дефекты безопасности, которые устранила команда PVS-Studio на этой неделе: выпуск N3

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

Для тех, кто ещё не знаком с инструментом PVS-Studio

PVS-Studio — это инструмент, который выявляет в коде многие разновидности ошибок и уязвимостей. PVS-Studio выполняет статический анализ кода и рекомендует программисту обратить внимание на участки программы, в которых с большой вероятностью содержатся ошибки. Наилучший эффект достигается тогда, когда статический анализ выполняется регулярно. Идеологически предупреждения анализатора подобны предупреждениям компилятора. Но в отличии от компиляторов, PVS-Studio выполняет более глубокий и разносторонний анализ кода. Это позволяет ему находить ошибки в том числе и в компиляторах: GCC; LLVM 1, 2, 3; Roslyn.

Поддерживается анализ кода на языках C, C++ и C#. Анализатор работает под управлением Windows и Linux. В Windows анализатор может интегрироваться как плагин в Visual Studio.

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

Подробная презентация на сайте SlideShare. В формате видео она доступна на YouTube (47 минут).
Статьи о проверенных открытых проектах.
PVS-Studio: поиск дефектов безопасности.

Потенциальные уязвимости (weaknesses)

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

1. MSBuild. CWE-476 (NULL Pointer Dereference)

V3095 The 'searchLocation' object was used before it was verified against null. Check lines: 170, 178. Microsoft.Build.Tasks Resolver.cs 170
V3095 The 'searchLocation' object was used before it was verified against null. Check lines: 249, 264. Microsoft.Build.Tasks Resolver.cs 249
V3095 The 'assemblyName' object was used before it was verified against null. Check lines: 176, 194. Microsoft.Build.Tasks Resolver.cs 176

protected bool FileMatchesAssemblyName
(
  AssemblyNameExtension assemblyName,
  ....
  ResolutionSearchLocation searchLocation
)
{
  searchLocation.FileNameAttempted =  // <=
    pathToCandidateAssembly;
  ....
  if (String.Compare(assemblyName.Name, ....) != 0)  // <=
  {
    ....
  }
  ....
  if (searchLocation != null)
  {
    ....
  }
  ....
  bool isSimpleAssemblyName = assemblyName == null ? 
    false : assemblyName.IsSimpleName;
  ....
  searchLocation.Reason =  // <=
    NoMatchReason.ProcessorArchitectureDoesNotMatch;
  ....
  if (searchLocation != null)
  {
    ....
  }
  ....
}

Report: http://ift.tt/2mYvHsZ

2. MSBuild. CWE-476 (NULL Pointer Dereference)

V3095 The 'e' object was used before it was verified against null. Check lines: 165, 170. MSBuild InitializationException.cs 165

internal static void Throw(string messageResourceName,
  string invalidSwitch, Exception e, bool showStackTrace)
{
  ....
  if (showStackTrace)
  {
    errorMessage += Environment.NewLine + e.ToString();  // <=
  }
  else
  {
    errorMessage = ResourceUtilities.FormatString(errorMessage, 
      ((e == null) ? String.Empty : e.Message));
  }
  ....
}

Report: http://ift.tt/2mYvHsZ

3. Entity Framework. CWE-670 (Always-Incorrect Control Flow Implementation)

V3014 It is likely that a wrong variable is being incremented inside the 'for' operator. Consider reviewing 'i'. EFCore ExpressionEqualityComparer.cs 214

V3015 It is likely that a wrong variable is being compared inside the 'for' operator. Consider reviewing 'i' EFCore ExpressionEqualityComparer.cs 214

var memberInitExpression = (MemberInitExpression)obj;
....
for (var i = 0; i < memberInitExpression.Bindings.Count; i++)
{
  var memberBinding = memberInitExpression.Bindings[i];
  .... 
  switch (memberBinding.BindingType)
  {
    case ....
    case MemberBindingType.ListBinding:
      var memberListBinding = (MemberListBinding)memberBinding;
      for(var j=0; 
              i < memberListBinding.Initializers.Count;    // <=
              i++)                                         // <=
      {
        hashCode += (hashCode * 397) ^
        GetHashCode(memberListBinding.Initializers[j].Arguments);
      }
      break;
    ....
   }
}

Report: http://ift.tt/2mThCNi

4. Entity Framework. CWE-670 (Always-Incorrect Control Flow Implementation)

V3081 The 'j' counter is not used inside a nested loop. Consider inspecting usage of 'i' counter. EFCore.Specification.Tests ComplexNavigationsQueryTestBase.cs 2393

for (var i = 0; i < result.Count; i++)
{
  var expectedElement = expected
    .Single(e => e.Name == result[i].Name);
    
  var expectedInnerNames = expectedElement
    .OneToMany_Optional.Select(e => e.Name)
    .ToList();
    
  for (var j = 0; j < expectedInnerNames.Count; j++)    // <=
  {
    Assert.True
    (
      result[i]
      .OneToMany_Optional.Select(e => e.Name)
      .Contains(expectedInnerNames[i])                  // <=
    );
  }
}

Report: http://ift.tt/2mThCNi

5. CoreCLR. CWE-188 (Reliance on Data/Memory Layout)

V557 Array overrun is possible. The value of 'dwCode — 1' index could reach 8. cordbdi rsmain.cpp 67

const char * GetDebugCodeName(DWORD dwCode)
{
  if (dwCode < 1 || dwCode > 9)
  {
    return "!Invalid Debug Event Code!";
  }

  static const char * const szNames[] = {
    "(1) EXCEPTION_DEBUG_EVENT",
    "(2) CREATE_THREAD_DEBUG_EVENT",
    ....
    "(8) OUTPUT_DEBUG_STRING_EVENT"         // <=
    "(9) RIP_EVENT",
  };

  return szNames[dwCode - 1];
}

Report: http://ift.tt/2nLRskb

6. FreeBSD. CWE-561 (Unreachable code detected)

V779 Unreachable code detected. It is possible that an error is present. mps.c 1306

static int
mps_alloc_requests(struct mps_softc *sc)
{
  ....
    else {
      panic("failed to allocate command %d\n", i);
      sc->num_reqs = i;
      break;
    }
  ....
}

Report: http://ift.tt/2nLRtEL

7. FreeBSD. CWE-561 (Unreachable code detected)

V779 Unreachable code detected. It is possible that an error is present. efx_mcdi.c 910

void
efx_mcdi_ev_death(
  __in    efx_nic_t *enp,
  __in    int rc)
{
  ....
  efx_mcdi_raise_exception(enp, emrp, rc);

  if (emrp != NULL && ev_cpl)
   emtp->emt_ev_cpl(emtp->emt_context);
}

Report: http://ift.tt/2mYEbR4

8. FreeBSD. CWE-561 (Unreachable code detected)

V779 Unreachable code detected. It is possible that an error is present. sctp_pcb.c 183

struct sctp_vrf *
sctp_allocate_vrf(int vrf_id)
{
  ....
  if (vrf->vrf_addr_hash == NULL) {
    /* No memory */
#ifdef INVARIANTS
    panic("No memory for VRF:%d", vrf_id);
#endif
    SCTP_FREE(vrf, SCTP_M_VRF);
    return (NULL);
  }
  ....
}

Report: http://ift.tt/2mYvtlO

10. FreeBSD. CWE-570 (Expression is Always False)

V547 Expression 'value < 0' is always false. Unsigned type value is never < 0. ar9300_xmit.c 450

HAL_BOOL
ar9300_reset_tx_queue(struct ath_hal *ah, u_int q)
{
  u_int32_t cw_min, chan_cw_min, value;
  ....
  value = (ahp->ah_beaconInterval * 50 / 100)
    - ah->ah_config.ah_additional_swba_backoff
    - ah->ah_config.ah_sw_beacon_response_time
    + ah->ah_config.ah_dma_beacon_response_time;
  if (value < 10)
    value = 10;
  if (value < 0)
    value = 10;
  ....
}

Report: http://ift.tt/2mYCH96

11. FreeBSD. CWE-571 (Expression is Always True)

V617 Consider inspecting the condition. The '0x00000080' argument of the '|' bitwise operation contains a non-zero value. mac_bsdextended.c 128

#define  MBO_TYPE_DEFINED 0x00000080

static int
ugidfw_rule_valid(struct mac_bsdextended_rule *rule)
{
  ....
  if ((rule->mbr_object.mbo_neg | MBO_TYPE_DEFINED) &&      // <=
      (rule->mbr_object.mbo_type | MBO_ALL_TYPE) != MBO_ALL_TYPE)
    return (EINVAL);
  if ((rule->mbr_mode | MBI_ALLPERM) != MBI_ALLPERM)
    return (EINVAL);
  return (0);
}

Report: http://ift.tt/2mYvi9Z

Прочие ошибки

1. FreeBSD

V646 Consider inspecting the application's logic. It's possible that 'else' keyword is missing. if_em.c 1944

static int
em_if_msix_intr_assign(if_ctx_t ctx, int msix) 
{
  ....
  if (adapter->hw.mac.type < igb_mac_min) {
    tx_que->eims = 1 << (22 + i);
    adapter->ims |= tx_que->eims;
    adapter->ivars |= (8 | tx_que->msix) << (8 + (i * 4));
  } if (adapter->hw.mac.type == e1000_82575)                // <=
    tx_que->eims =
      E1000_EICR_TX_QUEUE0 << (i %  adapter->tx_num_queues);
  else
    tx_que->eims = 1 << (i %  adapter->tx_num_queues);
  ....
}

Report: http://ift.tt/2mYFkIn

2. CoreCLR

V534 It is likely that a wrong variable is being compared inside the 'for' operator. Consider reviewing 'i'. ildasm mdinfo.cpp 1421

void MDInfo::DisplayFields(mdTypeDef inTypeDef,
                           COR_FIELD_OFFSET *rFieldOffset,
                           ULONG cFieldOffset)
 {
  ....
  for (ULONG i = 0; i < count; i++, totalCount++)
  {
    ....
    for (ULONG iLayout = 0; i < cFieldOffset; ++iLayout)  // <=
    {
      if (RidFromToken(rFieldOffset[iLayout].ridOfField) ==
          RidFromToken(fields[i]))
      {
        ....
      }
    }
  }
  ....
}

Report: http://ift.tt/2mYDEOM

Заключение

Предлагаем скачать анализатор PVS-Studio и попробовать проверить ваш проект:

Скачать PVS-Studio для Windows
Скачать PVS-Studio для Linux

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

Для быстрого знакомства с анализатором, вы можете воспользоваться утилитами, отслеживающими запуски компилятора и собирающие для проверки всю необходимую информацию. См. описание утилиты CLMonitoring и pvs-studio-analyzer. Если вы работаете с классическим типом проекта в Visual Studio, то всё ещё проще: достаточно выбрать в меню PVS-Studio команду «Check Solution».

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. Weaknesses detected by PVS-Studio this week: episode N3

Прочитали статью и есть вопрос?

Часто к нашим статьям задают одни и те же вопросы. Ответы на них мы собрали здесь: Ответы на вопросы читателей статей про PVS-Studio, версия 2015. Пожалуйста, ознакомьтесь со списком.

Комментарии (0)

Let's block ads! (Why?)

Эврика! Моменты озарения при изучении React

Светлана Шаповалова, редактор «Нетологии», перевела статью Тайлера МакГинниса, в которой он перечислил основные моменты озарения, которые возникают при изучении React.

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

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

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

Озарение №1. Props для компонентов — то же, что и аргументы для функций

Что хорошо в React: то самое наитие, которое вы используете для JavaScript-функций, можно применять, чтобы понять, где и когда надо создать компоненты React. Отличие React вот в чем: вместо того чтобы брать некоторые аргументы и возвращать значение, ваша функция будет брать некоторые аргументы и возвращать объектное представление вашего пользовательского интерфейса (UI).

Эту мысль можно выразить формулой fn(d) = V. Читается так: «функция принимает некоторые данные и возвращает представление».

Это прекрасный способ представить себе разработку пользовательских интерфейсов — теперь ваш UI просто состоит из различных вызовов функций. Это похоже на создание приложений. Теперь вы можете использовать все преимущества композиции функций при создании пользовательских интерфейсов.

Озарение №2. В React пользовательский интерфейс вашего приложения полностью построен с использованием композиции функций. JSX — это абстракция над этими функциями

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

Во-первых, JSX — это абстракция над React.createElement — функцией, возвращающей объектное представление DOM.

Всякий раз при трансляции JSX у вас будет объект JavaScript, представляющий собой фактический DOM — или любой другое представление платформы, на которой вы находитесь (iOS, Android и т. д.). Затем React проанализирует этот объект и проанализирует фактический DOM. С помощью diff React может обновить DOM только там, где произошло изменение. Это повышает производительность, но, что более важно, показывает, что JSX на самом деле «просто JavaScript».

Во-вторых, именно из-за того, что JSX — это просто JavaScript, вы получаете все преимущества JavaScript: например, композицию, линтинг и отладку. Но вы также по-прежнему получаете декларативность и схожесть с HTML.

Озарение №3. Компоненты не обязательно должны соответствовать узлам DOM

Когда вы впервые вникаете в React, вы учите, что «компоненты — это строительные блоки React. Они берут входные данные и возвращают некоторый интерфейс (шаблон дескриптора)».

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

В React хорошо то, что вам не нужно возвращать типичные «представления» из ваших компонентов. До тех пор, пока в результате возвращается элемент React, null или false, все хорошо.

Вы можете возвращать различные компоненты:

render () {
return 
}
You can return function invocations:
render () {
return this.props.children(this.someImportantState)
}
Or you can return nothing at all:
render () {
return null
}

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

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

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

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

Озарение №5. Наследование не нужно в React, а сдерживание и специализацию можно получить при помощи композиции

К счастью, React всегда был очень свободомыслящим относительно принципов функционального программирования. Один из примеров перехода React от наследования к композиции — релиз 0.13, когда стало ясно, что React не добавлял поддержку Mixins с классами ES6.

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

Озарение №6. Разделение контейнерных и презентационных компонентов

Если вы обратите внимание на строение компонента React, то он обычно включает в себя некоторое состояние, некоторые «крюки» жизненного цикла и разметку через JSX.

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

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

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

Озарение №7. Если вы пытаетесь сохранить большинство компонентов чистыми (pure), станет намного проще поддерживать элементы без состояния

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

Спасибо, что нашли время прочесть мою статью!

От редакции

Углубленное изучение JavaScript — это долгий путь. И библиотека React — лишь один из многих пунктов в резюме полноценного фронтенд-разработчика, при этом далеко не самый первый.
Если вы хотите к хорошим знаниям JavaScript добавить глубокое понимание Web API, научиться решать задачи на чистом JavaScript, вникнуть в BOM и DOM, изучить асинхронные HTTP-запросы (AJAX) и веб-сокеты (WebSocket) — записывайтесь на наш продвинутый курс «Front-end разработка: создаем интерактивные веб-страницы».

Комментарии (0)

Let's block ads! (Why?)

[Перевод] Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов

«Новая эра Web»: Университет ИТМО начинает подготовку IT-специалистов в области нейротехнологий

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

Примерами могут быть Brain Initiative и Human Brain Project, которые стоят на пересечении таких областей, как медицина, биология и нейроинформатика.

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

/ Flickr / Salford University / CC

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

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

Весной 2013 года в Сан-Франциско проводилась конференция NeuroGaming Conference & Expo, во время которой 18 компаний со всего мира продемонстрировали «нейрологические» достижения в области развлечений. Например, композитор Ричард Варп (Richard Warp) представил систему NeuroDisco, которая с помощью специальной гарнитуры позволяла слушателю микшировать музыку, реагируя на изменение его эмоционального состояния.

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

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

Еще одна компания, работающая в этой области, — «Моторика», которую основал выпускник факультета Точной механики и технологий Университета ИТМО Илья Чех. Команда работает над созданием доступных протезов с использованием 3D-печати, чтобы помочь детям с травмами рук.

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

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

«Популярность онлайн-обучения растет год от года, но есть и ряд проблем: до сих пор онлайн-курсы успешно заканчивают не более 5% слушателей, — комментирует заведующая кафедрой Компьютерных образовательных технологий Университета ИТМО Любовь Лисицына. — Путь к решению проблемы низкой результативности онлайн-курсов лежит в развитии технологий электронного обучения, в использовании новых моделей и методов для реализации нейроинтерфейсов с целью расширения ресурсов мозга».

Поэтому сотрудниками Университета ИТМО ведутся разработки по созданию специальных программно-аппаратных комплексов для исследования поведения человека во время обучения. В компании «Нейронет» заявляют, что нейротехнологии являются перспективным и многообещающим направлением. Они также предполагают, что в 2035 году сфера нейрообразования на мировом рынке будет оцениваться в 280 миллиардов долларов.

Особенности подготовки специалистов по нейротехнологиям

Международное аналитическое агентство Мarkets and markets провело исследование и выяснило, что одним из главных ограничивающих факторов роста рынка нейротехнологий является недостаток квалифицированных технических экспертов для разработки и поддержки сложных нейроинтерфейсов. При этом, как считают в аналитической компании Allied Market Research, к 2020 году разработка нейротехнологий станет одним из самых наукоемких процессов.

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

Объединить эти области знаний решили в Университете ИТМО. С 2017 года на кафедре Компьютерных образовательных технологий появится новая программа бакалавриата «Нейротехнологии и программирование». Как отмечает Любовь Лисицына, на текущий момент в России нет ничего подобного, а решение об открытии является реакцией на запросы рынка труда.

Что будут уметь выпускники?

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

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

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

P.S. Интересно почитать — другие материалы из нашего блога на Хабре:

Комментарии (0)

Let's block ads! (Why?)

«Мал да удал»: ученые разработали проточную батарею, охлаждающую чипы

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

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

/ фото Oregon Department of Transportation CC

Команде ученых из IBM и высшей технической школы Цюриха удалось найти две жидкости, которые могут выступать в качестве электролита и хладагента одновременно. «У нас впервые получилось создать такую маленькую батарею, способную подпитывать чипы и охлаждать их», — отмечает аспирант Джулиан Маршевски (Julian Marschewski).

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

Используя возможности 3D-печати, команда ученых разработала клинообразную систему из микроканалов, по которым поступают электролиты. Через пористые электроды жидкости переходят в специальный мембранный слой, где происходит диссоциация. Система оказалась способна вырабатывать 1,4 ватта мощности на один квадратный сантиметр. 400 милливатт тратятся на работу помпы, а 1 ватт остаётся для питания чипа.

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

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

P.S. О чем еще мы пишем в блоге IaaS-провайдера 1cloud:

Комментарии (0)

Let's block ads! (Why?)

HR-бренд: айтишника мало найти - его нужно удержать

четверг, 23 марта 2017 г.

Предсказываем будущее с помощью библиотеки Facebook Prophet

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

Зачем в команде мобильной разработки появился сейф под управлением Windows 10

image alt text

Привет! Я хочу рассказать, как мы сделали автоматическую выдачу 70 мобильных тестовых устройств, и перестали задаваться вопросом «у кого тот розовый iPhone 6».

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

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

Автоматический учет и ничего личного

Все тестовые устройства сейчас располагаются на DIY-стойках в шкафу. У каждого смартфона или планшета свое пронумерованное место и свой кабель для зарядки. Для учета используется Windows 10 приложение на планшете с подключенным сканером пропусков.

Для того, чтобы взять/отдать девайс нужно:

приложить бейджик к считывателю
отсканировать QR-код на нужных устройствах

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

Удобный поиск нужного смартфона — как бонус.

image alt text

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

image alt text

Последняя версия стенда.

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

Давным-давно, в далекой-далекой галактике…

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

image alt text
Фотореконструкция былых дней.

Плюс: учет не требовал каких-либо телодвижений со стороны мобильной разработки.

Минус: неудобно смотреть, сколько устройств на руках у коллег, не забыли ли нам что-то вернуть.

Со временем устройств и сотрудников становилось все больше, и привычная тетрадь уже не могла достойно ответить на вызовы времени и потребности тестировщиков. Поэтому её оцифровали и перенесли на страницу в Confluence, где наступила настоящая диктатура тестерского пролетариата. Хочешь взять вот этот смартфон — сначала найди свободного тестировщика, который все оформит. Кроме того, у каждого тестировщика всегда «Release is coming!», а тут еще отвлекают.

Но даже если найти человека удавалось, квест не заканчивался. Часто оказывалось, что нужный гаджет разряжен или уже занят. А вот если и тут повезло, тестировщик добавлял в Confluence-страничку ФИО сотрудника напротив взятых устройств.

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

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

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

Начинаем стройку

Какие вопросы мы хотели решить:

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

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

Проблема #1 — зарядка

Обычные USB-хабы и концентраторы для этой цели не подходят, ведь у них только 1-2 порта могут более-менее нормально заряжать устройства. А отдельная вилка для каждого устройства — некрасиво и неудобно.

Но тут я очень кстати нашел подходящий агрегат производства Anker:

image alt text

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

Проблема #2 — всему свое место

Для удобной расстановки мы заказали железный шкаф с дверьми-жалюзи «ДиКом **КД-144**»: он закрывается на замок, двери-жалюзи никому не мешают в открытом состоянии, а небольшие зазоры между полками и стенками позволяют без проблем провести провода для зарядки. Остается только просверлить небольшое отверстие в задней стенке для удлинителя.

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

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

Совет: лучше покупать пеноплекс шириной 3 см, тогда он подойдет как для телефонов, так и для планшетов.

Что в итоге получилось:

image alt text
Аккуратные ряды смартфонов, каждый на зарядке, нет клубка проводов.

image alt text

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

image alt text
Заказать их проще всего на всем известно й китайской торговой площадке.

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

Проблема #3, организационно-учетная

Эту задачу мы разделили на три подзадачи:

Идентификация сотрудника с использованием его бейджа. Для этого купили считыватель для пропусков: ST-CE01EM. Принцип работы считывателя прост: подключаем его по USB к ноутбуку (также считыватель работает и с Android-устройствами через OTG-переходник), открываем блокнот, прикладываем бейджик, и номер пропуска вводится посимвольно. Определить пользователя мы можем, внеся его данные в БД или через API.
Идентификация устройства. Для пилотной версии мы выбрали QR-коды из-за быстроты реализации. Достаточно распечатать и наклеить QR-код с идентификатором устройства на каждый девайс.
Но у QR-кодов в процессе использования выявилось несколько недостатков. В нашем приложении пользователь считывает код с помощью фронтальной камеры планшета и может не заметить сообщения, что устройство добавлено в "корзину", если перекроет экран рукой. Еще наш шкаф с мобилками стоит около окна, поэтому по утрам бывает сложно сканировать QR-коды, если предварительно не задернуть жалюзи. Поэтому сейчас мы переезжаем с QR-кодов на RFID-метки с клейкой основой — вместо сканирования кода достаточно будет приложить девайс к сканеру пропусков.
Фиксация изменений с помощью приложения для Windows 10 на С#.

UWP-приложение запускается на телефонах, планшетах и ПК с Windows 10. Кстати, про разработку UWP-приложений под Windows 10 думаем сделать отдельный пост. Если вам эта тема тоже интересна — пишите в комментариях.

Как перестать бояться и начать пользоваться

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

В первую очередь, вам нужно сделать форк на GitHub и собрать проект в Visual Studio 2017. Потом нужно найти PC для запуска приложения и сканер пропусков, а также заполнить базу сотрудников.

Необходимое оборудование

считыватель для пропусков — например, ST-CE010EM. Главное, чтобы устройство имитировало набор клавиш на клавиатуре. Для проверки подключите считыватель к компьютеру, откройте блокнот и приложите пропуск к считывателю. Номер пропуска должен появиться посимвольно.
Приложение по умолчанию ожидает 10-символьную длину пропуска: 000+НОМЕР_ПРОПУСКА, например 0001234567. Если при сканировании пропуска у вас не проставляются нули вначале, то считыватель можно перепрограммировать или отредактировать параметры номера бейджика в MainViewModel.cs.
PC с Windows 10. Удобнее использовать планшет или устройство все-в-одном с тачскрином.

Наполнение базы данных

База приложения в формате sqlite хранится в корне проекта TestStand.

Заполняем Devices

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

Id — номер устройства (QR код содержит как раз id устройства);
Model — модель гаджета;
Family — семейство устройства: iOS/Android/Windows;
OsVersion — версия операционной системы;
Type — тип устройства (Phone/Tablet/Wearable);
ScreenSize — размер экрана;
ScreenResolution — разрешение экрана;
IsContactlessPaymentsSupported — поддерживается ли на телефоне бесконтактные платежи (0/1);
PhoneNumber — номер телефона, если в нем есть симкарта.

Заполняем Employee

Если у вас есть возможность получать данные по пропуску через API, то можете написать для приложения расширение (extension). О расширениях уже подробно написал в своей статье Вадим Новосельцев, за что ему огромное спасибо!

В нашем приложении работа с расширениями ведется через ExtensionsService.cs. Само расширение используется в EmployeeService.cs (название по умолчанию: com.extensions.yamoney.teststand):

BadgeId — номер бейджика;
FirstName — ФИО сотрудника;
Login — логин сотрудника, по нему отправляется почта (login@domen.com). Отправка почты настраивается в EmailNotificationService.cs.

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

Печатаем QR-коды

В QR-коде должен быть записан ID устройства из таблицы Devices. Сформировать сам код можно онлайн, либо подобрать одну из множества утилит. Наклеиваем коды на гаджеты — и можно пользоваться.

image alt text

И вот прошел месяц

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

Главное преимущество в том, что мы теперь не тратим время на учет самих устройств, а на основании полученной статистики можем:

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

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

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

Комментарии (0)

Let's block ads! (Why?)

Миграция инфраструктуры в «облако» по шагам: какие возникают сложности и где

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

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

Подготовка

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

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

Мы выделяем мощности с небольшим запасом.

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

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

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

Переезд

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

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

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

Дальше образ тащится через выделенный канал или VPN. Некоторые заказчики пробрасывают просто через большой Интернет. Как правило, если речь о переносе серверного узла в «облако», у заказчика есть свой канал прямо до провайдера. Если переносится «зоопарк» без виртуализации, дело иногда сложнее: приходится строить VPN-туннель или же выгружать образы на отчуждаемые носители. Вообще, часто обычный VPN у провайдеров ограничивается где-то до 20 Мбит чисто по особенностям технологии. Поэтому обязательно нужен провайдерский L2VPN, либо придётся таскать через Интернет на свой страх и риск. Или же нужен патчкорд до провайдера, чтобы делать обмен напрямую, но с шифрованием. Выделенные каналы — не проблема, связь «“облако” — физика» получают многие: мы спокойно соединяем железные сервера во Владивостоке с виртуальными у нас. VPN посредством «облака»: ничего специально не надо, есть как базовый сервис.

Есть случаи, когда данных реально много, и даже гигабитный канал на стороне заказчика не устраивает. Тогда можно выгрузить всё на жёсткий диск с продуктива, привезти к нам, загрузить в «облако». Один раз даже таскали ноутбук с огромным жёстким диском. Кстати, заехать ко всем провайдерам просто, главный вопрос заказчиков — как потом выехать, если понадобится. У нас точно так же без проблем: например, однажды от нас переезжал заказчик со своим S3-подобным хранилищем (точнее, с нашего S3-совместимого они тащили всё на свой узел из-за особенностей по тому, как оформили обработку персональных данных). Просто попросили выгрузить в S3 все виртуалки в VMDK. Прибыли с 2 жёсткими дисками по 2 Тб, подключились к серверу, скопировали образы. Мы можем в VMDK или другом формате спокойно отдать.

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

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

Часто при переносе с железных платформ нужно делать ещё и апгрейд ОС исходных серверов — это тоже без проблем, но надо запланировать.

Особенности платформ

Довольно часто случается, что у заказчика в серверном узле одна платформа виртуализации, а переезд делается на другую по разным причинам. Особенно часто идёт миграция с VMware на KVM. Ключевой момент здесь в том, что для KVM есть два типа виртуализации. Первый и более производительный — virtio, для его работы требуются предустановленные драйвера. Во втором случае — legacy — менее производительный, когда используются IDE-диск и сетевой адаптер Intel E1000. Однако иногда этот тип виртуализации позволяет решить проблемы совместимости.

Дальше начинается квест с разным спектром гостевых операционок — 2003 и даже 2008 (она тоже была). Сложнее всего было с 2003, потому что не всё гладко вставало. В частности, обычно установка драйверов происходит на устройство, которое должно быть в операционной системе, но в случае миграции дрова ставятся ещё на машине, с которой идёт переезд на устройства, которых по факту нет. Чтобы при развёртывании всё сразу встало как надо. Это важно, потому что до запуска в облаке у такой машины нет сетевого адаптера, у виртуалки свой HDD и Ethernet. У машины в «облаке» свой драйвер HDD и своя сеть. В итоге в легаси-режиме ей прокидывается старый IDE-диск и адаптер. Но не во всех случаях это работало. В итоге пришли к тому, что с доставшими нас 2003-ми виндами решили выгружать снепшоты в промежуточное окружение (Proxmoxy), а там можно запустить виртуальную машину так, что у неё первый диск будет её «старый» IDE, а второй будет виртуальный, который винда увидит как существующее устройство. Вначале производилась в среде виртуализации Proxmox установка драйверов на ВМ для работы в KVM-плече, а уже затем ВМ выгружалась к нам в «облако». Потом виртуалка загружалась назад в «облако» и взлетала. Ещё была Убунта-8 лохматая, но даже она новее 2003-й винды. Самое весёлое — обновить эти ОС на стороне заказчика нельзя, например, на некоторых старых системах крутится «Консультант-Плюс» с купленной лицензией — это легаси, которое они вообще боятся трогать.

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

Встают вопросы совместимости, часто — при переезде Cisco в KVM либо при переносе MikroTik. В целом оно заводится: Микротик не поддерживается напрямую в KVM, но у нас есть опыт его настройки. От нашего «облака» шли связки в Рязань, Казань и Подольск, где, собственно, стоял Микротик, который строил все туннели между производствами.

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

Фактически мы поставляем заказчику ресурсы одного большого «облака», где он может выбрать три разные платформы: KVM-плечо для размещения одного куска инфраструктуры, «облачное» плечо на VMware (платформа Cisco Powered) для другого и MS-плечо на базе Hyper-V для третьего соответственно. Например, одному крупному банку очень хотелось завести у нас тестовую среду и скрестить её со своим железом, где крутился докер. Докеру на фиг не упала наша вебочка, но разработчикам очень понравилось API облака — у них своя самописная web-среда для всех тестовых площадок в разных дата-центрах. Подцепили наше API, дальше слияние докеров прошло отлично (спасибо возможностям и гибкости KVM, который позволяет очень многое докручивать). Ещё одна особенность: облачное плечо на Hyper-V мы специально проектировали для защиты ПДн. Такой подход накладывает ряд ограничений, и не любого заказчика с произвольными требованиями можно «приземлить» в облачное плечо Hyper-V.

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

Часто бывают промахи по перформансу. Канал, диски — могли недооценить требования к машине. Например, часто на «железных» переездах те, кто привык работать без виртуализации, забывают, что нужно отдавать несколько процентов производительности на работу гипервизора. Если у кого-то на серваках были графические карты — у нас графических карт в «облаке» нет. Был конфуз: заказчик не прочитал спеку, и сделали виртуализацию для видеомонтажа, 32 ядра, 200 гигов оперативы. Но у нас эта машина шла как сервер «облака», и предполагалось, что она отдаёт рабочий стол только ради консолей (стояло ограничение на 1,5 FPS для такого обмена). Зато СХД с диким перформансом: можно выбирать количество операций на те или иные нужды, оплата по факту.

Ещё некоторые заказчики не знают об ограничениях в лицензировании продуктов, размещённых в «облаке». Например, виртуальные машины с ОС Windows лицензирует исключительно поставщик сервиса IaaS (как владелец физических серверов).

Часто при миграции всплывают сетевые ошибки, которым много лет. Например, при одном сложном переезде выяснилось, что MSS был неверно сконфигурирован — остался костыль с 2007 года, и его так в результате никто не трогал. Результат был в том, что RDP-сессии рвались.

Ещё есть особенность внешней адресации. Получается, что в Интернет машинки могут входить через NAT, есть статическая трансляция.
Один из заказчиков хотел иметь в «облаке» подсеть «белых» IP-адресов от определённого провайдера. Дабы сэкономить средства и время, мы придумали следующую схему:

Строился VPN-туннель от маршрутизатора заказчика до «облака», но без указания AS КРОК.
Так как заказчик является провайдером, он выделил необходимую себе подсеть «белых» IP-адресов.
Трафик через VPN приходил на оборудование провайдера и через его собственную AS транслировался по BGP в Интернет.

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

Вот примерно так. Почитать ещё про «облака» можно здесь:

Комментарии (0)

Let's block ads! (Why?)

Как оценить качество системы A/B-тестирования

Запуск проекта Otus.ru

среда, 22 марта 2017 г.

Про биологию, мега-стройки и магических животных

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

Фронт-офисная биология

Задача: есть Банк с огромной линейкой банковских продуктов и сервисов по каждому из продуктов (подробнее на http://www.sberbank.ru). Необходимо автоматизировать все фронтальные сценарии по каждому из продуктов, по каждому из каналов для разных групп клиентов (да, да – разные категории клиентов могут иметь разные сценарии обслуживания по одному каналу).
Пока звучит скучно и непонятно. Однако те, кому приходилось автоматизировать финансовый сектор, могут прикинуть количество фронтальных сценариев к автоматизации и необходимое количество функциональных элементов. Простые инженерные оценки дадут приблизительно следующие показатели:

Количество сценариев (фронтальных процессов): ~ 10³
Количество визуальных форм в сценариях: ~10⁴
Количество печатных форм в сценариях: ~2 ᵡ 10³

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

Однако,

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

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

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

Ожидания бизнеса по возможности выстраивания сегмента-ориентированных или персонифицированных процессов обслуживания, что является удачной почвой для роста количества вариантов сценариев обслуживания до ~ 10⁴
Естественно, все сценарии нужно тестировать на эффективность либо landing page, либо на удобство рабочего места оператора, что если опять не плодит кол-во самих сценариев, то увеличивает популяцию визуальных форм до ~10^5-∞
Есть и длительные тренды внутривидовой борьбы. Например, удаленное обслуживание вытесняет офисное, и фронтальный функционал по удаленным каналам растет сам по себе. При этом офис не сдается – пытается получить часть «генофонда удаленки» и создать новые сценарии омниканального (Omni channel) обслуживания — ~10^5-∞

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

Не вавилонская система

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

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

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

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

Конечный исполняемый код можно всегда переопределить или дописать функционал, не трогая алгоритмы трансформации и получить важное частное решение
Сами алгоритмы трансформации можно заменять и расширять, не меняя уже сгенерированный код. Как мы говорили выше, целевой срок его жизни не большой
И самое главное. Уже готовый прикладной функционал это всего лишь один из видов модели и только потом конечный код. А значит для него можно придумать алгоритм, который перегонит его по необходимости в другую модель при замене архитектуры, требований ЦБ, необходимости автоматизации A/B-тестов, порождению специализированных сценариев обслуживания по каналам и сегментам потребителей.

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

Магический зверь и где он обитает

Собственно, именно этот магический зверь

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

АРМ Архитектора

АРМ Системного аналитика

Да, мы посадили наших системных аналитиков за Eclipse + Papyrus. Общая модель конфигураций пока построена на базе зарендеренного дерева UML-объектов и позволяет сейчас конфигурировать: общую декомпозицию требований, артефакты конфигураций процессов, визуальных форм, точек интеграции, сущностей, их атрибутов справочников и кучу системных объектов самой платформы ЕФС. Чуть позже здесь будет и JasperReport-редактор.

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

Общая модель генерации кода

Второй уровень, это собственно уровень модели функциональных элементов. Он позволяет уже породить первый полезный артефакт для IT-проекта – полную спецификацию функциональных элементов.

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

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

Наконец добавить слой бизнес-конструкторов независимо от организации функционального слоя и компонентной архитектуры
Расширять состав функциональных элементов и добавлять канало-специфичные функциональные элементы
Управлять компонентной архитектурой независимо от функционала
Ограничить сложность кода трансформации группы связанных конфигурационных элементов одного уровня в другой группу другого элемента объемом в 1K-2K строк кода.
Решать задачи детально, но не глобально. Например, задачи трансформации VO->DTO->VO очень часто имеет частное решение объемом «да ладно, за эти выходные точно запилю».
Иметь на каждом слое немножечко избыточное кол-во конфигураций, чтобы автоматизировать порождение частных случаев конфигураций и «автоматизировать автоматизацию автоматизации». Например, для канального фронтального сценария порождение множества его вариация для A/B-тестирования может быть выполнено автоматически. Ну и маппинг, маппинг, маппинг.

Как уже говорили в предыдущих двух разделах, последний пункт особенно важен. Он то и позволит 10⁴ визуальных форм превращать в 10⁵ для задач автоматизации A/B-тестов или вывода сценария в новый канал. При этом трудозатраты не увеличиваются и в 2 раза.

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

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

Для обеспечения полноты конфигураций мы разработали функционал, автоматизирующий реверс-инжиниринг (Reverse engineering). Мы строим Java Model выделенного блока функционала, соответствующего отдельному прикладному модулю (оранжевый квадратик на первом скриншоте) и пытаемся распознать паттерны кода, сравнивая их с тем что есть в компонентной модели. Пока эта магия более-менее успешно работает для прикладных сущностей, публичного API, ключевых системных объектов.

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

Комментарии (0)

Let's block ads! (Why?)

Обзор IntelliJ IDEA 2017.1: Java 9, Kotlin 1.1, Spring, Gradle, JavaScript, Go и многое другое

Интел усиливает позиции в HPC

Зашифрованные почтовые сервисы: что выбрать?

[Перевод] Стратегия развития языков программирования .NET

Мэдс Торгерсен (Mads Torgersen), занимающийся больше 11 лет развитием .NET-языков в Microsoft, поделился описанием принципов, которыми руководствуется его команда, принимая решения о развитии каждого языка. Передаю слово Мэдсу.

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

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

C#

C# используют миллионы людей.

Согласно проведенному опросу разработчиков на Stack Overflow, C# был признан одним из самых популярных языков программирования в 2016 году. По популярности его обошли лишь Java и, конечно же, JavaScript (SQL не рассматривается в качестве языка программирования, но не будем спорить об этом). На эти результаты мог повлиять уровень популярности сайта Stack Overflow в разных языковых сообществах, но без сомнений, С# однин из самых распространенных языков программирования. Он широко используется в различных направлениях: игры на движке Unity, мобильные приложения в Xamarin, веб-приложения в ASP.NET, бизнес-приложения в Windows, микрослужбы .NET Core в Linux на платформах Azure и Amazon Web Services (AWS) и многое другое.

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

После стольких лет люди продолжают любить C#! Почему? Всё это время мы развивали его с прагматичностью и своим стилем, решая новые задачи и не меняя при этом саму суть языка. C# считается мощным, эффективным и простым в использовании языком. Он и обычно ассоциируется с .NET, поскольку друг без друга у них нет будущего.

Стратегия развития C#

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

Каждая следующая версия C# содержит существенные улучшения: универсальные шаблоны в C# 2.0, LINQ и большое количество функциональных улучшений в C# 3.0, тип dynamic в C# 4.0, async в C# 5.0 и целый набор небольших, но полезных функций в C# 6.0. Многие возможности добавлялись для адаптации к новым вариантам использования, а начиная с версии C# 5.0 особое внимание уделяется подключенным устройствам и службам, скорости таких подключений и обработке потоков данных, идущих через них. Не будет исключением и новая версия C# 7.0, основными нововведениями которой являются кортежи и сопоставление шаблонов, позволяющие преобразовать и упростить работу с потоком данных и управление в коде.

Начиная с версии C# 6.0 мы начали делиться заметками разработчиков языка на GitHub. Всё чаще новые фичи появляются в диалоге с сообществом, иногда доходит до того, что Microsoft воспринимается как один из «contributors».

Описание процесса разработки языка C# опубликовано на GitHub в разделе dotnet/csharplang, а обсуждение происходит в рассылке csharplang.

Visual Basic

Visual Basic используют сотни тысяч людей.

Большинство из них используют WinForms для создания бизнес-приложений для Windows, а некоторые весьма умело пользуются возможностями веб-форм ASP.NET для создания веб-сайтов. Большинство из них также используют C#. Для многих разработчиков это обусловлено требованиями к языку в различных проектах, над которыми они работают. Однако, выходя за рамки основных вариантов использования Visual Basic, многие не раздумывая переходят на C#, даже если можно использовать Visual Basic. Экосистема, примеры и сообщество для C# зачастую оказываются обширнее.

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

Респонденты на Stack Overflow отнеслись к Visual Basic неблагосклонно: он получил первое место в списке языков, которым пользователи предпочли бы найти замену. Считаю, что к этому стоит отнестись с некоторой долей скептицизма. Во-первых, в число этих людей могут входить разработчики VB6, которых нельзя винить в желании двигаться вперед. Кроме того, Stack Overflow — это не основная среда обитания разработчиков Visual Basic, так что если вы решили принять участие в опросе, то это, скорее всего, потому что вы уже посещали Stack Overflow, будучи поклонником другого языка программирования. Наконец, более глубокий взгляд на эти результаты показывает, что большинство разработчиков Visual Basic предпочли бы перейти на C#, что может свидетельствовать скорее об их желании сфокусировать свое развитие в области .NET на одном языке, чем о том, чтобы просто отказаться от Visual Basic.

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

Стратегия развития Visual Basic

Мы будем поддерживать Visual Basic как простой и доступный язык. Мы сделаем всё необходимое, чтобы он оставался одним из основных языков среды .NET: например, если при добавлении новых возможностей в C# изменяется какой-либо API, то использование этого API в Visual Basic должно выглядеть так же естественно. С учётом того, что многие разработчики используют и Visual Basic, и C#, мы сохраним принцип использования кросс-языкового инструментария. Мы сосредоточим выпуск обновлений в популярных для Visual Basic областях и сценариях использования.

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

В Visual Studio 2015 Visual Basic 14 и C# 6.0 в основном продолжали развиваться совместно и имели много общих усовершенствований: операторы с условием NULL (?.), NameOf и так далее. При этом в обоих языках были устранены некоторые специфические для каждого из них недостатки. Например, в Visual Basic появились многострочные строковые литералы, комментарии после неявного продолжения строки и многое другое. В это же время в C# появились функции и свойства в теле выражений (expression-bodied members), а также другие возможности, которым нет места в Visual Basic.

В VB 15 появятся некоторые из новых возможностей C# 7.0. Кортежи полезны не только сами по себе, но и благодаря тому, что обеспечивают совместимость, так как они будут использоваться в подписях API. Тем не менее в Visual Basic 15 не будет таких возможностей, как выражение is, выходные переменные (out-variable) и локальные функции, которые принесут больше вреда, например, ухудшат читабельность языка.

Описание процесса разработки языка Visual Basic опубликовано на GitHub в разделе dotnet/vblang, f обсуждение происходит в рассылки vblang.

Более подробно стратегия развития Visual Basic описана в этой статье.

F#

Язык F# используют десятки тысяч людей.

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

F# занял высокую позицию в рейтинге любимых языков программирования: люди просто любят работать в нём! Несмотря на то, что F# имеет фантастический инструментарий по сравнению с большинством других языков в этом списке, он всё же не может сравниться с богатством возможностей C# и Visual Basic. Многие нововведения значительно способствуют прогрессу языка. Всё больше разработчиков для среды .NET (как внутри, так и за пределами Microsoft) считают F# языком программирования, который нужно учитывать и осваивать.

У F# невероятно заинтересованное сообщество, которое играет очень важную роль в его развитии и постоянном совершенствовании, не в последнюю очередь благодаря полностью открытому процессу разработки языка. Это абсолютный лидер среди языков .NET с открытым исходным кодом, существенный вклад в его разработку осуществляется за пределами Microsoft.

Стратегия развития F#

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

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

F# 4.1 содержит значительное улучшение инструментария в Visual Studio за счет интеграции с абстракцией рабочего пространства редактора Roslyn, направленности на .NET Core и .NET Standard, а также улучшенных сообщений компилятора об ошибках. Значительная часть оптимизации инструментария Visual Studio (в том числе улучшенные сообщения об ошибках) является результатом активного участия сообщества F#. В будущем мы намерены работать как с сообществом F#, так и c другими специалистами в Microsoft, чтобы обеспечить F# лучшим в своем классе инструментарием и сделать его функциональным языком программирования с лучшим инструментарием на рынке.

Описание языка F# можно найти в репозитории с предложениями на GitHub и RFC.

Заключение

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

Удачи в разработке!

Если вы увидели неточность перевода, сообщите, пожалуйста, об этом в личные сообщения.

Комментарии (0)

Let's block ads! (Why?)

...

суббота, 25 марта 2017 г.

пятница, 24 марта 2017 г.

Комментарии (0)

UI ! = UX

UI это инструмент

Неправильное использование это риск

Поиск подходящего дизайнера

Ответственность за проблему

Вывод

Комментарии (0)

Для тех, кто ещё не знаком с инструментом PVS-Studio

Потенциальные уязвимости (weaknesses)

Прочие ошибки

Заключение

Комментарии (0)

Озарение №1. Props для компонентов — то же, что и аргументы для функций

Озарение №2. В React пользовательский интерфейс вашего приложения полностью построен с использованием композиции функций. JSX — это абстракция над этими функциями

Озарение №3. Компоненты не обязательно должны соответствовать узлам DOM

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

Озарение №5. Наследование не нужно в React, а сдерживание и специализацию можно получить при помощи композиции

Озарение №6. Разделение контейнерных и презентационных компонентов

Озарение №7. Если вы пытаетесь сохранить большинство компонентов чистыми (pure), станет намного проще поддерживать элементы без состояния

От редакции

Комментарии (0)

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

Особенности подготовки специалистов по нейротехнологиям

Что будут уметь выпускники?

Комментарии (0)

Комментарии (0)

четверг, 23 марта 2017 г.

Автоматический учет и ничего личного

Давным-давно, в далекой-далекой галактике…

Начинаем стройку

Проблема #1 — зарядка

Проблема #2 — всему свое место

Проблема #3, организационно-учетная

Как перестать бояться и начать пользоваться

Необходимое оборудование

Наполнение базы данных

Заполняем Devices

Заполняем Employee

Печатаем QR-коды

И вот прошел месяц

Комментарии (0)

Подготовка

Переезд

Особенности платформ

Комментарии (0)

среда, 22 марта 2017 г.

Фронт-офисная биология

Не вавилонская система

Магический зверь и где он обитает

Комментарии (0)

C#

Стратегия развития C#

Visual Basic

Стратегия развития Visual Basic

F#

Стратегия развития F#

Заключение

Комментарии (0)

суббота, 25 марта 2017 г.

пятница, 24 марта 2017 г.

четверг, 23 марта 2017 г.

среда, 22 марта 2017 г.