Цей день настав

Чи знаєте ви, чому джедайський курс JavaScript називається “ScriptJedi42”, а не “JavaScriptJedi42” чи щось подібне?

Відповідь знаю я, бо ще з моменту його першого запуску у 2019 передбачалося, що він буде не лише по JavaScript, а також і по TypeScript, але згодом, коли мова набере достатньо поширення.

Свій перший код на TypeScript я написав років 10 тому, лиш тільки ця мова з’явилася на публіці, і мова мені дуже сподобалася. Менів вона була цікава концептуально, бо вона ідейно близька до C#, на якому я в той час активно займався комерційною розробкою. А ще у них обох один батько - Андерс Гейлсберґ, з роботою якого я був добре знайомий по Turbo Pascal / Delphi.

Хто нічого не знає про TypeScript, то простими словами це надбудова над JavaScript, яка в першу чергу додає можливість зазначати в коді типи даних і захищає від дуже поширених помилок, що виникають в результаті некоректного використання типів. Наприклад, коли передається текст, а очікується число, чи в об’єкті відсутній ключ з певною назвою. Звичайний JavaScript про такі помилки нічого не знає, і ви їх зустрінете вже коли проєкт буде працювати, а TypeScript - видасть помилку на етапі компіляції, і дасть змогу її відразу виправити. Важливо розуміти, що TypeScript не є окремою мовою, під час компіляції він трансформується в JavaScript, і всі нюанси останнього треба розуміти дуже добре.

Але якийсь час про TypeScript мало хто знав, і лише з виходом Angular 2 у вересні 2016 про мову почали говорити активно. І вже за два місяці я проводив свій перший воркшоп для розробників, ось навіть запис зберігся https://youtu.be/_UxchN7O1Ws . Цікаво, що за 6+ років з того часу в TypeScript з’являлися нові фічі і актуальна версія на сьогодні вже 5.0, однак практично все що було на тому воркшопі залишаєтсья актуальним, можете переглянути (практична частина там починається з 10-ї хвилини, і звук стає стабільний, бо то запис зі сцени, мікрофон був на столі, також лінк на код є).

Але популярність мова TypeScript набувала поступово, частково завдяки тому, що на перші ролі вийшов React, де традиційно без неї обходилися. І в 2019 році, коли я запускав ScriptJedi42, то просто вирішив почекати поки TypeScript набере достатньої популярності.

І так, цей день настав. У 2023 році приблизно кожен другий проєкт під фронтенд чи фулстек з NodeJS/NextJS/Remix стартує з TypeScript, і якщо ви в додачу до JS знаєте TS, то елементарно подвоюєте свої шанси на ринку.

Отже, тепер TypeScript є стандартною частиною курсу ScriptJedi42. Відразу стартуємо з його новою п’ятою версією. Для нього відводиться додатковий тиждень - таким чином тривалість курсу тепер становить 7 тижнів (49 днів). Цей тиждень виглядає аналогічно іншим тижням курсу - є теоретичні матеріали та набір практичних задач з автоматичною перевіркою на кожен день, які потрібно виконати і здати код на перевірку, я проводжу рев’ю і даю свої коментарі до коду. І звичайно що на ретроспективі розбираємо правильні способи зробити завдання. Модуль ми відтестували ще з групою, яка стартувала в січні, для них був незапланований бонус. 🙂

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

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

Також всі, хто завершили джедайський курс в минулому, мають можливість отримати доступ до модуля TypeScript в рамках нашої закритої джедайської спільноти, лише сконтактуйте зі мною.

Як працювати на кількох роботах одночасно

Вже десь так і працюємо

Тут в блозі на StackOverflow вийшла цікава стаття.

Виявилося, що зараз вже понад 70% розробників зазначають як своє основне джерело знань не формальну університетську освіту, а онлайн-джерела.

Якщо добре розуміти як працює університетська освіта, то тут нічого дивного немає - її основна мета полягає в підготовці науковців та дослідників, ну а те що виходить ще готувати інженерів - то більше побічний продукт 🙂

І чим далі, тим та прірва буде зростати, завершивши університет ти зазвичай все одно не застрибнеш на роботу без додаткової підготовки.

Тому меседж для студентів: знімайте рожеві окуляри, сподіваючись, що універ всьому навчить, і що “відмінно” в заліковій книжці означає, що візьмуть на роботу автоматом.

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

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

Також додам що для подальшої кар’єри, коли ти хочеш копнути більше, то університетські знання будуть потрібні, але оптимальніше їх здобувати в режимі lifelong learning. Ну і дуальна освіта в цьому контексті має сенс, якщо вона правильно організована, звісно.

Сьогодні чистий четвер - день чистого коду, то маю для вас щось цікавеньке по темі🙂

Тут недавно в інтернетах-твітерах розгорілася цікава дискусія про “Чистий код проти швидкості”.

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

Відосик набрав сотні тисяч переглядів, викликав купу баталій, навіть до Дядько Боб підключився, він створив репозиторій з поясненнями та прикладами.

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

Іноді абстракції нам даються досить дешево з точки зору продуктивності, є навіть поняття “zero cost abstraction” - це коли якісь абстракції, наприкад, система статичної типізації, здійснюються в момент компіляції і зникають під час виконання коду. З іншого боку є ну прям дуже дорогі - наприклад, автоматичне керування пам’яттю зі збірником сміття. Але ми розуміємо навіщо платимо - помилки в керуванні пам’яттю обходяться дуже дорого.

То чим погано купа switch/if - тим що в коді з’являється багато можливих шляхів виконання, це ускладнює тестування, бо на кожен шлях треба мінімум один юніт-тест. Є таке поняття “цикломатична складність” - її важливо зменшувати. Поліморфізм в ООП дозволяє позбутися розгалужень і потрібну поведінку ми отримуємо за рахунок наслідування, а не розгалужень в коді, і цикломатична складність при цьому не зростає.

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

Далі стосовно того, що треба робити маленькі функції, функція повинна робити “one thing”, але незрозуміло що це таке. Насправді визначити те, чи достатньо маленька функція дуже просто - це коли вже її не можна розбити на інші функції, це і буде той “one thing”. Навіщо нам це робити? Дуже просто - принцип поділу на малі частини один із фундаментальних в програмуванні, бо їх простіше реалізувати, тестувати, перевикористовувати. Тут взагалі якісь контраргументи складно приводити - менше і простіше завжди краще ніж більше і складніше.

Ну і останнє, що там згадали - це DRY - Do Not Repeat Yourself. Тут навіть обговорювати нічого - дублювання коду є великим злом. Цікаво, що колись мав досвід спілкування зі співробітником Microsoft, який працює у своєрідній “внутрішній поліції”, робота якої полягає в тому, щоб шукати в проєктах речі, що дублюються і випилювати їх, попутно роздаючи “антипеченьок”, щоб не робили так знову. Можете собі уявити масштаб проблеми, якщо вони для того цілий підрозділ тримають?

Ну то висновок з того простий - фільтруйте ютуберів, читайте якісні джерела. Прогляньте коментарі від Дядка Боба. Майте чистий код.

Христос Воскрес! Сьогодні Пасха, значить поговоримо про пасхалочки в коді.

В 1986 році під час портування іграшки для приставки Nintendo розробник вбудував код, який активував чіти після натискання послідовності клавіш.
Згодом ту послідовність почали вбудовувати в іграшки компанії Konami, за що й отримала назву “Код Konami”.

Можливо ви цього не знаєте, але код став свого роду культом і його зустріти можна далеко за межами іграшок, на купі різних серйозних сайтів.
Є купа готовий імплементацій у вигляді бібліотек, ось наприклад, для реакту: https://www.npmjs.com/package/react-konami-code

Звичайно, що пасхалочки тільки такою комбінацією не обмежуються, і навіть складно уявити скільки їх є в тих сервісах, якими користуємося щодня.
Я сам таке люблю і в деяких проєктах пасхалочки додавав, не про все можна розказувати :)

А ви робили пасхалочки?

Вихід з IT є https://lviv1256.com/news/it-spetsialist-vyrostyv-bilia-lvova-800-kushchiv-konopli/

Ось вам лайфхак, як за допомогою ChatGPT можна перевіряти ваші практичні навички.

1. Запит виглядає наступним чином: "Can you check my knowledge of JavaScript, so you will ask questions that will require writing code to answer? I will write code and you will check if it is correct and provide feedback on my code." Замість JavaScript може бути що завгодно інше.
2. Пишете код, ChatGPT перевіряє чи він ок.
3. Якщо потрібно - просите його покращити, пояснити щось.

В цьому повідомленні лише сам запит, приклад переписки дам окремим повідомленням.

Приклад перевірки практичних навичок з ChatGPT.

Коментарі по питанням.
1. Тут я навмисно написав невірний код, щоб побачити як він зреагує. ChatGPT повідомив що рішення некоректне і видав правильне та пояснив його.
2. Тут я написав коректне рішення у сучасному стилі, до нього не мало б бути зауважень, ChatGPT відповідно відреагував.
3. Тут я написав коректне рішення, але не оптимальне з точки зору обчислювавльної складності. ChatGPT повідомив, що рішення коректне, проте не оптимальне і дав підказку, що було б варто використати Set, проте не надав оптимального коду і перейшов до наступного питання. Я попросив його це зробити, він зробив і пояснив.
4. Тут я зробив рішення що має недолік, який робить його некоректним (не додав початкове значення для reduce). Нажаль він не "побачив" його, проте написав коректне, коли я попросив покращити.

Висновок: інструмент корисний, але довіряти на 100% не можна, треба все перевіряти, в принципі, як і з людиною :)

А сьогодні у нас профсвято переписування CSS https://nationaltoday.com/css-reboot-day/

Сьогодні теж свято :)
Дякую джедаю Віктору Малиновському за чудовий подарунок.

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

Сьогодні та завтра на 17:00 буду виступати на цій події
https://career.softserveinc.com/en-us/landings/unlock-it-open-week-2023
Сьогодні будемо розбирати ChatGPT з прикладами для навчання, буду ділитися лайфхаками, вже трохи є :)
Завтра - порівняння його з Copilot.

DOU збирають респондентів для анонімного зарплатного опитування: https://dou.ua/goto/bnHM
Шукають ще 2 000 розробників, тож саме ваша анкета дуже важлива.
Проходження опитування займає всього 10 хв 🤌🏻
Приєднуйтесь!

Місяць JavaScript на каналі programming mentor

Нещодавно StackOverflow опублікував результати опитування, в якому JavaScript стабільно утримує перше місце уже більше 10 років. Якщо ж додати TypeScript, родича JS, то їх лідерство непереборне - 65,8% профі розробників користуються JS, а 43,75% TS.

І тут Дуглас Крокфорд - далеко не остання людина в світі JS зовсім недавно записав відео, де закликав відмовитися від мови через її недоліки. Тому я хочу це обговорити.

Безумовно, у Крокфорда є аргументи, але він забув зазначити головне: якщо не JS, то на чому ж ми повинні писати?

Так, технології не ідеальні. Але замінити їх не можна просто тому що ми усвідомили їх недоліки. Вивчення нового та переписання старого це велика робота і витрати. Та найскладніша проблема - це визначити, що ж саме буде "новим ідеальним". Як зрозуміти, що щось нове краще за старе? І тут все зовсім не просто.

Нова мова потребує нової інфраструктури. Вибираючи щось нове “прямо з лабораторії”, ми зтикаємося з відсутністю ресурсів - людей, бібліотек, платформ, інструментів.

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

Хочу зазначити, що JS не стоїть на місці. Мені подобається її шлях розвитку: старі функції залишаються, але нові, що щороку з'являються, впливають на сучасний код. Однак існує боязнь, що мова стане настільки великою, що вивчати її буде важко. Та зростаючі можливості AI з кодуванням і рефакторингом надихають: нам не обов’язково відразу вивчати всю мову, достатньо пропросити ChatGPT/Copilot пояснити або переписати незрозумілий код.

То що ж нас очікує? JavaScript, незалежно від недоліків, залишається "default language". Знаючи JS і TS, ви безперечно знайдете роботу, особливо якщо будете слідкувати за тим, щоб у сівішці було все те, що в топах рейтингів. І якщо захочете, то навіть зможете безперебійно працювати на JS до самої пенсії, не змінюючи технологічний стек, незважаючи на всі ті нові прекрасні мови, що безперечно вийдуть у майбутньому.

Тому оголошую місяць JavaScript на своєму каналі! Кожен день публікуватиму код, факти, кращі практики та лайфхаки JS. Якщо ви ще не доєдналися, то підписуйтеся на канал і поїхали :)

Лінки на опитування: публікація на Stackoverflow та скорочений варіант на ДОУ.

Отже, пост в рамках нашого місячника JS.
На скріні два рядки коду, що роблять одне й те саме - копію масиву.
Але по-різному - у першому рядку оператор розширення (spread), а у другому - деструктуризація (destructuring) та залишок (rest).
Коли люди починають вивчати JS, то часто spread і rest плутають, бо виглядає наче однаково (три крапки), але ніт, це різне 🙂
Також зверніть увагу, що це мілка (shallow) копія, але у зазвичай нам треба саме її, вона працює швидше за глибоку (deep copy).
Ну і задавалося б, оскільки робиться те й саме, то й працювати має з однаковою швидкістю.
Проте, як виявляється, також ніт - я зробив тест швидкості, можете самі переконатися. Однаково працює в файерфоксі та сафарі, але в хромі/еджі перший метод швидший разів в 7. Якось навіть соромно за них.

Продовжуємо наш марафон по JS.
Починаючи з 2015, новий стандарт ECMAScript тепер виходить кожного року, публікується в червні, на днях чекаємо ES2023.
Хочу розказати про те, як це взагалі відбувається. За стандарт відповідає організація Ecma International через технічний комітет 39 (TC39).
Зміни або доповнення до стандарту відбуваються відповідно до процесу:
Stage 0 "Strawman" (трохи дивна назва, перекладається як “Опудало”): На цьому етапі вноситься нова ідея або пропозиція. Вона ще не є частиною стандарту, але вже внесена в список розгляду. Така пропозиція може бути внесена будь-ким з членів TC39.
Stage 1 "Proposal" (Пропозиція): На цьому етапі пропозиція обговорюється комітетом. Якщо комітет вирішить, що ідея має потенціал, вона проходить на цей етап. Потрібно представити формальний опис ідеї, а також приклади, дослідження і потенційні проблеми.
Stage 2 "Draft" (Чернетка): На цьому етапі визначається точний синтаксис і семантика реалізації. Пропозиція на цьому етапі має бути в достатній мірі формальною і детальною, щоб можна було реалізувати прототип.
Stage 3 "Candidate" (Кандидат): На цьому етапі пропозиція зазвичай вже є готовою. Вона вимагає подальшого випробування у реальному середовищі, а також зворотного зв'язку від розробників і спільноти.
Stage 4 "Finished" (Завершений): Це останній етап перед тим, як пропозиція стає частиною офіційного стандарту ECMAScript. Цікаво, що на цьому етапі пропозиція повинна мати дві незалежних реалізації (умовно в двох різних браузерах), після чого вона може бути включена в наступну версію стандарту.
Що нам дає знання процесу? Навіть ще до виходу стандарту ми можемо розуміти які фічі в ньому будуть і сміливо почати використовувати та не перейматися тим, що може в стандарт не попасти.
Детально процес описано тут https://tc39.es/process-document/
Актуальна версія стандарту тут https://262.ecma-international.org/
Чернетка стандарту тут https://tc39.es/ecma262/

Про фігурні дужки в JS.
Вони мають аж три зовсім різні значення:
1. Блок коду - позначають групу рядків, які виконуються послідовно і мають власну область видимості змінних (scope). На скріні - це зовнішні дужки, в які вкладено весь рядок.
2. Літерал об'єкта - конструюють об'єкт прямо в коді, у даному випадку це {user: "John", age: 42}.
3. Деструктуризація об'єкта - дозволяє "розкласти" об'єкт на окремі змінні, у даному випадку const {user, age}.
Будьте уважні, не завжди дужки роблять те, що може здаватися на перший погляд :)

Продовжуємо тему дужок.
Зараз поширене завдання з інтерв'ю. Треба пояснити що відбувається :)
1) [] + []: Коли масиви перетворюються в рядки, вони стають порожніми рядками. Отже, "" + "" рівне "".
2) [] + {}: Масив перетворюється на рядок, стає "", а об'єкт перетворюється на рядок, стає "[object Object]". Тому "" + "[object Object]" рівне "[object Object]".
3) {} + []: Це трохи заплутано. Тут не додаються об'єкт і масив. Замість цього {} інтерпретується як порожній блок коду і ігнорується.+[] потім перетворює порожній масив в число, яке дорівнює 0.
4) {} + {}: Тут аналогічно попередньому - перші дужки {} інтерпретуються як порожній блок, а другі {} намагаємося сконвертувати в число, тому NaN.

Сьогодні розглянемо різні способи виконання функцій.

1) Звичайний виклик: fn()
Найзрозуміліший спосіб викликати функцію. Аргументи передаються в дужках після імені функції.

2) Виклик через call(): fn.call(thisArg, arg1, arg2, ...)
Метод call() дозволяє вам викликати функцію, встановлюючи значення this в середині функції. thisArg є об'єктом, який повинен бути значенням this в функції. arg1, arg2, ... - це аргументи, які передаються в функцію.

3) Виклик через apply(): fn.apply(thisArg, argsArray)
apply() дуже схожий на `call(), але аргументи передаються як масив, а не окремо. thisArg є об'єктом, який повинен бути значенням this в функції. argsArray - це масив аргументів, які передаються в функцію.

4) Виклик через оператор new: new fn (можна ще з дужками, але це не обов'язково). Коли функцію викликають за допомогою оператора new, JavaScript створює новий об'єкт, і цей об'єкт встановлюється як значення 'this' в середині функції. Не буде працювати для стрілочних функцій. Детальніше про роботу new в мене є на ютубчику https://youtu.be/qBt7pkqUCQY

5) Виклик через шаблонні літерали: `fn```
Нова фіча ES2015. Фунція викликається з масивом рядків і значень, що з'єднують рядки.

Ще можна згадати про bind(), виклик як метод об'єкту та можливість застосувати eval().