Update Readme

Author: spajic

README.md

@@ -17,6 +17,8 @@
 - Добиться того, чтобы программа корректно обработала файл `data_large.txt` за `30 секунд`;
 - Написать кейс-стади о вашей оптимизации по шаблону `case-study-template.md`.
 
+Case-study должен получиться рассказом с техническими подробностями о том как вы пришли к успеху в оптимизации. Можно сказать, заготовкой статьи на Хабр/Medium/...
+
 ## Сдача задания
 Для сдачи задания нужно форкнуть этот проект, сделать `PR` в него и прислать ссылку для проверки.
 
@@ -27,7 +29,7 @@
 
 # Комментарии
 
-## Какую пользу нужно получить от этого задания
+## Риски
 Задание моделирует такую ситуацию: вы получили неффективную систему, в которой код и производительность оставляет желать лучшего. При этом актуальной проблемой является именно производительность.
 Вам нужно оптимизировать эту систему.
 
@@ -39,14 +41,24 @@
 Их риски:
 - перед рефакторингом “очевидных” косяков не написать тестов и незаметно внести регрессию;
 - потратить время на рефакторинг, хотя время было только на оптимизацию;
-- исправить все очевидные на глаз проблемы производительности, не получить заметного результата, решить что наверное просто Ruby слишком медленный для этой задачи
+- исправить все очевидные на глаз проблемы производительности, не получить заметного результата, решить что наверное просто Ruby слишком медленный для этой задачи, демотивироваться и разочароваться в попытках оптимизации
 
 ## Советы
 - Найдите объём данных, на которых программа отрабатывает достаточно быстро - это позволит вам выстроить фидбек-луп; если улучшите метрику для части данных, то улучшите и для полного объёма данных;
 - Попробуйте прикинуть ассимтотику роста времени работы в зависимости от объёма входных данных (попробуйте объём x, 2x, 4x, 8x)
 - Оцените, как долго программа будет обрабатывать полный обём данных
 - Оцените, сколько времени занимает работа GC (попробовав отключить его на небольшом объёме данных)
 
+### Совет: как посчитать кол-во строк в файле
+```
+wc -l data_large.rb # (3250940)  total line count
+```
+
+### Совет: как создать меньший файл из большего, оставив перевые N строк
+```
+head -n N data_large.txt > dataN.txt # create smaller file from larger (take N first lines)
+```
+
 ## Что можно делать
 - рефакторить код
 - рефакторить/дописывать тесты
@@ -56,7 +68,7 @@
 - исследовать предложенную вам на рассмотрение систему
 - построить фидбек-луп, который позволит вам быстро тестировать гипотезы и измерять их эффект
 - применить инструменты профилирования CPU, чтобы найти главные точки роста
-- выписывать в case-study несколько пунктов: каким профилировщиком вы нашли точку роста, как её оптимизировали, какой получили прирост метрики;
+- выписывать в case-study несколько пунктов: каким профилировщиком вы нашли точку роста, как её оптимизировали, какой получили прирост метрики, как найденная проблема перестала быть главной точкой роста;
 
 ## Что не нужно делать
 - переписывать с нуля
@@ -70,27 +82,28 @@
 - как с помощью профилировщиков нашли что именно даст вам наибольший эффект (главную точку роста)
 - как быстро протестировали гипотезу, получили измеримый результат и зафиксировали его
 - как в итоге написали небольшой отчёт об успешных шагах этого процесса
-инструментов профилирования `CPU` и разъяснений, сделанных на 2й лекции.
 
 ## Checklist
-- Построить и проанализировать отчёт `ruby-prof` в режиме `Flat`;
-- Построить и проанализировать отчёт `ruby-prof` в режиме `Graph`;
-- Построить и проанализировать отчёт `ruby-prof` в режиме `CallStack`;
-- Построить и проанализировать отчёт `ruby-prof` в режиме `CallTree` c визуализацией в `QCachegrind`;
-- Профилировать работающий процесс `rbspy`;
-- Построить и проанализировать отчёт `flamegraph` с помощью `rbspy`;
-- Добавить в программу `ProgressBar`;
-- Постараться довести асимптотику до линейной и проверить это тестом;
-- Написать простой тест на время работы: когда вы придёте к оптимизированному решению, замерьте, сколько оно будет работать на тестовом объёме данных; и напишите тест на то, что это время не превышается (чтобы не было ложных срабатываний, задайте время с небольшим запасом);
+- [ ] Прикинуть ассимпотику зависимости времени работы програмы от размера обрабатываемого файла
+- [ ] Построить и проанализировать отчёт `ruby-prof` в режиме `Flat`;
+- [ ] Построить и проанализировать отчёт `ruby-prof` в режиме `Graph`;
+- [ ] Построить и проанализировать отчёт `ruby-prof` в режиме `CallStack`;
+- [ ] Построить и проанализировать отчёт `ruby-prof` в режиме `CallTree` c визуализацией в `QCachegrind`;
+- [ ] Построить дамп `stackprof` и проанализировать его с помощью `CLI`
+- [ ] Построить дамп `stackprof` в `json` и проанализировать его с помощью `speedscope.app`
+- [ ] Профилировать работающий процесс `rbspy`;
+- [ ] Добавить в программу `ProgressBar`;
+- [ ] Постараться довести асимптотику до линейной и проверить это тестом;
+- [ ] Написать простой тест на время работы: когда вы придёте к оптимизированному решению, замерьте, сколько оно будет работать на тестовом объёме данных; и напишите тест на то, что это время не превышается (чтобы не было ложных срабатываний, задайте время с небольшим запасом);
 
 ### Главное
 Нужно потренироваться методично работать по схеме с фидбек-лупом:
 - построили отчёт каким-то из профилировщиков
 - осознали его
 - поняли, какая самая большая точка роста
 - внесли минимальные изменения, чтобы использовать только эту точку роста
-- перестроили отчёт, убедились, что проблема решена
 - вычислили метрику - оценили, как изменение повлияло на метрику
+- перестроили отчёт, убедились, что проблема решена
 - записали полученные результаты
 - закоммитились
 - перешли к следующей итерации

case-study-template.md

@@ -28,13 +28,22 @@
 Вот какие проблемы удалось найти и решить
 
 ### Ваша находка №1
-О вашей находке №1
+- какой отчёт показал главную точку роста
+- как вы решили её оптимизировать
+- как изменилась метрика
+- как изменился отчёт профилировщика - исправленная проблема перестала быть главной точкой роста?
 
 ### Ваша находка №2
-О вашей находке №2
+- какой отчёт показал главную точку роста
+- как вы решили её оптимизировать
+- как изменилась метрика
+- как изменился отчёт профилировщика - исправленная проблема перестала быть главной точкой роста?
 
 ### Ваша находка №X
-О вашей находке №X
+- какой отчёт показал главную точку роста
+- как вы решили её оптимизировать
+- как изменилась метрика
+- как изменился отчёт профилировщика - исправленная проблема перестала быть главной точкой роста?
 
 ## Результаты
 В результате проделанной оптимизации наконец удалось обработать файл с данными.
@@ -44,3 +53,4 @@
 
 ## Защита от регрессии производительности
 Для защиты от потери достигнутого прогресса при дальнейших изменениях программы *о performance-тестах, которые вы написали*
+