З третього походу в ужонд у вересні дали песель, хоча також до 24 лютого виїхав

Ніколи не працював з 1с, тому в мене нубське питання. Якщо зробити відкриту сумісну з 1с мову програмування, то наскільки це вирішить питання? Чи там сама платформа багато чого реалізовує і мова лише другорядна проблема?

Щось по типу GNU Octave як заміна Matlab

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

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

Також є історія знайомої, яка була в Угорщині до початку війни, потім поїхала до Польщі і їй дали песель без проблем.

Тому, мені здається, найкраща стратегія для вас це ходити в різні ужонди поки не дадуть песель 😃

Користуюся 4 місяць з задоволенням. Вже навіть не зручно і не звично, коли встановлюєш, якийсь інструмент яки fig ще не підтримує

Підтримую. Користувався обома інструментами і обоє роблять свою роботу відмінно, єдине що змусило пересісти з shottr на cleanshot, це постійні рандомні «вильоти» з програми.

Для оформлення на роботу через портал Дія сформував довідку про місце проживання. Отримав ковід сертифікат через портал. Декілька раз підписував документи Дія Підписом. На Новій Пошті показував паспорт з додатку Дія, щоб забрати прсилку. В Борисполі проходив контроль з паспортом у Дії

Потрібен зчитувач RFID. Якщо з телефону плануєш зчитувати, то гули в сторону «python kivy rfid». Для прикладу, ось, здається, схожий проєкт: github.com/tehpug/RFAttendance

А що ви маєте на увазі під ID-карткою? Пластиковий паспорт? Чи щось інше?

Для Financial Time: «Ukraine war» → «Russian invasion of Ukraine»

Змахує на якусь заказушну статтю від російського ІПСО: лише одна згадка про Росію, жодної про Путіна, 7 раз згадали Україну, Європа винна погана, бо виділяє менше коштів на сталий розвиток.

Всі й без Гейтса знають, що війна це дорого і що зараз Європі не до фінансування сталого розвитку. Але що на іншому боці, якщо кинути цю війну напризволяще і піти займатися голодом в Африці й проблемами зміни клімату? — більше війни, більше смертей, більше голоду.

archive.today/wrm3b

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

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

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

Літкод — то якщо у FAANG мітиш, в Україні не бачив співбесід з ним, та й маю відчуття, що літкод в перспективі замінять і там на якісь загальні system design інтерв’ю.

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

Тут питання спірне і не все треба сприймати як чітке правило, але бачу, що в бекенд розробці склався консенсус, як ділити логіку для типового проєкту:

• Рівень презентації — view в якому немає ніякої бізнес-логіки, окрім як розпарcити дані та передати їх у сервіс, також серіалізувати відповідь сервісу на вихід. Так зможете для однієї і тієї ж логіки додати різні інтерфейси/представлення: Rest, JSON API, GRPC, HTML або змінити формат відповіді, не змінюючи самої бізнес-логіки.
• Рівень бізнес-логіки/сервісний рівень/доменний рівень — тут живе ваша бізнес-логіка, валідації і запити в інші сервіси. Треба старатися, щоб цей рівень взагалі не залежав від view — не було роботи з request об’єктом, щоб можна було викликати в якомусь місці, де цього request немає. Для прикладу, щоб можна було викликати метод з бізнес-логікою в Celery задачі і в view моделі одночасно
• Рівень роботи з базою даних — на цьому рівні живуть невеликі функції для роботи з БД: щось створити у базі, щось видалити, щось оновити. Для Django не дуже поширена практика виділяти цей рівень, але я особисто робив би і його. Які переваги виділяти цей рівень: твій сервісний рівень не вдається до деталей як працювати з базою (легше читати), легше замінити сховище для якоїсь з моделей (для прикладу, якісь гарячі моделі вирішили перемістити в redis)

Гарно про такий підхід описано у Django Styleguide

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

Так-так, і особливо так, щоб спілкування між цими апками було мінімальним або лише через API application/bussines рівня — ніяких SQL JOIN моделей з двох апок. Чому так? щоб легше було виносити в якісь мікросервіси і тестувати апки незалежно один від одного.

Все менше бачу, щоб починали на Django робити нові проекти і все частіше бачу як беруть FastAPI. Але це не заперечує того факту, що Django популярний фреймворк і багато всього вже написано на ньому і інколи написано не дуже якісно або нашвидкоруч. Якщо вам подобається Django і ви впевнені у своїх силах, то можна спробувати розвивати і продавати себе під гаслом «Наведу лад на вашашому Django проекті: додам типізацію, напишу тести, оптимізую запити, відділю бізнес логіку від роботи з бд, поділю проект по незалежних доменах, та інше». Як на мене, на сталих Django проектах запит, щоб хтось прийшов і поприбирав дуже високий. А вже з гарно написаним і охайним Django проектом працювати не менш комфортно, ніж з FastAPI, де бардак ще не встигли наробити.

Щодо питання «моноліт чи мікросервіси», то я обираю моноліт за замовчуванням і мікросервіси, як еволюційний крок моноліту. Для мікросервісів Django теж ОК варіант — гарно ізольовані Django апки, можуть легко перетворитися в самостійні мікросервіси, тому тут лише питання у власній майстерності

Не знаю чому, але в самого в голові те N спливає, коли кажу кочівник

Прочитав декілька раз і не зрозумів твоєї тези. Робити помилки нормально, особливо коли навчаєшся і нормально ділитися своїми успіхами, а вони у автора є. Чи читає автор книги українською мовою — ми не знаємо. Навіть якщо й не читає, то що це говорить про нього?

Як бекенд розробник я теж не дуже добре розумію різниці. В одних компаніях System Administrator це то й хто віндовс співробітникам налаштовує, в інших це то й хто руками підіймає віртуалки і ставить на них всякі self-hosted штуки типу Jira, Gitlab, а інколи навіть займається релізом продукту, який розробляє компанія. З DevOps ще складніше — частина скаже, що це не професія, а методологія. Інші скажуть що це людина налаштовує Kubernetes і CI/CD (але водночас бачив, як такі люди себе називали system administrator). Інше визначення для DevOps давали, що це люди, які пишуть якийсь код для автоматизації інфраструктури — тільки GitOps, купа скриптів на bash, python. Infrastructure engineer взагалі не знаю хто це і чим від DevOps відрізняється.

В цілому є запит на пояснення цих професій не тільки для рекрутерів. Може напишете про це статтю на DOU?

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

Не боятися, пробувати ходити на співбесіди, підтягувати на те, що не знали на співбесіді й знову ходити на співбесіди