Full Stack Developer в Tractor
  • А в ЄС взагалі є хороші(i.e. високі) зарплати?

    питання було:

    Реально всі нормальні зп, які будуть відчутно вищими ніж те, що ми отримуємо в Україні, це лише США? Чи на хорошу вакансію в linkedin не пишуть, а це все відбувається по знайомству-рекомендації?

    відповідь: купи собі глобус...

    якщо не знаєш відповіді — просто промовчи.

  • Рейтинг шкіл за результатами ЗНО-2021

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

  • «Ответственность должна быть на инженерах, которые пишут код». Почему в People.ai отказались от QA-команды и что это дало

    Андрій дуже хороший інженер і лідер. Явно є глибоке розуміння особливостей роботи і вміння доносити хороші ідеї до людей. Респект

  • Уряд схвалив проєкт закону щодо посилення захисту працівників. Що це означає для ІТ ФОПів

    в Україні є свої бізнес традиції, одна з них — всі бізнеси мають працювати по сірому або по чорному. Кожні ~ 6 місяців — 1 рік в кілька етапів відбувається атака на всі білі бізнеси, які ± заробляють якісь гроші. В ЗМІ починають розказувати які несправедливі там умови, і як мало вони платять податків і як потрібно відрегулювати і навести ’справедливість’. Ключові тези в ЗМІ: ’неврегульовані’, ’бюджет недоотримує’, ’будівництво доріг’, ’зарплати вчителям’. Притому всі ЗМІ роблять це в один час і повторюють одні і ті ж тези чим створюють ілюзію масової підтримки. Нові умови завжи висуваються так що бізнесу можна або закриватись або перейти на сірі схеми. Потім з залежності від домовленостей, або дають задню і повертаються через пів року або створюють і продають нову посаду/орган, яка буде ’регулювати’ нові правила. Якийсь кац назвав цей паттерн ’Наїзд-відкат-від’їзд’ по якому силовики і законотворці ’спілкуються’ з бізнесом і до нас підходить.

  • О некомпетентности в ІТ, или Как сеньора Сеню хинкали погубили

    архітектор який розуміє що в нього в проект спроектований на 3 з 10 не буде читати книги. Як тільки він підніме кваліфікацію оцінка проекту знизиться до 1 з 10 і буде геть сумно.

  • Варианты распределенных сценариев

    нетипізовані вказівники callback* це жесть, я уявляю якщо розвести по 2 командах, і використовувати різні версії + параметри змінювати. Це неможливо підтримувати.

  • 5 правил менеджмента, о которых не пишут в книгах

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

  • От простого к сложному: путь от монолита к микросервисам

    Для цього одна людина має знати, як оті усі модулі працюють. А потім — мержи та пулл реквести та код ревью. І треш затягнеться на тиждень на рівному місці.

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

    В мікросервісах всі умовні 50% делегуються відразу іншій команді, в якій свої пріорітети, і в найпростішому випадку в Вас задача сформулювати вимоги, і домовитись з іншою командою і чекати. В складніший — гра в пінгпонг і поламаний телефон.

  • От простого к сложному: путь от монолита к микросервисам

    А ще є такий цікавий процес, як зміна інтерфейсу. В моноліті, зазвичай, здається, інтерфейси не версіоновані.

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

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

    Це може зробити одна людина, зробивши зміни в усі модулі. Запустивши білд, тести і почитавши код навіть одна людина зможе це зробити.
    З мікросервісами ви маєте іншу команду, код який не знаєте і набір інтерфейсів. Блекбокс. Якщо хочете деталей — пишети листи.

  • От простого к сложному: путь от монолита к микросервисам

    в мене моноліт, і тому все консистентно. всі модулі робочі і працюють. Навантаження на систему я знімаю лоад балансером. Де я зекономлю на мікросервісах? 150 МБ жорсткого диску ? ) Модуль навіть не завантажується в пам’ять якщо його не використовувати. Не говорячи про CPU. Виходить я трохи місця на жорсткому диску зекономив?

  • От простого к сложному: путь от монолита к микросервисам

    Має значення не розмір коду, а оперативка та проц. В моноліті купа модулів завантажені, кожний тримає свій стан.

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

  • От простого к сложному: путь от монолита к микросервисам

    в моноліті усім командам треба домовлятись про зміни
    Бо моноліт може не влазити в один бокс,

    особливо ці два аргументи про-мс мене радують. Як можна не розуміти що при мс домовлятись потрібно набагато більше і ’якісніше’, з меншим набором інструментів і з набагато більшою вірогідністю щось може піти не так.

    а не влазити в один бокс... не знаю в скількох % проектів розмір артифактів dll має значення. Це мають бути гігабайти dll. Ніхто не згадує про кеш і лоад балансери.

  • От простого к сложному: путь от монолита к микросервисам

    погано те що дуже прості сценарії перестають бути такими з мікросервісами. Тут приводили статтю dwmkerr.com/...​oservice-madness-in-2018
    Але простіше я вже говорив: 2 менші системи в загальному випадку складніше ніж одна для розробки і деплойменту. При тому значно складніше. Прості сценарії: невідповідність в DTO, пейджинація, невідповідність реквайрментів і коду. В монолітах таких проблем або немає за дизайном або вони вирішуються на етапі компіляції.

    Підтримали: Aliaksandr Valialkin, Sergey Lysak
  • От простого к сложному: путь от монолита к микросервисам

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

    Підтримали: Aliaksandr Valialkin, Sergey Lysak
  • От простого к сложному: путь от монолита к микросервисам

    Ви не знаєте точних умов. Суть в тому щоб сказати що краще, 1 солюшен на 20 проектів, на якому є умовний білд + тести, або 2 солюшени по 10 проектів.

  • От простого к сложному: путь от монолита к микросервисам

    можна уявити середній солюшен 20 проектів розбити на 2 по 10, закинути їх в 2 різні репозиторії і поєднати через json/xml. Спочатку це буде один розробник, і не буде складності з комунікацією. В якому випадку буде більше фейлів? Тепер переходимо від одного розробника до команд 5-10. Малюємо варіанти. А тепер уявити що склеювати до купи це все також будуть треті люди, які не знають деталей ні першого ні другого, обмежені в часі, і яким не можна або складно відмовити.

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

    Підтримали: Dmitry Bugay, Aliaksandr Valialkin
  • От простого к сложному: путь от монолита к микросервисам

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

  • От простого к сложному: путь от монолита к микросервисам

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

  • Why Households Need To Earn $300,000 A Year To Live A Middle Class Lifestyle Today

    що він несе? мабуть хворий на голову

  • Ви не програміст, якщо

    я гарантую.

← Сtrl 1... 678910...13 Ctrl →