madf

Є одна кльова софтинка, яку я давно використовую. Але мене задовбували у ній два дуже неприємних баги: хтозна-чого вона жерла CPU як не в себе, і її вікно іноді ховалось під інші вікна (хоча завжди повинне бути on top).

Спочатку я думав пофіксити швиденько баги (у мене були ідеї щодо high CPU consumption) і відправити патчі автору, але коли я глянув код... Коротше кажучи, простіше було її тупо переписати. Тому я форкнув її (GPL v. 3) і почав корячити. Відучити її жерти проц було нескладно, мої підозри підтвердились (колись давно я таке саме робив для Psi). І здавалось що і ховання під іншими вікнами вдалось виправити. Я „причесав“ код, трохи відрефакторив, зробив єбілд у локальному оверлеї і почав радіти життю.

Але виявилось що бага з хованням під вікнами так і залишилась. При чому я ніяк не міг визначити що саме викликає цю багу: одразу після старту все працює як треба, і тільки з часом вікно починає „ховатись“ — неначе соромиться... Я витратив купу часу намагаючись побороти цей баг, але марно. Тоді у мене закралась підозра що проблема у віконному менеджері — XMonad.
( Якщо вам не страшний код на Haskell можете зазирнути під кат )

Тут дехто вважає що я зануда, придовбуюсь до дрібниць і все таке.
Да, зануда. Да, придовбуюсь. Бо мені дуже неприємно отримувати багрепорти про Segmentation fault. Ні по пошті, ні в реальності, ні по телефону. І мені надзвичайно неприємно "червоніти" перед людьми яких я дуже поважаю!
Ладно, слухайте байку.
Пару років тому (ого, вже майже 2 роки пройшло) я домовився з одним студентом що він буде допомагати мені по проектам за певні гроші. "О!", думав я тоді, "Клас! Тепер справа піде!". Бо свого часу вже не вистачало тягнути усе.
Звісно, спочатку я дуже пильнував, детально переглядав кожний коміт, слідкував щоб було витримано стиль коду і не допускав тупих багів. Потім, через деякий час, я побачив що студент став писати більш-менш пристойний код і пильнував уже не так сильно (бо який же тоді сенс наймати когось писати код щоб потім самому "просіювати" кожний його рядок). Перевіряв виконання тікетів ну і іноді рекомендував як зробити краще. По термінам виконання задач не сильно "звєрствував" - давав 1-2 тижні. І наче все йшло непогано, проект просувався, я встигав займатись іншими справами. Єдине що мені з часом перестало подобатись - з’явилось відчуття що студент все більше став затягувати виконання задач щоб наприкінці місяця швиденько їх позакривати.
Прийшов час показувати нові фічі замовнику. Тим паче я розрекламував що тепер софтину можна буде запустити на маках від чого радість замовника не мала меж. Як я вже писав раніше, на маках все завелось буквально з першої компіляції. Ну так, з косметичними правками. Я перевірив основний функціонал, зібрав dmg, інсталлятор для вінди і віддав замовнику на тестування.
А сьогодні отримав по телефону SIGSEGV. Надзвичайно приємно. При тому що мак уже пора віддавати.
Ну по симптомам я уже зрозумів де там бага і пообіцяв швиденько виправити. Правда, на всякий випадок, попередив що можу за сьогодні не встигнути, але постараюсь. Мій оптимізм швидко вщух коли я заліз у код. Ох... Дані що мають бути в одному місці розкидані по купі модулів, зв’язано все через подвійні вказівники, MVC перетворене на гру "вгадай де мої дані", вказівники на NULL ніхто не перевіряє (як і return code), а сигнали оброблюються де завгодно крім очікуваних місць. І тепер що виправити тривіальну помилку треба перелопатити весь цей код, порозкладати дані по місцям, викинути половину сигнально-слотової каші... Одна із останніх задач була розібрати на "запчастини" великий MainWindow, виділити окремі віджети-view і прив’язати до моделі з даними. Задача була виконана, великий клас був розібраний на купку маленьких, але... Мабуть, MVC не на стільки очевидний і зрозумілий паттерн як мені здавалось.
Я не знаю, більшість речей мені здаються очевидними. І не такий вже у мене й великий досвід у розробці і супроводі ПЗ щоб мати якісь переваги перед початківцями, тим паче працюючими під контролем. Чому, чому, чому не можна віднестись до справи відповідально?!
Я втратив віру у людей. Краще буду писати все сам щоб не розгрібати подібні "приколи" в останній день. Скажіть мені (хоч я і не повірю) що все буде добре!

З релізом мене!
Останні два тижні пройшли під девізом "ні дня без комміту". Один день всього пропустив, зате в інші по десятку коммітів робив.
( Чим же я займався? )
Дякую компанії Vikos за наданий у тимчасове користування MacBook і своїй сестричці oxymona за тестування отриманих dmg. Код і пакунки, як завжди, лежать тут: http://code.google.com/p/qia. Є українська і російська локалізація.

Вчора товариш написав про свою реалізацію гри "Життя" Конуея. Я колись у школі написав багато її реалізацій - на ZX Basic, QBasic і Turbo Pascal. Я у неї навіть грав "вручну" - на шаховій дошці :)
Ну і вирішив тряхнути стариною - написати на plain C++. Колись, на другому курсі універу, коли я самотужки вивчав C++ у мене була думка написати реалізацію, але я тоді уже сидів під Linux і NCurses мені здалися дуже злими. А у графіку я взагалі тоді не ліз - навіть без X-сервера сидів :) Такшо тоді воно так і залишилось не реалізованим.
Першу реалізацію (чисто консольна версія, навіть без ncurses) я осилив хвилин за 30-40. При чому воно запрацювало одразу після успішної компіляції :)
Дивитись на неї можна тута: Conway's Life (CLI version)
Основа всього - клас Field. Поле клітин представлене як std::vector - звичайним одномірним вектором. Доступ по координатам стандартний: x * width + y. У методі Cycle захована вся логіка: в залежності від кількості сусідів наповнюється новий вектор, після чого відбувається швидкий swap. Метод що підраховує кількість сусідів страшнуватий, але працює. І я не знаю поки як його можна зробити красивіше.
Друга реалізація - той самий клас, але з GUI на Qt4. Витратив на неъ близько 2 годин. Спочатку близько години малював крапками і розважався з QImage і scanLine. Вийшло непогано, на полі 1000x1000 давало близько 2 fps. Потім залишив ці оптимізації і тупо, через QPainter зробив scalable версію. Ще хвилин 30 зайняло прикручування контролів і таймінгів.
На 100x100 Field::Cycle() відпрацьовує за 3 мс на одному ядрі AMD Phenom(tm) II X4 955. Малює швидко, окремих кадрів не видно. На 1000x1000 з квадратиками по 1 пікселю Field::Cycle() працювало за 342 мс, але давало десь 0.3 fps. Збирав у релізі, без оптимізацій.
Подивитись на цю версію можна тута: Conway's Life (Qt version). Реалізацію Field не змінював.

Колега залив проект на Launchpad:
https://launchpad.net/~spiderx-web/+archive/qia
Локальне дзеркало для клієнтів ISP GTS:
http://qia.update.dp.ua
Проект на Google Code:
http://code.google.com/p/qia/

Пару днів тому, начитавшись відгуків про новий графічний рушій Qt raster вирішив спробувати. Зі стандартним рушієм у мене у Konqueror підторможувала прокрутка (особливо на великих сторінках). Коли запустив з --graphicssystem raster - прокручувати стало плавно і без ривків. Круто, що тут скажеш...
( Read more... )

Щоб записати у QString Unicode-текст треба використовувати QString::fromUtf8(const char * data, int size = -1) або QString::fromWCharArray(const wchar_t * data, int size = -1). Якщо не вказувати size явно - треба щоб рядок закінчувався символом \0. Взято звідси.

Перші враження.
Пофікшені старі баги (старі - від C++ Builder v.6). Функціонал - той-же.
Додані градіентні тулбари та фон для віконечок. Якась ідіотська система допомоги. Ставиться декілька годин. Глючить (відкрив контекстне меню на одному із інструментальних віконечок і не зміг закрити - прийшлось закривати весь C++ Builder).
Поки "грався" з компонентом XMLDocument - зненавидів цю програму вкрай і ще більше полюбив Qt.