IT-стандарты *

Делимся последними материалами из нашего корпоративного блога и блога на Хабре. Сегодня в подборке — как поднять собственный DNS-сервер, стародавняя сетевая проблема с «раздуванием» буферов и куда пропал IPv5.

Привет, Хабр! Меня зовут Евгений Янес, я ведущий руководитель IT-направления в СберТехе — компании, которая строит Platform V, цифровую платформу Сбера для разработки бизнес-приложений.

В статье расскажу, как мы создали Platform V Incident Manager — продукт для автоматизации процесса обработки ошибок, а за счёт функции обработки связанных инцидентов оптимизировали работу сразу нескольких бизнес-процессов.

В блоге T1 Cloud мы говорили о языке программирования Hare и суждено ли ему заменить Си в долгосрочной перспективе. Сегодня поговорим о другом нишевом ЯП — Ballerina. Он заточен под работу в облаке и разработку сетевых сервисов. Однако мнения об этом проекте довольно полярные — инженеры отмечают как удачные решения, так и серьёзные недостатки.

Совсем недавно начал изучать фреймворк Fastify, который почему-то не особо популярен в русскоязычном сегменте интернета. Для хранения переменных конфигурации я всегда использовал файл .env. Для чтения файла .env на Express я привык использовать всем известную библиотеку dotenv, то врем как в экосистеме Fastify есть своя библиотека - @fastify-env.

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

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

Итак, ниже пойдёт перевод этой статьи от 27.07.2021 г. (обновлено 18.02.2022 г.). Перед прочтением статьи рекомендую потратить 5-10 минут времени на чтение ооочень короткой официальной документации библиотеки @fastify-env.

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

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

Говорим о компактной утилите для сбора цифровых отпечатков. Её применяют для оценки безопасности ИТ-инфраструктуры. Обсудим возможности и альтернативы.

Рассказываем, откуда взялось название «Запуск Завтра», кто вдохновил Самата попробовать формат подкаста и что общего у собственного проекта и гончарной мастерской.

Продолжение. С первой частью можно ознакомиться здесь.

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

Технологии и сервисы, новые языки программирования и нейронные сети. Читая публикации на хабре где публикуются разные умные люди, пишут умные статьи, лично я задаюсь общим вопросом. По общему моему анализу статей на Хабре, большинство тематик связаны с наукой, современными технологиями и сервисами, ну это и понятно это же площадка для айтишников. Авторы во многих статьях проводят серьезную работу по аналитике данных, многие обладают серьезными знаниями и опытом в разных областях и продолжают учиться. Некоторые рекламируют свои сервисы и продукты. Похвально наверное. Но самое печальное, на мой взгляд, что большинство айтишников (не все конечно) по сути занимаются ерундой, за которую платят неплохие деньги. Попробую донести свое мировоззрение.

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

Современный ИТ-руководитель постоянно находится в поисках решения сложных и противоречивых проблем: с одной стороны, требования жесткой экономии бюджета, с другой, необходимого ускорения развития ИТ-сервисов и бизнеса, с третьей, экспоненциально нарастающий объем нагрузок, с четвертой – волны пандемии и необходимость максимально безопасного и гибкого развертывания удаленных рабочих мест при драматически нарастающем объеме запросов на изменения и модернизации, с пятой… импортозамещение, санкции, проблемы с поставками и логистикой оборудования, соблюдение законодательства по защите персональных данных 152 ФЗ и др., комплайнс, требования ИТ-трансформации, бизнес-трансформации, информационной и ролевой трансформации и т.д и т.п.

И вот этот ИТ-руководитель, он же бэтмен, как-то должен справиться с ситуацией и спасти стремительно меняющийся мир и бизнес от разорения, мало того, помочь сделать его успешным и процветающим. Вопрос «что делать?» вечен, есть даже известное произведение великого классика XIX-го века, но давайте попробуем ответить на этот вопрос в начале XXI-го.

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

Я опубликовал этот твит пару дней назад. И теперь, после огромного количества комментов и ретвитов, мне кажется, что я должен остановиться на этом подробнее. Правда ли это валидный URL? Как его распарсить?

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

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

Участники ИТ-сообщества уже долгое время спорят, что делать с IPv4 и IPv6. Одни призывают внедрить протокол нового поколения как можно скорее. Другие считают, что решением проблемы нехватки адресов станет NAT. Но в пылу дискуссий на тематических площадках иногда можно встретить справедливый вопрос: куда пропал IPv5?

Размытое зрение, стук по клавиатуре и одно глобальное правило продуктивности.

Я был там. Слишком долго работаю над проектом. Я начинаю ошибаться. Я теряю детали. Ошибки продолжают появляться, а качество падает.

Делаю что-нибудь творческое в течение нескольких часов, и это утомительно.

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

Великие умы всех времен имеют нечто общее:

Всем привет! Меня зовут Александр Чуглин, я руководитель управления корпоративной архитектуры в Норникеле. У нас >1000 информационных систем и >4000 точек интеграции между ними, и всё это постоянно меняется. В таких масштабах важно правильно выстроить архитектуру предприятия, а затем и правильно ей управлять. Чтобы понять, по верному ли пути мы идём, важна сторонняя оценка и сравнение с мировыми практиками.

Для этого мы использовали одну из мировых методик. Нас тестируют, сравнивают с мировыми бенчмарками и дают заключение. Это как с английским языком: определи, какой у тебя уровень владения — продвинутый или начальный. Используется шкала от 1 до 5. Сегодня хочу рассказать, как мы смогли улучшить нашу оценку с 2 до 3, как собираемся покорять 4 и какие внедрённые практики помогли нам больше всего.

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

• Определить достижение целей спринта;

• Оценить краткосрочное влияние разработки ПО на удовлетворённость заказчиков и пользователей в развитии продуктов;

• Провести формализацию и учет параметров спринтов.

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