dmytrish: (Default)
Уроки, які я виніс із свого скриптописання для важливих речей в умовах Дикого Заходу Перла, відсутності тестів і типів, і чого мені тепер у чужих скриптах часто не вистачає:
  • логувати багато і всеохопно (коли від скрипта залежить залежать суми в десятки річних зарплат, кожний можливий шматок даних може стати критичним, якщо щось піде не так);
  • логувати в формі, відносно легкій для аналізу звичними інструментами, в моєму випадку пласкі файли, які можна обробляти юніксовими утилітами; не забувати час та контекст, важливість запису; треба шукати компроміс між легкістю людського сприйняття (skimability: наскільки його можна переглядати по діагоналі) і можливістю парсити пізніше;
  • логування також часто є формою документації та коментування коду: для розуміння перлівського коду його треба запускати і дивитись, що він робить, а логування це і є спосіб дивитись це.
  • логувати весь control flow: щоб за логом завжди можна було відтворити виконання;
  • ловити і детально логувати помилки; помилки не можна мовчки ігнорувати;
  • урок, натхнений Хаскелем: робити режим --dryrun, коли скрипт збирає всі дані і робить все, що повинен, за винятком критичних ефектів типу запису в бази даних: багато помилок ловиться під час dryrun і це іноді корисний інструмент для збору інформації про те, що хочеш зробити. Крім того, це незамінний інструмент для розуміння чужих скриптів, які часто неясно навіть як запустити.

Ще у мене за час епопеї із міграцією готелів із однієї системи полісі на іншу (точніше, прикривання старої системи новою) виробився досить корисний протокол щодо важливих змін:
  • спочатку тестувати у розробницькому середовищі (у нас є розробницьке середовище, із повними копіями усіх баз, які робляться щоночі);
  • старатись відділяти дані від дій: збір даних і прийняття рішень, що робити, має бути відділене від самих дій; проміжні дані/рішення мають зберігатись і не повинні бути ефемерними; краще написати скрипт, який збирає дані і приймає рішення, і окремий скрипт, який реально виконує рішення першого скрипта, щоб проміжні дані збереглись;
  • часто хороша ідея робити скрипти reversible, щоб можна було все відкотити назад, але тут неминучі деякі компроміси;
  • щедро додати асерти та перевірки припущень і preconditions;
  • тестувати на продакшні із dryrun, перевірити логи на помилки і будь-які аномалії;
  • тестувати якусь реальну вибірку методом Монте-Карло: брати випадкову вибірку, вручну ретельно перевіряєш результати
  • не робити великі зміни (кілька тисяч готелів) за один раз, бити на менші batches і пробувати щось робити поступово і ітеративно, щоб можлива шкода була більш обмежена і помилки встигали виявитись; нарощувати батчі експоненційно, якщо є можливість;
  • вести детальний відтворюваний журнал ручних дій із часом кожної дії;
  • виділяти час на аналіз результатів і бути готовим до firefighting після виконання скрипта, не робити такі зміни ввечері, перед вихідними і перед відпустками.

Отак і живем, хоча відсутність статичних гарантій і часто банального розуміння коду без запуску це ніби відсутність елементарної гігієни. Але все-таки цікаво, що інженерна культура не вичерпується статичними гарантіями і навіть на такому безриб'ї можна чомусь навчитись.
dmytrish: (qnxroot)

Пофігачив трохи коду на Расті, і дивне відчуття: з одного боку, сильна типізація, ADT, нормальний паттерн-матчінг, красота-лєпота, з другого, цикли, референси і імперативне програмування в усій красі. Цікава суміш.

Borrow checker не такий уже і страшний, після деякого освоєння теорії з ним впоратись відносно легко.

Compile-time речі дивні і незвичні, замість лексичного підмазування треба писати повноцінні макроси, що спочатку страшно, але в результаті повинно виходити менше #ifdef-каші.

І да, C++ здається потім пе́рлово-ламповим, Rust відчувається як мова із сильним інженерним дизайном. Підозрюю, що любителі красної словесності від програмування можуть його за це не полюбити (але то вже їхні проблеми).

dmytrish: (Default)
"Thinking, Fast and Slow" by Daniel Kahneman contains a hilarious chapter, "The illusion of stock-picking skill". Here are some selected quotes (emphasis is mine):

...a major industry appears to be built largely on an illusion of skill. Billions of shares are traded every day, with many people buying each stock and others selling it to them. It is not unusual for more than 100 million shares of a single stock to change hands in one day. Most of the buyers and sellers know that they have the same information; they exchange the stocks primarily because they have different opinions. The buyers think the price is too low and likely to rise, while the sellers think the price is high and likely to drop. The puzzle is why buyers and sellers alike think that the current price is wrong. What makes them believe they know more about what the price should be than the market does? For most of them, that belief is an illusion.

Many individual investors lose consistently by trading, an achievement that a dart-throwing chimp could not match. The first demonstration of this startling conclusion was collected by Terry Odean, a finance professor at UC Berkeley who was once my student.

Read more... )
dmytrish: (Default)
If you use Firefox, you can:

1) Install Greasemonkey;

2) Download and install this user script file from this Github gist;
dmytrish: (Default)
I, dmytrish, announce that I don't agree to the new Russian terms of service at LiveJournal.com and I am not responsible for any new content that may appear there under my nickname.

Я, dmytrish, засвідчую, що я не приймаю нову угоду про надання послуг із LiveJournal.com, і не відповідаю за будь-які нові пости, які можуть з’явитись під моїм іменем.

Profile

dmytrish: (Default)dmytrish

August 2017

S M T W T F S
   12345
6789101112
13141516171819
20212223242526
2728293031  

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 22nd, 2017 05:07 am
Powered by Dreamwidth Studios