Міфи браузерної сумісності: div, що виглядає по-різному в різних браузерах: https://twitter.com/Martijn_Cuppens/status/1015169981368225793?s=17
Twitter
Martijn Cuppens
The div that looks different in every browser https://t.co/hXmxoLA8fW
Репост коментаря на ФБ про роботу ментора з різними людьми.
➖Якщо це повний новачок, то звісно робота більше схожа на традиційне навчання, де все треба показувати і пояснювати. Тим не менше, досвід показує, що такий підхід як "practice first" працює найкраще, тобто ти пишеш якийсь код, просиш повторити його, людина це робить, отримує впевненість в собі, долає певний психологічний бар'єр, щоб почати кодувати, власне я так його і називаю "coding barrier" аналогічно до "speaking barrier". Ще для новачка дуже важливо сформувати шлях, яким слід рухатися, бо деякі з них, наприклад, хочуть вчити Angular і вважають, що HTML/CSS/JS можна пропустити.
➖ Далі люди, які вже щось знають/вміють (скажімо так, рівень "trainee") мають проблему, яка полягає в тому, що вони формально можуть зробити якусь роботу, а реально їхнє рішення повне різних "coding smells", антипаттернів і т.п. Тут потрібно працювати в іншому ключі - вже не треба постійно стояти за спиною, достатньо скеровувати людину на якісь ресурси і рев'ювати її роботу. Щоб не топтатися на місці, треба рухатися за певним планом відповідно до цілей, які хотілося б досягти. Особливо важливою на цьому етапі є організація командної роботи, бо щось потихеньку кодити самому і робити проект в команді - все-такі дві великі різниці.
➖Ну і нарешті - це вже діючі розробники (від джуніорів до сеньйорів) - з ними найскладніше, бо вони часто впевнені, що вже все знають/вміють, але я їх прекрасно розумію, бо коли мені було 25 років, то теж так думав :) Тут справа в тому, що рідко хто визнає, що йому потрібна допомога ментора, це вже якийсь психологічний бар'єр притаманний нашій культурі. Хоча буває, що до мене часто звертаються за консультацією люди, які технічно в певних напрямках вже давно сильніші за мене, але вони не бояться чогось запитатися, не переймаються тим, що хтось подумає, що вони чогось не знають. Тут часто питання зводиться до того, в якому напрямку рухатися, щоб не засидітися на місці, як правильно розвиватися, технології/архітектури обирати, що в тренді і тому подібне. Буває так, що людина сама все розуміє і їй ментор потрібен просто як той, хто може змотивувати, додаткове джерело відповідальності.
➖Якщо це повний новачок, то звісно робота більше схожа на традиційне навчання, де все треба показувати і пояснювати. Тим не менше, досвід показує, що такий підхід як "practice first" працює найкраще, тобто ти пишеш якийсь код, просиш повторити його, людина це робить, отримує впевненість в собі, долає певний психологічний бар'єр, щоб почати кодувати, власне я так його і називаю "coding barrier" аналогічно до "speaking barrier". Ще для новачка дуже важливо сформувати шлях, яким слід рухатися, бо деякі з них, наприклад, хочуть вчити Angular і вважають, що HTML/CSS/JS можна пропустити.
➖ Далі люди, які вже щось знають/вміють (скажімо так, рівень "trainee") мають проблему, яка полягає в тому, що вони формально можуть зробити якусь роботу, а реально їхнє рішення повне різних "coding smells", антипаттернів і т.п. Тут потрібно працювати в іншому ключі - вже не треба постійно стояти за спиною, достатньо скеровувати людину на якісь ресурси і рев'ювати її роботу. Щоб не топтатися на місці, треба рухатися за певним планом відповідно до цілей, які хотілося б досягти. Особливо важливою на цьому етапі є організація командної роботи, бо щось потихеньку кодити самому і робити проект в команді - все-такі дві великі різниці.
➖Ну і нарешті - це вже діючі розробники (від джуніорів до сеньйорів) - з ними найскладніше, бо вони часто впевнені, що вже все знають/вміють, але я їх прекрасно розумію, бо коли мені було 25 років, то теж так думав :) Тут справа в тому, що рідко хто визнає, що йому потрібна допомога ментора, це вже якийсь психологічний бар'єр притаманний нашій культурі. Хоча буває, що до мене часто звертаються за консультацією люди, які технічно в певних напрямках вже давно сильніші за мене, але вони не бояться чогось запитатися, не переймаються тим, що хтось подумає, що вони чогось не знають. Тут часто питання зводиться до того, в якому напрямку рухатися, щоб не засидітися на місці, як правильно розвиватися, технології/архітектури обирати, що в тренді і тому подібне. Буває так, що людина сама все розуміє і їй ментор потрібен просто як той, хто може змотивувати, додаткове джерело відповідальності.
Люблю роадмепи, вони наглядно показують, що рекомендуюється вчити, і в якій послідовності. Ловіть роадмеп для Angular-розробника 2018
GitHub
GitHub - sulco/angular-developer-roadmap: Angular Developer Roadmap
Angular Developer Roadmap. Contribute to sulco/angular-developer-roadmap development by creating an account on GitHub.
➖Ще більше роадмепів - на цей раз всеохоплюючий план самостійної підготовки як Software Engineer, фактично - повна альтернатива університетській освіті. 🤓
➖Автор цього плану розробив його для себе. Не маючи університетської освіти в Computer Science, він вирішив самостійно підготуватися до такого рівня, щоб отримати роботу в одній з найкращих світових IT-компаній. На самопідготовку по плану він витратив 11 місяців і минулого року його взяли на роботу в Amazon, підрозділ, що займається AWS. 💪
➖До речі, було йому тоді 45 років - це особлива примітка для тих, хто говорить, що "вже пізно щось змінювати". 😜
➖Автор цього плану розробив його для себе. Не маючи університетської освіти в Computer Science, він вирішив самостійно підготуватися до такого рівня, щоб отримати роботу в одній з найкращих світових IT-компаній. На самопідготовку по плану він витратив 11 місяців і минулого року його взяли на роботу в Amazon, підрозділ, що займається AWS. 💪
➖До речі, було йому тоді 45 років - це особлива примітка для тих, хто говорить, що "вже пізно щось змінювати". 😜
GitHub
GitHub - jwasham/coding-interview-university: A complete computer science study plan to become a software engineer.
A complete computer science study plan to become a software engineer. - jwasham/coding-interview-university
Із серії мої коментарі в фейсбуці. 🤓
➖Люди, які приходять зі строго типізованих мов, відразу починають шукати типізацію в JavaScript, але насправді то зовсім не факт, що воно треба. Справа в тому, що всіх базових типів даних в JS всього сім, з них лише три безпосередньо зберігають дані - Number, String та Boolean. Працюючи з числами, розробнику не потрібно заморочюватися розрядністю, задумуватися про знак, чи вирішувати питання ціле/дійсне - ти просто працюєш з числами
➖Навіщо взагалі потрібна строга типізація - ну наприклад для того, щоб випадково не викликати помилку виконання і не втратити інформацію, записавши дані в змінну, яка вказує на комірку пам'яті, яка їх не може вмістити. Але ж JS динамічна мова, такого бути не може в принципі - змінна буде завжди мати саме той тип, який ми в неї записуємо. Тут інше питання може бути - це коли з-за нашого незнання чи неуважності спрацював механізм автоконвертації типів і замість доданих двох чисел ми отримуємо сконкатеновані рядки символів, бо одне з чисел насправді було не числом, а рядком. В такому випадку статична типізація допомогла б, але є інший варіант - це розібратися з роботою конвертації і програмувати в функціональному стилі, уникаючи змінних взагалі.
➖Створюючи не змінні, а константи, ми завжди маємо розуміти, якого типу вони будуть, а надалі відповідно розуміти їх поведінку в виразах. Це зовсім не так складно, як здається на початку, питання звички. Треба уникати неявної конверсії типів, якщо вже робити, то явно, при перевірці на рівність використовувати оператор '===', а не '=='.
➖Ну і нарешті, а чи дійсно статична типізація є саме тою вундервафлею, що допомагає нам уникати помилок, можливо є щось краще? Дійсно, статична типізація допомагає в певних випадках, але далеко не гарантує коректність коду, є значно кращий механізм, на використання якого варто потратити зусилля - це юніт-тести.
➖Саме юніт-тести, за умови, якщо вони добре складені, і є тим механізмом, що захищає код від помилок. І шукати в статичній типізації те, чого вона не може дати в принципі, зовсім не варто. Можна легко створювати якісний код без статичної типізації, перевіряючи його юніт-тестами. Варто лише навчитися їх писати, бо то ціла наука, і у багатьох випадках пишуть їх не дуже відповідально, щоб перевірити коректність функції недостатньо викликати її один раз з довільними параметрами, потрібно розглянути граничні значення, перевірити роботу з некоректними аргументами і т.п. Є такі техніки EP+BVA, які використовують тестувальники, але рідко застосовують девелопери.
➖Ну а тепер про TypeScript - дійсно це дуже гарна річ, але показує вона себе в крупних проектах, часто можна обійтись Vanilla JS. Якщо говорити про сторонні бібліотеки, то в TS є можливість підгружати файли з анотаціями типів, які створені для великої кількості сторонніх бібліотек, я якщо таких анотацій немає - то можна попрописувати самому, просто не факт, що то більш корисні витрати часу, ніж на юніт-тести 😜
➖Люди, які приходять зі строго типізованих мов, відразу починають шукати типізацію в JavaScript, але насправді то зовсім не факт, що воно треба. Справа в тому, що всіх базових типів даних в JS всього сім, з них лише три безпосередньо зберігають дані - Number, String та Boolean. Працюючи з числами, розробнику не потрібно заморочюватися розрядністю, задумуватися про знак, чи вирішувати питання ціле/дійсне - ти просто працюєш з числами
➖Навіщо взагалі потрібна строга типізація - ну наприклад для того, щоб випадково не викликати помилку виконання і не втратити інформацію, записавши дані в змінну, яка вказує на комірку пам'яті, яка їх не може вмістити. Але ж JS динамічна мова, такого бути не може в принципі - змінна буде завжди мати саме той тип, який ми в неї записуємо. Тут інше питання може бути - це коли з-за нашого незнання чи неуважності спрацював механізм автоконвертації типів і замість доданих двох чисел ми отримуємо сконкатеновані рядки символів, бо одне з чисел насправді було не числом, а рядком. В такому випадку статична типізація допомогла б, але є інший варіант - це розібратися з роботою конвертації і програмувати в функціональному стилі, уникаючи змінних взагалі.
➖Створюючи не змінні, а константи, ми завжди маємо розуміти, якого типу вони будуть, а надалі відповідно розуміти їх поведінку в виразах. Це зовсім не так складно, як здається на початку, питання звички. Треба уникати неявної конверсії типів, якщо вже робити, то явно, при перевірці на рівність використовувати оператор '===', а не '=='.
➖Ну і нарешті, а чи дійсно статична типізація є саме тою вундервафлею, що допомагає нам уникати помилок, можливо є щось краще? Дійсно, статична типізація допомагає в певних випадках, але далеко не гарантує коректність коду, є значно кращий механізм, на використання якого варто потратити зусилля - це юніт-тести.
➖Саме юніт-тести, за умови, якщо вони добре складені, і є тим механізмом, що захищає код від помилок. І шукати в статичній типізації те, чого вона не може дати в принципі, зовсім не варто. Можна легко створювати якісний код без статичної типізації, перевіряючи його юніт-тестами. Варто лише навчитися їх писати, бо то ціла наука, і у багатьох випадках пишуть їх не дуже відповідально, щоб перевірити коректність функції недостатньо викликати її один раз з довільними параметрами, потрібно розглянути граничні значення, перевірити роботу з некоректними аргументами і т.п. Є такі техніки EP+BVA, які використовують тестувальники, але рідко застосовують девелопери.
➖Ну а тепер про TypeScript - дійсно це дуже гарна річ, але показує вона себе в крупних проектах, часто можна обійтись Vanilla JS. Якщо говорити про сторонні бібліотеки, то в TS є можливість підгружати файли з анотаціями типів, які створені для великої кількості сторонніх бібліотек, я якщо таких анотацій немає - то можна попрописувати самому, просто не факт, що то більш корисні витрати часу, ніж на юніт-тести 😜
Продовжуємо коментарі. У відповідь на таке:
👉Є така справа - приходять люди з "класичних" мов і лаються на JS, ніби все нелогічне і зроблене через одне місце. Але зараз багато людей, які починали з нуля на JS і те саме говорять про інші мови. Я взагалі з першої категорії, але відчуваю, що останнім часом більше згоден з тими, хто з другої. 🙈 В JS насправді немає зайвих ускладнень, і після того, як ти розібрався з певними речами, ти починаєш розуміти її гнучкість і простоту.
😱Мало того, деякі речі, які тобі здавалися нерушимими шаблонами, JS розриває. Наприклад, всі звикли до ООП з класами, але відомо, що ООП створене так, що за взірець взятий реальний світ. Однак у реальному світі класів немає, лише об'єкти. Так модель ООП в JS без класів насправді і є більш коректною моделлю, ніж те, до чого ми звикли :)
😜Якщо любиш C#, то TypeScript - саме те що треба, особливо якщо взяти до уваги, що робить їх одна й та ж сама людина
треба з JS тривалий час попрацювати, щоб склалось чітке враження. Поки що пишу перший проект на JS і плююсь та матюкаюсь. До цього я вже років 20 як програмую на різних мовах (Assembler, C++, Delphi, C#, Java). Найбільше я полюбив C#, це дійсно насолода
👉Є така справа - приходять люди з "класичних" мов і лаються на JS, ніби все нелогічне і зроблене через одне місце. Але зараз багато людей, які починали з нуля на JS і те саме говорять про інші мови. Я взагалі з першої категорії, але відчуваю, що останнім часом більше згоден з тими, хто з другої. 🙈 В JS насправді немає зайвих ускладнень, і після того, як ти розібрався з певними речами, ти починаєш розуміти її гнучкість і простоту.
😱Мало того, деякі речі, які тобі здавалися нерушимими шаблонами, JS розриває. Наприклад, всі звикли до ООП з класами, але відомо, що ООП створене так, що за взірець взятий реальний світ. Однак у реальному світі класів немає, лише об'єкти. Так модель ООП в JS без класів насправді і є більш коректною моделлю, ніж те, до чого ми звикли :)
😜Якщо любиш C#, то TypeScript - саме те що треба, особливо якщо взяти до уваги, що робить їх одна й та ж сама людина
Ну що ж, літо скінчилося, пора до роботи. В День Знань варто знання перевірити. Ось вам веселий тест по JS-фреймворкам
➖Одна з найпопулярніших книжок по JavaScript - це JavaScript: The Good Parts від Дугласа Крокфорда, який ще відомий тим, що придумав формат JSON. Сама книжка вийшла в 2008 році і трішки застаріла, однак основні концепнції мови не змінилися з того часу, тому вона навіть через 10 років варта уваги.
➖Проте сьогодні мова не про саму книжку - на гітхабі є цікавий репозиторій, де основні ідеї книжки викладені у стиснутому вигляді з лінками і прикладами коду. Однозначно - в закладки, вивчати і повторювати 🤓
➖Лінк на саму книжку: JavaScript: The Good Parts на сайті видавництва, а тут можна знайти форматі PDF на гітхабі
➖Проте сьогодні мова не про саму книжку - на гітхабі є цікавий репозиторій, де основні ідеї книжки викладені у стиснутому вигляді з лінками і прикладами коду. Однозначно - в закладки, вивчати і повторювати 🤓
➖Лінк на саму книжку: JavaScript: The Good Parts на сайті видавництва, а тут можна знайти форматі PDF на гітхабі
GitHub
GitHub - dwyl/Javascript-the-Good-Parts-notes: :book: Notes on the seminal "JavaScript the Good Parts: by Douglas Crockford
:book: Notes on the seminal "JavaScript the Good Parts: by Douglas Crockford - dwyl/Javascript-the-Good-Parts-notes
VS Code отримав нову суперську функціональність - можливість робити рев'ю pull request на гітхабі прямо з IDE. Дуже люблю цю ідеєшку, правильно розвивається ❤️👍
Visualstudio
GitHub Pull Requests in Visual Studio Code
Introducing GitHub Pull Requests for Visual Studio Code
Сьогодні 256-й день року! Вітаю всіх причетних зі святом! 🎂🍺 На його честь на dou.ua свіжі баяни завезли
DOU
Обзор CSS Flexbox layout — технологии для расположения блоков на HTML-странице
В статье проведем краткое знакомство с технологией Flexbox. Решив ее использовать, приготовьтесь поменять свои привычные представления о выстраивании элементов в потоке. И дайте себе немного времени на адаптацию к новому подходу.
📱Сучасний респонсів - це значно більше, ніж media queries в CSS-коді. JavaScript теж може дечим похвалитися. 😜 Цікава стаття про респонсів JavaScript, читати краще зі смартфона, відразу перевіряючи приклади - визначення статусу онлайн/офлайн, керування вібромоторчиком, видимість вкладки та інше. 👏
Улюблений VS Code отримав цікаву можливість транслювати ланцюжки промізів у виклик async/await 👍
DEV Community
Visual Studio Code can now convert your long chains of Promise.then()'s into async/await automagically
VSCode is continuing to evolve in pretty fascinating ways. I'm curious about whether I'd...
Всі знають динозаврика 🦖 з Хрому. Виявляється йому нещодавно виповнилося 4 роки. На офіційному блозі браузера опублікували історію його виникнення. Якщо інтернет у вас є, а в динозаврика бажаєте погратися, то є спеціальний режим, достатньо ввести в адресному рядку chrome://dino 🦕
Google
As the Chrome dino runs, we caught up with the Googlers who built it
"There's nothing fun about getting kicked offline—unless you have a friendly T-Rex to keep you company." Take a bite of this interview with the team behind Chrome's beloved offline Dino game.
Цікава стаття від фронтендера з Wix.com про мову програмування, яку він шукає. Згадується багато трендових мов та деякої екзотики, дуже корисно для розширення загального світогляду
Hackernoon
The Programming Language I’m Looking For | Hacker Noon
Для всіх, кто кодить в Angular - гарна стаття про найкращі практики
freeCodeCamp.org
Best practices for a clean and performant Angular application
by Vamsi Vempati Best practices for a clean and performant Angular application I have been working on a large scale Angular application at Trade Me [https://trademe.nz], New Zealand for a couple of years now. Over the past few years, our team has been refining…
State Machine, машина станів або кінцевий автомат - достатньо проста, але водночас надзвичайно потужна математична концепція, яка має багато практичних застосувань у програмуванні, у тому числі, і у веб-розробці.
Рекомендую детальну статтю зі Smashing Magazine з описом концепції та її застосуванні як на чистому JS, так і за допомогою бібліотек.
Також рекомендую туторіал на Медіумі з яскравим прикладом реалізації UI для сейфу
Рекомендую детальну статтю зі Smashing Magazine з описом концепції та її застосуванні як на чистому JS, так і за допомогою бібліотек.
Також рекомендую туторіал на Медіумі з яскравим прикладом реалізації UI для сейфу
Smashing Magazine
The Rise Of The State Machines — Smashing Magazine
The UI development became difficult in the last couple of years. That is because we pushed the state management to the browser. And managing state is what makes our job a challenge. If we do it properly, we will see how our application scales easily with…