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

Компании Energy Vault и Idealab анонсировали коммерческую доступность их «новаторского» решения и планируют в реальности на полных мощностях организовать реализацию своего энерго-стартапа совместно с индийским энергетическим гигантом Tata и мексиканской строительной компании CEMEX.

— Что за разработку они реализуют?

— «Умные» гравитационные башни. Это такие комплексы мега-кранов (высота 120 метров или 393 фута, по шесть стрел на башне) + 35-тонные бетонные блоки (много) + ПО для управления перемещением блоков и компоненты системы генерации электроэнергии.

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

— Только тут еще сохраняем энергию на долгий срок, а ветряки или солнечные станции рядом будут помогать на этапах поднятия блоков для минимизации энергозатрат. КПД обещают до 80-90%, а общую мощность (полную емкость хранения в данном случае) как у средних ГЭС, шесть моторов в кранах, от 2 до 5 МВт выходная мощность заявлена, но это в теории. Все зависит от алгоритмов специального ПО и современных энерго-генерационных комплексов.

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

Мужики в наших выпусках уже порядочно намужичили, и затронули, кажется, все проблемы со всех сторон. Некоторые доотвечались до того, что следующие 10 вопросов им могли задать уже в ФСБ (фу такими быть, товарищи запрещальщики).

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

Поэтому, когда я недавно говорил с Алиной Ануфриевой (allinne) об ИП в Германии, задал ей и привычные уже нам 10 вопросов.

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

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

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

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

В последнее время, мне пришлось немного поработать с блокчейном Ethereum. Идея, над которой я работал, требовала хранить прямо в блокчейне некоторое достаточно большое количество целых чисел, так, чтобы смарт-контракт имел к ним удобный доступ. Большинство уроков по разработке смарт-контрактов говорят нам «не храните много данных в блокчейне, это дорого!». Но сколько это «много», и с какого количества цена становится слишком высокой для практического использования? Это мне надо было выяснить, потому что нам наши данные выносить офф-чейн было никак нельзя, рушилась вся затея.

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

Для начала, я решил быстро прикинуть — получится ли у нас? Давайте возьмём стандартный, широко распространённый тип контракта — токен ERC20. По крайней мере, такой контракт хранит в блокчейне соответствие адресов людей, который купили токены, их балансам. В реальности, хранятся только балансы, каждый из которых занимает 32 байта (на деле здесь экономить не имеет смысла из-за особенностей Solidity и EVM). У более-менее успешного токена легко могут быть десятки тысяч обладателей, и таким образом получаем, что хранить в блокчейне около 320000 байт — вполне допустимо. А нам больше и не надо!

Наивный подход

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

Философские ошибки рыночной доктрины

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

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

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

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

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

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

Еще 4 года назад использование контейнеров в production было экзотикой, но сейчас это уже норма как для маленьких компаний, так и для больших корпораций. Давайте попробуем посмотреть на всю эту историю с devops/контейнерами/микросервисами ретроспективно, взглянуть еще раз свежим взглядом на то, какие задачи мы изначально пытались решить, какие решения у нас есть сейчас и чего не хватает для полного счастья?

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

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

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

Какова фундаментальная сложность задачи? Такова постановка базовой задачи специалистов по информатике, пытающихся рассортировать задачи по т.н. классам сложности. Это группы, содержащие все вычислительные задачи, требующие не более фиксированного количества вычислительных ресурсов – таких, как время или память. Возьмём простой пример с большим числом типа 123 456 789 001. Можно задать вопрос: является ли оно простым числом – таким, которое делится только на 1 и себя? Специалисты по информатике могут ответить на него при помощи быстрых алгоритмов – таких, что не начинают тормозить на произвольно больших числах. В нашем случае окажется, что это число не является простым. Затем мы можем задать вопрос: каковы его простые множители? А вот для ответа на него быстрого алгоритма не существует – только если использовать квантовый компьютер. Поэтому специалисты по информатике считают, что две этих задачи относятся к разным классам сложности.

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

Обычно, в качестве первого практического задания мы даем студентам Курс молодого бойца, который неожиданно для меня, стал весьма популярным в рунете. После этого мы переходили к более профильным вещам (мы все же занимаемся security): Check Point, Fortinet, Splunk, Kali-Linux. Однако, вскоре стало понятно, что это слишком резкий переход — от обычных сетей, сразу к таким сложным продуктам информационной безопасности. Скажем прямо, тот же Check Point, не самый лучший вариант для ознакомления с Межсетевыми экранами. Нужно было начинать с чего-нибудь попроще. Именно поэтому мы начали создавать курс “Cisco ASA Administrator”. Мы сразу решили, что сделаем этот курс открытым и запустим на канале NetSkills, просто потому что там больше подписчиков, а значит его увидят большее кол-во людей. Почему именно этот курс и о чём он, мы расскажем ниже.

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

Разумеется, никто не сможет сначала построить станцию и потом перенести несущую стену из-за того, что система вентиляции не сможет быть смонтирована в текущей конфигурации. Поэтому процессы реального мира всё больше уходят в «цифру». Как вам понравится комментарий к коммиту «Перенос капитальной стены на 2 метра севернее»? При проектировании и тестировании АЭС применяется полностью цифровой подход: создается информационная модель, к ней применяется классическая V-модель управления жизненным циклом. Таким образом, АЭС превращается в тиражируемый и полностью цифровой объект. Тестирование и запуск современных АЭС происходит в цифровом виде, и только после этого строители приступают к монтажу, используя всё те же цифровые модели.

Из этой статьи вы узнаете о том, что представляет собой современная информационная система, как происходит разработка и тестирование «капитальных» объектов на примере АЭС.


В основе материала — расшифровка доклада Вячеслава Аленькова, директора по системной инженерии и информационным технологиям инжиниринговой компании «Атомстройэкспорт» (ASE) с нашей декабрьской конференции Heisenbug 2017 Moscow.

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

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

25 мая 2018 года вступил в силу новый европейский регламент по защите персональных данных (далее GDPR – General Data Protection Regulation). Этот регламент известен своим экстерриториальным действием: он обязателен к применению во всех странах ЕС, а при некоторых условиях распространяет своё действие и на неевропейские компании или вынуждает их приводить свою деятельность в соответствие требованиям GDPR, чтобы не потерять европейского партнера. Следовательно, российский бизнес тоже может быть затронут новым законом, общий анализ которого доступен здесь. GDPR усиливает ранее установленный режим защиты персональных данных, а также вводит новые обязательства для организаций, обрабатывающих такие данные.

В частности, регламент провёл модернизацию уже существовавшей профессии ответственного по защите данных (далее DPO — Data Protection Officer). Эта должность была предусмотрена ещё рамочной директивой 1995 года, которая и была заменена новым текстом. Предыдущее законодательство регламентировало деятельность такого специалиста, но не настаивало на его назначении в обязательном порядке.

Заголовок статьи звучит как epic fail, но на самом деле все не так однозначно. Да и в общем и целом эта история закончилась весьма позитивно, хоть и не в Google. Но это уже тема для другой статьи. В этой же статье я расскажу о трех вещах: каким образом проходил мой процесс подготовки, каким образом проходили интервью в Google и почему же на мой взгляд все не так однозначно, как может показаться.

Предисловие

​Все началось более 2-х лет тому назад, и я перешел на 4-й курс специальности "Бизнес-информатика" Томского Государственного Университета Систем Управления и Радиоэлектроники (ТУСУР). До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому. Вариантов тем дипломных проектов рассматривалось много: и проекты конфигураций для автоматизации производственных нужд компании и проект внедрения Документооборота своими силами на 3 территориальные единицы и более 500 активных пользователей и внедрение ЭДО. Короче много всего что было в голове, но ничего из этого не вдохновляло. А это было главное.

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

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

Что неприятнее «красного теста»? Тест, который то зелёный, то красный, и непонятно, почему. На нашей конференции Heisenbug 2017 Moscow Андрей Солнцев (Codeborne) рассказывал, из-за чего они могут возникать и как снижать их число. Примеры в его докладе такие, что прямо-таки кожей ощущаешь боль, возникавшую при столкновении с ними. А советы полезные — причём ознакомиться с ними стоит как тестировщикам, так и разработчикам. Есть и неожиданное: можно узнать, как порой можно разобраться в проблеме, если оторваться от экрана и поиграть с дочкой в кубики.

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

Решение «Extreme Extended Edge» (также известное как Virtual Port Extender – VPEX) это новая технология, поддержка которой впервые представлена в операционной системе EXOS, начиная с релиза 22.5. Само решение основано на базе стандарта IEEE 802.1BR (Bridge Port Extension), и в рамках релиза EXOS 22.5 была добавлена поддержка новой аппаратный линейки ExtremeSwitching V400

Скриншот собираемых данных:



Современные системы безопасности ОЧЕНЬ прожорливы до ресурсов. Почему? Потому что они считают больше, чем многие продакшн-сервера и системы бизнес-аналитики.

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

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

Сейчас системы UBA (User Behavior Analytics) анализируют поведение пользователей, сравнивая их с другими сотрудниками компании, и оценивают логичность и правильность каждого действия сотрудника. Делается это за счёт Data Lake-методов и довольно ресурсоемкой, но автоматизированной обработки алгоритмами машинного обучения — в первую очередь потому, что прописывать все возможные сценарии руками занимает несколько тысяч человеко-дней.

Несколько дней назад меня в очередной раз спросили: «SD-WAN — это чистой воды маркетинг или реально эффективная технология?». Недоверие понятно: ко всему новому — а технологии всего пара лет — рынок присматривается с подозрением.

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