На днях мы получили очередную новость о санкциях США в области электроники: прекращены поставки компонентов для российских проектов по освоению космоса. Подобные темы в последнее время активно обсуждаются на сайтах ведущих СМИ о высоких технологиях. Например, только вчера на портале CNews появилась статья о том, как по поручению Правительства РФ будет разработан большой план по переходу на отечественные разработки в продуктах для оборонно-промышленного комплекса. Читателям показали фотографию российского микропроцессора «Эльбрус» (см. выше), а также процитировали министра связи Николая Никифора, который верит в то, что в России «примерно за 5 лет возможно разработать целый ряд платформенных решений — в том числе и операционную систему для мобильных устройств». В заключении статьи министр призывает отечественных разработчиков электроники и софта сфокусироваться на мировом рынке вместо того, чтобы создавать продукты локального масштаба, т.к. у России есть потенциальные рынки для экспорта своих технологий.
 
Эта публикация оказалась очень созвучна с тезисами выступления, которое мы — команда Promwad — готовили для форума «Живая электроника России» еще в 2010 году. Сегодня, четыре года спустя, наши идеи оказались весьма актуальными. Предлагаем читателям Хабра познакомиться с текстом под катом и высказать в комментариях свое мнение.

Вот так звучал наш манифест в защиту национальной электроники (текст и слайды):
 
Российская электронная отрасль не использует потенциальные возможности для более эффективного развития. Наши разработки в целом неконкурентоспособны как на мировом рынке, так и на внутреннем. Этот факт был не раз озвучен участниками крупнейших отраслевых форумов и конференций, подтверждают его и результаты исследований рынка.
 
На экспорт уходит только 5% электроники с ярлыком «произведено в России» (как мы знаем, этот индикатор — один из показателей конкурентоспособности, он отображает глубину интеграции в мировой рынок). Доля российской электронной продукции на международном рынке достигает только 0,05% (мизерная цифра, учитывая, что один только наш внутренний рынок — это 3% от потребления электроники во всем мире). Национальные компании не являются хозяевами даже на собственной территории, довольствуясь лишь пятой частью внутреннего рынка.
 
А в это время на мировой арене появляются новые центры экономического развития, которые оказывают всё большее влияние на расстановку сил в отрасли. Китай, Индия и Бразилия производят более 30% электроники для мирового рынка, опережая США, страны ЕС и Японию.
 

 
Конечно, национальные проблемы в электронной отрасли не остались без внимания. За развитием бизнеса в сфере радиоэлектроники пристально следит государство, коммерческие компании и венчурные инвесторы. Эксперты отрасли регулярно публикуют свои редакции списка рекомендаций для решения назревших проблем электронной промышленности. Отраслевые ассоциации, министерства и Правительство РФ также с готовностью предлагают целый набор программ. Последним документом такого рода стал проект «Стратегии развития электронной отрасли России до 2025 года», разработанный АПЭАП по поручению Минпромторга.
 
Разработчики названного документа предполагают, при удачной реализации программы доля отечественных разработок на внутреннем рынке электроники сравняется с импортной и достигнет 50%, а на мировом это показатель будет равен 5% (т.е. вырастет в 100 раз!). Но достижение лидерства России в приоритетных областях на зарубежных рынках планируется только в долгосрочной перспективе. А в ближайшие годы, по мнению разработчиков стратегии, предприятия должны сформировать фундамент для достижения этой цели, т.е. для начала проработать сценарий «продуктовая компания — инфраструктурное оборудование — российский рынок» (см. рисунок ниже, верхний ряд).
 

Варианты развития российских компаний-производителей и разработчиков электроники
 
Однако без ориентации на экспорт компании не смогут предложить более интеллектуально насыщенную электронику и тем самым выделиться на фоне массовой продукции Юго-Восточной Азии. Только работая в высоко конкурентной среде западных рынков по сервисной модели с ориентацией на экспорт потребительской электроники (см. рисунок, нижний ряд), можно впитать новую бизнес-культуру — нацеленность на быстрый результат, поиск тонкой грани между себестоимостью продукции и инженерными решениями. Это единственная возможность для внедрения более эффективных бизнес-процессов. Только на собственном опыте можно понять, что такое бизнес в сфере массовой потребительской продукции, что в действительности включает в себя понятие «качественное производство» и как с ним работать. Пока в России этого нет. И подобный опыт просто так, без реального погружения, получить невозможно, не помогут даже самые лучшие эксперты и консультанты.
 
Такие страны как Китай, Корея, Тайвань, Вьетнам, Индия и Япония смогли добиться видимых успехов в отрасли электроники благодаря тому, что они не замыкались на внутренних рынках, а впитывали зарубежные инвестиции и/или зарубежный опыт. Они не проходили свой путь в одиночку.
 

 
Только создавая российский интеллектуальный капитал в области электроники, следуя формуле «российский интеллект + российский капитал = российский интеллектуальный капитал» мы сможем достичь успехов и догнать мировую отрасль став реальным партнером и конкурентом на мировом рынке. Необходимо использовать общепризнанные мировые бизнес-модели, для которых характерно впитывание знаний западных специалистов. У них необходимо учиться управлению, организации бизнес-процессов, использованию технологий, и интегрироваться в мировую инфраструктуру. Только наращивая национальный интеллектуальный капитал, российская электроника сможет интегрироваться в мировую индустрию.
 

 
При этом в качестве рабочих моделей необходимо рассматривать такие варианты как:

• российская фаблесс-компания + западная фабрика;
• западный чип-вендор + российская фабрика;
• западный производитель потребительской электроники + российская EMS-компания.

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

1. Отсутствие корпоративной стратегии.
2. Сырые бизнес-процессы и организационные структуры.
3. Отсутствие интеграции с мировыми лидерами.
4. Работа на рынках с искусственно ограниченной конкуренцией.
5. Отсутствие кооперации в отрасли.
6. Дефицит специалистов и слабая инженерная культура.

Государственные стратегии и программы — это не панацея. Если игроки отрасли переложат бремя ответственности за свою судьбу на плечи министерств и отраслевых ассоциаций, существующая ситуация на электронном рынке не изменится. Пока каждый руководитель не осознает тот факт, что он может (и должен!) сам, без внешней помощи, сделать конкретные шаги по выходу на внешние рынки, планы перспективного развития так и останутся нереализованными.
 
P.S. Грустная статистика из первого абзаца наших тезисов была получена из «Стратегии развития электронной отрасли России до 2025 года» (полный текст в формате DOC доступен на сайте Минпромторга, который до конца 2014 года должен разработать программу импортозамещения для ОПК).
 

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

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

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

Как BPM-система помогает бизнесу?

BPM-система – это пример проверенной и отлаженной схемы взаимодействия. Объединив в себе хранилища данных, инструменты для оперативной работы с ними и средства Business Intelligence, ранее действовавшие локально, BPM-система стала полноценным и самодостаточным средством управления эффективностью бизнеса.

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

В этом особенность BPM-решений, из которой вытекает целый ряд отличий от систем электронного документооборота:

Роль KPI в операционном управлении процессами

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

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

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

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

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

О BPM-системах, в функционале которых развернуты инструменты KPI для управления бизнес-процессами компании, я расскажу вам в своем следующем посте.

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

Всем привет!

Друзья, не мне вам рассказывать, да и сами вы знаете о том, как делается backend для серверных/клиент-серверных приложений. В нашем идеальном мире всё начинается с проектирования архитектуры, затем выбираем площадку, затем прикидываем нужное количество машин, как виртуальных, так и нет. Затем происходит сам процесс поднятия архитектуры для разработки/тестирования. Всё готово? Ну поехали писать код, делать первый коммит, обновлять код на сервере из репозитория. Открыли консоль/браузер проверили и поехало. Пока всё просто, а что дальше?

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

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

Можно сразу подумать что мы ничего не слышали про aws, jelastic, heroku, digitalocean, puppet/chief, travis, git-hooks, zabbix, datadog, loggly… Уверяю вас это не так. Мы пытались подружиться с каждой из этих систем. Точнее мы настраивали каждую из этих систем для себя. Но не получали должного эффекта. Всегда появлялись какие то подводные камни и часть работы хотелось бы, как минимум, автоматизировать.

Живя в таком мире довольно большое количество времени, мы подумали — «ну мы же разработчики, давай-те сделаем с этим что-то». Прикинув проблемы, сопровождающие нас на каждом этапе создания и развития проекта — выписали их на отдельной страничке и превратили их в фичи будущего сервиса.
И спустя 2 месяца из этого родился сервис — lastbackend.com:

Проектирование

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

Сам процесс проектирования схемы до боли простой и интуитивный: слева список элементов backend-а, справа рабочее поле. Вот просто берём и перетаскиваем. Надо дать возможность node.js элементу подключиться к mongodb? Пожалуйста — берем и мышкой проводим соединение.

Настройка и масштабирование

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

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

Развёртывание

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

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

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

Аггрегация логов

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

Мониторинг и система оповещения

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

Резюме

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

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

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

PS

Так же друзья, если интересно, можем начать серию технических статей по стеку используемых технологий, а именно node.js, mongodb, redis, sockets, angular, svg и т.п.

На тему «использование MongoDB вместо memcached» гуглится немало историй успеха. Такое ощущение, что есть широкий класс задач, для которых эта идея работает неплохо: прежде всего это проекты, где интенсивно используется тэгирование кэша. Но если вы попробуете, то заметите, что в MongoDB не хватает функции удаления из кэша записей, которые читаются реже всего (LRU — Least Recently Used). Как поддерживать размер кэша в разумных рамках? LRU — это, кстати, «конек» memcached; вы можете писать в memcached, не задумываясь о том, что ваш кэш переполнится; но как же быть с MongoDB?

Раздумывая над этим, я написал на Python небольшую утилиту CacheLRUd. Это демон для поддержки LRU-удаления записей в различных СУБД (в первую очередь, конечно, в MongoDB). Ферма таких демонов (по одному на каждой MongoDB-реплике) следит за размером коллекции, периодически удаляя записи, к которым доступ на чтение производится реже всего. Отслеживание фактов чтения той или иной записи кэша происходит децентрализовано (без единой точки отказа) по протоколу, основанному на UDP (почему так? потому что «наивный» вариант — писать из приложения в мастер-базу MongoDB при каждой операции чтения — плохая идея, особенно если мастер-база окажется в другом датацентре). Читайте подробности чуть ниже.

Но зачем?

Зачем может потребоваться заменять memcached на MongoDB? Попробуем разобраться. Понятие «кэш» имеет два различных типа использования.

1. Кэш применяют, чтобы снизить нагрузку на перестающую справляться базу данных (или другие подсистемы). Например, пусть у нас есть 100 запросов в секунду на чтение некоторого ресурса. Включив кэширование и выставив маленькое время устаревания кэша (например, 1 секунду), мы тем самым снижаем нагрузку на базу в 100 раз: ведь теперь до СУБД доходит только один запрос из ста. И нам почти не нужно опасаться, что пользователь увидит устаревшие данные: ведь время устаревания очень мало.
2. Есть и другой тип кэша: это кэш более-менее статических кусков страницы (или даже всей страницы целиком), и применяют его, чтобы снизить время формирования страницы (в том числе редко посещаемой). Он отличается от первого тем, что время жизни кэшированных записей велико (часы или даже дни), а значит, во весь рост встает вопрос: как же гарантировать, что кэш содержит актуальные данные, как его чистить? Для этого применяют тэги: каждый кусочек данных в кэше, имеющий отношение к некоторому крупному ресурсу X, помечают теми или иными тэгами. При изменении ресурса X дают команду «очистить тэг X».

Для первого варианта использования кэша ничего лучше, чем memcached, похоже, не изобретено. А вот для второго memcached буксует, и тут на помощь может прийти идея «MongoDB вместо memcached». Возможно, это как раз ваш случай, если ваш кэш:

• Относительно невелик (верхний предел — сотни гигабайт).
• Содержит много «долгоживущих» записей, устаревающих за часы и дни (или вообще никогда не устаревающих).
• Вы существенно используете тэги и полагаетесь на то, что операция очистки тэга должна работать надежно.
• Кэш хотелось бы сделать общим и одинаково легко доступным (т.е. реплицируемым) на всех машинах кластера, в том числе в нескольких датацентрах.
• Вам не хочется беспокоиться, когда одна из машин для кэша на какое-то время перестанет быть доступной.

MongoDB и ее репликация с автоматическим failover мастера (превращением реплики в мастера при «смерти» последнего) позволяют гарантировать надежность очистки того или иного тэга. В memcached же с этим проблема: серверы memcached независимы друг от друга, и для удаления тэга вам нужно «пойти» на каждый из них с командой очистки. Но что, если в этот момент какой-то из серверов memcached окажется недоступным? Он «потеряет» команду очистки и начнет отдавать старые данные; MongoDB данную проблему решает. Ну и, наконец, MongoDB очень быстра в операциях чтения, ведь она использует событийно-ориентированный механизм работы с соединениями и memory mapped files, т.е. чтение производится напрямую из оперативной памяти при достаточном ее количестве, а не с диска. (Многие пишут, что MongoDB настолько же быстра, как memcached, но я не думаю, что это так: просто разница между ними с огромным запасом тонет на фоне сетевых задержек.)

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

Установка CacheLRUd

## Install the service on EACH MongoDB NODE:
cd /opt
git clone git@github.com:DmitryKoterov/cachelrud.git
ln -s /opt/cachelrud/bin/cachelrud.init /etc/init.d/cachelrud

## Configure:
cp /opt/cachelrud/cachelrud.conf /etc/cachelrud.conf # and then edit

## For RHEL (RedHat, CentOS):
chkconfig —add cachelrud
chkconfig cachelrud on

## …or for Debian/Ubuntu:
update-rc.d cachelrud defaults

Как работает демон

Чудес не бывает, и ваше приложение должно сообщать демону CacheLRUd (ферме демонов), какие записи в кэше оно читает. Приложение, очевидно, не может это делать в синхронном режиме (например, обновляя в мастер-базе MongoDB поле last_read_at в кэш-документе), потому что а) мастер-база может оказаться в другом датацентре относительно текущей веб-морды приложения, б) MongoDB использует протокол TCP, грозящий timeout-ами и «подвисанием» клиента при нестабильности связи, в) негоже выполнять запись при каждом чтении, не работает это в распределенных системах.

Для решения задачи применяется протокол UDP: приложение посылает UDP-пакеты со списком недавно прочитанных ключей тому или иному демону CacheLRUd. Какому именно — вы можете решить самостоятельно в зависимости от нагрузки:

• Если нагрузка сравнительно невысока, посылайте UDP-пакеты тому демону CacheLRUd, который «сидит» на текущей мастер-ноде MongoDB (остальные просто будут простаивать и ждать своей очереди). Определить, кто в текущий момент мастер, на стороне приложения очень легко: например, в PHP для этого применяют MongoClient::getConnections.
• Если же один демон не справляется, то вы можете отправлять UDP-сообщения, например, демонам CacheLRUd в текущем датацентре.

Подробности описаны в документации.

Что еще есть полезного

CacheLRUdWrapper: это простенький класс для общения с CacheLRUd из кода приложения на PHP, оборачивающий стандартный Zend_Cache_Backend (правда, этот класс для Zend Framework 1; если перепишите его для ZF2 или вообще для других языков, буду рад pull-request’ам).

Zend_Cache_Backend_Mongo: это реализация Zend_Cache_Bachend для MongoDB из соседнего GitHub-репозитория. Оберните объект данного класса в CacheLRUdWrapper, и получите интерфейс для работы с LRU-кэшем в MongoDB в стиле ZF1:

 $collection = $mongoClient->yourDatabase->cacheCollection; $collection->w = 0; $collection->setReadPreference(MongoClient::RP_NEAREST); // allows reading from the master as well $primaryHost = null; foreach ($mongoClient->getConnections() as $info) {     if (in_array($info['connection']['connection_type_desc'], array("STANDALONE", "PRIMARY"))) {         $primaryHost = $info['server']['host'];     } } $backend = new Zend_Cache_Backend_Mongo(array('collection' => $collection)); if ($primaryHost) {     // We have a primary (no failover in progress etc.) - use it.     $backend = new Zend_Cache_Backend_CacheLRUdWrapper(         $backend,         $collection->getName(),         $primaryHost,         null,         array($yourLoggerClass, 'yourLoggerFunctionName')     ); } // You may use $backend below this line. 

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

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

Разработчики представили готовый прототип смартфона, фото которого — под хабракатом.

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

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

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

Смартфон состоит из каркаса, на который крепятся сменные компоненты. Модули могут включать процессор, память, Wi-Fi, разъем питания, дисплей, аккумулятор, камеру, колонки и так далее. Модуль соединяется с другими частями через специальные беспроводные соединения.

Это интересно:
Леонид Куприянович и его мобильники
30 лет первому коммерческому звонку по переносимому сотовому телефону
Возвращение героя: Nokia 3310