Get Mystery Box with random crypto!

Radio Kottans

Логотип телеграм -каналу radio_kottans — Radio Kottans R
Логотип телеграм -каналу radio_kottans — Radio Kottans
Адреса каналу: @radio_kottans
Категорії: Технології
Мова: Українська
Передплатники: 2.05K
Опис з каналу

Share the knowledge (c)
Канал корисних посилань та новин зі світу програмування від спільноти розробників "Котани".
https://kottans.org/
Бажаєш підтримати? https://www.patreon.com/kottans

Ratings & Reviews

1.67

3 reviews

Reviews can be left only by registered users. All reviews are moderated by admins.

5 stars

0

4 stars

0

3 stars

0

2 stars

2

1 stars

1


Останні повідомлення 14

2021-02-04 13:00:05
Безкоштовний онлайн-інтенсив Binary Studio Academy з JS | .Net | Java цього літа
Найкращі студенти мають шанс на місце у компанії

Що на тебе чекає?
У червні та липні навчання сучасними фреймворками та інструментами, необхідна теоретична база та закріплення знань домашніми завданнями

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

У жовтні кращі студенти отримають шанс приєднатися до Binary Studio

Що чекають від тебе?
базові знання з програмування

Що треба зробити?
зареєструватися
скласти вступний тест
виконати завдання на базі запропонованих матеріалів
пройти співбесіду

Автори курсу обіцяють допомогти прокачатись до рівня впевненого junior-розробника та провести найбільш насичене знаннями літо 2021

Реєструйся на сайті Binary Studio Academy та отримуй доступ до матеріалів

До реєстрації: https://bit.ly/3cyVkhG
1.1K viewsAnastasiya Mashoshyna, 10:00
Відкрити / Коментувати
2021-02-01 13:00:06 Закон Гофстедера та деякі інші (не дуже серйозні) закони

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

Авжеж почнемо з Закону Атвуда:
Будь-який застосунок, що може бути написаний на JavaScript, рано чи пізно буде написаний на JavaScript. (а про node_modules у відкритому космосі ми вже писали).

Правило Карлтона:
В комп’ютерних науках є лише дві складні речі: інвалідація кеша та вибір імен змінних.


Про ставлення до технологій у спільноті:

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


Закона Пута (Putt Law)
Світ технологій опанований двома типами людей: тими, хто розуміє, чим не може керувати, та тими, хто керує тим, що не розуміє.

Планування та дотримання строків - така болюча тема, що на цю тему є чимало законів (і ми відчуваємо біль їх авторів)

Закон Брука
Якщо проєкт вже запізнюється, то додання людей до команди запізнить його ще сильніше.

Закон Мерфі
Все, що може піти не так, обов’язково піде не так. (о, так)

Правило дев'яносто на дев'яносто
Перші 90 процентів коду будуть написані за перші 90 процентів часу розробників. Решта 10 процентів коду потребуватимуть ще 90 процентів часу розробки.
Том Каргілл (Tom Cargill)

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

І деякі інші закони:

Десяте правило програмування Грінспана (Greenspun Law)
Будь-яка досить складна програма на C чи Fortran містить не придатну до повторного використання неформально специфіковану, повну помилок, повільну реалізацію половини Common List.
(У цьому законі ми геть нічого не розуміємо, але він викликає повагу)

Правило двох піц
Якщо ви не можете нагодувати команду двома піцами, то команда завелика
(Джеф Безос)

Закон Канінгема
Найкращий спосіб отримати правильну відповідь в інтернеті - не поставити питання, а запостити невірну.
До речі, Ворд Канінгем (Ward Cunningham) склав першу wiki
1.2K viewsAnastasiya Mashoshyna, edited  10:00
Відкрити / Коментувати
2021-01-31 13:00:04
Що ви хочете дізнатись від техлідів  до того, як прийти на співбесіду?

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

Дійсно,  "цікаві вакансії в дружньому колективі" вже нікому не потрібні.

Skyworker проводитиме інтерв’ю з техлідами ІТ-компаній та збиратиме відповіді на важливі для вас питання.

Запрошуємо обрати цікаві питання за цим посиланням - https://forms.gle/WQkCyQxk4qovS7uw9 

Вже у лютому ви зможете почути відповіді техлідів в епізодах подкасту Ok. Let's talk та мати більше інформації перед тим, як приймати запрошення на співбесіду.
992 viewsAnastasiya Mashoshyna, 10:00
Відкрити / Коментувати
2021-01-29 14:48:31
New Firefox Update
https://redd.it/kwe7mz
by @get_happiness via @r2tBot
1.0K viewsIvan Tytarenko, 11:48
Відкрити / Коментувати
2021-01-29 14:48:31 Firefox Nightly Build
941 viewsIvan Tytarenko, 11:48
Відкрити / Коментувати
2021-01-26 13:00:04 What exactly does it mean to be a "senior" software engineer?

В нещодавньому епізоді подкасту StackOverflow обговорювали тему сінійорства. Що це означає – бути Senior Software Engineer? Які якості потрібні такому фахівцю? Ось отримав ти посаду, а що робити далі, щоб мати успіх на цій посаді?

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

Пропонуємо перш ніж читати далі, сформулювати для себе, що таке leadership у сфері Software Engineering.



Готові?

Отже, на думку учасників бесіди, leadrship – це певне ставлення (attitude), яке має демонструвати людина. Ось приклади проявів такого ставлення:
- менторство
- ведення мітингів
- участь у прийнятті рішень щодо продукту та архітектури технічних рішень (design & product decisions)
- ведення проєктів
- видимість у компанії

Разом усе це можна описати як вплив, проте це вплив іншого роду, ніж здатність настояти на своєму. Не такий прямий, проте досить важливий вплив на кінцевий продукт.

Звісно, очікування від Senior Engineer залежать від компанії. Хтось скаже, що описані якості потрібні тім-ліду, а не рядовому Senior інженеру. Проте ситуації, коли Senior просто пише свій геніальний код і ні з ким не розмовляє, стають дедалі рідшими.

Посилання на подкаст: https://stackoverflow.blog/2021/01/19/podcast-305-what-does-it-mean-to-be-a-senior-software-engineer/
1.3K viewsAnastasiya Mashoshyna, 10:00
Відкрити / Коментувати
2021-01-25 13:00:04 TypeScript: type X has no index signature

Продовжимо розмову про Advanced Types у TypeScript. Перш ніж переходити до наступних тем, поговоримо про index signature та помилку type '{}' has no index signature.

Коли ми у TS хочемо описати ключі та значення об’єкту, у нас є дві можливості залежно від того, чи ми точно знаємо, які ключі міститиме об’єкт, чи ні (ключі динамічні чи невідомі нам з інших причин). В першому випадку ми, очевидно, описуємо очікувані властивості. А у другому випадку нам на допомогу прийде index signature – опис типів ключів та відповідних значень без вказання конкретних ключів. Є інші можливості (зокрема Mapped Types, про які ми ще поговоримо).

Почнемо знайомство з index signature з назви. До чого тут індекси? Слово index означає “вказівник”, проте в термінах TS index (into an object) значить "отримувати доступ до властивостей об'єкта за ключем". Нам добре знайомі колекції з числовими індексами (масиви), проте індексом може бути й рядок. Принаймні, так вважає TypeScript

const user = {
name: ‘John’,
age: 20
}

user["name"] // John
user.name // John

Тож, indexing - це доступ за індексом (рядковим, числовим), а index signature - це сигнатура (опис типів) ключів та значень об’єкта, яка буде використана при такому доступі.

Index signature виглядає так:

{ [x: string]: number }

У нашому прикладі x вказує на ключ, string - тип ключа, а number - тип значення.
Тобто, цей тип говорить, що в об’єкті даного типу будь-якому рядковому ключеві відповідає числове значення.

Також ми можемо комбінувати ці два підходи і попросити TypeScript перевірити, що в об’єкті є певні фіксовані властивості. Обмеженням є те, що тип значень в усіх властивостей має бути один.
type StringToBoolean = {
[key: string]: boolean;
isChecked: boolean
} // valid type

Помилка, якщо тип властивості з фіксованим іменем не збігається з типом index signature:

type StringToBooleanOrNumber = {
[key: string]: boolean;
checksCount: number
} // Error: Property 'checksCount' of type 'number' is not assignable to string index type 'boolean'

Через те, що в JS ключі об’єктів і так рядки (окрім символів), то фактично ми описуємо значення. Цей запис не робить припущень щодо наявності чи кількості властивостей в об’єкті: їх може бути багато чи навіть жодної. З index signature слід бути обережними, адже index signature обмежує типи ключів та значень, проте не гарантує, що певний ключ буде у об’єкті. Якщо такий ключ є, то значення за цим ключем буде вказаного типу

В яких випадках нам може знадобитися такий тип?
- Для об’єктів, точні ключі яких невідомі (наприклад, вони динамічні), але ми не хочемо типізувати їх як any.
- Другий приклад менш очевидний: якщо ви перебиратимете типізований об’єкт через Object.keys, ви можете здивуватися, адже TypeScript скаже, що тип ключа - рядок, а не поєднання усіх відомих ключів. Як виходить, що TypeScript не може розібрати ключі? Це рішення прийняте свідомо, про його мотивацію можна почитати тут
https://github.com/microsoft/TypeScript/pull/12253#issuecomment-263132208
Тож якщо ви вирішите перебирати ключі з Object.keys, TypeScript змусить вас надати index signature.

То що означає помилка type X has no index signature?
Компілятор каже “Це об’єкт, для якого ти не вказав усі ключі, тому може такий ключ в ньому і є, але я не знаю, якого типу його значення. Скажи мені".

Наступного разу поговоримо про спосіб отримати тип усіх ключів у об’єкті - оператор keyof.
1.1K viewsAnastasiya Mashoshyna, edited  10:00
Відкрити / Коментувати
2021-01-22 18:00:03 Компанія Kasta шукає Backend-розробника у команду!

Локація: Київ, Бориспільська (в теперішніх реаліях - віддалено)

Технічний стек: Clojure + ClojureScript, PostgreSQL, ElasticSearch, Kafka.

Необхідні навички:
Більше 2-х років досвіду розробки з використанням динамічних мов програмування (Clojure, Python, Groovy);
Досвід роботи з високонавантаженими системами та асинхронними фреймворками;
Досвід використання Kafka і ElasticSearch;
Глибокі знання реляційних баз даних і досвід роботи з PostgreSQL;
Досвід написання юніт-тестів та e2e тестів;
Добре розуміння підходів роботи за Gitlab flow або GitHub flow;
Навички опису архітектурних рішень.

Що потрібно буде робити:
Розробка нового функціоналу;
Обговорення реалізації нового функціоналу з продакт-менеджером та тім лідом;
Розвиток поточної архітектури;
Виправлення дефектів знайдених в production оточенні;
Допомога в налаштуванні системи моніторингу сервісів;
Рев'ю коду.

Більш детально: https://jobs.dou.ua/companies/modnakastaua/vacancies/145966/
Контакти: @anndovbysh
992 viewsAnastasiya Mashoshyna, 15:00
Відкрити / Коментувати
2021-01-20 14:22:04 Дуже крута доповідь Тіма Зуханека(Tim Suchanek) Generics, Conditional types and Mapped types надихнула нас поговорити про Advanced Types у TypeScript. Обов’язково послухайте Тіма, проте хочемо дещо додати від себе. В один допис усе не влізло, тому “далі буде..."

TypeScript Advanced Types ʕ •ᴥ•ʔ

Про що йдеться? Перший рівень роботи з TypeScript – досить інтуїтивний – це брати наявні типи та комбінувати їх для опису об’єктів доменної області. Беремо string, number, Array, отримуємо щось таке:
type User = {
name: string,
age: number,
hobbies: string[]
}
function registerUser(user: User): number { /* return registration number */ }

This is fine, але згодом типів, як і будь-якого іншого коду, стає забагато і ми згадаємо про DRY та SOLID. Було б класно використати типи повторно та зробити їх гнучкими. Іншими словами, ми хочемо працювати з типами як зі значеннями, бо звикли до цього у програмуванні.

У доповіді, яка стала приводом для цього допису, наведений такий приклад. Тім Зуханек працює над ORM Prisma. Його команда зіткнулася з проблемою безпечної типізації запитів до БД. Справа у тому, що користувач може скласти запит (query) таким чином, що потребуватиме лише певні поля з моделі. Для типізації результату такого запиту необхідно обраховувати типи динамічно в залежності від змісту запиту.

Отже, ми хочемо визначати власні типи на базі існуючих, і робити це динамічно. Що пропонує нам з цього приводу TypeScript? Запрошуємо у чарівний світ операцій над типами.

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

Generics

Звернімося до Вікіпедії:
Узагальнене програмування (generic programming) - стиль програмування, що описує алгоритми, не вказуючи конкретні типи значень, що приймають участь в обчисленнях. Ці типи будуть визначені пізніше, залежно від типів, наданих як параметри.

Що нам нагадують типи, що невідомі заздалегідь та будуть призначені при виконанні? Параметри функції.
Generics це параметризований типи. До дженериків відносяться зокрема масиви (ми можемо описати типи елементів масиву), проміси (яке саме значення містить проміс?) і багато інших вбудований типів, але і свої дженерики ми теж можемо писати. Дженерики у TS мають власний синтаксис – кутові дужки після типу, у яких ми вказуємо типи-параметри. Скажімо, у нас є тип, що описує об’єкт із властивістю value змінного типу. Тип T у визначенні дженерика вказує на параметр дженерика (той самий тип, не відомий заздалегідь)

type MyParametrizedType = { value: T}

На базі такого типу ми можем створити похідний тип, де обє’кт має властивість value вже конкретного типу:

type MyStringValueType = MyParametrizedType
const stringValueObject: MyStringValueType = {value: "hello"}

type MyNumberValueType = MyParametrizedType
const numberValueObject: MyNumberValueType = {value: 42}

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

const brokenObject1: MyStringValueType = {value: 42} // error
const brokenObject2: MyNumberValueType = {value: "hello"} // error

Так, очікувані помилки з’явилися! Можемо рухатися далі.

Далі буде...
1.1K viewsAnastasiya Mashoshyna, edited  11:22
Відкрити / Коментувати
2021-01-15 12:00:04 Код-рев'ю: як закохати у себе будь-якого рев'юера

Майкл Лінч(Michael Lynch) помітив, що статті про код-рев'ю зазвичай дають поради рев'юерам. Значно рідше можна знайти матеріали про те, як підготувати власний код до рев'ю.

У статті How to Make Your Code Reviewer Fall in Love with You Майкл зібрав рекомендації щодо того, як допомогти рев'юеру переглянути код з найбільшою ефективністю. Так ви зможете самі швидше вчитися (адже навчання - перше завдання код-рев'ю), допоможете вчитися іншим та зведете конфлікти у команді до мінімуму.

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

Майкл пропонує 13 кроків для цього. Дещо з цього списку – речі, які ми просто часто забуваємо, інше - тонші психологічні моменти.

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

1. Ретельно прогляньте код самостійно (так, усі іноді забувають)
2. Ясно опишіть, що саме було змінено
3. Автоматизуйте прості задачі
4. Відповідайте на питання за допомогою коду (це про приклади, а не про спілкування функціями)
5. Робіть зміни локалізованими
6. Розділіть функціональні та нефункціональні зміни на окремі пул-реквести
7. Діліть великі за обсягом зміни на кілька пул-реквести
8. Відповідайте на критику чемно
9. Зберігайте терпіння, якщо рев'юер припустився помилки
10. Викладайте свою позицію явно
11. Допомагайте знайти інформацію, якої не вистачає
12. Йдіть на поступки у питаннях, що стосуються смаку
13. Мінімізуйте час між ітераціями рев'ю
1.4K viewsAnastasiya Mashoshyna, edited  09:00
Відкрити / Коментувати