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

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

Аналогичная ситуация – с данными в автоматизированных системах.

Конец года, все потихоньку подводят итоги.

Для меня этот год запомнился проектом внедрения Single Sign On (SSO) между SAP и Windows. В этой статье расскажу об опыте внедрения и проектного менеджмента, подводных камнях, находках и выводах.

Компания — крупное транспортное предприятие в Бельгии, объединяющее метро, трамвай и автобус. Сотрудников более 10 тысяч, из них почти две тысячи это backoffice, использующий много инструментов: корпоративный сайт, почту, службу заявок, sharepoint, архивариус и, конечно, SAP.

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

Проблема:

• SAP для пользователя PC — это отдельное приложение, для входа в которое нужен свой пароль
• Сначала пароль нужно запросить, а потом помнить. Техподдержка вынуждена принимать звонки по созданию и смене паролей.
• С точки зрения пользователя лишний пароль — это лишние хлопоты. Люди хранят пароли на бумажках или делают их слишком простыми. Безопасность вопит о грубых нарушениях.
• Минимальные требования для пароля от PC не совпадают с параметрами паролей в SAP. Если приводить их к единому знаменателю, то лучше сразу внедрить SSO.

Задача: внедрить SSO между Windows и SAP, чтобы, заходя в свою учётную запись на PC, пользователь мог залогиниться в SAP не вводя пароль.

Если вы не имеете дела с SAP вам будет интересна эта статья с точки зрения менеджмента проекта, для сапёров тех детали будут приведены (в скобках).

Под катом:

1. Scope
   1.1 Scope Люди
   1.2 Scope системы
2. Компоненты
   2.1 Изменение параметров системы
   2.2 Windows Active Directory (AD)
   2.3 SAP Secure Login Client (SLC)
   2.4 Привязка пользователя SAP к его AD
   2.5 Модификация файла SAP logon.ini
3. Тестирование
4. SNC это дыра в безопасности
5. Командная работа
6. Информация для бизнеса
7. Трудности перевода
8. Итоги и выводы

Моя гостиная, попавшая в Ад.

Теперь в моём конвертере Noesis есть скрипт Roomba. Он отслеживает пылесос Roomba и сохраняет данные трекинга, что позволяет визуализировать эти данные множеством разных способов, в том числе, разумеется, превратить их в рандомизированную карту для DOOM.

Было бы здорово успеть сделать это к 25 годовщине DOOM, но она случилась и прошла, а я всё ещё ждал покупки Roomba 980 на eBay. Идея появилась у меня где-то в ноябре, когда мы с женой изучали разные робопылесосы. Я обнаружил, что в новых версиях Roomba довольно качественно реализован SLAM, поэтому задался вопросом — какие же данные можно получить из него и что с ними можно сделать.

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

Последний пост в году мы обычно посвящаем подведению его итогов — чем жила компания в 2018 и чего добилась. Скажем сразу: в уходящем году было маловато ярких событий. Похоже, это тенденция такая: яркость новинок неуклонно понижается. Но что-то в нем определенно произошло — вот на этом мы и остановимся. А чтобы было интереснее читать, разбавим текст лучшими короткими роликами Intel — теми, что набрали более миллиона просмотров на канале компании в YouTube. На КДПВ в этот раз — самое популярное видео года, 5 млн. просмотров

Что можно сделать с компьютером на электромагнитных реле у которого нет никаких устройств ввода, а из устройств вывода — только дамп восьми регистров?

Поиграть в игры, конечно! Играли же древние люди на калькуляторах МК-61/52, которые лишь немногим нагляднее.

Зовите детишек! Сейчас дядя Андрей расскажет рождественскую страшилку об NTP (Network Time Protocol).

Почти два года назад, в понедельник 16 января 2017 года, в нашу систему баг-репортов BitFolk поступил интересный тикет от постороннего лица. Отправитель представился как ведущий инженер-программист компании NetThings UK Ltd.

Тема: запрос NTP на IP 85.119.80.232

Привет,

Это может показаться странным, но мне нужно настроить сервер NTP по IP-адресу 85.119.80.232.

Что такого особенного в адресе 85.119.80.232? Это IP-адрес одного из NTP-серверов для обслуживания наших клиентов. За несколько недель до этого тикета сервер также был частью проекта NTP Pool.

Здесь важное слово «был». В конце декабря 2016 года я вывел NTP-серверы BitFolk из общественного пула и заблокировал их для посторонних.

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

Друзья, добрый день!

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

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

С 30 ноября по 2 декабря в Москве прошел PicsArt AI hackathon c призовым фондом — 100,000$. Основной задачей было сделать AI решение для обработки фото или видео, которое можно будет использовать в приложение PicsArt. Коллега по работе(на тот момент) Артур Кузин предложил поучаствовать, заинтересовав меня идеей — анонимизация личных фотографий пользователей с сохранением деталей(мимики и т.д). Также Артур позвал Илью Кибардина — студента МФТИ (кому-то же нужно было писать код). Название родилось очень быстро: DeepAnon.

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

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


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

Модель оценки объема работ

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


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

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

Сокращение разницы

Первый фактор — новому приложению необходимо догнать текущее.

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

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

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

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

Как появилась идея TeamLead Conf, при чем тут новый тип образования в digital и серендипность, рассказывает Александр Зиза, один из организаторов нашей конференции Aletheia Business и член программного комитета TeamLead Conf.

ChatOps со всем своим функционалом станет бесплатным — это наш вам подарок на праздники.

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

Часть 1 — тестирование с Locust
Часть 2 — продвинутые сценарии

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

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

В этой статье мы смоделируем и исследуем протокол двухфазного коммита с помощью TLA+.

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

Проблема двухфазного коммита

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

Менеджер транзакций (TM) принимает окончательное решение: коммит или отмена. Условием для коммита является готовность к коммиту всех RM. В противном случае транзакцию следует отменить.

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

Так получилось, что я относительно недавно начал программировать под Android – после месяца без проекта в компании, где я работаю, меня определили в команду мобильной разработки в уругвайском офисе Tata Consultancy Services. При беседе с тимлидом команды мне был озвучен стек, с которым мне предстояло сначала ознакомиться, а затем и овладеть. В числе прочего был фреймворк Dagger 2 для DI и MVP в качестве архитектурного паттерна. И Kotlin. Но о нем в другой раз :)

Таким образом, я приступил к изучению сначала основы Android SDK, а затем и всего сопутствующего стека. С самим SDK проблем не возникло – исчерпывающей информации по нему в сети более чем достаточно, начиная с официальной документации и заканчивая туториалами (особенно с этим помог проект startandroid), но с Dagger 2 и MVP применительно к Android-разработке возникли некоторые затруднения ввиду довольно куцей документации первого и, на тот момент, недостаточного понимания второго. Дело в том, что до мобильной разработки я делал микросервисы на Java с использованием Spring Boot/MVC и уже имел достаточное представление и о том, что такое Dependency Injection, и о том, что такое MVC. При том, даже само название “Spring MVC” предполагает, что этот паттерн заложен в архитектуру проекта и его использование очевидно. От Dagger 2 я ожидал как такой же как в Spring “магии” и настолько же проработанной документации и туториалов. И обломался :P

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

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

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