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

Було якось бажання отримати виш з CS аби мати більше переваг під час відгуків на вакансії. Подавався в AUK (American University Kyiv) — процесс вступу там не був дуже складний. Але в самому кінці сказали що треба мати військовий квиток. Тоді мій навчальний шлях і завершився бо не було його на той момент, та і пригадавши як це все було із першою освітою (купа медкомісій, походи в військомати і черги — як то всьо напрягало) трохи перехотів.

Зараз іноді передивляюся Coursera на предмет онлайн програм в Європі/США.
Автору дякую за статтю, що нагадала мені за цей пунктик!

Чи дозволяє застосунок обирати комбінацію клавіш для переключання ?
Я користуюся CTRL (лівий) + Space. Чи зможу зберегти цю комбінацію для переключання використовуючи ваш застосунок ?

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

Дякую за статтю ! Цікаве хоббі.
Завжди було цікаво як це працює і виглядає — процес проявлення плівкових фото в реальності. Проте ніколи руки не доходили пійти на майстер-клас. А статтею, ви як раз нагадали за це все! Можливо тепер хоч зараз знайдеться бажання і час спробувати.

І продали так само в $ ? Це вони прямо на рахунок у Польщі можуть виводиди , звідки ви вже придбали житло ?

«Не думай що команда може зробити для тебе, думай що ти можеш зробити для команди»

⠀⠀⠀⠀⠀⢀⣤⠖⠒⠒⠒⢒⡒⠒⠒⠒⠒⠒⠲⠦⠤⢤⣤⣄⣀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⣠⠟⠀⢀⠠⣐⢭⡐⠂⠬⠭⡁⠐⠒⠀⠀⣀⣒⣒⠐⠈⠙⢦⣄⠀⠀
⠀⠀⠀⣰⠏⠀⠐⠡⠪⠂⣁⣀⣀⣀⡀⠰⠀⠀⠀⢨⠂⠀⠀⠈⢢⠀⠀⢹⠀⠀
⠀⣠⣾⠿⠤⣤⡀⠤⡢⡾⠿⠿⠿⣬⣉⣷⠀⠀⢀⣨⣶⣾⡿⠿⠆⠤⠤⠌⡳⣄
⣰⢫⢁⡾⠋⢹⡙⠓⠦⠤⠴⠛⠀⠀⠈⠁⠀⠀⠀⢹⡀⠀⢠⣄⣤⢶⠲⠍⡎⣾
⢿⠸⠸⡇⠶⢿⡙⠳⢦⣄⣀⠐⠒⠚⣞⢛⣀⡀⠀⠀⢹⣶⢄⡀⠀⣸⡄⠠⣃⣿
⠈⢷⣕⠋⠀⠘⢿⡶⣤⣧⡉⠙⠓⣶⠿⣬⣀⣀⣐⡶⠋⣀⣀⣬⢾⢻⣿⠀⣼⠃
⠀⠀⠙⣦⠀⠀⠈⠳⣄⡟⠛⠿⣶⣯⣤⣀⣀⣏⣉⣙⣏⣉⣸⣧⣼⣾⣿⠀⡇⠀
⠀⠀⠀⠘⢧⡀⠀⠀⠈⠳⣄⡀⣸⠃⠉⠙⢻⠻⠿⢿⡿⢿⡿⢿⢿⣿⡟⠀⣧⠀
⠀⠀⠀⠀⠀⠙⢦⣐⠤⣒⠄⣉⠓⠶⠤⣤⣼⣀⣀⣼⣀⣼⣥⠿⠾⠛⠁⠀⢿⠀
⠀⠀⠀⠀⠀⠀⠀⠈⠙⠦⣭⣐⠉⠴⢂⡤⠀⠐⠀⠒⠒⢀⡀⠀⠄⠁⡠⠀⢸⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠙⠲⢤⣀⣀⠉⠁⠀⠀⠀⠒⠒⠒⠉⠀⢀⡾⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠉⠛⠲⠦⠤⠤⠤⠤⠴⠞⠋⠀⠀

Знаю одну історію як дехто намагався відрефакторити код. Зайшов на проект де був єдиним бекенд розробником. Там була структура що не подобалася розробнику, багато дублікату і всяке таке, що очі різало. Вирішив то відрефакторити, поступово разом з виконанням задач, але не врахував що навантаження на проекті і дедлайни можуть зрости. Результат вийшов не дуже:
— частина коду відрефакторена стала в новій структурі, здавалось би ок...;
— деякий новий функціонал писав не по легазі код стайлу, а «типо по нормальному» з наміром бо перформанс буде кращий;
— почав виносити деякі куски в сервіси, репозиторіїї і т.д;

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

Це все я до чого: треба мати на увазі що можливо не треби пріорітезувати рефакторінг.
Тут були поради про інтегрейшн тести — з цього я б почав, тобто:
1. Інтегрейшн тести — покрити всі ендпоінти, консюмери, листенери і т.д
2. Спланувати рефакторінг, і ще раз подумати чи стане часу і терпіння довести до кінця. Бо якщо воно лишеться на середині може стати гірше.

Цікава стаття, але все ж

В ІТ я потрапив сім років тому

Зараз дуже важко знайти роботу навіть досідченим програмістам, не кажучи вже про новавчків.

Міф № 4. Для роботи в ІТ обовʼязково потрібно знати англійську мову.

Це не міф. Це правда. Все інше скоріше виключення з правил ніж тенденція. Можливо це і було міфом 7 років тому, але про зараз дуже сумніваюсь. Усі наші недоліки це привід платити нам як умога нище, не знаючи англіської розробник буде неконкурентно здібним, що дасть можливість платити цому набагато менше, особливо в теперішніх реаліях коли вимоги до кандидатів виросли до небес.
І саме головне, рівень англійської може бути найчастіша причина відмов у співбесідах. Яким би класним розробником не був новачок, компаніі про це не дізнаються бо з рівнем А2 навіть спілкуватися не будуть, окрім випадків з виключеннями.

Як тільки почали вивчати програмування, ОДРАЗУ потрібно вчити англійську якщо рівень нище B2.

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

Вони як дебаггер який проходить крізь твоє життя

Класна аналогія )

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

Хороший момент ) Додав би до цього що початок і кінець це USD готівка. «Інвестори» кажуть не добре тримати під матрацом , тож гадаю треба в розрахунках брати до уваги що гроші були взяті як раз з під матрацу USD, заведені якось на рахунки з усіма комісіями і конвертаціями і потом при закритті інвестиційного портфелю той самий шлях назад під матрац.

Якщо візити були до родичів, то навіщо було їх приховувати

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

Я зрозумів що не додивився до тих сезонів де було про маньяка )) Треба це виправити ))

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

P.S. Тобі — то думаю більше було про те що він таких персонаж, що Майкл не любив його ) Тобто проблема була не в його ролі — HR )

Додам і ще один недолік до такого підходу — triggered функції мають бути ідемпотентними

Але в цілому так , це хороший момент , якого варто дотримуватись коли можливі retry або в цілому якщо обробляємо якісь івент чи вебхук де можливе повторення івенту )

Мені цікаво чи був у когось досвід міграціі з такої моделі проекту на більш звичну розробникам але в контексті того ж Firebase та GCP інфраструктури

Наприклад якщо розглянути типову модель Firebase проекту в якому все як описано в статті і як це промоутає Firebase:
— клієнт має прямий доступ в базу данних (Firestore)
— сам зчитує дані і сам записує
— на умовному backend стороні повно onCreate, onUpdate, onDelete тріггерів що реагують на відповідні івенти в БАЗІ ДАНИХ піднімаючи инстанс Cloud Function щоб щось зробити (duplication support, aggregation support, sending email/notification etc)

І мігрувати на щось таке:
— клієнт не має прямого доступу до бази данних (і взагалі не привязаний до Firestore, і нічого про це не знає)
— усі запити через HTTPS functions — onRequest тріггер в нашому випадку
— ніяких onCreate, onUpdate, onDelete тріггерів , знову ж таки все через відповідні HTTPS запити
— бажано ніяких duplication, aggregation support логіки (які через вище згадані onCreate, onUpdate функції часто і робляться). Якщо потрібні свіжі данні то ці данні збираються з відповідних таблиць

Цікаво з якими викликами команда стикнулася, чи не простіше в такому випадку заново переписати додаток або все ж таки є шлях плавно, по трохи робити таку міграцію в діючому проекті поступово декомісуючи onCreate, onUpdate тріггери переводячи клієнт на HTTPS

Думаю це можуть бути ті самі server-sent events (sse), по ходу діла вже можна думати над підходящим рішенням.

за його допомогою влаштувався

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

і він тобі допомогав

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

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

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

Думаю найкраще застереження це не мати onCreate, onUpdate тригерів ))

Набагато безпечніше і якісніше (імо) все робити через старий добрий http — в нашому випадку onRequest тріггер. Тобто усі update/write операціі обовязково через сервер (cloud functions з onRequest трігером в нашому випадку). І нам ніщо не заважає кидати ріал тайм івент клієнту самим якщо ім треба апдейтнуті дані інколи (а не так що клієн слухає апдейти в фаєсторі). Таким чином ми більш контролюємо ситуацію, можемо логувати те що потрібно, кидати нормальні помилки клієнту і т.д.

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

Так іх дійсно просто і швидко налаштовувати ))