TypeScript is actually JavaScript and one still has to be careful

TypeScript, although very promising language, does not solve fundamental JavaScript’s issue (feature?) with “this” property binding. TypeScript can lead to unfortunate errors since it is heavily used by people coming from C#/Java communities, who bring coding patterns with them. Let’s have a look at code example from TypeScript playground:

Now, lets make slight change to the last two code lines:

This happens because greet() method references this and when you make a call of greet() not on the object, this gets bound to the global scope. It’s really unfortunate that one can so easily destroy TypeScript object’s integrity. In C# this example would work just fine and therefore C# developers should be extra careful to avoid this pitfall:

Now, even knowing all rules of this binding (take a look at this article if you are not aware of these rules), I was caught when I was coding in TypeScript class for Angular 2 framework:

See how updateClock local function starts accessing Timer properties via this? Seriously, I was debugging this code full of surprise trying to understand why am I getting an error. And the reason was that updateClock() is invoked without binding to any object which meant binding to the global scope again.

Conclusion: TypeScript is great, but guys, don’t relax, remember you are still coding in JavaScript, not C# or Java. And probably avoid using classes and this altogether.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Ідея обчислювального процесу

Я сьогодні почав читати книгу “Structure and Interpretation of Computer Programs“. Початок першого розділу мені так сподобався, що я вирішив його перекласти. Мені здається, що для студентів-програмістів ці декілька абзаців можуть стати певним просвітленням.

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

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

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

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

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Чи є майбутнє у керованої моделлю розробки програмного забезпечення

Давненько не писав. Часто виникає бажання щось написати, але потім якось руки не доходять. Аж раптом нещодавно трапилась мені на очі презентація шановного Джона ден Хаана під назвою «Чому у керованої моделлю розробки програмного забезпечення немає майбутнього» (Why there is no future for model driven development). Оскільки я палкий прихильник розробки програмного забезпечення, керованої моделлю, не можу не відреагувати. Свою думку я йому коротко висловив на сайті, а тепер вирішив трохи детальніше розміркувати.
Почнімо з визначення. Отже розробка програмного забезпечення, керована моделлю (РКМ) – це методологія розробки програмного забезпечення (ПЗ), що спрямована на використання моделей ПЗ як основних продуктів розробки та генерування на їх основі інших робочих продуктів, у тому числі і вихідного коду, наприклад на Java або C++. Як і більшість понять у галузі ПЗ, це поняття запозичене із більш традиційних інженерних дисциплін, хоча там на керованості моделлю так явно не наголошують, оскільки використання моделей є загальноприйнятим. Ніхто навіть і уявити собі не може конструювання такої будівлі як Московський Міст у Києві чи літак «Мрія» без попередньої побудови великої кількості різноманітних спеціалізованих моделей. Моделі допомагають зрозуміти складні завдання та їх потенційні розв’язки через абстракцію. Однак у галузі розробки ПЗ моделювання аж ніяк не набуло широкого впровадження. Не будемо тут намагатися аналізувати причини, це тема окремого посту, а перейдемо відразу до демонстрації того, що РКМ має майбутнє.
Не вдаючись до історії постійного підвищення рівня абстракції мов програмування, відразу перерахуємо фундаментальні принципи програмної інженерії та покажемо як РКМ відповідає цим принципам: строгість та формальність, розділення відповідальності, модульність, абстракція, передбачення змін.
Строгість та формальність. Розробка програмного забезпечення є творчою діяльністю. У будь якій творчій діяльності є схильність до неточності. Строгість та формальність необхідне доповнення будь-якої інженерної діяльності. Тільки так можливо контролювати вартість та якість продуктів на виході такої діяльності. Моделювання ПЗ, використовуючи формальні мови, зі строго заданими синтаксисом та семантикою безумовно відповідає цьому принципу. Звісно, тут не йдеться про архітектуру, намальовану маркером на дошці, така модель корисна хіба що для обговорення проектних рішень.
Розділення відповідальності. Один з найголовніших принципів інженерії взагалі та інженерії ПЗ зокрема. Розділення відповідальності – це спрощення єдиного монолітного розв’язання завдання шляхом поділу на взаємодіючі розв’язання під-завдань. Моделювання різних аспектів ПЗ, таких як бізнес-логіка або архітектура, за допомогою різних, предметно-орієнтованих мов програмування (DSLs) є реалізацією цього принципу. Особливу вагу для бізнесу мають предметно-орієнтовані мови, призначені для опису конкретної галузі в якій працюватиме застосування. Наприклад, мови для опису управляння страховими полісами, бізнес процесів, алгоритмів розрахунку статистики успішності студентів і т.д. Програму, написану такою мовою зможе читати бізнес експерт, а програму мовою Java – ні.
Модульність. Цей принцип є окремим випадком попереднього. Суть його полягає у розбитті системи на простіші частини, що називаються модулями, компонентами, сервісами і т.д. Перераховані назви є, безумовно, абстракціями, створеними для реалізації принципу модульності. Однак ми не обмежені лише цими абстракціями у побудові ПЗ! Ми можемо послуговуватися, формально визначивши, такими абстракціями як компонент, процес, замикання, виключення, повідомлення, синхронізація, з’єднувач, двигун, крило літака, контролер, гамбургер, страховий поліс, множина яких обмежена лише нашою фантазією! Усі вони є частинками певного застосування, а моделювання ПЗ з їх використанням є реалізацією принципу модульності.
Абстракція. Принцип не потребує коментування. Відзначимо, що усе ПЗ є абстракцією. Абстракція дозволяє нам створювати складні системи. Абстракція подарувала нам поняття класу, об’єкту, події, функції, бібліотеки, тощо. Розробка ПЗ є складною. ПЗ є найскладнішим продуктом, що створює людина. Якщо задатися запитанням: а скільки інженерів-механіків я знаю? А скільки інженерів програмістів? Думаю, останніх у декілька разів більше. Гадаю, саме робота на надто низькому рівні абстракції змушує компанії наймати усе більше інженерів з ПЗ та виставляти захмарні ціни за розроблення та супроводження ПЗ. РКМ дає можливість підвищувати рівень абстракції та створювати нові абстракції, що краще відповідають потребам зацікавлених у розробці сторін.
Передбачення змін наголошує на тому, що необхідно передбачати та створювати зручні умови для внесення змін у ПЗ. Як правило, реалізацію цього принципу забезпечують модульність та розділення відповідальності. Якщо різні аспекти системи модельовані окремо, то можна легко змінювати окремо від інших аспектів бізнес-логіку, архітектуру, базову абстрактну машину (мови програмування, операційні системи, проміжне ПЗ, бази даних, тощо). Тобто РКМ надає інструменти для ефективної реалізації принципу передбачення змін.
Звісно, РКМ не є срібною кулею, гадаю такої кулі не буде винайдено. Однак, на мою думку, це закономірний рух уперед і дозрівання розробки програмного забезпечення до інженерної дисципліни. Автор коментованої доповіді відзначив, що моделювання має стосуватися не лише конструювання ПЗ, а й інших фаз розробки, особливо збору вимог, та розгортання. З цим важко не погодитися, тому правильніший термін був би не розробка, керована моделлю, а інженерія ПЗ, керована моделлю. Аби така інженерія стала реальністю, необхідно ще дуже багато наукових досліджень та практичної роботи.
Отже, чи є майбутнє у інженерії ПЗ, керованої моделлю? Судячи з усього так, інакше немає майбутнього у ПЗ як такого.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail