➖ Сьогодні дізнався цікаву інформацію - випускник мого місячного курсу HTML/CSS/JS Fundamentals, який знайшов роботу відразу на наступний день після закінчення курсу, пропрацював лише місяць розробником, після чого полишив роботу в IT, бо вона йому здавалася нудною, і висиджувати вісім годин в офісі в нього не вистачало сил. 🙈
➖ Це примусило задуматися над такою неочікуваною проблемою, над якою рідко думають люди, коли навчаються, щоб стати розробником.
➖ Можу сказати, що є варіант не лише в аутсорсі працювати, можна в продуктовій компанії, але треба постаратися "заразитися" тим продуктом, щоб цікаво було. Бо як дійсно нудно і нецікаво - то не варте воно того.
➖ Також для тих, хто фізично не витримує цілий день сидячи - є столи, які дозволяють перемикати режими і частину часу працювати стоячи, в самого такий, дуже зручно.
➖ Також свою роботу можна урізноманітнити, наприклад, брати ноутбук кудись в кафешку, бібліотеку, або частину роботи виконувати вдома. Таким чином можна робочий день на одному місці можна скоротити з восьми до чотирьох годин - тоді вже навіть не помічаєш як пролітає час.
➖ Наприклад в мене робота часто займає годин 10-12 на добу, але я виконую її в різних умовах і місцях, облаштував собі комфортне робоче місце вдома, багато часу проводжу на різних локаціях, важливо мати зручний портативний лептоп з гарним акумулятором.
➖ На своєму робочому місці, яке також достатньо комфортне, однак не завжди тихе, я проводжу зовсім небагато часу. На робочому телефоні налаштовано редирект на мобільний - люди, які працюють зі мною часто поняття не мають де я знаходжуся.
➖ Наприклад, зовсім недавно вирішував робоче питання по телефону, під час розмови коллега сказала, що хотіла б зустрітися, передати деякі документи - я відповів, що можна просто залишити в мене на столі, я подивлюся як повернуся, вона навіть не зрозуміла, що я працюю взагалі з іншої країни. 😜
➖ На завершення напишу, що колись зустрічав гарну фразу - все може бути цікавим, якщо йому приділити достатньо уваги 💪

Готуюсь до свого виступу в четвер на цій події - Front-end Developer Club 😎
І відкопав дещо цікаве - перший веб-сайт, який коли-небудь був зроблений. ❗️
Ось його адреса: http://info.cern.ch/hypertext/WWW/TheProject.html
Але в вашому браузері він навряд чи буде виглядати аутентично.
Більшість відвідувачів на початку дев'яностих його бачили так
Ну і найцікавіше - це заглянути в код і зустріти для себе багато нового 🤓
Запрошую на подію - буде цікаво, поговоримо про сучасні тренди в фронтенді і про те, як його то все вивчати 😜

Починаючий розробник не завжди розуміє, що "зроблено" - це поняття відносне. Корисна стаття на ДОУ про Definition of Done

Під час виступу на події Front-end Developer Club я згадував про Trampoline (батут) - дуже цікава техніка в програмуванні, яка дозволяє використовувати рекурсію без ризику переповнення стеку.
Знайшов відео на ютубі від Kyle Simpson (відомого своєю серією книжок You Don't Know JavaScript з поясненням техніки, ось посилання на відео: Trampolines.
Окремо даю лінк на детальне пояснення зі StackOverflow

Із серії - Відповіді на коментарі
Власне вчора у відповідь на питання в ФБ підкину лінк на пояснення ООП в JavaScript.
Відразу виникло питання - навіщо воно в веб-розробці?.
Ось моя відповідь:
➖ООП як концепція розроблено для спрощення реалізації великих проектів, бо підходи, які існували раніше, просто не справлялися з цим, складність проектів зростала настільки, що в якийсь момент продовжувати розробляти або супортити ставало економічно недоцільно.
➖Зараз це домінуюча парадигма програмування, тобто вже питання не стоїть у такому плані "використовуємо ООП" чи "не використовуємо ООП" - по дефолту завжди перша відповідь (звісно якщо не брати до уваги проекти, що робляться на функціональних мовах, там інший світ).
➖А тепер до веб-розробки: зовсім недавно на своєму виступі в Front End Developer Club я показував як еволюціонувала веб-розробка з 1991 року і те, що її складність постійно збільшується. Під "складністю" мається на увазі не просто складність написання коду для розробнику, вона як раз завжди знаходиться приблизно на одному рівні, а складність інструментів і технологій, кількість задіяного всього в проекті. Логіка всі більше переходить на фронтенд, вона або дублює бекенд, або взагалі підміняє його там, де це можна зробити.
➖Відповідно треба використовувати ООП, а для того, щоб його використовувати - треба розуміти. Насправді розібратися з тим усім зовсім не так складно, як здається на перший погляд :)
➖Звісно, якщо ми клепаємо черговий лендинг, де з усієї логіки - відправка форми на бекенд, то можна тим не перейматися. Але якщо хочемо зростати професійно, ще код JS для ноди писати, то без того вже ніяк :)
➖Варто розібратися з тими прототипами, заглядувати в сорс-код бібліотек, там багато цікавого.

Думаю багатьом знайома ситуація, коли по туторіалам все вдається, а по факту - наявності реальних знань і навиків не відчувається. 😨
Цікава стаття про те, як вибратися з полону туторіалів.
Основна ідея - треба вийти з зони комфорту і почати робити проекти без покрокових інструкцій, бо туторіал - це все-таки зона комфорту, де тебе ведуть протоптаним шляхом, тут складно робити помилки, а вчимося ми в першу чергу з помилок (це вже окрема нотатка від мене) 😜

На початку червня в Берліні пройшла конференція JSConf EU 2018. Багато цікавих спікерів, але мене особливо зацікавила доповідь Раяна Даля (Ryan Dahl) - автора Node.JS з вельми гучним заголовком 10 Things I Regret About Node.js.
Раян проливає світло на деякі рішення, прийняті під час створення Node.JS, а також пояснює, чому зараз вони здаються йому невдалими.
В це складно повірити, але багато з того, що ми знаємо про Node.JS його автор зараз вважає не дуже вдалими ідеями, зокрема:
➖використання системи збірки GYP для node;
➖використання коллбеків для асинхронного вводу-виводу (була можливість з самого початку використати промізи, але її довелося відкинути);
➖використання функції require() для підключення модулів без зазначення точного імені модуля і його розширення;
➖локальне збереження модулів;
➖використання файлу package.json для резолюції модулів;
➖поставка npm в комплекті з node та його репозиторію пакетів;
➖відсутнісь вбудованого механізму security, що обмежує доступ node до файлової системи чи мережі;
➖одне з найбільш цікавих: використання мови з динамічною типізацією (JavaScript).
Зараз Раян працює над новим проектом Deno, який фактично є альтернативою до Node.JS, використовує TypeScript як мову програмування (до речі, Раян багато позитивного говорить саме про TypeScript).
Персональний висновок від мене: часто буває так, щоб щось зробити успішним, його треба зробити швидко, якщо дуже довго продумувати деталі, то воно може не взлетіти. 🤓

Завтра для спільноти .NET-розробників буду розказувати про те, як писати гарний код на JavaScript
Приходити можна не лише .NET-розробникам, на вході тесту по C# не буде :)

Цікава історія на ДОУ (https://dou.ua/lenta/articles/from-driver-to-developer/) про водія-далекобійника, який зміг отримати роботу .NET-розробника.
Основні висновки:
➖головне - це мотивація, тоді ніякі зовнішні обставини не стануть назавді;
➖навчання через практику по скрінкастам дуже ефективне;
➖навчатися самостійно складно, але можливо;
➖навряд чи настане чітко визначений час, коли ти впевнений в тому, що вивчив достатньо, щоб шукати роботу, але в якийсь момент необхідно почати активно діяти;
➖під час пошуку роботи в основному вирішує моральна стійкість і наполегливість;
➖треба бути готовим до відмов і провалів, і не розглядати це як катастрофу, а вміти з кожної подібної ситуації отримувати корисний досвід.

Міфи браузерної сумісності: div, що виглядає по-різному в різних браузерах: https://twitter.com/Martijn_Cuppens/status/1015169981368225793?s=17

Репост коментаря на ФБ про роботу ментора з різними людьми.
➖Якщо це повний новачок, то звісно робота більше схожа на традиційне навчання, де все треба показувати і пояснювати. Тим не менше, досвід показує, що такий підхід як "practice first" працює найкраще, тобто ти пишеш якийсь код, просиш повторити його, людина це робить, отримує впевненість в собі, долає певний психологічний бар'єр, щоб почати кодувати, власне я так його і називаю "coding barrier" аналогічно до "speaking barrier". Ще для новачка дуже важливо сформувати шлях, яким слід рухатися, бо деякі з них, наприклад, хочуть вчити Angular і вважають, що HTML/CSS/JS можна пропустити.
➖ Далі люди, які вже щось знають/вміють (скажімо так, рівень "trainee") мають проблему, яка полягає в тому, що вони формально можуть зробити якусь роботу, а реально їхнє рішення повне різних "coding smells", антипаттернів і т.п. Тут потрібно працювати в іншому ключі - вже не треба постійно стояти за спиною, достатньо скеровувати людину на якісь ресурси і рев'ювати її роботу. Щоб не топтатися на місці, треба рухатися за певним планом відповідно до цілей, які хотілося б досягти. Особливо важливою на цьому етапі є організація командної роботи, бо щось потихеньку кодити самому і робити проект в команді - все-такі дві великі різниці.
➖Ну і нарешті - це вже діючі розробники (від джуніорів до сеньйорів) - з ними найскладніше, бо вони часто впевнені, що вже все знають/вміють, але я їх прекрасно розумію, бо коли мені було 25 років, то теж так думав :) Тут справа в тому, що рідко хто визнає, що йому потрібна допомога ментора, це вже якийсь психологічний бар'єр притаманний нашій культурі. Хоча буває, що до мене часто звертаються за консультацією люди, які технічно в певних напрямках вже давно сильніші за мене, але вони не бояться чогось запитатися, не переймаються тим, що хтось подумає, що вони чогось не знають. Тут часто питання зводиться до того, в якому напрямку рухатися, щоб не засидітися на місці, як правильно розвиватися, технології/архітектури обирати, що в тренді і тому подібне. Буває так, що людина сама все розуміє і їй ментор потрібен просто як той, хто може змотивувати, додаткове джерело відповідальності.

Люблю роадмепи, вони наглядно показують, що рекомендуюється вчити, і в якій послідовності. Ловіть роадмеп для Angular-розробника 2018

Відразу люди почали питати про роадмеп по React, то ось, тримайте

➖Ще більше роадмепів - на цей раз всеохоплюючий план самостійної підготовки як Software Engineer, фактично - повна альтернатива університетській освіті. 🤓
➖Автор цього плану розробив його для себе. Не маючи університетської освіти в Computer Science, він вирішив самостійно підготуватися до такого рівня, щоб отримати роботу в одній з найкращих світових IT-компаній. На самопідготовку по плану він витратив 11 місяців і минулого року його взяли на роботу в Amazon, підрозділ, що займається AWS. 💪
➖До речі, було йому тоді 45 років - це особлива примітка для тих, хто говорить, що "вже пізно щось змінювати". 😜

Із серії мої коментарі в фейсбуці. 🤓
➖Люди, які приходять зі строго типізованих мов, відразу починають шукати типізацію в JavaScript, але насправді то зовсім не факт, що воно треба. Справа в тому, що всіх базових типів даних в JS всього сім, з них лише три безпосередньо зберігають дані - Number, String та Boolean. Працюючи з числами, розробнику не потрібно заморочюватися розрядністю, задумуватися про знак, чи вирішувати питання ціле/дійсне - ти просто працюєш з числами 　
➖Навіщо взагалі потрібна строга типізація - ну наприклад для того, щоб випадково не викликати помилку виконання і не втратити інформацію, записавши дані в змінну, яка вказує на комірку пам'яті, яка їх не може вмістити. Але ж JS динамічна мова, такого бути не може в принципі - змінна буде завжди мати саме той тип, який ми в неї записуємо. Тут інше питання може бути - це коли з-за нашого незнання чи неуважності спрацював механізм автоконвертації типів і замість доданих двох чисел ми отримуємо сконкатеновані рядки символів, бо одне з чисел насправді було не числом, а рядком. В такому випадку статична типізація допомогла б, але є інший варіант - це розібратися з роботою конвертації і програмувати в функціональному стилі, уникаючи змінних взагалі.
➖Створюючи не змінні, а константи, ми завжди маємо розуміти, якого типу вони будуть, а надалі відповідно розуміти їх поведінку в виразах. Це зовсім не так складно, як здається на початку, питання звички. Треба уникати неявної конверсії типів, якщо вже робити, то явно, при перевірці на рівність використовувати оператор '===', а не '=='.
➖Ну і нарешті, а чи дійсно статична типізація є саме тою вундервафлею, що допомагає нам уникати помилок, можливо є щось краще? Дійсно, статична типізація допомагає в певних випадках, але далеко не гарантує коректність коду, є значно кращий механізм, на використання якого варто потратити зусилля - це юніт-тести.
➖Саме юніт-тести, за умови, якщо вони добре складені, і є тим механізмом, що захищає код від помилок. І шукати в статичній типізації те, чого вона не може дати в принципі, зовсім не варто. Можна легко створювати якісний код без статичної типізації, перевіряючи його юніт-тестами. Варто лише навчитися їх писати, бо то ціла наука, і у багатьох випадках пишуть їх не дуже відповідально, щоб перевірити коректність функції недостатньо викликати її один раз з довільними параметрами, потрібно розглянути граничні значення, перевірити роботу з некоректними аргументами і т.п. Є такі техніки EP+BVA, які використовують тестувальники, але рідко застосовують девелопери.
➖Ну а тепер про TypeScript - дійсно це дуже гарна річ, але показує вона себе в крупних проектах, часто можна обійтись Vanilla JS. Якщо говорити про сторонні бібліотеки, то в TS є можливість підгружати файли з анотаціями типів, які створені для великої кількості сторонніх бібліотек, я якщо таких анотацій немає - то можна попрописувати самому, просто не факт, що то більш корисні витрати часу, ніж на юніт-тести 😜

Продовжуємо коментарі. У відповідь на таке:

 треба з JS тривалий час попрацювати, щоб склалось чітке враження. Поки що пишу перший проект на JS і плююсь та матюкаюсь. До цього я вже років 20 як програмую на різних мовах (Assembler, C++, Delphi, C#, Java). Найбільше я полюбив C#, це дійсно насолода

👉Є така справа - приходять люди з "класичних" мов і лаються на JS, ніби все нелогічне і зроблене через одне місце. Але зараз багато людей, які починали з нуля на JS і те саме говорять про інші мови. Я взагалі з першої категорії, але відчуваю, що останнім часом більше згоден з тими, хто з другої. 🙈 В JS насправді немає зайвих ускладнень, і після того, як ти розібрався з певними речами, ти починаєш розуміти її гнучкість і простоту.
😱Мало того, деякі речі, які тобі здавалися нерушимими шаблонами, JS розриває. Наприклад, всі звикли до ООП з класами, але відомо, що ООП створене так, що за взірець взятий реальний світ. Однак у реальному світі класів немає, лише об'єкти. Так модель ООП в JS без класів насправді і є більш коректною моделлю, ніж те, до чого ми звикли :)
😜Якщо любиш C#, то TypeScript - саме те що треба, особливо якщо взяти до уваги, що робить їх одна й та ж сама людина

​​Ну що ж, літо скінчилося, пора до роботи. В День Знань варто знання перевірити. Ось вам веселий тест по JS-фреймворкам

Веб-розробник сам не свій без API. Ось вам списочок

➖Одна з найпопулярніших книжок по JavaScript - це JavaScript: The Good Parts від Дугласа Крокфорда, який ще відомий тим, що придумав формат JSON. Сама книжка вийшла в 2008 році і трішки застаріла, однак основні концепнції мови не змінилися з того часу, тому вона навіть через 10 років варта уваги.
➖Проте сьогодні мова не про саму книжку - на гітхабі є цікавий репозиторій, де основні ідеї книжки викладені у стиснутому вигляді з лінками і прикладами коду. Однозначно - в закладки, вивчати і повторювати 🤓
➖Лінк на саму книжку: JavaScript: The Good Parts на сайті видавництва, а тут можна знайти форматі PDF на гітхабі