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

А дело было так - я ловил пескарей пару недель назад я решил начать искать работу.

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

Заголовок статьи не оставляет простора для интриги, в нём, в общем-то, максимально сжато выражена суть нижеследующего повествования - но я всё-таки рискну отнять пару минут вашего времени, расписав более подробно мои соображения на эту тему.

…а также способами обнаружения вредоносных техник в сетевом трафике

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

Одним только переводом решили не ограничиваться. Мы дополнили матрицу экспертизой Positive Technologies о том, как обнаруживать ту или иную технику  с помощью систем анализа трафика (network traffic analysis, NTA), например таких, как PT Network Attack Discovery.  Готовы познакомить вас со своим проектом и рассказать, как устроена наша матрица и чем мы руководствовались при переводе названий тактик и техник. Welcome под кат!

В мире на сегодня накопилось много неприятных вещей и тенденций, о которых почему-то стало неприлично негативно высказываться. Даже фраза появилась: «Вы не понимаете, это другое!»  Немалая часть явлений так или иначе связана с ИТ. В рамках проводимого мероприятия «Стань автором, получи футболку!» решил выложить на обсуждение некоторые моменты с комментариями, почему я считаю их вредными, а иногда и опасными.

Поехали.

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

Вспомним наш любимый мультфильм «Падал прошлогодний снег» с его шикарными крылатыми фразами. Одна из них: «Уж послала, так послала». Вот и система так же — вместо отправки запроса посылает его куда-то далеко. А запросу обидно.

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

Возможно, вы уже слышали слово “легаси” (legacy) от сотрудников технических отделов и, как правило, в негативном ключе. Данным термином обозначают методы, технологии и компьютерные системы или прикладные программы, которые по каким-либо причинам признаны устаревшими. Однако всегда ли такое наследство несет негативный эффект для бизнеса, обязательно ли от него избавляться и как понять, что оно действительно вам мешает?

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

Как их только не называют: техписы, техрайтеры, документаторы... Хорошо, хоть не архивариусы!

Спрос на хорошую, качественную документацию к программам и системам постоянно растёт. При этом сейчас на рынке наблюдается серьёзный дефицит профессиональных технических писателей. Опытные технические писатели сейчас буквально на вес золота. Во всём мире профессия technical writer (или technical author) считается престижной и перспективной. Техническое документирование — это одна из замечательных пограничных областей для тех, кто так и не смог смириться в школе с разделением на гуманитариев и математиков.

Управление техническим долгом в архитектурном процессе современного банка — это не локальная задача его архитекторов. Это стратегический механизм, который при правильной реализации позволит непрерывно улучшать ИТ-ландшафт и, в конечном итоге, обеспечит достижение результатов, запланированных как ИТ-стратегией, так и бизнес-стратегией банка. Недостаточно техдолг просто записать — его жизненный цикл и формируемые показатели наглядно демонстрируют, что с ИТ не так и что с этим делать.

Проектирование и работа с 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. Она продолжает набирать обороты, хотя отдельной дисциплиной наука о данных стала сравнительно недавно. В эту субботу делимся большим, насыщенным материалом, который поможет узнать или вспомнить о ключевых этапах становления профессии, а освоить её можно здесь.

• Грейд — структура, позволяющая привязать зарплаты в компании к навыкам и задачам сотрудников.
• Грейды нужны не всем компаниям.
• Грейды не только про hard-skills.
• Грейды обоюдно удобны, если позволяют тем, кто больше вкладывает в развитие компании, получать больше.
• Грейды могут быть вертикальные и горизонтальные.
• Круто, когда человека сам решает, куда он хочет развиваться, и компания идет ему навстречу.

Привет! Меня зовут Женя Голева, я занимаюсь 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.