UProLa

Неокріпші думки

Про тетріс, Хаскель і типи

with 4 comments

Писав я недавно один проект на Python і зрозумів – відсутність типів у пайтончику заважає розбиратись у чужому коді. Щоб взнати, який тип має змінна доводилось вписувати print(var) і перезапускати програму (а вона була графічна). Це не особливо напрягало, проте тепер я розумію, чому вказувати типи потрібно навіть в “очевидних” випадках – не всім воно очевидно.

З такою логікою я взявся і дописав типи до більшості функцій свого тетріса на Хаскелі. Заодно перейшов від чисто функціонального програмування до типо-функціонального (тут немає помилки в слові “типо”).

https://gist.github.com/2281537 – для тих, хто спершу дивиться код.

Ну, по-перше, код збільшився на 45 рядків. Печалька… По-друге, в намаганнях зробити кросплатформенність я так нічого і не досяг, для запуску коду під лінуксом потрібно модифікувати код. Печалька :`( …

Випадковий елемент

> randomItem xs = (xs!!) <$> randomRIO (0, length xs - 1)

Навчу вас читати цей код. Першим ділом дивіться на символ <$>. Це потужний символ, він розділяє вираз на дві частини – ліву і праву. Все, що зліва – функція. Все, що справа – дані. Символ <$> застосовує функцію зліва до даних справа.

Чому саме так? Про це дещо нижче. Глянемо тепер на ліву частину – функцію. Символ !! еквівалентний отриманню елементу по індексу. Те, що в нормальних мовах xs[2] в Хаскелі записується як xs !! 2. Якщо xs – список, то xs !! 2 поверне елемент цього списку. А чому дорівнює xs !! ? Це уже буде функція, що приймає на вхід індекс а повертає елемент списку! Тому запис (xs!!) еквівалентний (\index -> xs !! index), тільки коротший.

Справа знаходяться дані, що генерує функція randomRIO. Вона повертає випадкове число з інтервалу, вказаного у дужках. Єдина проблема – це випадкове число загорнуто у монаду IO, з якої, як відомо, ніщо не може вийти.

Тепер ще раз про <$>. Цей оператор вводить функцію зліва в монаду IO справа і спокійно застосовує функцію до даних. Загальний результат залишиться в монаді IO, що, в принципі, також непогано.

> randomItem xs = randomRIO (0, length xs - 1) >>= (\index -> return (xs !! index))

Ось так в коді виглядає те, що я описав. Але всі пишуть через <$>, бо так простіше.

Таймер

> -- | Таймер для відмірювання одного інтервалу
> type Timer = ( Rational  -- ^ показник часу на початок відмірювання
>              , Rational) -- ^ інтервал відмірювання (в секундах)

> -- | Створити новий таймер
> createTimer :: Rational    -- ^ Інтервал часу для таймера (в секундах)
>                -> IO Timer

> -- | Оновити стан таймера. Друге поле кортежу результату показує, 
> -- чи прошов вказаний у таймері інтервал часу
> updateTimer :: Timer -> IO (Timer, Bool)

Об’ява такого типу дещо спростила роботу з часом за рахунок інкапсуляції коду. Тепер мені не доводиться заморочуватись параметрами таймера при передачі часу в mainLoop, що радує. Також зауважте спосіб анотації параметрів.

Таймер використовується, наприклад, у main:

> main = do timer <- createTimer 1
>           score <- gameLoop (World (emptyScreen 10 12) Nothing) 0 timer
>           putStrLn ("Your score - " ++ (show score))

Світ

> data World = World [[Char]]            -- ^ поле гри
>                    (Maybe ( Int        -- ^ координата X фігури
>                           , Int        -- ^ координата Y фігури
>                           , [[Char]])) -- ^ геометрія фігури

Стан світу мені довелося загорнути в окремий тип даних. Якщо чесно, це тільки ускладнило все. Наприклад, поворот фігури в світі тепер займає у 4(!) рази більше коду, ніж раніше.

було

> rotateFigure (screen, (x, y, fig)) = (screen, (x, y, rotate fig))

стало

> -- | Поворот фігури проти годинникової
> rotateFigure :: World -> World
> rotateFigure (World screen figure) = World screen (rot <$> figure)
>     where rot (x, y, fig) = (x, y, rotate fig)

Ось так ось… Але чого не зробиш заради читабельності! До-речі, бачите знову цей символ <$> ? На цей раз він працює не з монадою IO, а з монадою Maybe. В загальному, він працює з будь-яким аплікативним функтором, а оскільки монади являються функторами, то символ працює і з будь-якими монадами. Для списку він навіть має окрему загальноприйняту назву – map (девелопери спеціально залишили цю застарівшу назву map для того, щоб зробити помилки компіляції більш зрозумілими, коли справа йде про списки – все для новачків!)

Наслідки типізації

> -- | Визначити, які рухи довзолено фігурі в заданій позиції
> findPossibleMoves :: World
>                      -> ( Bool  -- ^ рух вправо
>                         , Bool  -- ^ рух вліво
>                         , Bool  -- ^ рух вниз
>                         , Bool) -- ^ поворот проти годинникової

> -- | Об'єднує поле з фігурою та викидує заповнені рядки.
> removeFilledLines :: World 
>                      -> ( [[Char]]  -- ^ об'єднане з фігурою поле гри
>                         , Int)      -- ^ кількість заповнених та видалених рядків

> gameLoop ::    World  -- ^ Стан гри
>             -> Int    -- ^ Рахунок
>             -> Timer  -- ^ Таймер, що відмірює час падіння фігури на один блок вниз
>             -> IO Int

Як глобальним наслідком тотальної типізації стала … поява коментарів до параметрів функцій! Якщо не впадлу написати тип параметру, то вже й не впадлу написати комент до типу. Хоча, якщо порівняти gameLoop з попепередньою версією:

> gameLoop :: ([[Char]], (Int, Int, [[Char]])) -- ^ світ
>              -> Int -- ^ рахунок (скільки ліній заповнено)
>              -> Bool  -- ^ необхідність рефреша світу
>              -> (Rational, Rational) -- ^ стан часу
>              -> IO ()

То прогрес як на долоні. Якщо постаратись, то за допомогою лінз та реактивного програмування можна буде добитись ООПшної лаконічності при модифікації стану гри, над чим я ще попрацюю.

Advertisements

Written by danbst

Травень 31, 2012 at 08:54

Оприлюднено в Програмування

Inline Skates

with 2 comments

Коли людям кажуть про ролики, то перші як правило уявляють собі їх неначе заміну льодовим ковзанам.

А зі словом “роллер” у першу чергу асоціюють маленьку дитину, яка хоче літом покататись на льоду, але за відсутністю останнього їй доводиться перекочуватись по асфальту.

А ще, коли кажеш “я вчора катався на роликах” люди уявляють, ніби ти неспішно їздив навколо дому з друзями десь хвилин 30.

Мені шкода людей, котрі катаються на роликах за 400 і менше грн.

Ще бісить, коли люди ігнорують роллерспорт як спорт або взагалі як спортивне заняття.

Все це настільки пригнічує, що хочеться провести невеликий лікбез.


Швидкість

Ролики чудово втамовують спрагу до швидкості. Поєднайте ККД велосипеда з контролем при бігу – суміш є вибуховою! Особисто я розганявся до 60 км\год на спуску по Татарській, а в крейсерній по прямій стабільно тримаю 30-35 км\год. Це швидкість уже не дитяча, якщо враховувати ймовірність падіння на асфальт – шкіра стесується немов рубанком!

Відстань

Чого немає у ковзанах, так це свободи пересування. Обмеження бортиками. При катанні на роликах ви обмежені тільки наявністю асфальту. Візьміть місто з хорошим покриттям, наприклад Київ, підрахуйте його розміри та побачите, що на роликах (як і на велосипеді) місто можна перетнути за годину-дві. Пішки цю відстань можуть подолати тільки бувавші туристи, а на роликах навіть такі неспортивні люди як я отримують повну свободу пересування.

Свобода пересувань

До речі, про свободу. Ролики – це вам не велосипед, їх можна запихнути в рюкзак і перетворитись у пішохода =) Також роллери поки-що користуються недорбками у ПДД: дозволено як рух по тротуару так і по дорожному полотну (першій полосі і на крейсерній швидкості). У деяких супермаркетах навіть довзоляють їздити на роликах, і це фактично є признаком адекватності менеджерів (таке спостерігається у Сільпо та Великій Кишені).

Свобода подорожей

По таких великих містах як Київ також можна подорожувати. Якби я не почав кататись, так би і не довідався про паркову зону ВДНГ, Центральний ботсад, Парк Партизанської слави, парк Пушкіна та парк КПІ, ландшафтні парки Феофанію, Співоче поле та Пирогово, Маріїнський парк, лісову зону біля Міністерського, Пущі-Водиці та в Дубках.

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

Ось кілька останніх маршрутів: 1, 2, 3, 4, 5

Ніч

Одним з досягнень свого життя вважаю нічні поїздки. В той час як мої однолітки проводять ночі по клюбах, мені був відкритий весь нічний Київ. Місяць, зорі, темне небо, неонові лампи та жовті придорожні ліхтарі – вся радість романтичного споглядання може бути доповнена раціональною складовою – відсутність машин та людей. Марафонські маршрути та високошвидісні спуски є неодмінним атрибутом нічних покатух.

Дуже приємно усвідомлювати, що хоча б щось ти робиш не як усі, і вдвічі приємніше, коли знаєш, що це не кожному дано. Нехай собі хтось і далі МРІЄ про нічні прогулянки, а я ж ними ЖИВУ!

Ось кілька останніх маршрутів нічних: 1, 2, 3, 4.

Зустріч сонця

Іноді я приїжджаю на оглядову точку, десь так о 5-6 ранку і помічаю людей, котрі прийшли зустріти сонце. Після того як воно встало, вони збираються та йдуть кудись деінде – додому, на роботу, поспати. Тоді я розумію – не я один люблю зустрічати новий день та робити спостереження “як же сцуко сонце швидко встає, от зараза!”

Як правило це поєднується з нічною, тому більшість роллерів волею чи неволею повинні любити ямакаськи (так у нас це називається). Хоча іноді збираються олдскул, цебто відомо тільки час та місце зустрічі і кожен добирається сам своїм ходом. Ось цих людей уже справді можна назвати фанами Сонця!

Спорт

Серед знайомих роллерів відрізняються люди, котрі намагаються бути кращими. Справді, вихід за межі льодової зони породив шість нових справді спортивних гілок: це слалом, спідскейтінг + даунхіл, агресив, слайди, стрибки та чаклуни. Кожен з них пов’язаний з фізичними або ментальними тренуваннями.

1. Зірка артистик-слалому – KSJ (Kim Sung Jin) – стрибає між конусами. Зверніть увагу на обертання на одному колесі(!), стрибки на одному колесі(!!) та зміну напрямку ноги при їзді на одному колесі(!!!). Один з небагатьох, хто вміє танцювати в такт музиці.

2. Якесь даунхіл відео – “відчуй себе машиною”

3. Яскравий приклад агресивного катання – повна відсутність страху та мізків!

4. Хорошо скомпонована підбірка слайдів від наших північних сусідів. Я так не можу =) але вчуся

5. Культура стрибків у Парижі. Зверніть увагу на бекфліп (сальто назад) і фейкі-720 (2 повних обороти спиною вперед) – це на даний момент топ-трюки. Рекордом висоти поки-що є 1.55 метра.

Чаклуни

Якщо коротко – це дитяча гра у заморозки на роликах. Якщо реально – це порівнювана з футболом та хокеєм виснажлива боротьба двух команд. Наразі гра визнається тільки в країнах СНГ, але цього достатньо щоб проводити міждержавні чемпіонати.

Ролики

Якщо не говорити про дуже вузькоспеціалізовані варіанти, то є кілька правил при підборі роликів. Це міцний шелл (зовнішня сторона ролика), по можливості виймаємий лайнер (внутрішня м’яка частина ролика), залізна рама (там де тримаються колеса), колеса з великою кількістю “м’яса” (поліуретанова складова) жорсткості 84А, розбірні підшипники з хорошою змазкою (якоюсь Літол-овою або заводською) та зручною геометрією бута (бажано, щоб була присутня бокова підтримка ноги та хороша фіксація стопи).

Один ролик важить від 1.5 до 2 кг.

Догляд за роликами

Так само як ковзани потрібно час від часу заточувати, так і за роликами потрібно доглядати. Після поїздок по воді потрібно промивати та перезмазувати підшипники. Після активних тренувань потрібно переставляти колеса (бо внутрішня сторона сильніше стирається ніж зовнішня) для рівномірного стирання. Після певного діаметру колеса краще змінити. Раз у пів-року ролики (або тільки лайнер) потрібно прати – а то запахи йдуть неприємні. Часто бувають поломки (наприклад, баклі), також вірогідною є ситуація загублення погано закручених вісьок та колес.

Роллери

У великих містах роллери утворюють субкультуру. Наприклад, в Києві кількість активних роллерів складає близько 300 людей. Ви скажете – “мало”? Ну, якщо отримати 300 друзів, просто одягнувши ролики на ноги для вас – це “мало”, тоді дивно чого ви читаєте цей пост =) Я так і не навчився відрізняти їхні риси, але мені подобається знаходитись у їх компанії: надійно, зручно, весело та приємно ) Люди то є завжди добре.

Падіння

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


Ну що ж, основну частину розповів, нероллерам більше знати і не потрібно. Хотілось би, щоб люди на нас дивились не як на психів, а як на нормальних психів. І щоб розуміли серйозність даного заняття. Думаю, ще років 5-7 будемо тероризувати Київ, а потім уже люди звикнуть =)

Ось так.

Written by danbst

Травень 16, 2012 at 00:55

Оприлюднено в 1, Пости

Про мову

with 15 comments

Мова є проблемою. Вірніше, сучасне різнобарв’я мов є проблемою. Люди думали, що machine translation цю проблему знівелює, але все сталось не як гадалось…

Як варіант вирішення, можна заставити всіх людей перейти на спілкування одною нейтральною мовою, Esperanto. В цьому випадку жоден machine translator не знадобиться. Варіант хороший, але тільки в теорії, бо люди щось до нього не тяжіють.

Я пропоную симбіоз MT і створення нової мови. Придумуємо діалект мови (української, наприклад) – правила граматики, слова та звуки таким чином, щоб обрана мова стала регулярною. Менше різних винятків, більш строга орфографія. Виконання МТ для такої мови буде на порядок простішою задачею, а отже буде доступним ріалтайм автопереклад голосу. А вивчення буде простішим, саме через високу схожість з рідною мовою.

Звісно, ця мова потрібна не для художньої літератури, а щоб можна було швидко зкомунікуватись з іноземцем по важливому питанню – переговори юридичних осіб, обмін наукових знань, орієнтування у незнайомій країні, листування.

Written by danbst

Травень 7, 2012 at 17:30

Оприлюднено в Програмування

Інший Інтернет

with 3 comments

Чи такого результату прагнули творці Інтернету? Де довгоочікувана семантична павутина? Чому тільки Гугл знає що і де лежить? Навіщо XML у якості бази (попри усю свою збитковість)? Хто сказав, що JavaScript повинен бути стандартом де-факто (попри усю свою хакнутість)? Хто сказав, що на RFC постять тільки хороші ідеї?

Ці та подібні питання мене бентежать уже давно, і вихід я бачу тільки один (якщо ви мене знаєте, то здогадатись не важко) – свій Інтернет.

Свій Інтернет

Разом з тим я багато не хочу.

Всього-лиш розділити дані (пригодні для семантичних зв’язків) (котрі власне і є КОНТЕНТОМ) і сайти (котрі насправді є графічними інтерфейсами “програм”).

Щось типу такого: site://… буде віддавати бінарник програми, котра власне і займається відмальовкою сайту у браузері, а doc://… буде віддавати конкретний шматок контенту, заданого через URI.

Цим самим буде об’єднано JavaScript, CSS і верстка HTML у суцільну нерозривну платформу. Вони ж бо один без одного існують слабо, але разом з тим мають добру модульність. Згодом у цій зв’язці можна буде замінити поганий інструмент на хороший, що призведе тільки до підвищення якості наданих сервісів.

А всі “текстові” та семантично зв’язані документи будуть спокійно хоститись на URL-ах зовсім інших типів у базовій розмітці (той же HTML) або у будь-якому іншому контент-форматі (PDF, PNG, FLV, TEX), причому теги будуть закодовані у самому URL (наприклад, doc://mysite.ua/video/recentvideo/vd01.flv – тут video та recentvideo виступають як теги). І не будуть залежати від стилів та джаваскриптів (популярні елементи типу спойлерів або підсвітки коду можна стандартизувати, якщо буде буря протестів).

Ось так. Коментарі? Пропозиції? Уточнення? Питання аудиторії такого Інтернету, до-речі, не стоїть – ті, кому це потрібно, – знайдуться 😉

Written by danbst

Квітень 22, 2012 at 18:06

Оприлюднено в Пости, Програмування

Випадково знайшов у завалах записів дворічної давності…

with 2 comments

Заповнював я анкету для прийому на роботу і зрозумів, що я – ніхто для роботодавця. В поле “Професійні навчики” не знаю, що вписати – знаю багато, проте професійно – нічого. В поле про зарплату я взагалі не знаю, що писати, поки що не можу себе оцінити і разом з тим боюсь помилитись при оцінці.

“Если бы вы могли выбирать себе работу или дело по душе, не будучи ограниченными никакими рамками, что бы Вы выбрали?” – Мені дууже хотілось написати “нічого не вибрав би”, що знову підтверджує мою нелюдскість.

“В чем по вашему мнению заключается профессионализм в работе на которую Вы претендуете?” – Звідки я знаю, що важливе при написанні запитів до БД? Це, власне, показує, що і про БД я особливо нічого не знаю.

“В какой «зоне жизни» Вы считаете себя наиболее реализованным?
(личная жизнь; семья,/дети; друзья / общественная деятельность; работа/ карьера; здоровье; образование / самообразование)” – капець. Виявилось в ніякій з перечислених. Знову я не людина.

Тоді ж і взнав, що англійську я знаю досить посередньо – читати щось зможу, але говорити і писати – не в цьому житті. А розхвалений на олімпіадах мій французький забув ПОВНІСТЮ!

Середній бал – 3.6-3.8 . З однієї сторони, бали не показник знань, з іншої – показник лінивості та намагання протидіяти (або шукати прогалини у) системі. Роботодавцю не потрібен такий робітник.


А що власне потрібно роботодавцю? а) Щоб працівник мав конкретний напрям на спеціальність (в моєму випадку – БД); б) щоб оцінював свої сили по заслугам, а не рандомізовано; в) щоб шарив ін. мови ДОБРЕ і міг це довести у будь-який момент; г) щоб мав можливість довести свою працелюбність, працеготовність і працеможливість.

Я підпадаю тільки під пункт “працеможливість”, і то, це навіть не факт, а припущення.

Проблема в тому, що у мене немає спеціалізації. Є відривочні знання, які не годятся ні окремо ні в цілому. І вибравши якийсь напрям я потім, мабуть, все життя буду себе картати, що ось такий я дебіл, треба було вибирати зовсім інше.

Хоча імовірніший такий варіант – мене буде мучити совість, що на вибір неправильного варіанту повпливала недосконала система, на яку я не зміг навести вчасних змін. Якби я встиг змінити систему, то тоді зміг би (за допомогою системи) правильно вибрати спецальність.


В зв”язку з цим можу зробити висновок – я частково не людина, і думки у мене іноді не людські. Тому при читанні деяких моїх постів згадуйте дану річ і враховуйте її в своїх коментарях.

Якщо комусь мої думки здаються неправильними, згадуємо слова Тарасова – треба вийти за межі життя, щоб побачити мету. Треба вийти за грані розуму, щоб зрозуміти ідею.(пафосно, але що поробиш)

22 квітня 2010 р.

Written by danbst

Квітень 15, 2012 at 19:40

Оприлюднено в 1

Нова нав’язлива ідея – Підтримка проекту

with 11 comments

Піднімемо питання maintainability коду. Або по нашому – “Який код легше підтримувати на протязі тривалого терміну”. Як правило, обговорення цього питання завершуються дуже швидко посиланнями на “авторитетного автора” або на “власний досвід”. Проте, це відповідь дилетанта, а нам (мені, цебто) потрібно щось більш конкретніше.

Зауважу, що проблемне поле не є цілиною, тобто, люди уже давно ставлять експерименти по підтримці коду. Фредерік Брукс, для прикладу, уже давав певні оцінки, а в наш час люди типу <a href=”http://www.dawis.wiwi.uni-due.de/team/stefan-hanenberg/”>Stefan Hanenberg</a> займаються <a href=”http://en.wikipedia.org/wiki/Experimental_software_engineering”>Empirical Software Studies</a>, як одним з методів аналізу мейнтейнабіліті та швидкості розробки.

Я в свою чергу пропоную ще один підхід (можливо він уже описаний десь). Він базується на наступному алгоритмі:
1. Складається мінімальне завдання (ТЗ), яке неважко виконати, проте воно може відображати складність проекту або його частини.
2. Складаються форки завдання. Форк завдання – це якби “завдання на доробку”, потенційна ситуація, що станеться в процесі підтримки коду.
3. Завдання анонсується піддослідним, незалежним, командам розробників. Потрібно його зробити, включно з форками завдань. Ключовою складовою є “не робити більше, ніж проситься в завданні, і при цьому повністю відтворювати функціонал”. Фактично, пункт 3 імітує процес “підтримки коду”.
3.1 Одна частина команд повинна виконати завдання як бажає, будь-яким методом
3.2 Друга частина команд повинна виконати завдання за мінімальний час
3.3 Третя частина команд повинна виконати завдання з максимальною оптимізацією
4. Після завершення першого етапу, кожна команда модифікує свій код для мінімізації наступних параметрів
– сумарна кількість рядків у всіх diff виконаних форків і оригінального завдання
– кількість рядків оригінального завдання, без фанатизму
Фактично, від кожної команди ми отримаємо приклад “ідеально легко-підтримуваного коду”
5. Зворотній зв’язок – модифікація ТЗ, пропозиції нових форк-завдань
6. Аналіз кращих представників коду, селекція у фінальну ітерацію
7. Видача новим командам цих відібраних зразків коду (тільки оригінал! форк solutions не даються) і завдання виконати всі форки.
8. Селекція нових кращих представників коду (селекція по швидкості виконання завдань всіх форків окремою командою)
9. Аналіз цих представників коду – які структури даних використовуються, які алгоритми, як організовано код, на якій мові все це написано, які технології використовуються, середня швидкість виконання одного завдання, оптимальність роботи. Показник “maintainability” буде автоматично максимальним, оскільки саме для його максимізації і виконувалися всі 8 кроків.

Щоб вам легше було представити цей процес, приведу приклад. Нехай в якості оригінального завдання вибрано “написати Тетріс”. Проект на основі цього завдання буде в певній мірі репрезентувати наступні класи задач: відео-гра, інтерактивна програма, простий проект. Я вже спробував описати мінімальний тетріс, ось цей опис:
– кросплатформенний
– консольне поле, повна перемальовка екрану (тобто, GotoXY використовувати не можна)
– фіксований розмір – 10 * 12 блоків, обмежений границею з одного символу ‘*’
– розмір блоку – одиничний символ ‘#’
– управління вліво (h), вправо (l), поворот за годинниковою стрілкою (Space), вихід (q)
– швидкість падіння фігури – 1 блок в секунду
– знищення заповнених ліній
– результат виводиться після завершення гри як число заповнених ліній
– поворот фігури неможливий, якщо в результаті виникне перетин або вихід за межі поля
– автовихід, якщо поле заповнилось доверху

В якості форків використовуються такі завдання:
– додати параметризацію (налаштування)
— через параметри командного рядка
— через конф. файл заданого формату
— через XML-конфіг
— в якості параметрів параметризації вибрати розмір поля, розмір блоку, клавіші управління, швидкість падіння
– додати лог статистики
– переписати відображення через
— curses (втрата кросплатформенності)
— SDL
— DirectDraw (втрата кросплатформенності)
— OpenGL
– зробити кожну падаючу фігуру кольоровою (на вибір з 16 кольорів)
– додати рівні: кожні 10 заповнених ліній збільшуйть рівень. Від рівня залежить швидкість падіння
– додати обгортку гри: гейм-менюшку, паузу, вибір профілю\користувача
– додати анімований фон
– додати кнопку швидкого падіння
– зробити анімацію знищення заповненого рядка і щоб був слоник біля поля і він стрибав, коли заповнюється 10-ий рядок.
– зробити так, щоб фігури підлягали гравітації 9.8 і відбивались (пружно, але вполовину) від нижньої межі
– зробити так, щоб замість квадратиків використовувались трикутники або шестикутники
– зробити так, щоб … тут ваші фантазії, яким повинен бути або не бути тетріс

Чим більше буде придумано завдань, тим більше можна буде говорити про адекватне моделювання реального розвитку проекту. Мінімальне дерево розвитку коду (щойно придумав) обов’язково буде щось та й означати, бо будь-що мінімальне має цю властивість. Тетріс – це всього лиш приклад, існує багато (скінченна кількість) класів задач, мінімальне дерево розвитку котрих зможе репрезентувати must have букет технологій та алгоритмів. І це неодмінно зможе бути використаним проти начальників, котрі вважають, що Сонце рухається навколо Землі.

Проблеми? Звісно, мільйони їх
1. Чи потрібне це комусь? Всі знають, що потрібно використовувати, мейнстрім уже сформований, хороші аналітики або девелопери з досвідом замінять всю твою ідею.
Відповідь: це науковий підхід до проблеми, а не експертний. Він ТОЧНО буде комусь потрібний, саме через його научність, а хороші аналітики та розробники можуть сумарно витягнути більше коштів, ніж грамотно спланована серія експериментів по maintainability
2. Цей параметр (maintainability) не є важливим при проектуванні проекту.
Відповідь: так, він не є критично важливим, проте аналіз мінімального дерева розвитку допоможе закласти правильно основу проекту.
3. Таку велику кількість квалфікованих розробників для постановки експерименту знайти неможливо!
Відповідь: взагалі-то так. Проте ідея, активна реклама та грамотна реалізація можуть зробити своє діло.
4. Даний підхід не підходить до алгоритмів, тому не запрацює і тут.
Відповідь: алгоритми справді неможливо оцінювати по цій методиці, тому що параметр “підтримка” для них немає змісту. Тільки проекти з великою кількістю зв’язків можуть отримати певний виграш від статистичного аналізу та селекційного відбору.
5. Дана методика репрезентує тільки доробки нового функціоналу, але не виправлення помилок.
Відповідь: так, помилки не будуть брати участь у історії селекцій. Проте в проекти на фінальній стадії селекції можна вводити зумисні помилки, і тоді форками будуть завдання на виправлення цих помилок.
6. Створення коректного завдання складніше ніж реалізація проекту.
Відповідь: реально найскладніша до вирішення проблема. Іншою схожою проблемою є тестування на відповідність завданню, робити це вручну може бути неможливим через велику кількість різноманітних проектів та параметрів. Методи автоматизації, юніт-тестингу, віртуалізації, симуляції та перевірки інваріантів справді повинні показати всю свою силу на даній задачі.
7. Централізація цього діла є must have (розробників не так багато, щоб розділятись), але тоді ми не зможемо говорити про “незалежність” результатів – буде всього лиш ще один “авторитет”.
Відповідь: можна централізувати тільки збір даних. Аналіз та інтерпретація даних виконується сторонніми групами науковців.

Основна моя думка наступна – якби це вже існувало на даний момент, я би обов’язково глянув на вибрані проекти у фінальну селекційну стадію, для розвитку своїх навиків проектанта. А поки-що я можу тільки мріяти і читати подальші баталії Haskell VS Python VS .NET VS Java, Ratpoison VS Ion VS xmonad VS KDE VS Gnome, битва за кращий спосіб зчитати XML-ку та безліч інших холіварів, де наразі існують тільки релігійні погляди без наукового підходу.

Written by danbst

Квітень 2, 2012 at 22:46

Оприлюднено в Програмування

Тетріс на Хаскелі

with 3 comments

Нещодавно я закінчив перший етап написання тетрісу, а саме добився того, щоб фігури падали і стакалися на дні дисплею. Перед тим, як поділитись своїми враженнями, хочу щоб бажаючі могли уявити собі складність (або простоту — як для кого) вирішення поставленої задачі на вибраному інстурменті — GHCi, найпопулярнішому інтерпретаторі Хаскеля.

Зазначу, що в даному пості зібрано задачі, які “щось виводять на консоль” і по своїй природі є процедурами як у Паскалі. Кожна наступна задача складніша за попередню. Розв’язки до задач надруковано білим текстом під умовою.

Нестандартні бібліотеки не використовуються! Єдиною довзоленою операцією при роботі з консоллю є вивід рядка на екран — putStrLn або print.

Задача 0 (розігрівка). Написати функцію clrscr, котра очищує екран консолі. Очищення робити через вивід великої кількості порожніх рядків.

Prelude> let clrscr = putStrLn (replicate 100 '\n')

Задача 1. Нехай задано дисплей гри у такому вигляді:

let screen = [ "           "
             , "           "
             , "           "
             , "  # ##   # "
             , "### ##  ###"
             ]

Вивести його на екран консолі.

Prelude> mapM_ print screen

Задача 2. Написати функцію showFigure, яка приймає на вхід h — висоту дисплею , (x, y) — координати фігури відносно правого верхнього кута дисплею, fig — геометрію фігури та виводить фігуру на консоль. Геометрія фігури задається у такому вигляді:

let figure = [" # "
             ,"###"
             ]

Prelude> let showFigure h (x, y) fig = putStrLn$ replicate y '\n' ++ foldr (++) "" (map (\line -> replicate x ' ' ++ line ++ "\n") fig) ++ replicate (h-y-1-length fig) '\n'

Задача 3. Нехай стан гри задано у вигляді наступного кортежу:

    let gameState = (screen, (x, y, figure))

Призначення елементів кортежу, сподіваюсь, зрозуміле. Завдання: написати функцію, яка виводить на екран цей стан так, щоб фігура знаходилась на дисплеї у вказаних координатах. Важливо, що якщо фігура частково або повністю виходить за дисплей, то не відображати невидимі блоки.

Я маю справді геніальне рішення цієї задачі, але воно не вміщується на полях даного посту.

Задача 4. Нехай стан гри задано у вигляді наступного кортежу:

    let gameState = (screen, Just (figure, x, y), Just figure, speed)

Відобразити на консоль наступне: дисплей у потовщеній рамці, поверх нього першу фігуру по вказаним координатам, зліва від дисплей відобразити другу фігуру (так звана “наступна фігура”), а також зробити зліва підпис “Швидкість: ” з вказаною швидкістю. Як видно по опису, фігури можуть бути не задані.

Признаюсь чесно: цю задачку я придумав, чисто щоб зайняти ваші мізки чимось корисним. Коли зробите, відішліть мені на e-mail розв’язок, я використаю у своїй грі =)

Written by danbst

Березень 3, 2012 at 21:37

Оприлюднено в Програмування