My worst nightmare is :

Hi, everyone.

This is my first blog article on English, because i think it is a common problem and i hope it will make sense.

Sometimes i get frighten out, because people around me are full of doubt, and than i get pissed of why this is my concern.

Usually I’m surrounded with creative peoples, most of them are right brainers and they used to express their self and their attitude with feeling’s, and sometimes those feelings seems to be dark.

My greatest barrier to keep doing the stable work is when my team gets demotivated, and so do I, and this is a big problem or a great attribute of mine.

As i saw a documentary last week, about Steve Job’s way of living, i understood that Stevo used to squeeze the juice of peoples he thought will get the job done.

If you had something that Stevo could use to improve a product or get money, he would become your best friend.

But all this Stevo story is the opposite of mine.

I used to get closer to the peoples who are on tight moment’s, and somehow i get to impact their feeling on me.

What Stevo did wrong, is I think he was not a Team Player, a great Team Player hook’s up all it’s team members not only those which is like easier to get to the point.

And while being somehow ambitious, I think you can’t serve the World if you did not served your Team first.

And remember

“And as we let our own light shine, we unconsciously give other people permission to do the same”

Marianne Williamson

Stafi – “Vegel” apo “Aset”

Para disa muajve duke bisedu me 1 mik timin, per problemet ne maredhenjen ne pune me tha qe : “Puntori nuk osht vegel, osht aset”.

Un u pajtova edhe pajtohem me ket definicion, tu e mar parasysh se pa staf (sidomos teknik), menagjmenti nuk kish pas me qka me u mare, dhe ish zhduke nevoja per te.

Shumica e kompanive ne Prishtine marin pagesa ne suaza mujore, dhe siq po duket mision i seciles eshte me pas nje “Cash Flow” ma stabil, e per disa me qen i hekurt.

Problemet me te medha po ndodhin kur ne nje prej muajve te ardhurat po rriten (dyfishohen,trefishohen), po ndodhe diqka qe nuk ka ndodhe gjate muajve tjere, dhe kjo po krijon stres te menagjmenti ku ata po behen paranojak dhe po mundohen qe muajin tjeter te vazhdojne me ket ritem.

Kjo po ndikon qe masat per disipline me u rrite, me u egzagjeru.

Pauzat per duhanpiresit shendrrohen ne gjendje kritike.

Problemi po qendron te egzagjerimi i sjelljeve te menagjmentit per mbajtjen e punes stabile qe nga muaji ku kompania ka pesu ndryshim drastik ne pranimin e te ardhurave, perderisa te stafi kjo shkakton nje ndjenje frike edhe mosbesimi, puntoret veq se po fillojne me mendu qe ka me pas sanskionime, kan me dyshu ne aftesite e tyre dhe pergjegjsia e menagjmentit ne keto kushte po zbarkohet te te gjithe puntoret duke kriju bindje te rrepta per menagjmentin.

Un mendoj qe puntori nuk osht “çekiq“.

Dizajneri grafik dhe front-endi

Na ishte nje her nje dizajner qe deshironte te behej programer, por pas disa tentiemeve e kuptoj qe nuk po munet me i kry te dyjat mas miri n`bote.

Nje kriter qe osht shfaqe qe thote se nje Web Designer duhet te ket njohuri edhe ne Front-end Development ku dizajnin duhet me e shfaq drejt ne Browser e jo ne ndonje editor visual nuk eshte edhe aq praktik.

Problemi me i madh qendron te perzierja e kreativitetit dhe perballja me zgjidhjen e problemeve ne implementim.

Nese Web Dizajni e mer nje kahje dhe krijon nje standard strikt ne View at-her kjo ndodh per shkak te dizajnerave teknik.

Zakonisht nje Dizajner Grafik vjen me 1 eksperience ku Veglat qe i ka perdor me punu i ka te gjitha ne nje Editor Vizual, por kur vjen nevoja me shkrujte Markup(HTML) ose CSS perballet me diqka qe nuk ka hase ma heret dhe i mungon logjika se si funksionon ajo dhe fillon gjithmon te perdor Snippets te gatshem pa e kuptu mire se qysh funksionojne ato.

Mundet me u thane qe nje dizajner grafik ka aftesi te mesoj se si ndertohet nje Objekt qe aj ka per qellim, po pse eshte ardhe deri te rezultati duhet te kaloj nje kohe e gjate sepse i duhet njohuri ne te gjitha shtresat ku kalon ajo cope e Kodit qe aj e ka konstruktuar.

Pra tu i mar per baze krejt kto qka i thash nje dizajner grafik nese e ben edhe punen e Front-end ne dizajnin e tije aj ka me reduktu shum elemente sepse eshte ai vet qe ka me u perball me to, dhe kjo mundet me rezultu ne Dizajn te manget.

Ne tjetrin aspekt kreativiteti vjen nga pjesa e djathte e trurit, perderisa realizimi i saj duhet me u bo duke e perdor pjesen e majte te trurit dhe te jet sa ma shum logjike dhe zgjidhje optimale.

Nje problem tjeter mundet me qene kur dikush tjeter e perdor ate Markup per Javascript ose PHP.Ka raste kur kom pranu Markup qe ka pas

<h1>TItulli i <span>kuq</span></h1>

Me Elementin me larte nese me jQuery tenton me manipulu : $(“h1″).text() ka me e largu <span> elementin ose nese i thu  $(“h1″).html() ki me u detyru me gjet nje menyre qysh me e rujt <span> pa e ndryshu.

“Jack of all trades master of none”

Tu e pas parasysh kete thenje kompanite e medha qe ofrojne sherbime ne WEB punesojne Front-end Engineers.

Nje interviste per nje front-end punues.

 

Permbajtje ma e mire ne “Portale”

Un nuk lexoj gazeta ose portale shpesh, po shpesh i nije njerzt tu u anku per permbajtjen e dobet neper to.

Ankohen per gabime gjuhsore, per permbajtje jo kualitative etj etj..

Nese nuk gaboj per ket pune eshte Redaktori, ai ben “Review” qdo lajm para se me u publiku,po po m`doket nuk osht tu e kry punen mire.

Dje tu bisedu me koleget e mi ne “Umbrella“, erdhem deri te 1 ide qe nashta kish funksionu.

Gazetareve sidomos neper portale, ju kish dashte 1 sfide ma e madhe edhe pse jo nashta me e rrite perfitimin prej shkrimeve te tyne.

Ket problem kishte me e ndihmu me u zgjidh 1 sistem qe ka ma shume Challenge deri ne publikim te lajmit.

Ideja osht qe qdo Gazetar me u pagu per qdo lajme, jo pagese flat, po per qdo lajme qe gazetari publikon me qen nje Reviewer qe e vlerson Lajmin.

Nese Reviewer permirson 30 % te lajmit, at-her 30 % te pageses per qat lajm e mer Reviewer.

Kjo po i bjen qe Reviewer duhet me konkuru me Gazetarin edhe me u pagu 2 palet proporcionalisht.

“Qka nese t`shkel kerri”

Para 1 kohe tu i tregu 1 djalit ma t`ri se un per Ambicjet e mija, i pengova m`doket edhe u kthy m`tha “Po pse po merzitesh qaq shum per pune,neser del t`shkel kerri edhe ski qka tregon”.

Per qdo hap qe e marim, qofte ajo edhe kur del me ble buke, gjithmon osht 1 risk a nashta ma shume se 1, munet mu shtrajtu buka e ti mos me pas pare me veti, munet me qellu buka bajat, munet me tu qky kesja edhe me t`ra buka rruges etj etj.

Po risku nuk bon me t`pengu nese veq ki shanca minimale me mrri deri te qellimi.

Shohim qdo dite njerz te profileve te ndryshme, qe rrezikojne profesionit/zanatit me u zhduke nevoja per to, po nuk nalen vazhdojne me u profilizu edhe ma thelle e me vazhdu me u zgjonu.

Sot ka profesione qe nuk kan egzistu para 30 vjetve, e ka me pas ne te ardhmen qe nuk i njohim sod.

Po nese vazhdojme me u tut “Nese na shkel kerri”, nuk kemi arsye me vazhdu edhe me eksploru e me u zgjanu ne fusha te reja ose me i permirsu kushtet qe i kemi sod.

“Our deepest fear is not that we are inadequate. Our deepest fear is that we are powerful beyond measure. It is our light, not our darkness that most frightens us.’ We ask ourselves, Who am I to be brilliant, gorgeous, talented, and fabulous? Actually, who are you not to be? You are a child of God. Your playing small does not serve the world. There’s nothing enlightened about shrinking so that other people won’t feel insecure around you. We are all meant to shine, as children do. We were born to make manifest the glory of God that is within us. It’s not just in some of us; it’s in everyone. And as we let our own light shine, we unconsciously give others permission to do the same. As we are liberated from our own fear, our presence automatically liberates others.” Marianne Williamson

 

 

Nje Framework qe te mundeson Ajax Site

Para nje kohe me interesojke se si Facebook mundet me navigu neper faqe tjera pa e Ri Renderu Chat Box-in.

Dhe duke inspektu ne Firebug u vrejke qe eshte tu bo vetem Ajax Request, dhe HTML-in perveq Chat Box-it eshte tu e insertu vetem me Java Script.

Kjo mnyre e Navimit besoj qe ka me gjet perdorin tek App. dhe Sajtat qe deshirojne nje pjes te tij me e mbajte gjat gjithe Kohe’s ne nje gjendje pa varesisht se kah Navigon Useri.

Scripten mund ta merni ketu.

Qe sajti te behet load vetem me Ajax duhet qe skripten ta integroni ne te gjitha Page-t.

<script src=’ajax_site.js’></script>

Permbajtja qe deshirone te ndryshohet me Ajax duhet ta futni ne.

<div id=”ajax_container”></div>

Kurse ate qe deshironi ta mbani te pa ndryshushme e leni jashte.

<div id=”ajax_container”></div><div>Permbajtje e Pandryshushme</div>

Per ket Framework duhet te integrohet edhe jQuery poashtu.

PS: Nese gjeni ndonje Bug ose deshironi te kontriboni shkruani koment !

Javascript Mutation Events

Duke e shkrujt nje plugin ne jQuery mu dashke nje menyre se qysh me e dite kur shtohet nje Element i ri (DOM Element ose Node) ne nje Element tjeter.

Kjo mu dashke se dojsha me e rujte funksionin edhe per elementet qe shtohen pasi dokumenti eshte Load nga Browser-i.

Diqka e ngjashme me funksionin .live() ne jQuery.

Nje zgjidhje e mire ne ket rast po jo e shkelqyer eshte Javascript Mutation Events (sepse nuk perkrahen ne te gjithe Browser’s).

Mutation Event’s mundesojne qe te egzekutohet nje funksion nese nje DOM Element Modifikohet, pra nese nje element i shtohet nje element tjeter, nese i ndrrohet ndonje atribut, nese i shtohet ndonje atribut etj.

Lista e ketyre Event’s eshte kjo :

• DOMAttrModified
• DOMAttributeNameChanged
• DOMCharacterDataModified
• DOMElementNameChanged
• DOMNodeInserted
• DOMNodeInsertedIntoDocument
• DOMNodeRemoved
• DOMNodeRemovedFromDocument
• DOMSubtreeModified

Per me e shtu nje event ne ndonje DOM Element ne RAW JS mundet kshtu

element.addEventListener("DOMNodeInserted", function (ev) {
          //Ndonje Funksion
}, false);

Kurse ne jQuery 

//Atach Event to Element to catch a new element insertion
$("#container").bind("DOMNodeInserted", function (ev) {
    alert("New Element Added");
    //Maybe insert something at Database using Ajax
});

Dhe me poshte keni nje shembull ne jsFiddle .

Egziston edhe nje jQuery plugin qe te mundeson me i Nxone (catch) ndryshimet vizuale kryesisht te nje DOM Elementi ne Run Time, ai quhet jQuery Mutate Plugin dhe mundet me i monitoru keto ndryshime :

• width
• height
• top
• right
• left
• bottom
• hide
• show
• scrollHeight
• scrollWidth
• scrollTop
• scrollLeft

Nje problem me Taxonomies në WordPress

Duke punuar ne nje Site per nje klient ku kishte mbi 10 Custom Post Types vrejta diqka te quditshme.

Ishin 2 Post Type’s qe permbajshin Custom Taxonomies te pa varura nga Deffault Taxonomy qe quhet Categories dhe eshte pjes e Post-it te zakonshem ne WordPress.

Ne njeren prej Cusom Taxonomy kishte disa lloje te Term’s dhe njera prej tyre quhej “About” qe slug kishte “about” .

Dhe duke u bazuar ne ket Term, un i vendosa disa Custom Field’s te te gjithe postet qe e kan ket Term, pra te gjithe postet e Kategorise About.

Po duke e zhvillu faqen, mu dasht qe ne nje tjeter Custom Taxonomy qe ishte e pavarur prej Taxonomy paraprake, mu desht nje term me emrin e njejt “About”.

Kjo ndikoj qe postet e Taxonomy paraprake te mos shfaqen Custom Field’s po te shfaqen vetem te kjo e fundit qe e krijova.

Pastaj e vrejta qe nese krijoni Term’s qe kan emer te njejte WordPress nuk i krijon ato, po vetem e mban referencen e tyre neper te gjithe Post Type’s.

Pra keni kujdes nese logjika ose query i posteve varet ne emrin e nje Term, mund te shfaqen edhe poste qe nuk e keni pase plan me i shfaqe.

Zgjidhja e ksaj deri tash eshte, e krijon nje term me emer te quditshem, dhe pastaj kthehesh dhe e Editon, vetem pasi te sigurohesh qe WordPress ka krijuar Term te ri dhe ID-ja e tije ndryshon prej qdo Term tjeter ne qdo Taxonomy me emer te njejte.

Stili jo i mire i nje procesi softuerik ne Kosove

Deri tash jon 2 stile te nje procesi softuerik ne Kosove qe perdoren zakonisht.

Stili i pare osht, vjen nje kerkes dhe menagjmenti e mledh ekipen e zhvilluesve edhe jau transmeton kerkesen ku secili mundohet me e gjet veten edhe me e kry qat pjes qe ata mendojne qe e bejne mire dhe shpejte.

Kjo osht keq se disa pjes ose kerkesa mundet mos me u mbulu sepse tashme secili nga ekipa veq e ka zgjedh qat cope qe po don me e programu.

Probleme mundet me pas edhe te pergjegjesia, perderisa puna eshte nda paralelisht te gjithe kan pergjegjesi te barabarta, e n`ket rast nuk mundesh me lyp pergjegjsi prej krejt ekipes per nje pjes se nuk ka nevoj krejt ekipi me punu ne at pjes.

Kjo qe po e thom nuk mendohet me fuksionu kshtu, sepse shumica e coptojne ekipin ne hierarki tu ju vnu pozita (Head of diqka) po apet rrjedhshmeria eshte kjo.

Stili i dyte eshte kompanite qe kan staff te vogel dhe marin me shume se 1 projekt ne te njejten kohe.

Nje projekt i caktohet vetem nje zhvilluesi, ai eshte pergjegjes (nese ai projekt eshte web) per CSS, HTML, jQuery, PHP, Server, DataBaze, Stabilitet, Testing etj.

Ne keto faza nese vetem nje person eshte duke punuar shum elemente neglizhohen lehte sepse bindja qe krijohet gjat punes ne Code fiton, perderisa ne Run Time softueri mundet me pas probleme.

Stili me i mire eshte me e pas 1 ekip te zhvilluesve dhe me pas te pakten 1 Softuer Arkitekt dhe nje Softuer Inzhinier.

Keta te 2 mund ta projektojne nje proces softuerik dhe jane te zote qe kerkesat ti pranojne nga klientet dhe ti transferojne te zhvilluesit ne menyren me te mire ti mundshme pa harru me cek asgje.

Pse nuk duhet te ruhet logjika ne Event Handler

Shpesh ne review’s ose ne ndonje sugjerim nga ndonje komunitet online sugjerohet strikt qe te mos shkruhet Logjika qe kryen nje rutine ne Handler te Eventit.

Nje shembull pse mund te shkaktoj problem te madh.

$(document).mousewheel(function(event, delta, deltaX, deltaY) {
//Some Code Logic
//Update Panels
//Fire other Events
});

Snipeti me larte tregon se eshte perdor Mouse Wheel jQuery plugin, dhe brenda Parametrin Function qe pranon ky plugin eshte shkruajte (improvizuar ne ket rast) nje Logjik per manipulimin e UI.

Dhe ne ket rast ky snipet funksionon.

Problemi qe mundet me linde eshte kerkesa qe ket event ta bejme Trigger ne ndonje Event tjeter, psh ne nje Button Click.

Edhe per ket problem eshte nje zgjidhje, jQuery ofron .trigger() funksionin qe te mundeson, me Fire Event’s externally.

function fireMouseWheel()
{
$(document).trigger(“mousewheel”, 1,1,1);
}

Shembull nga jsFiddle

Problemi me i madh eshte nese ndryshon menyra egzekutimit te kodit, ne ket rast per ndonje arsye eshte vendos te mos perdoret jQuery Mouse Wheel por te perdoret nje native MouseWheel Event Listener.

At-her programeri eshte i detyruar qe te ndryshoj menyren se si eshte trigger MouseWheel neper secilin rresht ku eshte perdor.

Zgjidhja me e mire ne ket rast kishte me qen qe Rutinat dhe Logjiken e Aplikacionit ta ruajm ne Funksione te veqanta dhe ato Funksione ti egzekutojme aty ky kemi nevoj.

$(document).mousewheel(function(event, delta, deltaX, deltaY) {
//Some_Code_Logic() – Funsion
//Update_Panels() - Funsion
//Fire_other_Events() - Funsion
});