Завтра для спільноти .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 на гітхабі

VS Code отримав нову суперську функціональність - можливість робити рев'ю pull request на гітхабі прямо з IDE. Дуже люблю цю ідеєшку, правильно розвивається ❤️👍

Сьогодні 256-й день року! Вітаю всіх причетних зі святом! 🎂🍺 На його честь на dou.ua свіжі баяни завезли

Питання до інтерв'ю з Angular

📱Сучасний респонсів - це значно більше, ніж media queries в CSS-коді. JavaScript теж може дечим похвалитися. 😜 Цікава стаття про респонсів JavaScript, читати краще зі смартфона, відразу перевіряючи приклади - визначення статусу онлайн/офлайн, керування вібромоторчиком, видимість вкладки та інше. 👏

Улюблений VS Code отримав цікаву можливість транслювати ланцюжки промізів у виклик async/await 👍

Всі знають динозаврика 🦖 з Хрому. Виявляється йому нещодавно виповнилося 4 роки. На офіційному блозі браузера опублікували історію його виникнення. Якщо інтернет у вас є, а в динозаврика бажаєте погратися, то є спеціальний режим, достатньо ввести в адресному рядку chrome://dino 🦕

Цікава стаття від фронтендера з Wix.com про мову програмування, яку він шукає. Згадується багато трендових мов та деякої екзотики, дуже корисно для розширення загального світогляду