Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 980 сообщений
Cообщения с меткой

стандарты - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Как bot-to-bot в ближайшее время может заменить API-интерфейсы

Среда, 29 Июня 2016 г. 18:39 (ссылка)

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







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



Смерть API?



На сегодня, когда две системы программного обеспечения могут говорить друг с другом, разработчикам ПО необходимо осуществить интеграцию с использованием API (интерфейсы программирования приложений). Этот процесс отнимает много времени. Вот почему за последние несколько лет стали популярны такие услуги, как Zapier, Scribe и FTT. Они обеспечивают исключительные интерфейсы для сотен приложений, позволяя Вам присоединить, например, Вашу систему CRM к инструментами рассылки или платформой аналитики.



Однако, в эпоху bot-to-bot программные приложения могут говорить с системами друг друга, независимо от того имеют ли они существующую интеграцию API. Конечно, общение bot-to-bot не будет использовать обмен большим количеством данных, но оно создаст специальную связь между, например, пользовательским банковским программным обеспечением и интернет-магазином. Банковское ПО может поговорить с ботом интернет-магазина и попросить потерянный счет: «Моему клиенту нужен счет для заказа 45678, можете ли Вы предоставить его?».



Большой финал: bot-to-bot-to-consume



Красотой общения bot-to-bot является то, что оно будет происходить на простом английском языке; это будет разговор, который сможет понять каждый человек. При условии, что все разговоры между моим ботом Энни и другими ботами попадают в архив, я смогу вернуться и посмотреть, как они пришли к определенному выводу. В моем банковском примере, когда счет остается потерянным, я могу нажать на кнопку «подробнее» и открыть разговор Энни с интернет-магазином.



Но дальше все еще интереснее. Если мой бот зашел в тупик в разговоре с другим ботом, она может позвать меня на помощь: «Привет, это Энни, твой финансовый бот. Я разговариваю с поставщиком, но у меня возникают некоторые трудности в понимании того, что он мне говорит». Я могу присоединиться — конечно, если у меня есть несколько свободных часов (поскольку терпение ботов неограниченно) и перефразировать вопрос Энни, чтобы получить ответ от другого бота. Далее Энни может продолжать разговор и управлять моими делами.



Семантическая паутина



Разве мы не говорили 10 лет назад о присоединении одного онлайн сервиса к другому? Как оно называлось? Правильно, семантическая паутина. Каждый веб-сайт собирался быть аннотированным с использованием стандартных форматов данных, позволяя другим сервисам сканировать эти данные и использовать их в своей бизнес-логике. Я считаю, что боты будут выполнять подобное в ближайшие 3-5 лет и это означает, что все данные будут равномерно отформатированы. Вместо них боты продемонстрируют онлайн сервисы и данные на простом английском языке, позволяя людям и другим ботам взаимодействовать, даже если они ранее никогда не общались.



Созыв всех разработчиков программного обеспечения



Итак, разработчики программного обеспечения, когда Вы разрабатываете Вашу платформу для электронной коммерции, онлайн маркетинга, финансов, системы ERP (планирование ресурсов предприятия) или любого другого программного решения, пожалуйста, подумайте о реализации смарт-бот, кроме вашего традиционного API интерфейса.



Ссылка на оригинал статья
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/262539/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Об относительной яркости, или насколько живучим бывает легаси

Вторник, 28 Июня 2016 г. 14:56 (ссылка)

Я уверен, что многим программистам знакома формула:



Y = 0.299 R + 0.587 G + 0.114 B


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



Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.



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



Но почему нельзя? И откуда же взялись именно такие коэффициенты?



Мини-экскурс в историю



Есть такая международная организация, которая разрабатывает рекомендации (де-факто стандарты) для сферы телерадиокоммуникаций — ITU.



Интересующие нас параметры прописаны в рекомендациях ITU-R BT.601, принятых в 1982 году (по ссылке обновленная редакция). Уже на этом моменте можно слегка удивиться — где мы и где 82-ой год? Но это только начало.



Циферки перекочевали туда из рекомендаций ITU-R BT.470 от 1970 года (по ссылке также обновленная редакция).



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



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



Современные колориметрические параметеры начали выкристаллизовываться в 1970 году с модернизацией систем PAL/SECAM. Примерно в это же время американцы придумали свою спецификацию SMPTE-C на аналогичные люминофоры, но NTSC перешла на них только в 1987 году. Я не знаю наверняка, но подозреваю, что именно этой задержкой объясняется сам факт рождения пресловутых Rec.601 — ведь по большому счету, они морально устарели уже к моменту своего появления.



Потом в 1990 году случились новые рекомендации ITU-R BT.709, а в 1996 на их основе придумали стандарт sRGB, который захватил мир и царствует (в потребительском секторе) по сей день. Альтернативы ему существуют, но все они востребованы в узкоспецифичных областях. И прошло уже, ни много ни мало, 20 лет — не пора бы уже избавиться от атавизмов окончательно?



Так в чем же конкретно проблема?



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



Любое RGB-пространство (а YIQ это преобразование над моделью RGB) определяется тремя базовыми параметрами:



1. Хроматическими координатами трех основных цветов (они называются primaries);

2. Хроматическими координатами белой точки (white point или reference white);

3. Гамма-коррекцией.



Хроматические координаты принято задавать в системе CIE xyY. Регистр букв в данном случае важен: cтрочные xy соответствуют координатам на хроматической диаграмме (всем известная «подкова»), а заглавный Y — это яркость из вектора CIE XYZ.



Теперь посмотрим на компоненту Y у всех первичных цветов NTSC (я пометил их розовым):





* Оригинал таблицы со многими другими пространствами на сайте Брюса Линдблума.



Знакомая цифирь, правда? Вот и ответ на вопрос «откуда взялось?»



А проблема в том, что используемое сегодня пространство sRGB существенно отличается от системы 60-летней давности. И дело даже не в том, что из них лучше или хуже — они просто разные:







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



Вы можете спросить: а зачем древнему NTSC охват (практически совпадает с охватом Adobe RGB 1998!) настолько больше, чем у современного sRGB? Я не знаю. Совершенно очевидно, что кинескопы того времени покрыть его не могли. Быть может, хотели сделать задел на будущее?



Как правильно?



Относительные яркости первичных цветов в пространстве sRGB приведены в таблице выше (помечены зеленым) — их и нужно использовать. На практике обычно делают округление до 4-х знаков:



Y = 0.2126 R + 0.7152 G + 0.0722 B


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



Этой формулы хватит для 99% обычных случаев. Её использует во всех своих спецификациях W3C (например, матричные фильтры в SVG). Если вам нужна бОльшая точность, придется вычислять L*, но это отдельная большая тема. Неплохой ответ на StackOverflow, который дает отправные точки для дальнейшего чтения.



Почему меня это волнует?



Как уже было сказано выше, за многие годы формула растиражирована на несметном количестве сайтов, и они сидят в топе всех поисковиков (например). Источники посерьезнее часто приводят обе формулы, но не делают между ними должного различия, преподнося их как равноправные альтернативы. Характерный пример на StackОverflow: Formula to determine brightness of RGB color — ответы довольно подробные, но человеку не в теме сложно сделать осознанный выбор.



Справедливости ради, серьезные проекты такими ошибками почти не страдают — авторы не брезгуют сверяться со стандартами, да и фидбек аудитории работает (хотя и там не обходится без исключений). А вот рядовой программист, которому нужно побыстрее решить задачу, вбивает в поисковик что-то типа «rgb to grayscale», и тот подсовывает ему сами знаете что. Формулу продолжают находить и копипастить до сих пор! Феноменальная живучесть.



На розыск этих примеров я потратил около 20 минут:





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



А поводом для написания этой заметки стал слайд из доклада Василики Климовой с HolyJS-2016 — с той же самой доисторической формулой. Понятно, что формула не повлияла на основной смысл выступления, но наглядно продемонстрировала ваши шансы ненароком её нагуглить в 2016 году.



Подытоживая: если увидите в чьем-то действующем коде последовательность 299/587/114 — кидайте автору ссылку на эту заметку.
Original source: habrahabr.ru.

https://habrahabr.ru/post/304210/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Построение цепочки доверия в PKI, так ли все просто

Понедельник, 27 Июня 2016 г. 16:34 (ссылка)

Инфраструктура открытых ключей (PKI) – достаточно популярная технология для обеспечения целостности и доказательства авторства в различных ИТ-системах. Порою о ее использовании человек, сидящий за компьютером, даже не подозревает, как и в случае проверки целостности программы при установке на компьютер.Технология PKI не нова. Если считать от момента возникновения алгоритма Меркле по распределению ключа – то технологии уже 42 года, если считать от момента возникновения RSA – то 39 лет. Возраст в любом случае внушительный. За это время технология существенно эволюционировала и позволяет создать солидный список сервисов для других приложений и пользователей.Сами сервисы регламентированы в ряде стандартов, в серии X.500 – это серия стандартов ITU-T (1993 г.) для службы распределенного каталога сети и серии RFC (Request for Comments) – документ из серии пронумерованных информационных документов Интернета, охватывающих технические спецификации и стандарты, широко используемые во Всемирной сети. Причем серия RFC первична. Основная масса RFC о PKI была выпущена компанией RSA, одной из отцов(мам)-основателей технологии PKI.Отдельно следует упомянуть всякого рода национальные стандарты и нормативные требования, к примеру, в РФ это ФЗ-63, приказы ФСБ России № 795 и 796 и прочие производные от них. Следует учитывать, что многообразие стандартов RFC и описанных в них функций PKI породило несколько организационно-нормативных подходов к построению инфраструктуры PKI в отдельно взятой стране. Для иллюстрации приведу список сервисов PKI, которые описаны в стандарте X.842:Key Management Services1 Key Generation Service2 Key Registration Service3 Key Certification Service4 Key Distribution Service5 Key Installation Service6 Key Storage Service7 Key Derivation Service8 Key Archiving Service9 Key Revocation Service10 Key Destruction ServiceCertificate Management Services1 Public Key Certificate Service2 Privilege Attribute Service3 On-line Authentication Service Based on Certificates4 Revocation of Certificates ServiceElectronic Notary Public Services1 Evidence Generation Service2 Evidence Storage Service3 Arbitration Service4 Notary Authority5 Electronic Digital Archiving ServiceOther Services1 Directory ServiceIdentification and Authentication Service1 On-line Authentication Service2 Off-line Authentication Service3 In-line Authentication Service3 In-line Translation ServiceRecovery Services1 Key Recovery Services2 Data Recovery Services5 Personalisation Service6 Access Control Service7 Incident Reporting and Alert Management ServiceРезультатом этого многообразия стало безобразие в национальных стандартах отдельных стран. Как результат – набор проблем по совместимости между различными решениями в отдельных странах и, очень часто, невозможность построения цепочки доверия между двумя пользователями технологии PKI в разных странах.Прежде чем рассматривать вопрос методики построения трансграничного доверия, хотелось бы разобрать вопрос построения цепочки доверия внутри страны, взяв за пример РФ.Для этого кратко опишу, как вообще строится базовая инфраструктура PKI и какие есть методы обеспечения доверия в PKI.Доверие в PKI строится по принципу поручительства – например, если два человека не знают друг друга, но хотят вступить в отношения, которые требуют взаимного доверия, они ищут третьего, кому бы могли доверять они оба и кто бы поручился за каждого из них перед другим. Аналог такого человека в PKI называется третья доверенная сторона.Одной из областей применения PKI является обеспечение юридической значимости электронного документооборота. То есть обеспечение возможности доверять электронной подписи под электронным документом. Но, следует уточнить обеспечение юридической значимости требует выполнения целого ряда условий, одним из которых является построение цепочки сертификации. В рамках данной статьи, я хотел бы детально рассмотреть только саму процедуру построения цепочки сертификации и ее взаимосвязи с цепочкой доверия.Цепочка доверия между людьми строится при помощи построения цепочки сертификации. Делается это следующим образом: в роли третьей доверенной стороны выступает аккредитованный удостоверяющий центр. Это юридическое лицо, обладающее одним или несколькими наборами оборудования, которое реализует функции удостоверяющего центра. Аккредитация означает, что это юридическое лицо отвечает ряду требований законодательства, у него есть соответствующие лицензии ФСБ, Минкомсвязи и иногда ФСТЭК России, должным образом оборудованные помещения, обученный персонал с правильными дипломами и сертифицированные ПО и оборудование в роли удостоверяющего центра (УЦ). Так вот, этот удостоверяющий центр уполномочен государством подтверждать вашу электронную подпись другим лицам. Процедура подтверждения вашей электронной подписи удостоверяющим центром является процессом создания цепочки сертификации, так как сертификат УЦ так же подписывается Главным удостоверяющим центром (ГУЦ), который является единой точкой доверия. Что такое электронная подпись и как она работает – вопрос за рамками данной статьи, об этом можно почитать в других источниках.Для того чтобы этот УЦ мог точно сказать, что под документом именно ваша подпись, вам надо прийти в центр регистрации этого УЦ и предоставить ваш открытый ключ, запрос на сертификат, паспорт и ряд других документов. В результате вы получите сертификат открытого ключа, подписанный на ключе данного УЦ. Аналогом этого являются 2-я и 3-я страницы внутреннего паспорта гражданина РФ, там тоже стоит ваша уникальная подпись, ФИО и указано, какой орган эти данные заверил. Но есть небольшое различие – в случае паспорта доверие к его носителю строится через подтверждение подлинности самого паспорта, а потом уже через данные, которые в нем указаны. В электронном мире УЦ принято доверять, только если оба пользователя, которые пытаются общаться между собой, обслуживаются в этом УЦ. В случае если УЦ у каждого пользователя свой, встает проблема доверия между УЦ. Путей ее решения несколько, путь снизу подразумевает кросс-сертификацию между УЦ разных пользователей. Такой путь хорош, когда УЦ не много, но если каждое ведомство развернет себе свой УЦ, получится ситуация, которая возникла в РФ к 2002–2005 годам: множество УЦ по стране, а единого пространства доверия нет, так как кросс-сертификация среди 800 УЦ – штука технически нереальная.И вот тут возникает вопрос – как построить единое пространство доверия в отдельно взятой стране так, чтобы оно работало. Подход, который используется в РФ и не только – создание Главного удостоверяющего центра (государственного) (ГУЦ), подпись его сертификатом всех сертификатов УЦ в стране, как результат – построение цепочки доверия через проверку действительности всех сертификатов в подписи через ГУЦ. Такой подход подразумевает, что проверяются подпись пользователя, действительность сертификата пользователя, действительность всех сертификатов в цепочке (УЦ–ГУЦ). Проверка действительности сертификатов в различных странах производится по-разному. В Эстонии и на Украине для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван. В России для проверки надо запросить у каждого УЦ в цепочке список отозванных сертификатов (СОС) и проверить, что сертификат в нем не указан. Пожалуй, наиболее развитым вариантом построения системы PKI следует считать схему с использованием мостообразующего УЦ, в том виде, в котором она используется в США. Федеральный мостообразующий УЦ (бридж) США содержит несколько базовых служб функции которых следует разобрать в отдельной статье. И вот в этот момент начинаются сложности. Сложность первая. Случается, что сертификат пользователя заполнен неправильно, не соответствует требованиям законодательства, в этом случае он должен быть перевыпущен. Как правило, подобную проблему порождает работник УЦ, который неправильно его заполнил, а проблемы получает пользователь, когда не может его нормально использовать.Сложность вторая. Законодательство говорит о том, что УЦ – это юридическое лицо, и ГУЦ должен подписать сертификат этого УЦ. Ситуация, когда у одного юридического лица несколько комплексов УЦ и несколько сертификатов этих УЦ, толком в законах не прописана. УЦ этим пользуются, часть сертификатов не подписывают с помощью сертификата ГУЦ и делают их в лучшем случае самовыпущенными – когда цепочку к ГУЦ можно построить только по имени УЦ в сертификате – или вообще самоподписанными – когда связи между сертификатами одного УЦ технически не существует, она есть только на бумаге.Сложность третья. Если сертификат отозвали, УЦ обязан его добавить в список отозванных сертификатов (СОС), обязанность эта прописывается в RFC, если они приняты как стандарт в стране, или в регламенте ГУЦ, к которому обязаны присоединиться все аккредитованные УЦ. В случае когда СОС (CRL) большой, УЦ для удобства пользователей выпускает дельта СОС (deltaCRL) с изменениями за короткий период. В регламенте ГУЦ прописана периодичность обновления 12 часов или по факту отзыва сертификатов. В реальности различные УЦ свои СОС публикуют как хотят, существуют некоторые УЦ, которые обновляют их 1 раз в несколько месяцев. Или же СОС подписывается ключом, который не имеет отношения к сертификату УЦ, что тоже сводит шанс построить цепочку доверия к нулю. Потихоньку возникает проблема с обработкой самих СОС, за время существования УЦ они уже стали достаточно большого размера, но дельта СОС не выпускает почти никто.Сложность четвертая, связная. Построение цепочки доверия в PKI так или иначе требует наличия связи с УЦ и ГУЦ и работу в онлайне. Работа в офлайне не предусмотрена. Существует ряд мест и приложений, где работа с подписями и сертификатами в офлайне очень бы пригодилась. Далеко не вся территория РФ охвачена качественным интернетом и каждый лишний передаваемый байт воспринимается болезненно, так как бьет по кошельку.Сложность пятая, техническая. Иногда в программно-аппаратных комплексах УЦ все-таки находятся ошибки в логике и реализации, это также может влиять на построение цепочки доверия.И только если на пути пользователя эти проблемы не встретились, цепочка доверия должна построиться. В случае использования OCSP/TSP-служб проблемы тоже существуют, но это тема для отдельной статьи.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304220/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Московская биржа стала первой российской финансовой организацией — участником международного блокчейн консорциума

Среда, 22 Июня 2016 г. 17:26 (ссылка)

image



Московская биржа стала участником международного блокчейн-консорциума HyperLedger и присоединилась к проекту Linux Foundation, в рамках которого функционирует этот консорциум.



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



Сергей Поляков, Управляющий директор по информационным технологиям Московской биржи: «Технология распределенного реестра приобретает все больший вес в финансовой индустрии. Группа „Московская биржа“ активно изучает перспективы применения блокчейн-решений в процессах проведения торгов, клиринга и расчетов. Первые результаты нашей работы уже применяются: Национальный расчетный депозитарий развивает пилотный проект системы электронного голосования владельцев облигаций e-proxy voting на основе этой технологии».



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



О HyperLedger Project

image



В рамках международного проекта Linux Foundation в декабре 2015 года стартовал блокчейн-консорциум HyperLedger Project, целью которого было заявлено совместное продвижение блокчейн-технологии путём идентификации и разработки существенных аспектов для отрытого стандарта распределённых реестров, которые могут изменить способ проведения бизнес-транзакций на глобальном уровне.



HyperLedger Project организует площадку для коммуникационных сессий бизнеса и разработчиков, способствует формированию общепризнанных международных блокчейн-стандартов в финансовой индустрии. Проект объединяет как глобальных игроков мирового финансового рынка (CME, Deutsche Boerse, LSE), так и крупные IT–компании (IBM, CISCO, Intel).



В проекте HyperLedger функционируют технический комитет (Technical Steering Committee), маркетинговый комитет (Marketing Committee) и технический консультативный совет конечных пользователей (End User Technical Advisory Board). Представители Московской Биржи и НРД войдут в состав всех комитетов и рабочих групп блокчейн-консорциума.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303874/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Суровый рынок веб-разработки в России или зачем нам базы данных, постоянное хранилище и FTP

Среда, 15 Июня 2016 г. 21:20 (ссылка)

image




Чем бы дитя ни тешилось, лишь бы по FTP не деплоило и не масштабировало свои продукты, перекачивая образы виртуальных машин. Респект и хвала умным парням и девушкам, которые знают, что такое CI, CD и активно их используют в своем продакшне. Cust Dev по России показал, что все очень плохо. Увы.



Крик души



Соблюдаем анонимность и надеемся никого не обидеть. На вопрос “Как вы работаете и доставляете свой продукт в продакшн?” мы услышали уйму различных ответов. Вот некоторые тезисы из самых популярных ответов:


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

  2. Разворачиваем новые экземпляры своего SaaS, копируя целиком виртуалки. За ночь копируется нормально.

  3. Как-как? По ftp, а git используем для резервных копий.

  4. Мы планировали использовать git, но как-то не получилось. Сейчас все руками.

  5. У меня все настроено с помощью капистрано.

  6. Все через пулл-реквесты, потом суровый код-ревью, потом CI подтягивает все в прод.





Это не сферические кони в вакууме, а реальные люди из реальных студий и агентств России из крупных и мелких городов. На удивление различия в относительных долях того или иного ответа в зависимости от региона оказались несущественными. Быть может, для небольшого и несерьезного проекта, типа сайта-одностраничника, подобный подход вполне себе вменяемый, но если ты ответственный за DevOps в более-менее крупной веб-студии, для безболезненного масштабирования просто жизненно-необходимо придерживаться git workflow и использования ряда CI/CD инструментов.



SaaS масштабирование



Боль у каждого своя, и как использовать тот или иной инструмент решает каждый сам. Если вы — счастливый обладатель SaaS решения (системы мониторинга, CRM, CMS, в общем, все, где нужно масштабироваться быстро по горизонтали) и вы до сих пор клонируете виртуозки, то бог вам в помощь мы вас ждем. Пишите нам в саппорт, и мы предложим вам выгодные условия использования нашей платформы для обеспечения быстрого масштабирования. Небольшое демо такого прикладного использования нашей системы









Использование системы не по назначению, перманентное хранилище и FTP



Есть то, что есть, и работать приходится именно с этим. Особенности работы Docker образов и контейнеров включают в себя определенные ограничения для файловых операций внутри контейнера, а именно — неперсистентность результата их выполнения после перезапуска процесса веб-сервера (что порождает пересоздание контейнера) или перебилда image вашего приложения. Мы, хоть и косвенно, но являемся Shared CaaS решением. Наше предложение — хранищище с FTP доступом из вне. Папка монтируется в контейнер при билде и запуске приложения.



Для любителей писать на шаблонизаторе php систем эта проблема наиболее актуальна, ибо 90% написанных решений безбожно творят уйму операций с файлами, сохраняют туда данные, конфиги, темы, настройки и пр. Если взять пример запуска веб-сервера, совместимого с большинством php-систем (наличие апача для многих является просто необходимым) https://github.com/dokkur/php-common/blob/master/Procfile, то мы в самом простейшем варианте даем возможность закинуть все необходимое содержимое в примонтированную папку через FTP. Для этого нужно:


  1. Зарегистрироваться у нас

  2. Нажать кнопку + справа вверху

  3. Ввести имя приложения, выбрать датацентр

  4. Выбрать нужный темплейт — Any PHP

  5. Дождаться окончания создания приложения, перейти в п.меню Storage

  6. Кликнуть на строку /app/www и получить данные для подключения: Host, Username, Password. Если изменения DNS еще не настигли ваш узел связи или у вас закешировано там что-то другое, то советуем использовать доменное имя инстанса, на котором создано ваше приложение: п.меню Settings, посмотреть на git url и прочитать хостнейм — то, что между символами “@” и ”:”.



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



Что делать и кто виноват?



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



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



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



Что наиболее точно характеризует вас:


































































































Проголосовало 3 человека. Воздержавшихся нет.





Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303388/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Zinur

«Стандарты НАТО» добьют украинскую оборонку

Среда, 08 Июня 2016 г. 09:09 (ссылка)


«Стандарты НАТО» добьют украинскую оборонку | Русская весна






Возможности и потенциал военно-промышленного комплекса Украины в ближайшее время существенно сократятся. Это следует из планов его стратегического развития, которые утверждены президентом Петром Порошенко. Переход украинского ВПК на стандарты НАТО, возможно, и сблизит страну с этим альянсом политически, однако на украинской «оборонке» придется поставить крест.

Читать далее...
Метки:   Комментарии (1)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Марсоход Opportunity более чем в 40 раз превысил запланированный срок службы

Пятница, 03 Июня 2016 г. 19:10 (ссылка)

В этом году марсоход Opportunity отмечает свое 12-летие на красной планете. Марсоход был высажен 24 января 2004 года и до сих пор продолжает функционировать.

Марсоход «Оппортьюнити» совершил посадку в кратере Игл, на плато Меридиана. В настоящее время Opportunity находится в районе кратера Индевор, тем самым пройдя более 40 км от своего первоначального положения

image

NASA/JPL/Cornell University, Maas Digital LLC — photojournal.jpl.nasa.gov/catalog/PIA04413



Марсоход управляется двумя компьютерами на базе стандарта CompactPCI, спроектированными и построенными инженерами компании BAE Systems.

Когда Opportunity приземлился, команда НАСА думала, что суровый марсианский климат сделает его неработоспособным в течение нескольких месяцев. Запланированный срок работы марсохода был равен примерно 90 суток. Но марсоход, получающий энергию только от солнечных батарей, все еще собирает данные.

Атмосфера Марса более разрежена, чем воздушная оболочка Земли, и на 95,9 % состоит из углекислого газа, около 1,9 % приходится на долю азота и 2 % аргона. Содержание кислорода 0,14 %. Среднее давление атмосферы на поверхности в 160 раз меньше, чем у поверхности Земли.

Средняя температура на Марсе значительно ниже, чем на Земле, — около -40°С. При наиболее благоприятных условиях летом на дневной половине планеты воздух прогревается до 20°С — вполне приемлемая температура для жителей Земли. Но зимней ночью мороз может достигать -125°С. При зимней температуре даже углекислота замерзает, превращаясь в сухой лед.

image



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

Original source: habrahabr.ru.

https://habrahabr.ru/post/302560/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

IBM представляет первую в мире память PCM с записью трёх бит в ячейку

Пятница, 03 Июня 2016 г. 16:33 (ссылка)





Специалисты нашей компании на ежегодном тематическом форуме IEEE International Memory Workshop в Париже представили рабочий прототип памяти на основе фазового перехода (Phase-change memory, PCM). В каждой ячейке памяти хранится по три бита данных. Тестовый образец создан по 90-нм КМОП техпроцессу и представлен в виде массива ёмкостью 32 Мбит.



По мнению разработчиков, такая память очень перспективна, поскольку она способна выдержать несколько миллионов циклов записи. В то же время обычная flash-память — не более 3000 циклов перезаписи. Скорость работы РСМ памяти примерно равна скорости работы оперативной памяти. Если разработку удастся запустить в массовое производство, это позволит получить универсальную память, причем уже в недалеком будущем. Ну а сейчас компания планирует использовать PCM чипы для SSD, а также в виде буферной памяти для SSD с NAND-флэш в качестве основы.

Читать дальше →

https://habrahabr.ru/post/302550/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Интеграция системы мониторинга Vutlan SC8100 с NMS Cacti

Пятница, 03 Июня 2016 г. 05:37 (ссылка)

Человек всегда хочет большего. Система мониторинга от компании Vutlan отслеживает контролируемые параметры, оповещает о приближении к опасным значениям с помощью SMS сообщений и e-mail рассылки. Отображает данные в виде графиков, позволяет использовать графические карты. Хороший, качественный программный продукт, полностью закрывающий потребности технических специалистов. Лучшим качеством инженера является желание исследовать, изучать и улучшать существующие решения. По этому рассмотрим возможность интеграции данных с датчиков и сенсоров во внешнюю систему мониторинга параметров. Для примера возьмем одну из GNU GPL систем NMS — Cacti. Выбрать подходящую под ваши задачи систему можно тут. На мой вкус, наилучшей системой NMS для отслеживания параметров инженерного оборудования (систем вентиляции и кондиционирования, систем распределения электропитания, пожаротушения, видеонаблюдения, управления доступом) является Cacti. Очень удобная система графиков, позволяющая наглядно отслеживать динамику значений:



image



Читать дальше →

https://habrahabr.ru/post/302368/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Варианты альтернативы электронной почте

Понедельник, 30 Мая 2016 г. 13:08 (ссылка)


Отчет компаний International Data Corporation и McKinsey Global Institute показывает, что работники тратят 28% рабочего времени на чтение и ответ электронных сообщений, что снижает производительность на 25%. Электронная почта стала основным средством связи для каждой организации. Заменить эмейл достаточно трудно, но, тем ни менее, возможно.







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



Читать дальше →

https://habrahabr.ru/post/302080/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<стандарты - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda