1) На скільки спрощує найм наявність pet project?
Ну як на мене — радикально спрощує. Інакше єдиним способом дізнатись чи є кандидат програмістом — це виконання тестового.
2) Чи варто викласти код у публічний доступ?
Так, бо без наявності коду саме існування проекту нічого не скаже про те, який ви програміст
3) На скільки враховуються рекомендації із попередньої роботи?
Ну враховуються якщо є, але не будуть ключовими для прийняття рішення
4) Які враження у вас виникають від мого pet project?
Ідея в принципі цікава, але й є що вдосконалювати. Треба спробувати покористуватись.
Бекенд поки пишу. У процесі
Професійний колектив, цікаві люди, цікаві проекти, цікаві замовники
Яким чином?
Ну на робочий проект не можу, NDA, але можу дати посилання на свій pet project з аналогічною концепцією — пишу live chat component для корпоративного сайту потихеньку. Demo можна подивитись тут pragmasoft-ua.github.io/humane-chat-frontend а сам проект тут github.com/...t-ua/humane-chat-frontend
Дока ще не дописана, але в принципі компонент можна буде додати одним скриптом до будь якої сторінки. Там у демо також є приклад кастомізації кольору.
Компоненти самі використовують API, користувачі просто додають їх до своїх сторінок / сайтів та якщо треба кастомізують їх вигляд під загальний дизайн сайту. Тобто інтеграція не потребує роботи програміста, тільки верстальника
Я цілком згоден, так і є. Я ж і написав, що треба тільки починати дивитись, щоб не бути як ті генерали, що завжди готуються до минулої війни.
Більше це мабуть дійсно не джунів стосується.
Але якщо цікаво наведу реальний приклад де використання lit навіть зараз є цілком виправданим. Один з наших замовників має платне API, доступ до якого продає як франшизу партнерам та також використовує сам з динамічного UI. Партнери можуть використовувати API зі свого кастомного UI, але зазвичай у них немає своїх розробників, щоб зробити це фахово. Тому ми надаємо готовий UI який можна кастомізувати і додати до статичного сайту / CMS. Раніше таке зазвичай робилось через iframe, але зараз набагато краще робити це саме через веб компоненти.
Ну тут багато аспектів, але якщо коротко то різниця у заміні синхронних бібліотек асинхронними та підтримка конкурентного рендерінгу. На заміну redux state який є синхронним за дизайном, і всі асинхронні додатки до нього як thunk або saga тільки вносять зайве ускладнення, до того ж ще будуть потребувати переходу на useSyncExternalStore з 18 версії, використовується apollo або react query які за дизайном вже є асинхронними. Те ж стосується і Suspense, нові роутери з асинхронними завантажувачами та кешем (react router v6.4 або react location router).
Окрім цього нова архітектура — це реюзабельні хуки, композиція хуків та бібліотеки хуків, headless компоненти, esm модулі і сучасні esm бандлери (vite, new parcel, swc/esbuild ), тотальний typescript, ssr/ssg
вже друга версія, а я за нього тільки почув...
Ну то може проблема не в ньому а в вас? І також якщо не секрет, яка була версія React коли ви вперше про нього почули ? ;)
Якщо серйозно, то веб компоненти — то стандартне API браузера, і його потрібно вивчати не замість, а на додаток до фреймворків, якими ви користуєтесь. Наприклад, intersection observer чи workers це також стандартні API, і їх бажано знати фронтендеру незалежно від того, на якому фреймворку він пише. Так само і з веб компонентами, тим більше що там аж чотири API.
Веб компоненти можна писати взагалі без фреймворків, але з фреймворками дещо зручніше, і lit мабуть найзручніший і найпопулярніший, але є й інші. Stencil від Ionic наприклад, або preact також може.
А то джун піде вивчить й на цьому закінчить кар’єру
То буде якийсь неправильний джун, бо якщо він сподівається вивчити один фреймворк на всю свою кар’єру — він швидко її закінчить незалежно від того, на який фреймворк він зробить ставку. Джунам треба вчитися перш за все програмувати і вивчати веб як платформу, бо браузер зараз то вже майже окрема операційна система, а не якісь конкретні фреймворки.
Тут ще можу додати, що lit — це інструмент для написання саме компонентів, а не застосунків. Це важливо, бо застосунки включають ще багато чого — взаємодію з сервером, routing, state, ssr/ssg та інше.
Тому, якщо ви плануєте писати саме single page frontend застосунки, то react/preact мабуть на зараз це самий правильний вибір, бо має найбільший вибір доступних бібліотек та інтеграцій достатньої якості для широкого кола потреб. Треба тільки впевнитися, що ви використовуєте найбільш сучасну react архітектуру, бо на курсах зараз дають досить застарілу архітектуру і джунам важко буває її відрізнити.
Але якщо це не single page застосунок то шанси на те, що lit буде правильним рішенням зростають.
Зараз для lit немає серйозної інфраструктури саме для написання застосунків, але треба цікавитись їм вже зараз, аби не прогавити час, коли всі на ньому вже пишуть, а ви «тільки за нього почули». Або починати писати самому цю інфраструктуру вже зараз :)
З іншого боку все більше ui бібліотек нового покоління пишуться як framework agnostic core до якого потім додаються адаптери до різних фреймворків, перш за все React. Той же Ionic або Fluent наприклад.
Я вважаю що вартий, бо інакше б не писав тут про нього. По перше, веб компоненти — це стандарт, який вже добре підтримується сучасними браузерами. Це має першорядний вплив на розмір фреймворку (а це швидкість завантаження) і швидкість рендерінгу. На відміну від пропрієтарних фреймворків, базовані на стандартах мають шанс жити значно довше, бо стандарти підтримують стабільний інтерфейс. Якщо ви подивитесь на нову генерацію компонентних бібліотек, то зможете помітити, що їх зараз пишуть як веб компоненти, а потім обертають у адаптери для реакту та інших фреймворків.
Хлопці, шо я вам скажу, треба вже починати дивитись у бік веб компонентів. Бо боротьбу між vue react та angular може виграти lit
А що планується у наступних частинах? Structured concurrency? Locks?
Из Харькова, сейчас в Виннице, такой активности пока не заметил. Сам жду, что в руководстве страны поймут, что восстановить экономику не менее важно для победы, чем убивать врагов, по крайней мере с расчетом на длительное противостояние.
+ на IBAN
Або не перетворюється, якщо є помилки компіляції TS.. Для цього TS взагалі і існує
Може PWA розглянути як платформу? Чи там є якийсь функціонал, для якого PWA недостатньо?
> чи варто створювати власну аутсорс-компанію, чи уже запізно, тобто ринок перенасичений)?
Варто, не перенасичений
> починати самому чи шукати однодумців (кофаундерів)?
Безпечніше самому
> де шукати оцього омріяного «нормального» першого замовника, upwork чи звернутись за послугами якихось сейлзів?
Усі можливі канали, включаючи ті, що ви назвали. Якщо ви 10 років працювали у IT, у вас повинно бути не менше десятка контактів замовників з минулих проєктів. Спитайте їх, може їм потрібні ваші послуги безпосередньо, або якщо ні, може вони вас комусь порекомендують.
Взагалі, ринок зараз такий, що вам важче буде знайти співробітників, ніж замовників.
> розглядати реєстрацію компанії десь за кордоном, чи на першу пору залишатись ФОП допоки обороти не перевищують ліміти?
ФОП
Цікаво що мінцифри з цього приводу думає? Чи є у них якась стратегія на цей рахунок? Чи як завжди на якусь допомогу від влади годі й розраховувати? Може це якось спонукає нарешті владу переглянути умови тимчасового переміщення за кордон IT спеціалістів?