Блоґ одного кібера

Історія хвороби контуженого інформаційним вибухом

Posts Tagged ‘робота

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

leave a comment »

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

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

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

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

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

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

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

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

Written by bunyk

21 Серпня, 2013 at 22:15

Красиво друкуємо xml в термінал

leave a comment »

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

def pprint_xml(text):
    import xml.dom.minidom
    from pygments import highlight
    from pygments.lexers import XmlLexer
    from pygments.formatters import TerminalFormatter
    xml = xml.dom.minidom.parseString(text)
    print highlight(xml.toprettyxml(), XmlLexer(), TerminalFormatter())

Потребує pygments.

Разом з Інтроспектором та іншими утилітами для дебагу це вже тягне на якусь лібу. Напевне наступного тижня заведу собі таку десь на github.

Written by bunyk

2 Серпня, 2013 at 14:12

Опубліковано в Кодерство, Розмітка

Tagged with ,

Журнал роботи в Google Sheets та розширення його функцій з JavaScript

with 11 comments

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

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

В Google Sheets є дві корисні комбінації клавіш:

  1. Ctrl + ; – вставляє в клітинку дату
  2. Ctrl + Shift + ; – вставляє в клітинку час. В мене чомусь в форматі AM/PM.

Цього було б досить, але рахувати тривалість задач доводиться вручну. Незручно. Якщо є табличка:
Прочитати решту цього запису »

Written by bunyk

23 Липня, 2013 at 23:43

Пошук роботи програмістом

with 5 comments

Зразу попереджаю що зараз я працюю на своїй другій роботі, якщо не рахувати одноразової роботи велослюсарем та ще одного разу одноразової контент-менеджером, тому мій досвід пошуку роботи поки що не такий вже й великий. Але мене попросили поділитись, крім того я шукав роботу в трьох містах (Київ, Франківськ, Львів), немало ходив на співбесіди, моє резюме вже напевне має 20-ту редакцію (хоча в систему контролю версій я його лише недавно засунув, тому історія версій коротка), а ще в мене багато знайомих які теж успішно знайшли роботу і їхні підказки та підтримка дуже допомагали.

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

Written by bunyk

24 Червня, 2013 at 23:23

Опубліковано в Всяке

Tagged with ,

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

with 9 comments

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

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“, і поринути в читання. Але код – це не книжки (я читав книжку про те як читати книжки, а про те як читати код – не читав), крім того автор книжки зазвичай хоче аби ви прочитали книжку, а автор коду – лише аби комп’ютер той код зміг виконати, та й досвіду читання коду в мене набагато менше, тому думаю треба дізнатись як це роблять інші. Переберу-но я кілька статтей:

Мотивація

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

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

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

Written by bunyk

17 Червня, 2013 at 23:38