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


Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.

Друзья, в конце января у нас стартует новый курс под названием «MS SQL Server разработчик». В преддверии его запуска мы попросили преподавателя курса, Кристину Кучерову, подготовить авторскую статью. Эта статья будет вам полезна, если у вас есть очень популярная таблица на проде с доступом 24/7 и вдруг неожиданно вы поняли, что срочно нужно добавить индекс и ничего не сломать в процессе.

Итак, что же делать? Традиционный способ CREATE INDEX WITH (ONLINE = ON) вам не подходит, потому что, например, вызывает падение системы и сердечный приступ вашего ДБА, все топы пристально следят за response time вашей системы и в случае увеличения оного приходят к вам и вашему ДБА на разговор по поводу завышенных цифр вашей компенсации за труд.

Скрипты и описанные приёмы были использованы на системе с нагрузкой 400К requests per minute, версии SQL Server 2012 и 2016 (Enterprise).

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

Кейс № 1. Маленькая, но очень популярная таблица

Таблица 50 тыс. записей (небольшая), но очень популярная (несколько тысяч обращений в минуту). Вам нужен новый индекс и минимальное время простоя и блокировок на таблице.
В приложении весь доступ к БД только через процедуры.

При ошибке приложение сделает повторную попытку обратится к таблице.

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

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

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

В прошедшие выходные в Кельне закончилась игровая выставка Gamescom 2018. Негласно ее воспринимают как возможность поиграть во все, что анонсировали на E3 парой месяцев ранее. Поэтому сюрпризов мало — геймплея много. И в случае с Cyberpunk 2077 это даже круче.

Под катом лучшие ролики с выставки.

Любой, кто поднимал сайты знает, что стоит запустить веб-сервер, как на него начинают приходить запросы. Еще и DNS про него толком не знает, а в лог-файле ошибок httpd уже полно записей вроде таких:



Вот мне стало интересно, и я решил изучить этот вопрос поглубже. Как только появилось время, я написал парсер логов веб-сервера. Поскольку люблю наглядность, результаты поместил на карту.
И вот какая картина получилась:

Всем привет! Прежде всего, хочу поблагодарить всех, кто участвовал в обсуждении моей первой статьи: «Кто сканирует Интернет и существует ли Австралия».

Публиковал статью без всякого умысла, просто поднял тему, которая так или иначе касается всех. Не только тех кто связан с ИТ, но и любого, чей сервер или ПК сидит на «реальных»(«белых») адресах Интернет.

Как я и предполагал, после публикации статьи, резко вырос «интерес» к IP-адресу на котором висит сборщик статистики. Многие, ради шутки, вставляли в URL сообщения, различные наборы символов и т.д. Так обнаружилось, что существуют и Австралия и Новая Зеландия. Да и много кто еще.