Получих покана от Веселин Тодоров да участвам в инициативата подхваната от Марио Пешев за това как протича една работна седмица.

Добре, че ме хвана след края на семестъра, защото когато трябва да посещавам университета, програмата ми е много странна и разпъната. И е тясно свързаната с програмата от университета. Сега след края на семестъра, вече не работя дистанционно от Варна. И от около една седмица съм в Добрич и ходя работа в офиса на pixeldepo, където работя.

Така, как протича един мой работен ден? Или поне как най-вероятно ще протича, базирано на това как мина тази седмица и как беше миналата и по-миналата година.

Ставам към 9 – 9.30

Едно от нещата, който наистина много мразя е да ставам рано (за мен 7 сутринта е време за лягане не за ставане). Будилника ми е настроен да звъни на три пъти – 9.00 / 9.10 / 9.25 и обикновено до към 9.30 съм станал. В следващите 20-30 минути, в зависимост кога съм станал имам време за душ, закуска и други подобни. В 10 часа вече съм тръгнал за офиса или ако шефа минава покрай нас по това време ме качва до офиса.

Начало на работния ден към 10.05 – 10.15

Офиса е на буквално 5 минути път от вкъщи(то маи в Добрич всичко е на 5 минути). Лошото е, че се минава през един доста стръмен баир. Но няма перфектни неща. И така към 10.10 съм вече на работа.  Първото нещо което правя е да проверя дали има спешни неща за правене до обяд и какво има да се прави като цяло за деня. Ако има нещо спешно се работи по него. Но когато няма, идва ред на “прегледа на печата” и на задачите – GMail / Basecamp / GReader / Twitter / Todoist / Taskar.  От там си заделям неща, за обедната почивка или video-та за слушане докато работя по нещо по-просто. Общо взето в преди обедния период не съм много продуктивен.

Периода между 11 – 12 часа

Това е може би най-странния и период от работния ми ден. В зависимост от това дали трябва нещо да контактувам с клиенти / да разпределям работата на колегите по проектите в който работя / да се направи нещо спешно като оправяне на бъг или добавяне на нов модул някъде, правя най-наложителното. Но в общия случай това е момента в които помагам на колеги или се осъжда нещо около текущия проекта.

Обедна почивка между 12 – 13 ~ 13.30

В общия случаи има два варианта за обедната почивка. Първия е да отидем някъде с нечия кола да обядваме навън с колегите. А Втория вариант е да “магазиним” ( т.е. ходене до магазина) и после да се обядва в офиса докато се четат / гледат / препращат / обсъждат нещата които са били отбелязани в “прегледа на печата”.

Същинската работа 14- 17.30

Това е най-продуктивната част от деня ми. Това е периода в които работата която върша е най-качествена и най-бързо работя. Обикновено докато работя и съм си намерил някоя интересна презентация, я слушам докато кодирам вместо музика. И нещата стават още по-добре.  Като цяло шума излизащ от мен намалява в този период и само при нужда се раздвижвам (като да се помогне с нещо на колега) .

Около 17.30 – 18.00 когато е края на работния ден пак намалявам оборотите. За да видя дали ще може да се остане в офиса след работно време до към 19 ~ 19.30 ~ 20 примерно. Защото обикновено ни “гонят” в 18 от работа (колкото и странно това да звучи).

Ако се остане след 18.00 пак имам пик в продуктивността, съпоставим с периода 14 – 17.30. Това си го обяснявам с това, че в офиса оставаме най-често аз и Добромир Райнов и климатиците, които вече не трябват, не бучат. И целия офис излъчва някакво спокойствие и уют по това време.

След края на работния ден

Когато съм във Врана има много различни неща за правене. Но Добрич в това отношение е малко по-скучен град, а и се оказва че повечето ми познати и приятели са във Варна. Така че след работния ден не ми е много интересен. А и още само една седмица съм тук и нямам много идеи какво да правя след работа. Надявам се най-сетне с брат ми, да започнем пак да ходим на фитнес или на някакъв друг спорт.

Събота – Неделя

Още не знам какво ще правя тези дни. Най-вероятно Събота ще спя до обяд. Ще ходя да се видя някои друг познат във Варна. Ще работя по някои личен проект или opensource проект. И ще блогвам сигурно. Но времето ще покаже.

Станков Live

По план от другата седмица в Сряда започва втори сезон на “Станков Live”. Това е малко нещо което правя всяка сряда някъде между 12.30 ~ 14.30 на работа. Тогава събирам колегите и говорим (т.е. главно аз говоря) за нови технологии, методологии и други интересни неща около последните проекти. Като цяло си обменяме опит и си сверяваме часовниците.  Поне от миналогодишния сезон си мисля, че доста добри неща произлязоха от това. Надявам се тази година да съм по-добър

Горе долу такава беше последната седмица. И такава би трябвало да ми е програмата за няколко то месеца до началото на новия семестър и до моето завръщане във Варна.

Тъй като инициативата е готина предавам щафетата на всеки, които я иска Малко късно се включих и затова много хора вече са писали доста интересни неща.

• Webcast: What to Expect in Rails 3.0
  (tags: programming rails ruby video)
• The Ultimate Wordpress 2.8 Optimization Guide
  (tags: php web wordpress optimization performance howto)
• Cocoa Dev Central: Learn Objective-C
  (tags: programming tutorial development objective-c)
• All Videos | Browse Videos | MIT World
  (tags: video mit talks)
• Forget Apple, THIS is Gadget Packaging at its Finest [Monday Morning Madness] – The Next Web
  (tags: video fun)
• Rob Cherny.Com: JavaScript Event Delegation and Event Handlers: Web Development and other stuff
  (tags: programming development javascript tutorial delegation event)
• The Top 10 Reasons The Ruby Programming Language Sucks
  (tags: ruby presentation)
• Different approaches to positioning a comment icon in Basecamp and Backpack – (37signals)
  (tags: web tips design webdesign webdev css tricks 37signals)
• Advanced Rails Studio: Custom Form Builder
  (tags: programming rails ruby tips webdesign web plugin templating)
• The Ruby Toolbox: Know your options!
  (tags: programming rails web plugins development library reference)
• Containers and their children
  (tags: programming tutorial webdesign html css)
• CSS – Imageless Rounded Corners | A JavaScript, CSS, and XHTML Resource By Matt Snider
  (tags: css)
• How Steve Jobs Was Able To Save the Company
  (tags: apple history)
• rdoc.info
  (tags: tools api plugins opensource ruby rails rdoc docs)
• How Twitter Will Change the Way We Live – TIME
  (tags: internet web article twitter web2.0 toread)
• Интернет речник- Статия: Кубчето на Рубик

Измина малко повече от година (1 година и 4ри дни да сме точни) от излизането на Firefox 3. Още със самото си излизане подобри рекорди. Но мина една година и какво се случи през нея със Firefox и браузърите като цяло.

Като начало всички вървят напред към HTML5, доста браузъри вече имат html5 благини като <canvas>/<video>/Selector API/Storage/Data Attributes.

Същевременно има и нова версия на EcmaScript – 5 (т.е. JavaScript) и се очаква до края на година в браузърите да започват да се появяват части от новата спецификация. Която поне на хартия изглежда много обещаващо.

Firefox

И след като беше подобрен рекордът брояча за свалянията на Firefox работи и момента е на скромните – 28,340,281.

В момента аз съм със версия Firefox 3.0.11. Преди време бях писал за 3.1, но такава версия няма да има. Поради факта че в 3.1 има много промени по Firefox версията ще е номерирана 3.5 и се очаква да излезе до месец най-много. За нея имам надеждата, че ще стане както при Firefox 2, която се водеше бавна, и заемаща много RAM. И при излизането на тройката всичко беше перфектно. Сега година след това отново се чува от всякъде за версия 3, че Firefox е бавен и много тежък. Така че много се надявам 3.5 да е достатъчно бърз. И от тази статия Chrome and Firefox 3.5 Memory Usage – поне нещата изглеждат много добре.

Друго нещо за което много чакам 3.5 са и няколко CSS добавки, които въпреки че не се виждат под 3.0 ги ползвам в 90% от административните модули на сайтове, който правим в pixeldepo. И така при самото излизане на 3.5 ще има доста доволни клиенти

Safari

Преди няколко седмици излезе версия четири, която утвърди Safari като един от най-добрите браузъри. Също така Safari е много близо до това да замени Firefox като браузъра, който ползвам всеки ден. Общо взето ако ги имаше “малките неща” от Firefox в Safari, щях да съм забравил отдавна за Firefox. Но ако Firfox 3.5 не скъси малко границата със Safari може и да забравя тези неща. Защото за момента според мен Safari е най-добрия браузър на пазара.

Chrome

Chrome, беше изненадващ ход от страна на Google, за него писах няколко пъти тази година. Това, че ползва WebKit, го прави много лесен за работа, т.е. да правиш неща за него. Подобно на Safari-то с него съм нямал проблеми до сега. Има красив интерфейс и много ме радва, че все повече познати го ползват.

Opera

Като стана дума за проблеми. Opera е браузърът който ми е създавал най-много главоболия тази година. Даже повече от IE6! Това се обяснява с факта, че като цяло Opera е малко използван и бъговете за него не са толкова известни.

Но за самата Opera как беше година? По различни статистики Opera най-много пострада от Chrome. Голяма част от пазарния дял на Chrome идва от този на Opera (което мен лично ме радва).

Друго интересно нещо е че Opera 10b идва, което е проблем за много js библиотеки. Тъй като е първия браузър който стига двуцифрен номер, той има честа да се сблъска с Browser Detection проблем. Т.е. за много библиотеки Opera 10 е Opera 1, защото вземат само първото числи от версията на браузъра Затова Opera 10 ще се води версия 9.8 (нещо като това че Windows 7, същност ще е 6.1)

Internet Explorer

При IE-та също не беше много тихо тази година. Продължава борбата за намаляване на IE6 и доста хора и компании спряха  да грижат за IE6, което според ме е правилното решени.

Излезе IE8, като единственото добро нещо което може да се каже за него, е че е доста по-добър от IE7. Все още е светлинни години от добрите браузъри като Firefox, Safari и Chrome, че даже и от Opera. Няма да забравя първия път като го пуснах, колко грозен ми се стори целия му интерфейс. Като цяло са налага на Microsoft да дават $10 000 на хората за да го ползват (което ми напомня за тази Mac vs PC реклама).

И като стана дума за Microsoft и реклама,  за IE8 беше пусната и доста смешна (да не кажа по-остра дума) таблица с това колко IE8 е по-добър от Firefox / Chrome. Самата таблица като я гледах и си мислех кое от кое звучи по-смешно – Performance, Web Standards или Developer Tools, не можах да избера. Всичко изглежда толкова смешно и жалко. Дано не и се вържат много нормални хора, защото не вярвам някои нормално мислещ developer да се хване.

За повече информация относно IEтата, препоръчвам тази статия: QuirksBlog: State of the Browsers – IE edition

Заключение

Миналата година беше доста интересна и забавна и според много хора маркира началото на новите Browser Wars. До колко това е така, всеки може да прецени за себе си. Но поне според мен бъдещето е доста светло – по-бързи браузъри, по-вече стандарти ( в добрия смисъл на думата), html5, подобрен javascript, по-малко IE6

В JavaScript във всяка функция има предефинирана променлива arguments. Тя представлява масиво подобна структура съдържаща аргументите подадени към функцията  и callee . В поста ще се постарая да обясня какво точно е callee и как би било полезно.

Само да поясня за думата “масиво подобна структура”, преди да продължа нататък. Това значи, че arguments изглежда като масив. Т.е може да се достъпват  елементи от него с arguments[n] и има свойството length, което оказва броя на елементите. Но до тук свършват прилики му с масива, в повечето браузъри arguments няма нито един метод. Това е една от главните причина в prototype.js да я има $A функцията.

Така, но да се върнем на arguments.callee, какво точно е това? В callee се записва връзка (или референция, ако това звучи по-добре) към текущата функция, т.е. функция в която е arguments. Това може да се илюстрира със следния пример:

function foo(){
    console.log(arguments.callee == foo);
}

foo(); // true

Защо толкова често foo се ползва в примери, някои знае ли ? Даже страница в wikipedia има – foobar.

Два прости примера

// пример едно:
// функция която брои колко колко пъти е била викана.
function example1(){
    console.log(++arguments.callee.count);
}

example1.count = 0;
example1(); // 1
example1(); // 2
// и така на татък

// пример две:
// функция, която проверява дали броя на подадените аргументи е толкова колкото се очакват
function example2(a, b){
    if (arguments.length == arguments.callee.length){
        // тук може и throw "error" да се хвърли, но за примера и това върши работа
        console.log(
            'expected ' + arguments.callee.length + ' argument(s) given ' + arguments.length
        );
    }
}

example2();          // грешка
example2(1);         // грешка
example2(1, 2);      // работи
example2(1, 2 , 3);  // грешка</pre>

Във втория пример използвам Functon.length, който указва колко аргумента очаква дадената функция.

Два полезни примера

Като цяло с argument.callee може да се правят доста магии. В практиката повечето случаи, в които съм го ползвал е, когато съм имал анонимна функция и искам да направя нещо със самата функция и ми трябва връзка към нея.

Пример1: Имате event  handler при click и искате след първото натискане този handler да се махне.
В допълнение може да се направи при click event handler-ът да се предава от елемент на елемент, но това няма да го пиша, за да не натоварвам примера (ако някои иска може да го напиша допълнително).

// предполагам, че се ползва prototype.js
$('element').observe('click', function(){
    alert('this will be shown only one time');

    this.stopObserving('click', arguments.callee);
});

Пример2: прост ефект – увеличаване на размерите на квадрат. Използва анонимна функция която се само извиква с timeout, докато div-а не достигне максималния си размер. В повечето случаи interval би вършил работа, но принципа е важен в случая.

// тук създавам примерен div
var element = new Element('div').setStyle({
    width: '10px',
    height: '10px',
    backgroundColor: 'red'
});

document.body.appendChild(element);

var step = 10, max = 1000, time = 10;

(function(){
    var width = parseInt(element.style.width) + step,
        height = parseInt(element.style.height) + step;

    element.style.width = width + 'px';
    element.style.height = height + 'px';

    if (max > width && max > height){
        setTimeout(arguments.callee, time);
    }
})();

Малко допълнителна информация за arguments

Оказва се, че някои браузъри дефинират arguments само, когато е необходимо. Т.е. ако в тялото на фунцията не се използва никъде arguments, тя въобще не се дефинира.  Което спестява време и ускорява самия кода.  Тук има повече информация по този въпрос. Този факт е интересен и си мисля, че повече javascript интерпретатори ще използват подобен похват в бъдеще.

Доста често напоследък ми се налага да правя динамични страници изцяло задвижвани от javascript, като при тях постоянно се добавят и махат dom елементи. Което значи непрекъснато да се добавят и махат event хандлъри, което е меко казано досадно и води до много грешки. Но с вградените в CD3.Behaviors event delegation функции (за тях специално ще има поне един цял пост) тази работа е много лесна, просто делегирам всички действия към елементи които няма да се променят.

До тук всичко звучи много добре, но както винаги IE се появява на сцената с бъг, който е, че submit действието няма bubbling (т.е. не се делегира към родителските елементи на формата). Което е в пълен разрез със спецификация, но какво да се прави свикнали сме.

Този проблем го знам от много време и винаги го заобикалях по един или друг начин. Но наскоро на колега му трябваше бързо решение, което да може да ползва на 2 – 3 места затова за няколко минути написах това за Prototype.js:

Element.addMethods({
    delegateSubmit: function(element, callback){
        return $(element)
            .observe('click', function(e){
                if (e.findElement('form') && e.findElement('input[type=submit],input[type=image]'))
                    callback.call(this, e);
            })
            .observe('keyup', function(e){
                if (e.keyCode  == Event.KEY_RETURN && e.findElement('input') && e.findElement('form'))
                    callback.call(this, e);
            })
        }
});

Като цяло това, което прави тази функция е, че наблюдава за натискане на submit или image бутони или за натискане на enter върху някои input. Лошото в случая е, че страдат и нормалните браузъри като Firefox или Safari.

Затова направих нова версия, която засича дали submit се делегира (за начина, по който разбирам пише по-подробно в тази статия – Detecting event support without browser sniffing)

Element.addMethods({
    delegateSubmit: (function(){
        var el = document.createElement('div'), isSupported = 'onsubmit' in el;

        if (!isSupported){
            el.setAttribute('onsubmit', 'return;');
            isSupported = typeof el.onsubmit == 'function';
        }

        return isSupported ? function(element, callback){
            return Event.observe(element, 'submit', callback);
        } : function(element, callback){
            return $(element)
                .observe('click', function(e){
                    if (e.findElement('form') && e.findElement('input[type=submit],input[type=image]'))
                        callback.call(this, e);
                })
                .observe('keyup', function(e){
                    if (e.keyCode  == Event.KEY_RETURN && e.findElement('input') && e.findElement('form'))
                        callback.call(this, e);
                    })
        };
    })()
});

Това е доста по-добро решение което оправя проблема със submit само, когато има такъв проблем.

Тук бих могъл примерно да използвам Function.wrap върху Event.observe, но нещо не съм фен такива monkey patching неща. А и по-скоро това и хака за делегиране на focus/blur под IE ще са част от моята Event.delegate, която ако имам късмет ще е част от Prototype.js.

Ако някой има по-елегантно решение, няма да му се разсърдя ако го сподели.