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

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

Мы провели опрос и узнали, какие слова, словечки и высказывания раздражают IT-специалистов. Среди ответов есть неожиданные, но лидер вряд ли кого-то удивит. Как к этому всему относиться? Как к профессиональному жаргону, который есть в каждой специальности. Обычного человека скорее всего покоробят профессионализмы юристов и врачей, но для нас всех короткое и ёмкое слово — формулировка короткой и точной мысли. По крайней мере, очень хочется так думать ;-)

Наверно, многие из моих читателей как раз закончили квартальный (и/или годовой) цикл планирования, так что сейчас будет подходящее время напомнить, что процесс, которым мы пользуемся как стандартом в технологической отрасли, на самом деле — полная чушь. Разумеется, я имею в виду методологию Objectives and Key Results. Давайте же поговорим об OKR, что это такое и откуда они взялись, а ещё о том, почему это ужасная идея.

Любой компании, которая стремится сохранить конкурентоспособность на рынке, необходимо создание «золотой записи» (профиля) клиента во внутренних базах. Для этого многие используют системы управления мастер-данными (MDM, master data management), но сталкиваются с рядом проблем, другие – применяют CDP-платформы (Customer Data Platform), которые также имеют свои недостатки. А теперь представьте, если от каждого из решений можно было взять лишь лучшее, оставив за бортом все слабые стороны. Как это сделать – в новой статье CleverData под катом.

В технической документации часто встречаются фразы с использованием страдательного залога. Параметры там «задаются», файлы «сохраняются», а программа «запускается». Ох, опасная эта форма для строгих и однозначных описаний! Почему же страдательный залог заставляет читателей страдать? Будем разбираться...

Эта статья – ответ на статью «Обращение к издательствам: пожалуйста, не переводите термины».

Давайте поговорим, например, о распределённых базах данных. Всем известно, что данные делятся на фрагменты, которые затем распределяются между узлами.

– Какие-такие «узлы» и «фрагменты»? – спросит программист, работающий с MongoDB. – Наверное, ты имел в виду «чанки» и «шарды»?

– Что за «чанки»? – переспросит аналитик, хранящий данные в GreenPlum. – У нас данные делятся на «регионы», которые потом распределяются по «регионсерверам»!

Можно было бы продолжать этот воображаемый спор, но я лучше приведу табличку:

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

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

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

Привет, Хабр!

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

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

Когда я в последний раз менял работу и проходил собеседования, конечно, основные вопросы были про навыки продакта и особенности продуктов, которыми я занимался. Вопросы касались метрик, экономики продукта и взаимодействия с пользователями. Поскольку мой опыт специфичен :), в какой-то момент у меня даже закралось сомнение, а точно ли я продакт? Начал размышлять, откуда родился такой вопрос — и понял.

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

Но чаще всего авторы обходят стороной продукты, которые существуют для гораздо меньшего числа пользователей, и которыми пользуются те команды, которые делают большие, классные и успешные продукты. Я говорю о внутренних ИТ-продуктах компаний.

Меня зовут Денис Соловьев, и так получилось, что я работал и продолжаю работать как раз на таких внутренних ИТ-продуктах. Я хочу сравнить, какие из инструментов и подходов работают для них.

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

Рыская по интернетам, зашел на страницу про URI и спустя несколько часов осознал, как мало я знал об этом монстре. Признаюсь, до этого я думал, что URI это либо URL, либо URN. Но это не так! Есть и другие варианты идентификации ресурса в сети.

Передо мной книга «Модельное мышление» Скотта Пейджа (издательство «Манн, Иванов и Фербер», Москва, 2020). По словам автора, «В книге рассматривается подход под названием “многомодельное мышление” - использование совокупности моделей для осмысления сложных явлений».

Тема эта не нова. Достаточно привести примеры публикаций популярных англосаксонских авторов Дж. Д. Вильямса (1), Л. Мозеса (2), Д. Химмельблау (3). Есть публикации и отечественных авторов (4). Отметим, что эти вопросы на различных уровнях неоднократно освещались уже 60 и 40 лет назад.

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

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

Тем не менее, я осознал: нет такого понятия — чистый код.

Изменив одно местоимение, можно на 90% увеличить показатель кликабельности (CTR) кнопки, которая приведет новых пользователей. Дописав одно предложение, можно увеличить количество оплаченных покупок и снизить нагрузку на саппорт. Поставив одну запятую, можно было бы сохранить 5 миллионов долларов. ОК, третий пример про договоры, но все равно показателен.

Текстам в интерфейсе уделяется незаслуженно мало внимания. Их игнорируют, про них забывают, про них вспоминают, когда уже поздно: дизайн сделан, код написан, огребаем на проде. Печально. А ведь хороший текст — один из самых дешевых способов сделать продукт лучше, и заработать больше денег.

Исследование Nielsen Norman Group показало, что лаконичный, объективный (без маркетологического хвастовства) текст, который легко читается пользователем, увеличивает юзабилити сайта на 124%. Только текст. UX и навигацию не трогали.

В вашем продукте (сайте, программе, приложении и т.д.) есть английский текст, и вы хотите, чтобы он приносил вам выгоду, а не просто занимал место? Читайте статью дальше. Я расскажу, как писать по-английски нужно, и как не нужно.

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

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

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

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

Поехали.

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

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

Если я вижу в заголовке статьи на Хабре, названии доклада на конференции или в статье в СМИ слова «цифровая трансформация», я всегда знаю — будет пресно, скучно и много лжи. Из этого словосочетания делают волшебную палочку: цифровая трансформация как способ освоения бюджетов, цифровая трансформация как повод уволить сотрудников, цифровая трансформация как повод объяснить провалы сервиса, цифровая трансформация как способ поднять репутацию на модном тренде. При этом для многих за этими словами скрывается что угодно, кроме первоначального, идейного смысла. На фоне этого проваливаются более 70% проектов трансформации по всему миру. И так будет, пока в эти два красивых слова будут вкладывать всё что угодно, кроме принятия цифровых технологий внутри всех процессов управления. И это касается и гигантов рынка, и самых небольших компаний. Так почему мы все трансформируемся, трансформируемся, да так и не вытрансформируемся?