архімаггриб в Дарницькі печери
  • Довгі мітинги vs. Фокус уваги та пам’ять

    В одній конторі було що щось обговорювати треба 4-5 годин — фактично, повний день. Разів 10 так.
    Рішення — графік перерв. 45 хвилин розмова — 15 перерва на все що треба. Рівно за графіком. Насильно зупиняти посеред промови, якщо інакше люди не розуміють.
    З третього разу проблем вже не було, люди звикли.

  • Чистий код Роберта Мартіна не такий вже чистий?

    І не тільки тут. Взагалі легко гугляться десь пʼять прикладів подібної критики. І що характерно © — вона вся реально грунтовна.

  • Помер Ніклаус Вірт, творець Pascal

    Головна проблема Паскаля була в тому, що в IT майже завжди перемагає не кращий, а перший мінімально придатний.
    Це спочатку принесло Pascal коли Вірт після нього виправив багато помилок і зробив Modula, а потім ще кривіше створіння — C.
    І в результаті ми серед всіх досягнень Вірта бачимо лише той Pascal, і то вимер.
    Не пощастило. Але його досягнення розібрали на шматки і корисне поступово вводять під своїми іменами.
    Першопроходці — з ними часто так. :(

    Підтримав: Dmytro
  • Огляд книжки «Чистий код» Роберта Мартіна

    А з приводу ГоФ — не згоден. Класифікація найбільш загальних патернів дуже непогана, і сформульована в практичному стилі «вам треба зробити ось таке при таких-от умовах — використовуйте такий паттерн»

    Проблема не в класифікації, а в відборі. Чому саме ці 25 серед сотень.

    Але все інше зустрічаеться регулярно — щось рідше, щось частіше.

    Що у вас за робота, що вони регулярно зустрічаються?
    І коли зустрічався, наприклад, Visitor?

    Що дійсно напрягає, так це карго-культ, який на базі таких книг виникає

    ...

    Але то далеко не завжди проблема книги :).

    Саме неї.
    Бо коли такі книги пишуться без того, щоб кожну главу починати з «В усьому мають бути міра, норма і межа, а тепер слухайте», карго-культісти виростатимуть тисячами.

  • Огляд книжки «Чистий код» Роберта Мартіна

    якщо писати плагіни мов чи підтримки фреймворків в Eclipse або Idea

    Це надто специфічні випадки.

    Зважайте на те, що цій книжці більше 20 років.

    Скоріше, тут специфіка орієнтації авторів.

  • Огляд книжки «Чистий код» Роберта Мартіна

    брідж може бути використан
    інтерпретатор може бути використан
    адаптер може бути використан
    команд може бути використан

    Це реальні випадки чи уява про те, що «если кто-то кое-где у нас порой» © може щось використати?
    Здається, «питання риторичне» ([Артур Шев]) :)

    треба піклуватись про інфрастуктуру в якій ви запускаєте тести, піклуватись про фреймворк

    Це ніяк не протирічить тому, що я написав.

    чи писали ви тести в форматі BDD?

    Писав. Це була побочна робота, але була. У простих випадках — нічого складного і дивного, якщо мова зафіксована, немає.

    чи помітили ви використання патернів GoF в BDD?

    Ні, бо вони не використовувались. Сам фреймворк не враховую, але про нього особлива мова (PropEr і власна надбудова над ним).

    питання риторичне

    Ви повністю промазали зі свою згадкою :))

    Підтримав: Женя Онопрієнко
  • Огляд книжки «Чистий код» Роберта Мартіна

    а які на вашу думку патерни не є ідеальними?

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

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

    Деталі — наприклад, кто хоч раз бачив Builder? Я бачив, але не External, як у GoF, а Internal і Builder Context. External — жодного разу за майже 30 років у галузі. Чому вони вибрали саме цей варіант?

    Зазвичай архітектурний вибір рішення проходить в інших місцях. Які ми бачимо спори? Чи не найбільше всього — анемічна чи багата (насичена?) доменна модель. Потім — фреймворки і мови.

    То, може, книга GoF має якусь дидактичну цінність, як ті сортування, які ми всі вчимо бо це легко навчити алгоритмам на масиві, але потім 99% забуває? Може, і так, але знову — хто довів цінність вибору саме цих 25 патернів? Де порівняння?

    qa пише код, шоб код був розширяємим треба використовувати принципи ооп, солід, грасп, патерни програмування та автотестування.

    По пунктах. Саме для кода тестування, не цільового коду.

    ООП? Хіба що для «вбудування» у фреймворки типу pytest, і тільки тому, що вони так написані. Замість цього могло б бути написання на шаблонній мові з автогенерацією з неї (як і робиться в деяких BDD-фреймворках).

    SOLID? Скільки випадків де реально треба подумати про S і це за межами звичного визначення здорового глузду? Де O в автотестуванні? Де L за межами сидіння в ООП бо туди вже засунули? Чи багато реального D в тестових фреймворках? До біса дверцяти.

    GRASP в цілому? Найбазовіші принципи на зразок Information Expert — да. Але я б подивився на того, хто спробував би зробити інакше.

    Скільки яких реально патернів з GoF набору ви бачите у автотестах? Де Adapter? Де Bridge? Реально хоч один випадок Interpreter? Куди всунути Command? Де Visitor? Про що ви взагалі?

    чи ви про щось інше кажете?

    Саме так.

    90+% роботи в автотестуванні це вибір, що має бути в тесті, а що — не має. Треба думати про зовсім інші матерії.

    Підтримав: Yurii Kovalets
  • Огляд книжки «Чистий код» Роберта Мартіна

    а можете більш детально розвивинути чому ви думаєте що патрени GoF — це інфоциганство?

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

    дуже жаль, що вам не пощастило працювати з автотестувальниками

    Невірно. «Пощастило» і багато.
    Справа не в автотестуванні і автотустувальниках, а в тому, что цілі QA не мають проєцуватись напряму на конкретні рішення дизайну коду.

    так той, принципи GRASP в книгах Роберта Мартіна так само розглядаються і рекомендуються

    Але сховані під шаром SOLID-подібного сміття (хоча і він постійно порушується).

    ви точно читали ці книжки що критикуєте Роберта так яро?

    Читав.

  • Огляд книжки «Чистий код» Роберта Мартіна

    Вся «Clean code» — самопротирічна безграмотна нісенітниця. Оглядів цього достатньо в інтернеті, можна згадати хоча б це або це.

    Роберт Мартін — «інфоциган», що продає софт-скілли під виглядом хард-скіллів. Те ж стосується TDD і «банди чотирьох» з їх 25 патернами. Їх ідеї гарні самі по собі, але випʼячування саме їх і в такому вигляді, як це роблять Мартін або GoF, не має жодного сенсу, крім створення шару термінології, якою можна жонглювати для досягнення своїх цілей в корпоративному середовищі.

    Я здивований підписом автора статті. Я б ще зрозумів таку статтю від якогось PМа зі стажем над групою джунів, якому до дупи, що розробляти — бухгалтерію чи мобільний застосунок для шейпінгу. Але при підпису «Head of QA Department» незрозуміло, який звʼязок QA з темою.

    Як конструктив рекомендую почати хоча б з «Code complete» і принципів GRASP замість SOLID. В них теж є спірні твердження, але нема такого, що корисні речі треба викопувати з-під товстого шару сміття, як вся «творчість» Мартіна.

  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    Ти забагато хочеш від джензі.

    «Джензі» це хто?

    Якщо бути таким як ти, то доведеться в кожного кинути книжку ульмана, а потім ще шльопнути по губам якимось томіком посучасніше

    Ні! Ні, і я не про це!
    Не треба нам ахо-ульманів, це вигін в зовсім іншу сторону. Навпаки, те, що бачимо у цій статті, це коли спочатку спохаблять, а потім намагаються викласти з мордою академічною цеглою.

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

    Тут не виконано ніщо з цього.

    Підтримав: Andriy Slobodyanyk
  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    А ця стаття для трейні.

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

    Підтримав: Andriy Slobodyanyk
  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    Якось занадто поверхнево.

    > Команди управління транзакціями використовуються тільки з командами DML, як-от — INSERT, UPDATE та DELETE. Вони не можуть використовуватися під час створення таблиць або їх видалення, оскільки ці операції автоматично фіксуються в базі даних.

    Вірно для більшости, але не для всіх баз.

    > Ця команда може використовуватися тільки для скасування транзакцій з моменту виконання останньої команди COMMIT або ROLLBACK.

    Не згадан autocommit-режим, і що він може бути за замовчуванням. Тоді ви нічого вже не скасуєте.

    > SAVEPOINT — це точка транзакції, до якої ви можете повернути транзакцію, не відкочуючи її повністю.

    Багато де не реалізовано.

    > Приклад 1. Банківська транзакція

    Ані слова про те, що будь-який з UPDATE може зависнути на визначений час чи одразу відмовити, що COMMIT може відмовити, що робити у такому випадку. (Я вже не згадую, що реальна банківська транзакція пише ще два десятки таблиць логів і статистики, і скоріш за все сам переказ на цільовий рахунок теж у таблиці тимчасового логу, а не одразу.)

    > Основні проблеми паралельного доступу:

    І ані слова про те, що цей аналіз дуже поверхневий. Забуті такі проблеми, як read skew, write skew. Щоб почитати, наприклад:
    www.cockroachlabs.com/...​le/demo-serializable.html
    justinjaffray.com/...​oes-write-skew-look-like
    A Critique of ANSI SQL Isolation Levels, Jun 1995, Microsoft Research (1995! це ж коли було і мало хто знає)
    Кожен хто претендує на звання хоча б інтерна з DBA чи мідла у суміжних областях — має це знати і уважати. В такій статті як ця — якщо не в основному тексті, то хоча б у PS треба було б зауважити.

    Ні слова про те, як можна керувати рівнем оптимістичности в транзакціях, які рушії (движки?) як з цим працюють (блоковочники і версіонники (MVCC) дуже по-різному відносяться до цього), про переваги всяких select for update де вони є...

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

    Привіт автору від Даннінга з Крюгером, даруйте.

  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

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

  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

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

    Ну это в первую очередь ваша ошибка — «гибкий график» должен предусматривать уровень гибкости. Может, он работал раньше с теми, кто иного варианта просто не знал.
    Обычно таки «гибкий график» это что-то вроде «понедельник, среда и пятница — обязательное присутствие и работа с 12 до 16 с быстрой реакцией на все входящие, участие в совещаниях, остальное когда хочешь» и детали — когда быть на связи — критически важны. Поэтому «гибкий график» без указания постоянной части это вообще ни о чём. Тут вы сами виноваты на 90%. Остаток на него — что не подумал какая степень гибкости — но, может, у него таки опыта в этом не было.

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

    Все так (навіть якщо документація здається повною і ідеальною)... ну і зовсім без живої розмови можна впоратись з дуже малою часткою робіт...

  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

    Ну якщо для вас «вчитись» то «шаройобитися»... що ви тут робите?

  • Чи є у вас на проєкті код фрізи?

    Там де найдовше працював — декілька днів перед форком релізної гілки, потім вивільняє. А ось в релізній вже сувора дисципліна. Релізні гілки за часом кожні ~2 місяці.
    Там appliances що встановлюються у кастомера.

    На поточному проекті схоже, але дещо більше бардака.

  • Чи багато у вас вкладок і закладок у браузері? Як ви їм даєте раду?

    800-900 в найбільш товстому профілі. Не заважають, бо не завантажені.

    Підтримали: Oleksandr Suvorov, Alex Oliinyk
  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

    Головне — кричати «Вільна каса!» впевненим голосом.
    Oh wait... навіть в маку вчитися новій роботі це декілька тижнів.

    Підтримав: Микола Сидоренко
  • Відбувся реліз Django 5.0

    На нём DOU работает.

  • Які ваші прогнози та очікування від 2024 року?

    И тогда действительно победа была нужна любой ценой,

    Требование победы любой ценой — _никогда_ не должно быть. Не потому, что нельзя так хотеть, а потому, что это даёт оправдание именно бессмысленным потерям.
    ещё
    В случае WW2 это 1942: Мясной Бор, Ржев и ещё десяток аналогичных локаций, которые стараются не вспоминать, потому что до сих пор в лесах труп на трупе во много слоёв. Или взятие Берлина «к дате», которое добавило полмиллиона погибших.
    Статистика смертности в тылу, кстати, не радует. Сколько там от голода и холода?

← Сtrl 1... 45678...375 Ctrl →