Welcome! 👋️️️️️️
Do you remember how we played in IT-alphabet? Today we gonna do the same but in English.

👉 We start: Web → your letter is B

Have a nice #english_friday 💛

Привіт 👋

В програмуванні часто можна зустріти різні способи найменування ідентифікаторів. Для прикладу: camelCase, snake_case, PascalCase, kebab-case, SCREAMING_SNAKE_CASE тощо 🤓

👉 Розкажіть, які з них і в яких випадках ви використовуєте?

T3 Env 🤫

Мало не в кожному проєкті є змінні середовища. І дуже часто в JavaScript застосунках ми зчитуємо їх просто з process.env. Якщо немає більше жодних налаштувань, то все це тримається на чесному слові. Адже ніхто не перевіряє присутність цих змінних, не валідує їх та не перетворює у необхідний формат.

Тому, сьогодні ми хочемо поділитись з вами бібліотекою T3 Env, за допомогою якої ви можете валідувати свої змінні середовища та утворити їх тип. Бібліотека сконструйована для роботи з full-stack фреймворками, тому, за потреби, ви можете налаштувати одночасно client і server змінні.

👉 Відкрити сайт

#library

#todo поділитися корисним шорткатом, який ви використовуєте 😇

#how_to створити гарний та простий todo list ✅

Виконаний повністю без JavaScript!

👉 Відкрити посилання

Welcome! 👋️️️️️️
Let's practice our English! So...

👉 What is the last movie you watched and add some short review?

Have a nice #english_friday 💛

#todo написати функцію toggle на будь-якій мові програмування, яка на вхід приймає два параметри - масив значень будь-якого типу і одне значення того ж типу, та повертає:
- масив без цього значення, якщо воно було присутнє;
- масив з цим значенням, якщо воно відсутнє у початковому масиві.

Наприклад:
[1,2], 3 -> [1,2,3]
[1,2], 2 -> [1]

charm.sh 💅

Ми вже якось розповідали в нашому чаті про charm.sh, а сьогодні хочемо поділитися ним ще й тут!

В charm.sh ви можете знайти різні бібліотеки та застосунки з відкритим кодом. Сподобаються вони тим, хто любить працювати з терміналом.

Якщо ви хочете зробити власний термінальний застосунок, знайдете там багато класних бібліотек, з якими вийде зробити все дуже гарно (правда писати доведеться на Go 🤷‍♀).

Щодо вже готових застосунків, ви знайдете там теж цікаві речі. Наприклад, mods дозволить вам використовувати AI, через pop можете відправляти емейли тощо. І все це в командному рядку! Блогери можуть спробувати vhs, що дозволить вам робити запис своїх команд у GIF.

До речі, гіфка, яку ви бачите, теж зроблена за допомогою цього застосунку!

👉 Відкрити посилання

#library

Welcome! 👋️️️️️️
Let's practice our English! So...

👉 What development tools do you use daily and would suggest to others?

Have a nice #english_friday 💛

Tailwind-merge 👉👈

Сьогодні Tailwind чи не найпопулярніший спосіб стилізації веб-застосунків. І якщо ви використовували його з будь-яким компонентним фреймворком, то, швидше за все, відчували наступну проблему.

Уявімо, що у вас є свій компонент Button і за замовчуванням його фоновий колір - блакитний. Але ви ж хороший програміст, ваш компонент може бути перевикористаний з різними опціями. Тож в одному місці ви хочете отримати зелену кнопку, тому передаєте відповідний tailwind-клас.

Тепер у вас є два конфліктні класи і в результаті ви все одно бачите блакитну кнопку.

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

👉 Відкрити посилання

Також рекомендуємо переглянути коротке відео, у якому розробник показує цю проблему та розробляє утиліту для її вирішення на основі бібліотеки tailwind-merge.

👉 Дивитися відео

#library

Git 🤓

У 99% проектів в IT використовується система контролю версій і в 93.87% (станом на 2022 рік) це саме git. Тож знання цієї системи є не менш важливим, ніж знання мов програмування та технологій, з якими ви будете працювати.

Відразу скажемо, що тут важливо розуміти сам принцип роботи, а не зазубрювати команд git. Насправді, зазвичай ви будете використовувати приблизно 7 основних команд, і набагато рідше всі інші.

Вже вкотре рекомендуємо вам LearnGitBranching. Тут ви зможете дуже швидко і інтерактивно вивчити команди git, а на додачу, ще й візуалізувати дерево комітів.

Також можете звернути увагу на The Odin Project. У їхньому курсі є 3 окремі статті про git, де ви зможете почитати все від особистих налаштувань до перших команд.

А якщо ви ще хочете попрацювати з GitHub, створити свій перший Pull Request, змерджити його тощо, то спробуйте GitHub Minesweeper.

Також, будемо раді, якщо ви поділитесь своїми способами вивчення git у коментарях.

#interview

#todo написати функцію, яка знаходить найдовший спільний префікс серед масиву стрічок. Якщо спільного префікса не існує, функція повертає порожню стрічку.

Наприклад:
["web", "webhook", "website"] -> "web"
["frontend", "backend", "fullstack"] -> ""

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

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

Фіксована ставка.

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

АЛЕ, якщо ви працюєте за такою формою оплати, обов’язково потрібно обговорити те, як оплачується понаднормовий робочий час, і чи він взагалі можливий. Якщо цей час додатково не оплачується, то в мене є питання до компанії.

Погодинна оплата.

При такій формі працівник отримує фіксовану оплату за кожну годину роботи. Чудово підійде для part-time роботи. У свій вільний від основної роботи час, програміст виконує таски, записує витрачені години та отримує зарплату за формулою кількість годин * рейт.

Не рекомендуємо таку форму оплати, якщо це ваша основна робота. Ми мали такий досвід, коли працювали з трекером. Все, що можемо сказати - ніякої стабільності, багато нервів та різний розмір зарплати кожного місяця.

Оплата за виконаний проект.

Дуже вигідно замовнику, але не програмісту. Це тому, що незалежно від того, наскільки б детально ви не прораховували обсяг роботи та бюджет, завжди з'являються правки та підводні камені, про які ви не підозрювали, і в більшості випадків доведеться працювати за свій кошт.

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

Сподіваємось, пост був корисним, хоча й дуже суб'єктивним! Чекаємо історії про ваш досвід і рекомендації про найкращу форму оплати 💛

#experience