Tag Archives: itblog-ua

Проблема з програмістами, що “вище середнього”

Posted by on 18.08.2014 Коментарі Вимкнено до Проблема з програмістами, що “вище середнього”

Liaoning School by kattebelletje

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

Примітка: тим хто читав або чув про чудову книжку “Pragmatic Thinking and Learning” деякі твердження можуть здатися протиріччям, але це не так. Поняття експерта там дещо ортогональне тому що описано тут, плюс там теж згадується про пастку “спочивання на лаврах”.

Оригінал: The Problem With ‘Above Average Programmers’
Автор: Dave Rodenbaugh

Швидко! Дайте відповідь на наступне питання не роздумуючи:

Як би ви оцінили ваші навички з програмування? (Нижче середнього, Середнє, Вище середнього)

Психологічні досліди проведені в різних групах показали, що більше 90% всіх програмістів вважають свої навички “Вище середнього”.

Як ви розумієте, так бути не може. Грубо кажучи, в групі зі 100 людей 50% вище середнього, а 50% — нижче. Цей ефект відомий в психології як “Ілюзія переваги”. Його спостерігали та задокументували у багатьох областях, і навіть знаючи про цей ефект ви ймовірно все одно дасте відповідь “Вище середнього”.

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

А тепер уявіть на хвилинку, що ви і справді “вище середнього”. Просто мужик! Рок-зірка. Бог поміж смертних. Клави схиляються в реверансі, коли ви проходите поруч, а труби грають туш, коли ви комітите на Github.

Якщо ваші знання вище середнього, то ви експерт в тому що ви робите. Називати себе експертом дуже приємно — ви здобуваєте повагу, шану та престиж будучи ним.

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

Натомість, чому б не розглянути іншу можливість? Ви — середняк, або (боже збав!) нижче середнього. Окрім пораненої гідності, яку ви можливо будете переживати, подумайте про справжні переваги:

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

Можливо ви чули про “розум початківця”? Короткий його зміст сказаний майстром Дзену з типовою лаконічністю коану:

В голові початківця є багато можливостей, в голові експерта є лише кілька.

Пастка самоназви себе “експертом” в розробці софту означає, що ви запираєте себе у певну мову (Java, Ruby, PHP), певну сферу (медичні пристрої, соціальні мережі, ігри), певну спеціалізацію (embedded, enterprise, тощо). Коли ви напрацюєте цей досвід, вас буде переслідувати страх помилки, коли ви вийдете за свою зону комфорту. Зі своїм золотим молотом досвіду все навкруги здаватиметься цвяхом. Ви не будете думати про викрутки та інші адекватні інструменти оскільки ви про них не знаєте, або не вмієте користуватись.

Саме тому починаючи новий software-проект ви часто дивуєтесь чому “досвідчені програмісти” не можуть взяти X, ви ж вивчили X всього за кілька днів. X може бути чим завгодно: замикання, об’єктно-орієнтоване програмування, фреймворк Ruby on Rails, програмування на Haskell. Врешті-решт, це не має ніякого значення, голова експерта забита застарілими знаннями. Голова початківця відкрита та вільна від перепон.

Коли ви експерт, вчитися важче. Тому бути “досвідченим програмістом” небезпечно.

Тож яка ж першочергова річ, яку можуть зробити програмісти? Почати з того, аби вважати свій рівень нижчим середнього. Вийти за зону комфорту. Бути “найсереднішим”.

Маестро ніколи не перестає вчитись, і ви не переставайте також.

Проблема з програмістами, що “вище середнього”

Posted by on 18.08.2014 Коментарі Вимкнено до Проблема з програмістами, що “вище середнього”

Liaoning School by kattebelletje

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

Примітка: тим хто читав або чув про чудову книжку “Pragmatic Thinking and Learning” деякі твердження можуть здатися протиріччям, але це не так. Поняття експерта там дещо ортогональне тому що описано тут, плюс там теж згадується про пастку “спочивання на лаврах”.

Оригінал: The Problem With ‘Above Average Programmers’
Автор: Dave Rodenbaugh

Швидко! Дайте відповідь на наступне питання не роздумуючи:

Як би ви оцінили ваші навички з програмування? (Нижче середнього, Середнє, Вище середнього)

Психологічні досліди проведені в різних групах показали, що більше 90% всіх програмістів вважають свої навички “Вище середнього”.

Як ви розумієте, так бути не може. Грубо кажучи, в групі зі 100 людей 50% вище середнього, а 50% — нижче. Цей ефект відомий в психології як “Ілюзія переваги”. Його спостерігали та задокументували у багатьох областях, і навіть знаючи про цей ефект ви ймовірно все одно дасте відповідь “Вище середнього”.

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

А тепер уявіть на хвилинку, що ви і справді “вище середнього”. Просто мужик! Рок-зірка. Бог поміж смертних. Клави схиляються в реверансі, коли ви проходите поруч, а труби грають туш, коли ви комітите на Github.

Якщо ваші знання вище середнього, то ви експерт в тому що ви робите. Називати себе експертом дуже приємно — ви здобуваєте повагу, шану та престиж будучи ним.

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

Натомість, чому б не розглянути іншу можливість? Ви — середняк, або (боже збав!) нижче середнього. Окрім пораненої гідності, яку ви можливо будете переживати, подумайте про справжні переваги:

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

Можливо ви чули про “розум початківця”? Короткий його зміст сказаний майстром Дзену з типовою лаконічністю коану:

В голові початківця є багато можливостей, в голові експерта є лише кілька.

Пастка самоназви себе “експертом” в розробці софту означає, що ви запираєте себе у певну мову (Java, Ruby, PHP), певну сферу (медичні пристрої, соціальні мережі, ігри), певну спеціалізацію (embedded, enterprise, тощо). Коли ви напрацюєте цей досвід, вас буде переслідувати страх помилки, коли ви вийдете за свою зону комфорту. Зі своїм золотим молотом досвіду все навкруги здаватиметься цвяхом. Ви не будете думати про викрутки та інші адекватні інструменти оскільки ви про них не знаєте, або не вмієте користуватись.

Саме тому починаючи новий software-проект ви часто дивуєтесь чому “досвідчені програмісти” не можуть взяти X, ви ж вивчили X всього за кілька днів. X може бути чим завгодно: замикання, об’єктно-орієнтоване програмування, фреймворк Ruby on Rails, програмування на Haskell. Врешті-решт, це не має ніякого значення, голова експерта забита застарілими знаннями. Голова початківця відкрита та вільна від перепон.

Коли ви експерт, вчитися важче. Тому бути “досвідченим програмістом” небезпечно.

Тож яка ж першочергова річ, яку можуть зробити програмісти? Почати з того, аби вважати свій рівень нижчим середнього. Вийти за зону комфорту. Бути “найсереднішим”.

Маестро ніколи не перестає вчитись, і ви не переставайте також.

Зверніть увагу на:

Must have для сучасних IDE та редакторів

Posted by on 31.07.2013 Коментарі Вимкнено до Must have для сучасних IDE та редакторів

LightTable LogoНаразі у мене є два улюблених редактори для коду: Sublime Text та LightTable (з vim, хоч любові до гробу не склалося, оскільки я в чистій консолі не так часто працюю, але він теж гарний). Про перший зараз мабуть не знає лише лінивий. У нього багато всяких крутих можливостей для редагування, плюс він дуже круто розширюється завдяки масі доступних плагінів. Але! Все те, що зараз пропонує Саблайм — це необхідний мінімум, без якого я вже не уявляю комфортної роботи, тому на цьому питанні я зупинятись не буду. Набагато цікавіше жити днем завтрашнім і оцінити куди надалі розвиваються редактори. А для того, аби оцінити це, прошу переглянути відео “Inventing on a Principle” (“Винаходячи за принципом”). Його, я впевнений, багато хто вже бачив, тому перепрошую за повторення, можете одразу читати далі. Хто не бачив — обов’язково подивіться. Причому тут його показано не лише для програмування, а й інших сфер як-то радіоелектроніка, обробка відео, тощо. Дуже цікава штука, насолоджуйтесь (до речі, у кого проблеми з англійською — там є російські субтитри):

LightTable concept screenshot Але то все концепт… Гарна ідея, але (мабуть) не тривіальна в реалізації, і невідомо коли ми вже зможемо використати щось подібне в реальній роботі. Чи відомо? Насправді розробники вже можуть помацати перші реалізації цієї ідеї за допомогою LightTable. LightTable наразі єдина робоча реалізація про яку я знаю, тому якщо існують інші — скажіть, я хочу спробувати 😉 Про цей редактор я дізнався суто випадково, коли копав більше інформації про Clojure (власне LT написаний на Clojure і це була перша мова яку він підтримував). Звісно, там все не настільки аж неймовірно як у відео вище, але все ж JavaScript’овий приклад, який зробили з виходом версії 0.4 уже вражає:

Згодом з’явилась ціла серія відео про використання ClojureScript в LightTable в аналогічному стилі. Перше відео тут, далі по списку в Related на Ютюбі.

Звісно, в реальному житті все не настільки райдужно: в LightTable поки нема багатьох можливостей, до яких я вже звик в Sublime Text, тому у більшості випадків я не можу повністю перейти на нього. Плюс справжня real-time розробка наразі є лише для JavaScript, ClojureScript та, в принципі, Clojure. Для останньої та для Python є підтримка трохи простішої, але теж корисної фічі inline evaluation: це REPL прямо у вікні редактора — кльова фіча, я постійно нею користуюсь. Хоча насправді подібна штука не нова і є навіть в Visual Studio 2010 — це інтерактивна консоль для F# (можна подивитись приклад роботи тут).

Must have для сучасних IDE та редакторів

Posted by on 31.07.2013 Коментарі Вимкнено до Must have для сучасних IDE та редакторів

LightTable LogoНаразі у мене є два улюблених редактори для коду: Sublime Text та LightTable (з vim, хоч любові до гробу не склалося, оскільки я в чистій консолі не так часто працюю, але він теж гарний). Про перший зараз мабуть не знає лише лінивий. У нього багато всяких крутих можливостей для редагування, плюс він дуже круто розширюється завдяки масі доступних плагінів. Але! Все те, що зараз пропонує Саблайм — це необхідний мінімум, без якого я вже не уявляю комфортної роботи, тому на цьому питанні я зупинятись не буду. Набагато цікавіше жити днем завтрашнім і оцінити куди надалі розвиваються редактори. А для того, аби оцінити це, прошу переглянути відео “Inventing on a Principle” (“Винаходячи за принципом”). Його, я впевнений, багато хто вже бачив, тому перепрошую за повторення, можете одразу читати далі. Хто не бачив — обов’язково подивіться. Причому тут його показано не лише для програмування, а й інших сфер як-то радіоелектроніка, обробка відео, тощо. Дуже цікава штука, насолоджуйтесь (до речі, у кого проблеми з англійською — там є російські субтитри):



LightTable concept screenshot Але то все концепт… Гарна ідея, але (мабуть) не тривіальна в реалізації, і невідомо коли ми вже зможемо використати щось подібне в реальній роботі. Чи відомо? Насправді розробники вже можуть помацати перші реалізації цієї ідеї за допомогою LightTable. LightTable наразі єдина робоча реалізація про яку я знаю, тому якщо існують інші — скажіть, я хочу спробувати ;) Про цей редактор я дізнався суто випадково, коли копав більше інформації про Clojure (власне LT написаний на Clojure і це була перша мова яку він підтримував). Звісно, там все не настільки аж неймовірно як у відео вище, але все ж JavaScript’овий приклад, який зробили з виходом версії 0.4 уже вражає:

Згодом з’явилась ціла серія відео про використання ClojureScript в LightTable в аналогічному стилі. Перше відео тут, далі по списку в Related на Ютюбі.

Звісно, в реальному житті все не настільки райдужно: в LightTable поки нема багатьох можливостей, до яких я вже звик в Sublime Text, тому у більшості випадків я не можу повністю перейти на нього. Плюс справжня real-time розробка наразі є лише для JavaScript, ClojureScript та, в принципі, Clojure. Для останньої та для Python є підтримка трохи простішої, але теж корисної фічі inline evaluation: це REPL прямо у вікні редактора — кльова фіча, я постійно нею користуюсь. Хоча насправді подібна штука не нова і є навіть в Visual Studio 2010 — це інтерактивна консоль для F# (можна подивитись приклад роботи тут).

Зверніть увагу на:

“Складні речі – доступно, прості – робляться самі”

Posted by on 31.07.2013 Коментарі Вимкнено до “Складні речі – доступно, прості – робляться самі”

Якщо перефразувати девіз мови Perl “Зробити прості речі простими, а складні можливими” для LISP, то вийде “Зробити складні речі доступними, а прості робляться самі”
– Всеволод Дьомкін, Grammarly. З презентації на HotCode 2013

Clojure Logo

У мене тут в чорновиках стільки записів — треба їх потроху публікувати. Але вони всі вже здоровезні, і я все не можу їх довести до ладу, тому я подумав, що варто робити з них менші і таки виводити в світ. Сьогодні я вирішив написати першу замітку про Clojure. Це, мабуть, наразі самий новий, але вже дуже популярний діалект LISP, що працює поверх JVM. Перші спроби наковбасити щось на Clojure у мене сталися ще кілька місяців тому, коли я написав простенький конвертор тест-кейсів з Testlink в TFS, але то було зроблено на колінці і окрім того, що я його написав дуже швидко, там пишатись особливо нема чим: це моя перша програмка на чомусь LISP-подібному не рахуючи простеньких завдань в універі, тому код страшненький, без всяких крутих ліспових фішечок типу макросів, з багами, але працює 🙂

Про Clojure я дізнався суто випадково на конференції Javascript Framework Days навесні цього року з презентації Олександра Соловйова про ClojureScript (це така підмножина мови, що транслюється в JavaScript, типу як CoffeeScript). До речі, рекомендую подивитись саму презенташку про FRP та ClojureScript – вона весела, динамічна, а мені не потрібно буде розповідати про те, що являють собою LISPоподібні мови і Clojure в тому числі.

А ось нижче приклад простенької задачки яку буквально на днях мну вирішив для себе. Суть полягає в тому, щоб розпарсити старий допотопний HTML на сайтах філармонії, театру Франка, органного залу та інших подібних закладів у iCalendar формат, аби їх можна було б собі підключити собі в Outlook чи Google Calendar. Парсити доводиться звичайний html, бо жоден з цих сайтів та агрегаторів не додумався зробити цього сам, або хоча б видавати афішу в rss-форматі (якщо хтось знає де є такі — скажіть). Вгадайте скільки рядків займає подібна програмка навіть на Python з будь-якими лібами 😉

Готовий закластися, що навіть на Python буде більше ніж це:

(ns eventic.core
  (:require [net.cgrand.enlive-html :as html]
            [clj-time.format :as time]
            [clj-ical.format])
  (:import java.net.URL java.nio.charset.Charset)) 
  
; хелпер для завантаження сторінки (штатний рідер enlive не шарить кодувань)
(defn fetch-page [url]
  (-> url java.net.URL. .getContent (java.io.InputStreamReader. "WINDOWS-1251") html/html-resource))
  
; закачуємо сторінку
(def p
  (fetch-page "http://www.filarmonia.com.ua/ua.afisha"))
  
; хелпер для конвертації дат виду "30.07.2013" в datetime
(defn to-date [date]
  (time/parse (time/formatter "dd.MM.yyyy") date))
  
; переводимо усі теги <br> в n, а всі інші теги прибираємо зберігаючи текст
(defn extractor [content]
  (map #(apply str (-> % (html/at [:br] (html/content "n") [:*] html/unwrap))) content)) 

; вибираємо дати і конвертуємо в date-time формат
(def dates
  (map #(-> % :content first to-date)
        (html/select p [:table :tr :td :p :span])))
    
; вибираємо заголовки
(def titles
  (map #(-> % :content first str)
        (html/select p [:table :tr :td :h2])))

; вибираємо описи одразу переводячи їх в plain text
(def descriptions 
  (rest (extractor
    (html/select p [:table :tr :td [:p (html/attr? :align)]]))))

; робимо структуру наповнення для iCalendar
(def ical
  (map #(vec (zipmap [:dtstart :summary :description] %))
        (map vector dates titles descriptions)))

; записуємо в файл
(spit "filarmony.ics"
  (->> (clj-ical.format/write-object
         (apply conj [:vcalendar] (map #(apply conj [:vevent] %) ical)))
       with-out-str))

І все. На виході отримуємо готовий файл у iCalendar форматі з усім необхідним. Можливо з першого погляду здаватиметься, що це якась тарабарщина, але насправді Clojure вчиться дуже швидко. Достатньо пари годин на день і вже за 3-4 дні можна писати маленькі корисні штуки для себе (я раніше постійно використовував Python для цього, але тепер в мене з’явилася нова робоча конячка 🙂 ). І суть навіть не в тому, що цей код компактний сам по собі. Суть в тому, що Clojure має такі засоби, що дозволяють створювати бібліотеки на кшталт Enlive, які надзвичайно потужні і прості в користуванні одночасно, а відповідно код що їх використовує стає простішим і його легше підтримувати.

А тим часом я думаю як це все оформити в простенький сервіс, який можна буде розгорнути на Google App Engine — все ж Clojure на JVM працює. Я вже надивився прикладів і презентацій на “Hackers with Attitude”, тож хочу тепер сам спробувати (і згодом описати це).

P.S. Ну і хто досі не читав “Перемогти посередність” Пола Грема, дуже рекомендую 😉

“Складні речі – доступно, прості – робляться самі”

Posted by on 30.07.2013 Коментарі Вимкнено до “Складні речі – доступно, прості – робляться самі”

Якщо перефразувати девіз мови Perl
“Зробити прості речі простими, а складні можливими” для LISP,
то вийде “Зробити складні речі доступними, а прості робляться самі”

— Всеволод Дьомкін, Grammarly.
З презентації на HotCode 2013

Clojure Logo

У мене тут в чорновиках стільки записів — треба їх потроху публікувати. Але вони всі вже здоровезні, і я все не можу їх довести до ладу, тому я подумав, що варто робити з них менші і таки виводити в світ. Сьогодні я вирішив написати першу замітку про Clojure. Це, мабуть, наразі самий новий, але вже дуже популярний діалект LISP, що працює поверх JVM. Перші спроби наковбасити щось на Clojure у мене сталися ще кілька місяців тому, коли я написав простенький конвертор тест-кейсів з Testlink в TFS, але то було зроблено на колінці і окрім того, що я його написав дуже швидко, там пишатись особливо нема чим: це моя перша програмка на чомусь LISP-подібному не рахуючи простеньких завдань в універі, тому код страшненький, без всяких крутих ліспових фішечок типу макросів, з багами, але працює :)

Про Clojure я дізнався суто випадково на конференції Javascript Framework Days навесні цього року з презентації Олександра Соловйова про ClojureScript (це така підмножина мови, що транслюється в JavaScript, типу як CoffeeScript). До речі, рекомендую подивитись саму презенташку про FRP та ClojureScript – вона весела, динамічна, а мені не потрібно буде розповідати про те, що являють собою LISPоподібні мови і Clojure в тому числі.

А ось нижче приклад простенької задачки яку буквально на днях мну вирішив для себе. Суть полягає в тому, щоб розпарсити старий допотопний HTML на сайтах філармонії, театру Франка, органного залу та інших подібних закладів у iCalendar формат, аби їх можна було б собі підключити собі в Outlook чи Google Calendar. Парсити доводиться звичайний html, бо жоден з цих сайтів та агрегаторів не додумався зробити цього сам, або хоча б видавати афішу в rss-форматі (якщо хтось знає де є такі — скажіть). Вгадайте скільки рядків займає подібна програмка навіть на Python з будь-якими лібами ;)

Готовий закластися, що навіть на Python буде більше ніж це:

(ns eventic.core
  (:require [net.cgrand.enlive-html :as html]
            [clj-time.format        :as time]
            [clj-ical.format])
  (:import java.net.URL
           java.nio.charset.Charset))

; хелпер для завантаження сторінки (штатний рідер enlive не шарить кодувань)
(defn fetch-page [url]
  (-> url java.net.URL.
    .getContent (java.io.InputStreamReader. "WINDOWS-1251") html/html-resource))

; закачуємо сторінку
(def p (fetch-page "http://www.filarmonia.com.ua/ua.afisha"))

; хелпер для конвертації дат виду "30.07.2013" в datetime
(defn to-date [date]
  (time/parse (time/formatter "dd.MM.yyyy") date))

; переводимо усі теги <br> в \n, а всі інші теги прибираємо зберігаючи текст
(defn extractor [content]
  (map #(apply str
    (-> %  (html/at [:br] (html/content "\\n") [:*] html/unwrap))) content))

; вибираємо дати і конвертуємо в date-time формат
(def dates
  (map #(-> % :content first to-date) (html/select p [:table :tr :td :p :span])))
; вибираємо заголовки
(def titles
  (map #(-> % :content first str) (html/select p [:table :tr :td :h2])))
; вибираємо описи одразу переводячи їх в plain text
(def descriptions
  (rest (extractor (html/select p [:table :tr :td [:p (html/attr? :align)]]))))

; робимо структуру наповнення для iCalendar
(def ical
  (map #(vec (zipmap [:dtstart :summary :description] %))
    (map vector dates titles descriptions)))

; записуємо в файл
(spit "filarmony.ics"
  (->> (clj-ical.format/write-object
    (apply conj [:vcalendar] (map #(apply conj [:vevent] %) ical))) with-out-str))

І все. На виході отримуємо готовий файл у iCalendar форматі з усім необхідним. Можливо з першого погляду здаватиметься, що це якась тарабарщина, але насправді Clojure вчиться дуже швидко. Достатньо пари годин на день і вже за 3-4 дні можна писати маленькі корисні штуки для себе (я раніше постійно використовував Python для цього, але тепер в мене з’явилася нова робоча конячка :) ). І суть навіть не в тому, що цей код компактний сам по собі. Суть в тому, що Clojure має такі засоби, що дозволяють створювати бібліотеки на кшталт Enlive, які надзвичайно потужні і прості в користуванні одночасно, а відповідно код що їх використовує стає простішим і його легше підтримувати.

А тим часом я думаю як це все оформити в простенький сервіс, який можна буде розгорнути на Google App Engine — все ж Clojure на JVM працює. Я вже надивився прикладів і презентацій на “Hackers with Attitude”, тож хочу тепер сам спробувати (і згодом описати це).

P.S. Ну і хто досі не читав “Перемогти посередність” Пола Грема, дуже рекомендую ;)

Зверніть увагу на:

OnLive Desktop

Posted by on 12.07.2012 Коментарі Вимкнено до OnLive Desktop

OnLive Desktop – це майкрософтівський сервіс в хмарі, який дає нам доступ до Офісу (в принципі) на будь-якому пристрої (безкоштовна версія 2 гіга + Офіс). Це попросту Remote Desktop на майкрософтівський комп в хмарі, який власне виконує проги, а скріншот надсилає на ваш пристрій (наразі це iPad і Андроїд-планшети, але в ближчому майбутньому обіцяють pc та маки теж… поки що можна попробувати на pc через Bluestacks ;) ).

Як на мене, це досить революційне, радикально-неполовинчасте рішення. (Бо те, що існує зараз – дублюючий софт, типу GoogleDocs, який намагається яваскриптом повторювати функціональність десктоп-додатків – це ж насмішка, правда?..) Воно же вітало у повітрі… Чому ніхто не здогадався раніш? Працює в принципі будь-де. Інсталяцій не потрібно. IT-фахівців не потрібно. Супроводження не потрібно. Усе винесено на серверну частину. Клієнт отримує лише скрін. Функціональність повна.

Ну і користь для розробників софту переоцінити важко – піратам важко креканути щось, що встановлено на сервері виробника, монетизація контрольована. (Для того ж все (хмара) і задумувалося, не?)

OnLive Desktop

Posted by on 12.07.2012 Коментарі Вимкнено до OnLive Desktop

OnLive Desktop – це майкрософтівський сервіс в хмарі, який дає нам доступ до Офісу (в принципі) на будь-якому пристрої (безкоштовна версія 2 гіга + Офіс). Це попросту Remote Desktop на майкрософтівський комп в хмарі, який власне виконує проги, а скріншот надсилає на ваш пристрій (наразі це iPad і Андроїд-планшети, але в ближчому майбутньому обіцяють pc та маки теж… поки що можна попробувати на pc через Bluestacks ;) ).

Як на мене, це досить революційне, радикально-неполовинчасте рішення. (Бо те, що існує зараз – дублюючий софт, типу GoogleDocs, який намагається яваскриптом повторювати функціональність десктоп-додатків – це ж насмішка, правда?..) Воно же вітало у повітрі… Чому ніхто не здогадався раніш? Працює в принципі будь-де. Інсталяцій не потрібно. IT-фахівців не потрібно. Супроводження не потрібно. Усе винесено на серверну частину. Клієнт отримує лише скрін. Функціональність повна.

Ну і користь для розробників софту переоцінити важко – піратам важко креканути щось, що встановлено на сервері виробника, монетизація контрольована. (Для того ж все (хмара) і задумувалося, не?)

Визначення власності

Posted by on 22.03.2012 Коментарі Вимкнено до Визначення власності

На днях у Пола Грема вийшло ще одне вельми цікаве есе на тему приватної власності та копірайтів (в контексті нещодавних спроб прийняти SOPA та PIPA). По-моєму, дуже влучна стаття і, благо, невелика – вирішив перекласти. Читаючи її я також часто згадував про оцей комікс (англ. оригінал): “Я пробував подивитись Гру Тронів і ось що вийшло” і дибілізм до якого інколи доходять всілякі правові обмеження на поширення медіа в інтернеті: у мене є підписка на Crunchyroll та думаю якось таки замутити Spotify Unlimited для онлайн музла. Так от якого дідька я мушу користуватись цим всим через американські та британські проксі відповідно, якщо я навіть гроші вже плачу. По відео це взагалі алес… Я вже не кажу, що так само не можна офіційно з України користуватись онлайн сервісами типу Hulu, BBC iPlayer, тощо.

Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Defining Property

Elephant Chained
[1]

В дитинстві я читав книжку з історіями про відомого японського суддю XVIII сторіччя, якого звали Оока Тадаске (Ooka Tadasuke). Одна зі справ, яку він судив була порушена власником ресторану. Бідний студент, що міг дозволити собі лише рис, їв його насолоджуючись запахом інших смачностей, які доносились із ресторану. І власник хотів заставити студента заплатити за запахи, які він із задоволенням нюхав. Студент же крав запах їжі!

Я часто згадую цю історію, коли чую як RIAA та MPAA звинувачують людей у крадіжці музики чи кінострічок.

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

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

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

Причина того, що так багато людей і досі думають, що у власності є лише одне незмінне визначення полягає в тому, що це визначення змінюється дуже повільно.[3] Але воно зараз якраз перебуває в стані трансформації. Рекордингові лейбли та кінематографічні студії звикли продавати своє добро ніби це повітря, що йде по трубах на місячній базі. Але з появою комп’ютерних мереж ми ніби переселилися на планету з атмосферою, якою можна дихати. Дані передаються зараз як запах. Але через прийняття бажаного за дійсне та короткострокової жадібності, лейбли та студії поставили себе на місце власника ресторану, звинуваючуючи користувачів в тому, що вони крадуть їх запахи.

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

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

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

Божевільні заходи по захисту прав, які зараз проводять лейбли та студії, дуже нагадують подібну ситуацію. Газетам та журналам теж непереливки, але вони принаймні занепадають з гідністю. RIAA та MPAA заставили б нас дихати через трубки, якби змогли.

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

От тут дуже корисно мати працюючу демократію та багато незалежних країн. Якби у світі був єдиний авторитарний уряд, лейбли та студії купили б закони, які встановили те визначення власності, яке їм хочеться. Але на щастя є ще країни, які не є copyright-колоніями США і навіть в самих США політики все ще бояться електорату у великих кількостях. [4]

Людям, які керують у США може не подобатись, коли виборці чи інші країни відмовляються схилитись перед їхньою волею, але і ми зацікавлені в тому, аби люди, що намагають змінити закони заради власних інтересів, не мали чим нам дорікнути. Приватна власність – це дуже корисна ідея і, можливо, взагалі однин з найкращих винаходів людства. Досі кожне нове визначення приносило нам збільшення матеріального достатку [5]. Думаю, що не буде помилкою припустити, що і нове теж. Це було б трагедією, якби ми всі були змушені використовувати застарілу версію просто тому, що деякі впливові люди занадто ледачі аби оновити його.

  1. Photo by Invisible Lens Photography/Flickr ↩︎

  2. Якщо вам цікаво дізнатись більше про збирачів, рекоменду. книжки Елізабет Машал Томас (Elizabeth Marshall Thomas): The Harmless People та The Old Way. ↩︎

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

  4. Наскільки мені відомо термін “copyright-колонія” вперше використав Myles Peterson. ↩︎

  5. Стан технології це не просто функція від визначення власності. Вони впливають одне на одне. І таким чином ви не можете з власної волі змінити визначення власності не зачепивши (зазвичай зашкодивши) розвиток технологій. Історія СРСР – яскравий тому приклад. ↩︎

Визначення власності

Posted by on 22.03.2012 Коментарі Вимкнено до Визначення власності

На днях у Пола Грема вийшло ще одне вельми цікаве есе на тему приватної власності та копірайтів (в контексті нещодавних спроб прийняти SOPA та PIPA). По-моєму, дуже влучна стаття і, благо, невелика – вирішив перекласти. Читаючи її я також часто згадував про оцей комікс (англ. оригінал): “Я пробував подивитись Гру Тронів і ось що вийшло” і дибілізм до якого інколи доходять всілякі правові обмеження на поширення медіа в інтернеті: у мене є підписка на Crunchyroll та думаю якось таки замутити Spotify Unlimited для онлайн музла. Так от якого дідька я мушу користуватись цим всим через американські та британські проксі відповідно, якщо я навіть гроші вже плачу. По відео це взагалі алес… Я вже не кажу, що так само не можна офіційно з України користуватись онлайн сервісами типу Hulu, BBC iPlayer, тощо.

Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Defining Property

Elephant Chained

Photo by Invisible Lens Photography/Flickr

В дитинстві я читав книжку з історіями про відомого японського суддю XVIII сторіччя, якого звали Оока Тадаске (Ooka Tadasuke). Одна зі справ, яку він судив була порушена власником ресторану. Бідний студент, що міг дозволити собі лише рис, їв його насолоджуючись запахом інших смачностей, які доносились із ресторану. І власник хотів заставити студента заплатити за запахи, які він із задоволенням нюхав. Студент же крав запах їжі!

Я часто згадую цю історію, коли чую як RIAA та MPAA звинувачують людей у крадіжці музики чи кінострічок.

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

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

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

Причина того, що так багато людей і досі думають, що у власності є лише одне незмінне визначення полягає в тому, що це визначення змінюється дуже повільно. [2] Але воно зараз якраз перебуває в стані трансформації. Рекордингові лейбли та кінематографічні студії звикли продавати своє добро ніби це повітря, що йде по трубах на місячній базі. Але з появою комп’ютерних мереж ми ніби переселилися на планету з атмосферою, якою можна дихати. Дані передаються зараз як запах. Але через прийняття бажаного за дійсне та короткострокової жадібності, лейбли та студії поставили себе на місце власника ресторану, звинуваючуючи користувачів в тому, що вони крадуть їх запахи.

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

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

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

Божевільні заходи по захисту прав, які зараз проводять лейбли та студії, дуже нагадують подібну ситуацію. Газетам та журналам теж непереливки, але вони принаймні занепадають з гідністю. RIAA та MPAA заставили б нас дихати через трубки, якби змогли.

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

От тут дуже корисно мати працюючу демократію та багато незалежних країн. Якби у світі був єдиний авторитарний уряд, лейбли та студії купили б закони, які встановили те визначення власності, яке їм хочеться. Але на щастя є ще країни, які не є copyright-колоніями США і навіть в самих США політики все ще бояться електорату у великих кількостях. [3]

Людям, які керують у США може не подобатись, коли виборці чи інші країни відмовляються схилитись перед їхньою волею, але і ми зацікавлені в тому, аби люди, що намагають змінити закони заради власних інтересів, не мали чим нам дорікнути. Приватна власність – це дуже корисна ідея і, можливо, взагалі однин з найкращих винаходів людства. Досі кожне нове визначення приносило нам збільшення матеріального достатку [4]. Думаю, що не буде помилкою припустити, що і нове теж. Це було б трагедією, якби ми всі були змушені використовувати застарілу версію просто тому, що деякі впливові люди занадто ледачі аби оновити його.

Примітки

[1] Якщо вам цікаво дізнатись більше про збирачів, рекоменду. книжки Елізабет Машал Томас (Elizabeth Marshall Thomas): The Harmless People та The Old Way.

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

[3] Наскільки мені відомо термін “copyright-колонія” вперше використав Myles Peterson.

[4] Стан технології це не просто функція від визначення власності. Вони впливають одне на одне. І таким чином ви не можете з власної волі змінити визначення власності не зачепивши (зазвичай зашкодивши) розвиток технологій. Історія СРСР – яскравий тому приклад.

Зверніть увагу на: