I am terdelyi

Feltéve, hogy nem egy olyan cégnél dolgozunk ahová szupermeneket (vagyis PHP-hez, HTML-hez, Photoshophoz, Flash-hez, kreatívhoz, szövegíráshoz és csocsózáshoz egyszerre értő "szakemberek") vettek fel, mert akkor bizony továbbra sem leszünk igazán megbecsülve.

2009-ben meguntam, hogy szabadúszóként hónapról-hónapra élek és beadtam az önéletrajzomat néhány céghez. Ennek volt köszönhető, hogy 2 évet a reklámszakmához közel, a Greenroom webes csapatában tölthettem el, mint dedikált sitebuilder. Már akkoriban több műfaj érdekelt: túl voltam legalább három tucatnyi weboldal beindításán, webdesignerkedtem, HTML-ben és PHP-ban bűvészkedtem, mégis 26 évesen éreztem először szükségét annak, hogy elkezdjek szakosodni, mert kezdett minden egyre összeegyeztethetetlenebbé válni és ugyebár az ember sem érthet mindenhez egyformán, ugyanolyan jól. A HTML és CSS kódolást, azaz a sitebuilderséget a "menjen IE6-ban is" problémától eltekintve teljesen testhezálló iránynak véltem, hiszen akkoriban nem kellett hozzá más, mint totális tableless szemlélet, div-ek struktúrálása, szeletelésre alapozott Photoshop tudás, meg egy-két fontosabb böngésző bug ismerete, aztán jöhetett is a következő megbízás. Az, hogy végül valamilyen szinten megutáltam a sitebuildinget többnyire az ügynökségi, kapkodós munkamódinak is köszönhető, bár tegyük hozzá az ember napi 8 órában alkalmazottként sikeresen megtanulja maga előtt tologatni a feladatait.

A HTML5 és a CSS3 kampány abban az időben kezdett beindulni és bevallom őszintén nagyon nehezen barátkoztam meg velük, pedig imádom a technológiai újításokat. Eleve az a tény, hogy ezek a szabványok majd csak valamikor 2014 körül kerülnek véglegesítésre számomra azt a triviális végkövetkeztetést sugallta, hogy addig úgysem fogja őket senki sem használni. Az elmúlt egy év tökéletesen bizonyítja mekkorát tévedtem és mennyire rossz irányból közelítettem meg a dolgokat. Elsőre baromi béna hozzáállásnak tűnik, pedig igazából csak igyekeztem megúszni a változást, azt gondoltam, ha elodázom, úgysem fog megtörténni.

A félelmet többek között az adta, hogy a HTML5 gyökeresen átrendezi a HTML struktúráról korábban kialakított képet (lényegében hadat üzen a diveknek), míg a CSS3 a matematikát is igénylő transzformációkkal elindult a videókártyákkal közvetlen natív módban támogatott Flash animációk irányába. És ez csak a kezdet, van itt még bőven lehetőség: HTML5 cache, meg fájlkezelés, oldalbetöltési sebesség optimalizálása, optimalizáció régebbi böngészőkre (Modernizr), optimalizáció mobil eszközökre (responsive design, media query-k), reneszánszát élő fejlesztések Javascript frameworkökre (jQuery,Mootols, Prototype), amelyek közül egyre több kap már back-end fronton is hangsúlyosabb szerepet (backbone.js, node.js).

Az elmúlt néhány évben hatalmas mennyiségű, elsajátításra váró frontend technológia keletkezett, s habár azon vitatkozhatunk, hogy egy sitebuilder mennyire legyen front-end developer is, a két szakma erősen elkezdte fedni egymást - vagy ha úgy tetszik egyikből nőtt ki a másik. Aki idejében kapcsolt és töménytelen mennyiségű információt szívott magába minden irányból, tesztelgette, próbálgatta mit tudnak ezek a technológiák és kis szerencsével meg tudta  különböztetni a mellékvágányt az innovációtól, akkor ezeknek köszönhetően most kivételes képességek birtokában van. Kivételes és anyagilag a korábbinál sokkal inkább megbecsülendő képességek birtokában.

Ezért állok egy ideje tétlenül: belevágjak a változásba és lényegében újra megtanuljam a szakmát, vagy lépjek egy szintet feljebb a most távolibb rivaldafényben tündöklő back-end fejlesztések színpadán, ahol talán a Ruby on Rails felbukkanása óta kiemelkedőbb és meghatározóbb dolog nem nagyon történt (lásd PHP frameworkök megjelenése)?

Attól félek a választ számomra majd csak egy jelenleg szintén olvasás alatt álló, másik történet végkimenetele adja meg: "Alkalmazottak legyünk vagy vállalkozók".

Permalink | Leave a comment  »

Még mielőtt beleásnám magam a témába egy kis magyarázattal tartozom: akadnak pillanatok az életemben, amikor teljesen fölösleges, haszontalan, de számomra valamilyen okból fontos dolgokra keresek válaszokat. Valahogy így indult, hogy egységesítsem a kimenő emailjeim láblécét. Tudom-tudom, már nem annyira divat a grafikus (HTML) aláírás, most sokkal menőbb a minimalizmus. De: tegyük fel, hogy nekem tetszik, és esetleg mást is érdekel, hogy Mac-en a Mail alkalmazás alatt hogyan is fussunk neki.

Szóval, így nézett ki az eredeti aláírásom:

Tripleweb
Mobile: +36 (xx) xxx-xxxx
SKYPE: terdelyi
Web: http://www.tripleweb.hu
Twitter: http://www.twitter.com/wearetripleweb

Először készítettem belőle egy HTML változatot a logó embléma részével, ezzel együtt a "Tripleweb" szót is elhagytam. Az írott kódból természetesen le kell hagyni minden HTML, HEAD és BODY taget, mivel csak egy szimpla HTML blokkot gyártunk, nem egy komplett HTML dokumentumot, a levél alapértelmezett típusa pedig "plain text" helyett "rich text" legyen (Preferences > Composing > Message Format). Arra is figyeljünk, hogy bármilyen képet is linkelünk a kódban tegyük fel egy HTTP szerverre és arra hivatkozzunk, mert inline (csatolmány) módszerrel képeket platformfüggetlenül küldeni nem könnyű manapság és a legtöbb levelező kliens nem is szereti. Persze a Gmail és a Thunderbird meg fogja kérdezni, hogy letöltse a képet, de addig ott lehet az üres helyek kitöltésére való az "alt" attribútum.

(Tudom, már megkaptam a kritikát, hogy fordított Adidas, de a W betűt ábrázoló három vonal egyszerűen annyira találó szerintem, hogy amíg valaki nem dob be nekem az ablakon egy jobbat, maradok ennél.)

Aranyszabály, hogy emailben HTML-t úgy kódolunk, mintha 1998-ban járnánk: semmi div, semmi modern CSS, szorítkozzunk a jó öreg táblázatokra. A Campaign Monitornak van egyébként erről egy remek guide-ja (http://www.campaignmonitor.com/design-guidelines/), úgyhogy a részletektől most megkímélnék mindenkit.

Hogy hogy raktam be a Mailbe? Először is létrehoztam egy új aláírást (Preferences > Signatures). Mindegy mi van benne, csak írj bele valamit és mentsd el. Ezután nyissuk meg a "/Users/<Sajátuser>/Library/Mail/V2/Maildata/Signatures" könyvtárat és keressük meg az új aláírásunkat (a Library alapértelmezetten rejtve van, Forklift fájlkezelővel azonban ez könnyen áthídalható probléma). A fájl elnevezése lesz majd fontos nekünk a későbbiekben. Ezután nyissuk meg Safariban a HTML kódunkat és nyomjunk rá egy "Save as…" parancsot, majd mentsük el webarchive-ként. Ez készít egy .webarchive kiterjesztésű fájlt, amit másoljunk be a korábban megadott elérési úthoz, az aláírásokhoz. Az aláírás fájl nevét pontosan másoljuk, majd töröljük a fájlt és a frissen kapott webarchive fájlunkat beillesztés segítségével nevezzük át az aláírás fájlnevére. Ezután Command + Q-val lépjünk ki a Mailből, indítsuk újra és ellenőrizzük a "Preferences > Signatures" alatt az új HTML aláírásunkat. A képek nem fognak megjelenni, mert a nézőkéje nem képes kezelni a távoli képeket, de ez ne zavarjon meg minket. Hozzunk létre egy új levelet, amelyhez csatoljuk az aláírást és máris látni fogjuk a képünket.

Ezek után nyomtam egy-egy tesztet Gmailre, iPhone-ra és Mailre, meglepő módon mindegyiken más lett az eredmény. Rövid guglizás után kiderült, hogy a Gmail nem szereti, ha egy képet csak úgy bedobunk egy cellába, ilyenkor extra paddingot rak a szülő TD-be. Adjunk egy inline (magyarul: style="") "display:block;" tulajdonságot az IMG-nek és voialá. Akadtak itt még spacing gondjaim, ezért ügyeljünk rá, hogy a táblázatok megkapták a megfelelő paraméterezéseket és semmiféle extra paddingot nem tartalmaznak (cellpadding="0" cellspacing="0" border="0").

iPhone-on a betűk mérete volt ormótlanul nagy, kiderült ugyanis, hogy a Mail app szereti a pixelre fix méretű szövegeket saját maga irányítani. Erre való "-webkit-text-size-adjust:none;" tulajdonság, ami lényegében megtiltja a Mailnek és egyéb webkit alapú böngészőnek, hogy annak alapértelmezett szövegméretét vegye fel.

Apropó, ha már pixel: szintén trend, hogy emailben px vagy pt alapú betűméreteket használunk, itt most kivételesen felejtsük el a reszponzív weboldalakon örömmel használt százalékot vagy em-et.

Korábban a SKYPE beépített böngésző pluginjánál, de most már Gmailen és mobiltelefonokon is tapasztalom, hogy a telefonszámokat előszeretettel alakítják automatikusan "tel:" kezdetű linkekké, ami bosszantó lehet, ha az aláírásba nem terveztük default kékre linkelni a számunkat. Ennek kezelésére többféle megoldás létezik, nekem itt most az is elég volt, ha minden - vagyis dash karakter elé berakok egy entity-t, méghozzá a "&#173;"-t, ami voltaképpen az ún. soft hyphen (http://en.wikipedia.org/wiki/Soft_hyphen).

Ha már lúd, legyen kövér alapon elkészítettem a logót dupla akkora méretben is, majd megtartva a HTML kódban az eredeti "width" és "height" tulajdonságokat cseréltem a HTTP szerverre feltöltött verziót erre a nagyobbra, hogy a logó HiDPI kijelzőkön is tűéles maradjon.

A végleges HTML kód:

És most lehet tapsolni, akinek esetleg újat is mondtam.

Permalink | Leave a comment  »

Ez most egy kicsit rendhagyó blogposzt lesz, de kikívánkozott belőlem. Gondolom már mindenki hallott a hírről:

"Húsvéthétfőtől új macifigurák fogadják az esti mesék előtt a gyerekeket. Maci tévé címmel nemrég kibővült mesesáv indult az m2 csatornán, az ehhez készült új főcím a TV Macik fél évszázados hagyományába illeszkedik. (...) Az új főcím alkotói, Fischer Ferenc animátor és Berkes Gábor zeneszerző annyiban rugaszkodtak csak el a korábbi tradíciótól, hogy megújították a főcímzenét is, és az új változatban TV Maci már nem egyedül ül le esténként a képernyő elé."

Az első, ami megfogott, az a zenéje. Az ilyen gyenge szoftveres trombiták már a Gálvölgyi show-ban is cikik voltak, de 2012-ben igazi amatőrségre utal - a régóta pályán lévő Berkes Gábortól meg aztán főleg. Azt sem értem miért lenne megújítás az, ha beakasztjuk a fő dallam egy részét, de nem rakunk hozzá könnyen felismerhető másikat? Meg, ha már 2012, hol vannak a dubsteppes részek?

Ehhez képest miről szól a mostani? Maci hazajön a fociról, szép szőke csaja van, aki olyan debil, hogy kétszer is átszámolja megvan-e a három plüssbabája. Maci ezután beül a PC elé, de igazából maga se tudja mit csinál (a gép se nagyon működik), és Macilányról az állandó mosolygás miatt meg nem tudjuk eldöntetni, hogy akkor most azért simizi-e meg a párját, mert ilyen okos, vagy töke ki van már azzal, hogy állandóan a gépnél ül. Végül mindketten beülnek a plazmatévé elé (átlagos életszínvonal előrevetítés hurrá!), persze előtte Maci jól kikéri magának, hogy Macilány beültette a nyuszit a helyére. A mese után átteleportálnak a hálószobába és rajzolgatni kezdenek - aludni nem kell, a tv néző gyerekek is ráérnek addig, amíg ki nem száll belőlük a vacsora mellé bedobott kóla. A másik - egyébként valószerűbb - verzió, hogy Macilány voltaképpen Maci testvére, de lényegen ez sem változtat.

Az eredetinek volt egy finom bája a - magyar - televízió hőskorában, de ez így egy nagy nulla, és pontosan ezért szokatlan hozzá az eredetikből megtartott bábozás is. Mindenesetre már látom a következő generációt, amelyben Maci és a haverok Facebook eseményt nyitnak a Maci TV-nek, amit megtekintés előtt természetesen magnet linkkel letorrenteznek, miközben valahol a háttérben fedetlen, szőrös keblekkel a Macilány szoptatja újszülött kismaciját.

Permalink | Leave a comment  »

Pusztán jóindulattól vezérelve egy kicsit elemezném azt, hogy 2012. január 2-án az Index középre igazította magát - természetesen nem politikai, hanem webdesign szempontból. Az oldalt tartalmazó #page_wrapper div kapott egy margin:0 auto; CSS deklarációt, de ezzel együtt más, apróbb módosításokra is sor került. Azt most hagyjuk, hogy a legtöbb középre igazított, fehér hátterű weboldal - hogy a tartalom ne folyjon szét a háttéren - valamiféle keretet kap, legyen az a szó legszorosabb értelmében keret (border) vagy egy finom háttérszín (lásd a CNN vagy a The New York Times), mert ennek ellenkezőjére is van remek példa (pl. a BBC).

Az oldalakon észrevehető az is, hogy a szövegtest szélesebb a szokottnál (eddig a jobb oldalon két sidebar volt), de sajnos az itt megjelenített tartalmak továbbra sem konzekvensek. Eleve nem értettem a balra igazított korszakban miért kell margóig húzni a fotókat, miközben a paragrafusokat 34px-el beljebb kezdik, ráadásul ezt sem alkalmazták minden cikkben (most sem).

A jelenleg 640px-re nyújtott szöveg div ugyan kedvez a kirakható hirdetések méretének (mert ugye a méret a lényeg, véletlenül sem a hirdetés minősége vagy kreativitása), viszont nehezíti a szöveg olvashatóságát, az ún. readability-t. Optimális esetben 50-75 karakter vagy 12 szó megjelenítése javasolt a megfelelő olvasási élmény eléréshez, ami egy 14px betűméretű szöveg esetében nagyjából 500px-be fér bele. Az Index ezzel szemben jelenleg 15px-es betűmérettel dolgozik a 640px-es konténerben, hol behúzással, hol behúzás nélkül, ami átlag 90-95 karakter / sor és 10-14 szót jelent, tehát eléggé ki van centizve.

Ezek persze nem kőbe vésett szabályok, olvasó válogatja kit mi zavar, hány karakter után veszíti el a fókuszt a következő sorhoz és azt sem gondolom, hogy az Index dizájnerei mindezeket nem vették figyelembe.

Mindenesetre fontos, hogy mielőtt oldalt szélesítünk vagy tervezünk figyeljünk rá mennyire lesz olvasható a tartalmunk, vagy ha már egyszer elkészültünk vele, legyen bátorságunk felülbírálni döntéseinket és ha muszáj, fussunk neki újra. Az optimalizálás nem bűntetendő.

Permalink | Leave a comment  »

Kissé kezd brazil szappanoperai magaslatokba törni az EllisLab (http://www.ellislab.com/) kommunikációja és az azokra érkező reakciók a felhasználói közösség részéről, úgyhogy itt az ideje tiszta vizet önteni a pohárba, vagy legalábbis összefoglalni mi az, ami jelenleg zajlik a CodeIgniter háza táján.

Az egész mizéria – vagy ha találóbban akarjuk kifejezni paranoia – ott kezdődött, amikor Derek Jones, a CI-t létrehozó EllisLab chief technology officere  a projekt hivatalos oldalán megjelentette rövid szösszenetét, „What’s Happening Now?” (http://codeigniter.com/news/whats_happening_now/) címen. A bejegyzésben többek között az új verziókövetőre való átállást (BitBucket) dícsérte, felhozott néhány másik publikációt az Expression Engine kapcsán, melyekben a CI-t emlegették, majd megosztott velünk néhány dolgot:

•  Továbbra is dedikált szoftverfejlesztő munkatársat keresnek, aki a CI fejlesztését egyengetné, de hosszú hónapok elteltével is még mindig csak az interjúszakaszban tartanak.
• Változtattak fejlesztési módszereiken,  ami minden bizonnyal elő fogja segíteni a CI 2.0 fejlődését.
• Dolgoznak egy rövid összefoglalón, ami majd meghatározza a CI jövőjét és irányát.
• Szeretnék még jobban összefogni a közösséget, de nem találtak még rá megfelelő vezetőt, ezért új módszerek után néznek.
• Imádják a Mercurialt (hurrá).

A fentiekből hamar kisillabizálható, hogy az utoljára 2009. február 10-én új verziószámmal frissült CI-ről (vagyis az 1.7.1-esről, mivel a 2010 júliusában kiadott 1.7.2 mindössze security patch volt) ezúttal sem tudtunk meg semmi újat, ellentétben az EllisLab működéséről. A 2006-ben megjelent 1.5-ös verzióhoz képest négy év alatt mindössze 2.2 pontot ugrottunk előre.  Innen nézve a verzióugrások jelenlegi állapota teljesen elfogadható mértékű lenne, ha ugyanennyi idő alatt a semmiből teremtett konkurens frameworkök nem duzzadtak volna fel a CI alapképességeit jelentősen meghaladó rendszerekké.

Azt azonban fontosnak tartom megjegyezni, hogy a CI alapjában véve már most is egy szinte hibátlan, jól átgondolt, remek rendszer, amelyet akkor is bátran használhatunk majd, ha esetleg a következő hónapokban lefagyna körülötte a levegő – hiszen ez tettük az elmúlt négy évben is. Az MVC felépítésnek köszönhetően végletekig horgolhatjuk a core-t, fejleszthetjük  alapképességeit vagy készíthetünk korlátlan mennyiségű libraryt, melyek működésének csak saját képzeletünk és persze szaktudásunk szabhat határt. A CI egy megfelelő alap, amire bármikor építkezhetünk, attól függetlenül, hogy továbbfejlesztik-e vagy sem. Mindazonáltal a CI a PHP-ból és adatbázis nyelvekből (mint pl. a MySQL) építkezik, amelyeket viszont hétről-hétre frissítenek, okosítanak, optimalizálnak, így ha az új technológiák és megoldások nem kerülnek adaptálásra a CI előbb-utóbb elavultá válik és akkor jönnek majd a bajok. Ez a kinduló problémája a CI-közösség jelenlegi zúgolódásának, és két részre osztja a társaságot: azokra, akik hisznek a CI jövőjében, de nem értik miért nem halad a fejlesztés előre, illetve vannak azok, akik szeretik a CI-t, de már érzik a vesztét és elkezdtek kikacsingatni egy másik framework felé (pl. a YII vagy a CakePHP). Márpedig egy projekt szempontjából rendkívül fontos a megfelelő fejlesztői környezet kiválasztása, nehogy néhány hónap vagy netán év múlva kellemetlen pillanatokat okozzon nekünk egy-egy lejárt rendszer javítása.

Visszatérve a cikkre, néhány hónappal annak megjelenése előtt először Derek Allard (http://derekallard.com/blog/post/new-challenges/), majd Dan Horrigan (http://dhorrigan.com/blog/article/i-am-no-longer-with-ellislab) közölte blogján, hogy elhagyja az EllisLabot és új kihívások után néz. Többek között ez és Jones írása adta az alapot bizonyos Phil Strugeonnak, a CI-alapú PyroCMS (http://pyrocms.com/) fejlesztőjének az ihletet, hogy billentyűzetet ragadjon és blogba mondja „What happens next?” (http://philsturgeon.co.uk/news/2010/10/what-happens-next) című összegzését. Az angol fejlesztő ebben nagyjából teljes erővel nekimegy az EllisLabnak és kritizálja annak saját gyermekéhez  való hozzáállását. Jogosan kéri számon a már hosszú ideje ígérgetett CI 2.0-t, mely szerinte egy ideje elég stabil ahhoz, hogy végre hivatalosan is megjelenhessen, mi több már rég a 2.1-es változatot releaselhetné a cég, ha nem termékei, az Expression Engine és az új MojoMotor fejlesztésével lett volna ennyire elfoglalva. Phil a két említett oszlopos fejlesztő kilépésével egyenesen a CI halálát vizionálja. A beérkező hozzászólások között aztán feltűnt Derek Jones, aki természetesen csapata védelmére kelt, külön kiemelve, hogy felesleges hasonlítgatni a CI-t más, túlhízott rendszerekhez, mikor az alap filozófia az volt, hogy a CI könnyen kiismerhető, gyors, méretében kicsi, és komplexitása ellenére mégis egyszerű framework legyen. Ezen kívül figyelmeztetett arra a kevésbé elhanyagolható tényre, hogy az EllisLab dollárszázezreket költött a CI fejlesztésre, mégis ingyen kínálta fel a fejlesztői közösségnek. Ezt később Leslie Camacho, az EllisLab elnöke hivatalos twitterén is megírta: „Ez egy ajándék, amelyet ingyen adunk mindenféle elvárás nélkül”.

És itt még nincs vége. Másnap egy másik fejlesztő, Zack Kitzmiller „What just happened?” (http://zackisamazing.tumblr.com/post/1423508218/what-just-happened) címmel kisebb összefoglalót közölt Tumblr blogján az elmúlt két nap bejegyzésháborújáról, és külön kiemelte Jones kissé aggresszívnak tűnő kommentjeit Phil bejegyzésénél. Kitzmiller szerint a baj leginkább abban keresendő, hogy az EllisLabs egy nyílt forráskódú rendszert épített, de nem hallgat a közösségre, nem tölt be hatékony irányító szerepet. A fórumok tele vannak kérésekkel és ötletekkel, számos hasznos és remek library, illetve helper készült, de azokat mégsem építik be a core-ba, egyszóval az egésznek semmi köze más, nyílt forráskodú rendszereknél megszokott fejlesztési folyamatokhoz.

Kitzmiller bejegyzését később Leslie Camacho hosszabban kifejtett véleményével (http://salvator.me/site/pub/codeigniter_0_100) bővítette. Értelmezése szerint Camacho blogbejegyzésében színt vallott, és végre beismerte, hogy kizárólag anyagi okokból lehet a CI  a mai napig életben. Camacho szerint a CI előtt jelenleg két út áll: közvetlen bevételt kell termelnie vagy találniuk kell egy elfogadható középutat a közösséggel. Ez akár azt is jelentheti, hogy minimális összeggel, de szálljunk be a CI fejlesztésébe – Kitzmiller ezért is kapta fel a vizet. A végén párhuzamot vont a Rails és a CI között, miszerint mindkettő egy eszköz, amire épít a közösség, amit épít a közösség, akkor miért ne fejleszthetnénk együtt? Kitzmiller szerint az EllisLab egyszerűen fél a fejlesztőktől és nem bízik meg bennük annyira, hogy a kezükbe adja az irányítást.

Egy héttel ezelőtt aztán megindult valami. Bár hivatalos megjelenési dátum továbbra sincs, az EllisLab megerősített több, korábban nyilvánosságra került 2.0-ás infót (http://codeigniter.com/news/codeigniter_2.0_-_now_with_more_awesome/):

• elfelejthetjük a PHP 4 támogatást, a minimális követelmény az 5.1.6 lesz
• változik néhány fájlelnevezési szabály
• a modellek tisztábbak lesznek
• az Email és Validation library-k is láncolhatók lesznek

Mindez azonban kizárólag a hivatalos forrásokra támaszkodó fejlesztőknek lehetett újdonság, a többiek már rég tisztában vannak a változásokkal (többek között Philnek hála: http://philsturgeon.co.uk/news/2010/03/codeigniter-2), mi több, hónapok óta a Bitbucket-ről letölthető 2.0-át használják.

Tegnap a CI weboldalán megjelent egy felhívás, melyben 6 kivételes tehetségű CI fejlesztőt keresnek, akik kiemelt vezetőkként – ha jól értelmezem afféle moderátorként - vinnék tovább a rendszer fejlesztését. Hogy anyagi vonzattal vagy a közösség érdekében, arról nem szól a fáma.

Persze az is lehet, hogy az EllisLab már teljesen elvesztette a kontrollt a CI kommunikációja felett (ez remekül látszik a hírhez fűzött frissítésnél, mely szerint a közösség egy része igencsak félreértette az EllisLab szándékait a csapattoborzással). Mivel a hatfős csapat egyik fő feladata a 2011 első negyedévének megtervezése, mindössze néhány hónap múlva meglátjuk.

Permalink | Leave a comment  »