Детектив за матеріалами IT. Частина друга
У цій частині я спробую показати, як же спочатку виглядало поділ Користувальницького Інтерфейсу на Вигляд і Контролер і які цікаві рішення можна знайти в цій області на сьогоднішній день. Посилання на першоджерела наведені на початку першої частини.
Отже, не дивлячись на те, що Вигляд визначається як модуль, що відображає Модель – "view is a (visual) representation of its model", практиці до Виду, як правило, просто відносять всі графічні елементи GUI, тобто Видом вважається все те, що ми бачимо на екрані ЕОМ.
Зрозуміло, що тут міститься певне протиріччя, оскільки такі графічні компоненти, меню, кнопки, тулбари служать для відображення інформації про систему, а насамперед для управління системою. Клавіатура і миша завжди були засобом управління програмою та перебували в «ведомости» Контролера (як би його не трактували). Тому здається нелогічним і дивним, що кнопки, зроблені з пластмаси, вважаються елементами управління і відносяться до Контролера, а кнопки, намальовані на екрані, і по суті виконують ті ж самі функції (виробляти вхідні події), чомусь відносять до Виду.
Читати далі →

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

Ми тоді писали під 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 бод) заради рев'ю коду. На наступний ранок мене чекало нарада з Марком, де він порядково коментував мій код, вказуючи на помилки в стилі і вимагаючи, щоб я сьогодні ж їх виправив.

Читати далі →

Відповідь на введення в проектування сутностей, проблеми створення об'єктів

Після прочитання статті Введення в проектування сутностей, проблеми створення об'єктів на хабре, я вирішив написати розгорнутий коментар про приклади використання Domain-driven design (DDD), але, як водиться, коментар виявився занадто великим і я вважав правильним написати повноцінну статтю, тим більш що питання DDD, на хабре і не тільки, видаляється мало уваги.
DDD
Рекомендую прочитати статтю про яку я буду тут говорити.
Якщо коротко, то автор пропонує використовувати білдери для контролю за консистентностью даних в сутності при використанні DDD підходу. Я ж хочу запропонувати використання Data Transfer Object (DTO) для цих цілей.

Читати далі →

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

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

Введення в проектування сутностей, проблеми створення об'єктів

При моделюванні такого поняття предметно-орієнтованого проектування як сутність можуть виникнути деякі складності, обумовлені бізнес-вимог або технічною частиною. Зокрема, іноді виникає складність із створенням об'єкта-сутності.

У даній статті описуються дві такі проблеми, і розглядається спосіб їх вирішення. Так само стаття підійде як введення в проектування сутностей. Для розуміння матеріалу знадобиться базове уявлення про предметно-орієнтованому проектуванні.

Читати далі →

Полювання на міфічний MVC. Огляд, повернення до першоджерел і про те як аналізувати і виводити шаблони самому

— Не розумію, чому люди так захоплюються цим Карузо? Недорікуватий, гугнив, співає — нічого не розбереш!
— А ви чули, як співає Карузо?
— Так, мені тут дещо з його репертуару Рабинович наспівав по телефону.
Детектив за матеріалами IT. Частина перша
Я усвідомлюю, що писати чергову статтю на тему Модель-Вид-Контролер це безглуздо і шкідливо для «карми». Проте з цим «паттерном» у мене надто особисті відносини – провалений проект, півроку життя і важкої роботи «в кошик».
Проект ми переписали, вже без MVC, просто керуючись принципами – код перестав бути схожий на клубок спагеті і скоротився наполовину (про це пізніше, в обіцяної статті про те, як ми застосовували «принципи» у своєму проекті). Але хотілося зрозуміти, що ж ми зробили не так, у чому була помилка? І протягом довгого часу вивчалося все, що містило абревіатуру MVC. До тих пір поки не зустрілися початкові роботи від творця – Трюгве Реенскауга…
І тоді все стало на свої місця. Виявилося, що фактично на основі принципів ми пере-винаходили «original MVC». А те, що часто підноситься як MVC, не має до нього ніякого відношення… втім також як і до гарної архітектури. І судячи з того скільки людей пише про неспроможності «класичного MVC», сперечається про нього і винаходить його різноманітні модифікації, не одні ми зіткнулися з цією проблемою.
Більше 30 років зібрані у MVC ідеї та рішення залишаються найбільш значущими для розробки користувальницьких інтерфейсів. Але як не дивно, незважаючи на існуючу плутанину і велика кількість суперечливих трактувань, розробники продовжують задовольнятися інформацією «з других рук», черпаючи знання про MVC з вікіпедії, невеликих статей в інтернеті і фреймворків для розробки веб-додатків. Найбільш «просунуті» читають Мартіна Фаулера. І чомусь майже ніхто не звертається до першоджерел. Ось цей пробіл і хотілося б заповнити. І заодно розвіяти деякі міфи.

Читати далі →

Хитрощі і трюки Netbeans на живих прикладах

Дуже часто я чую фрази різних людей на тему того, що повноцінні IDE — це не потрібно, що Vim, Sublime Text і Atom дозволяють все робити, і так далі, і так далі. Тільки недавно у мене знову виникла бесіда на цю тему, і я знову згадав про те, що хотів показати людям деякі трюки сучасних IDE, які сильно спрощують життя під час роботи.
Я люблю цю якісну опенсорсную IDE Netbeans. У мене навіть колірна схема під неї є своя власна (не забудьте прочитати опис, якщо побажаєте її випробувати). На всіх відеороликах як раз вона і використовується в роботі, плюс темний інтерфейс Darkula і вільний шрифт Hack.
Іноді я переходжу в PhpStorm, попрацювати там і порівняти можливості цих двох IDE. І час від часу приходжу до розумію, що кожна з них по-своєму гарна. PhpStorm має безліч цікавих інтелектуальних можливостей для швидкої розробки ООП коду. А на стороні Netbeans — безкоштовність, а також потужний і не сильно перевантажений інтерфейс. Це особливо відчувається після повернення на нього з PhpStorm.
У цій статті я хотів би показати деякі прикольні трюки, які присутні в Netbeans та інших сучасних IDE, а деякі з них — тільки в Netbeans. Дуже часто вони допомагають мені заощадити масу часу при роботі над великими проектами.
Прошу також не обурюватися людям, які використовують сучасні IDE і знають більшість цих трюків. Це не для вас! Справа в тому, що є безліч інших людей, які їх не знають, і я б хотів показати їм ці можливості на реальному прикладі.
Читати далі →

Рефакторинг салону відеопрокату на JavaScript

Моя книга по рефакторінгу в 1999 році починалася з простого прикладу розрахунку і форматування чека для відеомагазинах. На сучасному JavaScript є кілька варіантів рефакторінгу того коду. Тут я викладу чотири з них: рефакторинг функцій верхнього рівня; перехід до вкладеної функції з диспетчером; використовуючи класи; трансформація із застосуванням проміжної структури даних.

Багато років тому, коли я писав книгу по рефакторінгу, я почав з (дуже) простого прикладу рефакторінгу коду, який обчислював рахунок для клієнта за прокат відеофільмів (в ті дні нам потрібно було ходити в салон для цього). Нещодавно я розмірковував про це прикладі, зокрема, як би він виглядав на сучасному JavaScript.

Будь рефакторинг передбачає поліпшення коду в певному напрямку, в тому, яка відповідає стилю програмування команди розробників. Приклад у книзі на Java, а Java (саме в той час) передбачала певний стиль програмування, об'єктно-орієнтований стиль. Однак з JavaScript є набагато більше варіантів, який стиль вибрати. Хоча ви можете дотримуватися Java-подібного об'єктно-орієнтованого стилю, особливо з ES6 (Ecmascript 2015), не всі прихильники JavaScript схвалюють цей стиль. Багато хто дійсно вважають, що використовувати класи Дуже Погано.

Читати далі →

Динамічне перенаправлення мережевого трафіку

Мова в статті піде про те, як організувати можливість динамічного перемикання між мережевими інтерфейсами.
Коріння питання почали зростати з попереднього проекту socmetr.ru, де потрібно збирати великий обсяг інформації з соціальних мереж, і таким чином забиваючи єдиний канал з інтернетом. Аналіз показав, що навіть при наявності стиснення, обсяг інформації, що надходить так великий, що відбувається його блокування, при цьому потужності CPU і Memory не задіяні і на 20%, а дискова підсистема майже весь час простоює, тобто ми вперлися в ширину каналу, яку нам надає провайдер.
Перша думка була піти екстенсивним шляхом і просто збільшити його можливості, трохи охолонувши і призадумавшись, зрозуміли, що перекладаємо проблему на майбутнє. Само собою, виникло запитання: "Яким шляхом підемо, товариші?". В результаті реалізували наступну ідею:
image
Читати далі →

Переходимо c Tarantool на 1.5 1.6



Привіт, Хабр! Хочу розповісти історію міграції з Tarantool версії 1.5 на 1.6 в одному з наших проектів. Як ви думаєте, чи потрібно займатися міграцією на нову версію, якщо і так все працює? Наскільки легко це зробити, якщо у вас вже написано досить багато коду? Як не торкнутися живих користувачів? З якими труднощами можна зіткнутися при таких змінах? Який взагалі профіт від переїзду? Відповіді на всі питання можна знайти в цій статті.

Читати далі →