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

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

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

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

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

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


— Меня зовут Костя, я руководитель группы разработки внутренних компонентов в команде Яндекс.Браузера. В Браузере я чуть больше пяти лет, занимался разными вещами: от всего декодирования в браузере, всех HTML5-видео, до отрисовки, рендеринга и других подобных процессов.

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

Disclaimer: автор — не турборазработчик, а обычная веб-макака без претензий. Поэтому приведенные задания и решения могут вызвать у вас улыбку, баттхерт и желание указать автору на его некомпетентность. С нетерпением жду вас в комментариях! :)

Обсуждение выполненных тестовых заданий

В прошлой части я описывал, что делал аж два тестовых задания: первое на DevOps Engineer, второе — на Ruby Developer. Расскажу, что же было дальше.

О чем это

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

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

Актуальность задачи защиты от подделок

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

Советы по грамотному написанию технической документации для пользователей.
Часть 2

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

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

В этой части мы подробно разберем топики, из которых в основном состоит пользовательская документация (особенно User’s Guide) – а именно task-топики, в которых рассказывается, как решить конкретную задачу.

Расскажу, как нам удалось написать линтер, который получился достаточно быстрым, чтобы проверять изменения во время каждого git push и делать это за 5−10 секунд при кодовой базе в 5 миллионов строк на PHP. Мы назвали его NoVerify.

NoVerify поддерживает базовые вещи вроде перехода к определению и поиску использований и умеет работать в режиме Language Server. В первую очередь наш инструмент ориентирован на поиск потенциальных ошибок, но умеет проверять и стилистику. Сегодня его исходные коды появились в open-source на GitHub. Ищите ссылку в конце статьи.

В мире PHP хорошо известны инструменты миграций структуры БД — Doctrine, Phinx от CakePHP, от Laravel, от Yii — это то первое, что пришло в голову. Наверняка, есть еще с десяток. И большинство из них работают с миграциями — командами для внесения инкрементных изменений в схему базы данных.

Я не буду описывать зачем это, на хабре много постов на эту тему. Например:

• Версионная миграция структуры базы данных: основные подходы — хоть и старая статья, но принципы не стареют
• Эволюционный дизайн баз данных — перевод статьи Мартина Фаулера, хорошее описание [инкрементного подхода]
• Опыт 1440 миграций баз данных — практичный пост по работе с PostgesSQL

Далее, развитие моего опыта работы в команде с постоянным изменением структуры БД в разных ветках.

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

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

Если вы уже столкнулись с этой проблемой, и читаете эту статью, пытаясь нагуглить рецепт панацеи, то знайте, что его не существует. Тем более, в вашей голове уже скорее всего возникли инновационные мысли о том, чтобы сымитировать реалистичное поведение пользователя с помощью WebDriver, путём рандомного mouse overing'а элементов, кликов по инпутам, и бережно расставленных Thread.sleep(). Абсолютно точно известно, что этот подход работать не будет, не тратьте свое время попусту.



Получается, выхода нет?

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

Для начала следует договориться, что значит лучшие практики для языка программирования. Здесь можно вспомнить слова Расса Кокса, технического руководителя Go:

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

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

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

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

Источник

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

Сложилось так, что потребовалось контролировать около 30 VDS-ок на Debian, которые мне благополучно «передали» под надзор (а я как бы больше программист, чем *nix-администратор). И первая мысль, что пришла в голову после базовых операций по смене и проверке доступов, была «Если я что-то упустил, хочу оперативно знать о подключениях». Есть рецепты (в том числе на Хабре) связывания события авторизации по SSH и почтовых уведомлений, которые я использовал как базу, но мне хотелось все-таки оперативности и некоторой информативности. В общем получил я в итоге вот такую «систему», которая в течение месяца вполне успешно работает и сообщает мне о любом факте авторизации.

1. С помощью мануалов по API-телеграм получен токен и чат-ид для бота уведомлений (тут распространяться не буду, это все легко и просто находится в 1-2 строке поисковика).
2. Создано два скрипта, код от которых будет размещен ниже. В принципе можно все сунуть и в один файл, но т.к. я хотел модульности, то я вынес в отдельный скрипт функцию отправки уведомления в телеграм-бота.
3. В два файла настроек добавил вызов скрипта регистрации события входа на сервер и перезапустил службу SSH.

На все про все уходит минут 5-10, не больше. Ну а теперь собственно техничка.

PS. Все выполнялось на Debian9 x 64 (если это важно).

Статья подготовлена Анной anna-che и Ксенией KseMish.

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

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

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

Вот некоторые варианты для самого обычного человека:

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

Как раз о последнем варианте и пойдёт речь.

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

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

Снова законодатели совершенствуют нам жизнь! Портал правовой информации опубликовал Постановление Правительства Российской Федерации от 13.02.2019 № 146 "Об утверждении Правил организации и осуществления государственного контроля и надзора за обработкой персональных данных".

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

Надзирать будут в четырёх формах:

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

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

Облака, белогривые лошадки...

^{(откуда-то из интернета, впервые увидел тут.)}

Нагрузка на нашу систему сильно неравномерна: во-первых, в течение суток нагрузка меняется в 5 раз. Во-вторых, есть и ярко выраженная сезонность. Суточный максимум проверок после окончания летней сессии уменьшается в 10 раз! Зимняя сессия не столь яркая, но тоже не подарок. Плюс каждая последующая летняя сессия тяжелее (по числу проверок) и сложнее (новые технологии поиска и функциональность) предыдущей. Поэтому, с одной стороны, хочется иметь хороший запас по ресурсам, с другой – не платить лишнего во время спада активности. В сессию можно развернуть побольше серверов, а летом сократить объем потребляемых ресурсов. Очевидно, что это как раз случай облачных провайдеров. В этой статье я расскажу о различных аспектах взаимодействия с несколькими облачными провайдерами (AWS, ИТ-Град, MCS, YC). Если кому-то покажется, что это крик души, он не сильно ошибется. Итак, поехали!

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

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

Давайте рассмотрим некоторые шаблоны входа в систему, которые на мой взгляд не идеальны. А затем рассмотрим лучшие практики. TL;DR; Это страницы авторизации, которые просты, предсказуемы, на обычных страницах и дружат с менеджерами паролей.

Привет, Хабр! Не так давно возникла довольно типичная ситуация — руководство дало команду «Выбрать систему защиты данных от утечки». Основной критерий выбора — способность решить задачу не допустить утечек критически важной (по мнению руководства) документации, файлов и тому подобного. Как следовало из устного ЦУ руководителя, журналы и разная аналитическая функциональная оснащённость — вторична. Цитируя шефа, «для отлова злоумышленников мы можем и видеокамеры повесить, решайте задачу так, чтоб не разбираться с утечками, а исключить их». Разумеется, все прекрасно понимают, что 100% исключения риска утечек достичь нереально, поэтому — речь о минимизации риска утечки информации.

Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т.д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что :)

В общем, именно судьба той статьи побудила меня написать эту. И я очень надеюсь, что она будет полезна и прояснит многое.

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