Tag Archives: Нещоденник - Page 2

Ітеративно і інкрементно

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

Тому тут просто процитую те що написано в підвалі блогу Едді Османі:

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

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

Створіть новий gist чи fiddle, відкрийте консоль і експериментуйте. Це, бляха, весело!

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

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

Хоча пошук багів звісно це теж трішки творчий процес, гідний Шерлока Холмса, але варто придумати щось аби зробити його ще більш творчим. Прописувати в коді контракти по ходу пошуку?


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

Коли здається що щось не так – RTFM!

Вчора знайшов помилку в веб-сервері Nginx. Мені на Google+ підказали, що насправді я неправильно прочитав документацію, тому що “з версії 0.6.7 шлях до файлу є відносним директорії з файлом конфігурації nginx.conf, а не відносним префіксній директорії.” Хоча звісно незрозуміло чому такий виняток, бо в документації про префіксну директорію, написано що вона “used for all relative paths set by configure (except for paths to libraries sources) and in the nginx.conf configuration file. It is set to the /usr/local/nginx directory by default.” Про такий виняток не написано. Але все одно помилився тут таки я.

Сьогодні знову помилився:

os.path.join('a', 'b', '/c/d.jpg')
# out: '/c/d.jpg'
# WTF? 
os.path.join('a', 'b', 'c/d.jpg')
# out: 'a/b/c/d.jpg'

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

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


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

Гроші ніби є, а користуватись ними в мене не виходить

KredoDirect – система набагато краща за iBank 2 UA (як корабель назвеш, так й попливеш), бо не треба ставити ніяку Java від Oracle, а можна зразу зайти й користуватись. Біфіт я ненавиджу щирою ненавистю і добре що в Авалі в мене вже закінчились гроші. Залишилось тепер лише закрити карточку.

Біда з KredoDirect в тому, що я коли створював для нього новий пароль, неправильно ввів майстер пароль. Вчора з другої спроби знову ввів його неправильно і залогінився, але так і не встиг заплатити пенсійному фонду, тому що система розлогінює вас при будь-якому натисненні кнопки “назад”. Подумав – висплюсь, зранку заплачу.

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

from getpass import getpass

from oplop import create

alphabet = 'abcdefghijklmnopqrstuvwxyz,/.][\';`1234567890-=\\'

def edits1(word):
    splits     = [(word[:i], word[i:]) for i in range(len(word) + 1)]
    deletes    = [a + b[1:] for a, b in splits if b]
    transposes = [a + b[1] + b[0] + b[2:] for a, b in splits if len(b)>1]
    replaces   = [a + c + b[1:] for a, b in splits for c in alphabet if b]
    inserts    = [a + c + b     for a, b in splits for c in alphabet]
    return set(deletes + transposes + replaces + inserts)

n = 0
for mp in edits1(getpass('master password:')):
    p = create('kredodirect', mp)
    if p[0] == 'z':
        n += 1
        print
        print n
        print mp, p

Отримав 31 варіант помилки і паролі які виходять в результаті. Десь на перевірці четвертого пароля мені сказало: “Доступ до Інтернет сервісу заблокований”, і цим моя атака грубою силою закінчилась. :( Українським пенсіонерам доведеться ще трохи почекати на свою пенсію. А мені доведеться йти в банк. Там треба купити картку з одноразовими ключами за 40 грн, так сказала техпідтримка. :(

А ще вчора спробував купити квитки додому. Квиток в одну сторону чомусь вже коштує 57 грн. Недавно за ці гроші до Києва можна було доїхати. Стільки готівки я при собі не мав, а був в той час в центральних квиткових касах. Вони працюють до восьмої вечора, довелось раніше з роботи піти аби до них дістатись. І виявилось, що картки Visa вони не приймають. Якийсь задрипаний мінімаркет під моїм будинком приймає, а центральні квиткові каси Львівської залізниці – ні. Я просто не знаю що сказати…

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


Filed under: Кодерство, Нещоденник Tagged: гроші, зле, Python

Це не так просто – розуміти.

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

Neo: Do you always look at it encoded? Cypher: Well you have to. The image translators work for the construct program. But there's way too much information to decode the Matrix. You get used to it. I...I don't even see the code. All I see is blonde, brunette, red-head. Hey, you uh... want a drink?

Нео: Ви завжди дивитесь не неї зашифрованою?

Сайфер: Ну, ми змушені. Транслятори зображення працюють над програмою конструювання. Але тут надто багато інформації щоб розкодувати Матрицю. Ти звикнеш. Я… Я навіть не бачу код. Все що я бачу – блондинка, брюнетка, руденька. Ей, ти еее… не хочеш випити?

Передмова

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

Проблема перша – я не знаю ООП в JavaScript. Дякуючи документації до LeafLet, і тому що ООП там реалізовано через нього – проблема майже розв’язана. Ну й звісно JavaScript я в терміновому порядку підтягую.

Проблема друга – проект з галузі Business Intelligence. А я про схему даних “сніжинка”, OLAP-куб та інші подібні речі чую вперше. Але я почитав вікіпедію, подивився всілякі відеопояснення і тепер маю певне поняття. Якось ним поділюсь, може хтось скаже що моє поняття про BI хибне.

Третя, і головна проблема – купа коду без жодної документації. І на відміну від попередньої роботи (prom.ua), де проект пишуть роками і далі будуть, тут проект писали пів року (судячи з логів СКВ), дедлайн вже в кінці місяця, тому рефакторингом мене попросили не займатись. Ще до того як я запитав чи можна. Про документацію я не питав, тому що документація – це нереально, якщо ви звісно не пишете якусь бібліотеку з відкритим кодом. Зовсім нереально. Але юніт тести – в нашому випадку теж дуже важко, через специфіку середовища. Хоча менеджер сказав “Хочеш тести? Дуже добре!”, і при цьому якось дуже підозріло посміхнувся.

Хоча код знадобилось би трішки підчистити, тому що:

nested_code

Тому мій єдиний вихід – ввімкнути щось схоже на “Push it to the limit“, і поринути в читання. Але код – це не книжки (я читав книжку про те як читати книжки, а про те як читати код – не читав), крім того автор книжки зазвичай хоче аби ви прочитали книжку, а автор коду – лише аби комп’ютер той код зміг виконати, та й досвіду читання коду в мене набагато менше, тому думаю треба дізнатись як це роблять інші. Переберу-но я кілька статтей:

Мотивація

Елі Бендерський пише про те як розуміти власний код. Код який неможливо зрозуміти, на його думку – це такий самий, або можливо ще більший гріх, ніж код який не працює. А програмісту який з гордістю заявляє що не розуміє код який писав тиждень тому, треба давати в писок аби вибити з нього ту гордість. За цим посиланням мені “дають в писок”. Хоча я гордився не тим що написав незрозумілий код, а тим що я його таки зрозумів і навіть трішки спростив. :)

Методи написання коду який буде вам зрозумілим – регулярно його перечитувати і переписувати.

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

Зібрані поради

  • Зрозуміти що від програми вимагається і для чого її пишуть. Перед тим як робити все інше.
  • Спитати автора.
  • Пройтись за допомогою зневадника.
  • Вставляти багато print та assert.
  • Записувати всі відкриття в письмовій формі.
  • Спробувати щось змінити і подивитись що зміниться, а що зламається.
  • Парне програмування з розумним колегою чи автором. Спробуйте думати вголос. Може виявитись що в вас різні думки і почнеться продуктивна суперечка.
  • Код не читають рядок за рядком. Якщо щось не розумієте – можливо ви ще не прочитали код в кінці який потрібен для того щоб розуміти код посередині. Пропускаємо, ставимо закладку і повертаємось до нього потім.
  • Знайти функцію main, чи як там називається точка входу і читати з неї. Якщо точок входу багато (наприклад багато обробників подій) – виписати їх список.
  • Прочитати документацію викликів зовнішніх бібліотек. (На щастя сторонні бібліотеки документуються частіше.)
  • Починати з простих частин. Якщо ти не можеш розуміти навіть ті частини що здаються простими – код або занадто заплутаний, або ти недостатньо знаєш мову чи фреймворк.
  • Рефакторинг. Наприклад дайте нормальні імена ідентифікаторам, кілька разів застосуйте extractMethod
  • Додавання коментарів туди ж… Тільки будьте певні що вони не введуть когось хто прийде після вас в оману.
  • Якщо поняття не маєте як почати писати коментарі – описуйте для функції трійки Хоара.
  • Почати читати з тестів. Якщо таких нема – покривати тестами. (А тих хто написав код без тестів – покривати матами :D ). Подивитись чи тести проходяться. Якщо не проходяться – значить ви неправильно зрозуміли як повинна працювати програма (і добре що ви це дізнались раніше поки ще є час зрозуміти її правильно), або вона працює неправильно (Співчуваю ви знайшли баг. Якщо ще не впевнені що зможете пофіксити – додайте в багтрекер.)
  • Намалювати граф викликів.
  • Роздрукувати код на кольоровому принтері з підсвіткою синтаксису, розкласти його на підлозі, взяти в руки кілька маркерів та олівців і лазити виділяючи точки входу, важливі виклики, дописуючи коментарі на полях і позначаючи важкодоступні місця.
  • Намагатись зрозуміти лише необхідний мінімум і припускати що решта коду працює так як і повинна. (А як дізнатись як повинна? :) )
  • Згенерувати за допомогою ctags та cscope чи що там у вас є, індекс для прискорення навігації по коду. Хороше IDE – головний інструмент програміста-археолога. Також є інший софт, на зразок LXR (для читання коду Linux), Doxygen, Resharper, купа всякого…
  • Намагатись поміщати елементи в чорний ящик, тобто старатись зрозуміти ЩО вони роблять, а не ЯК вони це роблять. Правда тут є виверт 22 – код містить опис того як щось робиться, а що робиться – нам якраз потрібно зрозуміти. Тим не менш – треба абстрагуватись як тільки зрозуміємо якусь частину і переходити до наступної.
  • Спитати досвідчених користувачів програми, які не обов’язково повинні бути її творцями. Можливо якщо повністю зрозуміти як люди працюють з програмою – не доведеться її читати, можна буде написати свою версію. :)
  • Виділити найважливіші прецеденти, зрозуміти їх.

Посилання

Також варто сказати про те що тут – як з підтягуванням. Знання про те що не варто скрипіти зубами, напружувати прес чи інші м’язи (якщо в вас коліна підтягуються до грудей – це не добре). І не забувати видихати при скороченнях і видихати при розслабленні. І мати стабільний ритм. Але тільки це не допоможе вам підтягуватись 20 разів поки ви не спробуєте 2, потім 3, потім 4 і так далі, регулярно та постійно.

Література


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

Теорія вивчення іноземної мови

Перейти зразу до суті.

Наука дослідження людини, а особливо її мозку куди складніша ніж наприклад комп’ютерні науки, тому нема чого дивуватись що в цій галузі існує купа найрізноманітніших напрямків. А міждицсциплінарних – ще більше. І виявляється на стику прикладної лінгвістики (як використовувати мову з користю?) і когнітивної психології (як люди думають своєю головою?) існує наука про опанування другої мови (second language acquisition). Відрізняється вона від науки опанування першої мови тим що опановуючи першу мову ви використовуємо лише наші вроджені інстинкти мавпування, а не підручники і спілкування з викладачем. Я прочитав про цю науку, і хоча там роблять публікації ще з 80-тих, але поки що не сильно наблизились до проекту Вавилонської вежі.

Правда одна ідея мені таки запам’яталась: існує два типи навчання: елементне та системне. Я так зрозумів це як синтетичний та аналітичний підхід. В першому випадку ми вчимо окремі елементи мови: слова, речення, певні фрази і т.п. В другому випадку ми вчимо якісь систематичні правила.

І особисто для мене працює лише елементне навчання. Правила я все одно не можу запам’ятати бо для їх використання треба думати. А мова це така штука яка повинна сидіти десь глибше свідомості. Ви бачите слово immer, always, ĉiam, всегда, いつも чи завжди і у вас залежно від контексту автоматично повинно засвічуватись поняття \forall t. Чи в крайньому випадку при immer повинно засвічуватись “це німецькою означає завжди”. Далі контекст повинен переключитись і всі наступні слова вже автоматично беруться зі словника.

Правда можуть виникнути сюрпризи наприклад коли ви чуєте “Bei mir bist du schein” і пробуєте перекласти з німецької, а потім інтернет підказує що то насправді ідиш, а німецькою пишеться “Für mich bist du schön”.

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

Коротше кажучи зараз я намагаюсь перевірити гіпотезу того чи можна мову вивчити самостійно на рівні читання газет, просто читаючи. Хоча я вже прослухав Pimsleur German I, подивився Extr@ auf Deutsch (тепер залишилось вивчити німецьку і можна буде ще раз подивитись), прочитав по 50 сторінок Langenscheidt Німецька мова 20 хвилин щодня, і С.О. Носков “Самовчитель німецької мови”, потім знайшов ключі до вправ і подумав що їх все таки напевне варто робити.

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

Проте все одно, щоб читання не було таким болісним, на перших етапах хотілось би якось уникнути текстів що містять багато низькочастотних слів, і читати якісь учбові тексти. Ідеальною була б книжка на зразок “Gerda malaperis”, але вона чомусь одна така, і лише для есперанто.

Плюс книжки Gerda malaperis в тому що це детектив, який дає якусь напругу, і викликає постійне бажання дізнатись що там далі. Часом настільки що починаєш пропускати половину слів, сюжет все одно від того не змінюється. Це мінус. Тому щоб себе стримувати повинен бути якийсь тест. “Після прочитання цього розділу ви повинні знати наступне. Якщо не знаєте – потрібно читати уважніше”. Плюс будь-якого тесту, навіть найлегшого в тому що він змушує задуматись. І я придумав теорію як зробити тести складнішими.

По суті

Є набір пар запитання – відповідь. В нашому випадку запитання – це слова або фрази на зразок “es tut mir leid”. Відповіді – це їх переклад, в даному випадку “мені шкода”. Треба перевірити знання цих пар, і вказати користувачу слабкі місця. Яким чином визначити слабкі місця? 10 разів перевірити чи користувач знає слово. Якщо він 9 разів з десяти знає – то так і записати – це слово користувач знає на 9 з десяти. Далі вибирати слова які користувач знає найгірше і давати їх йому.

Тести з варіантами відповіді – найкращі для комп’ютера тому що їх просто перевіряти. Для тестів “введіть відповідь” потрібно буде зробити неслабенький синтаксичний аналізатор і зведення відповіді до “канонічної форми”.

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

Якщо користувач раптом помиляється, і обирає варіант б) ми записуємо в табличку з помилками пару entshuldigung – їсти, і кажемо що при 10 показах слова enshuldigung користувач обрав цей неправильний переклад 2 рази. І таким чином коли ми наступного разу будемо показувати тест зі словом “пробачте” користувачу, ми з більшою ймовірністю домішаємо туди помилковий варіант “їсти”, просто тому що користувач частіше робить цю помилку.

Таким чином можна буде виявити слова які я плутаю, наприклад: besuchen – відвідувати, гостювати; brauchen – потребувати; bekommen – отримувати, і вчити мене їх не плутати.

Я вирішив підівчити JavaScript, і написати програмку для цього. Вчора виклав її прототип на github. https://github.com/bunyk/item_lang_learn.

Проблеми на даний момент – я здається якось неправильно прив’язую події до кнопок з варіантами відповідей, бо після кількох кліків завжди запускається тільки подія для неправильної відповіді. Напевне варто переписати з однаковим обробником для всіх кнопок, але присвоїти кнопкам різні ідентифікатори.

Друга проблема – якщо робити модель на основі localStorage – треба буде за допомогою JavaScript багато сортувати, і взагалі робити речі які гарна база даних робила б за нас. А localStorage не вміє.

Ну, і ще проблема в тому аби зробити оформлення нормальним. jQueryUI і Bootstrap ніби непогані, але лише їх недостатньо.

Але наступного року придумаю як з цим розібратись.


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

Новий кваліфікаційний рівень і пізнання AOP

Ах, я його отримав позавчора. Але часу побритись не знаходжу, не те що про це написати.

Ну але зараз я маю хвильку часу:
все зробив
тому знову похвалюсь.

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

На захисті запам’ятався елемент виступу мого одногрупника, забув як його звати, але пам’ятаю що він senior Java developer в EPAM.

Він сказав: AOP – це парадигма яка дозволяє замість, перед чи після методу виконати ще якийсь код. І я прозрів! Аспектно орієнтоване програмування – це декоратори. І маємо ще простіше визначення ніж “екзистенціалізм це гуманізм”, бо AOP це таки точно, за визначенням декоратори.

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

Я правильно розумію парадигму?


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