Sep 24 2009

TLA

Category: Dev,НонсенсLucho @ 16:26

Ето някои абривиатури, които може и да знаете или да незнаете, кой знае…

ACID – Atomicity, Consistency, Isolation, Durability

CRUD – Create, Read, Update, Delete

DRY – Don’t Repeat Yourself

GNU – GNU is Not Unix (recursive acronym)

BSD – Berkeley Software Distribution

BashBourne-again shell

GPL – (GNU) General Public License

CRM – Customer Relationship Management

CMS – Content Management System

DTD – Document Type Definition

PHP – PHP: Hypertext Preprocessor (recursive acronym)

ASP – Active Server Pages

TDD – Test-driven development

BDD – Behavior Driven Development

REST – Representational State Transfer

SOAP – Simple Object Access Protocol

COTS – Commercial off-the-shelf

TFT – Thin-film transistor

LCD – Liquid Crystal Display

Естествено има още много, но според мен има голям шанс да незнаете някои от тези, а пък се срещат тук-таме 😛


Aug 22 2009

Share your screen

Category: Dev,Firefox,HTML5,Web,НонсенсLucho @ 03:43

Напоследък съм изгубил творческата си искра, в работата се занимавам с .NET 2 (нестига, че е .NET ами и е от 2004г 🙁 ) не съм почивал цяло лято и ми се ще да пиша на Ruby и Rails или Objective C за iPhone. Та сред всички тези несгоди и поради факта, че съм програмист все пак (а добрите програмисти решават проблеми ежедневно и би трябвало и своите да могат да решат!!!) предприех някои стъпки за измъкване от блатото, като една от тях беше да си пиша малко проектче за мое лично удовлетворение. Първоначалната идея изникна в главата ми по напълно случаен начин, с времето идеята се развиваше и променяше, пишех по малко код и очаквах вдъхновението ми да се върне и да ми каже какво да правя… е този момент дойде днес – тази вечер.

Първоначалната ми идея, с която няма да ви занимавам сега, включваше използване на HTML 5 Canvas – платно на което може да се рисува и дава пълен достъп до битмапа – красота! Естествено този стандарт е все още слабо разпространен сред браузърите, защото е нов (Microsoft-ския Trident още не го подържа изобщо, бахти изостаналата нация :-P). Идеята включваше и Рейлс, но прагматичното в мен победи и пожела да запълня 99% свободен bandwith на хостинга ми (да, блога ми е толкова популярен, че ползвам <1% от линията 🙁 ). Това води след себе си сравнително неприятното задължение да пиша на PHP… но няма да се лъжем, на PHP се пише много бързо, ама много, много бързо и грозно и… абе селска работа! Предните седмици, докато чаках вдъхновението, реших да проуча въпроса, как мога да взема изображение от клипборда и да го плесна на кенвъса, оказа се нетолкова лесна история, но възможна все пак. Цената не е прекалено висока – ползвам Java Applet-че, което върши цялата работа всъщност. Алтернативата е Flash, но доколкото разбрах Flash 10 налагал по-строги ограничения за боравене с клипборда, а и не обичам Flash и ActionScript (винаги ме е боляло много след интервенция с тях). Големият проблем е, че някъде при прехвърлянето на битмапа от клипборда през аплета към javascript-ския код нещата стават много бавно и това може да отнеме до няколко секунди, за по-големи изображения, но като се абстрахираме от това – ТО РАБОТИИИИ!!!! Следващото нещо, което направих е функционалност за селектиране на фрагмент от кенвъса, почти като в Paint или друг редактор… и в общи линии до тази вечер бях стигнал до тук, когато ме осени идеята – selection tool-а става на crop tool и целия проект се превръща в 3-click-screen-share. Гениално наистина, print screen, paste, [optional: crop], save и получаваш линк… а и подобно нещо не съм виждал да има досега… е друг е въпросът колко често на човек му трябва подобно нещо, но като се замисля, че иначе трябва да отваряш image editor, пък после да save-ваш, пък после да го публикуваш някъде, и накрая да пратиш линк – it is retarded!

Първоначалната версия на услугата е тук: http://dailyffs.com/shotme/

За сега всички енджини без този на Microsoft подържат в някаква степен Canvas, като за FireFox 3.5 приложението върви на 100%. Естествено за view на изображението впоследствие не е необходимо нищо специално и всеки браузър би свършил работа, така че всички ще могат да видят скрийншота ви – спокойно 😉

Ако някой има предложения или поне му е харесала идеята или пък го е отвратила, може да напише мнението си тук. Чуждият фийдбек е стимул, стимул за подобряване, изпипване и разширяване на идеята. Ако има интерес ще наема нов domain и ще се постарая да оправя забавянията, да сложа една четка, че да може да оградите примерно определено място от изображението, на което искате да наблегнете.

Хубаво е когато човек дава свобода на въображението и творчеството си, кара те да се чувстваш щастлив и да си изпълнен с идеи и енергия… даже и цената, която трябва да платиш да е малко писане на PHP 😛


Jul 06 2009

Дългият път на съзиданието

Category: Dev,НонсенсLucho @ 18:24

Често обичам да не документирам, да не описвам нещата които правя… понякога съжалявам за това. И не толкова че видите ли след 5 години ще съм забравил за какво е бил даден проект, а по-скоро защото не записвам яките моменти, които съм преживял докато съм го разработвал.

Ето, сега ще се поправя и ще опиша стъпките, идеите, мислите, абе всичко през което минавам докато дивелъпвам проекта си по Python. В този смисъл постът, който четете в момента ще се допълва ежедневно с новости, за това стей тюнд.

Проекта представлява конзолен mp3 плейър за Линукс (уж Python е портабъл… но аз не го вярвам това, за сега 😛 ), като интерфейсът ще е тип “стара дос програма” – графичен интерфейс с ascii символи. Надявам се, освен стандартните за всеки mp3 плейър нещица, да успея и да го накарам да работи с онлайн радиа (streaming). Естествено в момента си поставям цели, за които не съм напълно убеден дали ще са реализуеми… но какво пък – ще опитам! Друг фичър, който много искам да направя е да минава в бекграунд режим, за което имам някакви идеи, но пак неизвестните са доста.

Естествено вече съм попрегледал какви благинки предлага Python и какви външни компоненти (ех, колко SE  звучи това) бих могъл да ползвам. За нещастие, част от нещата изглежда са за Python 2.5, но докато неразцъкам и това твърдение е в сферата на unknown-ото.

Day 0:

И така “дей 0” е по-скоро “вечер 0”, бутнах се под Убунтуто си и си сложих Eric (IDE за Python). Доста бутони, доста функции, дано да се работи приятно с това нещо. Тръгнах да създавам нов проект и се сетих – нямам име за него. Е… след 15 секундно размишление се спрях на “Pyp3” (“пай-пи-три”). И така вече съм готов да започвам най-нелепата част… подкарване на някой от основните модули които ще ползвам. За съжаление не намерих нищо,  което да пуска звук и да е за Python 3, така че ще се пише на Python 2.5. Това всъщност не е толкова зле, защото:

А) Рано или късно ще портнат библиотеките до 3

Б) Python 2.5 е стандартна версия за всяко Убунту и други дистрибуции

Та инсталирах audiere и numpy (дипенденси) от репобраузъра и успешно пуснах една mp3-ка (чак да не повярва човек 😀 ). Следваща стъпка е да разцъкам curses – нещото, което осигурява ascii интерфейса.

След един час четене не умопомрачително дългия менюъл на curse и малко конзолно тестче стигнах до следните два важни извода:

1. Curse няма готови диалогчета (за open file например) – селско (все пак има надежда, че някъде някой е написал нещо по въпроса)

2. Терминалите не са това което бяха. На 22 инчов монитор в текстов режим имам 48 реда по 136 колони, в графичен много повече… къде изчезнаха добрите стари 80×25. Може би са изчезнали заедно с DOS, кой знае :D. На малкия ми латоп (резолюция 1024х600), в текстов режим конзолата е баш 80х25 реда. Т.е. нищо не изглежда както трябва – неприятно.

Друг проблем е че трябва да поддържам доста диалогови прозорци и мишка. Решението може би е тази надстройка на curses – Urwid, която ще спести излишното копане за диалози.

Интерфейса, който за сега ми се върти в главата включва тикер за текуща песен, скролче за звука, бутони add, rem, jmp, que, ext, bkg (добавяне/махане на песен, jump по име – включва диалог, que – включва диалог, exit и преминаване в background режим), текуща плейлиста (в общи линии списък със заглавия).

Day 1:

Продължих да разцъквам Urwid и като цяло съм доста доволен. Направих прототип на плейлиста, но изникна нов проблем. В плейлистата човек може да има хиляди песни и е нормално да има скролбар, само че скролбара е фиксиран от броя редове в терминала (това значи, че е ограничен по брой позиции, на които да се мести), което неминуемо води до проблем че при преместване на скролбара с една позиция, в листата може да бъдат скипнати повече записи отколкото може да покаже. Ще се получи “прескачане”, което ще е по-скоро дразнещо от колкото полезно. Поради този факт (и това че скролбар не е имплментиран в Urwid официално :-P) обмислям вариант да мина без скролбар, а по-скоро с филтър, който да филтрира песните по част от име и да сложа поле, което да показва на кой номер песен (страница) е плейлистата в момента. Това би помогнало и за реализацията на Jump функционалността, като просто се филтрира по ключова дума и се натисне някаква клавишна кобмбинация… нийййт. Вечерта завърши с Пранка 🙂

Day 2 & 3:

За тези два дни горе-долу направих плейлистата и филтрирането и леко се отчайвам от скоростта с която напредвам, а ми предстой да свържа кода за directory browsing с плейлистата. Все пак все повече ми се избистрят идеите в главата, така че може да се каже че положението не е толкова критично. Дано дедлайна не ме притисне много…

Day 4:

Интегрирах кода за браузване из файловата система с плейлистата и добавих код за плейване на аудио файлове – даже пуснах няколко (big success)! Вече съм една идея по-спокоен, защото имам нещо работещо. И все пак ми остава queue функционалността на плейлистата, което няма да е толкова прозрчано и просто. Чудя се дали да не напиша малко тестове и паралелно с това да не рефакторна кода на няколко места, може би е добра идея (Както се вижда съм скептик относно предварителното писане на тестове… а по принцип съм скептик и относно писането на тестове ИЗОБЩО, но се старая да променя това!!!). Намерих още една библиотека, която би била полезна в проекта – Mutagen, служи за четене на тагове от разнообразни аудио формати и ще ми помогне с title/author в плейлистата.

Day 5 & 6:

Уж беше събота и неделя, а свърших доста малко неща. Все пак позавърших изгледа на плейъра и четенето/показването на ID3 таговете. Реших да отложа правенето на опашка, защото е мега досадно и не е толкова фън, колкото плейването на стрийминг и рънването в бекграунд. Плейването на стрийминг се оказа доста нетривиална задача, която ми отвори един куп проблеми, та и там нещатата не са розови. Трябва да почна да пиша тестове… ех тези ш****и тестове…

Day 7 & 8:

Оказа се, че Audiere е тотално скаран с всичките ми идеи да го подкарам с http стрийм… то не бяха наименовани пайпове, сокети, даже се мъчих да му вкарам numpy-ски масив от float32, но след дълги среднощни борби реших да се преориентирам към GStreamer, който е бая тежко, по-точно обемно нещо, и много исках да не опирам до него. За това пък плейва без грижи само като му се даде URI. Отначало исках да ползвам Audiere за плейване на локални файлове и Gstreamer за уеб стрийминг, но освен че е доста грозно решение, срещнах трудности в освобождаването на заетия аудио ресурс когато искам да подменя on-the-fly библиотеката. По-точно Audiere освобождаваше веднага всичко, но на GStreamer му отнемаше поне 5-6 секунди и switch-ването помежду им не ставаше гладко. В резултат на това се наложи да си напиша адаптор към GStreamer от стария код за плейване на фиайлове, който ползваше Audiere. Беше кървава баня, но се справих, даже промените по интерфейса бяха почти незначителни. За съжаление GStreamer е слабо документиран също, макар че има туториали, но референса (вкл. и този, който е в интерпретатора) е много постен. Голяма мъка беше, но сега поне мога да плейвам радио 🙂

Day 9:

Гледах Ледена Епоха 3 (3D), но не беше нещо особено. Поради този факт не свърших много – оправих цветовата схема на плейъра, проведох задълбочен рисърч за пускане на application в background, който не доведе до никакви реални резултати. Впоследствие открих workaround – просто трябва да се пусне плейъра във втори терминал (ctrl+alt+f[1..6]) и да се switch-ва в него като трябва да се контролира pyp3. Останаха ми още два малки таска и после тестове.

Day 10:

Добавих възможност за конфигуриране на outlook-а на плейъра, като се опишат цветовете на отделните части от ascii интерфейса в конфигурационен файл. Готино е когато нещата са максимално customisable. Сложих и event handler, който да следи по кутлурен начин дали дадена песен е свършила. Това ми отне сумати време, защото няма кой знае колко полезно инфо в нета… или трябва да падне голямо четене, докато се разбере по-точно. Много мразя, когато се занимавам с непопулярни неща, защото са слабо документирани и само ми късат нервите! Освен това в крайна сметка при четене от online stream не пристига event за край на stream-а ако се прекъсне връзката, което е хипер малумно, защото на това се надявах най-вече :(. Оправих разни бъгове и с това приключвам официално работа по Pyp3 (е имам да пиша тестове, но за тях няма да блогвам).

Final Conclusion:

Използвани компоненти: GStreamer, Urwid, Mutagen, Audiere (GStreamer-а го замени впоследствие)

Функционалност:

– плейване на файлове и стрийминг

– филтриране, jump, add/del, select, directory browsing dialog (само интегриране)

– auto save/load на плейлистата и цветовата гама на плейъра

– play/pause/stop/next/prev, fastforward/slowbackward ( 😀 ), ID3 tags, текущо време на плейване, state на плейъра, volume

– autoplay next track, autoreconnect to stream on lost connection

След една камара време и безсъние резултата не е чак толкова грандиозен, но това се дължи основно на факта, че падна голяма борба заради слабите документации и защото трябваше да switch-на от Audiere към GStreamer. Съответно голяма част от времето отиде за направата на, иначе, не особено сложни неща.

Неща за които не ми стигна времето:

– Queue – малко ме е яд за това, защото има полза от опашка

– Rating – не ползвам такива неща… но може да има смисал

Все пак от много време не бях писал нещо, което да ми е на сърце и да ме ентусиазира, така че, въпреки всички трудности съм happy 🙂

pyp3


May 05 2009

The King of Quines

Category: DevLucho @ 18:44

Quine не е миспелнато Queen, а програма, която извежда сама себе си и се надявам не само мен ме freak out-ва това. Все едно някой андройд да разбере, че не е човек, а машина. Почти толкова тъжно е както когато малкото роботче в AI на Спилбърг отчаяно искаше да намери феята, за да го превърне в истинско момче и майка му да го обича… драма драма.

За типичния Quine е удобно да се ползва printf-оподобни функции, които да имат еднакъв форматиращ низ и аргумент за форматирането. По този начин се получава нещо като вложено построяване на низа за печатане. Друг подход е функционалния, който е представен по-надолу (Javascript частта).

Предполагам, че все още на никой нищо не му е ясно и тъй като не мога да направя по-дълго отрицание от това, ето няколко варианта написани на някои от скриптовите езици, с които съм имал вземане-даване (популярните езици изискващи компилация имат твърде дълги Quine-ита).


Python

_='_=%r;print(_%%_)';print(_%_)

Какво прави кода: записва в променливата _ форматиращия низ, като %r значи да се изведе repr на обекта (това ще изведе текстово представяне на обекта, ако обекта е низ ще изведе и единични кавички), а %% е escape-ване на %. После се извиква print, като се форматира низът от _ сам със себе си (%).

_=’_=%r;print(_%%_)’;print(_%_) -> _=‘_=%r;print(_%%_)’;print(_%_)


Ruby

_="_=%p;puts _%%_";puts _%_

Какво прави кода: прави същото, което и горния код, но тук вместо %r имаме %p, функцията за отпечатване се казва puts и нямаме нужда от скоби за извикването на функция (обичам Ruby).


PHP

<?php $f='<?php $f=%c%s%c; printf($f,39,$f,39); ?>'; printf($f,39,$f,39); ?>

Какво прави кода: да, познахте, кода прави същото, което и предните два, с тази разлика, че php изисква допълнителен незначещ crap, който да се зарови около кода (<?…), печатащата функция е printf, която има синтаксис сходен с printf от C, а за да оградим резултата в единични кавички се изписва ascii символ 39, което както се досещате е единична кавичка.


Javascript

( function (x) { return "(" + x + ")(" + x + ")"; } )( function (x) { return "(" + x + ")(" + x + ")"; } )

Какво прави кода: тук става вече по-интересно, защото кода не прави това, което предните 3 функции правеха. Записа много прилича на Quine на Scheme и да си призная една част от него е загадка за мен (например защо като подадем като параметър на функция друга функция, получения аргумент е записа/кода на подадената функция, а не обект с адрес. Може това да е представянето, незнам). Първо и двете анонимни функции са еднакви, като втората е аргумент на първата и при изпълнение ще се запише два пъти със скоби отляво и отдясно, което е и изходния запис. Скобите са нужни, за да окаже in-place изпълнение на първата анонимна функция и че втората анонимна функция е аргумент на първата. Може да пробвате този код като го напишете в адресната лента на browser-а си (тествано с FireFox):

javascript: ( function (x) { return “(” + x + “)(” + x + “)”; } )( function (x) { return “(” + x + “)(” + x + “)”; } )



Apr 26 2009

Coders Dos and Don’ts

Category: DevLucho @ 20:52

Нерядко се натъквам на много дразнещи писания и идеи и мисля, че е време да си излея мъката. Мразя заклеймяването на някого като “младши програмист” или “нууб”, но просто има граници, които не трябва да се прекрачват и неща, които трябва да се забранят със закон. Ще спомена няколко от тях, за които не се говори толкова много – няма да обеснявам, че трябва да се спазват конвенции или че не бива да имате празен кеч блок и подобни всеизвестни работи.

1. Булеви сравнения

if (bool_var == true) { …

За всеки здравомислещ човек е ясно, че този запис е абсолютно излишен и е достатъчно да се напише “if (bool_var) {…, останалите нездравомислещи хора ще се оправдаят, че така кода е по-четим – дрън дрън! Този запис не само че не е по-четим, ами е грозен, по-дълъг и в някои случай даже объркващ.

Следния код е още по-фрапантен:

if (bool_var == true)  {

return true;

} else {

return false;

}

Пет излишни реда за да се постигне ефекта от “return bool_var“. Ако някой седне да чете кода и види подобни писания вероятно първо ще се зачуди какво сте имали предвид, после ще реши, че сте абсолютни нубове, а и прочитането на 5 реда и разбирането им е по-трудно от колкото прочитането и разбирането на един (изключваме разни функционално ориентирани езици, където един ред може да достигне стотина символа).

2. One Language Warshipers

Един феномен, характерен за повечето започнали работа наскоро е издигането в култ на езика, на който пишат. Особено характерно е за Java и C# (.NET) дивелъпърите. И тея хора като почнат да се прехласват и да разправят колко е велик единствения език, който са виждали и направо ми иде да… напиша някой ред в блога ми за тях 🙂 . Та хора, всеки език има някакви предимства и собствен “чар” пред другите. Неможе да ми обяснявате колко е велик Java за web (за малък до среден клас сайт) понеже ми се е налагало да се боря с него и има много куци неща, които разни други езици и фремуъркове са преудоляли успешно. Това че във фирмата където работите ви карат да пишете на опредлен език, защото системата им вече работи по този начин и няма връщане назад, не значи че пишете на нещо, което си заслужава. И даже и езика и технологията, която ползвате да е много добра в дадена област, това не означава че може да отворите файл и да запишете един низ вътре на един ред например и че няма много по-елегантни и приятни езици.

Човек трябва да е опънмайндед и да иска да научи повече и повече, а не да се забие в първата срещната технология. Светът не се състои само от Java и C#, в него има и други езици C, C++, Objective C (за маковски работи), Python, Perl, Ruby, PHP (недейте моля) und so weiter (има още много наистина), част от които са по-бързи, други по елегантни за писане, трети просто по-лесни. Всеки един от тях изисква специфичен начин на мислене и предлага различни концепций и когато човек реши, че само един единствен му е достатъчен определено се осакатява професионално, при това много жестоко.

3. Разбираемо писане vs. Оптимално писане

Под разбираемо писане имам предвид структуриран код, в който поне автора се оправя и знае кое какво прави… това често не е най-оптималния, най-добрия от към пърформанс код. Добра практика е след написването на разбираемия код да го превърнете в оптимален, ако има нужда де. Лошата (ама много лошата) практика е да напишете така кода, че да е с висок пърформанс, но след две седмици като ви докладват бъг, да се чудите къде и какво да пипате или ако се наложи някой да пипа по кода, да не му отнеме месец докато разбере, че записвате GPS кординати в int като местите побитово за да запишете всеки градус, минута и секунда 😀 . Та за начало, нека всичко е написано разбираемо и по лесния начин и за всеки неразбираем ред най-добре да има коментар, пък после, живот и здраве, с моторната резачка и с разни грозни хакове, може да се докарат нещата до по-оптимален и грозен вариант (може би в 99% от случаите, този параграф изглежда странен, но ако пишете за J2ME или друга платформа с много ограничени ресурси, може да е доста полезен).


« Previous Page