Наша отрасль изобилует словами из английского языка. Но надо помнить, что после русификации произношение слова часто становится совершенно не похоже на оригинал.
Чтобы больше не ставить англоязычных коллег в тупик на зум-коллах, мы попросили нашего коллегу Адама Дэйли озвучить произношение терминов, в которых русскоговорящие специалисты часто делают ошибки.
Примеры формулировок требований в соответствии с руководством по написанию требований от INCOSE
Статья содержит примеры формулировок требований как правильных (т.е. с точки зрения соответствия правилам руководства), так и неправильных (т.е. с точки зрения нарушения правил руководства).
Метрика CLV/CAC – это метрика, которая вводит в заблуждение.
Ели коротко, то вывод о том, что метрика CLV/CAC вводит в заблуждение является прямым следствием, в том числе, и моей предыдущей статьи, которую можно посмотреть по ссылке:
Юнит-Экономика - главное о метрике CLV (Customer Lifetime Value)
Напомню, что ключевым выводом указанной публикации является то, что в основе метрики CLV лежит известная из финансов и инвестиционного анализа метрика NPV, т.е. проще говоря мы можем определить CLV как
CLV = NPVc = PVc - CAC , где
CLV – Customer Lifetime Value (пожизненная стоимость клиента);
NPVc – Чистая приведенная стоимость денежных потоков по клиенту;
PVc – Чистая приведенная стоимость операционных денежных потоков по клиенту;
САС – первоначальные затраты на привлечение клиента.
Не так давно у меня появился интерес узнать, какие вообще нынче есть подходы и отношения к Юнит тестированию. Сделано это было скорее в познавательных целях. Сравнив труды по популярности, я решил ознакомиться с книгой "Unit Testing: Principles, Practices, and Patterns (Vladimir Khorikov)". Я не ставлю своей задачей полностью рецензировать данный труд, но не могу не обратить внимание на некоторые тезисы данной книги, которые часто вижу и слышу и о которых хотелось бы поговорить.
У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).
Данная итоговая сводка содержит определения, краткое описание свойств, которыми должны обладать качественно сформулированные потребности/требования, а также наборы потребностей/требований. В итоговой сводке содержится краткое изложение правил написания качественных потребностей/требований, а также их атрибутов.
Данная статья - перевод с английского языка итоговой сводки по написанию требований.
На Хабре уже писали, кто такие деврелы, и не кто-нибудь, а одна из топ-деврелов русскоязычного пространства Женя Голева. Рекомендую сначала заглянуть в статью Жени, а потом продолжать читать, если вдруг вы вообще ничего не знаете про деврел. В целом понятие относительно новое, в СНГ — уж тем более, и из-за нашей локальной специфики окутанное ложными представлениями, тайнами, мифами и легендами.
Меня зовут Вероника Ильина, я Head of Developer Relations в Dodo Engineering уже почти два года. И я очень люблю «Разрушителей мифов». Так что в этой статье пройдусь по популярным мифам, живущим в головах разработчиков, эйчаров, бизнес-заказчиков деврелов и самих деврелов.
Возьмите чашечку чая, устройтесь поудобнее и погнали рассуждать про деврел.
Представьте, что вам нужно попасть из точки А в точку Б. Вы можете дойти пешком, прокатиться на велосипеде, сесть на поезд или вызвать такси. Скорость, сложность и материальные затраты будут напрямую зависеть от выбранного варианта передвижения.
При этом в одних случаях вы можете совершенно точно знать маршрут, расстояние и какое транспортное средство выбрать, а в других путь будет очерчен только приблизительно.
С разработкой похожая ситуация: подход определяет способ реализации поставленной цели. Он организует рабочий процесс, влияет на распределение ресурсов, формирование команды и взаимодействие между различными участниками процесса. Выбор подхода, который соответствует вашей цели и обстоятельствам, позволяет оптимизировать всю работу, сэкономить время и деньги и прийти к ожидаемому результату.
В этой статье мы подробно рассмотрим, что такое продуктовый и проектный подходы, а также расскажем, в каких ситуациях лучше применять каждый из них.
Итак, поехали.
В большинстве своем понимается как "что-то связанное с компьютерами". Я входил в ИТ задолго до того, как это стало модно. Когда айтишник и математик в представлении обывателя выглядели совершенно одинаково. Сейчас айтишниками называют и продукт менеджеров, и дизайнеров и маркетологов. В общем - опрятный_человек_за_двумя_мониторами_стоковое_фото.жпг. Но мне хочется углубиться в это понятие и дотошно разобрать, что же такое "Информационные технологии" на самом деле.
Почему неопытным и даже уже сертифицированным специалистам стоит знакомиться с новыми версиями материалов по подготовке
Кому актуально:
• Тестировщикам, которые уже имеют сертификат и хотят узнать что нового в версии 4.0
• Тем, кто собирается получать сертификат и думает стоит ли бежать сейчас или уже сдавать по новой версии силлабуса
• Всем, кто предпочитает подкреплять свои знания стандартами/ авторитетными источниками
• Структурировать базовые знания в области тестирования
• Для прохождения/проведения собеседований: к сожалению и сейчас есть Интервьюеры которые ожидают услышать что верификация это статическое тестирование. В интернете тоже можно увидеть инфу что Security тестинг это функциональное тестирование. И где же правда? На что опираться и чем подкрепить свой ответ?
• Для НЕ тестировщиков кому интересно что из себя представляет ISTQB сертификация (например для PM)
Обзор версии 4.0 / Основные изменения силлабуса / Преимущества и недостатки новой версии / Советы по подготовке к экзамену / Примеры экзаменационных задач из сэмплов
На западе существует общеизвестный The Jargon File, история которого уходит аж в 70-е годы прошлого столетия. К сожалению, я не знаю, существует ли более-менее современный русскоязычный словарь айтишного сленга, но попытки создать что-то подобное, хоть и в меньшем масштабе, несомненно, предпринимались. Одна из таких попыток - это КАРДАН - краткий англо-русский дикционарий Академии Наук. Небольшой словарик, родившийся, как следует из названия, в одном из подразделений Академии Наук СССР приблизительно в конце-середине 80-х годов.
Привет, Хабр!
Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.
Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)
Когда пару лет мы решили заказать разбор нашего сайта, мы хотели получить обратную связь от обычного пользователя, не профессионала VPN. Чего мы не ожидали — что получим мнение человека, дезинформированного маркетингом VPN-провайдеров. VPN-провайдеры и маркетологи, заполонившие интернет псевдорейтингами VPN, существующими только ради партнёрских ссылок, убеждают пользователей в том, что VPN — волшебная палочка интернет-безопасности, одним махом обещающая полную анонимность, защиту переписок, аккаунтов и кредитных карт, неуязвимость для хакерских атак, а ещё экономию на авиабилетах и аренде машин и покупках в интернет-магазинах.
В этой статье мы сделали гид по маркетинговым мифам и заблуждениям о VPN, и порочным коммерческим практикам, сознательно культивируемых VPN-компаниями.
Мы продолжаем наш цикл статей о тестировании. Ранее мы узнали о распространённости юнит тестирования в среде разработчиков, а также о том, стоит ли нам, разработчикам, тестировать свой код (спойлер: всё же скорее стоит). Сегодня же мы затронем несколько более прикладную часть грамотного процесса тестирования, а именно создание тест кейсов. Первоначально выделение кейсов может показаться разработчику тривиальной задачей, но, как мы скоро увидим, данный процесс можно определить некоторым набором правил.
Дорогой читатель, в этом посте мы с тобой рассмотрим 6 аббревиатур и подумаем когда их применение уместно.
Потоковая передача данных — один из наиболее актуальных терминов в сфере технологий для создания масштабируемых приложений реального времени в облаке и инновационных бизнес-моделей. Какие топ-5 тенденций потоковой передачи данных ждут нас в 2023? В статье разберем это и расскажем, какую роль в движении данных играет Apache Kafka. Узнайте о децентрализованной сети передачи данных, облачном лейкхаусе, совместном использовании данных и расширенном управлении данными.
Потоковая передача данных с помощью Apache Kafka — это приключение и эволюция для приведения данных в движение. Тенденции меняются с течением времени, но основная ценность масштабируемой инфраструктуры реального времени как основного центра обработки данных остается неизменной.
В предыдущих частях серии статей мы рассмотрели принципы работы преимущественно с точки зрения приложения. В этой заключительной части мы фокусируемся на инфраструктуре.
Серия статей состоит из следующих связанных частей:
Часть 1: Сообщение producer’а;
Часть 2: Подъем consumer’ов;
Часть 3: Смещения и как с ними справляться;
Часть 4: Мой кластер потерян! — Принятие неудачи.
Обычно предприятия используют Kafka в качестве основы для своей платформы обработки данных. Дело в том, что она справляется с широким спектром критически важных для бизнеса рабочих нагрузок. Но рано или поздно все может быть обречено на провал. Вот почему важно учитывать неудачи при проектировании (да, ошибки реальны) вашей общей архитектуры и мыслить терминами резервного копирования и аварийного восстановления.
Уважаемые читатели, эта статья будет для вас полезна, если:
• Вы являетесь действующим архитектором ИТ и вам необходима дискуссия с коллегами о роли архитектора;
• Вы хотите стать архитектором, но еще не осознали, кто это;
• С вами рядом работает архитектор, и вы не понимаете, чем он занимается;
• Вы не владеете английским, но давно хотели прочитать книгу западного автора по архитектуре;
• И в целом если вы интересующийся современными веяниями ИТ, а именно архитектура является популярным запросом от работодателей в виду растущих масштабов автоматизации.
Когда я в последний раз менял работу и проходил собеседования, конечно, основные вопросы были про навыки продакта и особенности продуктов, которыми я занимался. Вопросы касались метрик, экономики продукта и взаимодействия с пользователями. Поскольку мой опыт специфичен :), в какой-то момент у меня даже закралось сомнение, а точно ли я продакт? Начал размышлять, откуда родился такой вопрос — и понял.
Много статей написано про то, как развивать продукты и как быть их владельцем. Чаще всего в статьях рассказывают о приложениях для вызова такси, агрегаторах объявлений, маркетплейсах, социальных сетях или интернет-магазинах. В общем, это всегда рассказ о том, как сделать лучше жизнь сотен тысяч или даже миллионов пользователей. Такие статьи круто читать, и в них много не только интересных примеров, но и действительно полезных ходов и приёмов.
Но чаще всего авторы обходят стороной продукты, которые существуют для гораздо меньшего числа пользователей, и которыми пользуются те команды, которые делают большие, классные и успешные продукты. Я говорю о внутренних ИТ-продуктах компаний.
Меня зовут Денис Соловьев, и так получилось, что я работал и продолжаю работать как раз на таких внутренних ИТ-продуктах. Я хочу сравнить, какие из инструментов и подходов работают для них.
Это вторая по счету статься из цикла про SQL инъекции. В данном статье мы с вами рассмотрим особенности SQL инъекций при использовании команды UNION.
