UProLa

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

NixOS – дистрибутив Лінукса з декларативною конфігурацією

with 7 comments

Блукаючи по сторінках, пов’язаних з Haskell-ем, наштовхнувся на експериментальний дистрибутив Лінукса з цікавими властивостями. Особливо мене зацікавили наступні: можливість транзакційного оновлення системи та декларативне налаштування системи. Першими словами було “Це анріал”, але дистрибутив скачав і поставив (у мене якраз ArchLinux здох через апдейт драйверів). Певні враження та приклади приведу в даному пості.

Конфігурація NixOS

Менйтейнери знають про функ. програмування не з лівих вуст – головний девелопер вчився в Utrecht University, котрий подарував світу альтернативну GHC реалізацію Хаскеля. Власне він розробив спеціальну функційну мову для роботи з пакетами, в якій установка пакета або вибір певної поширеної опції є всього лиш “галочкою” у текстовому вигляді. Ось приклад, що я вже наставив собі у систему (файл /etc/nixos/configuration.conf):

# the system.  Help is available in the configuration.nix(5) man page
# or the NixOS manual available on virtual console 8 (Alt+F8).

{ config, pkgs, ... }:

{
  require =
    [ # Include the results of the hardware scan.
      ./hardware-configuration.nix
    ];

  boot.initrd.kernelModules =
    [ # Specify all kernel modules that are necessary for mounting the root
      # filesystem.
      # "xfs" "ata_piix"
    ];
    
  # Use the GRUB 2 boot loader.
  boot.loader.grub.enable = true;
  boot.loader.grub.version = 2;
 
  # Define on which hard drive you want to install Grub.
  boot.loader.grub.device = "/dev/sda";
  boot.initrd.enableSplashScreen = true;

  networking.hostName = "localhosted"; # Define your hostname.
  networking.wireless.enable = true;  # Enables Wireless.
  networking.useDHCP = true;
  networking.wireless.driver = "wext";
  # networking.wireless.userControlled.enable = true;
  networking.nameservers = [ "8.8.8.8" ];

  # Add filesystem entries for each partition that you want to see
  # mounted at boot time.  This should include at least the root
  # filesystem.
  fileSystems =
    [ { mountPoint = "/";
        device = "/dev/disk/by-label/nixos";
      }

      { mountPoint = "/storage"; # where you want to mount the device
        device = "/dev/sda8";  # the device
        fsType = "ext4";      # the type of the partition
      #   options = "data=journal";
      }
    ];

  # List swap partitions activated at boot time.
  swapDevices =
    [ { device = "/dev/disk/by-label/swap"; }
    ];

  # Select internationalisation properties.
  i18n = {
    consoleFont = "Terminus";
    consoleKeyMap = "us";
    defaultLocale = "uk_UA.UTF-8";
    supportedLocales = [ "en_US.UTF-8/UTF-8" "ru_RU.UTF-8/UTF-8" "uk_UA.UTF-8/UTF-8" ];
  };

  # List services that you want to enable:

  # Enable the OpenSSH daemon.
  # services.openssh.enable = true;

  # Enable CUPS to print documents.
  # services.printing.enable = true;

  # Enable the X11 windowing system.
  services.xserver.enable = true;
  services.xserver.layout = "us";
  services.xserver.xkbOptions = "eurosign:e";

  # Enable the KDE Desktop Environment.
  services.xserver.displayManager.kdm.enable = true;
  services.xserver.desktopManager.kde4.enable = true;
}

Гляньте, для прикладу, на рядок

# Use the GRUB 2 boot loader.
  boot.loader.grub.enable = true;
  boot.loader.grub.version = 2;
 
  # Define on which hard drive you want to install Grub.
  boot.loader.grub.device = "/dev/sda";

Достатньо всього лиш вписати в конфігу ці рядки і після ребілду система сама поставить GRUB куди їй там треба. Якщо ми змінимо версію на 1, то під-час ребілду буде автоматично скачаний перший груб і поставлений замість другого. Тобто, не обов’язково вручну скачувати, ставити і налаштовувати пакет, якщо для нього є описана опція – користуйтесь нею.

Інший приклад – мережа.

networking.hostName = "localhosted"; # Define your hostname.
  networking.wireless.enable = true;  # Enables Wireless.
  networking.useDHCP = true;
  networking.wireless.driver = "wext";
  # networking.wireless.userControlled.enable = true;
  networking.nameservers = [ "8.8.8.8" ];

В ArchLinux також спробували зробити такий конфіг мережі, але у них вийшло гавняно і новий синтаксис використовується не сильно. (До-речі, якщо вам вкрай не подобається вручну налаштовувати мережу, можна все то закоментувати і вказати опцію networking.wicd.enable=true; – всі налаштування будуть йти через wicd, котрий буде автоматично скачаний і поставлений.)

Далі ви побачите статичне монтування дисків. Замість спеціального синтаксису mount і /etc/fstab можна використовувати уніфікований, що є серйозним напрямком до User-oriented операційної системи.

Установка X і кедів – взагалі пісня. Простіше, мабуть, тільки галочка (але які нафіг галочки, коли навіть xserver не стоїть?)

Модифікація системи

Серед різноміїття дистрибутивів я надаю перевагу rolling-release варіаціям. Мені подобається, коли система оновлена “по максимуму”. Проте вибір, як такий, у мене невеликий – Arch Linux, Gentoo, NixOS, можливо ще щось. Арч при цьому має перевгу над Генту в плані наявності бінарних пакетів. Так ось, NixOS також має таку перевагу над Генту! Тобто, всі програми компіляться з сорсів, проте якщо є бінарник, то буде використаний саме він. Бінарники, в свою чергу, білдяться на спеціальній гідра-фермі, цілодобово, кожен день.

Всі пакети ставляться в юзер-спейс, тому для установки пакетів не потрібно root-права. Я поки-що не знаю, добре це чи погано, але це чудова причина для тих, хто юзає sudo без пароля, використовувати менше sudo без пароля.

Іншою цікавою особливістю є те, що якщо конфігурація системи змінюється, то це не призведе до втрати системи. Усі старі кофігурації не видаляються, і потім доступні у меню GRUB. Цим самим можна легко відкатити будь-які зміни системи, що радує (fallback image не завжди справляється з цією задачею, адже проблеми можуть бути в обв’язці ядра, що враховується конфігурацією NixOS.)

Миска дьогтю

Недарма NixOS виступає як експериментальна система. Один з Дебіан-майнтейнерів розкритикував її менеджер пакетів, коли хтось запропнував замінити dpkg і apt.

  • Готових пакетів доволі мало. В тому ж дебіану, генті та арчі їх в рази більше
  • Готових бінарних пакетів дуже мало. Навіть Chromium, і той поки-що не білдиться бінарно (а на моєму компі він компілився всю ніч, поки не здохла батарея…)
  • Замість dependency hell ми тепер отримуємо configuration options hell. Кількість опцій зашкалює і в майбутньому буде тільки рости. Думаю, скоро з’явиться якась графічна приблуда для цих опцій і ми отримаємо повноцінний MacOS *irony*
  • Якщо ви будете модифікувати систему старим способом (через конфіги /etc), то будьте готові ними пожертувати під-час чергового ребілду системи. Тру-способом є створення нової опції і підключення її в конфіг системи. Unix-way, кажете? =)
  • Все тормозить. В порівнянні з Arch
  • Ггюки присутні. Наприклад, kate під рутом не хоче запускатись
  • Думаю, проблема з драйверами для відеокарти тут стоїть дуже гостро.
  • Відсутність крауд-документації (гугл-отвєти, форуми, ком’юніті). Всі проблеми треба напряму вирішувати з девелоперами або в не дуже активному IRC-чаті (котрий, до-речі, мені сильно допоміг в установці системи). Гугл і ЛОР практично нічого не знають про NixOS.
  • Думаю, тут є серйозні проблеми з security, але це всього-лиш здогадка
  • В папці /bin знаходиться тільки один файл – /bin/sh ! kernel panic!
  • А знаєте, чого один? Бо всі програми ставляться в /nix/store/, і до них спереду дописується 160бітний хеш. Вигляда
    це приблизно так:

    [danbst@localhosted:~]$ ls /nix/store/ | head
    00418vqs74568frbp4bzb27wq0q7drd2-switch-to-configuration.sh
    00ix198j4hfbbkb2w18aiwiz73rr017l-libevent-2.0.17-stable.tar.gz.drv
    00j4kxw914408w5bwap970f7iljff955-upstart-tty4.conf
    01656gv7ysz8vj6qxnh5drqka6n1118n-closure.drv
    01a60wl2a2gg7pwcs7v4arx29173s9g3-kde.pam.drv
    01d61sgqavjph83c9qx9n05yjv1qblcl-gmp-5.0.5
    01dzpp03fsvc7xixg9sp2hdhi5iy9m3v-1k7b4mpfxpbcq5wih614z9g05w22ibwjq8wzh30xihl70q310zzq.nar-bsdiff
    01r9wqssr0m7h7hb13jkchn3g8zyjk6r-pth-2.0.7
    01w11lngp8s4lxllyr6xbmjfyrfkrn43-builder.sh
    0286r8g56dj2pvirgac079flz9gjnka2-font-cursor-misc-1.0.3.tar.bz2.drv
    

    ЖОПА. Переходити по автокомпліту до потрібного пакету тепер нереально.

  • …і ще багато-багато різних голімих приколів, котрі мене поки-що не чіпали.

Як висновок

Як висновок, я скажу, що система юзабельна в певних межах і цікава, в межах своїх унікальних властивостей. Як на робочу машину я би не ставив, але на домашню типового лінуксойда – то цілком навіть дуже непогано. Подивимся, чи зможу я на ній прожити до кінця літа, поставити xmonad, ATI-драйвери, wine та Windows-ігри. Якщо особливо серйозних проблем я з цим не отримаю, то значить WIN. Арівідерчі!

Advertisements

Written by danbst

Червень 24, 2012 at 09:34

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

Tagged with ,

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

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 ()

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

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

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