Блоґ одного кібера

Історія хвороби контуженого інформаційним вибухом

Статистична оцінка терміну виконання проекту перекладу

with 4 comments

Я тут начитався Джоела Спольськи, про те що без дедлайнів живуть тільки геймдевелопери (“Буде зроблено тоді коли буде зроблено. Кармак”), тому що ігри – це програми в яких існує лише одна версія, тому що ніхто не захоче грати гру з тим самим сюжетом (“В грі сюжет так само важливий як і в проні. Кармак”) в якій лише додали два нові види зброї і поправили баги виявлення зіткнень (“Я дивився, дивувався (“оМГ моби не бігають через стінки! жееесть!”) але шпіляти навіть не думав. danbst”). Більшість інших програмок потрібно випустити до певної конкретної дати, бо конкуренти не чекають, тому якщо щось не встигається – зі специфікації викидають зайвий функціонал. (“В нас якість – понад усе. Рівно 31 числа ми випустимо настільки якісний браузер, наскільки зможемо.” Джемі Завінські згадує анекдот з Netscape).

І чому я собі в резюме не дописав що я якось з таким аццкім софтом мав справу?

В жорстких дедлайнах я ще не був (ну, в університеті робив лабораторні не в останню ніч перед …, а зранку перед здачею, але то просто від нудьги. На роботі наприклад просять проставити в JIRA оцінку терміну виконання задачі, але зазвичай виходить що я два-три дні щось читаю і думаю як я її буду робити, потім коли я вже знаю як її робити і скільки часу на неї піде, я забуваю цю оцінку проставити, за три-чотири години роблю задачу, далі від нічого робити займаюсь рефакторингом (поки що в межах PEP8). А потім ще два-три дні перекидуюсь з тестерами коментарями щодо задачі. Суть моїх коментарів зводиться до двох основних видів: “fixed.”, “це не бага, це фіча”. Тобто частиною часу яка піддається оцінці зазвичай взагалі можна нехтувати як похибкою. Але думаю що за рік-два вже виясню як оцінювати терміни виконання.

А взагалі, конкретна стаття Джоела – Evidence based sheduling. Ідея в тому, аби просто фіксувати прогрес, а оцінку дати релізу поставить система, причому навіть побудує розподіл ймовірностей того що продукт вийде до такого то числа (реклама FogBugz 6.0).

Грошей на персональний FogBugz в мене ще нема, тому захотів зробити щось своє, простіше, і для розваги. Я наприклад адміністратор, і автор більше 10% правок вікіпідручника. Серед проектів – переклад Dive into Python 3 – прибитого проекту Марка Пілігрима, щоб продовжити його справу, пропагувати Python 3 в Україні, покращити свої відповідні знання і навики, і просто just for fun.

Так от, захотів я собі вияснити чи встигну перед смертю той переклад закінчити. Дописав свого бота (його код жахливий, тепер я це бачу, і цим теж треба зайнятись), частинку яка обчислює таку об’єктивну метрику як об’єм тексту в байтах, і складає в таблицю – час, об’єм.

Потім спробував записати в .csv, і думав собі намалювати графік в OO.Calс, але то падло, незважаючи на те що я йому вказав правильний формат запису дати в колонці, не змогло зрозуміти що між датами в сусідніх рядках не завжди проміжок часу – 1, тому графік вийшов неправильним. Тому я знову матюкнув афісний софт у всіх його інкарнаціях (хоча Excel напевне таки класний інструмент, коли розібратись нормально, але на то треба час і бажання), і вкотре встановив matplotlib.

Графік вийшов те що треба:

Хід роботи над проектом. Вісь X - днів від початку. Вісь Y - байти.

Що залишилось? Залишилось визначити момент закінчення проекту. Це простіше:

bunyk@bunyk-laptop:~/diveintopython3$ wc -c *.html
   2983 about.html
  47874 advanced-iterators.html
    470 blank.html
  65799 case-study-porting-chardet-to-python-3.html
   5259 colophon.html
  31982 comprehensions.html
  51102 files.html
  40274 generators.html
  85892 http-web-services.html
   4518 index.html
  30908 installing-python.html
  32061 iterators.html
  75095 native-datatypes.html
  38669 packaging.html
  72478 porting-code-to-python-3-with-2to3.html
  30981 refactoring.html
  56699 regular-expressions.html
  53129 serializing.html
  52100 special-method-names.html
  47209 strings.html
  27847 table-of-contents.html
   5060 troubleshooting.html
  59885 unit-testing.html
   6533 whats-new.html
   6200 where-to-go-from-here.html
  62023 xml.html
  36903 your-first-python-program.html
1029933 загалом

Ввесь оригінал містить трохи більше мільйона символів. Розділ your-first-python-program містить 36903 символів, а його повний переклад 44962 байти. Тобто, можна вважати, що на кожен символ оригіналу, припадає 1.2183833292686232 байта оригіналу. Що значить що об’єм повного перекладу буде приблизно 1254853 байти.

Тобто наша ціль трохи далі за 1.2 мільйонами символів. Графік показує що ми біля 160000, що складає 12%. Було б непогано, якби не 600 витрачених днів. (Витрачених взагалі то треба взяти в лапки, але тут важливий час завершення, а не витрачені часові ресурси, тому ймовірність і тривалість періодів під час яких я забиваю теж треба враховувати). Правда тоді до завершення доведеться чекати років з 10, за той час Ґвідо вже напевне Python 5 випустить. Правда кінець графіка виглядає трохи краще, і якщо відкинути перших десять значень, то майже лінійний. Чудово б підійшла лінійна оцінка, хіба ні? Враховуючи те, що проект малоймовірно отримає такий експоненційний ріст як вікіпедія загалом.

Тому думаю собі: тут все просто, тут напевне проходить звичайний лінійний метод найменших квадратів. Гуглю, знаходжу: numpy.linalg.lstsq. Читаю опис параметрів, ні чорта не розумію, дивлюсь далі, о!, є приклади. Переписую приклад:

def plot_with_prediction(sequence):
	import numpy as np
	import pylab
	x, y = zip(*list(sequence))
	x = np.array(x)
	y = np.array(y)
	A = np.vstack([x, -np.ones(len(x))]).T
	m, c = np.linalg.lstsq(A, y)[0]
	# now compute predicted values:
	yp = m*x + c
	pylab.plot(x,y, 'o')
	pylab.plot(x,yp, '-')
	pylab.show()

і що отримую:

Облом з numpy.linalg.lstsq

Явно щось не те. Може ви щось підкажете? Може якісь статті про регресійний аналіз, forecasting, і часові ряди. Тільки так аби для чайників, будь-ласка. Хай там будуть нейронні мережі, аби лиш я зміг за дві-три години розібратись і реалізувати.

UPD:
Рев’ю коду – прекрасна річ. Дякуючи цитованому ще в першому абзаці пану danbst, бага видалена, я і далі не шарю аналіз даних, але отримую потрібні картинки:

далі буде…

Advertisements

Written by bunyk

Листопад 8, 2011 at 01:47

Відповідей: 4

Subscribe to comments with RSS.

  1. A = np.vstack([x, -np.ones(len(x))]).T

    а чо в коді мінус стоїть? в прикладі ж його немає

    danbst

    Листопад 8, 2011 at 02:21

    • ааа. То я експериментально пробував підібрати правильні вхідні дані (однаково не працює).

      В разі чого, дані такі:

      data = [(2, 8485), (235, 15220), (448, 15287), (449, 23706), (452, 23706), (458, 23823), (464, 71663), (471, 71679), (537, 75980), (539, 77218), (543, 78685), (544, 91979), (546, 94672), (556, 99991), (557, 104972), (558, 119957), (559, 119981), (561, 124530), (563, 126689), (564, 129192), (565, 131792), (567, 137614), (568, 146256), (574, 148949), (575, 151202), (577, 152954), (578, 153245), (579, 158554)]
      

      bunyk

      Листопад 8, 2011 at 02:23

    • Нічогособі! Забрав назад, запрацювало. Ти крутий.

      bunyk

      Листопад 8, 2011 at 02:28

  2. Мораль: спати напевне треба більше. Але важко заснути коли тут так весело.

    bunyk

    Листопад 8, 2011 at 02:33


Залишити відповідь

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out / Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out / Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out / Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out / Змінити )

З’єднання з %s

%d блогерам подобається це: