Шаги по разработке большой компьютерной программы для доставки заказчику

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

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

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

HR-специалист одной компании недавно сказал такую фразу: “разработчики не хотят к нам идти, как только узнают, что мы работаем по Agile”. И хотя я сам нередко слышу недовольство, высказываемое разработчиками в отношении Agile, такая категоричность меня удивила.

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

Почему же не стыкуются отзывы реальных разработчиков с декларируемыми целями Agile?

«Наш продукт популярен на внутреннем рынке, поэтому теперь мы думаем выходить на международный. С чего мне начать как менеджеру по продукту?»

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

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

В этой статье мне хотелось бы пройтись по моему контрольному списку вопросов, составленному на основе общепринятых рекомендаций по локализации и моего 10-летнего опыта международного масштабирования программных продуктов (это и мобильные игры, и B2C-приложения для массового рынка, и SaaS-продукты B2B).

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

Для начала — основные понятия:

• Глобализация — подготовка продукта к работе на разных рынках. Сюда относится различные аспекты маркетинга, дизайна и технологической реализации.
  
• Интернационализация (сокращенно — i18n) — обеспечение максимальной универсальности продукта, создание прочного фундамента для локализации и перевода.
  
• Локализация (сокращенно — l10n) — адаптация продукта к определенным региону, культуре и языку.
  
• Перевод (сокращенно — t9n) — собственно перевод продукта на новый язык.
  

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


Взаимоотношение различных процессов в рамках продукта. Источник: блог Adobe.

Переведено в Alconost

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

В нём всё, конечно, крутится вокруг JavaScript. Поэтому если вы используете для веб-разработки JS — я очень рекомендую взглянуть на State of JavaScript в том случае, если вы ещё этого не сделали.

Для меня одним из самых интересных результатов State of JavaScript стало неожиданное внимание тех, кто участвовал в опросе, к фронтенд-фреймворку Svelte.

В общем рейтинге ведущих фронтенд-инструментов (основанном на показателях осведомлённости о фреймворке, интереса к нему и удовлетворённости им) Svelte появился на второй позиции. Он идёт там сразу после React, опережая такие хорошо известные инструменты, как Vue.js, Preact, Angular и Ember.
Меня это слегка шокировало, так как Svelte — это сравнительно новый инструмент — как в плане возраста, так и в плане парадигмы разработки программного обеспечения.

Рейтинг фронтенд-фреймворков по результатам исследования State of JavaScript

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

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

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

Одной из наиболее популярных методологий улучшения качества разрабатываемых приложений является Test-driven development (TDD). Но эффективна ли методология TDD для разработки встраиваемых систем? Ответ на этот вопрос будем искать под катом.

Привет! Меня зовут Люба, и я QA инженер команды разработки систем для контакт-центра в Lamoda.

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

Тема капч не нова, в том числе для Хабра. Тем не менее, алгоритмы капч меняются, как и алгоритмы их решения. Поэтому, предлагается помянуть старое и прооперировать следующий вариант капчи:



попутно понять работу простой нейросети на практике, а также улучшить ее результаты.

   Уже не помню, как я наткнулся на статью habr.com/ru/post/464337, но она запала мне в мозг и не давала покоя вплоть до минувшего дня. Несколько раз я пытался понять происходящее, пару раз пытался заставить это работать, но безрезультатно: я совершенно ничего не понимаю в нейронных сетях и даже программирую не как настоящий программист.

Вместо введения

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



Совершенно неожиданно мне написала моя научная руководительница — она предложила написать исследовательскую статью, которая как раз входит в мою сферу интересов — журнал собирал публикации на тему игр. Вау! Как вы помните, у меня как раз были наброски того, что можно было бы изучить. Так и родилась эта статья. Результаты и рассуждения — под катом.

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

Под катом ожидания, реальность и выгорание инди-разработки. А в конце — ссылка на демо, можно прочувствовать, как близко автор был к успеху.

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

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

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

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

CL: "changelist" — список изменений кода, отправленный в систему контроля версий на ревью. Аналог Pull Request в GitHub или Merge Request в GitLab.

Когда проигрываешь в мультиплеере, проще всего обвинить баланс — рандом, пушка имба и далее по списку. Но где эта грань между тем, когда не хватило собственного скилла и когда у игры есть реальные проблемы?

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

Предлагаем вам познакомиться с переводом статьи Jamie Bullock, опубликованной на сайте medium.com. Автор рассказывает, какие веб-приложения он обычно использует в работе.

Быстрый вход в управление продуктом через Open Source

Фотография сделана Finn Hackshaw на Unsplash

“Как вы достигли успеха в управлении продуктом”?

Это вопрос, с которым рано или поздно сталкивается каждый продукт-менеджер. По мере того, как управление продуктом перестает быть просто маркетинговой функцией, возрастает и привлекательность этой роли.

Если это вам действительно интересно, то цифровому миру найдется, что предложить. Существует огромное количество каналов Slack, групп Facebook, групп LinkedIn и обучающих курсов, в которых можно участвовать, вовлекаться и учиться. Продукт — это огонь. А управлять им еще жарче.

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

Всем привет.

Я бэкэнд разработчик и фронтэнд задачи решаю как умею, то есть на jQuery, это работало в 2015, работает и сейчас. Но при наличии Vue и React это уже не камильфо. Из любви к особому пути я решил осваивать не проверенный миллионами разработчиков Angular/React/Vue, я решил попробовать Svelte.

Сделав пару упражнений из учебника, я решил перейти к практике. Для этого я взял одно из своих успешно выполненных тестовых заданий.

По заданию надо было сделать просмотр списка задач и одной задачи из этого списка, CRUD не нужен.

Клиентская часть выполнена как SPA, и вся работа с DOM ведётся через jQuery, для замены jQuery на Svelte это отличный кандидат.

Ниже я расскажу о самых первых препятствиях на этом пути и конечно о том как их преодолеть.
Учебник по Svelte очень доступный и наглядный, но как внедрить Svelte в произвольный проект не очень понятно, ведь Svelte это не библиотека как jQuery, это компилятор, то есть код написанный с использованием директив Svelte надо каким то образом откомпилировать в нативный JS.

Другим камнем преткновения было использование

$

в Svelte это зарезервированный символ, поэтому его использование в коде который будет скомпилирован Svelte приводит к ошибке:

[!] (plugin svelte) ValidationError: $ is an illegal variable name

Каждые несколько лет в индустрии разработки ПО происходит смена парадигмы. Одним из таких явлений можно признать рост интереса к концепции микросервисов. Хотя микросервисы — это технология не самая новая, лишь в последнее время её популярность буквально взлетела до небес.

Большие монолитные сервисы в наши дни заменяют независимыми автономными микросервисами. Микросервис можно рассматривать как приложение, которое служит единственной и очень специфической цели. Например — это может быть реляционная СУБД, Express-приложение, Solr-сервис.



В наши дни сложно представить себе разработку новой программной системы без применения микросервисов. А эта ситуация, в свою очередь, ведёт нас к платформе Docker.

Есть неожиданно много людей, считающих, что писать код можно как угодно, а все эти правила и рекомендации просто занудство. Что же, у каждого каждого человека есть право на своё мнение.

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

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

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

В этой заключительной части нашей серии архитектур микросервисов мы научимся включать сервер имен Eureka и позволять микросервисам взаимодействовать с ним.

Это статья входит в серию статей «Микросервисы со Spring Boot»:

• Часть 1. Начало работы с архитектурой микросервисов
• Часть 2. Создание микросервиса Forex
• Часть 3. Создание микросервиса конвертации валют
• Часть 4. Использование Ribbon для балансировки нагрузки
• Часть 5. Использование сервера имен Eureka

В этой серии статей вы познакомитесь с концепцией микросервисов и узнаете, как создавать микросервисы с помощью Spring Boot и Spring Cloud.

Это руководство поможет вам изучить основы микросервисных архитектур. Мы также начнем рассматривать базовую реализацию микросервиса со Spring Boot.

Мои последние исследования, результат которых описан в предыдущих статьях, привели меня к мысли: а что, если создать систему, противоположную Системе подавления — Систему Раскрытия Потенциала, применимую к планете Земля и человечеству? Данная система описывает правила такого устройства многомерной среды обитания существ, в которой энтропия сознания сведена к минимуму. Живущие/играющие в ней существа реализуют весь доступный им Потенциал — совокупность всех их интеллектуальных, физических и всех прочих ресурсов, данных им во всём пространстве и времени, в полном объёме. Иначе говоря, как сделать идеальную игру?

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

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

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