Як швидко перейти з однієї технології на іншу? 🤯
Передісторія: на початку травня замовник вирішив, що нам терміново потрібен мобільний застосунок. Разом з командою ми обрали Flutter. Найцікавіше те, що він вирішив, що його повинні писати я та Юра, хоча я ніколи не писала на мобілку, і про це йому неодноразово говорила. Тому я повинна була швидко в ньому розібратись та почати допомагати Юрі в розробці. Проблема ще була в тому, що Flutter використовує мову програмування Dart, тобто я повинна була спочатку вивчити нову мову, а потім вже новий фреймворк.
В мене було зовсім мало часу і ось їм план дій:
1. Знайти статті, які допоможуть розібратись з новою технологією на базі тих, які ти вже знаєш. В моєму випадку, я почала читати статті, в яких пояснюється в чому схожість та відмінність JavaScript і Dart, Web-розробка і Flutter-розробка тощо. Ці статті швидко допомогли мені збагнути, які моменти я знаю зі свого досвіду, а які принципи для мене зовсім нові, і я повинна звернути на них увагу.
2. Почати писати невеличкий застосунок по гайду. Я думаю, вже всі давно зрозуміли, що нові знання по програмуванню потрібно відразу практикувати, бо толку буде мало. Так і в моєму випадку, я найшла в документації покрокову інструкцію розробки маленького застосунку, в якому, в принципі, були всі базові моменти, які я мала дізнатись про Flutter. Звичайно, перші кроки я повністю копіювала і вже потім розбиралась, що вони роблять. Далі поступово пробувала не дивитись на реалізацію, а писати невеличкі шматки коду самостійно.
3. Брати таски. Після того я відразу почала працювати над функціоналом, який не є початковим у нашому застосунку, тому я мала час повільно, але впевнено його робити. Було складно, вилазило багато моментів, про які я взагалі не здогадувалась, кожен новий елемент я гуглила, 100500 раз розказувала, що більше ніколи не проміняю JavaScript, але не дивлячись на це, завдяки практиці, я швидко вчилась.
Вкінці я отримала крутий досвід та результат - Mobile UI is absolutely epic! I can't believe you've only been working with Flutter for a few weeks. Both you and Yurii are incredibly talented. We always appreciate your help!!
#experience
Передісторія: на початку травня замовник вирішив, що нам терміново потрібен мобільний застосунок. Разом з командою ми обрали Flutter. Найцікавіше те, що він вирішив, що його повинні писати я та Юра, хоча я ніколи не писала на мобілку, і про це йому неодноразово говорила. Тому я повинна була швидко в ньому розібратись та почати допомагати Юрі в розробці. Проблема ще була в тому, що Flutter використовує мову програмування Dart, тобто я повинна була спочатку вивчити нову мову, а потім вже новий фреймворк.
В мене було зовсім мало часу і ось їм план дій:
1. Знайти статті, які допоможуть розібратись з новою технологією на базі тих, які ти вже знаєш. В моєму випадку, я почала читати статті, в яких пояснюється в чому схожість та відмінність JavaScript і Dart, Web-розробка і Flutter-розробка тощо. Ці статті швидко допомогли мені збагнути, які моменти я знаю зі свого досвіду, а які принципи для мене зовсім нові, і я повинна звернути на них увагу.
2. Почати писати невеличкий застосунок по гайду. Я думаю, вже всі давно зрозуміли, що нові знання по програмуванню потрібно відразу практикувати, бо толку буде мало. Так і в моєму випадку, я найшла в документації покрокову інструкцію розробки маленького застосунку, в якому, в принципі, були всі базові моменти, які я мала дізнатись про Flutter. Звичайно, перші кроки я повністю копіювала і вже потім розбиралась, що вони роблять. Далі поступово пробувала не дивитись на реалізацію, а писати невеличкі шматки коду самостійно.
3. Брати таски. Після того я відразу почала працювати над функціоналом, який не є початковим у нашому застосунку, тому я мала час повільно, але впевнено його робити. Було складно, вилазило багато моментів, про які я взагалі не здогадувалась, кожен новий елемент я гуглила, 100500 раз розказувала, що більше ніколи не проміняю JavaScript, але не дивлячись на це, завдяки практиці, я швидко вчилась.
Вкінці я отримала крутий досвід та результат - Mobile UI is absolutely epic! I can't believe you've only been working with Flutter for a few weeks. Both you and Yurii are incredibly talented. We always appreciate your help!!
#experience
👍28🔥9❤7😱2👏1
Частина 1. Наша перша технічна співбесіда.
… в якості інтерв’юерів 🫣
Так, ми раніше мали невеликий досвід у проведенні співбесід, але цього разу ми були повністю відповідальні за неї, повинні були провести її з початку та до кінця, самі продумати хід діалогу та питання.
На нашому проекті був потрібен розробник. Як ми раніше розповідали, зараз ми сфокусовані на розробці мобільного застосунку, тому потрібна була людина, яка підтримувала б веб. Нам підібрали кандидатів і від нас вимагалось тільки обрати найкращого.
Якщо чесно, спочатку ми думали, що це буде дуже легко, це ж не нас співбесідують, а ми. АЛЕ коли ми сіли скласти питання або хоча б якийсь хід розмови, ми розгубились. Що питати? Навіщо таке питати? А може це взагалі не потрібно дізнаватись?
І тоді ми почали згадувати наші співбесіди як кандидатів. Їх була достатня кількість, але лише від однієї у нас були дійсно тільки приємні спогади. Це була співбесіда на нашу попередню компанію і проводив її наш колишній (хах) тім лід. Він не питав по списку примітивні питання з першого сайту "що питати розробника". Це була розмова двох досвідчених програмістів. Він розповідав про себе, що він використовував, по ходу питав про наше відношення до тієї чи іншої методики. Він хотів почути не завчений матеріал, а саме нашу думку, що нам подобається і що ми б не хотіли використовувати в роботі. Питав про наш досвід, технології, наше відношення до цих технологій, чому ми обрали саме їх. Звісно були питання про патерни, алгоритми і тд, але ж знову, це була не теорія, а саме чи мали ми з ними досвід, і що реалізовували завдяки ним.
Після закінчення такої співбесіди, ти не виходиш як вижатий лимон, ти виходиш з новими поглядами на старі речі, та тільки з приємними емоціями і відчуттям якісно проведеного часу.
І нам максимально хотілось провести саме таку співбесіду, а не суху і чисто технічну.
Дуже багато тексту і не хочеться вас перевантажувати, тому далі буде…
#experience #interview
… в якості інтерв’юерів 🫣
Так, ми раніше мали невеликий досвід у проведенні співбесід, але цього разу ми були повністю відповідальні за неї, повинні були провести її з початку та до кінця, самі продумати хід діалогу та питання.
На нашому проекті був потрібен розробник. Як ми раніше розповідали, зараз ми сфокусовані на розробці мобільного застосунку, тому потрібна була людина, яка підтримувала б веб. Нам підібрали кандидатів і від нас вимагалось тільки обрати найкращого.
Якщо чесно, спочатку ми думали, що це буде дуже легко, це ж не нас співбесідують, а ми. АЛЕ коли ми сіли скласти питання або хоча б якийсь хід розмови, ми розгубились. Що питати? Навіщо таке питати? А може це взагалі не потрібно дізнаватись?
І тоді ми почали згадувати наші співбесіди як кандидатів. Їх була достатня кількість, але лише від однієї у нас були дійсно тільки приємні спогади. Це була співбесіда на нашу попередню компанію і проводив її наш колишній (хах) тім лід. Він не питав по списку примітивні питання з першого сайту "що питати розробника". Це була розмова двох досвідчених програмістів. Він розповідав про себе, що він використовував, по ходу питав про наше відношення до тієї чи іншої методики. Він хотів почути не завчений матеріал, а саме нашу думку, що нам подобається і що ми б не хотіли використовувати в роботі. Питав про наш досвід, технології, наше відношення до цих технологій, чому ми обрали саме їх. Звісно були питання про патерни, алгоритми і тд, але ж знову, це була не теорія, а саме чи мали ми з ними досвід, і що реалізовували завдяки ним.
Після закінчення такої співбесіди, ти не виходиш як вижатий лимон, ти виходиш з новими поглядами на старі речі, та тільки з приємними емоціями і відчуттям якісно проведеного часу.
І нам максимально хотілось провести саме таку співбесіду, а не суху і чисто технічну.
Дуже багато тексту і не хочеться вас перевантажувати, тому далі буде…
#experience #interview
👍43❤11❤🔥2
Частина 2. Наша перша технічна співбесіда.
👉 Читати частину 1
Ми вирішили, що складемо план розмови, але він буде з загальними питаннями про досвід, вподобання і прагнення на майбутнє.
Так як ми шукали full stack розробника, ми отримали такий план:
1. Знайомство. Спочатку ми розповіли хто ми є, трішки жартували (сподіваюсь, смішно), щоб кандидат відчував себе комфортніше. Потім розпитували кандидата про нього. Ось приклад питань (це далеко не всі). Так, але давайте за англійську не сваріться, тому що це все писалось на колінці 😅:
- What recent task was a challenge for you?
- Which tech stack do you prefer?
- Do you have some technologies you want to try?
2. Web.
- What state-management tools have you used (Redux, MobX)? Pros and cons.
- What third-party libraries/API’s have you used?
- How do you optimise your React code?
3. Backend.
- What frameworks/libraries have you used for your services?
- Have you used ORMs? Could you list them? Pros and cons.
- Where did you deploy your services? Did you use some CI/CD tools?
4. Питання від кандидата. Це дуже важливо поцікавитись чи в нього залишились питання і максимально чітко на них відповісти.
Так, в питаннях було багато "have you used", адже ми хотіли почути саме досвід, що вони вміють робити, з чим вони стикались на попередніх проектах, їх вподобання та те, з чим вони більше не хотіли б працювати. Завдяки таким питанням, співбесіда розвивалась у форматі розмови, а не "питання-відповідь".
Ви можете сказати, що цього дуже мало та не достатньо, щоб дізнатись, який рівень у даного розробника, тому уточнимо, що перед співбесідою кандидати виконували завдання і те, що писати код вони вміють, ми знали 🙂. Плюс, вони виконували таски в нашому комерційному проекті (відразу кажемо, що їм за це непогано заплатили, тому їх ніхто не використав) і ми могли ще поцікавитись як їм код, архітектура, що сподобалось, що ні, які виникли питання. Це також нам допомогло краще зрозуміти кандидата та його вподобання.
І питання звучали на англійській, тому що компанія американська і ми спілкуємось англійською. Один з кандидатів був з Казахстану і він знав росій**ку, але ми відразу порозумілись, що дану мову ми використовувати не будемо! Ну і вам не радимо 😉
Сподіваємось, вам цей пост був корисний, адже коли ми готувались, то не змогли знайти актуальних статей про те, як краще проводити співбесіду.
І, до речі, ми отримали хороші відгуки від кандидатів:
- It was a fun meeting. Thank you for your time today!
- Thank you for taking the time to have a meeting today. I could understand the current application and the roadmaps. I also really enjoyed speaking with you.
#experience #interview
👉 Читати частину 1
Ми вирішили, що складемо план розмови, але він буде з загальними питаннями про досвід, вподобання і прагнення на майбутнє.
Так як ми шукали full stack розробника, ми отримали такий план:
1. Знайомство. Спочатку ми розповіли хто ми є, трішки жартували (сподіваюсь, смішно), щоб кандидат відчував себе комфортніше. Потім розпитували кандидата про нього. Ось приклад питань (це далеко не всі). Так, але давайте за англійську не сваріться, тому що це все писалось на колінці 😅:
- What recent task was a challenge for you?
- Which tech stack do you prefer?
- Do you have some technologies you want to try?
2. Web.
- What state-management tools have you used (Redux, MobX)? Pros and cons.
- What third-party libraries/API’s have you used?
- How do you optimise your React code?
3. Backend.
- What frameworks/libraries have you used for your services?
- Have you used ORMs? Could you list them? Pros and cons.
- Where did you deploy your services? Did you use some CI/CD tools?
4. Питання від кандидата. Це дуже важливо поцікавитись чи в нього залишились питання і максимально чітко на них відповісти.
Так, в питаннях було багато "have you used", адже ми хотіли почути саме досвід, що вони вміють робити, з чим вони стикались на попередніх проектах, їх вподобання та те, з чим вони більше не хотіли б працювати. Завдяки таким питанням, співбесіда розвивалась у форматі розмови, а не "питання-відповідь".
Ви можете сказати, що цього дуже мало та не достатньо, щоб дізнатись, який рівень у даного розробника, тому уточнимо, що перед співбесідою кандидати виконували завдання і те, що писати код вони вміють, ми знали 🙂. Плюс, вони виконували таски в нашому комерційному проекті (відразу кажемо, що їм за це непогано заплатили, тому їх ніхто не використав) і ми могли ще поцікавитись як їм код, архітектура, що сподобалось, що ні, які виникли питання. Це також нам допомогло краще зрозуміти кандидата та його вподобання.
І питання звучали на англійській, тому що компанія американська і ми спілкуємось англійською. Один з кандидатів був з Казахстану і він знав росій**ку, але ми відразу порозумілись, що дану мову ми використовувати не будемо! Ну і вам не радимо 😉
Сподіваємось, вам цей пост був корисний, адже коли ми готувались, то не змогли знайти актуальних статей про те, як краще проводити співбесіду.
І, до речі, ми отримали хороші відгуки від кандидатів:
- It was a fun meeting. Thank you for your time today!
- Thank you for taking the time to have a meeting today. I could understand the current application and the roadmaps. I also really enjoyed speaking with you.
#experience #interview
👍32❤7🔥3
Давайте поговоримо про гроші.
За наш шлях в ІТ ми встигли попрацювати з різними формами оплати. Тому, сьогодні ми хочемо розібратися з плюсами та мінусами кожної з них і з'ясувати, в яких випадках краще обирати той чи інший варіант.
Фіксована ставка.
Фіксована ставка – це оплата за фіксовану кількість робочого часу (наприклад, місяць) незалежно від того, скільки роботи потрібно виконати. Чудово підійде, якщо ви працюєте в компанії. Маєте один чи кілька проектів, відпрацювали місяць, отримали зарплату. Всім все підходить.
АЛЕ, якщо ви працюєте за такою формою оплати, обов’язково потрібно обговорити те, як оплачується понаднормовий робочий час, і чи він взагалі можливий. Якщо цей час додатково не оплачується, то в мене є питання до компанії.
Погодинна оплата.
При такій формі працівник отримує фіксовану оплату за кожну годину роботи. Чудово підійде для part-time роботи. У свій вільний від основної роботи час, програміст виконує таски, записує витрачені години та отримує зарплату за формулою
Не рекомендуємо таку форму оплати, якщо це ваша основна робота. Ми мали такий досвід, коли працювали з трекером. Все, що можемо сказати - ніякої стабільності, багато нервів та різний розмір зарплати кожного місяця.
Оплата за виконаний проект.
Дуже вигідно замовнику, але не програмісту. Це тому, що незалежно від того, наскільки б детально ви не прораховували обсяг роботи та бюджет, завжди з'являються правки та підводні камені, про які ви не підозрювали, і в більшості випадків доведеться працювати за свій кошт.
Мали досвід, працювали над проектом пару місяців, отримали навіть не свою місячну зарплату. Тому, якщо вам пропонують зробити проект під ключ, який займе більше, ніж місяць часу, пробуйте домовлятись за погодинну оплату.
Сподіваємось, пост був корисним, хоча й дуже суб'єктивним! Чекаємо історії про ваш досвід і рекомендації про найкращу форму оплати 💛
#experience
За наш шлях в ІТ ми встигли попрацювати з різними формами оплати. Тому, сьогодні ми хочемо розібратися з плюсами та мінусами кожної з них і з'ясувати, в яких випадках краще обирати той чи інший варіант.
Фіксована ставка.
Фіксована ставка – це оплата за фіксовану кількість робочого часу (наприклад, місяць) незалежно від того, скільки роботи потрібно виконати. Чудово підійде, якщо ви працюєте в компанії. Маєте один чи кілька проектів, відпрацювали місяць, отримали зарплату. Всім все підходить.
АЛЕ, якщо ви працюєте за такою формою оплати, обов’язково потрібно обговорити те, як оплачується понаднормовий робочий час, і чи він взагалі можливий. Якщо цей час додатково не оплачується, то в мене є питання до компанії.
Погодинна оплата.
При такій формі працівник отримує фіксовану оплату за кожну годину роботи. Чудово підійде для part-time роботи. У свій вільний від основної роботи час, програміст виконує таски, записує витрачені години та отримує зарплату за формулою
кількість годин * рейт.Не рекомендуємо таку форму оплати, якщо це ваша основна робота. Ми мали такий досвід, коли працювали з трекером. Все, що можемо сказати - ніякої стабільності, багато нервів та різний розмір зарплати кожного місяця.
Оплата за виконаний проект.
Дуже вигідно замовнику, але не програмісту. Це тому, що незалежно від того, наскільки б детально ви не прораховували обсяг роботи та бюджет, завжди з'являються правки та підводні камені, про які ви не підозрювали, і в більшості випадків доведеться працювати за свій кошт.
Мали досвід, працювали над проектом пару місяців, отримали навіть не свою місячну зарплату. Тому, якщо вам пропонують зробити проект під ключ, який займе більше, ніж місяць часу, пробуйте домовлятись за погодинну оплату.
Сподіваємось, пост був корисним, хоча й дуже суб'єктивним! Чекаємо історії про ваш досвід і рекомендації про найкращу форму оплати 💛
#experience
👍49❤4🔥3👎1😢1
vim 🤓
Останнім часом я вирішив спробувати vim. І сьогодні я хочу коротко поділитись про перший досвід та враження.
Насправді, це сталось з другої спроби, бо перший раз я обрав трохи не той підхід. Я подумав, що просто залечу в нього і все почне само собою виходити. А виявилось, що це зовсім нелегко.
Одне з найскладніших місць у vim - це саме почати ним користуватись, адже це зовсім нове середовище. Одразу після того як ви зрозумієте основні вертикальні і горизонтальні рухи, режими роботи та команди, ви будете ставати все більш продуктивнішими.
У vim справді закладено певний сенс. Ви зможете будувати свої команди на ходу, оперуючи вже тим, що вивчили. Ось короткий приклад: delete word - dw, delete inside () - di(.
Поки я пробую комбінувати VSCode з розширенням vim та Neovim редактори. Ще не вирішив чи буду змінювати редактор коду, але думаю, що все таки vim залишу у будь-якому випадку (хоча б як розширення).
Тому, якщо вам зручно працювати з фокусом на клавіатурі, раджу хоча б спробувати.
Якщо ви зацікавились, поділюсь кількома ресурсами:
- Youtube плейлист від ThePrimeagen
- Learn Vim for the last time
- Vim Adventures
#experience
Останнім часом я вирішив спробувати vim. І сьогодні я хочу коротко поділитись про перший досвід та враження.
Насправді, це сталось з другої спроби, бо перший раз я обрав трохи не той підхід. Я подумав, що просто залечу в нього і все почне само собою виходити. А виявилось, що це зовсім нелегко.
Одне з найскладніших місць у vim - це саме почати ним користуватись, адже це зовсім нове середовище. Одразу після того як ви зрозумієте основні вертикальні і горизонтальні рухи, режими роботи та команди, ви будете ставати все більш продуктивнішими.
У vim справді закладено певний сенс. Ви зможете будувати свої команди на ходу, оперуючи вже тим, що вивчили. Ось короткий приклад: delete word - dw, delete inside () - di(.
Поки я пробую комбінувати VSCode з розширенням vim та Neovim редактори. Ще не вирішив чи буду змінювати редактор коду, але думаю, що все таки vim залишу у будь-якому випадку (хоча б як розширення).
Тому, якщо вам зручно працювати з фокусом на клавіатурі, раджу хоча б спробувати.
Якщо ви зацікавились, поділюсь кількома ресурсами:
- Youtube плейлист від ThePrimeagen
- Learn Vim for the last time
- Vim Adventures
#experience
👍14🤓6❤4😨1
Як знайти свою першу роботу в ІТ, частина 1.
Резюме 📄
Ми поставили собі запитання - як би ми зараз шукали свою першу роботу в ІТ взагалі без досвіду. І в нас вийшла невеличка підбірка порад, якою б ми хотіли поділитись. Все, що тут написано, чисто суб'єктивні ідеї з нашого досвіду або досвіду наших знайомих/друзів, які також працюють в ІТ.
Перше, з чого потрібно почати, це звичайно гарне, структуроване та інформативне резюме. Зараз є дуже багато статей, як правильно підготувати cv, наприклад, читайте пост. Тому, зараз хочемо виділити тільки ті речі, які для нас важливі в створенні резюме:
- Структурованість. Повинні бути чіткі секції/блоки, де описані конкретні дані про вашу освіту, досвід, проєкти тощо. Це дасть змогу роботодавцю/рекрутеру легко знаходити потрібну інформацію про вас.
- Стислість. Резюме не повинно бути на 20 сторінок, ніхто його читати не буде. В ідеалі все повинно поміститись на 1-2 сторінки, тим більше "в нас немає досвіду", а занадто багато розписувати про свої всі пет-проєкти і дипломи "Кенгуру" не варто.
- Дизайн. Його просто не має бути. Я пам'ятаю своє перше резюме: чорний фон, яскраво жовті вставки, білий текст, інформація розкидана як-небудь. Мені казали, що це крінж, а я - зате красіво! Ні, ні і ще раз ні. Резюме - це документ, не потрібно там нічого придумувати. Білий фон, чорний текст, чітка структура. Я чула, що деякі рекрутери радять навіть фото не ставити, напевно, вони програмістів не по красоті набирають 🙂
- Формат. Зберігайте своє резюме в двох форматах - doc i pdf. Doc - для себе, щоб швидко поправити/оновити інформацію. Pdf - для роботодавця, щоб в нього точно нічого не поплило/не переформатувалось. Також не забудьте чітко підписати файл, наприклад, CV_Junior_React_ Developer_Anastasiia_Tarasenko.
Тепер нам цікаво почути вашу думку, яке ж має бути те резюме 💛
#experience
Резюме 📄
Ми поставили собі запитання - як би ми зараз шукали свою першу роботу в ІТ взагалі без досвіду. І в нас вийшла невеличка підбірка порад, якою б ми хотіли поділитись. Все, що тут написано, чисто суб'єктивні ідеї з нашого досвіду або досвіду наших знайомих/друзів, які також працюють в ІТ.
Перше, з чого потрібно почати, це звичайно гарне, структуроване та інформативне резюме. Зараз є дуже багато статей, як правильно підготувати cv, наприклад, читайте пост. Тому, зараз хочемо виділити тільки ті речі, які для нас важливі в створенні резюме:
- Структурованість. Повинні бути чіткі секції/блоки, де описані конкретні дані про вашу освіту, досвід, проєкти тощо. Це дасть змогу роботодавцю/рекрутеру легко знаходити потрібну інформацію про вас.
- Стислість. Резюме не повинно бути на 20 сторінок, ніхто його читати не буде. В ідеалі все повинно поміститись на 1-2 сторінки, тим більше "в нас немає досвіду", а занадто багато розписувати про свої всі пет-проєкти і дипломи "Кенгуру" не варто.
- Дизайн. Його просто не має бути. Я пам'ятаю своє перше резюме: чорний фон, яскраво жовті вставки, білий текст, інформація розкидана як-небудь. Мені казали, що це крінж, а я - зате красіво! Ні, ні і ще раз ні. Резюме - це документ, не потрібно там нічого придумувати. Білий фон, чорний текст, чітка структура. Я чула, що деякі рекрутери радять навіть фото не ставити, напевно, вони програмістів не по красоті набирають 🙂
- Формат. Зберігайте своє резюме в двох форматах - doc i pdf. Doc - для себе, щоб швидко поправити/оновити інформацію. Pdf - для роботодавця, щоб в нього точно нічого не поплило/не переформатувалось. Також не забудьте чітко підписати файл, наприклад, CV_Junior_React_ Developer_Anastasiia_Tarasenko.
Тепер нам цікаво почути вашу думку, яке ж має бути те резюме 💛
#experience
👍24❤9🔥1
Як знайти свою першу роботу в ІТ, частина 2.
Пошук роботи 🔍
👉 Читати частину 1
Написали файне резюме, тепер можемо приступати безпосередньо до пошуку роботи. Наголосимо знову, що в даному списку тільки ті сервіси, які ми особисто використовували. Насправді, їх існує набагато більше.
Ну що ж, почнемо. А по всім канонам ІТ, перше, на що потрібно звернути увагу, це:
- LinkedIn. Дану соціальну мережу не можна на 100% назвати сервісом для пошуку роботи, це більше ваше портфоліо. І воно у вас має бути обов’язково! Саме тут ви можете написати максимально багато інформації про себе. Заповнюйте skills та проходьте тести, щоб їх підтвердити (вони взагалі не є складними + відповіді давним-давно злиті 🤫). Долучайтесь до знайомих і незнайомих, особливо до рекрутерів. Багато з них можуть пропонувати різні вакансії через LinkedIn. Також можете опублікувати своє CV з текстом, що ви шукаєте роботу. Можливо, воно розлетиться і хтось вас помітить.
- Djinni - суб’єктивно найкраща платформа для пошуку роботи. Детально та якісно заповнюйте свій профіль і постійно перевіряйте вакансії, які для вас релевантні. І ще така «порада» - подавайтесь навіть на ті вакансії, де є технології, які ви не дуже знаєте. Я не кажу подаватись на Angular, якщо ви знаєте React. Я кажу подавайтесь на ті вакансії, де в переліку є, наприклад, Tailwind, а ви його ще не знаєте, але ви розумієте, що походу зможете його швидко вивчити. Якщо б ми в свій час подавались лише на ті ваканасії, де ми знаємо 100% з переліку вимог, ми б сиділи без роботи.
- Dou - чесно, ми не шукали роботу через цю платформу, але чули, що це також дуже хороший сервіс. Ми там більше дивимось відгуки про компанії. Я в свій час була підписана на їх телеграм-канал, де вони діляться вакансіями, інтернатурами, стажуваннями для людей зовсім без досвіду. Ви зможете його знайти на сайті. І ще одна «порада» - не цурайтесь безкоштовної інтернатури чи стажування (якщо звичайно це не комерційний проект) - це хороший шанс потрапити в компанію. Майже всі наші друзі (в тому числі і ми) потрапили в свою першу компанію через стажування або інтернатуру. Плюс, це досвід, який ви зможете вписати собі в резюме.
- Сайти компаній. Шукайте та моніторте сайти різних компаній, а особливо розділ кар’єра. Там є список вакансій і, можливо, ви знайдете собі підходящу. Навіть, якщо такої немає, можете всеодно надіслати своє резюме, раптом воно їх зацікавить.
- Сарафанне радіо - це дуже недооцінений спосіб пошуку роботи і дуже даремно. Тому не стидайтесь і говоріть всім, що шукаєте роботу, особливо тим знайомим, які дотичні до ІТ. Зараз важка ситуація на ринку і буде дуже круто, якщо ваш знайомий зможе замовити словечко за вас у своїй компанії.
Напишіть про ваші способи пошуку роботи, нам цікаво 💛
#experience
Пошук роботи 🔍
👉 Читати частину 1
Написали файне резюме, тепер можемо приступати безпосередньо до пошуку роботи. Наголосимо знову, що в даному списку тільки ті сервіси, які ми особисто використовували. Насправді, їх існує набагато більше.
Ну що ж, почнемо. А по всім канонам ІТ, перше, на що потрібно звернути увагу, це:
- LinkedIn. Дану соціальну мережу не можна на 100% назвати сервісом для пошуку роботи, це більше ваше портфоліо. І воно у вас має бути обов’язково! Саме тут ви можете написати максимально багато інформації про себе. Заповнюйте skills та проходьте тести, щоб їх підтвердити (вони взагалі не є складними + відповіді давним-давно злиті 🤫). Долучайтесь до знайомих і незнайомих, особливо до рекрутерів. Багато з них можуть пропонувати різні вакансії через LinkedIn. Також можете опублікувати своє CV з текстом, що ви шукаєте роботу. Можливо, воно розлетиться і хтось вас помітить.
- Djinni - суб’єктивно найкраща платформа для пошуку роботи. Детально та якісно заповнюйте свій профіль і постійно перевіряйте вакансії, які для вас релевантні. І ще така «порада» - подавайтесь навіть на ті вакансії, де є технології, які ви не дуже знаєте. Я не кажу подаватись на Angular, якщо ви знаєте React. Я кажу подавайтесь на ті вакансії, де в переліку є, наприклад, Tailwind, а ви його ще не знаєте, але ви розумієте, що походу зможете його швидко вивчити. Якщо б ми в свій час подавались лише на ті ваканасії, де ми знаємо 100% з переліку вимог, ми б сиділи без роботи.
- Dou - чесно, ми не шукали роботу через цю платформу, але чули, що це також дуже хороший сервіс. Ми там більше дивимось відгуки про компанії. Я в свій час була підписана на їх телеграм-канал, де вони діляться вакансіями, інтернатурами, стажуваннями для людей зовсім без досвіду. Ви зможете його знайти на сайті. І ще одна «порада» - не цурайтесь безкоштовної інтернатури чи стажування (якщо звичайно це не комерційний проект) - це хороший шанс потрапити в компанію. Майже всі наші друзі (в тому числі і ми) потрапили в свою першу компанію через стажування або інтернатуру. Плюс, це досвід, який ви зможете вписати собі в резюме.
- Сайти компаній. Шукайте та моніторте сайти різних компаній, а особливо розділ кар’єра. Там є список вакансій і, можливо, ви знайдете собі підходящу. Навіть, якщо такої немає, можете всеодно надіслати своє резюме, раптом воно їх зацікавить.
- Сарафанне радіо - це дуже недооцінений спосіб пошуку роботи і дуже даремно. Тому не стидайтесь і говоріть всім, що шукаєте роботу, особливо тим знайомим, які дотичні до ІТ. Зараз важка ситуація на ринку і буде дуже круто, якщо ваш знайомий зможе замовити словечко за вас у своїй компанії.
Напишіть про ваші способи пошуку роботи, нам цікаво 💛
#experience
👍15❤8🔥2
Як знайти свою першу роботу в ІТ, частина 3.
Співбесіда 🤯
👉 Читати частину 2
Дуже відповідальний момент - технічна співбесіда. Зазвичай (але не завжди), вона ділиться на три частини:
1. Знайомство. Якщо рекрутеру ви не могли розповісти всі технічні деталі вашого досвіду, то вже на цьому етапі ви можете зробити це в усій красі, адже перед вами сидять програмісти і вони вас розуміють. А взагалі, самопрезентація - це дуже важлива навичка, тому необхідно її також тренувати.
2. Теоретичні питання. Майже нереально здогадатись наперед, що вас будуть запитувати. Зазвичай, питають від простих питань до більш складніших. Але ж знову акцентуємо вашу увагу - не завжди. Юра якось проходив співбесіду чисто на frontend, а в нього почали відразу питати про бази даних 🙈 І також, якщо ваш колега проходив співбесіду в ту ж саму компанію, це не дає вам гарантію отримати такі самі запитання. В нас був такий досвід і сподівання, але питання виявились різними, тому що вели співбесіду різні програмісти.
На цьому етапі хочеться дати кілька порад:
- Не панікуйте. Знаю, це складно, але постарайтесь сприймати співбесіду як хороший шанс перевірити свої знання, а не останню можливість у вашому житті.
- Готуйтеся до співбесіди поступово. Не потрібно все вчити в останню ніч. Ви не виспитесь, все переплутаєте і зможете забути навіть ті поняття, які добре знали. Краще виділяти кілька годинок щодня і розбирати питання, в яких ви невпевнені.
- Знайдіть список питань для підготовки до співбесіди і розбирайте їх. Можете використовувати нашу рубрику #interview, де ми розбираємо питання різної складності. Також під цією рубрикою ми публікували багато підбірок питань та відповідей по різних технологіях. Можете використати FullStack Cafe, там є величезні списки питань, які можуть бути на співбесіді.
- Будьте готові до надто простих питань. Зараз ринок складний і від джунів вимагають те, що навіть не всі сіньйори знають. Але ніхто не відміняв фундаментальні поняття, які потрібно 100% знати.
- Не бійтеся чогось не знати. Якщо ви не знаєте відповіді, головне не панікуйте. Візьміть хвилинну паузу, і раптом відповіді все ж немає, поясніть, що з цими технологіями ви ще не працювали. Знати все — неможливо, але ваша реакція на незнання може розказати набагато більше, ніж правильна відповідь.
3. Live coding. Як же я ненавиджу цей етап. Особисто в мене, коли хтось дивиться як я програмую, починається дуже сильний тупняк. Навіть було таке, що я відмовлялась від вакансії, бо там був етап live coding. Але зазвичай, від цього нікуди не дітись, потрібно опановувати себе і дивитись страхам в обличчя. Спробуйте знайти на сайтах HackerRank, LeetCode або Codewars приклади схожих задач і вивчіть алгоритми, які використовуються в їхньому вирішенні.
І на останок, обов'язково готуйте свої запитання. Це важливо і для вас, щоб розуміти особливості проєкту, продукту, команди, а також це показує співрозмовнику ваше серйозне ставлення до роботи.
Напишіть, як ви готуєтесь до технічної співбесіди, нам цікаво 💛
#experience
Співбесіда 🤯
👉 Читати частину 2
Дуже відповідальний момент - технічна співбесіда. Зазвичай (але не завжди), вона ділиться на три частини:
1. Знайомство. Якщо рекрутеру ви не могли розповісти всі технічні деталі вашого досвіду, то вже на цьому етапі ви можете зробити це в усій красі, адже перед вами сидять програмісти і вони вас розуміють. А взагалі, самопрезентація - це дуже важлива навичка, тому необхідно її також тренувати.
2. Теоретичні питання. Майже нереально здогадатись наперед, що вас будуть запитувати. Зазвичай, питають від простих питань до більш складніших. Але ж знову акцентуємо вашу увагу - не завжди. Юра якось проходив співбесіду чисто на frontend, а в нього почали відразу питати про бази даних 🙈 І також, якщо ваш колега проходив співбесіду в ту ж саму компанію, це не дає вам гарантію отримати такі самі запитання. В нас був такий досвід і сподівання, але питання виявились різними, тому що вели співбесіду різні програмісти.
На цьому етапі хочеться дати кілька порад:
- Не панікуйте. Знаю, це складно, але постарайтесь сприймати співбесіду як хороший шанс перевірити свої знання, а не останню можливість у вашому житті.
- Готуйтеся до співбесіди поступово. Не потрібно все вчити в останню ніч. Ви не виспитесь, все переплутаєте і зможете забути навіть ті поняття, які добре знали. Краще виділяти кілька годинок щодня і розбирати питання, в яких ви невпевнені.
- Знайдіть список питань для підготовки до співбесіди і розбирайте їх. Можете використовувати нашу рубрику #interview, де ми розбираємо питання різної складності. Також під цією рубрикою ми публікували багато підбірок питань та відповідей по різних технологіях. Можете використати FullStack Cafe, там є величезні списки питань, які можуть бути на співбесіді.
- Будьте готові до надто простих питань. Зараз ринок складний і від джунів вимагають те, що навіть не всі сіньйори знають. Але ніхто не відміняв фундаментальні поняття, які потрібно 100% знати.
- Не бійтеся чогось не знати. Якщо ви не знаєте відповіді, головне не панікуйте. Візьміть хвилинну паузу, і раптом відповіді все ж немає, поясніть, що з цими технологіями ви ще не працювали. Знати все — неможливо, але ваша реакція на незнання може розказати набагато більше, ніж правильна відповідь.
3. Live coding. Як же я ненавиджу цей етап. Особисто в мене, коли хтось дивиться як я програмую, починається дуже сильний тупняк. Навіть було таке, що я відмовлялась від вакансії, бо там був етап live coding. Але зазвичай, від цього нікуди не дітись, потрібно опановувати себе і дивитись страхам в обличчя. Спробуйте знайти на сайтах HackerRank, LeetCode або Codewars приклади схожих задач і вивчіть алгоритми, які використовуються в їхньому вирішенні.
І на останок, обов'язково готуйте свої запитання. Це важливо і для вас, щоб розуміти особливості проєкту, продукту, команди, а також це показує співрозмовнику ваше серйозне ставлення до роботи.
Напишіть, як ви готуєтесь до технічної співбесіди, нам цікаво 💛
#experience
👍13🔥5❤3😭1
Як знайти свою першу роботу в ІТ, частина 4.
Фідбек 👻
👉 Читати частину 3
Ви молодці, вже все найгірше позаду, залишилось дізнатись результат ваших зусиль.
Найнеприємніше, що може статися на цьому етапі - це звичайно ж відмова. Найкраще, що ви можете зробити — це не сприймати відмову як кінець світу. Якщо компанія дала адекватний фідбек, чому ви їм не підійшли, то ви дізнались на що потрібно звернути увагу і на співбесідах з іншою компанією зможете проявити себе ще краще. Але якщо ви розумієте, що ви добре пройшли всі етапи, а компанія не може об'єктивно аргументувати свій вибір або просто впала на мороз - то є велика вірогідність, що проблема була не у вас. Зараз складний ринок і в один день може все змінитись. Тому не засмучайтесь і продовжуйте пошуки своєї першої роботи.
Якщо ж ви отримали позитивний фідбек, ми вас вітаємо. Єдині поради, це ще раз переконатись, що ви дійсно хочете в дану компанію, перечитати УВАЖНО всі умови та договір, ну і добре приготуватись до нової сходинки у вашій кар'єрі.
#experience
Фідбек 👻
👉 Читати частину 3
Ви молодці, вже все найгірше позаду, залишилось дізнатись результат ваших зусиль.
Найнеприємніше, що може статися на цьому етапі - це звичайно ж відмова. Найкраще, що ви можете зробити — це не сприймати відмову як кінець світу. Якщо компанія дала адекватний фідбек, чому ви їм не підійшли, то ви дізнались на що потрібно звернути увагу і на співбесідах з іншою компанією зможете проявити себе ще краще. Але якщо ви розумієте, що ви добре пройшли всі етапи, а компанія не може об'єктивно аргументувати свій вибір або просто впала на мороз - то є велика вірогідність, що проблема була не у вас. Зараз складний ринок і в один день може все змінитись. Тому не засмучайтесь і продовжуйте пошуки своєї першої роботи.
Якщо ж ви отримали позитивний фідбек, ми вас вітаємо. Єдині поради, це ще раз переконатись, що ви дійсно хочете в дану компанію, перечитати УВАЖНО всі умови та договір, ну і добре приготуватись до нової сходинки у вашій кар'єрі.
#experience
❤10👍3💯1
Чому
Масив - це набір елементів одного типу, що зберігаються в неперервному шматку памʼяті. Масив не можна просто взяти і розширити чи зменшити. Це можна побачити в традиційних масивах, наприклад, в С (
А в JS те, що ми називаємо Array - насправді набагато складніша структура даних (яка насправді десь глибоко внизу напевно має справжні масиви). Все це зроблено для оптимізації та для спрощення роботи програміста. Тому, коли ви зробите щось на кшталт
Масив - одна з найпростіших структур даних. І ми вважаємо, що алгоритми та структури даних варто знати хоча б поверхнево, тому щоб тримати себе в тонусі, зараз проходимо безкоштовний курс від ThePrimeagen на Frontend Masters, який можемо і вам сміливо порекомендувати.
👉 Відкрити посилання
#experience
[] в JS насправді не масив?Масив - це набір елементів одного типу, що зберігаються в неперервному шматку памʼяті. Масив не можна просто взяти і розширити чи зменшити. Це можна побачити в традиційних масивах, наприклад, в С (
int[3]). А в JS те, що ми називаємо Array - насправді набагато складніша структура даних (яка насправді десь глибоко внизу напевно має справжні масиви). Все це зроблено для оптимізації та для спрощення роботи програміста. Тому, коли ви зробите щось на кшталт
new Array(4 мільярди), то ваш компʼютер благополучно продовжить працювати далі. Ви навіть можете додати значення до першого та останнього елемента і все буде нормально.Масив - одна з найпростіших структур даних. І ми вважаємо, що алгоритми та структури даних варто знати хоча б поверхнево, тому щоб тримати себе в тонусі, зараз проходимо безкоштовний курс від ThePrimeagen на Frontend Masters, який можемо і вам сміливо порекомендувати.
👉 Відкрити посилання
#experience
👍21❤7🤯2
Коли і як ІТ-спеціалісту говорити про підвищення зарплати? 💰
Ми прекрасно розуміємо, що зараз складна ситуація на ринку і далеко не всім хочеться піднімати це питання. Але якщо ви вже достатньо часу працюєте в компанії і відчуваєте, що вже давно виросли, то можливо наші поради будуть вам в нагоді.
Почнемо з першого питання - коли потрібно говорити про підвищення зарплати?
1. Ви маєте сильне внутрішнє відчуття того, що ви гідні отримувати більше і вважаєте необхідністю, щоб вас підвищили. Ви взяли на себе багато відповідальності, багато чого навчились та зробили для компанії. Не потрібно плутати з банальним "хочу більше грошей". Це бажання має бути підкріплене вашим ростом як спеціаліста.
2. Не менш важливо підібрати правильний час для обговорення. Це може бути успішне завершення проєкту, вирішення важливої проблеми або збільшення робочого навантаження, з яким ви добре справляєтесь (тут важливо не затягувати, щоб не отримати вигорання).
Наступне питання - як підготуватись до розмови?
1. Ви повинні підготувати аргументи на свою користь - чого ви досягли за цей період, чого навчились, за що взяли відповідальність, скільки користі компанії ви принесли. Якщо коротко, нахвалюйте себе, але в міру 😅
2. Проаналізуйте ринок. Поцікавтеся, які зарплати отримують спеціалісти вашого профілю в інших компаніях. Можете використати статистику зарплат Djinni.
3. Називайте точну цифру. Так простіше. Всім.
4. Добре підготуйтесь перед обговоренням. Не чекайте, що під час розмови у вашій голові з’являться усі вагомі аргументи. Підготуйте їх заздалегідь. Наприклад, яка буде ваша реакція, якщо вам запропонують меншу суму або взагалі відмовлять.
Якщо ви залишились незадоволені від результатів обговорення, обов'язково узгодьте наступний перегляд і що ви повинні до цього часу зробити та навчитись. Чітко окресліть всі вимоги і працюйте над собою.
Якщо все дуже погано, ви можете завжди отримати контроффер і будувати розмову по-іншому. Не знаю, як зараз це працює, але раніше - це було дуже популярно. Але ми не рекомендуємо!
#experience
Ми прекрасно розуміємо, що зараз складна ситуація на ринку і далеко не всім хочеться піднімати це питання. Але якщо ви вже достатньо часу працюєте в компанії і відчуваєте, що вже давно виросли, то можливо наші поради будуть вам в нагоді.
Почнемо з першого питання - коли потрібно говорити про підвищення зарплати?
1. Ви маєте сильне внутрішнє відчуття того, що ви гідні отримувати більше і вважаєте необхідністю, щоб вас підвищили. Ви взяли на себе багато відповідальності, багато чого навчились та зробили для компанії. Не потрібно плутати з банальним "хочу більше грошей". Це бажання має бути підкріплене вашим ростом як спеціаліста.
2. Не менш важливо підібрати правильний час для обговорення. Це може бути успішне завершення проєкту, вирішення важливої проблеми або збільшення робочого навантаження, з яким ви добре справляєтесь (тут важливо не затягувати, щоб не отримати вигорання).
Наступне питання - як підготуватись до розмови?
1. Ви повинні підготувати аргументи на свою користь - чого ви досягли за цей період, чого навчились, за що взяли відповідальність, скільки користі компанії ви принесли. Якщо коротко, нахвалюйте себе, але в міру 😅
2. Проаналізуйте ринок. Поцікавтеся, які зарплати отримують спеціалісти вашого профілю в інших компаніях. Можете використати статистику зарплат Djinni.
3. Називайте точну цифру. Так простіше. Всім.
4. Добре підготуйтесь перед обговоренням. Не чекайте, що під час розмови у вашій голові з’являться усі вагомі аргументи. Підготуйте їх заздалегідь. Наприклад, яка буде ваша реакція, якщо вам запропонують меншу суму або взагалі відмовлять.
Якщо ви залишились незадоволені від результатів обговорення, обов'язково узгодьте наступний перегляд і що ви повинні до цього часу зробити та навчитись. Чітко окресліть всі вимоги і працюйте над собою.
Якщо все дуже погано, ви можете завжди отримати контроффер і будувати розмову по-іншому. Не знаю, як зараз це працює, але раніше - це було дуже популярно. Але ми не рекомендуємо!
#experience
👍10❤3🔥1
Next.js fallback 'blocking' 🧱
На проєкті ми використовуємо Next.js і деплоїмо застосунок на Vercel. І в певний момент проєкт перестав деплоїтись на сервер (при тому, що build проходив без проблем). Жодних деталей помилки ми знайти не могли, просто
На сайті в нас є досить довгий (дуууже довгий) список сторінок, що генеруються статично. Після довгої боротьби з помилкою, ми врешті спробували ще раз, але обмежили кількість цих сторінок, і, на щастя, це спрацювало! Тепер потрібно рішення, яке збереже ті ж сторінки, але дозволить деплоїти проєкт.
#experience
На проєкті ми використовуємо Next.js і деплоїмо застосунок на Vercel. І в певний момент проєкт перестав деплоїтись на сервер (при тому, що build проходив без проблем). Жодних деталей помилки ми знайти не могли, просто
unknown error. Найвеселіше те, що спроба збілдити і задеплоїти старіші коміти теж викидала помилку.На сайті в нас є досить довгий (дуууже довгий) список сторінок, що генеруються статично. Після довгої боротьби з помилкою, ми врешті спробували ще раз, але обмежили кількість цих сторінок, і, на щастя, це спрацювало! Тепер потрібно рішення, яке збереже ті ж сторінки, але дозволить деплоїти проєкт.
getStaticPaths дозволяє повернути параметр fallback, який може бути false, true або "blocking". Якщо ви повернете false, тоді всі шляхи, які не повернулись з цієї функції будуть повертати 404. А от якщо повернути "blocking", то Next.js спробує зарендерити цю сторінку при першому запиті, і у разі успіху, збереже її у кеші. Отож, тепер ми генеруємо невелику кількість сторінок, проте, як тільки хтось спробує відкрити сторінку, яка ще не згенерована, але дані для якої існують, Next.js одразу створить все необхідне.#experience
👍14❤2🔥2
Короткий відгук про Ghostty 👻
В цілому я задоволений і, швидше за все, буду використовувати його як основний (до цього я використовував WezTerm).
Він дійсно виглядає доволі шустрим, але що мені сподобалося ще більше — це те, що з ним зручно працювати і без жодних налаштувань. Все ж я дещо змінив і вклався в 9 рядків:
#experience
В цілому я задоволений і, швидше за все, буду використовувати його як основний (до цього я використовував WezTerm).
Він дійсно виглядає доволі шустрим, але що мені сподобалося ще більше — це те, що з ним зручно працювати і без жодних налаштувань. Все ж я дещо змінив і вклався в 9 рядків:
theme=catppuccin-mocha
font-family=Monaspace Krypton Var
font-variation=wght=300
window-padding-x=0
title=" "
macos-titlebar-proxy-icon=hidden
cursor-style-blink=false
shell-integration-features=no-cursor
keybind=cmd+t=unbind
#experience
❤4🔥2👍1
Nix ⚙️
Минулого року ми відкрили для себе Nix. Спочатку було важко зрозуміти, що це таке, але воно виглядало досить незвично, тож ми вирішили дослідити, як це можна використати.
Nix — це інструмент для менеджменту пакетів і налаштувань. У нашому розумінні це ціла екосистема, адже тут є своя мова, застосунок та навіть операційна система. Якоюсь мірою це схоже на npm та package.json у JavaScript чи venv у Python.
Щодо NixOS — це операційна система на основі Linux, створена на базі менеджера пакетів Nix. Фактично вся система може бути налаштована та (головне!) відтворена за допомогою певного набору конфігураційних файлів.
Ми поки що тільки пробуємо його використовувати — наразі встановили лише на Raspberry Pi. У планах також налаштувати систему на macOS за допомогою nix-darwin. Має вийти доволі цікаво, адже тоді за допомогою кількох файлів можна буде відтворити всі налаштування на іншому комп'ютері.
Можливо, хтось із вас уже використовував Nix? Діліться своїм досвідом! 💛
👉 Відкрити посилання
#experience
Минулого року ми відкрили для себе Nix. Спочатку було важко зрозуміти, що це таке, але воно виглядало досить незвично, тож ми вирішили дослідити, як це можна використати.
Nix — це інструмент для менеджменту пакетів і налаштувань. У нашому розумінні це ціла екосистема, адже тут є своя мова, застосунок та навіть операційна система. Якоюсь мірою це схоже на npm та package.json у JavaScript чи venv у Python.
Щодо NixOS — це операційна система на основі Linux, створена на базі менеджера пакетів Nix. Фактично вся система може бути налаштована та (головне!) відтворена за допомогою певного набору конфігураційних файлів.
Ми поки що тільки пробуємо його використовувати — наразі встановили лише на Raspberry Pi. У планах також налаштувати систему на macOS за допомогою nix-darwin. Має вийти доволі цікаво, адже тоді за допомогою кількох файлів можна буде відтворити всі налаштування на іншому комп'ютері.
Можливо, хтось із вас уже використовував Nix? Діліться своїм досвідом! 💛
👉 Відкрити посилання
#experience
👍7🔥3❤1😁1
WebP to PNG 🥴
У нашому проєкті виникла потреба генерувати PDF-файли. Для цього ми використовуємо бібліотеку react-pdf - інструмент для створення PDF. Працювати над таким типом завдань — це ще той квест, тому краще оминайте такі задачі.
Нам потрібно вставляти динамічні зображення (на даний момент підтримуємо лише JPG, PNG та WebP). Ми розчарувалися, коли виявилося, що PDF не підтримує формат WebP, а обробка таких зображень була надзвичайно необхідною.
Тому ми обрали, мабуть, найпростішу та найшвидшу стратегію — відмалювати WebP-зображення на canvas і отримати з нього PNG. Виглядає код приблизно так:
Тут, до речі, можете побачити приклад використання Promise.withResolvers, про який ми розповідали раніше.
#experience
У нашому проєкті виникла потреба генерувати PDF-файли. Для цього ми використовуємо бібліотеку react-pdf - інструмент для створення PDF. Працювати над таким типом завдань — це ще той квест, тому краще оминайте такі задачі.
Нам потрібно вставляти динамічні зображення (на даний момент підтримуємо лише JPG, PNG та WebP). Ми розчарувалися, коли виявилося, що PDF не підтримує формат WebP, а обробка таких зображень була надзвичайно необхідною.
Тому ми обрали, мабуть, найпростішу та найшвидшу стратегію — відмалювати WebP-зображення на canvas і отримати з нього PNG. Виглядає код приблизно так:
function toPNGUsingCavas(src: string) {
const image = new Image()
const { promise, resolve, reject } = Promise.withResolvers<string>()
image.onload = function () {
const canvas = document.createElement('canvas')
canvas.width = image.naturalWidth
canvas.height = image.naturalHeight
const context = canvas.getContext('2d')
if (!context) {
reject(new Error('Could not get canvas context'))
} else {
context.drawImage(image, 0, 0)
resolve(canvas.toDataURL('image/png'))
}
}
image.onerror = reject
image.src = src
return promise
}
Тут, до речі, можете побачити приклад використання Promise.withResolvers, про який ми розповідали раніше.
#experience
👍17🔥2❤1
"Неофіційні" правила в команді 👀
Ви напевно вже чули, що ми понад два роки працюємо над стартапом. За цей час наша команда значно виросла (спочатку працювали лише вдвох, а тепер нас уже 7 розробників із різних країн і часових зон). Разом із цим стало трохи складніше взаємодіяти у команді: кожен сфокусований на своїх тасках, вони часто переплітаються, виникають одні й ті ж питання, ті ж проблеми. А оскільки внутрішні процеси в нас майже не налаштовані, ми вирішили запровадити кілька "неофіційних" правил, які мають допомогти нам покращити взаємодію.
1. Обговорювати всі питання у спільному dev-чаті, а не в особистих повідомленнях.
Кожен член команди повинен мати доступ до обговорень, щоб за потреби допомогти або знайти потрібну інформацію. Вся важлива комунікація має бути відкритою та доступною для всіх. А ще це допоможе уникнути нескінченних однакових питань про логіку та архітектуру проєкту.
2. Ділити завдання на менші частини.
Оскільки це стартап, таски бувають дуже різними — від "підправити стилі таблички" до "розробити мобільний застосунок". Якщо завдання велике, намагаємось розбити його хоча б на backend і frontend або на окремі модулі. Адже якщо PR містить 100+ змінених файлів, його дуже складно перевірити — це займає купу часу, а якість рев’ю від цього тільки страждає.
3. Перевіряти PR-и колег.
Ми працюємо над великим проєктом, і важливо розуміти, що розробляють інші учасники команди. Якщо немає термінових завдань, намагаємось приділяти час рев’ю чужих PR. Це допоможе підтримувати якість коду, уникати конфліктів та краще розуміти загальний розвиток проєкту.
У нас немає бізнес-аналітика, ПМа, тестувальника і взагалі жодних "зайвих" людей. Так, звучить страшно, але це стартап, шо поробиш 😅 Сподіваємось, ці правила допоможуть нам трохи врятувати ситуацію.
Розкажіть, які "неофіційні" правила є у вас у команді? 💛
#experience
Ви напевно вже чули, що ми понад два роки працюємо над стартапом. За цей час наша команда значно виросла (спочатку працювали лише вдвох, а тепер нас уже 7 розробників із різних країн і часових зон). Разом із цим стало трохи складніше взаємодіяти у команді: кожен сфокусований на своїх тасках, вони часто переплітаються, виникають одні й ті ж питання, ті ж проблеми. А оскільки внутрішні процеси в нас майже не налаштовані, ми вирішили запровадити кілька "неофіційних" правил, які мають допомогти нам покращити взаємодію.
1. Обговорювати всі питання у спільному dev-чаті, а не в особистих повідомленнях.
Кожен член команди повинен мати доступ до обговорень, щоб за потреби допомогти або знайти потрібну інформацію. Вся важлива комунікація має бути відкритою та доступною для всіх. А ще це допоможе уникнути нескінченних однакових питань про логіку та архітектуру проєкту.
2. Ділити завдання на менші частини.
Оскільки це стартап, таски бувають дуже різними — від "підправити стилі таблички" до "розробити мобільний застосунок". Якщо завдання велике, намагаємось розбити його хоча б на backend і frontend або на окремі модулі. Адже якщо PR містить 100+ змінених файлів, його дуже складно перевірити — це займає купу часу, а якість рев’ю від цього тільки страждає.
3. Перевіряти PR-и колег.
Ми працюємо над великим проєктом, і важливо розуміти, що розробляють інші учасники команди. Якщо немає термінових завдань, намагаємось приділяти час рев’ю чужих PR. Це допоможе підтримувати якість коду, уникати конфліктів та краще розуміти загальний розвиток проєкту.
У нас немає бізнес-аналітика, ПМа, тестувальника і взагалі жодних "зайвих" людей. Так, звучить страшно, але це стартап, шо поробиш 😅 Сподіваємось, ці правила допоможуть нам трохи врятувати ситуацію.
Розкажіть, які "неофіційні" правила є у вас у команді? 💛
#experience
❤10👍5🔥3
Aerospace Script 🪟
Window manager — це програма, яка керує вікнами ваших застосунків: їхнім розташуванням і розміром.
Серед таких програм (або схожих до них) можна виділити:
- Linux: i3, Hyprland;
- MacOS: Magnet, Rectangle, Yabai, Amethyst.
Зараз я тестую Aerospace. І в один момент я зрозумів, що мені дечого не вистачає.
#how_to втикати відосіки під час роботи, якщо у вас один монітор: двічі натискаєте праву клавішу на відео в YouTube та натискаєте Picture in Picture.
Проблема в тому, що через використання WM я розділяю вікна на різні воркспейси, а вікно Picture in Picture залишається тільки на одному з них. Оскільки fixed-режиму для вікон немає, єдиний варіант — змусити вікно автоматично переміщуватися під час зміни воркспейсу.
Ось як це зробив я:
#experience
Window manager — це програма, яка керує вікнами ваших застосунків: їхнім розташуванням і розміром.
Серед таких програм (або схожих до них) можна виділити:
- Linux: i3, Hyprland;
- MacOS: Magnet, Rectangle, Yabai, Amethyst.
Зараз я тестую Aerospace. І в один момент я зрозумів, що мені дечого не вистачає.
#how_to втикати відосіки під час роботи, якщо у вас один монітор: двічі натискаєте праву клавішу на відео в YouTube та натискаєте Picture in Picture.
Проблема в тому, що через використання WM я розділяю вікна на різні воркспейси, а вікно Picture in Picture залишається тільки на одному з них. Оскільки fixed-режиму для вікон немає, єдиний варіант — змусити вікно автоматично переміщуватися під час зміни воркспейсу.
Ось як це зробив я:
exec-on-workspace-change = [
'/bin/bash/', '-c',
'aerospace move-node-to-workspace --window-id $(aerospace list-windows --monitor focused --app-bundle-id com.google.Chrome --format "%{window-id} %{window-title}" | awk "\$0 ~ /Picture in Picture/ {print \$1}") $AEROSPACE_FOCUSED_WORKSPACE'
]
#experience
❤2👍2🔥2
Я тепер Vibe coder 💅
Нещодавно @Yurets7777 розповідав у чаті, що замовник хоче почути пояснення від тих, хто не використовує Cursor: як вони планують залишатися такими ж продуктивними, як ті, хто працює з ним?
ШІ настільки швидко розвивається, що важливо навчитися ефективно ним користуватися. Тож я вирішив спробувати й встановив Cursor, зараз тестую Free Trial.
Перше, що варто відзначити: Cursor побудований на базі VS Code. Тому, якщо ви працювали у VS Code, звикнути до нього буде легко. Передбачено імпорт налаштувань, хоча у мене виникли труднощі з перенесенням профілів. У VS Code я використовував різні конфігурації для різних проєктів, але перенести їх у Cursor не вдалося. Я спробував вручну відтворити налаштування, але зіткнувся з іншою проблемою: при відкритті не-default профілю всі параметри постійно скидалися. Загалом, останнім часом я працював у Neovim, тому перехід дався непросто.
Ще не до кінця розібрався з робочим процесом у Cursor. Тут є кілька режимів (chat, agent…), і підказки буквально вискакують на кожному кроці, навіть коли їх не просиш. Поки що ретельно перевіряю кожну зміну, яку він пропонує, і досить часто доводиться вказувати, що виправити. Також не до кінця зрозумів, як краще з ним працювати: давати одразу велику задачу й доопрацьовувати її частинами чи самому продумувати загальну схему, а потім просити імплементувати окремі шматки?
Загалом, враження поки змішані. Для мене ШІ — це інструмент, яким можна користуватися, але точно не той, що зробить усю роботу за мене. Водночас здається, що Cursor (разом із Windsurf, Trae та іншими) задає правильний напрямок. Vibe coder-ом я поки точно бути не хочу, але намагаюся знайти оптимальний спосіб інтеграції ШІ у свій робочий процес.
Подивимося, як ця технологія розвиватиметься далі.
А ви вже тестували щось подібне? Діліться враженнями! 💛
#experience
Нещодавно @Yurets7777 розповідав у чаті, що замовник хоче почути пояснення від тих, хто не використовує Cursor: як вони планують залишатися такими ж продуктивними, як ті, хто працює з ним?
ШІ настільки швидко розвивається, що важливо навчитися ефективно ним користуватися. Тож я вирішив спробувати й встановив Cursor, зараз тестую Free Trial.
Перше, що варто відзначити: Cursor побудований на базі VS Code. Тому, якщо ви працювали у VS Code, звикнути до нього буде легко. Передбачено імпорт налаштувань, хоча у мене виникли труднощі з перенесенням профілів. У VS Code я використовував різні конфігурації для різних проєктів, але перенести їх у Cursor не вдалося. Я спробував вручну відтворити налаштування, але зіткнувся з іншою проблемою: при відкритті не-default профілю всі параметри постійно скидалися. Загалом, останнім часом я працював у Neovim, тому перехід дався непросто.
Ще не до кінця розібрався з робочим процесом у Cursor. Тут є кілька режимів (chat, agent…), і підказки буквально вискакують на кожному кроці, навіть коли їх не просиш. Поки що ретельно перевіряю кожну зміну, яку він пропонує, і досить часто доводиться вказувати, що виправити. Також не до кінця зрозумів, як краще з ним працювати: давати одразу велику задачу й доопрацьовувати її частинами чи самому продумувати загальну схему, а потім просити імплементувати окремі шматки?
Загалом, враження поки змішані. Для мене ШІ — це інструмент, яким можна користуватися, але точно не той, що зробить усю роботу за мене. Водночас здається, що Cursor (разом із Windsurf, Trae та іншими) задає правильний напрямок. Vibe coder-ом я поки точно бути не хочу, але намагаюся знайти оптимальний спосіб інтеграції ШІ у свій робочий процес.
Подивимося, як ця технологія розвиватиметься далі.
А ви вже тестували щось подібне? Діліться враженнями! 💛
#experience
👍9🔥5😢2💅1
NixOS config 🔩
Раніше ми вже трохи розповідали, що таке Nix.
Мені було цікаво попрацювати з цим, і, нарешті, знайшлось трохи часу. Щоб не мучити Raspberry (бо на ньому зараз Pi-hole), я створив віртуалку і тестую все на ній.
Поки що тільки маленька перемога - воно хоча б працює. Прості налаштування вже наче освоїв, тому далі два важливих кроки:
1. Придумати, як нормально поставити .config/. Швидше за все, треба буде просто клонувати git-репозиторій, але потрібно ще розібратись.
2. Налаштувати GUI. Хочу спробувати i3 - чув про нього багато, але жодного разу не користувався.
Після цього думаю буде достатньо практики, щоб перенести це і на основний компʼютер. Загалом, поточний прогрес можна глянути тут. Багато натхнення і "позиченого" коду від Mitchell Hashimoto.
А якщо комусь цікаво або хтось уже мав справу з Nix - буду радий обговорити ⬇️
#experience
Раніше ми вже трохи розповідали, що таке Nix.
Мені було цікаво попрацювати з цим, і, нарешті, знайшлось трохи часу. Щоб не мучити Raspberry (бо на ньому зараз Pi-hole), я створив віртуалку і тестую все на ній.
Поки що тільки маленька перемога - воно хоча б працює. Прості налаштування вже наче освоїв, тому далі два важливих кроки:
1. Придумати, як нормально поставити .config/. Швидше за все, треба буде просто клонувати git-репозиторій, але потрібно ще розібратись.
2. Налаштувати GUI. Хочу спробувати i3 - чув про нього багато, але жодного разу не користувався.
Після цього думаю буде достатньо практики, щоб перенести це і на основний компʼютер. Загалом, поточний прогрес можна глянути тут. Багато натхнення і "позиченого" коду від Mitchell Hashimoto.
А якщо комусь цікаво або хтось уже мав справу з Nix - буду радий обговорити ⬇️
#experience
👍6🔥2😁1
Як передати проєкт? 🎁
Ми завершуємо участь у поточному проєкті, однак його розробка триває, тож ми передали всі справи новій команді. Процес handover розбився на кілька етапів:
1. Завершення поточних задач.
На момент передачі у нас ще були активні таски та баги. Щоб не перекидати це на інших, ми доробили все, що могли — й лише після цього передали проєкт.
2. Передача доступів.
Тут усе просто: ми надали повні доступи до всіх сервісів і впевнились, що нові розробники змогли ними скористатися.
3. Коротка документація.
Чому коротка? Бо в нас її майже не було 🙂 Ми описали ключові речі: які фреймворки, бібліотеки та методи стилізації використовуються, як працюємо зі стейтом, формами, базою даних. Додали інформацію про інфраструктуру: де сервери, як білдиться проєкт, який сервіс відповідає за авторизацію тощо.
Окрему увагу приділили відомим багам, ризикам, технічному боргу, а також запропонували кілька ідей для покращення. Чесно кажучи, знаючи, у що це все виросте — ми б будували проєкт зовсім інакше 😅
4. Handover session.
На окремому дзвінку обговорили ключові частини проєкту та пояснили, на що звертати увагу. Зокрема, зараз у застосунку є waitlist, який частково потрібно обробляти вручну.
А ще це була просто тепла розмова з командою, яка підхоплює розробку. Ми раді завершити участь на хорошій ноті 💛
#experience
Ми завершуємо участь у поточному проєкті, однак його розробка триває, тож ми передали всі справи новій команді. Процес handover розбився на кілька етапів:
1. Завершення поточних задач.
На момент передачі у нас ще були активні таски та баги. Щоб не перекидати це на інших, ми доробили все, що могли — й лише після цього передали проєкт.
2. Передача доступів.
Тут усе просто: ми надали повні доступи до всіх сервісів і впевнились, що нові розробники змогли ними скористатися.
3. Коротка документація.
Чому коротка? Бо в нас її майже не було 🙂 Ми описали ключові речі: які фреймворки, бібліотеки та методи стилізації використовуються, як працюємо зі стейтом, формами, базою даних. Додали інформацію про інфраструктуру: де сервери, як білдиться проєкт, який сервіс відповідає за авторизацію тощо.
Окрему увагу приділили відомим багам, ризикам, технічному боргу, а також запропонували кілька ідей для покращення. Чесно кажучи, знаючи, у що це все виросте — ми б будували проєкт зовсім інакше 😅
4. Handover session.
На окремому дзвінку обговорили ключові частини проєкту та пояснили, на що звертати увагу. Зокрема, зараз у застосунку є waitlist, який частково потрібно обробляти вручну.
А ще це була просто тепла розмова з командою, яка підхоплює розробку. Ми раді завершити участь на хорошій ноті 💛
#experience
👍12🔥5❤1