Управление техническим долгом в архитектурном процессе современного банка — это не локальная задача его архитекторов. Это стратегический механизм, который при правильной реализации позволит непрерывно улучшать ИТ-ландшафт и, в конечном итоге, обеспечит достижение результатов, запланированных как ИТ-стратегией, так и бизнес-стратегией банка. Недостаточно техдолг просто записать — его жизненный цикл и формируемые показатели наглядно демонстрируют, что с ИТ не так и что с этим делать.
Проектирование и работа с REST-сервисами стали повседневными задачами для многих аналитиков. Однако мы часто встречаемся на работе с различными или даже противоречащими друг другу трактовками таких понятий, как REST, RESTful-сервис, RESTAPI.
Сегодня мы разберём, какие принципы вложил в парадигму REST её автор и как они могут помочь нам при проектировании систем.
Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.
Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.
Рун не должен резать
Тот, кто в них не смыслит.
В непонятных знаках
Всякий может сбиться.
Десять знаков тайных
Я прочел и знаю...(Сага об Эгиле)
Многие начинающие программисты, уже освоив синтаксис C++, обнаруживают, что нет простого способа, как подключить библиотеку, так и собрать программу для другой ОС, или чего хуже, под другим компьютером с той же ОС. Эта проблема отчасти порождается спорной практикой обучения, когда код учат писать и запускать лишь средствами IDE, таких как Visual Studio, Code::Blocks, и других.
Поначалу такой подход работает, но лишь до первой реальной задачи сделать что-то, что запустится не только на вашей машине. Тут-то новички и сталкиваются с отсутствием стандартной системы сборки и менеджера зависимостей. После осознания этой сложности, большинство студентов, как правило, переходят на другие языки, попутно тиражируя в индустрии миф о том, что C++ де не кроссплатформенный язык, а вот мой Python/Java/C# - да.
Между тем нас окружает множество замечательных кроссплатформенных программ написанных на C++. Если вы обучаетесь C++ и хотите понять как создавать такое ПО, то эта статья для вас.
Data Science — одна из самых востребованных профессий в IT. Она продолжает набирать обороты, хотя отдельной дисциплиной наука о данных стала сравнительно недавно. В эту субботу делимся большим, насыщенным материалом, который поможет узнать или вспомнить о ключевых этапах становления профессии, а освоить её можно здесь.
Привет! Меня зовут Женя Голева, я занимаюсь developer relations с 2016 года, и постоянно вижу профессиональных чатах холивары о нашей работе. Люди спорят, кто такие деврелы, кто занимается не деврелом, а какие виды деврелов наоборот имеют право на существование и очень нужны в команде.
Ответы на многие похожие вопросы уже есть — в книге Мэри Тенгвал “The Business Value of Developer Relations”. Я заручилась поддержкой автора и издательства-правообладателя и перевела главу “Building a Developer Relations Team / What’s in a name?” для русскоязычного сообщества. У вас впереди 10 коротких и ёмких разделов про цели и задачи всей команды Developer Relations на старте и в процессе развития, про то, какие роли и специализации могут быть востребованы на разных этапах, что кандидатам необходимо знать и уметь на входе, а что — вовсе не обязательно и можно добрать в процессе работы.
Эта статья будет полезна в первую очередь тем, кто хочет разобраться в специфике направления developer relations: если вы СТО или СЕО, то вам скорее будут полезны первые несколько разделов и последний, если вы уже занимаетесь деврелом или очень хотите начать, здесь будут ответы на вопросы, как войти в профессию или куда в ней развиваться дальше.
Если я вижу в заголовке статьи на Хабре, названии доклада на конференции или в статье в СМИ слова «цифровая трансформация», я всегда знаю — будет пресно, скучно и много лжи. Из этого словосочетания делают волшебную палочку: цифровая трансформация как способ освоения бюджетов, цифровая трансформация как повод уволить сотрудников, цифровая трансформация как повод объяснить провалы сервиса, цифровая трансформация как способ поднять репутацию на модном тренде. При этом для многих за этими словами скрывается что угодно, кроме первоначального, идейного смысла. На фоне этого проваливаются более 70% проектов трансформации по всему миру. И так будет, пока в эти два красивых слова будут вкладывать всё что угодно, кроме принятия цифровых технологий внутри всех процессов управления. И это касается и гигантов рынка, и самых небольших компаний. Так почему мы все трансформируемся, трансформируемся, да так и не вытрансформируемся?
Упрощать реальный мир, чтобы потом успешно разрабатывать всякие теории для мира вымышленного – нормальный процесс для всех наук. У физиков целый набор таких артефактов: идеальный газ, материальная точка, абсолютно твердое тело, несжимаемая жидкость и пр.
И что самое характерное – работает! Уравнение Менделеева-Клапейрона прекрасно описывает вполне реальный газ, а классическая механика великолепно справляется с расчетом движения тел различного масштаба (пока этот масштаб не уходит в микромир или наоборот – в область действия общей теории относительности).
По-умному такой процесс называется моделирование методом редуцирования – т.е. мы максимально упрощаем реальную систему, получаем математическую модель, которая позволяет прогнозировать поведение системы, а потом оказывается, что и реальная система удовлетворяет выявленным закономерностям.
Подобный подход применяется и в сфере информационной безопасности. Сегодня мы посмотрим на один из таких артефактов – изолированную программную среду и как эта среда позволяет решать задачи обеспечения ИБ в реальных системах.
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето:
- 20% времени мы пишем новый код.
- 80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).
Во время поддержки мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов. Одним из таких способов способов и является код ревью
Вы писали в школе шпаргалки? Наверняка да. Вероятно, замечали, что одни шпоры были монолитным переписыванием учебника, а другие настоящими подсказками: открыл, глазом схватил схемы, списки, пункты и быстро убрал, потому что информация организована идеально. Такие писали те редкие отличники, которые не за уши тянутые и не зубрилки, и крепкие хорошисты с пониманием себя в обучении — это была их страховка, если хотите, успокоительное. Более того, пока так обрабатываешь, форматируешь и излагаешь информацию, выучиваешь предмет навсегда. Вот это была самая настоящая систематизация.
А теперь вопрос: стал ли автоматизированным процесс списывания с появлением удобных мобильных телефонов? Как считаете? Формально — да: труд человека минимизирован, информацию передаёт машина, у процесса высокая скорость, задействованы технологии, трудоёмкость операций снижена практически до нуля. Но, с другой стороны, информацию в электронной шпаргалке создал какой-то человек и дальше просто запущен процесс создания безлимитных копий. Получается автоматизация отчасти, да ещё с негативной коннотацией — она лишает человека возможности получить минимальные знания и работает только на целевой «KPI», т.е. оценку. Правда, немного похоже на некоторые формальные офисные процессы, которые направлены на какие-то мнимые цели и ключевые показатели с потолка?
Часто дискуссии на Хабре, в социальных сетях, на профильных площадках и в закрытых группах сводятся к обсуждению того, что CRM-система — это не про автоматизацию, потому что она сама за сотрудника работать не может и ему, бедненькому, нужно самому заполнять карточки клиентов с кучей полей, справочники, различные рабочие сущности программы и т.д. Беда да и только — все-то думали, что CRM работать за сотрудников будет, а она даже пальцы не загибает. Ага?
Два года назад я написал статью ІТ-термины на примере процесса выращивания картошки, собравшая огромное количество позитивных комментариев и просмотров. С тех пор появился отдельный персонаж - Картофанчик, который продолжает рассказывать просто об ИТ. Проект оригинально ведется на украинском языке.
Привет Хабр!
Меня зовут Саша Шутай, я тимлид в компании AGIMA. Конечно, прежде чем стать руководителем команды, я был разработчиком и работал под руководством нескольких тимлидов, поэтому знаком с разными подходами к управлению. В этой статье я поделюсь своим опытом тимлидерства и дам полезные советы, которые упростят жизнь новоиспеченного тимлида. В общем, расскажу, что ждёт разработчика, решившего стать руководителем.
Концепция устойчивого развития появилась на фоне признания мировым сообществом проблем экологии, развития общества и науки, ограниченности природных ресурсов. Устойчивое развитие предполагает, что удовлетворение потребностей современного общества и текущая деятельность человека не должна наносить вреда для последующих поколений. За почти 35 лет своего существования концепция претерпела некоторые изменения. В настоящее время под устойчивым развитием обычно понимают баланс между экономическим, экологическим и социальным развитием, экономический рост без ущерба окружающей среде, способствующий разрешению социальных проблем.
Эта статья написана по следам онлайн-курса Translation Quality Management от ТГУ и агентства Palex, который я недавно прошла по совету коллеги. Этот курс посвящен обеспечению качества переводов и предназначен как для менеджеров, организующих процесс перевода, так и для переводчиков и редакторов. Поскольку я переводчик и редактор в одном лице, некоторые идеи из этого курса показались мне полезными, и я хотела бы ими поделиться, а также рассказать, как они могут помочь сделать проверку (и самопроверку) переводов эффективнее. Статья может быть полезна тем, кто переводит и проверяет тексты, в частности, в IT.
Данный пост содержит выдержки из одноименной статьи Дэниела Фагеллы, руководителя отдела исследований в компании Emerj от 26.02.2020. Слегка укороченный перевод данной статьи служит доказательством концепции, изложенной мной в предыдущем посте о принятом за рубежом понимании термина machine learning.
Занимаясь многолетним научно-техническим переводом все чаще приходится сталкиваться с ситуациями, когда терминологическая идиоматика источника идет вразрез с принятыми у нас в обиходе понятиями, и что для того чтобы сохранить идиоматику источника нетронутой с целью донести до читателя смысл и стилистику неискаженными в том виде, в котором данный предмет изложения воспринимается за рубежом, приходится преодолевать кучу барьеров, главный из которых можно услышать из уст редактора издательства:
v-agent ориентированное программирование (VAOP) - это методология программирования, основанная на представлении алгоритма в виде v-agent script, который позволяет программному агенту, получившему название v-agent, выполнять операции закодированные в модулях v-agent box.
Идеологически v-agent ориентированное программирование - добивается того, чтобы алгоритм был записан в одном месте в виде, понятном всем - заказчикам, программистам и исполняющей среде (компьютеру), что улучшает процесс взаимодействия всех при создания программного продукта и, что особенно важно, существенно снижает затраты на этапе поддержания работы и адаптации к изменению внешних условий в Будущем.
Парадокс заключается в том, что мы должны меняться, чтобы все было по-прежнему, поэтому главная задача v-agent ориентированного программирования это обеспечить Бессмертие программного продукта при минимальных вложениях средств в его постоянную модернизацию.
В одной из прошлых статей мы рассказывали про IP-телефоны, которые ставятся в отельные номера. Самая популярная модель среди них — трубка Fanvil H2U. Собственно буква H в названии модели и означает слово "hotel", и предназначены они в первую очередь для настенной установки в ванных комнатах отелей и выполнения функции телефона экстренной связи. H2U не имеет подтвержденной степени влагозащищенности по стандарту IP (как и похожие модели других производителей), но в условиях влажных и запаренных душевых комнат чувствует себя уверенно, что мы сами проверяли в реальных инсталляциях. Вообще, установка телефонов в ванные комнаты важна для отелей не только для повышения реального комфорта и безопасности гостей, но и для выполнения формальных требований для прохождения гостиничной квалификации.
Однако, как показывает практика, более 80% продаж этих аппаратов проходят как раз не в отели, а в самые разные другие сферы. Разберемся, почему так происходит и куда их ставят.
