Анализ и проектирование систем *

Здравствуйте, хабражители!

Прочитав здесь о сравнении смс-сервисов для рассылок, мы решили рассказать вам о своем опыте построении подобной системы, которая верой и правдой служит нам несколько лет и постоянно дорабатывается и совершенствуется. Надеемся, наш опыт будет вам полезен. В общем, тем, кому интересно, прошу под кат.

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

UPD: Обновленная видеоверсия статьи на Youtube (лекция записана в Киевском политехническом институте 18 апреля 2019 года в рамках курса «100 видео-лекций по программированию»):

Эта статья — краткий пересказ невероятно интересного доклада Скотта Майерса для тех, у кого нет 70 минут на весь доклад, но есть 7 минут на основные тезисы.

Некоторые люди, которые не пишут на С++, а лишь слышали об этом языке, задаются вопросом: «Почему вообще кто-то пишет на C++?». Но есть люди, которые используют С++ каждый день, и вот эти люди задаются вопросом: «А действительно, почему я пишу на этом языке?».

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

Язык, который был бы получен в результате принятия всех предложений, выходил слишком сложным и тогда Бьёрн Страуструп сказал «А помните Ваза?». Никто, кроме людей из Швеции, не понял о чём речь. Ваза был огромным боевым кораблём, построенным в Швеции в 1625 году. Основным принципом постройки корабля было «А почему бы нам не добавить сюда ещё и вот такую фичу?». Многие из идей исходили непосредственно от короля, в частности он лично утверждал размеры корабля. Также на Ваза по указаниям свыше требовалось нацепить огромное количество элементов украшения, резьбы, большое количество пушек и т.д. А королю ведь не откажешь. Итог был закономерным — из-за ошибок в конструировании Ваза затонул в первом же рейсе, едва выйдя из бухты.

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

На идею этой статьи меня натолкнула реклама на Youtube. В очередной раз, когда я включал ребёнку мультфильм «про мамонтёнка», Youtube решил порадовать нас перед этим самым мультфильмом рекламой какого-то кинофильма с кадрами убийств и насилия (16+). Данный подход хорошо тренирует скорость и реакцию родителей — нужно успеть нажать «Skip Ad», как только это становится возможным. В результате я, как потенциальный потребитель, не почувствовал всей прелести рекламируемого в ролике продукта — рекламная компания провалилась, рекламодатель терпит потенциальные убытки.
Попробуем совместно разобраться как современные технологии могут улучшить эту ситуацию.

Работа с БД: список JDBC подключений с указанием параметров подключений.

Компания из ТОП-5 в России зарабатывает в среднем от 7 до 9 миллионов долларов за час. Соответственно, технический простой длиной в два часа, который удалось сократить до одного часа нечеловеческим усилием воли, стоит именно эту сумму.

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

Сейчас расскажу, как мы внедряли такие системы.

Многие сложные системы удается исследовать только моделированием. Для систем, состоящих из большого количества независимых объектов, такие как поведение толпы, развитие многоклеточных организмов или военные операции, наиболее адекватным оказывается агентное моделирование. Есть много предназначенных для этого систем, например российская проприетарная AnyLogic.
Я же хочу рассказать об языке NetLogo, хорошо зарекомендовавшим себя в образовании, но годный и для взрослых задач.

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

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

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

С годами компания обычно доходит до того, что много справочников на одну тему (например, «Хобби» или «Пол») хранятся в совершенно невообразимых форматах в различных системах, препятствуя эффективной интеграции и обмену данными.

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

Хотите знать, что именно мы сделали, и какую роль в нашем продукте играют Lucene и Apache CXF?

Сегодня на airbnb вышел очень интересный пост о том, как они делают A/B-тесты. Мне показалось, что перевод данной статьи будет интересен Хаброжителям, так как многие создают собственные проекты, и методы анализа airbnb как максимум могут оказаться полезными, как минимум позволят задуматься о том, что неплохо бы тестировать метрики вашего продукта.

Изюминка Analyst Days – в ее участниках


24 мая в третий раз системные и бизнес аналитики смогут с головой окунуться в свою профессиональную область на международном уровне благодаря Analyst Days III – единственной конференции на пространстве СНГ, которая собирает экспертов из разных городов и стран в одном месте.

Конференцию Analyst Days мы задумали около 3 лет назад, когда пришла идея отстраниться от распространенного формата универсальных конференций, которые в ограниченные временные рамки пытаются включить «все и ничего»: продуктовую разработку, управление проектами и персоналом многое-многое другое. Порой тема анализа на таких конференциях вообще забывается. Нам же хотелось сделать что-то совершенно иное и, что немаловажно, более полезное, пусть и для менее широкого круга людей.

Прочитал, что пишут на хабре про мозговые штурмы и нашел, что такого еще не писали. Последняя статья про мозговые штурмы называется «Миф об эффективности мозговых штурмов», но при этом наоборот преподносит мозговые штурмы как один из наиболее эффективных инструментов исследования. Основная мысль той статьи — это позволять критиковать во время обсуждений, тогда все будет хорошо. На самом деле не все так просто и есть другая проблема мозговых штурмов.

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

В последнее время в научных публикациях всё чаще упоминается алгоритм достижения консенсуса в распределенных системах под названием Paxos. Среди таких публикаций ряд работ сотрудников Google (Chubby, Megastore, Spanner) ранее уже частично освещенных на хабре, архитектуры систем WANdisco, Ceph и пр. В то же время, сам алгоритм Paxos считается сложным для понимания, хоть и основывается он на элементарных принципах.

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

Публикуем статью, написанную на основании предыдущего доклада Ирины Суровой с прошлой конференции Analyst Days. В этом году Ирина выступает не только в роли докладчика, но и члена программного комитета будущей московской конференции.

Введение

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

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

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

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

Уважаемые сейлы, менеджеры продуктов и проектов – давайте активнее продвигать документацию. Давайте на ней зарабатывать!

Доброго дня, $habrauser!
Чем мы сегодня с вами поделимся? Решением.



Долго анализировали вопросы виртуализации. Везде одно и то-же. Стоимость vcpu, память, иопсы… скучно.
Появилась некая модель: мы не желаем продавать пресловутый человеко-час. Хорошая книга, но сейчас не об этом.
Нужно дать возможность не просто работать со своими виртуальными ресурсами, а создавать их.
Нам очень понравилось решение Mirantis с их проектом Fuel. Что из этого получается? Получается модель DCaaS — не нам проектировать стандарты и названия, но как нам кажется правильный подход.

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

Введение

При работе с требованиями возможно применение различных методов их организации: от метода полного хаоса, до интеграции требований с программным кодом (статья Пять уровней зрелости требований). Постепенно улучшая работу с требованиями, обычно, в процесс начинают внедрять различные новые методологии и инструменты. Одним из классов инструментов, призванных упростить работу с требованиями, являются специально обученные «зверьки»: Системы Управления Требованиями (СУТ). Основными возможностями таких систем являются:

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

Среди данных программ есть известные «Монстро-звери», такие как: IBM Rational DOORS, Borland Caliber, Polarion Requirements и др. с большим количеством функциональных возможностей. Такие системы, как правило, являются хорошо зарекомендовавшими себя, но дорогостоящими. Однако среди данного перечня есть маленькие, бесплатные, малоизвестные, но очень полезные «зверьки» типа Axiom.

До Международной конференции по системному и бизнес анализу «Analyst Days-2014», которая пройдет 24 мая в Москве, еще чуть больше месяца, а свободных мест уже почти не осталось. Кто еще хочет попасть на мероприятие, тому стоит поспешить, чтобы обеспечить себе местечко!



Возможно, мешают пройти регистрацию сомнения, нужна ли вам конференция или нет? Тогда окончательно убедят вас посетить столь значимое мероприятие сферы несколько эксклюзивно подготовленных интервью со спикерами конференции – Ириной Суровой, системным аналитиком в R&D «Лаборатории Касперского», и Денисом Бесковым, руководителем «Школы системного анализа». Из беседы вы узнаете, какие ключевые качества нужны аналитикам, почему важно посещать отраслевые конференции и что ждет участников «Analyst Days-2014».

В этой статье я хочу описать основы использования продукта QlikView от компании QlikTech, предназначенный для бизнес-аналитики (Business intelligence). Осторожно, много спойлеров.