![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
malyj_gorganСлухайте, а хтось може в парі абзаців пояснити, що то таке сабж і з чим його їдят? Дідько з нею, з його vulterability'ею, я хочу зрозуміти, чим був такий хороший чи зручний чи потрібний сам log4j, що та вульнерабіліті виявилася такою проблємною? Тільки пояснити так, на хлопский розум, без відсилань в непотрібні абревіатури.
Дякую!
Дякую!
no subject
Date: 2021-12-31 02:23 am (UTC)І як нам визначити, який саме об'єм прав (а) має тий, чи інший метод, і (б) якій об'єм йому потрібен?
Якщо б це було тривіальною задачею в складних системах... Можна розібрати хоча б на прикладі вишепроцитованої вразливості в iMessage.
Що в цьому коді вказує на потенційну ескалацію функціональності?
Чи, наприклад, контекст та організований логінг - необхідні, так? Хтось може сказати - а давайте все ліпити (включно з повним контекстом) в stdout, а sidecar вже збере і розбереться, що треба залишити.
І іноді цій підхід може працювати. А іноді - створювати ще більші вразливості (хоча б тому, що повний контекст та inter-process communication це вже небезпечно, небезпечніше, ніж це робити всередині процесу).
І тому практики integration/deployment за межами critical safety infrastructure важливіші за ідеальний код (хоча б тому, що ідеальний код не можливий принципово, а значить, нам треба вчитись щось робити з неідеальним кодом).
Але, ці практики звучать просто - і навіть відчуваються просто коли вже втілені. А саме втілення дуже складне, бо воно не про 0 та 1, не про алгоритми, не про формальні методи, а про взаємодію людей.
no subject
Date: 2021-12-31 08:39 am (UTC)Це не лише софта стосується, а всього, отакий вічний пошук балансу між тим, щоб довіряти відповідальності інших, чи обмеженням прав і можливостей цих інших на інструментальному/нормативному рівні (тобто, обмеженням доступу до / можливостей відповідних інструментів). Воно ж присутнє всюди: доступ до зброї, регулювання будівництва і вуличного руху, регулювання споживацьких товарів. А вже у вихованні дітей ти про це думаєш щодня багато разів. Так от, на цьому філософському рівні я вважаю, що майже всюди ми зловживаємо інструментальним контролем, але саме ось тут -- навпаки. Хоча забороняти ті чи інші інструменти я не закликаю, закликаю самообмежуватися :)
no subject
Date: 2021-12-31 05:22 pm (UTC)(Це, звісно, в умовах "типового" software development задач - є купа edge cases де ці практики є корисними.)
Що до людей, які вміють, не хочуть чи не мають можливості - це дуже класне питання, яке починається з incentives. Якщо, наприклад, cost-saving менеджер каже "be your own QA" - то можна розробнику розраховувати на бонус за вдосконалення testing pipeline чи скорочення часу виконання тестів на годину? Відповідь на це питання проводить чітку межу між компаніями (чи командами в компанії).
Бо incentives define behavior - якщо за такі практики менеджмент підтримує працівників, то більшість людей активно починає вчитися, хотіти, та шукати можливість. Не все, але більшість.
А що до нестачі інструментального контролю - я погоджусь. Але не в сенсі "тримати та не пущати", а в сенсі саме instruments.
- Штурман, приборы!
- Триста!
- Что триста?
- А что приборы?
Менеджмент coding/integration/deployment practices як раз починається з вимірів того, що в тебе відбувається в цих місцях. А з цим, як правило, дуже сумно - хоча усі інструменти є на ринку, в Гугл найматися, щоб їх використовувати - вже не треба.
no subject
Date: 2021-12-31 07:21 pm (UTC)Я в індустрію попав, коли замість засилля класичних практик почало ставатися засилля заборони класичних практик. В результаті, спостерігав два колективи, де падіння якості продукту дуже чітко слідувало за відмовою від окремого QA і перекладанням усієї відповідальності за якість/безпеку коду на тих людей, які його пишуть. (В третьому колективі окремого к'юей, здається, і не було, тому падіння якості константувати не можу) Якщо ти помітив, я з самого верху не наполягаю на універсальності свого розуміння, як все має працювати, а навпаки, критикую випадки, коли насаджувався первний універсальний підхід тому, що "так модно" або "так дешевше цього місяця"
> ...до бізнес-результатів.
А ось тут вірю. Бізнес результати найчастіше націлені на короткий і середній горизонт подій, тоді як практики типу "звільнимо к'юєїв, хай програмісти просто пишуть кращий код" короткочасно якраз вигідні, а проблеми проявляються в майбутньому. Ще раз: я не кажу, що воно обов'язково всюди так, але у тих двох випадках, які я спостерігав, так і було: новий підхід знижував видатки і збільшував швидкість видачі продукту, бізнес покращувався... зате через 2-3 роки проблеми виростали лавиноподібно, одна компанія зменшилася втричі і пройшла через Chapter 11, друга просто накрилася, але "винен" уже був хтось інший. Звичайно, проблеми з підходом до кодування були не джерелом усіх проблем, а одним із симптомів. Але убиває не причина хвороби, а саме симптоми, це я як медик кажу :)
> ... про менеджерів і інсентівз ...
Exactly! Все правда, і те, що джерелом таких проблем найчастіше є менеджмент, і те, що інженери, в принципі, самі винні, що ведуться, можуть і не вестися.
> Але не в сенсі "тримати та не пущати", а в сенсі саме instruments.
Правильно. "Тримати і не пущати" і "силою заганяти" -- два однаково шкідливі перегиби в різні боки (часто в один)
> ...починається з вимірів того, що в тебе відбувається в цих місцях... в Гугл найматися, щоб їх використовувати - вже не треба.
А тут починаються сумні реалії життя: абстрактно все вимірювати і грамотно організовувати було би класно, але коли у тебе 2/3 команди пішло, нікого нормального найняти не виходить, менеджмент, який до цього докотився, уже помінявся... а ти сидиш в новорічний вечір перед проектом, який тріщить по швах і думаєш, що "блін, якби у них була хоч пара к'юеїв, вони би до цього не допустили" Десь так. Так що це у мене менше універсальні міркування, а більше крик душі :)
no subject
Date: 2021-12-31 07:51 pm (UTC)А що вони можуть зробити, якщо менеджер вирішує звільняти SRE та QA - що є антіпатерном, навіть в компаніях, де девелопери самі займаються тестуванням?
Сказали своє фу менеджменту, менеджмент їх не послухав, що далі? Далі залишається єдина можливість - перейти через дорогу в компанію з більш адекватним менеджментом, що вони і роблять, ні?
Класична проблема:
- В тебе ж сокира тупа!
- Та нема коли точити, рубати треба!
Але ж проблема в тому, що якщо не почати щось робити - ані з retention, ані з hiring, ситуація краще не стане.
Бо навіщо йти працювати, там де бардак та проблеми, якщо можна піти туди, де нема бардаку та проблем?
Як кажуть: "You can change the organization or you can change the organization."
В мене є підозра, що саме це буде примушувати індустрію сепаруватися на окремі прошарки - в одному треш і угар, в іншому адекватні (хоча і неідеальні) практики, і перетинатися ці два світи не будуть.
no subject
Date: 2021-12-31 08:15 pm (UTC)> Бо навіщо йти працювати, там де бардак та проблеми, якщо можна піти туди, де нема бардаку та проблем?
От я і пробую щось робити. Паралельно працюю, планую реорг, перевіряю домашні завдання кандидатів. Ну і, паралельно думаю, чи то таки самому піти туди, де менше проблем, чи своїм прикладом почати покращення в плані retention. Піти -- це вихід, але лишитися -- це шанс щось змінити тут, заробивши на цьому якісь дивіденди. От і думаю.... а в перервах скаржуся тобі :)
no subject
Date: 2021-12-31 08:03 pm (UTC)Якщо ми вже почали звертатися до медичних аналогій, то гірше за відсутність лікування може бути тільки невміле та часткове лікування: хоч software engineering взяти, хоч бактеріальну інфекцію.
no subject
Date: 2021-12-31 11:53 pm (UTC)От, до речі, не обов'язково. Комбінація ефекта плацебо з "само пройшло" часто виступає не набагато гірше, ніж реальне лікування. Враховуючи вартість реального лікування, це створює купу етичних парадоксів, які дають право на існування всяким чаклунствам і гомеопатіям. Трохи спрощеним, але ральним є сценарій, коли треба вибрати що краще: коли у тебе виздоровіє п'ять пацієнтів з десяти, а п'ять помирає від неправильного лікування, чи помирає три пацієнти, а семеро виздоровлює від 70%-ефективної терапії, але ця терапія така дорога, що п'ять з цих семи банкрутує, і через стрес і падіння достатку втрачає 10 років life expectancy.
Словом, ну їх нафіг, ті медичні аналогії.