Как стать автором
Обновить
75
Карма
0
Рейтинг
Сергей Владимиров @vlsergey

Пользователь

Ретроспектива по шагам. Рецепт

Управление проектами *Agile *Управление продуктом *

Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, "обучающих" материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.

Читать далее
Всего голосов 6: ↑6 и ↓0 +6
Просмотры 20K
Комментарии 20

Типобезопасность в JavaScript: Flow и TypeScript

JavaScript *ООП *
Все, кто имеют дело с разработкой UI в кровавом enterprise наверняка слышали о «типизированном JavaScript», подразумевая под этим «TypeScript от Microsoft». Но кроме этого решения существует как минимум ещё одна распространённая система типизации JS, и тоже от крупного игрока IT-мира. Это flow от Facebook. Из-за личной нелюбви к Microsoft раньше всегда использовал именно flow. Объективно это объяснял хорошей интеграцией с существующими утилитами и простотой перехода.

К сожалению, надо признать, что в 2021 году flow уже значительно проигрывает TypeScript как в популярности, так и в поддержке со стороны самых разных утилит (и библиотек), и пора бы его закопать поставить на полку, и перестать жевать кактус перейти на де-факто стандарт TypeScript. Но под этим хочется на последок сравнить эти технологии, сказать пару (или не пару) прощальных слов flow от Facebook.
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Просмотры 9.1K
Комментарии 10

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Java *Карьера в IT-индустрии
В своей карьере мне приходилось быть и разработчиком, и менеджером, и даже один раз «CTO» в небольшом стартапе. И, разумеется, приходилось проводить большое количество собеседований кадидатов. Поэтому для себя я выработал такие правила проведения технических собеседований:

  • всем кандидатам задавать одинаковые вопросы,
  • вопросы должны быть такие, чтобы на них ответил и junior, и senior, но по разному,
  • после трёх вопросов должен быть понятен уровень кандидата.

И вот такие три вопроса для Java-разработчиков у меня получились.
Читать дальше →
Всего голосов 41: ↑25 и ↓16 +9
Просмотры 25K
Комментарии 55

Когда вредно хешировать

Информационная безопасность *Криптография *
Предисловие
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На Хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

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

Под сложностью восстановления понимается тот факт, что для нахождения первого прообраза [надёжной криптографической хеш-функции] требуется совершить в среднем не менее $2^{n-1}$ операций хеширования, где $n$ — количество бит в выходе криптографической хеш-функции. Взяв современную хеш-функцию с большим размером выхода (начиная от 256 бит) разработчик информационной системы уверен, что восстановить исходные данные по значению хеш-функции нельзя. Чаще всего он прав.

Но есть важный набор случаев, когда несмотря на надёжность хеш-функции восстановление прообраза или даже исходного текста не представляет проблемы. Это случай, когда использовать хеш-функцию бессмысленно. Это случай, когда количество вариантов исходного текста поддаётся перебору.
Читать дальше →
Всего голосов 27: ↑26 и ↓1 +25
Просмотры 11K
Комментарии 28

Асимметричные криптографические протоколы распределения ключей: Деннинга—Сакко, DASS, Ву-Лама

Информационная безопасность *Криптография *
Предисловие
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На Хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам. Предыдущие разделы главы «Криптографически протоколы»: 1, 2, 3, 4, 5; следующий по порядку: 7.

Асимметричные протоколы, или же протоколы, основанные на криптосистемах с открытыми ключами, позволяют ослабить требования к предварительному этапу протоколов. Вместо общего секретного ключа, который должны иметь две стороны (либо каждая из сторон и доверенный центр), в рассматриваемых ниже протоколах стороны должны предварительно обменяться открытыми ключами (между собой либо с доверенным центром). Такой предварительный обмен может проходить по открытому каналу связи, в предположении, что криптоаналитик не может повлиять на содержимое канала связи на данном этапе.
Читать дальше →
Всего голосов 6: ↑6 и ↓0 +6
Просмотры 3.7K
Комментарии 0

Схемы распределения ключей с доверенным центром: схемы Жиро и Блома

Информационная безопасность *Криптография *
Предисловие
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На Хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам. Предыдущие разделы главы «Криптографически протоколы»: 1, 2, 3, 4

Схемы распределения ключей с доверенным центром состоят из трёх этапов.

  1. На первом этапе доверенный центр создаёт некоторый секрет, известный только ему. Это может быть некоторая секретная матрица с особыми свойствами, как в схеме Блома, или пара из закрытого и открытого ключей, как в схеме Жиро.
  2. Для каждого нового легального участника сети доверенный центр, используя свою секретную информацию, вырабатывает некоторый отпечаток или сертификат, который позволяет новому участнику вырабатывать сеансовые ключи с другими легальными участниками.
  3. Наконец, на третьем этапе, когда начинается протокол общения двух легальных участников, они предъявляют друг-другу идентификаторы и/или дополнительную информацию от доверенного центра. Используя её, без дополнительного обращения к центру, они могут сгенерировать секретный сеансовый ключ для общения между собой.
Читать дальше →
Всего голосов 10: ↑10 и ↓0 +10
Просмотры 2.7K
Комментарии 0

«Криптосистемы-протоколы»: Диффи—Хеллмана, Эль-Гамаля, MTI/A(0), STS

Информационная безопасность *Криптография *
Предисловие
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На Хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам. Предыдущие разделы главы «Криптографически протоколы»: 1, 2, 3

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

Позже в 1990-х годах будут разделены математические асимметричные примитивы (шифрование и электронная подпись) и протоколы, эти примитивы использующие, что будет продемонстрировано в разделе про асимметричные протоколы.
Читать дальше →
Всего голосов 18: ↑18 и ↓0 +18
Просмотры 22K
Комментарии 1

Трёхпроходные протоколы

Информационная безопасность *Криптография *
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На Хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

Предыдущие темы:


Если между Алисой и Бобом существует канал связи, недоступный для модификации злоумышленником (то есть когда применима модель только пассивного криптоаналитика), то даже без предварительного обмена секретными ключами или другой информацией можно воспользоваться идеями, использованными ранее в криптографии на открытых ключах. После описания RSA в 1978 году, в 1980 Ади Шамир предложил использовать криптосистемы, основанные на коммутативных операциях, для передачи информации без предварительного обмена секретными ключами. Если предположить, что передаваемой информацией является выработанный одной из сторон секретный сеансовый ключ, то в общем виде мы получаем следующий трёхпроходной протокол.
Читать дальше →
Всего голосов 19: ↑19 и ↓0 +19
Просмотры 5.2K
Комментарии 1

Криптографические протоколы: определения, запись, свойства, классификация, атаки

Криптография *
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

Основные понятия


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

Формализация подобных действий делается через описание протокола. Протокол — описание распределённого алгоритма, в процессе выполнения которого два или более участников последовательно выполняют определённые действия и обмениваются сообщениями (Здесь и далее в этом разделе определения даны на основе [Cheremushkin:2009]).

Под участником (субъектом, стороной) протокола понимают не только людей, но и приложения, группы людей или целые организации. Формально участниками считают только тех, кто выполняет активную роль в рамках протокола. Хотя при создании и описании протоколов забывать про пассивные стороны тоже не стоит. Например, пассивный криптоаналитик формально не является участником протоколов, но многие протоколы разрабатываются с учётом защиты от таких «неучастников».
Читать дальше →
Всего голосов 27: ↑27 и ↓0 +27
Просмотры 24K
Комментарии 11

React + IndexDb + автообновление = почти AsyncRedux

JavaScript *ReactJS *
Туториал
В данной заметке по шагам расскажу как приготовить IndexDB (база данных, которая встроена в любой современный браузер) для использования в проектах, написанных на ReactJS. В результате Вы сможете использовать данные из IndexDB так же удобно, как если бы они находились в Redux Store вашего приложения.

IndexDB — это документоориентированная СУБД, удобное средство для временного хранения относительно небольшого объёма (единицы и десятки мегабайт) структуированных данных на стороне браузера. К стандартной задаче, для которых мне приходится использовать IndexDB относится кэширование данных бизнес-справочников на стороне клиента (названия стран, городов, валют по коду и прочее). Скопировав их на сторону клиента потом можно лишь изредка загружать с сервера обновления этих справочников (либо целиком — они же небольшие) и не делать это при каждом открытии окна браузера.
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Просмотры 7.5K
Комментарии 0

Протоколы распространения ключей на симметричных шифрах

Информационная безопасность *Криптография *
Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

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

  • В результате работы протокола должен между двумя абонентами должны быть сформирован секретный сессионный ключ.
  • Успешное окончание работы протокола распространение ключей должно означать успешную взаимную аутентификацию абонентов. Не должно быть такого, что протокол успешно завершился с точки зрения одной из сторон, а вторая сторона при этом представлена злоумышленником.
  • К участию в работе протокола должны допускаться только легальные пользователи сети. Внешний пользователь не должен иметь возможность получить общий сессионный ключ с кем-либо из абонентов.
  • Добавление нового абонента в сеть (или исключение из неё) не должно требовать уведомления всех участников сети.
Читать дальше →
Всего голосов 18: ↑18 и ↓0 +18
Просмотры 13K
Комментарии 12

Blockchain

Информационная безопасность *Криптография *
Данный текст будет являться новой главой для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github. На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

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

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

В таких системах есть три группы действующих лиц:

  • источники событий (транзакций)
  • источники блоков (фиксаторы транзакций)
  • получатели (читатели) блоков и зафиксированных транзакций.

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

Основное требование к таким журналам таково:

  • Невозможность модификации журнала: после добавления транзакции в журнал должно быть невозможно её оттуда удалить или изменить.
Читать дальше →
Всего голосов 53: ↑49 и ↓4 +45
Просмотры 119K
Комментарии 73

Квантовый протокол распределения ключей BB84

Криптография *
Данный текст будет являться новой главой для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github. На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

В 1984 году Чарлз Беннет (англ. Charles Henry Bennett) и Жиль Брассар (фр. Gilles Brassard) предложили новый квантовый протокол распределения ключа. Как и другие протоколы его целью является создание нового сеансового ключа, который в дальнейшем можно использовать в классической симметричной криптографии. Однако особенностью протокола является использование отдельных положений квантовой физики для гарантии защиты получаемого ключа от перехвата злоумышленником.

До начала очередного раунда генерации сеансового ключа предполагается, что у Алисы и Боба, как участников протокола, имеется:

  • квантовый канал связи;
  • классический канал связи.

Протокол гарантирует, что вмешательство злоумышленника в протокол можно заметить вплоть до тех пор, пока злоумышленник не сможет контролировать и на чтение, и на запись все каналы общения сразу.
Читать дальше →
Всего голосов 11: ↑10 и ↓1 +9
Просмотры 13K
Комментарии 5

Восстановление Apache Derby без резервной копии

SQL *
Для собственного удовольствия у меня на личном компьютере крутится робот для Википедии (аккаунт1, аккаунт2, исходный код). Бот держит локальный кеш версий страниц Википедии — чтобы не ходить каждый раз на удалённый сервер за ними, а также набор специфичных данных, которые собирались последние пару лет и очень важны для работы бота. Данные собираются в базу данных под управлением Apache Derby, и, вместе с кешем, БД занимает около 50 Гб.

И вот, в один прекрасный выходной день, когда бот обрабатывал данные в 8 потоков на 4-х CPU, Abbyy Finereader распознавал 14-ый том русского биографического словаря под редакцией А. А. Половцева, а противники делали свой ход в Civilization Age of Kings… возник он — синий экран смерти. Давненько не виделись, подумал я, перезагружая компьютер. С причиной ладно — скорее всего проблемы с видеоадаптером на аппаратной почве. Вот только когда компьютер загрузился и я попробовал запустить бота ещё раз, возникло это:
ERROR XSDG2: Invalid checksum on Page Page

А прошлый бэкап, как обычно, датирован мартом месяцем…
Читать дальше →
Всего голосов 3: ↑3 и ↓0 +3
Просмотры 4.3K
Комментарии 0

Вышла новая версия Apache POI 3.8beta4

Java *
В новой версии библиотеки, кроме обычных исправлений ошибок, содержится большое количество изменений, связанных с парсингом и обработкой файлов MS Word.
Читать дальше →
Всего голосов 24: ↑23 и ↓1 +22
Просмотры 3.1K
Комментарии 11

Re: Сравнение производительности платформ .NET и Java на примере бинарного дерева

Чулан
Как же надоели некорректные сравнения платформ. Оставив в стороне различия между .NET и Java, которые не были учтены в тесте, покажу на шагах оптимизацию времени исполнения.

Читать дальше →
Всего голосов 31: ↑22 и ↓9 +13
Просмотры 595
Комментарии 13

Использование XPath для указания ссылок на объекты

Чулан
Данный топик рассказывает о возможности использования XPath для выбора объектов из базы данных в случаях, когда использование SQL нежелательно.
Читать дальше →
Всего голосов 11: ↑10 и ↓1 +9
Просмотры 1.9K
Комментарии 11

Использование apr_socket_sendfile() из сервлетов под Tomcat

Java *
В этом топике расскажу о маленьком, но эффективном способе передачи файлов пользователю из сервлета по HTTP протоколу. Используется:
  • Apache Tomcat
  • Apache Portable Runtime Library
  • Apache Tomcat Native Library
  • Ваш сервлет, которому нужно отдавать файлы пользователю
Читать дальше →
Всего голосов 31: ↑23 и ↓8 +15
Просмотры 2K
Комментарии 15

SoftReference Read-Write Cache для Hibernate — с «хвостами» для реализации кластера

Java *
В этом топике попробую рассказать о реализации системы кеширования данных в CMS ArpSite. Эта подсистема уже не раз переписывалась, но она является именно тем, что позволяет системе вообще работать с приемлимым временем отклика.

Использование SoftReference даёт возможность оставить поведение кеширования «на самотёк» — за пореблением памяти следит сама JVM, она же очищает старые элементы.

«Cluster» означает, что кеш самостоятельно отслеживает события инвалидации (устаревания, обновления) значений и следит за тем, чтобы на других серверах в кластере устаревшие элементы выкидывались из кеша. Есть и другие определения кластерного кеша. Например, основной режим работы JBoss Cache может даже «вытягивать» элементы с других узлов кластера, если их нет на текущей машине. Но для нашей системы, где скорость получения элемента с другой машины ненамного меньше скорости генерации элемента, достаточно инвалидации.

Read-Write означает, что мы не используем блокировку элементов кеша и вообще не думаем (почти) о том, что в нашей системе есть какие-то независимые транзакции. Для CMS это нормально, но, разумеется, для какого-нибудь enterprise application это было бы недопустимо.
Читать дальше →
Всего голосов 5: ↑4 и ↓1 +3
Просмотры 4.1K
Комментарии 23

Java-ассемблер, мета-программирование и JPA

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

Краткая постановка задачи:
  • Есть набор виртуальных «классов» в понятии бизнес-пользователя. Например, «сайт», «папка», «новость», и т.д. Каждый из таких классов имеет набор полей (аттрибутов).
  • Пока что у нас нет наследования классов, а поля ограничены примитивными String/Integer/Long/Enum/Boolean, даже без multiple, но с возможными заданными значениями по умолчанию
  • Каждый класс записывается в отдельную таблицу, например, objects_sites, objects_news, objects_folder, etc. Таблица всегда содержит ID объекта, а также колонки для полей.
  • Нужно сделать так, чтобы загрузка этих объектов работала через JPA (Hibernate), с использованием необходимого кэширования/транзакций/Lazy-loading'а и других вкусностей, которые нам даёт JPA.

Для выполнения данной задачи использовалось:
  • В качестве баз данных — MySQL 5.0, InnoDB, три схемы базы данных (разные типы могут лежать в разных схемах, чтобы отделить системные типы от пользовательских)
  • Sun JDK 6.0
  • Tomcat 6 + JOTM 2.1.9 + Hibernate 3.5.0-Final (patched)
  • Для создания классов использовалась связка CGLib 2.2 (входящая в Hibernate) и ASM 3.2 (в Hibernate входит 3.1)

Читать дальше →
Всего голосов 42: ↑33 и ↓9 +24
Просмотры 9K
Комментарии 24
1

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность