#todo описати останній таск, який став для вас справжнім челенджем 🤯

Setup frontend project

Як човен назвеш - так він і попливе. А в нашому випадку - як засетапиш проект 😉

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

- обрати фреймворк/бібліотеку. Якщо ви працюєте на компанію, думаю, цей вибір зроблять без вас і просто поставлять перед фактом на чому має бути написаний поект. Якщо це ваша відповідальність - оцініть з чим ви вмієте добре працювати (адже ваша ефективність - це важливо), і найголовніше, що підходить даному проекту.
- обрати мову. Вибір між JS або TS (якщо такий вибір є). Ну тут зрозуміло, що я рекомендую (TYPESCRIPT).
- безпосереднє налаштування. Маю на увазі вибір чим зібрати проект (webpack, vite, rollup тощо), або, якщо це реалізовано під капотом, то трішки покопатись в налаштуваннях також не завадить.
- налаштування стилів. Сюди входить вибір бібліотеки/препроцесору і його налаштування. Якщо будете писати на чистому css, не спішіть пропускати даний крок - ресетнути стилі, додати всі необхідні фонти також потрібно.
- eslint/prettier/stylelint. Якщо хочете мати безлад в коді, прошу дуже, можете пропустити цей крок.
- git hooks. Маєте пост на дану тему - відкрити посилання.
- git actions. Автоматичний деплой, перевірка пулл реквестів, запуск тестів на GitHub само не з’явиться, це також бажано налаштувати.
- state manager. Будете використовувати зовнішню бібліотеку чи обійдетесь вбудованим функціоналом важливо вирішити напочатку і налаштувати все для зберігання даних.
- тести. Якщо є потреба покривати проект тестами (а вона точно є), підготуйте все для цього.
- структура. Створіть всі необхідні для початку папки, щоб бачити, що і де у вас буде знаходитись.
- деплой. Не завжди дану задачу покладають на тендітні плечі фронтенд розробника, але якщо це ваша відповідальність - це також потрібно налаштувати відразу.

*оновіть favicon та title відповідно до проекту. Не знаю куди це віднести. Просто не забудьте.

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

На цьому все. Успіхів вам! 💛

#experience

❗️До кінця розіграшу залишилось 12 днів - доєднатись

Хей 👋

На минулому тижні разом з вами ми придумали спільну традицію - кожну п'ятницю спілкуватись в чаті лише англійською! Так як це ми проводимо вперше, давайте дізнаємось більше один про одного. Тому ...

👉 Name three facts about yourself - two of them must be true and one must be a lie. Guess the lying fact from other guys.

Good luck and have a good Friday! 💛

#english_friday

❗️До кінця розіграшу залишилось 11 днів - доєднатись

12-factor application

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

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

Давайте глянемо на декілька з них:

- оголошення та ізоляція залежностей - всі залежності вашого застосунку мають бути описані (package.json, Pipfile) для того, щоб можна було з легкістю зрозуміти, що потрібно встановити, та мають бути ізольованими (node_modules/, virtualenv).
- конфігурація - налаштування, що можуть змінюватись для різних середовищ, мають перебувати саме в змінних оточення. Щоб було простіше, згадайте .env файли, process.env або os.getenv.
- dev/prod паритет - застосунок проектується для Continuous Deployment, отже потрібно мінімізувати різницю між dev та prod середовищами. Завдяки цьому, ви зможете побачити однакову поведінку при розробці та в релізі, тому зможете релізитись хоч щогодини.

Як не дивно, там є ще 9 правил (бо всього 12), тому переходьте за посиланням і дивіться повний опис.

Читати документацію

Звісно, буває нелегко дотримуватись багатьох правил. Дану методологію, наприклад, часто критикують через її заточеність під Heroku (саме розробники платформи Heroku описали правила 12-factor додатку).

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

#article

❗️До кінця розіграшу залишилось 11 днів - доєднатись

9-10 листопада у Сан-Франциско GitHub проводитиме GitHub Universe для розробників. Хороша новина - можна доєднатись і онлайн, потрібно просто зареєструватись і взяти безкоштовний квиток. Все триватиме 2 дні! Буде багато розповідей, серед яких - хмарні технології, безпека, штучний інтелект та комʼюніті. Якщо цікавитесь - залишаємо посилання внизу.

Отримати свій квиточок

❗️До кінця розіграшу залишилось 8 днів - доєднатись

HTTP Methods and Codes

На співбесіді без питань про HTTP не обійтись, тому ловіть коротенький гайд.

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

Нагадаємо, що HTTP (скор. англ. HyperText Transfer Protocol — «протокол передачі гіпертексту») - це протокол передачі даних, що використовується в комп'ютерних мережах.

Розглянемо кілька найпопулярніших методів та коли їх використовують:

- GET - діставання даних. В цьому випадку мається на увазі, що дані ніхто змінювати не буде, вони лише повернуться у відповідь.
- POST - закидування даних. З цим методом ви швидше за все захочете відправити якийсь body з певними даними. Зазвичай цей метод використовують для створення саме нового обʼєкту даних, наприклад реєстрація.
- PUT - повне оновлення даних. Тут ви теж будете відправляти body, але вже з метою повністю оновити обʼєкт даних.
- PATCH - часткове оновлення даних. Знову кидаємо body, але воно може містити лише частину обʼєкту.
- DELETE - тут думаю по назві все можна зрозуміти 😉

Коли сервер отримає ваш запит, він підготує для вас відповідь і статус цієї відповіді. Розглянемо найпопулярніші з них:

- 200 - все спрацювало ок
- 404 -
- 201 - щось нове було створено
- 500 - здається сервер зламався
- 401 - ви не авторизовані
- 403 - доступ заборонено

#interview

❗️До кінця розіграшу залишилось 7 днів - доєднатись

У Юри сьогодні День Народження! 🥳

Він би не хотів, щоб я це постила, але його ніхто не питає.

Давайте скинемось по привітанню людині, яка постійно старається знайти дійсно круту інфу, щоб вам було цікаво! А ще придумує ці дурацькі тести, на які всі сваряться, і я не виняток! 😄

#todo написати функцію на будь-якій мові програмування, яка приймає число і повертає true, якщо число є паліндромом (читається однаково в обох напрямках), і false в іншому випадку. Наприклад, 121 є паліндромом.

❗️До кінця розіграшу залишилось 6 днів - доєднатись

Setup backend project

Спочатку налаштуй себе на роботу 😉

Нещодавно Настя розповідала про те, як вона сетапить frontend проекти. Сьогодні я хочу відмітити чи повторити найважливіше з її посту та розповісти про речі, що я додаю при налаштуванні бекенд проекту.

Я пропущу такі кроки як вибір мови та фреймворку, тут кожен обирає своє.

- Налаштуйте лінтери та форматтери - це справді допоможе зберігати один вигляд коду.
- Додайте git hook та github actions (або pipelines від bitbucket чи gitlab). Нехай перевірка форматування файлів запускається перед комітом, тести перед пушем. І навіть якщо хтось обійде цей захист, на GitHub все одно буде ще одна перевірка.
- Пограйтесь з Docker. Можете обгорнути свій застосунок в docker. Зараз майже будь-яка платформа може працювати з контейнерами. Якщо не сильно хочеться, все ж я раджу хоча б використовувати вже готові docker image з сервісами, які ви використовуєте (наприклад, базою даних). Припустимо, що ваш застосунок використовує postgres та redis, треба встановлювати їх собі на компʼютер і постійно запускати. Якщо ж напишете всього один файлик docker-compose - зможете однією командою це все запускати і використовувати.
- Налаштуйте змінні середовища. Зберігайте секретні дані у файлику .env (або .env.{середовище}). Швидше за все бібліотека/фреймворк автоматично будуть зчитувати його, але якщо ні, впевнений, що з легкістю зможете знайти рішення.
- Якщо працюєте з базою даних - налаштуйте зʼєднання з нею і додайте ORM (читати пост). Навряд чи вам захочеться писати прямі SQL-запити, тому додати Prisma, Sequalize для JS чи SQLAlchemy для Python буде хорошою ідеєю.

Старався коротко і по суті описати основні кроки. Тому, якщо вас цікавить щось детальніше - давайте обговорювати ⬇️

#experience

❗️До кінця розіграшу залишилось 5 днів - доєднатись

Hello 👋

Давайте сьогодні попрактикуємо технічну англійську. Можете писати свої відповіді тут або в чаті. Тому ...

👉 Name your favorite language/technology and explain why you like it.

Have a wonderful Friday! 💛

#english_friday

❗️До кінця розіграшу залишилось 4 дні - доєднатись

🚀 Next.js 13

Нещодавно була оголошена версія Next.js 13, яка внесла величезні зміни у фреймворк. Команда Next.js співпрацювала безпосередньо з командою React, щоб створити найкращу веб-платформу.

Основні оновлення:

- Next.js 13 містить Turbopack, який до❗️700❗️разів швидший, ніж Webpack.
- Не потрібна папка pages, за допомогою якої працював маршрутизатор. Тепер можна оголосити файл page.js в будь-якій папці і він стане роутом. Крім цього, з'явились нові файли, такі як - error.js (дана сторінка буде з'являтись, коли виникла помилка), loading.js (коли сторінка завантажується), layout.js (обгортає всі сторінки в папці в прописаний в даному файлі врапер).
- Значно спростили getServerSideProps.

і ще багато іншого. Тому, хто цікавиться даним фреймворком, рекомендую переглянути!

Відкрити документацію
Дивитись огляд від Fireship

🥳 а ще у нас нова рубрика - #news , в якій ми пишемо про події в сфері ІТ, які не залишать вас байдужими

❗️До кінця розіграшу залишилось 4 дні - доєднатись

Зʼявилась крута ідея? Xочеться створити стартап або класну програму, але для назви спадає на думку тільки BestProgram або SuperStartup? От нам це насправді знайомо. Нещодавно знайшли такий сервіс як Namelix, який за ключовими словами спробує підібрати імʼя для вашої ідеї.

Зберігайте та користуйтесь - відкрити посилання 💛

#tips

❗️До кінця розіграшу залишився всього 1 день! Останній шанс доєднатись завтра до 18:00. Не впусти його! 😉

Три місяці курсів - і я вже в IT?!

👋 Хей-хей! Маємо для вас круту ІТ-подію.

IT-індустрія і досі продовжує обростати новими міфами! Саме час спростувати деякі з них під час нового вебінару від Intellias. Долучайся 10 листопада, на каналі @IntelliStart у Telegram та вигравай один із двох павер бенків - Xiaomi Mi Wireless! Початок - о 18:00.

👉 Долучайся за посиланням:
https://yangx.top/+CN_zeMDNkA02MTli

#news

Які етапи життєвого циклу класової компоненти замінює useEffect?

Що ви зараз бачите перед собою? Це - скарб. Тому що дане питання полюбляють запитувати як і в Junior розробників, так і Senior.

Давайте трішки пригадаємо.

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

А якою ж може бути функція, яку передали в useEffect?
- Та будь-якою! Тільки вона не повинна приймати ніяких параметрів та, за бажанням, може повертати функцію зачистки (так-так, функція повертає функцію). Цю зачистку React викликає перед повторним викликом useEffect або перед unmount компоненти.

Тож повернемось до наших баранів. Проста відповідь на основне питання - componentDidMount, componentDidUpdate та componentWillUnmount.

useEffect дійсно обовʼязково запускається після того, як замаунтив компоненту в DOM. Тому, якщо ви хочете симулювати роботу didMount - передайте в компоненту пустий масив залежностей (в ньому всередині точно нічого не буде змінюватись).

Якщо хочете отримати didUpdate - взагалі не передавайте нічого як залежності (пропустіть параметр). В такому випадку React запускатиме ваш ефект при будь-яких змінах у компоненті.

Ну і як же отримати willUnmount? Згадуємо про повернення функції зачистки. Якщо у нас не буде залежностей в масиві, ця зачистка запуститься саме один раз - перед unmount компоненти.

Читати документацію

#interview

❗️Кінець розіграшу о 18:00. Не впусти свій шанс!