-
Volodymyr Melnyk on IT and software development
Немає про що говорити з архітекторами, що розповідають про мікросервісну архітектуру. Такої просто не існує. А що існує, то це мікросервісна стратегія розгортання.
Про переваги й недоліки мікросервісів написано дуже багато, але все те - дурня, бо фокусується на технічній стороні у той час, як мікросервіси є технічним недо-рішенням соціальної, організаційної, комунікаційної проблеми, що виникає у великих компаніях із тисячами розробників. Задача мікросервісної стратегії розгортання полягає у тому, аби зробити команди максимально автономними в т.ч. такими, що розгортають власні сервіси незалежно від інших, тобто у збільшення пропускної здатності команд та скороченні циклу зворотнього зв'язку за рахунок обмеження коммунікацій між командами.
Я не знаю чи є у компаній типу FAANG вибір, але у Вас точно є вибір не робити так, як робить мега-корпорація, принаймні до тих пір, поки Ви не наблизитеся до тих же розмірів.
#saas #microsaas #case https://www.youtube.com/watch?v=1CDBbEVBtBU
Читать полностью…
Я перечитав велику кількість старої літератури по Smalltalk і знайшов одну помилку, а точніше власне розширення до ООП. Коли Алан Кей писав про обмін повідомленнями, то мова насправді йшла про так зване late binding, тобто можливість підміни реалізації, тобто про поліморфізм. Моє рішення з мейлбоксом (чергою повідомлень до об'єкта) базується на реалізації акторів в Erlang. Це ортогональні властивості, які можуть використовуватися разом чи окремо одна від іншої.
Ще з цікавого:
- Класи не розглядаються як типи об'єктів, а типи об'єктів визначаються за інтерфейсами, не в сенсі Java, а в сенсі сукупності методів об'єктів і їх сигнатур. Тобто мова йде про duck-typing.
- Спадкування від конкретних класів вважається у більшості випадків поганою практикою. Таке спадкування може використовуватися як тактика тимчасового збереження попередньої версії реалізації.
- Більшість прикладів того, що спадкування - це зло, походять з анти-патернів спадкування з класичної літератури по ООП. З самого початку говорилося про те, що спадкування А від Б - це дуже сильне відношення "А є Б". Дуже часто таке рішення трансформується в композицію. Це нормальний процесс об'єктно-орієнтованого аналізу та рефакторингу.
- Загалом ідея ООП дуже сильно зав'язана на повторне використання кода та фреймворкінг. Ідея створення фреймворків буквально є вшитою в ООП. Принцип інверсії залежностей (DIP), а точніше оригінал - принцип інверсії контролю (IoC) - це про створення узагальненого фреймворку, який викликає кастомний код, замість використання бібліотек у коді (від цьго і інверсія контролю). Це вже пізніше DIP набув нової інтерпретації пов'язаної з top-down (низхідним) підходом до розробки.
Шо там по ITRampage?
- Мені так сподобалось працювати з HTML і так не сподобалось писати генератор статичного сайту, що я принаймні тимчасово забив на ідею писати власний генератор сайту чи використовувати вже готовий. Якщо ти володієш HTML - тобі більше нічого не треба!
- Нова версія ITRampage буде представлена створенними вручну HTML сторінками. Публікації будуть виключно англійською.
- Я хочу покращити якість публікацій, вже десь десяток написав, але їх необхідно ще переосмислити, допрацювати, попрацювати над стилем.
- Реліз нового ITRampage відбудеться як тільки в мене буде 10 публікацій якими я повністю буду задоволений.
Прийшла у голову чудова думка як найбільш просто пояснити low coupling та high cohesion. Low cohesion/high coupling - це коли файл/модуль містить багато include/import/require директив, а high cohesion/low coupling - це коли мало.
Читать полностью…
Більшість розробників для власних блогів обирають генератори статичних сайтів, при тому половина інтернет-ресурсів працює на WordPress, який є жахливим. Я обрав WP як тимчасовий варіант і вже жалкую про це, на стільки воно криве, глючне і повільне лайно. Що це говорить про типового власника сайту? Гадаю, що це говорить про погане розуміння того, з чим маєш справу у більшості випадків, а також про те, що швидкість запуску важлива та знову ж про принцип "нікого ще не звільняли через те, що він замовив щось у IBM". Я гадаю, що повернусь найближчим часом до розробки власного генератора статичних сайтів, з WP вже жити не можу.
Читать полностью…
Головна навичка, що відрізняє Senior від Junior розробників
Головна навичка, що відрізняє Senior від Junior розробників – це впевненість у своїх силах Senior розробників.
Досвід та теоретичні знання Senior розробники мають велике значення, але найголовнішим фактором “сеньйорності” я бачу саме впевненість у власних силах. Junior розробники часто просто бояться прийняти рішення, вони відчувають себе недостатньо компетентними аби оцінювати якість власної роботи і тому потребують чужої оцінки. Ця невпевненість породжує параліч. Ця ситуація на стільки типова, що має власну назву – Paralysis by Analysis.
https://itrampage.com/головна-навичка-що-відрізняє-senior-від-junior-ро/
Ваші оцінки – лайно
В ІТ існує декілька непорозумінь з оцінками, а ця публікація покликана їх вирішити.
https://itrampage.com/ваші-оцінки-лайно/
Коли я кажу, що хтось не потрібен…
… то маю на увазі не те, що Вам необхідно неодмінно звільнити QA, DevOPS, PM чи ще когось. Я маю на увазі те, що ці позиції існують аби приховати проблему, а не вирішити її. Такий підхід може достатньо довго працювати і задовільняти Вас. В решті решт хто сказав, що бізнес має існувати вічно? Бізнес має існувати лише допоки є попит на товари чи послуги, які він надає. Якщо Ви плануєте чи вже заробляєте на хайпі, то Вас це не має хвилювати. Закривайте цей таб у браузері.
Якщо ж у Ваших планах побудова чогось довготривалого (> 3 років), то Вас необхідно зрозуміти дві прості речі:
Проблема у Вашому підході до людей.
Ви не маєте бездумно копіювати бізнес-моделі, організаційне структури, технології, тощо.
https://itrampage.com/коли-я-кажу-що-хтось-не-потрібен/
Ваші проєкти – лайно https://itrampage.com/ваші-проєкти-лайно/
До речі, для тих, хто полюбляє читати про лайно я створив нову категорію - https://itrampage.com/category/bs/ Все про лайно тепер буде зібрано у ній.
Підтримайте постік у LinkedIn (це дуже корисно для просування блога) та й додавайтеся у контакти https://www.linkedin.com/feed/update/urn:li:activity:7157738873458982913/
Читать полностью…
Як за допомогою LLM покращити роботу менеджерів на 350% та домогтися виконання проєктів у зазначені терміни та в зазначений бюджет
Наш Український Інстутут Інвазивної Психології та Психодинаміки (УІІПП) ім. Френка Герберта нарешті створив стабільну модель трансляції думок у реальному часі. Великою проблемою була інтерпретація думок, які насправді не є текстом, як може здаватися, а скоріше представлені мішаниною образів. Завдяки набравшим популярність Large Language Model (LLM) ми змогли створити штучну свідомість, яка здатна інтерпретувати усі транслюємі образи у зрозумілий текст. Іншими словами, ми створили штучну свідомість, яка повністю ідентична натуральній та так сама текстуалізує підсвідомість.
Оскільки УІІПП тісно співпрацює з багатьма потужними підприємствами у сфері дослідження ефективних підходів до менеджменту, піддослідними стали менеджери різного рівня. Двадцятьом добровольцям у мізки було вживлено чіпи, які в реальному часі транслювати по бездротовій мережі потік підсвідомого. Сервер, що знаходиться в одній з будівель УІІПП отримував ці дані та транслював їх за допомогою LLM в текстовий формат. У цій публікації ми вирішили поділитися найбільш цікавими фрагментами записаного.
https://itrampage.com/як-за-допомогою-llm-покращити-роботу-мен/
Мій шлях пізнання об’єктноорієнтованого програмування https://itrampage.com/шлях-пізнання-обєктноорієнтованого/
Читать полностью…
Arkhi - головний, tekton - будівельник, столяр, архітектор - головний будівельник.
Зараз в будівництві архітектори не будують, цим займаються інженери, а архітектори лише малюють красиві картинки, навіть не проєктують.
В ІТ ідея архітектури і патернів прийшла з будівництва, особливо відзначилась у цьому книга A Pattern language. Towns. Buildings. Construction. Таке запозичення видає глибоке ставлення до розробки ПЗ як до будівництва, що є помилкою, адже перше і друге не одне й те саме з безлічі причин. Метафори й аналогії корисні аби щось пояснити на знайомому прикладі, але не можуть бути використані для доказів. Крім того, таке порівняння IT з будівництвом видає сильне тяготіння до waterfall.
В 4 з 5 компаніях де я працював архітектором, архітектори були відокремлені від решти команди. Від архітекторів також вимагалося розробляти достатньо детальні артефакти для того, аби команда могла просто закодити те, що там зображено, довго не думала, не з'ясовувала самостійно якісь деталі, не приймаа рішень не узгоджених з бізнесом. Від усього цього віє waterfall'ом, а ще це просто не може так працювати, бо:
1. Неможливо усе передбачити.
2. Є досить тривалий процес із купою учасників, які по ланцюгу передають артефакти одне одному. Це збільшує фактор "зламаного телефону" та/або змушує переробляти роботу за тими, від кого ти отримав вхідні.
3. Архітектори не працюють з існуючим кодом і розуміють його значно гірще за розробників, які самі його не знають, бо писали його давно, а може й не вони.
4. Загалом upfront-архітектура не працює. Живі створіння єволюціонували (виживали завдяки щасливій випадковості) з першопочатково примітивних форм, а не були створені богом.
5. Архітектори - це переважно нав'язана компанією штука. В самих розробників майже ніколи не виникає запиту на архітектуру. Це створює тертя в середині "команди". Крім того, більшість розробників не вивчають артефактів та не вміють їх читати.
6. Компанії тяготіють до використання складних методологій та фреймворків, які ускладнюють усім життя, обслуговуючи неіснуючий запит.
7. Більшість проблем архітектури пов'язані зі структурою внутрішніх комунікацій в компанії, їх якістю, прозорістю, стратегічним плануванням (його відсутністю), дедлайнами та тиском на розробників, enterprise-архітектурою, тощо, а не з самою розробкою.
8. Бізнес використовує архітекторів як буферну зону між собою та розробниками. Коли існує конвейєр, все, між його початком та кінцем - буферна зона. Etnterprise, Solution, Software архітектори, бізнес- та системні аналітики, продукт-, проджект-, делівері-, енжинірінг-, хуїлінг і пізділінг менеджери, овнери, та ще черга з купи тунеядців, які мали б покращити комунікації та процеси, але лише погіршують, спотворюючи першопочатковий сигнал та експоненційно збільшуючи кількість зв'язків.
Процес - це щось не просто явне, що можна спостерігати, але й чітко формалізоване, таке, що має чіткі межі. Проте, зазвичай, коли в компаніях говорять про процеси, то мова йде про bloody mess. На одному з останніх місць роботи я навіть бачив розісланий на всю компанію лист із закликом повідомляти про якісь зайві чи неоптимальні процеси.
Якщо процеси зайві в певних контекстах - їх можна порушувати. В цьому і сенс agile-гнучкості. Правила та політики - це лише документування поведінки за замовчуванням, коли думати та приймати власних рішень не хочеться. Але справа не у цьому. Справа у тому, що компанії навіть не відомі власні процеси.
Процеси ніде не задокументовані, ніде не відстежуються і не виміряються. Такі процеси є процесами лише у сенсі повсякденного вжитку, тобто процес - це лише інше слово для виконання чогось із фокусом на тривалість, про структурованість і системність не йде мови.
- А яєшня вже готова?
- В процесі!
Чому вчить розумних людей досвід роботи на дядю, то це тому, що дядя - дебіл, але навіть коли дебіл з дня у день лупає скеля, то вона врешті-решт піддається, розколюється й сиплеться. Там, де поставала скеля тепер прокладено новий шлях.
В нас ще є і такий канал, який найближчим часом я буду все більш активно вести.
Читать полностью…
Скучили за новими публікаціями в ITRampage? Хочу нагадати, що тут /channel/itfeed01 я публікую найкращі матеріали з усього інтернету по мірі того, як сам їх вивчаю. Бажаєте бути он зе сейм пейдж? - Підписуйтесь.
Читать полностью…
Алан Кей (автор ідеї ООП) пояснював, що ООП - це загалом про обмін повідомленнями. Чим повідомлення відрізняється від виклику функції чи процедури? Тим, що викликом ми вимагаємо виконати щось конкретне, а повідомленням ми про щось повідомляємо та не чекаємо неодмінно на реакцію. Повідомлення не блокують та потребують використання мейл-бокса (черги вхідних повідомлень). Використання мейлбокса робить об'єкти - обробники повідомлень потоко-безпечними, адже повідомлення з черги беруться послідовно одне за одним. Тобто об'єкт працює в лише одному власному треді, а от відправка повідомлень може віжбуватися із багатьох інших потоків.
Я не бачив ООП мов програмування, які б реалізовували такі об'єкти. Усе, що т.з. ООП мови дають - це об'єктну (receiver.method) нотацію, тобто семантику інкапсуляції поведінки та деякого стану. Ви ніколи не бачили справжнього ООП!!!!
Описані вище об'єкти досить важкі, по суті вони відповідають мікросервісам, що розгортаються всередині одного процесса. Якщо в типовій ORM використовується відображення об'єкта на запис (ActiveRecord), то для описаних вище об'єктів такий підхід не має жодного сенсу. Справжні об'єкти повинні мати значно більший час життя та відображатися на таблицю/реляцію, а не на окремий запис/кортеж. Такий спосіб використання об'єктів дозволяє працювати з записами як зі звичаними структурами, підвищує ефективність та швидкість роботи, позбавляє необхідності використовувати паттерн IdentityMap, зменшує кількість звернень до БД (наприклад, на рівні об'єкта-таблиці можна генерувати PK без конфліктів, кешувати, та багато чого іншого).
Почав вивчати Crystal - це такий мікс Ruby, Golang та Erlang/Elixir з приємним синтаксисом, просунутою системою типів, чудовим compile-time метапрограмуванням та продуктивністю дещо кращою за Golang. Дуже раджу звернути на нього свою увагу.
Читать полностью…
Найбільш коштовна та дебільна ідея більшості сучасних UI/UX https://itrampage.com/найбільш-коштовна-та-дебільна-ідея-бі/
Читать полностью…
Ще один фактор гівнокода
В одній з компаній CEO мав звичку спілкуватися з розробниками, намагаючись прикинутися не аби яким експертом в ІТ і посилаючись на те, що першу версію системи він розробив самостійно (що не правда) та на те, що його батько працює якимось профессором у Утрехті. Під час однієї з таких розмов я розповів йому, що код проєкта – лайно і що ми маємо усе переписати з нуля, заново зібравши вимоги, оскільки вони не очевидні з наявного коду та оскільки ~70% коду є мертвим, як і більшість функціональності проєкта. ....
https://itrampage.com/ще-один-фактор-гівнокода/
Ваші цінності – лайно. Або про корпоративний газлайтинг (на прикладі корпоративних цінностей #Railsware)
#values #business
Одразу хочу зазначити, що не маю негативного ставлення до корпоративних цінностей як таких. Корпоративні цінності – це найвищий рівень визначення спеціалізації компанії,її дифференціації, унікальної пропозиції, типу управління компанією та управління очікуваннями клієнтів. У цій публікації я розгляну як неправильно корпоративні цінності формуються та використовуються, тобто ще про один культ вантажу та газлайтинг.
https://itrampage.com/ваші-цінності-лайно-або-про-корпорати/
Дизайн на Discovery стадії – це лайно
Я вже розповідав, що Ваші дизайн системи – лайно і пізніше в окремій публікації розповім чому загалом дизайн – це лайно. Призначення цієї ж публікації – розмовісти чому розробка на стадії т.з. Discovery – це лайно.
https://itrampage.com/дизайн-на-discovery-стадії-це-лайно/
Нова публікація на ITRampage: Ваші дизайн системи - лайно https://itrampage.com/ваші-дизайн-системи-лайно/
Читать полностью…
DevOops або чому *баних АйТівців може навчити гірничий інженер
https://itrampage.com/devoops-або-чому-баних-айтівців-може-навчити/
Найгірша проблема розробки ПЗ
… полягає у тому, що усі бажають його безмежно масштабувати й задовольняти якомога більшу кількість користувачів. Саме від цього безмежно розростається складність, стає важко вносити зміни, розробники нудяться та шукають новий проєкт. Все інше – вторинне. https://itrampage.com/найгірша-проблема-розробки-пз/
Ви розумієте абстрагування не правильно! https://itrampage.com/ви-розумієте-абстрагування-не-правил/
Читать полностью…
Пиши код як чайник
Парадигми, ідіоми мов, фреймворки, Domain Specific Languages, Domain Driven Design, Clean Architecture, Hexagonal Architecture, Onion Architecture, монади та моноіди, найкращі практики та методології, Test Driven Development, Behaviour Driven Development, SOLID: Single Responsibility Principle, Open/Closed Principle, [Barbara] Liskov’s Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle, AntiCorruption Layer, Model View Controller, Model View Viewmodel, Model View *Whatever, low-coupling, high-cohesion, 12 factor application, 5 lines per method, 100 lines per class, GoF patterns, DevOps, DevSecOps, SCRUM, Kanban, Team Topology, … – це все, коротко кажучи, лайно.
https://itrampage.com/пиши-код-як-чайник/