[Перевод] Советы по Postgres для Rails разработчиков

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

Управление долгими запросами с помощью таймаутов

Долгие запросы могут оказывать все виды негативных воздействий на вашу базу данных. Независимо от того, работают ли запросы часами или всего несколько секунд, они могут держать блокировки, переполнять WAL, или просто потреблять огромное количество системных ресурсов. C Postgres легче добиться большей стабильности с помощью установки таймаута на запросы. Удобно, что можно установить значение по умолчанию, например, 5 секунд, как показано в примере ниже, и тогда любой запрос, длящийся дольше 5 секунд будет убит:

production:
    url: <%= DATABASE_URL %>
    variables:
        statement_timeout: 5000

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

class MyAnalyticsJob < ActiveJob::Base
    queue_as :analytics
    def perform
        ActiveRecord::Base.connection.execute “SET statement_timeout = 600000” # 10 минут
        # ...
    ensure
        ActiveRecord::Base.connection.execute “SET statement_timeout = 5000” # 5 секунд
    end
end

Поиск “плохих” запросов

Rails многое абстрагирует при взаимодействии с вашей базой данных. Это может быть как хорошо, так и плохо. Postgres сам позволяет отслеживать долгие запросы, но по мере роста вашего Rails приложения, этого может оказаться недостаточно. Чтобы узнать происхождение запроса, есть чрезвычайно удобный гем marginalia, который будет логировать, откуда именно пришел ваш запрос. Теперь, когда вы видите неправильный запрос, слишком медленный, или который просто можно убрать, вы точно знаете где в коде это поправить:

Account Load (0.3ms) 
SELECT `accounts`.* FROM `accounts`
WHERE `accounts`.`queenbee_id` = 1234567890
LIMIT 1
/*application:BCX,controller:project_imports,action:show*/

Внимание на комментарий — прим.пер.

Высокоуровневый обзор ситуации с запросами к базе

Часто требуется общая картина того, что происходит в вашей базе данных. pg_stat_statements — это расширение Postgres, которое часто предустановленно в облачных средах, таких как Citus Cloud. Оно позволяет видеть, какие запросы выполнялись с момента последнего сброса статистики и как они себя вели.

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

SELECT query, total_time / calls AS avg_time
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

Если включить «track_io_timing» в сборщике статистики Postgres, то можно понять что является узким местом — процессор или ввод-вывод. Можно узнать больше о pg_stat_statements здесь(или в другой статье okmeter.io на хабре — прим.пер.).

Использование продвинутых фич

По умолчанию Rails использует файл «schema.rb» для хранения копии схемы базы данных, обычно используемой для инициализации базы данных перед запуском тестов. К сожалению, многие расширенные функции Postgres, такие как функциональные и частичные индексы, а также составные первичные ключи, не могут быть представлены в этом DSL.

Вместо этого имеет смысл перейти на генерируемый и используемый Rails файл «db/structure.sql», который можно сделать следующим образом:

# Use SQL instead of Active Record's schema dumper when creating the database.
# This is necessary if your schema can't be completely dumped by the schema dumper,
# like if you have constraints or database-specific column types
config.active_record.schema_format = :sql

Внутри используется формат Postgres «pg_dump», который иногда может быть чересчур подробным, но зато гарантирует получение полностью восстановленной структуры базы данных. Если вы столкнетесь с проблемой чрезмерно длинных diff-ов, можете взглянуть на activerecord-clean-db-structure.

Следите за тем, чтобы сложные транзакции не блокировали друг друга

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

BEGIN;
UPDATE organizations SET updated_at = ‘2017-04-27 11:31:03 -0700’ WHERE id = 123;
SELECT * FROM products WHERE store_id = 456;
--- еще всякие statement’ы тут
COMMIT; 

Первый оператор UPDATE будет удерживать блокировку на строку "organizations" с id "123", с самого начала и до COMMIT’а транзакции.

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

Чтобы обнаруживать подобные проблемы зарание, вы можете установить «log_lock_waits = on» в PostgreSQL.

Контролируйте подключения к базе данных

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

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

Let's block ads! (Why?)

[Перевод] Внимание! Хакеры начали использовать уязвимость «SambaCry» для взлома Linux-систем

Помните SambaCry?

Две недели назад мы сообщали об обнаружении в сетевом программном обеспечении Samba (иная реализация сетевого протокола SMB) критической уязвимости 7-летней давности. Она обеспечивает возможность удалённого выполнение кода и позволяет злоумышленнику взять под контроль уязвимые Linux- и Unix-машины.

Чтобы узнать больше об уязвимости SambaCry (CVE-2017-7494), вы можете прочитать нашу предыдущую статью.

В то время было обнаружено, что в Интернете существует около 485 000 компьютеров с поддержкой Samba и открытым портом 445. Исследователи предсказывали, что атаки на основе уязвимости SambaCry могут распространяться так же как WannaCry ransomware.

Предсказание оказалось довольно точным. Компьютер-приманка, созданный командой исследователей из «Лаборатории Касперского», подцепил вирус, который использует уязвимость SambaCry для заражения компьютеров Linux — загрузки инструкций и криптомайнера.

Специалист по безопасности Омри Бен Бассат независимо от «Лаборатории Касперского» также обнаружил этот вирус и назвал его «EternalMiner».

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

С использованием уязвимости SambaCry злоумышленники выполняют две служебные нагрузки в уязвимых системах:

(349d84b3b176bbc9834230351ef3bc2a — Backdoor.Linux.Agent.an) INAebsGB.so — обратная оболочка, обеспечивающая злоумышленникам удаленный доступ.
(2009af3fed2a4704c224694dfc4b31dc — Trojan-Downloader.Linux.EternalMiner.a) CblRWuoCc.so — бэкдор, который включает в себя утилиты для запуска CPUminer.

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

INAebsGB.so

Основная функциональность cblRWuoCc.so

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

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

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

Счёт хакеров по состоянию на 08.06.2017

Организаторы ботнета для майнинга на базе SambaCry уже заработали 98 XMR, стоимость которых сегодня составляет 5 380 долларов. Эта цифра постоянно растет с увеличением числа заражённых Linux-систем.

«В первый день они получили около 1 XMR (около 55 долларов по обменному курсу на 10.06.2017), но за последнюю неделю доход вырос до 5 XMR в день», — говорят исследователи.

Журнал транзакций со всеми доходами злоумышленников

Разработчики Samba уже исправили проблему в новых версиях Samba 4.6.4 / 4.5.10 / 4.4.14 и настоятельно призывают тех, кто использует уязвимую версию Samba, установить патч как можно скорее.

P.S. Другие интересные статьи из нашего блога:
→ Как принять закон или обработка данных в распределённых системах понятным языком
→ ТОП 100 англоязычных сайтов об IT
→ Балансировка нагрузки в Облаках
→ Лучшие игрушки для будущих технарей времён нашего детства (СССР и США)

Let's block ads! (Why?)

[Перевод] Интеграция React и DataTables — не так тяжело, как рекламируют

Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов

[Из песочницы] Диалектика нейронного машинного перевода

или Перерастает ли количество в качество

Статья по мотивам выступления на конференции РИФ+КИБ 2017.

Neural Machine Translation: почему только сейчас?

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

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

Прекрасно видно, что на радарах вплоть до недавнего времени нет ничего про нейронный машинный перевод – и вот в конце 2016 года свои новые технологии и системы машинного перевода, построенные на базе нейронных сетей, продемонстрировали сразу несколько компаний, среди которых Google, Microsoft и SYSTRAN. Они появились почти одновременно, с разницей в несколько недель или даже дней. Почему так?

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

В основе нейронного переводчика механизм двунаправленных рекуррентных нейронных сетей (Bidirectional Recurrent Neural Networks), построенный на матричных вычислениях, который позволяет строить существенно более сложные вероятностные модели, чем статистические машинные переводчики.

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

Для ускорения процесса разработчики используют GPU от NVIDIA, а Google также и Tensor Processing Unit (TPU) – чипы собственной разработки, адаптированные специально для технологий машинного обучения. Графические чипы изначально оптимизированы под алгоритмы матричных вычислений, и поэтому выигрыш в производительности составляет 7-15 раз в сравнении с CPU.

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

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

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

Качество перевода: чей BLEU score толще?

Попробуем понять, соответствует ли рост качества перевода накопленным ожиданиям и тому росту затрат, которые сопровождают разработку и поддержку нейронных сетей для перевода.
Google в своем исследования демонстрирует, что нейронный машинный перевод дает Relative Improvement от 58% до 87%, в зависимости от языковой пары, по сравнению с классическим статистическим подходом (или Phrase Based Machine Translation, PBMT, как его еще называют).

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

Качество перевода: есть ли прорыв?

Несмотря на то, что Google заявляет об улучшении на 60% и даже выше, в этом показателе есть небольшой подвох. Представители компании говорят о «Relative Improvement», то есть насколько им удалось с нейронным подходом приблизится к качеству Human Translation по отношению к тому, что было в классическом статистическом переводчике.

Эксперты отрасли, анализирующие результаты, представленные Google в статье «Google's Neural Machine Translation System: Bridging the Gap between Human and Machine Translation», достаточно скептически относятся к представленным результатам и говорят, что фактически BLEU score удалось улучшить только на 10%, а существенный прогресс заметен именно на достаточно простых тестах из Wikipedia, которые, скорее всего, были использованы и в процессе обучения сети.

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

Исходный текст (EN): Worrying never did anyone any good.
Перевод Google PBMT: Не беспокоясь не делал никому ничего хорошего.
Перевод Google NMT: Беспокойство никогда никому не помогало.

Кстати, перевод той же фразы на Translate.Ru: «Волнение никогда не приносило никому пользы», можно заметить, что он был и остался таким же и без использования нейронных сетей.

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

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

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

Машинный перевод: в чем задачи

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

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

К таким задачам можно отнести:

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

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

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

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

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

Кейс: Amadeus

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

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

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

→ Подробно задача и реализация проекта расписаны в документе.

Попробуем сравнить перевод, сделанный через PROMT Cloud API, интегрированный в Amadeus Fare Rules Translator, и «нейронный» перевод от Google.

Оригинал: ROUND TRIP INSTANT PURCHASE FARES

PROMT (Аналитический подход): ТАРИФЫ МГНОВЕННОЙ ПОКУПКИ РЕЙСА ТУДА И ОБРАТНО

GNMT: КРУГЛЫЕ ПОКУПКИ

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

Кейс: TripAdvisor

TripAdvisor один из крупнейших в мире туристических сервисов, который не нуждается в представлении. По данным статьи, опубликованной The Telegraph, ежедневно на сайте появляется 165,600 новых отзывов о различных туристических объектах на разных языках.

Задача перевод отзывов туристов с английского на русский язык с качеством перевода, достаточным для того, чтобы понять смысл этого отзыва. Основная сложность: типичные особенности user generated content (тексты с ошибками, опечатками, пропусками слов).

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

→ Подробнее почитать о проекте можно на сайте компании.

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

Посмотрим на примеры:

Оригинал: We ate there last night on a whim and it was a lovely meal. The service was attentive without being over bearing.

PROMT (Гибридный перевод): Мы ели там в последний вечер случайно, и это была прекрасная еда. Персонал был внимательным, но не властным.

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

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

Проблемы использования NMP для бизнеса

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

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

Для создания модели нужна база, где содержится минимум 100 млн. токенов (словоупотреблений), а чтобы получить перевод более-менее приемлемого качества – 500 млн. токенов. Далеко не каждая компания обладает таким объемом материалов.

• Наличие механизма или алгоритмов автоматической оценки качества получаемого результата.

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

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

Выводы

• В общем случае нейронный автоматический перевод дает результат более высокого качества, чем «чисто» статистический подход;
• Автоматический перевод через нейронную сеть – лучше подходит для решения задачи «универсального перевода»;
• Ни один из подходов к МП сам по себе не является идеальным универсальным инструментом для решения любой задачи перевода;
• Для решения задач по переводу в бизнесе только специализированные решения могут гарантировать соответствие всем требованиям.

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

Ссылки по теме

http://ift.tt/2qkZfnc
http://ift.tt/2d504iw
http://ift.tt/2dhsIei
http://ift.tt/2doC1ej
http://ift.tt/2eYrPpD
http://ift.tt/2mspRA0
http://ift.tt/2fbkJl5
http://ift.tt/2seDbPG
http://ift.tt/1LLXl83
http://ift.tt/2seBBgT
http://ift.tt/2sOpLam
http://ift.tt/2seRTWR

Let's block ads! (Why?)

[Перевод] Ruby on Rails соглашение. Часть 4

Цените интегрированные системы

Ruby on Rails можно использовать для разных целей, но его конек — это монолитные интегрированные системы. Такие системы нацелены на решение всей задачи совокупно. Через Rails проходит все, начиная от генерации JavaScript для мгновенного обновления страниц, и заканчивая миграцией базы данных от одной версии к другой, когда проект уже в эксплуатации.

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

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

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

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

Плохо, когда система преждевременно дробится на сервисы или, что еще хуже, на микросервисы. Бытует мнение, что при разработке «Современного Интернет-Приложения» неизбежно придется строить одну и ту же систему много раз: один раз на стороне сервера, один раз на стороне клиента в виде JavaScript MVC, по одному разу для каждой мобильной платформы, и так далее. Но это требование ничем не обусловлено, так делать совершенно необязательно!

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

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

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

Прогресс превыше стабильности

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

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

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

Это не некая вседозволенность причинять кому-то ненужную или чрезмерную боль. Большой Переход от Rails с версии 2.x до версии 3 все еще будоражит раны тех, кто был причастен к этому переходу. Это было тяжело. Серьезный переполох, который многих оставил на версии 2.x на долгое время, причем некоторых из них уже было оттуда не вернуть. Но, по великой схеме вещей, это все равно стоило того.

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

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

До сих пор мы очень хорошо справлялись с этим. С того момента, как я начал, мы прошли через Ruby версий 1.6, 1.8, 1.9, 2.0, 2.1, 2.2 и теперь на 2.3. Множество серьезных изменений произошло на этом пути, но Rails непосредственно присутствовал и участвовал в них, чтобы иметь под капотом Ruby, и помочь каждому быстрее осуществлять процесс разработки. Эта отчасти привилегия, а отчасти и обязательство Rails, является основой популяризации Ruby.

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

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

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

Возведите большую палатку

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

Именно по этому мы так не делаем!

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

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

По мере непрекращающегося развития RSpec, DSL для тестирования, я часто выражал серьезное недовольство, и это отлично иллюстрирует сказанное выше. Я могу разглагольствовать до посинения, так как не считаю Rspec серьезной перспективой, а он несмотря на это и процветал, и процветает как технология. И это гораздо важнее, нежели выбор какой-то одной, «единственно верной» технологии!

То же самое можно сказать о режиме Rails в качестве HTTP API. В то время, как я лично предан и сосредотачиваюсь на интегрированной системе, включающей в себя виды (представления), несомненно Rails может многое предложить и разработчикам, желающим разделить свое приложение на клиентскую и серверную часть (бекенд и фронтенд). Мы должны принять это, поскольку такие решения могут развиваться в Rails как второстепенные, и я уверен, что это возможно.

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

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

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

• Часть 1
• Часть 2
• Часть 3
• Часть 4

Let's block ads! (Why?)

[recovery mode] По щучьему велению… (язык программирования Pike)

Статья представляет собой очень краткое введение в Pike. Признайтесь — мало кто из вас слышал об этом языке. Однако язык Pike даже применяется в продакшене (для работы Opera в режиме Turbo).

Краткие характеристики:

— интерпретируемый (не будете думать чем бы заняться во время компиляции);
— cинтаксис: основанный на С (с минимальными отличиями);
— лицензия — GNU GPL, GNU LGPL and MPL;
— объектно-ориентированный;
— со сборщиком мусора (которому кстати, можно подсказывать если очень надо);
— …

История

Язык появился еще 1994 году. Автор Fredrik Hübinette. Предшественником считатся язык LPC (объектно-ориентированный язык на иснове языка C, созданный прежде всего для разработки игр — LPC Тут на самом деле интересная история — но копипастить вики не имеет смысла. Короче говоря, если бы не игры, не было бы языка.

Скажу сразу — с документацией не все в порядке. Далеко не все примеры (даже для новичков) будут работать (причем это может быть даже Hello world!).

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

Привет, мир!

Текст программы:

int main()
{
  write("Hello world!\n");
  return 0;
}

Сохраняем этот текст в hello.pike и запускаем в коммандной строке: pike hello.pike

Теперь с окошечком:

int main()
{
    GTK.setup_gtk(); 
    object w = GTK.AboutDialog();
    w.set_program_name("My GTK hello world program");
    w.signal_connect("destroy", lambda(){exit(0);});
    w.set_title("My first program"); 
    w.set_comments("Pike is a dynamic programming language with a syntax similar to Java and C. "+ 
        "It is simple to learn, does not require long compilation passes and has powerful built-in" +
            "data types allowing simple and really fast data manipulation.");  
        array(string) arr1=({"Mr. Smith", "and others"});
        array(string) arr2=({"Mrs. Smith", "and others"});      
    w.set_authors(arr1);
        w.set_artists(arr2);
    w.show_now();
    
  return -1;
}

Как видим, работа идет через GTK. Возврат -1 из функкции main нужно для того чтобы программа сразу не прекратила работу, иначе окошечка не увидите. Выход и программы происходит по кнопке закрытия окна с помощью прикрепленной лямбда-функции lambda(){exit(0);}

В официальном туториале для этого применяют GTK.Alert(«Hello world!»), но однако у меня такое не заработало (версия 8.0) — видимо туториал устарел.

Структуры данных:

Синтаксис работы с основными структурами данных радует.

Массивы:

int main()
{
    array(string) arr1 = ({ "red", "green", "white" });
        write(arr1);
        write("\n");
        array(string) arr2 = ({ "red", "green", "yellow" });
        write(arr2);
        write("\n");
        write(arr2 + arr1);  //просто все элементы двух массивов 
        write("\n");
        write(arr2 & arr1);  //пересечение 
        write("\n");
        write(arr2 | arr1);  //объединение множеств 
        write("\n");
        write(arr2 ^ arr1);  //xor - т.е. только те элементы которые не являются общими 
        write("\n");
        write(arr2 - arr1);  //разность 
        write("\n");
    
  return 0;
}

Результат:

redgreenwhite
redgreenyellow
redgreenyellowredgreenwhite
redgreen
redgreenyellowwhite
yellowwhite
yellow

Maps:

int main()
{
    mapping map2 = (["red":4, "white":42, "blue": 88]);
    mapping map1 = (["red":4, "green":8, "white":15]);  
        
    print_map(map2 + map1);
    print_map(map2 - map1);
    print_map(map2 & map1);
    print_map(map2 | map1);
    print_map(map2 ^ map1);
    
    return 0;
}

void print_map(mapping m){
    array(string) arr;
    arr = indices(m);
    foreach(arr, string key){
        write(key + ":" + m[key] + " ");    
    write("\n");
}

Результат:

red:4 green:8 white:15 blue:88
blue:88
red:4 white:15
red:4 white:15 green:8 blue:88
green:8 blue:88

Есть еще так называемые multiset. По сути тоже что mapping, но без значений:

int main(){
    multiset o = (< "", 1, 3.0, 1, "hi!" >); 
    print_multiset(o);  
    return 0;
}

void print_multiset(multiset m){
    array(string) arr;
    arr = indices(m);
    foreach(arr, string key){
        write(key + ":" + m[key] + " ");
    };
    write("\n");
}

Результат:

1:1 1:1 3.0:1 :1 hi!:1

Объекты

class car {    
    public string color;
        public string mark;
        private string driver;
        
        void create(string c, string m, string d){      
            color = c;
                mark = m;               
                driver = d;
        }
        
        string who(){
            return mark + " " + color + "\n";
        }       
}

int main(){
    car car1 = car("red", "vaz", "Mike"); 
    write(car1.who());  
        
    car car2 = car("green", "mers", "Nik");
    write(car2.who());          
    write(car2.mark);
        
    return 0;
}

Результат:

vaz red
mers green
mers

Метод create играет роль конструктора. Есть и модификаторы доступа. Но будьте осторожны с модификатором static. Мало того что он означает совсем не то, что вы подумали — он еще и depricated.

Связь с Java

А теперь дернем код Java (а почему и нет если можем?):

int main()
{
    float pi = Java.pkg.java.lang.Math.PI;
        write("Pi = " + pi + "\n");
        
        object syst = Java.pkg.java.lang.System;
        write("time = " + syst.currentTimeMillis() + "\n");
        
        object str = Java.pkg.java.lang.String("...Hello!..."); 
        write((string)str.substring(3,str.length()-3) + "\n");
        
        object map2 = Java.pkg.java.util.HashMap(); 
        object key = Java.pkg.java.lang.String("oops");         
        object val = Java.pkg.java.lang.String("ha-ha");        
        map2.put(key, val);
        write((string) map2.get("oops") + "\n");
        
        object map = Java.JHashMap(([ "one":1, "two":2 ]));   
        write((string) map.get("two") + "\n");
    
  return 0;
}

Как видно из примера, обращение к классам Java идет через Java.pkg. При печати надо не забывать приводить объекты Java к строке с помощью (string). Можно вызывать обычные методы Java. Как видно из примера, для HashMap есть даже специальная конструкция для облегчения работы (что, впрочем, неудивительно).

Работа с интернетом

Скачаем страничку с интернета и выведем в консоль:

int main()
{
    Protocols.HTTP.Query web_page;
    web_page = Protocols.HTTP.get_url("http://ift.tt/2soNznM");
    string page_contents = web_page->data();  
    write(page_contents);    
    return 0;
}

Щука помнит об СССР:

int main(){
    Geography.Countries.Country c = Geography.Countries.USSR;   
    write(c.name + "\n");    
    return 0;
}

Отступление от темы

(Готовя этот материал, параллельно экспериментировал с задачей определения страны по IP адресу — по своему адресу конечно. И вздрогнул когда перепутал программы и мне в ответ пришло «USSR»).

Заключение

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

Ссылки

→ Главная
→ Википедия (англ)
→ Статья об языке
→ github
→ Roxen (веб-сервер на Pike)

Let's block ads! (Why?)

Красно-черные деревья: коротко и ясно

Всегда ли надежно шифрование или восстановление данных с внешнего жесткого диска Prestigio Data Safe II

[recovery mode] Без правок. Как стать самым счастливым дизайнером на планете

Решение линейных диофантовых уравнений с любым числом неизвестных

Наивно. Супер. Рецензия на книгу Джина Желязны «Говори на языке диаграмм»

Книга "Say It With Chart" (дословно «Скажи это с помощью диаграммы») написана более 30-ти лет назад (в 1985 году!), однако и сегодня пользуется интересом. Она переведена на главные мировые языки, переиздается вновь и вновь, бизнесмены, маркетологи, аналитики считают её настольной книгой и в 2017-м.
Книгу интересно читать, в ней много полезного, но это было ожидаемо. Неожиданностью стал недостаток информации о её авторе в сети (которому принадлежит еще несколько мировых бестселлеров). О Джине Желязны нет статьи в Википедии (ни на английском, ни на русском), на запросы типа «биография Дж. Желязны» или «кто такой Дж. Желязны» выдаются бесчисленные сайты с одним и тем же текстом — аннотацией к книге «Говори на языке диаграмм». А это, согласитесь, только усиливает интерес, поэтому рецензия будет состоять из двух частей: «О книге» и «Кто такой Джин Желязны?».

О книге

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

Главная идея сформулирована в самом начале:

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

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

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

В оригинале используется игра слов: «It wasn’t always like that. I entered the field of visual communications in the year 1961 B.C. That’s Before Computers, Before Calculators, Before Copiers». B.C. = Before Christ = до рождества Христова, то есть до н.э. Before Computers, Before Calculators, Before Copiers.

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

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

Часть I — описание процесса преобразования данных в диаграммы. Читателю предлагается пройти следующий путь:

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

Джин Желязны уточняет:

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

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

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

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

• Круговая диаграмма – самый непрактичный тип диаграмм.
• Помещать на круговой диаграмме не более 6-ти компонентов, в идеале – 5 самых важных, остальные сгруппировать в один сектор с названием «прочее».
• Самый главный сектор круговой диаграммы должен идти от линии 12-ти часов циферблата (сверху вправо), он должен быть самым контрастным.
• Не использовать на линейчатой диаграмме и гистограмме одновременно подписи на шкале и у столбца.
• На диаграммах использовать целые числа, избегая дробей.
• Координатная сетка не должна быть яркой. «Координатная сетка как линии футбольного поля; нужны, чтобы судьи могли выполнять свои функции, а не чтобы привлекать внимание зрителей».

Первую часть автор заканчивает тем, что

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

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

Часть II посвящена использованию 5 типов диаграмм для передачи соответствующих идей. На 44 страницах автор последовательно комментирует и подробно разбирает 80 примеров диаграмм разного вида. Материал помогает углубиться в перечисленные в первой части типы визуализации данных. Автор приводит иллюстрации (примеры диаграмм), комментирует их, сравнивает с другими.

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

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

По мнению автора, для проверки эффективности выбранного варианта диаграммы нужно убрать шкалы:

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

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

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

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

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

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

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

Кто такой Джин Желязны?

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

На его персональном сайте говорится, что он работает директором по визуальным коммуникациям в McKinsey & Company (консалтинговая фирма существует с 1926 года!), выступает с лекциями и тренингами в ведущих бизнес-школах Америки и Европы. Его книги: «Говори на языке диаграмм» (Say It With Charts), «Говори на языке презентаций» (Say It With Presentations), сейчас идет работа над «Говори на языке воображения» (Say It With Imagination).

Интересно противопоставление взглядов Дж. Желязны и Эдварда Тафти.
Желязны защищает PowerPoint и доказывает, что инструмент может быть очень полезным в визуальной коммуникации. Он пишет:

«Думаю, что все вы знаете о жарких спорах экспертов бизнес-коммуникации вокруг PowerPoint. Наверное, нет другого такого софта, вокруг которого было бы столько эмоций. Иногда даже кажется, что противники застрелят друг друга пунктами списков (bullet points — «пули пункты»). Громче всех, конечно, «выстрелы» критиков. Один из главных, профессор Университета Йеля Эдвард Тафти, утверждает, что PowerPoint провоцирует людей на создание пошлого, тривиального контента и сильно «засоряет» серьёзную коммуникацию. «Совещания должны фокусироваться на кратких письменных отчетах на бумаге, а не на тезисах или обрывочных пунктах списка, проецируемых на стену», — считает Тафти в своей работе «Когнитивный стиль PowerPoint».

Далее Желязны доказывает пользу самой популярной программы для создания презентаций, приводя свой вариант визуализации карты похода Наполеона на Москву (Charles Joseph Minard (1781–1840)) — той самой карты, которую Тафти называет одним из лучших примеров информационной графики, — сделанные в PowerPoint.

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

У него есть книга мемуаров «В одно мгновение» (In The Moment), в которой он делится эпизодами своей жизни.
Вступление к книге:

«Если бы вы были восьмилетним ребёнком и видели, что ваших друзей куда-то забирают нацисты, то вы бы подумали, что Париж — это плохое место пребывания в 1942 году. Если бы вы носили Звезду Давида, то так оно и было. Переход от измученной Европы к энергичной, трепещущей Америке также не всегда воспринимался легко. Школа в Бронксе (на уличный манер «Da Bronx»), колледж, служба в ВВС и, наконец, корпоративная Америка — мир крупного бизнеса. Большие шаги и отсутствие матери, которая могла бы вести тебя. Для начала Жанно стал Джином, автором этих сверкающих, разоблачающих, дерзких, тонких, мудрых, острых, терпимых, любопытных, гениальных, грустных и веселых, хитрых и прямолинейных эссе без границ. Джин, мы готовы развлекаться и удивляться всему тому, что ты должен сказать, и неизменно восхищаться твоими идеями».

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

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

Let's block ads! (Why?)

Security Week 23: EternalBlue портировали на Win10, ЦРУ атакует с файлсерверов, маркетологи незаметно заразили весь мир

Приключения EternalBlue продолжаются: теперь исследователи из RiskSense портировали его на Windows 10. На первый взгляд это деструктивное достижение, однако же, именно в этом состоит немалая часть работы исследователя-безопасника. Чтобы защититься от будущей угрозы, сначала надо эту угрозу создать и испытать, причем крайне желательно сделать это раньше «черных шляп».

Ранее RiskSense разработали EternalBlue-модуль для Metasploit, который отличается от оригинала тем, что его гораздо хуже детектят IDS. Из него выкинули имплант DoublePulsar который слишком хорошо изучен и не особо умеет скрываться на машине, демаскируя атаку. Вместо него исследователи разработали собственный шеллкод, который способен загрузить нужную нагрузку напрямую.

Исходный EternalBlue, как и его модуль для Metasploit, работает лишь на Windows 7 и Windows XP, а также на Windows Server 2003/2008 R2. В своем отчете компания подробно анализирует все цепочку багов, используемых эксплойтом, и из документа видно, что к подобной атаке уязвимы все системы на базе ядра NT – однако выручают защитные технологии, часть из которых EternalBlue обходить умеет, часть – не очень.

Старший аналитик компании Шон Диллон высказался в духе, что атаки такого типа (heap spray) на ядро Windows – «почти чудо», настолько трудоемка их разработка, в отсутствие доступных исходников ОС. Поэтому такую же атаку для Linux разработать было бы проще.

Исследователи же создали версию, успешно атакующую Windows 10 x64 версии 1511 (Threshold 2), для чего понадобилось разработать новый способ обхода DEP. Особо отмечено, что на других версиях Win10 новый эксплойт не работает. Но принцип атаки понятен, понятна и его широкая применимость. Ждем волны WannaCry под Windows 10?

Опубликована документация на имплант ЦРУ для заражения сетей

Новость. Американское разведсообщество все больше «радует» мировое сообщество информационной безопасности. То ли АНБ соревнуется с ЦРУ в эдаком хитром пиаре, то ли в обеих организациях завелись последователи Сноудена – столь же идейные, но, все же, более осторожные.

В прошлый четверг на WikiLeaks появилась публикация о разработанном в ЦРУ импланте, превращающем файлсервер под Windows в точку распространения вредоносных программ по локальной сети. Инструмент, скромно названный Pandemic, подменяет запрашиваемые машинами с файлсервера файлы троянизированными версиями. Согласно документации, Pandemic 1.1 умеет подменять до 20 различных файлов объемом до 800 Мб.

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

Очевидно, заражение машины-клиента происходит в том случае, если файл с сервера будет запущен, то есть в первую очередь опасны исполняемые файлы. Однако нельзя исключать применение Pandemic с эксплойтами, например, для Microsoft Office – в этом случае заражение будет распространяться и через документы.

Китайский зловред заразил 250 миллионов компьютеров по всему миру

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

Rafotech придумала собирать ее с помощью троянца. Зловред Fireball заражает компьютер жертвы очень простыми методами – его устанавливают более-менее легитимные программы (так называемое crapware) самой Rafotech и ее коллег, также его можно получить в спаме. Казалось бы, не самые мощные каналы распространения, однако же, по данным CheckPoint, троянец инфицировал более 250 миллионов компьютеров по всему миру.

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

На своем сайте Rafotech заявляет, что ею «охвачено более 300 миллионов пользователей». Ну, теперь мы знаем, что это похоже на правду. Таки охвачено. Однако тревожит, что речь не только об индивидуальных пользователях – в CheckPoint посчитали, что Fireball поражены 20% корпоративных систей в мире. Потенциально это дает боевым маркетологам поистине устрашающие возможности, и не только по показу рекламы.

Древности

«Find-1575»

Неопасный резидентный вирус. Записывается в COM- и EXE-файлы при их старте и при поиске файлов в каталогах (функции DOS FindFirst и FindNext FCB). При некоторых условиях по экрану начинает ползать «зеленая гусеница». Перехватывает int 1Ch, 21h

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 67.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Let's block ads! (Why?)

О новых интересных законах или «Тварь ли я дрожащая или всё-таки сообщество»

[Из песочницы] Xenoblade Chronicles — разбор игровых данных

Всем привет! Меня зовут Артем, в тырнетах более известен под идиотским ником TTEMMA, но не суть. Я являюсь одним из основателей любительской группы переводчиков Russian Studio Video 7 и единственным ромхакером-программистом в данной команде.

Мы с командой первые, кто смог подарить фанатам Resident Evil переводы двух культовых игр на Nintendo GameCube – Resident Evil Remake и Resident Evil Zero, когда-нибудь я расскажу о том, как мы все это делали, но в данной теме я бы хотел рассказать о такой роскошной игре, как Xenoblade Chronicles на Nintendo Wii и о том, как происходил и далее происходит ромхак данной игры. В данной игре всё сделано в японском стиле, странно и в некоторых моментах просто задаёшься вопросом — «Зачем?», но потом вспоминаешь, на сколько японцы странные люди и эти вопросы отпадают. Ну что ж, начнём?

Предисловие

Xenoblade Chronicles эта та игра, из-за которой стоит, нет, даже нужно приобрести Nintendo Wii. JRPG, большой открытый мир, куча вспомогательных квестов и захватывающий сюжет, который затянет прохождение игры не на недели, а на месяца. Все, кто знаком с Nintendo Wii, знает, что консоль предназначена для слабеньких красочных семейных игр по типу Super Mario и т.п, но то, что сотворили Monolith Soft достойно похвалы, их Xenoblade Chronicles обладает прекрасной и красивой графикой, не смотря на огромные технические ограничения консоли(посоревноваться в плане графики может только Resident Evil Remake и Resident Evil Zero).

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

Технические нюансы

Немного расскажу о самой Wii и о том, о чем речь в данной теме не пойдёт.

Что Nintendo GameCube, что Nintendo Wii работает на процессоре от IBM с архитектурой PowerPC. Данный процессор работает в Big-Endian режиме, это важно запомнить(как по мне, хакинг файлов Big-Endian намного удобнее, чем Little-Endian из-за порядка байтов).

Благо, Nintendo сильно позаботились о разработчиках игр и в своих SDK предоставили просто огромное количество форматов для любой цели, именно о них речь в данной теме и не пойдёт. Может быть я потом и расскажу о них подробно, но моя лень вряд ли позволит. Выделить из форматов Nintendo я хочу лишь один – BRFNA (Binary Revolution Font), о нём и пойдёт дальше речь.

Шрифт

Шрифт в Xenoblade Chronicles(далее XC) хранится в стандартном, но редко используемом в играх формате с расширением BRFNA.

Существует лишь два стандартных для Wii формата шрифта:

1. BRFNT(более популярный)
2. BRFNA(редко используемый)

Я не буду углубляться в их структуру, а лишь расскажу о различиях:

• В BRFNA был добавлен новый блок, хранящий в себе информацию о кодировке(ansi, kanji, european и т.д.)
• В BRFNA текстуры с символами сжаты неизвестным мне форматов, в то время как в BRFNT они лежат в открытом виде и спокойно редактируются.

BRFNA успел доставить много проблем, во первых – неизвестный тип сжатия, во вторых – слегка странное разделение по кодировкам. Спас нас из этой ситуации, как ни странно, официальный конвертер шрифтов из 3DS SDK от Nintendo. Но и с ним появились проблемы, пришлось изучать используемые кодировки в самом XC, писать отдельные конфигурационные файлы для конвертера текстур и поиграться с настройками самого конвертера, чтобы шрифт был идентичен оригиналу. И о благо, после нескольких дней мучений я смог вывести русские буквы с использованием русских кодов символов из UTF8.

Правда, игра долго упиралась из-за размера нового шрифта и крашилась в самом начале загрузки игры. Сначала были подозрения, что мои кривые руки делают что-то не так, но после того, как я убрал умляуты из шрифта, то игра спокойно запустилась. Но убирать умляуты я категорически не хотел, поэтому подошёл с другой стороны, я просто изменил формат текстур c IA4(4 бита на цвет, 4 бита на прозрачность) на просто I4(4 бита на цвет, без прозрачности) и вуаля, XC взлетела как миленькая.

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

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

PKB\PKH – контейнеры файлов

Что-то начал я свой рассказ совсем не с того. Чтобы добраться до многих основных файлов, придётся их как-то извлечь из контейнера PKB.

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

Пример PKB

Самое же интересное хранится в PKH файлах, но и чтобы добраться до них придётся постараться. Все PKH файлы находятся в отдельном для каждого языка U8 архиве с именем static.arc.

STATIC.ARC английского языка

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

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

PKH можно поделить на 2 блока: Header и Entry, что я и сделал.

public class pkhModuleEntry
    {
        public uint ID;
        public uint unk;
        public ushort sizeFile;
        public uint offsetFile;

        public pkhModuleEntry()
        {
            ID = unk = offsetFile = sizeFile = 0;
        }

    }

public class pkhModule
    {
        uint Magic;
        uint version;
        uint tableOffset;
        uint pkhSize;
        uint countFiles;
        pkhModuleEntry[] entry;
        string[] extensions;
        ...
    }

Entry у нас начинается с указателя tableOffset. Только вот проблема в том, что entry разделено ещё на несколько блоков, загрузка всей информации о файлах происходит таким образом:

for (int i = 0; i < countFiles; i++)
            {
                entry[i] = new pkhModuleEntry();
                entry[i].ID = mainPkhSfa.ReadUInt32();
                entry[i].unk = mainPkhSfa.ReadUInt32();
            }

            for (int i = 0; i < countFiles; i++)
                entry[i].sizeFile = mainPkhSfa.ReadUInt16();

            for (int i = 0; i < countFiles; i++)
                entry[i].offsetFile = mainPkhSfa.ReadUInt32();

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

1. Индексы файлов и неизвестные значение
2. Размеры файлов
3. Указатели на файлы

Можно заметить, что указатель на определённый файл хранится в uint32, то есть в 4-байтной переменной, а вот размер, почему-то, в 2-байтной. Объясню данный изъян, как я говорил выше, в PKB файлы выравнены по 2048 байт и это сделано не спроста. Размер файла указывается не в байтах, а в количестве данных блоков. К примеру, размер файла указан 0xC, следовательно размер в PKB будет 0xC * 0x800 = 0x6000.

Пример PKH

Изучив данную структуру был быстро наклёпан распаковщик\запаковщик и я приступил к изучение контейнеров, хранящих в себе текст.

Контейнеры с текстом

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

1. Контейнер BDAT – хранит в себе какие-то данные и строки, приоритетно системные (меню, торговля, настройки).
2. Контейнер SB – хранит в себе скрипты и строки с разговорами с жителями.
3. Контейнер REV – хранит в себе данные и строки, используемые в кат-сценах.

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

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

Контейнер BDAT

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

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

К сожалению, Dolphin обладает хреновеньким дебаггером(либо я просто зажрался и привык к дебаггеру PCSX, где есть все возможные функции для дебагга). Мне надо было выяснить, в какой области памяти расшифровывается BDAT и поставить там брик на запись, но, Dolphin умеет ставить бряк только на команду по адресу, но на чтение\запись из опр. участка RAM не умеет, это стало проблемой. Начались поиски Dolphin с дополненными функциями для дебагга и таковой был найден — Dolphin DebugFast на основе 4 версии, в него добавлена лишь одна особенность — брик на чтение\запись в RAM, то что нужно, подумал я и приступил к дальнейшему хаку.

Найдя в памяти участок с нужными мне данными, я поставил брик и начал изучать, как же игра расшифровывает свои BDAT. Всё оказалось просто и в тоже время интересно. В BDAT есть 2 байтовый ключ, первый байт грузится в регистр R5, второй в R0 соответственно, так же есть булевая переменная, которая в начале расшифровка устанавливается в 1(true).

Если булевая переменная установлено в 1, то расшифровка происходит с помощью регистра R5, если же в 0, то расшифровка происходит с помощью регистра R0.

Шифрование же основано на простом XOR, порядок расшифровка таков:

1. Зашифрованный байт = Зашифрованный байт ^ R(5 или 0)
2. R(5 или 0) = (Зашифрованный байт + R(5 или 0)) & 0xFF
3. Смена булевой переменной на противоположное значение

Код на C#:

public static void BDAT_DecryptPart(int offset, int size, ushort key, MemoryStream data)
        {
            data.Position = offset;
            int endOffset = offset + size;
            if (endOffset > data.Length)
                endOffset = (int)data.Length;

            bool reg = true;
            byte _r0 = (byte)(0xFF - (key & 0xFF));
            byte _r5 = (byte)(0xFF - (key >> 8 & 0xFF));
            byte inByte = 0;

            while (offset < endOffset)
            {
                inByte = data.GetBuffer()[offset];
                if (reg)
                {
                    data.GetBuffer()[offset] = (byte)(inByte ^ _r5);
                    _r5 = (byte)((_r5 + inByte) & 0xFF);
                    reg = false;
                }
                else
                {
                    data.GetBuffer()[offset] = (byte)(inByte ^ _r0);
                    _r0 = (byte)((_r0 + inByte) & 0xFF);
                    reg = true;
                }
                offset += 1;
            }
        }

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

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

Примерчик

Зашифрованный блок с 0x2C — 0x66.

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

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

class header
    {
        public uint magic;
        public byte mode;
        public byte unk;
        public ushort offsetToNameBlock;
        public ushort sizeTableStruct;
        public ushort unkTableOffset;
        public ushort unk2;
        public ushort offsetToMainData;
        public ushort countEntryMain;
        public ushort unk3; public ushort unk4;
        public ushort cryptKey;
        public uint offsetToStringBlock;
        public uint sizeStringBlock;
        ...
   }

• Magic — константа и всегда равна BDAT(ansi)
• Mode — 1: нет шифрования, 3: имеется шифрование
• unk — как понятно, неизвестно, но данный байт всегда равен нулю
• offsetToNameBlock — указатель на зашифрованный блок с именами блоков
• sizeTableStruct — размер одного блока со всеми данными
• unkTableOffset — указатель на таблицу, которую до конца я разобрать не смог
• unk2 — неизвестно, но всегда равен 0x3D
• offsetToMainData — указатель на блок, содержащий все данные
• countEntryMain — количество блоков по указателю offsetToMainData (размер блока MainData можно просчитать таким образом: sizeTableStruct * countEntryMain)
• unk3 — неизвестно, всегда 0x01
• unk4 — неизвестно, всегда 0x02
• cryptKey — 2-х байтный ключ для расшифровки
• offsetToStringBlock — указатель на блок с текстом
• sizeStringBlock — размер блока с текстом(равен 0, если текста нет)

После Header до offsetToNameBlock идут неизвестные данные, как выяснилось это информация о блоках в MainData и имеет данную структуру:

class typeStruct
    {
        public byte unk;
        public byte type;
        public ushort idx;
        ...
    }

• unk — неизвестно
• type — тип данных
• idx — указатель в MainData(точный указатель просчитывается таким образом: offsetToMainData + (IndexStructure * sizeTableStruct) + idx

И остался последний блок — offsetToNameBlock, он имеет такую структуру:

class nameBlock
    {
        public string bdatName;
        public nameBlockEntry[] nameEntry;

        public nameBlock(StreamFunctionAdd sfa, int countName)
        {
            bdatName = sfa.ReadAnsiStringStopByte();
            sfa.SeekValue(2);

            nameEntry = new nameBlockEntry[countName];

            for (int i = 0; i < countName; i++)
            {
                nameEntry[i] = new nameBlockEntry(sfa);
            }
        }
    }

    class nameBlockEntry
    {
        public ushort offsetToStructType;
        public ushort unk;
        public string name;
        public typeStruct type;

        public nameBlockEntry(StreamFunctionAdd sfa)
        {
            offsetToStructType = sfa.ReadUInt16();
            unk = sfa.ReadUInt16();
            name = sfa.ReadAnsiStringStopByte();

            type = new typeStruct(sfa, offsetToStructType);

            sfa.SeekValue(2);
        }
    }

Хочу выделить только переменную countName, которой нет нигде в Header, но просчитывается она путем отнимания указателя на NameBlock 0x20 и делением данного числа на 4. Объясню почему: Header кончается по адресу 0x20, NameBlock начинается далеко после Header, а как мы знаем, сразу после Header идёт информация о структурах блоков в MainData, которая занимает 4 байта на структуру. И вот чтобы узнать кол-во таких структур, нужно узнать размер только информации о структурах и поделить на их размер, то есть 4.

Кажется, на первый взгляд, сложным строением, но попробую объяснить по другому:

Есть блок, где хранятся все данные — MainData. Данный блок поделён на несколько блоков, количество которых описано переменной countEntryMain, а размер одного такого блока описан переменной sizeTableStruct. А вот какие данные хранятся в одном таком блоке уже описывается с помощью класса typeStruct, количество которых может быть от 1 до нескольких. Для каждой typeStruct есть название, которое храниться в nameBlockEntry.

Вот и всё, BDAT разобран был наклёпан софт для извлечения\замены текста, который успешно пашет.

Пример извлечённых строк из BDAT

Заключение

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

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

Спасибо за уделённое время!

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

Let's block ads! (Why?)

Гейзенбаг 2.0: как прошла в Петербурге конференция по тестированию

В Москве конференция Гейзенбаг уже проходила в декабре 2016-го, а теперь впервые добралась до Петербурга. Суть у Гейзенбаг 2017 Piter осталась прежней: «конференция о тестировании, но не только для тестировщиков». А изменились ли детали? Какие доклады были в этот раз? Правда ли, что Илари Хенрик Эгертер сбрил свою удивительную бороду? Ответы на все эти важнейшие вопросы — под катом.

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

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

А Илари говорят ненастоящий - бороды то нет. Ну почти нет :) @ilarihenrik, where is your beard?#heisenbughttp://pic.twitter.com/YCWQET07Bk

— Maxim Shulga (@maxbeard12) June 4, 2017

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

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

После Илари все разошлись по трём залам — и обо всех последовавших докладах не расскажешь, но кое-что опишем. Очень широко в программе была представлена автоматизация тестирования — что, пожалуй, логично в случае мероприятия «и для тестировщиков, и для разработчиков». И известный многим по подкасту Radio QAАлексей Виноградов, занявший главный зал после Илари, повёл речь как раз об улучшении автотестов, начав с ироничного дисклеймера: «В принципе, доклад могут понять все, потому что я говорю на русском языке, а в примерах кода будут знакомые символы от A до Z, но рассчитан он на тех, кто уже занимался автоматизацией тестирования». Другой его запоминающейся фразой стала «Горжусь тем, что после многих лет работы программистом улучшил свой уровень и смог стать тестировщиком» — действительно, пока некоторые разработчики смотрят на тестирование сверху вниз и ощущают его примитивной работой, тот же Гейзенбаг показывал, насколько это далеко от правды.

Алексей стал разбирать конкретные примеры, начав «предположим, что у нас стоит задача протестировать Amazon, и первым делом проверим авторизацию». Зрители с интересом следили за его предложениями по улучшению тестов, однако выяснилось, что не все согласны с его подходом. Как только дело дошло до вопросов из зала, микрофон оккупировал другой спикер, Николай Алименков, и стал напористо расспрашивать об опыте Алексея: работал ли он когда-либо в проектах, где автотесты писало сразу много людей, и долгосрочными ли были эти проекты?

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

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

Пока в главном зале кипели эти страсти, всё было гораздо спокойнее в третьем, где Марк Филипп рассказывал про особенности JUnit 5 (который после долгого периода Milestone-версий этим летом должен наконец дойти до релиза). У этой версии популярнейшего фреймворка интересная история появления: деньги на её прототип решили собрать с помощью краудфандинга, оплатив так работу двух разработчиков на протяжении шести недель, и удалось собрать 219% от требовавшейся суммы. Становилось интересно узнать непосредственно от главного организатора этой кампании: означает ли этот успех, что open source-сообществу вообще стоит активно использовать краудфандинг? Сам доклад был техническим, и там времени на подобные подробности не было, но в интервью для онлайн-трансляции расспросили Марка об этом. Оказалось, что краудфандинговая кампания требует приложить много сил, от разработки системы наград для участников до правильного юридического оформления. А значит, хотя рабочее время разработчиков с её помощью оплатить удалось, следует учесть, что для такого требуется и затратить немало времени.

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

А Дэн Куйаяр, на прошлом Гейзенбаге рассказавший о своём Appium и занявший третье место по оценкам зрителей, теперь снова говорил о нём, но уже под другим углом. Appium давно используется для тестирования мобильных приложений, а недавно стал поддерживать также приложения для Windows и Mac, и в выступлении был сделан акцент на этом.

Неудивительно и то, что про анализ результатов нагрузочного тестирования рассказывал Алексей Лавренюк: он отвечает за Яндекс.Танк. От такой темы ожидаешь, что она сама загрузит слушателей, но среди технических рассуждений «по числам похоже, что работает только одно ядро процессора, и вот как можно это проверить» нашлось место и очень доступной метафоре. Это была история из личного опыта: «Мы с большой компанией оказались в баре, и хотя многие заказали просто виски, а барменов было несколько, заказы выполнялись очень долго. Потому что все заказы сложили в общую очередь, а на коктейли уходит куда больше времени, чем на виски, и все бармены застряли на коктейлях. Чтобы справиться с этой проблемой, можно разделять тяжёлые и лёгкие запросы в разные очереди».

Наконец, завершал конференцию кейноут Николая Алименкова с подробным разбором ряда паттернов проектирования (любопытно, что при интересе к ним знаменитую книгу от «Gang of Four» он назвал «хорошей для того, чтобы засыпать»). Николай, разумеется, первым делом решил разобраться с доводами Алексея Виноградова: «Поднимите руки, у кого в проекте больше трёх человек пишут функциональные автотесты. А теперь те, у кого больше пяти. Так, треть зала уверенно подняла руки! Говорите, блефуют? К сожалению, у меня нет инструмента проверить их на этот блеф».

Кто из Николая и Алексея прав? Решать вам — а мы за плюрализм мнений и за то, чтобы давать вам увидеть ситуацию с разных сторон. Будем ждать вас в декабре Москве на следующем Гейзенбаге, который станет двухдневным, а на прощание покажем, что происходит, когда зовёшь выступать на конференцию специалиста по security testing из Google:

Что может сделать профессионал в безопасности (@paradoxengine) с системой управления лифтом за 5 секунд #heisenbughttp://pic.twitter.com/gAzyNnge4H

— SQA underhood (@sqaunderhood) June 4, 2017

Let's block ads! (Why?)

Третья IT-конференция GeekDay — три дня бесплатных мастер-классов по программированию

Новость для тех, кто мечтает получить IT-профессию: с 22 по 24 июня пройдёт онлайн-IT-конференция GeekDay #3. За это время вы сможете прослушать 20 бесплатных мастер-классов по различным сферам программирования и разработки.

Что вас ждёт на третьем GeekDay?

1. Вы узнаете, как разработать и кастомизировать Android-приложение, как создать несколько приложений под iOS и 2D-игру. Поймёте, как сделать код лаконичным и красивым.
2. На мастер-классах вы сможете пообщаться с профессиональными практикующими программистами уровня Senior. У каждого спикера — профильное образование, солидный стаж работы по специальности и большой опыт разработки сервисов и приложений для крупных компаний (Mail.Ru Group, МегаФон, Билайн).
3. Общение и обмен опытом со специалистами поможет вам сформулировать идею и реализовать свой проект.

Спикеры конференции:

• Сергей Камянецкий, Senior C# Developer. Вместе с Сергеем вы разработаете 2D-игру и узнаете, как научить игровые объекты взаимодействию с пользователем и друг с другом.
• Юрий Жайворонок, Senior Web Developer Mail.ru Group, работал над «HYKL» вместе с Berkeley University. Расскажет, как обычному программисту добиться успеха в IT-сфере.
• Евгений Картавец, Senior .Net Developer, Team Lead, руководитель отдела обучения GeekBrains. Научит основам ООП и даст рекомендации для дальнейшего развития.
• Игорь Филимонов, глава департамента веб-разработки в МакроИндекс. У него вы научитесь хитростям работы с CMS-платформами и за час создадите свой блог.
• Алексей Кадочников, профессиональный веб-разработчик. На его лекции вы узнаете, как сделать из фиксированного макета адаптивный, и сможете применить знания на практике.
• Кирилл Лукьянов, профессиональный iOS-разработчик с опытом в IT-сфере более 13 лет. Научит создавать Task-лист и iOS-приложение для видео-стриминга.
• Александр Фисунов, разработчик ПО с многолетним опытом работы в крупных проектах. Расскажет о возможностях Java — самого популярного языка программирования в мире.
• Александр Ерофеев, сотрудник, преподаватель и аспирант СпбПУ. Расскажет, как при помощи HTML/CSS создавать сайты, приложения, презентации и другие IT-объекты.
• Владимир Языков, профессиональный веб-разработчик с опытом реализации крупных проектов. Вы узнаете о методологии БЭМ и сможете избежать классических для новичка ошибок.
• Василий Дерябин, создатель и управляющий партнёр в веб-студии «Visario.ru». Научит вас создавать продающие лэндинги для стартапов без навыков программирования.
• Роман Муратов, профессиональный C#-разработчик. Расскажет об взаимодействиях с игровыми объектами и особенностях реализации игрового инвентаря.
• Юрий Афанасьев, Senior PHP Developer в «Alpari». Вы узнаете о способах сделать код лаконичным и красивым и получите советы для развития с нуля до уровня Senior.

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

Зарегистрироваться для участия в конференции или просмотра трансляции можно на сайте конференции. Ждем вас!

Let's block ads! (Why?)