🏚 Фонд Сергія Притули запускає проєкт NEST – встановлення модульних будинків замість зруйнованого житла на власних ділянках українців.

Мета проєкту — повернути додому українські сім’ї, допомогти відновити їх родинне гніздо (англійською — nest, звідки й назва проєкту) на рідній землі — звести мобільний тимчасовий будинок. Він зводиться одразу на земельній ділянці родини, для якої цей будинок призначений.

На перші три будинки для українських родин кошти назбирали американські школярі віком від 11 до 17 років.

"Це така міжнаціональна толока. Росіяни нищать, а ми всім світом відбудовуємо. Вони хочуть нас викорінити, а ми будемо повертатися додому у свої міста і села, бо це наша земля і наше коріння. Українці — нація, якій важливо мати своє родинне гніздо. У цьому зміст нашого проєкту NEST. Це не тимчасове поселення для переселенців десь далеко від дому. Родина житиме у новій домівці, але на своїй землі, у своїй громаді та відбудовуватиме життя громади. Бо ми непереможні, коли об’єднані." – коментує ініціативу Сергій Притула.

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

React Context vs Redux

Якщо в мене півроку назад спитали, що б я використовувала в своєму застосунку для роботи з даними - не задумуючись відповіла би Redux. Чому? А бо я не працювала без нього з часів своїх пет-проектів. Зараз в мене є два активних проекти і хочете прикол? Вони без Redux.

Давайте почнемо просто з означень.

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

Redux - це окрема, досить потужна бібліотека, яка дозволяє створити сховище (state, по-розумному), в якому зберігаються дані застосунку. Він сам по собі ніяк не пов'язаний з React, але разом вони надають дуже зручний інтерфейс для керування даними. Так, як саме сховище знаходиться поза React, всі компоненти можуть отримати доступ до нього. Хоча насправді, саме сховище додається на верхньому рівні в React дерево, використовуючи Context, і саме так надає доступ до даних.

Якщо у вашому застосунку вам потрібно лише передавати дані глибше і у вас немає надскладної логіки, яку потрібно моніторити, тоді використовуйте React Context. Він чудово підходить для обміну тривіальними фрагментами стану між компонентами. Плюс, він вбудований в React і вам не потрібно гратись з налаштуваннями.

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

Чула, що навіть розробники Redux говорять, що програмісти почали пхати його всюди, там де він зовсім не потрібний, і забувають, навіщо він взагалі був створений. Тому як говорив один мій замовник - no drama, please. Якщо у вас невеликий застосунок, де просто потрібно прокидати дані по дереву - використовуйте Context і не робіть моїх помилок.

І прикріпляю статтю, де можете почитати більше про дану тему - читати статтю

#experience

Поки це повідомлення летить до вас, десь за кулісами з ним відбувається різноманітна хімія.

Рано чи пізно, ваші застосунки будуть спілкуватися з іншими і ви зустрінете термін REST. Тому, ми хотіли поділитись своїм розумінням про це і, як результат, написали статтю про REST та речі повʼязані з ним.

Читати статтю

А ще, там в кінці є міні-завдання, тому можете ділитися результатами в коментарях

Що таке SEO?

Головне не переплутати і не сказати, що це головна людина в компанії.

SEO - це, дослівно, оптимізація пошукових двигунів, таких як Google (а хтось користується іншим пошуковим сервісом?). Всі ми постійно щось гуглимо і отримуємо різні сторінки з результатами. Але звідки взагалі Google знає про ці сторінки?

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

Тож грамотно налаштоване SEO - це навіть крутіше різних реклам. Тож як можна його покращити?

Найпростішою (і правильною) відповіддю є meta-теги, а особливо, keywords та description. Проте, як казали раніше, є дуже багато інших факторів. Для початку, вам треба буде перевірити, чи зображення мають alt-атрибут. Перегляньте, як у вас побудовані заголовки, чи правильна в них ієрархія (не дарма ж існує 6 видів). Важливо і те, як швидко ваша сторінка завантажується. В 2016 році Google сказали, що будуть в першу чергу перевіряти мобільну версію веб-сайтів.

А чи помічали ви, що деякі сторінки підвантажують зображення і короткий опис, коли ви ділитеся ними в соціальних мережах? Тоді зверніть увагу на Open Graph - особливі теги, створені Facebook, що дозволяють коротко описувати сторінку, якою діляться користувачі.

Про те, як грамотно налаштувати SEO, можна прочитати на офіційній статті від Google - читати статтю

#interview

🚀 Нові властивості CSS

Не так давно вийшло оновлення css, яке має нові фічі - container і :has(). Обидва вже підтримуються в Chrome 105 і в Safari 16 (якщо вірити CanIUse).

Container запити дозволяють стилізувати елементи в залежності від розміру батьківського елемента (те саме, що і media query, але в залежності від розміру батьківського елемента, а не екрану).

:has() - це псевдоклас, який відображає елемент у тому випадку, якщо будь-який із селекторів, переданий як параметр, відповідає хоча б одному елементу.

Читати більше

#article

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

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

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

#library

Різниця між Type та Interface в TypeScript?

Type - це спосіб створення власного імені для вами ж описаного типу (рекурсія якась 🔃). Це може бути комбінація примітивних типів або ж тип обʼєкту з певними властивостями. Є дві основні операції над типами:
- intersection (перетин) - оператор &, коли типи зливаються в один;
- union (обʼєднання) - оператор |, коли змінна може набувати будь-якого одного з заданих типів.

Interface теж дозволяє створювати власне імʼя, тільки його зазвичай використовують для обʼєктних типів. Єдиною операцією між інтерфейсами є extend (розширення). Унаслідок ви отримуєте всі ті ж властивості, що має базовий інтерфейс, та можете додати нові.

Виходить, що обидва способи досить схожі та мають майже однакові можливості. Так і є, в 95% використання ви можете обрати будь-який з підходів.

Що в них відмінного? Спробуйте створити два інтерфейси з однаковим іменем і подивіться на результат. Код буде без жодної помилки, а в кінці ви отримаєте просто обʼєднання двох оголошень. Тип можна оголошувати тільки один раз.

Особисто я зараз частіше віддаю перевагу саме Type. Поясню чому. По-перше, Type все ж таки має трішки більше можливостей (наприклад, присвоєння примітивів). По-друге, значення інтерфейсу в програмуванні це швидше про методи, а в TypeScript Interface може зберігати і властивості.

Коротко ознайомитись з типами та інтерфейсами в Typescript можна у самому довіднику.

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

#interview

Друзі, нагадуємо, що в нас є чатик, де можна обговорювати різні питання та новинки в сфері ІТ 💛

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

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

Ми з Юрою не виняток. Десь більше півроку тому ми також працювали на двох роботах (фулл тайм і парт тайм) + вели невеликий стартап. Тому з легкістю можемо поділитись плюсами і мінусами такого досвіду.

Погнали…

Плюси

Гроші. Ви дійсно будете заробляти багато. Багато працюєш = багато заробляєш. Просте правило, яке працює в усіх сферах.

Запасний аеродром. Якщо настає такий момент, коли ви вже не хочете/не можете працювати на одну з компаній і це прям вже горить (як було у нас з Юрою), ви можете з легкістю її покинути, тому що у вас є постійний заробіток незалежно від даної компанії. Зручно? Так.

Мінуси

Стрес, легко перегоріти. Коли ви взяли на себе декілька проектів, не чекайте, що буде легко. Звісно, можуть бути дні, коли все на лайт режимі, ви працюєте в своєму темпі і все добре. Але ніхто не відміняв закон підлості. Часто буде таке, що все буде падати, ламатись, критичні правки будуть прилітати одночасно на всіх проектах. І саме на цьому моменті ви розумієте, що краще піти на завод.

Відкладене життя. Ваша робота буде займати весь ваш день. Кожен день перед екраном. Постійно. У вас залишатиметься дуже мало часу на хобі та відпочинок, а то і зовсім не залишатиметься. І тоді ви доходите до того, що краще вже купити ту саму квартиру пізніше на рік, але провести цей рік в балансі з роботою та відпочинком. Я не думаю, що ви в сорок років будете згадувати як круто сиділи за компом цілими днями. Ви будете згадувати як відпочили в горах, спробували щось нове, або банально сходили з друзями на пиво.

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

А ви для себе вирішуйте самі 💛

#experience

Смакота!

Code Smells - виберіть найкращий переклад - код з запашком; код, що погано пахне; смердючий код.

Чому запах? Тому що на вигляд код виглядає нормально, але має ознаки, які вказують, що десь глибоко є певні проблеми. Вони і створюють цей запах. Code Smells може мати різні ознаки, але зазвичай схожий результат - складність ефективно розвивати систему, використовування можливостей ООП (або інших підходів) та складний для розуміння код.

Наявність таких запахів означає необхідність у рефакторингу (але про нього вже наступного разу).

Більше про Code Smells та їх приклади можна почитати у статті нижче.

Читати статтю

Хоча б гляньте підзаголовок у цій статті, він того вартий :)

#article