Разработчики любят спорить о языках программирования и инструментах. Если опустить типичные претензии, обычно все сводится к тому, что люди просто защищают свой выбор. Это проявление тенденции оправдывать и защищать свои инвестиции - время потраченное на изучение используемых языка и инструментов. И в этом есть смысл. Но не всегда это поведение является рациональным.
Был сделан экспериментальный паровой мотоцикл по технологиям паровой эпохи. К всеобщему удивлению, его параметры оказались совсем не похожими на наши представления о 18 веке.
Если посмотреть на ассортимент шлагбаумов у нас на сайте, то одна из первых вещей, которая бросается в глаза, это разлет стоимости шлагбаумов от 49 650 рублей до 1 793 567 рублей. А один из часто возникающих вопросов это, а в чем собственно разница между шлагбаумом за условные 60 000 и за 160 000. И отвечать на такие вопросы и мне, и коллегам приходится достаточно часто.
Поэтому, вся нижеследующая объемная статья это попытка дать развернутый ответ на этот вопрос. А так как шлагбаумов у нас много, под катом много текста.
Принципы Site Reliability Engineering (SRE) в последнее время очень популярны, отчасти благодаря знаменитой книге о SRE в Google, где говорится о золотых сигналах, за которыми нужно следить, чтобы наши системы работали быстро и безотказно в любых масштабах.
Все понимают, что это важные сигналы, но не все знают, как их отслеживать. Об этом всем мы расскажем в данной статье.
Когда говорят о выборе архитектуры IT-системы, почти всегда упускают один ма-а-аленький нюанс: мы делаем продукты для пользователей, не для себя. А пользователям совершенно неважно, какая у сервиса архитектура. Никто в отзывах не ставит звёздочки за event-driven подход или классную реализацию service mesh — разве что в редких случаях, когда речь о продуктах для разработчиков.
Техническое совершенство — современные инструменты, предельная оптимизация, чистота кода и лаконичная, но гибкая и масштабируемая архитектура — всё это нужно нам, технарям. А как это всё связано со счастьем пользователей, как его измерять и учитывать при проектировании сервиса, разберёмся под катом.
Сразу небольшой оффтоп: набросал канву статьи, хотел обсудить с сообществом как актуальность темы, так и содержание: что упущено, что стоит добавить, а что стоит просто выкинуть... Хейтеры радушно приветствуются :)
----------------------
Современный ИТ-руководитель постоянно находится в поисках решения сложных и противоречивых проблем: с одной стороны, требования жесткой экономии бюджета, с другой, необходимого ускорения развития ИТ-сервисов и бизнеса, с третьей, экспоненциально нарастающий объем нагрузок, с четвертой – волны пандемии и необходимость максимально безопасного и гибкого развертывания удаленных рабочих мест при драматически нарастающем объеме запросов на изменения и модернизации, с пятой… импортозамещение, санкции, проблемы с поставками и логистикой оборудования, соблюдение законодательства по защите персональных данных 152 ФЗ и др., комплайнс, требования ИТ-трансформации, бизнес-трансформации, информационной и ролевой трансформации и т.д и т.п.
И вот этот ИТ-руководитель, он же бэтмен, как-то должен справиться с ситуацией и спасти стремительно меняющийся мир и бизнес от разорения, мало того, помочь сделать его успешным и процветающим. Вопрос «что делать?» вечен, есть даже известное произведение великого классика XIX-го века, но давайте попробуем ответить на этот вопрос в начале XXI-го.
Сначала пара слов о задачах типового ИТ-директора средней бизнес-компании, которые «лежат» на его рабочем столе, «живой» пример реального ИТ-руководителя (из интервью):
В конце декабря 2020 года я написал несколько статей на Хабре по своему опыту использования GitHub в обучении студентов (ссылки на них будут в конце сей статьи).
Сегодня же хочу рассказать об автоматизации проверки кода студентов. Примеры будут про C#, т.к. это мой основной язык, на котором я преподаю программирование.
Для меня при обучении программированию важно, чтобы студенты умели не только правильно решать задания, но и красиво писать код. В обучении и проверки заданий я использую EditorConfig, dotnet cli и GitHub Actions. Но обо всём по порядку.
Если вам нужна быстродействующая нереляционная СУБД типа «ключ-значение», то, возможно, подойдет Redis (Remote Dictionary Server). На базе Redis можно создать не только хранилище данных, но и кэш, брокер сообщений, а также очередь. Для увеличения отказоустойчивости можно настроить репликацию данных между серверами Redis.
В этой статье мы расскажем о том, как установить Redis в ОС Debian 11, а также как контролировать этот сервис вручную и с помощью Zabbix.
Недавно мы написали о том, насколько экономически разумно «переезжать» с Oracle на PostgreSQL. В этом материале хотели бы поделиться практическим опытом, как осуществить миграцию небольшой СУБД, и какие подводные камни вас могут ожидать при этом.
Обзор методов множественного доступа в беспроводной связи. Часть 5. Поляризация и закрученные волны
Привет, коллеги! У нас продолжается серия статей, посвящённых методам множественного доступа в беспроводной связи. Напомню, что в первой части мы рассмотрели методы частотно-временного разделения, во второй части – неортогональные методы разделения по мощности, в третьей части – методы кодового разделения и в четвёртой части – методы пространственного разделения пользователей.
В пятой части я расскажу о методах с поляризационным разделением пользователей и с разделением по орбитальном угловому моменту электромагнитной волны. Мы сравним между собой эти методы и, как всегда, обсудим их основные преимущества и недостатки, а также рассмотрим практический пример реализации множественного доступа с совместным использованием поляризационного и OAM-мультиплексирования.
Бывает, что программное обеспечение теряет актуальность, исчезает, трансформируется до неузнаваемости — уж если это случилось с Winamp, то что же грозит остальным :-) На самом деле, путь большинства технологий конечен, лет через 20 мы не обнаружим даже следов значительной части современных топовых приложений, устройств и компонентов. И это повод радоваться, а не грустно вздыхать, поскольку эволюция технологий это основа новой эволюции человечества (вот это пафос!). Однако многие программы и системы, видоизменяясь, сохраняют свою сущность и многие годы активно используются миллионами пользователей. Несколько десятилетий так было с CRM-системами. А дальше — будет?
У нас в Газпромбанке сложилась довольно интересная ситуация. Банк относительно недавно начал активно работать с розницей, которая как локомотив начала тянуть все внутрибанковское IT и менять характер работы всех подразделений.
Одна из главных наших проблем (впрочем, как и у многих) — долгие релизы, низкое качество кода, недоступность и нестабильность систем на тестовых полигонах. Но главное — интеграционные релизы. Когда несколько команд одновременно пытаются зарелизить свои доработки, нужно много времени и средств, чтобы синхронизировать всех. При этом каждый привносит новые баги, все начинают бегать кругами, спотыкаться, фиксить, перенакатывать… В итоге качество продукта низкое, а пользователь смотрит на это все с недоумением.
Как с этим всем бороться? Вот короткий рецепт от нас: избавиться от интеграционных релизов. Вообще. Собрать автономные, кросс-функциональные команды, каждая из которых будет выполнять свою задачу, не толкаясь локтями с другими. Для этого перепилить пайплайн, повысить инженерную культуру, ввести стандарты и так далее. Подробнее — под катом.
Рассмотрено два способа получения значения атрибута HTML-элемента на HTML-странице в скрипте на языке PowerShell с помощью методов объектов из библиотеки HTML Agility Pack.
Показан прямой доступ к значениям атрибутов с помощью выражения вида $node.Attributes. Далее большая часть статьи посвящена методам GetAttributeValue из библиотеки HTML Agility Pack. Освежаю в памяти, что такое «полиморфизм» и как он реализован в библиотеке для данного метода. Также будет немного затронуто понятие «обобщенного метода» («generic method») в языке C#.
Блокчейн - это радикально новая вычислительная модель, в которой данные и приложения защищаются не централизованными посредниками, а децентрализованной сетью компьютеров. Благодаря своей безразрешительной природе блокчейн позволяет любому человеку подключиться к сети и начать независимую проверку целостности вычислений, что приводит к созданию системы сдержек и противовесов между пользователями и операторами сети.
От создания новых цифровых валют с программной денежной политикой (например, Bitcoin) до выполнения программируемых приложений с минимальным доверием (например, Ethereum), блокчейн быстро входит в общественное сознание как новая форма цифровой инфраструктуры, часто называемая Web3. Однако, несмотря на то, что всеобъемлющее ценностное предложение блокчейн признается многими, нюансы, касающиеся лежащей в основе блокчейн модели доверия, часто понимаются неправильно.
Эта статья поможет объяснить, чем модель доверия в блокчейн отличается от традиционных вычислений, рассмотрев роль самопроверяющихся полных узлов, в частности то, как они обеспечивают достоверность производителей блоков (например, майнеров/валидаторов) и как снижение стоимости проверки лежит в основе масштабируемости блокчейн.
В криптосообществе за многие годы образовался целый культ по созданию красивых адресов для криптокошельков. Каждый желающий может сгенерировать для себя «красивый» адрес, который будет не только уникальным, но и будет иметь в себе определенное сочетание букв и цифр. Это очень увлекательный и интересный процесс, но нельзя полностью исключать риск, связанный с привлечением третьей стороны и перехватом приватного ключа к криптокошельку. Все мы когда-либо слышали о независимых агрегаторах CoinMarketCap и CoinGecko это самые популярные площадки для отслеживая цен на бирже, но в этой статье мы не будем рассматривать механизмы и функции этих площадок. Речь пойдет о скрытых кодах в vanitygen + oclvanitygen и стремительное распространение их на популярных площадках.
Это исследовательский проект создан в целях информационной безопасности.
Многим пользователям не устраивают стандартные рандомные адреса криптокошелька и именно по этой причине они используют различные программы, утилиты и плагины для создание красивых криптовалютных адресов.
Согласно порталу TAdviser жертвами все чаще становятся из-за использование не проверенное программное обеспечение.
Торговая система QUIK [ссылка удалена мод.] для большинства серьёзных игроков рынка является очень популярной системой предоставления своим клиентам интерфейса для торговли ценными бумагами. Но в большинстве своём внутренности этой системы, как и любого коммерческого продукта являются закрытыми, в связи с чем могут возникать проблемы интеграции во внутреннюю инфраструктуру предприятия. В этой статье будут рассмотрены возможные механизмы интеграции QUIK в системы предприятия являющегося клиентом брокера или самостоятельным брокером.
