Tag Archives: Нещоденник

Програмістські експерименти

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

– Чи копіюється map-а, при присвоєнні?
– Хвилину.

package main

import "fmt"

func main() {
fmt.Println("- Чи копіюється map-а, при присвоєнні?")
a := make(map[string]string)
a["answer"] = "Так"
b := a
b["answer"] = "Ні"
fmt.Println("-", a["answer"])
}

– Ні

Якщо звісно не запитання “нам обрати технологію А чи Б?” І звісно ресурсу на те щоб реалізувати рішення в обох і порівняти нема. Тоді й з’являються релігійні суперечки про те в кого мова потужніша.

Теорія взаємодії процесів (насправді про IT-Arena)

Я не дуже хотів йти на Львів ІТ арену, бо то настільки понтово що задорого. Крім того на вузькоспеціалізованих конференціях на зразок PyCon я мало що розумію, навіть якщо сам доповідаю. 🙂 Хоча, знаєте, ото щойно передивився одну доповідь – і ніби все зрозумів (а що ще краще, виявляється що викладені там ідеї я зараз використовую в Angular, хоч і забув про них). Крім того, нащо йти на платну конференцію, якщо ти навіть не встигаєш читати всі блоги і дивитись всі безкоштовні відео доповідей з інших конференцій в інтернеті?

Але я пішов, і не пожалів. Познайомився з Естер Дайсон. Вона великий фанат здорового способу життя, і інвестор в наш проект.

Пішов на доповідь про мікросервіси оцього чоловіка. Там дізнався що всі системи які містять багато взаємодіючих компонентів можна описувати наприклад пі-численням. Але так як книжки з пі-числення страшенно дорогі, ось вам безкоштовна про математичну теорію названу “Взаємодія послідовних процесів”, і написана не аби-ким, а Сером Чарлзом Ентоні Річардом Гоаром. Тепер залишилось знайти час прочитати.

А ще поміж іншим дізнався про те що програмне забезпечення це лайно (точніше завжди знав), але існує стрібна куля. Називається LangSec, коли ми вхідні параметри описуємо якоюсь формальною мовою. Чим це відрізняється від Логіки Хоара і наприклад статичної типізації з алгебраїчними типами даних – ще треба подумати.

А ще зустрів хлопців з Quintagroup, вони зразу такі “О, це ти той пітонщик з SoftServe що пише на Zope”. Я такий – той, але вже не пітонщик і не з SoftServe. 🙂 Зараз вони багато працюють над проектом Prozorro, і шукають нових людей. Тому якщо знаєте Pyramid (чи який там фреймворк у https://github.com/openprocurement), шукаєте роботу – напишіть їм.


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

Упс, я зламав сайт ЦРУ

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

Selection_066


Filed under: Нещоденник, Павутина

Новий безкоштовий онлайн-курс веб-розробки для початківців

Ну а шо, в мене тепер купа досвіду в викладанні, а попит є. То чому б ні? Першим 10-тьом учасникам – участь безкоштовна. ;) А далі буде видно скільки я осилю. Може раз на тиждень, поки не прийде пора відпусток літом?

Прем’єра в четвер, 17-го березня, онлайн, в Google Hangouts. Приєднатись можна за посиланням: https://plus.google.com/events/cd18to4v9bob2p94ume6fb7qih8

Курс розглядатиме всі аспекти, починаючи від верстання статичних сторінок (що я погано вмію :) ), і контролю версій, до NoSQL баз даних (бо SQL я погано вмію :) ), і того що таке REST API. Ну, коротше кажучи, будемо розбиратись разом. Але почнемо з простого – що таке Git, Github, HTML і як помістити останній на Github pages.

Викладаю я більш-менш терпимо. Ось відгук, там фраза “Окрема подяка за підбір тренерів” – то про мене. ;)

По ходу справи будемо писати підручник: https://uk.wikibooks.org/wiki/MEAN

Картинка для привернення уваги: Git changing head uk

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


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

Анонс Lvivpy4

Попередні три я пропустив бо не читаю новини, але от на цьому буду, тому що там я буду нести людям світло науки і знання.

Цитую сам себе:

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

Одним словом те що ви могли почитати в трактаті про ZCA, тільки тепер в авторській озвучці, + можна буде задавати питання, і побачити мене в 3D. Головне руками не чіпати! :)

Тому якщо в кого виникне таке бажання – заходьте в Офіс Lohika Systems, Львів, вул. Лемківська 15а, 2-й поверх, 30-го травня. Реєстрація: http://www.meetup.com/uapycon/events/222342688/

І не переживайте, там доповідаю не тільки я.

Робота і життя після відпустки починається шалено (правда якщо врахувати що під час відпустки я більшість часу лише спав, їв і дихав), я навіть 10% всього цікавого зараз не розповів, але те що розповів – одне з найголовнішого. :)


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

Анонс Lvivpy4

Попередні три я пропустив бо не читаю новини, але от на цьому буду, тому що там я буду нести людям світло науки і знання.

Цитую сам себе:

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

Одним словом те що ви могли почитати в трактаті про ZCA, тільки тепер в авторській озвучці, + можна буде задавати питання, і побачити мене в 3D. Головне руками не чіпати! :)

Тому якщо в кого виникне таке бажання – заходьте в Офіс Lohika Systems, Львів, вул. Лемківська 15а, 2-й поверх, 30-го травня. Реєстрація: http://www.meetup.com/uapycon/events/222342688/

І не переживайте, там доповідаю не тільки я.

Робота і життя після відпустки починається шалено (правда якщо врахувати що під час відпустки я більшість часу лише спав, їв і дихав), я навіть 10% всього цікавого зараз не розповів, але те що розповів – одне з найголовнішого. :)


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

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

Я вирішив стати майстром верстки, 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

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

З відзнакою. Ось як він виглядає. Власне це не зовсім диплом, бо просто показує що я всього лиш завершив курс який тривав сім тижнів, і не підтверджує того факту що завдання робив я. І не зовсім швейцарський, бо 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: добре, освіта

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

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

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

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

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

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

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


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

Чим відрізняється декоратор від адаптера? (І про фасад)

Цих вихідних їхав поїздом додому, і в купе побачив на столі книжку “Heads first Design Patterns” видавництва O’reilly. Моїми сусідами по купе були хлопець з дівчиною. Вони виглядали сонними, і навіть плутали напрям поїздки (думали що поїзд до Києва їде, а не до Франківська, хоча їхали до Франківська), і активно проявляли намір лягти спати, тому я запитав:

- Можна я вашу книжку подивлюсь? Бо завжди хотів знати чим відрізняється декоратор від адаптера.

На що хлопець відповів:

- Так, звісно.

А дівчина:

- Ви що, теж програміст?! Як вас всіх скрізь багато розвелось!

Вони лягли на свої полиці, я теж підклав під голову рюкзак, вмостився на своїй полиці і взявся за книжку.

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

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

Як приклад для декораторів наводили клас – напій.

# coding=utf-8
class Beverage(object):
    def __init__(self,
        description = 'Невідомий напій', 
        price = 0,
    ):
        self._description = description
        self._price = price

    @property
    def description(self):
        return self._description

    @property
    def price(self):
        return self._price

class Tea(Beverage):
    def __init__(self,
        description = 'Чай',
        price = 2,
    ):
        super(Tea, self).__init__(description, price)

class Coffee(Beverage):
    def __init__(self,
        description = 'Кава',
        price = 3,
    ):
        super(Coffee, self).__init__(description, price)

tea = Tea()
print tea.description, tea.price # чай 2
coffee = Coffee()
print coffee.description, coffee.price # кава 3

А тепер уявімо собі що нам треба ще написати класи для тих самих напоїв, але з цукром, а ще з молоком. Можна було б наслідуватись, але тоді в нас буде ціла купа різних класів. Цукор і молоко – це декоратори напою.

class BeverageDecorator(Beverage): # важливо що декорований напій, це теж напій
    _description = 'Невідомий додаток'
    _price = 0
    def __init__(self, beverage):
        self.beverage = beverage
    
    @property
    def price(self):
        return self._price + self.beverage.price

    @property
    def description(self):
        return self.beverage.description + ' і ' + self._description

class Sugar(BeverageDecorator):
    _description = 'Цукор'
    _price = 0.1

class Milk(BeverageDecorator):
    _description = 'Молоко'
    _price = 0.2

my_coffee = Milk(Sugar(Sugar(Coffee())))
print my_coffee.description, my_coffee.price
# Кава і Цукор і Цукор і Молоко 3.4

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

class FahrenheitThermometer(object):
    @staticmethod
    def get_temperature():
        return 451

class CelsiusAdapter(object):
    def __init__(self, fahrenheit_thermometer):
        self.thermometer = fahrenheit_thermometer

    def __call__(self):
        return (self.thermometer.get_temperature() - 32) * 5.0 / 9

f = FahrenheitThermometer()
print f.get_temperature()
c = CelsiusAdapter(f)
print c()

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

Багато із звичних декораторів в Python є насправді адаптерами. Тому можна сказати що в Python декоратор – це обгортка, яку крім того можна ще й особливим синтаксисом застосувати до огортуваного об’єкта. Той же @property, @staticmethod – змінюють інтерфейс виклику методу, роблячи його зручнішим. @twisted.internet.defer.inlineCallbacks – теж змінює інтерфейс, перетворюючи співпрограму (coroutine) на набір асинхронних функцій.

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

class Voltmeter(object):
    def value(self):
        return 220

class Ammeter(object):
    def value(self):
        return 0.36

class Wattmeter(object):
    def __init__(self, voltmeter, ammeter):
        self.voltmeter = voltmeter
        self.ammeter = ammeter

    def value(self):
        return self.voltmeter.value() * self.ammeter.value()

w = Wattmeter(Voltmeter(), Ammeter())
print w.value()

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


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