Додекалендар

Я вирішив стати майстром верстки, CSS3, SVG і всяких інших крутих штук. Для цього вирішив забабахати календар на гранях додекаедра, розгортку якого можна подивитись на моєму гітхабі: http://bunyk.github.io/dodecahedron/

Календар на гранях додекаедра вигідний тим, що це оригінально, бо 3d, а ще ним добре грати футбол чи інші ігри з м’ячем. :)

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

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

Найбільше сил пішло на те, щоб вирішити що React чомусь не хоче рендерити SVG, з D3 доведеться писати море коду, а Angular – саме воно, і треба його трохи підучити. Мені дуже сподобалось, надалі намагатимусь писати на ньому більше.

Розгортка і моделька

Розгортка і моделька з листка A4

А зовсім круті нерди можуть зробити аналогічний календар за допомогою Tikz в \LaTeX.


Filed under: Графіка, Кодерство, Нещоденник, Павутина Tagged: HTML, JavaScript, SVG

Трактат про Zope Component Architecture

Zope – це дуже-дуже старий фреймворк (історія почалася ще з 1995), але деякі його частини, а іноді і сам він використовуються в різних системах і досі. Наприклад Twisted використовує інтерфейси Zope (їх свідчення). Біда з ним в тому, що якась пристойна інструкція в інтернеті не доступна. Може вона й була там колись, але на жаль посилання не завжди працюють, а з такою старовиною як Zope – дуже часто ведуть в тупик 404. Своїм трактатом постараюсь цю біду хоч трохи виправити.

Ах, ще цікавий факт, ZCA з’явилась в Zope 3 (BlueBream), при спробі переписати все “правильно”, ігноруючи зворотню сумісність. Таким чином ситуація трохи нагадує ситуацію з Python 3. Тільки Python 3 з’явився в 2008, і здається таки має деякі шанси вижити, а от Zope 3 (BlueBream) – в 2004, і від нього відросли інші фреймворки, наприклад BFG, який об’єднався з Pylons і став Pyramid. Але цю всі історію дуже цікаво розповідає Пол Еверітт, один з тих хто все це почав. Він пояснить вам що Zope ще не вмерла, вона просто спить:

А тут мова піде лише про таку частинку Zope, як ZCA. І ми будемо писати код. З нуля!

Термінологія

Але почнемо з теорії, аби розуміти що збираємось писати.

  • Zope – Z Object Publishing Environment – фреймворк і веб-сервер які намагались публікувати у вебі об’єкти, ще в ті часи коли Apache віддавав статичний HTML і ганяв CGI скрипти. Шлях в URL в ньому відповідає не шляху до файлу зі скриптом, а шляху в ієрархії об’єктів. Кажуть то був прорив.
  • Компонент (Component) – якийсь код на Python, зазвичай клас, що реалізує інтерфейс. Компоненти поділяються на адаптери та утиліти (див. нижче).
  • Інтерфейс (Interface) – спеціальний клас, єдиною метою якого є опис функціоналу що реалізується іншим класом чи модулем. Вони реєструються в реєстрі компонент, і до цього реєстру можна робити запити “Дайте мені будь-ласка компоненти що реалізують оцей інтерфейс”. Класи можуть декларувати що вони реалізують (implement) певний інтерфейс. Екземпляри цих класів тоді надають (provide) цей же інтерфейс.
  • Сервіс (Service) – це об’єкт що працює з компонентами. Думайте про компоненти як про “речі”, а про сервіс – як про частину коду що бере ці “речі” і робить з ними щось корисне.
  • Реєстр компонентів (Component registry, також Site Manager) – база даних компонентів та інтерфейсів, сервіс за означенням вище. Якщо ви реєструєте компоненти в реєстрі, вони стають доступними для інших користувачів того ж реєстру. Існує глобальний реєстр компонентів що створюється автоматично, і можна використати ZODB як локальний реєстр.
  • ZODB – ZOpe Object Database – база даних об’єктів Zope. Використовувати її з компонентами не обов’язково, тому про неї якось іншим разом.
  • Глобальний реєстр компонентів (global component registry) – сервіс що автоматично створюється коли ваша програма що містить компоненти Zope запускається і наповнюється компонентами що описані в конфігураційних файлах ZCML. До глобального реєстру можна отримати доступ з будь-якого місця програми. Коли програма завершує роботу всі зміни внесені до глобального реєстру зникають і при наступному запуску він заново завантажується з ZCML.
  • Локальні компоненти (Local components) – це компоненти що не створюються в глобальному реєстрі компонентів. Зазвичай їх зберігають в ZODB, що також означає що вони персистентні, тобто можуть пережити перезапуск програми.
  • ZCML (вимовляється “зе-кемел”, Zope Configuration Markup Language) – XML файли, що описують компоненти які потрібно зареєструвати в глобальному реєстрі.
  • Адаптери (Adapter)- це класи що дозволяють використовувати з об’єктом нові інтерфейси. Клас адаптера містить виклик adapts() який вказує інтерфейс що адаптує адаптер, що означає що ви можете передати будь-який об’єкт, що реалізує цей інтерфейс, в метод __init__ класу адаптера, наприклад a = myAdapter(myobject). Тепер MyAdapter бере на себе обов’язок фронт-енда для myobject, таким чином, що будь-який інтерфейс реалізований за допомогою myAdapter, буде правильно працювати з myobject. В певному сенсі адаптер “огортає” адаптований об’єкт.
  • Фабрика (Factory) – це щось (якщо конкретніше, не щось, а утиліта, визначення якої буде нижче), яка створює компоненти та об’єкти. Це як більш високорівнева версія конструктора. Фабрика має бути об’єктом який можна викликати, і повинна реалізувати інтерфейс IFactory. Фабрики надають зручні засоби для доступу до конструкторів компонентів через реєстр компонентів, а не прямим викликом конструктора. Важливо зауважити що ZCM автоматично створює фабрики, коли ви реєструєте компоненти. В багатьох випадках це означає що ви не матимете справи зі створенням фабрики напряму.
  • Утиліта (Utility) – об’єкт який ви хочете додати до реєстру компонентів. Вона може бути будь-яким об’єктом мови Python, який може знадобитись іншій частині програми. Утиліта повинна реалізовувати принаймі один інтерфейс.

Я знаю що ви з цього словника майже нічого не зрозуміли. Не бійтесь, я теж. Далі ми розберемо це на практиці, і ситуація проясниться.
Read more »

Як я отримав швейцарський “диплом”

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

Але важливо те, що я пройшов курс функціонального програмування на Scala, який:

  • Базується на SICP.
  • Мову Scala викладає творець мови Scala. І він не тільки багато знає, він ще й вміє це доступно пояснити.
  • Мартін Одерськи – викладач Фередальної політехнічної школи Лузани – одному з двох політехнічних університетів Швейцарії. В іншому, Федеральній вищій технічній школі в Цюріху він в 89-тому отримав PhD, під керівництвом не аби кого, а Ніклауса Вірта. Який створив мову Паскаль – найвідомішу широкому загалу.
  • Задачі настільки добре покриті автоматичними тестами, що можна суто завдяки їм знайти в себе помилку, навіть не звертаючись до форумів. Форуми теж чудові, я двічі застрявав і двічі підказка знаходилась саме на форумі. (Що не означає що вам там викладуть готове рішення).

Ну і найголовніше – що я таки хоч один пройшов. Бо до того записувався на NLP, логіку, криптографію, гейміфікацію, і так і не набрав на жодному з них більше 5%. На цьому ж – 97.5%. Треба було показати собі що це простіше ніж здається, головне кілька місяців зберігати мотивацію, чи просто раз на тиждень застосовувати силу волі і садити себе за комп’ютер.

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

Третя мотивація – я хочу записатись на курс FRP. Що таке FRP – дивіться “Александр Соловьев — Functional Reactive Programming & ClojureScript “. Надихаюча доповідь яку можна розтягувати на цитати.

Як виявилось для успіху потрібно було робити те, що я майже від 8-го класу ніколи не робив – домашні завдання. І здавати їх вчасно, бо за кожну добу спізнення знімають 20% балів. Через це я набрав не 100%. Звідси висновок – не варто здавати лаби в останній момент, бо може ще якась помилка вилізе.

Фото з лекції

Фото з лекції

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

Коротше кажучи моя подяка професору Одерськи:

Great introductory course on functional programming, great tasks, and great lectures. Will also inroll into your reactive programming couse. Keep going!


Filed under: Кодерство, Нещоденник Tagged: добре, освіта

Вступ до D3

D3 (розшифровується як DDD, що означає Data Driven Documents) – то бібліотека для написання JavaScript візуалізацій.

Бібліотеку можна скачати з сайту, або під’єднатись до CDN:

<script type="text/javascript" src="http://d3js.org/d3.v3.min.js"></script>

Тепер, щоб змінити наприклад текст якогось елемента, можна за допомогою d3 цей елемент вибрати, і відредагувати його текст:

d3.select('#field').text('hello world!')

Метод select приймає такі самі селектори CSS як і jQuery, тому тут нічого несподіваного для тих хто користувався jQuery (чи CSS) не повинно бути.

Можна також додавати елементи:

d3.select('body').append('p').text('hello world!')

Можна змінювати оформлення елементів:

d3.select('body')
   .append('p')
   .text('hello world!')
   .style('color', 'red')

Цих маніпуляцій з елементами вже досить щоб малювати щось з SVG:

var panel = d3.select('body');
var width = panel[0][0].clientWidth - 2;
var height = panel[0][0].clientHeight - 2;
var svg = panel.append('svg')
    .attr('width', width)
    .attr('height', height)
    .style('border', 'solid black 1px');

var circle = svg.append('circle')
    .attr('cx', width / 2)
    .attr('cy', height / 2)
    .attr('r', height / 2 - 1);

Тепер давайте додамо ще трішки кіл, і подивимось на відмінність між select та selectAll. Перший метод повертає лише перший знайдений елемент, а другий – всі.

for(var i = 0; i <= 10; i++) {
    svg.append('circle')
        .attr('r', 10)
        .attr('cy', height / 2);
};

var circles = svg.selectAll('circle');

Тепер ми можемо задати атрибут всім колам зразу. А можемо сказати що атрибут кожного кола повинен бути результатом обчислення функції. І передати замість значення – лямбду. Наприклад можна змусити наші кола скакати туди-сюди через певний інтервал:

setInterval(function() {
    circles.attr('cx', function() { return Math.random() * width });
}, 100);

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

var tabulate_function = function(f, a, b, count) {
    var f_data = [];
    var width = b - a;
    for(var i=0; i < count; i++) {
        f_data.push(f(a + i * width / count));
    };
    return f_data;
};

Передавши в функцію tabulate_function, функцію для табулювання, інтервал a, b, та кількість обчислень, ми отримуємо масив з даними:

var BARS_COUNT = 100;
var data = tabulate_function(Math.sqrt, 0, 10, BARS_COUNT);

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

var bars = svg.selectAll('rectangle').data(data); // Прив’язуємо до вибірки з прямокутників
bars.enter().append('rect'); // А що якщо прямокутників нема (не вистачає)? Тоді додаємо прямокутник.

var bar_width = width / BARS_COUNT;

bars
    .attr('y', function(d) { return height - d * 100 }) // Позиція по осі Y як і висота функції від даних
    .attr('x', function(d, i) { return i * bar_width }) // Позиція по осі X - функція від номера елементу даних.
    .attr('width', bar_width)
    .attr('height', function(d) { return d * 100 });

Має вийти щось схоже на оце: sqrt. Якщо не вийшло – подивіться в чому відмінність вашого і мого коду.

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

Щоб вони видалялись, не забудьте написати:

bars.exit().remove();

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

В такому випадку, я виношу це все в функцію update:

var update_graph = function(data) {
    var bar_width = width / data.length;
    var bars = svg.selectAll('rect').data(data);

    bars.enter().append('rect');

    bars
      .attr('x', function(d, i) { return i * bar_width })
      .attr('width', bar_width)
      .transition().duration(2000) // Наступні атрибути змінювати плавно, за 2 секунди
      .attr('y', function(d) { return height - d * 100 })
      .attr('height', function(d) { return d * 100 });
    
    bars.exit().remove();  
};

І тоді, коли ми викличемо цю функцію кілька разів з різними даними – картинка буде плавно змінюватись, не перестворюючи надто багато елементів. А якщо видалити виклик transition().duration() – то буде змінюватись миттєво. Можна подивитись тут.

І на цьому напевне завершу мою розповідь, а то вона щось виходить нуднішою ніж я сподівався. А d3 не нудний, на ньому не тільки графіки можна малювати, а й наприклад прості іграшки.

Посилання

  1. JSFiddle – спонсор даної публікації. :) Всім рекомендую користуватись під час читання різноманітних підручників з веб дизайну.
  2. Scott Murray – Learning d3 (youtube)
  3. Mike Bostock – Three Little Circles
  4. Mike Bostock – Thinking With Joins

Filed under: Графіка, Кодерство, Павутина Tagged: JavaScript

Німецьке QWERTY

Німці використовують деякі букви, яких нема в стандартній латинській розкладці: ÄÖÜẞ, тому існує окрема німецька розкладка. Але біда, біда, вона не QWERTY, а QWERTZ, і Z та Y поміняні місцями. Правильної розкладки чомусь нема, тому я вирішив зробити свою. Має працювати на всіх системах що використовують X keyboard extension з X Window System.

Замість кнопки “-” отримуємо “ß”, замість “[” – “Ü”, “;” – “Ö” ну а замість “‘” – “Ä”. Всі інші залишаються на місці, а не перескакують чорт зна куди як в традиційній німецькій розкладці.

Відкриваємо розкладки для Німеччини:

cd /usr/share/X11/xkb/
sudo vim symbols/de

Додаємо розкладку з наступними клавішами (наслідується від базової американської):

xkb_symbols "germanqwerty" {
    include "us(basic)"
    name[Group1]="German (QWERTY)";

    key <AD11>	{ [udiaeresis, Udiaeresis, dead_diaeresis, dead_abovering ] };
    key <AC10>	{ [odiaeresis, Odiaeresis, dead_doubleacute, dead_belowdot ] };
    key <AC11>	{ [adiaeresis, Adiaeresis, dead_circumflex, dead_caron ] };
    key <AE11> {type[Group1]="FOUR_LEVEL_PLUS_LOCK",  symbols[Group1]=
                  [ssharp, question, backslash, questiondown, 0x1001E9E ]};
};

Далі додаємо нову розкладку до списку відомих:

cd /usr/share/X11/xkb/
sudo vim rules/evdev.xml

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

        <variant>
          <configItem>
            <name>germanqwerty</name>
            <description>German (QWERTY)</description>
          </configItem>
        </variant>

Далі треба розлогінитись і залогінитись заново, і можна додавати розкладки через аплет панелі робочого стола.

Посилання


Filed under: Кодерство, Конспекти Tagged: deutsch, linux

Покращене запрошення до вводу $ ▮

Кольорове запрошення до вводу дозволяє візуально виділяти місця де ви ввели команду і лог виконання команди.

Для цього, потрібно задати змінну середовища PS1 в файлі ~/.bashrc для звичайного і для суперкористувача.

Наприклад:

export PS1="\[\e[0;34m\]\u@\h : \w\[\e[m\]\n\[\e[0;32m\]\A \$> \[\e[m\]"
export PS1="\[\e[0;34m\]┌─[\u@\h : \w\n└─[\[\e[0;31m\]\A\[\e[0;34m\]]─> \$ \[\e[m\]"

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

\e[0;34m – синій колір, \e[0;32m – зелений, \e[m – повернутись до звичайного кольору. Повний список кольорів наприклад тут.

\u – користувач, \h – ім’я хоста до першої крапки, \w – повний шлях до поточної директорії, \A – час в 24-годинному форматі HH:MM, \$ – #, якщо ефективний UID користувача 0, інакше – $. Більше можна через man bash, в секції PROMPTING.


Filed under: Інструменти, Кодерство Tagged: linux

Генеруємо гарні PDF із Python. І трошки про качкодзьоба

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

Робив він це таким чином: python-скрипт генерує tex-документ згодовує його Beamer+pdflatex і... профіт!

Все було б добре, але 1 - мені не подобався кінцевий результат, 2 - не подобалось застосовувати прив’язку до зовнішніх продуктів. Тож почались дослідження...

 

Шлях до JavaScript майстерності

В 2013 почав писати оцейсписок, поки мій Python-проект ще не стартував, і мені дали тимчасово розгрібати купу JS:

  1. jQuery – ok, користуватись вмію, куди без нього.
  2. JavaScript: The Definitive Guide – за один раз не прочитаєш
  3. JavaScript: The Good Parts – за один раз прочитав, але варто перечитати.
  4. JavaScript Web Applications – можливо не найцікавіша книжка яку я читав, але з неї я дізнався про Spine.js, Backbone.js, underscore.js, та паттерн pub/sub.
  5. Прочитати про те як написання коду схоже на поезію
  6. Прочитати про об’єкт Class в Leaflet. Подумати що це варто було б окремою бібліотекою випускати, бо ж не в кожному проекті де треба ООП, треба карти…
  7. Почати модульно організовувати проекти, require.js
  8. Починати скрипти з декларації "use strict";.
  9. Пам’ятати про те що існує underscore.js, писати менше циклів.

А кінця шляху нема.

Нагадування 2014-го: І Smooth Coffescript варто дочитати.


Filed under: Кодерство, Павутина Tagged: JavaScript

Розробка керована питаннями

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

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

Качечка теж втомилась :)

Качечка теж втомилась :)

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

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

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

Ну й наостанок дам приклад того про що я пишу – лог питань що виникають при розробці гри в “п’ятнадцять”: bunyk.github.com/blob/master/fifteen/worklog.txt. Сама гра.


Filed under: Кодерство, Психософія Tagged: психологія, розробка

Прогризання в Хаскель

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

Книжка складна (чи то Хаскель такий), але гумор іноді веселий:

Шукати елемент у порожньому списку теж не варто, бо його там немає (і не тільки його — там немає багатьох інших елементів!)

Дійшов до розділу 8 про написання власних типів і типокласів. Ледве розібрався. Цікаво що в типів та конструкторів типів є типи (кшталти, kinds), і це не типи, як в Python, а щось інше. Не зрозуміло чому типоклас Функтор такий важливий. Ну можна виконувати над ним map. Але напевне важливий, бо десь я бачив слова “Аплікативний функтор, моноїд”, значить то десь до монад не далеко. Але дуже тішусь тим що наступний розділ буде про ввід-вивід, і я НАРЕШТІ зможу написати “Привіт, світе!”. :) Ну тобто ясно що main = putStr "Привіт, світе!", але зрозуміти що повертає putStr.

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

А потім може постараюсь пройти Write Yourself a Scheme in 48 Hours.


Filed under: Кодерство, Нещоденник Tagged: haskell