Тут в блозі на 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().

Все, що потрібно знати про NaN в JavaScript

Сьогодні поговоримо про таємничий NaN в JavaScript. Якщо ви коли-небудь працювали з числами в JS, ви напевно зіткнулися з ним. Не панікуйте, це не помилка, а спеціальна числова величина.

NaN (Not a Number) - це особливий значення, яке повертається, коли операція, що очікує отримати число як результат, не здатна це зробити. Наприклад, коли ми спробуємо поділити число на рядок:
console.log(42 / "fourty-two") // NaN

А як визначити, чи є наша змінна NaN?
JavaScript має для цього вбудовану функцію isNaN().
Проте, є одна особливість: ця функція спочатку намагається перетворити аргумент у число. Тож вона поверне true не тільки для NaN, а й для значень, які не можуть бути перетворені в число:
console.log(isNaN("forty-two")); // true
console.log(isNaN("42")) // false

Але не все так просто. Саме NaN є єдиним значенням в JavaScript, яке не є рівним самому собі. Це звучить дивно, але:
console.log(NaN === NaN) // false

Така особливість може привести до помилок при порівнянні. Тому, якщо ви хочете точно перевірити, чи є значення NaN, краще використовуйте функцію Number.isNaN(), вона не робить спроби конвертувати аргумент:
console.log(Number.isNaN(NaN)) // true
console.log(Number.isNaN("123")) // false

Отже, що ми маємо: NaN - це спеціальне значення в JavaScript, що вказує на неможливість виконання математичної операції.
Завжди використовуйте Number.isNaN() для точної перевірки на NaN.

Будьте уважні при роботі з числами в JS і завжди пам'ятайте про NaN, на відміну від інших мов JS не викличе помилку, а підсуне його коли не чекали :)

Сьогодні розберемося з об’єктом Number.

a: Об'єкт Number у JavaScript - це обгортка навколо примітивного числового значення. В прикладі ми створили новий екземпляр об'єкта Number з числом 42. Це буде об’єкт, не примітив, тому new Number(42) !== new Number(42)

b: Функція Number також може бути використана для перетворення рядків в числа. У прикладі рядок '42' перетворюється на числове значення 42. Оскільки тут без new, тому це примітив і Number('42') === Number('42')

c: Об'єкт Number має кілька вбудованих властивостей. Наприклад, в прикладі c Number.MAX_VALUE повертає максимальне допустиме числове значення в JavaScript. Аналогічно є Number.MIN_VALUE.

d: Number.isNaN() ми вже розбирали вчора, тут додав його для повноти картини.

e: Методи Number.parseInt() та Number.parseFloat() дозволяють конвертувати рядки в цілі та дійсні числа відповідно. Перший дозволяє ще передати систему числення як додатковий параметр.

f: Number.isFinite() перевіряє, чи є число скінченним. Це дуже корисно, коли ми хочемо впевнитися, що число не дорівнює Infinity, -Infinity чи NaN.

g: Number.isInteger() перевіряє, чи є значення цілим числом.

h: Number.isSafeInteger() перевіряє, чи є число безпечним цілим числом, тобто чи воно знаходиться в діапазоні, який можна точно представити в JavaScript. Вихід за ці межі призведе до помилок в обчисленні цілих чисел. Краще тоді використовуйте тип bigInt.

j: Так виглядає максимальне безпечне ціле число, аналогічно є мінімальне.

Нарешті опублікували новий стандарт ES2023🔥

Нового небагато, але є про що розказати.

a: Array find from last: Тут просто зручна дрібниція - нові методи для пошуку елементів з кінця масиву - findLast() та findLastIndex(). Вони виконують аналогічні завдання до find() та findIndex(), але в зворотному порядку.

b: Symbols як ключі WeakMap: Тепер тип Symbol можна використовувати символи як ключі WeakMap, дивно, що раніше такого не було, бо цей символ оригінально був створений в першу чергу для ключів.

c: Hashbang Grammar: Hashbang - це така юніксовська фіча, що дозволяє на початку файлу задати інтерпретатор для нього, тепер стандартно підтримується в JS, можна “нативно” запускати js-файли на юнікс-подібних ОС.

d: Change Array by Copy: Це самі важливі зміни, що вплинуть на написання коду. Тепер не треба окремо робити копію масиву, коли користуємося мутуючими методами, а масив міняти не хочемо - методи копію зроблять за нас. Отже, нові методи toReversed(), toSorted(), toSpliced() та with(), які повертають новий масив, змінюючи його без мутацій оригінального. Якщо з усіма іншими методами зрозуміло з назви, то до with() дам окреме пояснення - воно продукує новий масив, замінивши елемент з певним індексом на значення, що йде другом аргументом.

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