Позитивні моменти використання стандартів ISO та системи менеджменту якості доведено досвідом багатьох компаній, у тому числі і в сфері інформаційних технологій. Про це вже багато написано, тому пропагувати ISO та систему менеджменту якості я не беруся. Завдання моєї статті — показати, що з допомогою двох не дуже складних схем можна зрозуміти сенс процесу впровадження системи менеджменту якості і отримати конкретні, чіткі рекомендації, які документи для цього потрібні. Таких схем, які наведені в статті, ви не знайдете ні в одному керівництві. Саме тому я вирішив поділитися ними з читачами Хабра.


Джерело

Читати далі →


Джерело

За даними IoT Analytics в 2016 році найбільше проектів (22% від загальної кількості), пов'язаних із застосуванням інтернету речей, було реалізовано для промислових об'єктів. Це підтверджує розвиток і поширення технологій заявлених у доктрині Industry 4.0.

Таким чином, на наших очах виник новий клас кібер-фізичних систем, отримав назву Industrial Internet Control Systems (IICS) або Industrial Internet of Things (IIoT).
З назви зрозуміло, що такі системи є гібридом технологій, що використовуються в АСУ ТП і в системах на базі інтернету речей. Відповідно в таких системах необхідно враховувати всі ризики, пов'язані з порушенням властивостей інформаційної (security) і функціональної безпеки (safety).

Дана стаття продовжує цикл публікацій щодо функціональної безпеки. У ній розглянуто вимоги до організації життєвого циклу систем управління (АСУ ТП, вбудовані системи, інтернет речей). Запропонована єдина структура процесів, що підтримують виконання вимог як до інформаційної, так і до функціональної безпеки.

Читати далі →

На моєму першому місці роботи я працював на хлопця на ім'я Марк. Марк був дуже розумним і цілеспрямованим програмістом, і я багато чому навчився у нього. Але ми з ним постійно буцалися з приводу стандартів і стилів кодування.

Ми тоді писали під DEC VAX на VAX Basic. Щоб уся ця історія мала якийсь сенс, ви повинні розуміти, що VAX Basic не був тим класичним Basic, про який ви думаєте. Розробники компілятора із DEC почали з синтаксису Basic і потроху додали все хороше з FORTRAN, Modula II і Pascal. Наприклад, ще на початку 1980-их в мові вже були винятки.

Також потрібно пам'ятати, що в 1980-их ще не існувало повноцінних IDE з багатими редакторами коду (на кшталт Visual Studio). Ми використовували щось, зване TPU (Text Processing Utility). Ця програма була дещо потужніше, ніж Notepad, але значно поступалася сучасним редакторам. Тоді вона змагалася з Emacs і vi. В результаті, кожен розробник сам відповідальний за свій стиль коду, а текстовий редактор в це справа абсолютно не втручався.

Марк визначив строгий набір правил і стандартів написання коду. Його прихильність цим стандартам була близька до фанатизму. Наприклад, він міг пріконнектіться до робочого комп'ютера вночі з дому (а в той момент це означало використання модему зі швидкістю близько 1200 бод) заради рев'ю коду. На наступний ранок мене чекало нарада з Марком, де він порядково коментував мій код, вказуючи на помилки в стилі і вимагаючи, щоб я сьогодні ж їх виправив.

Читати далі →

Як 3 тисячі рублів і прості методи підвищення ефективності ЦОД допомогли заощадити купу грошей

За час своєї роботи я часто зустрічався з проблемами нестачі ресурсів корпоративних ЦОД, які можна сформулювати, наприклад, наступним чином: «У нас не вистачає фізичного місця для розміщення обладнання», «У нас не вистачає підведеної потужності» і так далі і тому подібне. Рішення подібних проблем «в лоб» веде до очевидної відповіді – вимкнути і вивести з експлуатації частину ІТ-обладнання, або здійснити заміну обладнання на більш ефективне за співвідношенням продуктивність/споживання/фізичні розміри.

В більшості випадків виявляється, що ресурсів на самому справі в надлишку, але використовуються вони, м'яко скажемо, марнотратно. Проблема полягає найчастіше в банальному раздолбайстве або розвитку корпоративного ЦОДа експансивно, так сказати з успадкованим принципам. Прийняті рішення не перевіряються на предмет ефективного використання наявних ресурсів, в організаціях немає методики їх перевірки і, у результаті, ми отримуємо те, що отримуємо.

Якщо ви для себе зрозуміли, що так далі жити не можна, рекомендую почати з читання блогів таких компаній як: Крок, Білайн, Data Line. У них можна знайти статті, в яких вони діляться своїм досвідом у сфері енергоефективності. Їх методи працюють — PUE комерційних майданчиків знаходиться в межах 1,3-1,4 (у кого-то трохи менше) що при TIER III є відмінним результатом. Проте в якийсь момент ви зрозумієте, що у них там своя вечірка з мегаватами, резервами і досвідченим персоналом. І вам на ній не місце.

Що ж робити простим смертним, у яких ЦОД – це 10 стійок, 200 кВт потужності, завжди не вистачає рук і часу?

Читати далі →

Рефакторинг платіжного процесу Я. Грошей — пробудження сили

<img src=«habrastorage.org/files/a32/bd2/d70/a32bd2d705ce4e9c914eb060191ae8b4.jpg» alt=«image» alt text"/>
Для будь-якого проекту з довгою історією одного разу наступає момент, коли код починає жити своїм життям — просто не залишається тих, хто добре орієнтується в логіці і зв'язках. Додавання нових функцій часом схоже на постріл навмання: може потрапити в ціль, а може — у глядачів.
І тоді приходить він, рефакторинг платіжного процесу. Але ми вирішили зробити процес ще цікавіше, додавши до рефакторінгу ідеї IDEF-0.
Читати далі →

Тренди і події в світі веб-технологій в 2016 році



Фото: Flickr / Dennis Skley / CC

Початок року — чудовий привід ще раз поговорити про цікаві події недавнього минулого. Але нас цікавить не все підряд, а те, як розвивалася наша улюблена галузь — веб. Отже, ми представляємо вашій увазі підбірку ключових подій і трендів, які оформилися в 2016 році і будуть впливати на те, яким інтернет стане в найближчому майбутньому.
Читати далі →

Парсинг JSON — це мінне поле

image

JSON — це стандарт де-факто, коли заходить мова про (де)серіалізації, обмін даними в мережі мобільного розробці. Але наскільки добре ви знайомі з JSON? Всі ми читаємо специфікації і пишемо тести, відчуваємо популярні JSON-бібліотеки для своїх потреб. Я покажу вам, що JSON — це ідеалізований формат, а не ідеальний, яким його багато хто вважає. Я не знайшов і двох бібліотек, які ведуть себе однаково. Більше того, я виявив, що крайні випадки і шкідлива корисне навантаження можуть призвести до багам, падіннями і DoS, в основному тому, що JSON-бібліотеки засновані на специфікаціях, які з часом розвиваються, що залишає багато речей погано або взагалі не задокументованими.

Зміст1. Специфікації JSON
2. Тестування парсинга
2.1. Структура
2.2. Числа (Numbers)
2.3. Масиви
2.4. Об'єкти
2.5. Рядка
2.6. Двоїсті значення RFC 7159
3. Архітектура тестування
4. Результати тестування
4.1. Повні результати
4.2. C-парсери
4.3. Objective-C-парсери
4.4. Apple (NS)JSONSerialization
4.5. Freddy (Swift)
4.6. Bash JSON.sh
4.7. Інші парсери
4.8. JSON Checker
4.9. Регулярні вирази
5. Контент парсинга
6. STJSON
7. Висновок
8. Додаток
Читати далі →

Функціональна безпека, частина 4 з 4. Процеси управління та оцінювання



Безпеки на хабре присвячений цілий хаб, і, мабуть, ніхто особливо не замислюється, що саме вкладається в поняття «безпека», і так все ясно: інформаційна безпека (security). Однак, є ще й інша сторона безпеки, safety, пов'язана з ризиками для здоров'я і життя людей, а також навколишнього середовища. Оскільки інформаційні технології самі по собі небезпеки не представляють, то зазвичай говорять про функціональної складової, тобто про безпеку, пов'язану з правильним функціонуванням комп'ютерної системи. Якщо інформаційна безпека стала критична з появою інтернету, то функціональна безпека розглядалася і до появи цифрового управління, адже аварії відбувалися завжди.

Дана стаття продовжує серію публікацій на тему функціональної безпеки.

Частина 1 є вступній.
частина 2 розглянута загальна структура стандарту МЕК 61508 «Функціональна безпека систем електричних, електронних, програмованих електронних, пов'язаних з безпекою» (IEC 61508 Functional safety of electrical/electronic/electronic programmable safety-related systems) і використовувана в ньому термінологія.
частини 3 вимоги МЕК 61508 розкладено «по поличках» на основі їх загальної класифікації.

У цій статті досить абстрактні вимоги до управління функціональної безпекою інтерпретовані для впровадження в робочі процеси. Ця інформація перевірена і відшліфована на практиці декількох проектів по сертифікації.
Процесна інженерія – нудно це чи ні? Саме процеси дозволяють масштабувати IT-бізнес. Мені особисто доводилося спостерігати, як впровадження процесів в розробку призводило до серйозного професійного зростання, як виконавців, так і всієї компанії. І навпаки, «затики» і так звана «недоцільність» впровадження добре структурованих процесів свідчили про незрілість і інших серйозних проблем.
Отже…

Читати далі →

Функціональна безпека, Частина 3 із 3. МЕК 61508: Систематична випадковість чи випадкова систематичність?

Безпеки на Хабре присвячений цілий хаб, і, мабуть, ніхто особливо не замислюється, що саме вкладається в поняття «безпека», і так все ясно: інформаційна безпека (security). Однак, є ще й інша сторона безпеки, safety, пов'язана з ризиками для здоров'я і життя людей, а також навколишнього середовища. Оскільки інформаційні технології самі по собі небезпеки не представляють, то зазвичай говорять про функціональної складової, тобто про безпеку, пов'язану з правильним функціонуванням комп'ютерної системи. Якщо інформаційна безпека стала критична з появою інтернету, то функціональна безпека розглядалася і до появи цифрового управління, адже аварії відбувалися завжди.

Дана стаття продовжує серію публікацій на тему функціональної безпеки.

У вступної частини 1:

— обґрунтовано важливість оцінювання та забезпечення функціональної безпеки для комп'ютерних систем управління;
— розглянуто архітектури систем, для яких необхідно оцінювати і забезпечувати функціональну безпеку; до таких систем відносяться АСУ ТП (Industrial Control Systems) на базі програмованих логічних контролерів (ПЛК), вбудовані системи (Embedded Systems) і рівень пристроїв (Device Layer) для інтернету речей;
— коротко представлено безліч стандартів, що відносяться до функціональної безпеки в різних сферах застосування.

У частині 2 розглянута загальна структура стандарту МЕК 61508 «Функціональна безпека систем електричних, електронних, програмованих електронних, пов'язаних з безпекою» (IEC 61508 Functional safety of electrical/electronic/electronic programmable safety-related systems) і використовувана в ньому термінологія.

Опис досить непростий термінологічної казуїстики зайняло цілу статтю, і тепер настав час розібратися зі структурою вимог МЕК 61508.

Не рекомендується до прочитання тим, хто не цікавиться стандартизацією.

Читати далі →

Виходить HTML 5.1, готується HTML 5.2



Представники організації World Wide Web Consortium (W3C) порадували громадськість відразу двома новинами. Мова йде про роботу над HTML 5.1 і HTML 5.2. Специфікація версії 5.1 вже на останній стадії узгодження.

Її статус перейшов від «Release Candidate» до «Proposed Recommendation». Таким чином, HTML 5.1 залишилося отримати «благословення» концорциума («W3C Recommendation») і вийти у світ. Новий стандарт готовий на 99,99%. Так що, найближчим часом стандарт HTML 5.0 буде не актуальне.
Читати далі →