Терминология IT

Ниже моя история прохождения тестирования ISQTB Foundation Level, переживания, пробы, ошибки и советы по эффективной подготовке, актуальные для 2021 года.

На рис. 1 показан общий вид узлов, определенных альянсом O-RAN. Синие элементы определены 3GPP и адаптированы спецификациями O-RAN (добавляется «O-»), а оранжевые - это элементы, определенные O-RAN. (интерфейсы между элементами явно не показаны на этом рисунке - они представлены подробнее далее)

В настоящее время одной из самых обсуждаемых тем в мире телекоммуникаций является Open RAN. Автор хотел бы предложить серию сообщений, чтобы обсудить технические аспекты в этой области. Этот пост представляет собой введение в O-RAN, за которым следуют еще три обсуждения технических деталей. Прежде всего, чтобы избежать недоразумений, мы собираемся обсудить O-RAN (с тире). Это Open RAN, как определено O-RAN Alliance, организацией, миссия которой состоит в том, чтобы «переформировать индустрию RAN в сторону более интеллектуальных, открытых, виртуализированных и полностью совместимых мобильных сетей» [1].

На рис. 1 показана эволюция сети радиодоступа (RAN) при переходе от традиционного подхода к Open RAN. Унаследованный (legacy) способ предоставления RAN заключается в том, что существует один черный ящик, а внутренние интерфейсы внутри этого ящика закрыты и находятся в руках одного поставщика. Двигаясь к Open RAN (O-RAN), мы разделяем различные функции базовой станции на следующие объекты с открытыми интерфейсами между ними: централизованный блок (CU), распределенный блок (DU) и удаленный блок (RU)). Подобная архитектура определена в 3GPP, но с подходом O-RAN эти объекты могут разрабатываться разными поставщиками из-за открытых интерфейсов между ними (включая Open Fronthaul, Open FH). Кроме того, важным является то, что оранжевая коробка на схеме, т.н. Интеллектуальный контроллер RAN (RIC) выделяется из блоков обработки и дает возможность прямого взаимодействия с интерфейсами управления, таких как функции управления радиоресурсами (RRM) или самоорганизующихся сетей (SON). В концепции O-RAN именно здесь находится «мозг» моделей искусственного интеллекта (AI) для автоматизации радиосети.

Google планирует заменить cookie на новую технологию сбора информации о пользователях для рекламодателей. В Евросоюзе опасаются монополии IT-гиганта в области обезличенных данных (ОД) и деанонимизации. Представители бизнеса и эксперты соглашаются с тем, что американская компания только формально будет соблюдать законы стран о защите персональных данных (ПД). По факту Google получит IT-инструмент не только маркетингового, но и идеологического манипулирования гражданами.

На днях у меня появилась довольно интересная идея для статьи, основанная на следующей предпосылке: на Хабре ни разу не рассказывали об организации энтерпрайз разработки "от и до". В плане совсем с нуля и хотя бы до комфортного минимума. За отправную точку я буду брать ситуацию полнейшего хаоса, когда какой-то код существует на машине единственного разработчика, нет системы контроля версий, нет тестовых сред, код объектов БД существует только внутри эталонной продуктивной базы данных, нет никаких процессов сборки и установки, контроля качества кода и так далее. Возможно читатель задастся вопросом "Такое бывает в 2020 году? Разве кто-то еще так разрабатывает?" и будете только отчасти правы. Предлагаю обсудить детали под катом.

В русском языке встречаются два варианта написания слова Bitcoin — через «ои» (Биткоин) и через «ой» (Биткойн). Какое же из них верное? На самом деле это не такой уж простой вопрос. Дебаты между сторонниками обоих вариантов ведутся не один год и, на момент написания этой статьи, в русском языке нет устоявшейся нормы.

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

Для того, чтобы программным продуктом могли пользоваться люди в разных странах, нужно адаптировать его для них, то есть локализовать. И одним из важнейших этапов локализации всегда был и остается перевод. Я работаю в Plesk переводчиком с английского на русский язык и в этой статье хочу рассказать об особенностях работы IT-переводчика, а именно, о том, какие типы текстов мы переводим и с какими «подводными камнями» порой сталкиваемся в каждом из них. Надеюсь, мой опыт окажется полезным тем, кто переводит или собирается переводить IT-контент с английского на русский язык.

Мультитенантность (мультиарендность) – особенность архитектуры ПО, которая позволяет приложению обслуживать несколько независимых арендаторов. Пользователи не мешают друг другу, их данные хранятся независимо и безопасно, а разработчики могут быстро запускать версии продукта с разными техническими возможностями.

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

^{Перевод: https://medium.com/javascript-in-plain-english/19-things-i-stole-from-great-developers-85511ff56570}

Вы замечали, что мир IT очень огромен, но при этом в нем как будто нет места для ИБ, несмотря на то, что довольно много, а порой критично много на самом деле нуждающихся в нём?

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

Под катом я хотел бы сравнить и провести параллель (пусть, быть может, местами, это может казаться утрированно) между ведьмаками и пентестерами (ведьмаками из мира IT).

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

Понятие токена в BPMN вызывает много вопросов, хотя на самом деле, эта сущность крайне проста и полезна. Для начала приведем классическое определение:

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

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

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

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

Проблема

У каждого из нас есть не менее одной идеи на миллион. Но далеко не у каждого получается воплотить свои задумки в жизнь. Этому есть ряд причин, о которых написано немало книг и статей. Известно также, что реализовать свои идеи не получается даже у крупных компаний с большим опытом, крутой командой и немалым бюджетом. Для примера можно посмотреть на «кладбище» проектов компании Google или «морг» Microsoft. Трудно представить, что у этих компаний столько много не получившихся проектов, на которые были потрачены немалые деньги и время.

Что делать? Какое решение? В этой статье собрана большая часть методов проверки гипотез, также рассказывается о новом термине «претотипирование» с примерами известных компаний.

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

К примеру, решение алгоритмических задач для разработчика важнее знания спецификации языка. Процесс интервью Java разработчика в Москве будет начинаться с Java Core и заканчиваться JVM(Java Virtual Machine) и JMM(Java Memory Model) в частности. В европейских и американских компаниях от вас для начала захотят увидеть способность эффективно писать код. А если вы захотите попробовать свои силы в Google или Facebook, или в любую другую компанию- ИТ гигант - вам назначат собеседование с жареным текстовым редактором, именно текстовым редактором, без подсказок IDE, где вас будет интервьюировать человек, мозг которого будет напоминать компилятор. Он не будет полагаться на случай, он будет точно знать как работает этот код или же этот код с дефектом. 

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

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

Привет, меня зовут Александр, я тимлид команды разработки трекинговых решений компании Admitad.

Почти всегда на собеседованиях мне задают вопросы, чем занимается команда, какие у нас проекты и т.д. На устное объяснение кандидатам принципа работы CPA-сети Admitad уходит достаточно много времени, к тому же это не очень наглядно. Поэтому я решил написать статью, где в виде ответов на вопросы собрана информация о трекинге, сервисах нашей команды и задачах, которые мы решаем. Также я расскажу, как у нас работает мониторинг, чем микросервисы лучше монолита, какая польза от QA и еще пару интересных вещей.

Оригинальное название Defining Metrics for the Service Desk

Автор  Stuart Rance

Дата публикации 3.5.15

Достоинства: подробно рассмотрены 

- понятие целей (objectives) и критических факторов их достижения (CSFs) и их отличие от ключевых показателей (KPIs)

- для чего использовать KPIs и почему в отчетности фокусироваться на целях и CSFs 

Недостатки - слишком компактно. 

Уровень - базовый

Оценка - 8/10.

Оригинал How to Make Sure Your KPIs Are Balanced

автор  Stuart Rance, дата публикации 21.10.14

Достоинства: написано простым, доступным языком, качественные примеры.

Недостатки: слишком компактно.

Уровень сложности - средний.

Полезность - 7/10.

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

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

Здесь и далее курсивом замечания переводчика.

Еще одна компактная статься Стюарта Рейнса про то, чем измерять результативность процессов.

Оригинал Defining Metrics for Incident Management By Stuart Rance 

Опубликовано September 23, 2014 

Достоинства - хорошая иллюстрация декомпозита цели-показатели-метрики, качественный пример показателей, настойчивое напоминание о подходе  “адаптируй и применяй”

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

Сложность материала - базовая.

Оценка - 8/10.

Здесь и ниже курсовом комментарии переводчика.