Vida Balázs blog

Az alábbi módon lehet távoli swf-et beágyazáskor maszkolni. A hangsúly a sorrenden van. Másként nem maszkol.

import flash.display.*;
import flash.net.URLRequest;
var rect:Shape = new Shape();
rect.graphics.beginFill(0xFFFFFF);
rect.graphics.drawRect(0, 0, 100, 100);
rect.graphics.endFill();
addChild(rect);
var ldr:Loader = new Loader();
ldr.mask = rect;
var url:String = “http://www.untrusted.example.com/content.swf”;
var urlReq:URLRequest = new URLRequest(url);
ldr.load(urlReq);
addChild(ldr);

Macports nem teszi fel, de a leszedett forrást sem lehet lefordítani hiba nélkül, de szerencsére csak a Makefile hibás. Megoldás szedd le a 2.2b forrását innen:

svn export svn://svn.mplayerhq.hu/rtmpdump/tags/rel-2.2b

A Makefile-t módosítsd az alábbi diff szerint:

23a24,25
> LDFLAGS=-L/opt/local/lib/
>
33c35
< posix linux unix osx:
—-
> posix linux unix:
44a47,49
> osx:
>     @$(MAKE) INC=-I/opt/local/include $(MAKEFLAGS) progs
>

Fordítsd le (libz openssl és kitudja mi kell hozzá macportsból):

make osx

Végül másold a binárisokat az /opt/local/bin könyvtárba.

Flexben komponensen belül ez a kód nem bindolódik:
<mx:Repeater dataProvider=”{parentApplication.remarks}” >

Helyette saját bindable attribútumot kell definiálni és kívülről hívni:
<mx:Repeater dataProvider=”{remarks}” >

Egyrészről itt van eclipse használat lépésről lépésre (alábbi link). Másrészről az oldal alján pedig, hogy mit csinálj ha nincs eclipse-ed.

http://developer.android.com/resources/tutorials/hello-world.html

Én azzal kezdtem, miután leszedtem és kicsomagoltam az sdk-t, hogy beállítottam a PATH változóba az sdk tools könyvtárát, hogy könnyebb legyen parancsokat hivogatni.

megcsinálod a virutális device-ot:
android create avd —target 1 —name my_avd

Aztán a lap alján lévő paranccsal létrehozod a projekt könyvtárat:
android create project —package hu.vidabalazs.helloandroid —activity HelloAndroid —target 1 —path ./HelloAndroid

Debug mode-ban kell buildelni, mert:
“Debug mode simply allows you to run your application without manually signing the application.”
forrás a másik hasznos oldal: http://developer.android.com/guide/developing/other-ide.html

Így sign-olni nem kell semmit.
parancs: ant debug

Én USB-n csatalkoztattam a telót. ekkor így tudod telepíteni a lefordult cuccot:
ant install

Ha változtatsz a kódon és újrafordítottad nem tudod telepíteni amíg az előző fent van, leszedni így lehet:

adb uninstall hu.vidabalazs.helloandroid

az uninstall után a package name-et kell megadni, nem a projekt nevét!

Van ant uninstall is, de az nem szedi le az appot.
Ha a leírtak után is van kérdésed akkor hívj bátran!

Még annyit hogy az ant hasonló cucc, mint a make (Makefile) vagyis sok parancsot, tennivalót lehet egy-egy kulcsszó alá rendezni és okosan futtatni. Java világban azt használják, nem a make-et.
http://ant.apache.org/

Nem jó irány, hogy gemek saját generátort adnak ki a rails standard generátorai helyett, mint például az rspec_controller.

Most választanom kell, hogy vagy rspec, vagy facebooker által generálok kontrollert. Szeretném mind a kettőt egyszerre.

Sok 10 évvel ezelőtt, amikor bekötötték a vezetékes vizet úgy döntöttek elődeink, hogy a kútra már nem lesz szükség. Az akkori átalakítások törmelékét drága lett volna elszállíttatni, ezért feltöltötték vele a feleslegessé vált kútat, végül a terasz 30 centis betonrétegével elfedték. Manapság könnyen lehülyéznénk aki ilyet csinál. Annak idején ez racionális döntésnek tűnt, mint az is, hogy a betont csak habarcsnak használták és mészkővel töltötték fel a teraszt. Ma a mészkövet drágán vesszük a sziklakerthez.

Generációnként változik, hogy mi drága, mi olcsó.

Hallgassatok bele (alul) a francia Bercsényi huszárezred indulójába!
Ez az ejtőernyős alakulat Rákóczi szabadságharc után Franciaországba menekült gróf Bercsényi László által alapított Bercsényi huszárok utódainak tekintik magukat.

A szöveg francia fonetikusban:
Prononciation du chant

Dienne guienne vi o la nac
Les teureutes en za gane
Azene ba na tom nac
Nitch vigas ta la chan

Refrain (bis)
Chou o kasell
Kechmar failette
Eteche ro jame
Ich tene vilaide

Nad nercheny mi cloche
Chir do galma gaban
El fodiote se gue gnec
Mi decato nayane

Refrain (bis)
Chou o kasell
Kechmar failette
Eteche ro jame
Ich tene vilaide


Magyarban:
Bercheny hongrois

GYENGE VIOLANAK
LETOROTT AZ AGA
AZ EN BANATOMNAK
NIMCS VIGASZTALASA

Refre`n
SUHOG A SZEL
KESMARK FELETT
EDES ROZSAM
ISTEN VELED

NAGY BERCSENYI MICKLOS
SIRDOGAL MAGABAN
ELFOGYOTT SZEGENYNEK
MINDEN KATONAJA

Refre`n
SUHOG A SZEL
KESMARK FELETT
EDES HAZAM
ISTEN VELED

És itt lehet meghallgatni:

http://www.rhp1.terre.defense.gouv.fr/Chants/chant_rgt_hongrois.mp3

Az ezred honlapjáról:
http://www.rhp1.terre.defense.gouv.fr/m1_H_chant_rgt.html

Csuda dolgok vannak a világban!

Korábban már írtam a Scrum-ról. Most találtam ezt a részletesebb leírásomat a témában.

A scrum-ot elsősorban szoftverfejlesztéshez találták ki, de persze máshol is alkalmazható. Azért terjed, mert kezelni tudja a menet közben érkező ügyfél oldali változtatásokat. 1-2 hónapos ciklusokból épül fel a menetrend. A ciklusok elején egy sima listába felírjuk az ügyféllel közösen, hogy mit szeretne/énk elérni a ciklus végére. A listát addig rágjuk, amíg mindkét oldal megérti és ugyan azt érti az egyes feladatok alatt. A feladatokhoz prioritást rendel az ügyfél. Ekkor még csak azt tudjuk tehát, hogy mik a feladatok és az ügyfélnek melyik milyen fontos. Ezután leülünk a fejlesztőkkel és átbeszéljük, hogy melyik feladat milyen konkrét tennivalókra bontható, és melyik tennivaló mennyi órát vesz igénybe. Így kijön, hogy a ciklus végére mennyi feladattal tudunk végezni. Ezzel az infóval visszamegyünk az ügyfélhez és meggyőzzük róla, hogy a listája alján lévő dolgokat ebben a ciklusban nem fogjuk tudni megcsinálni. Ekkor ezt elfogadja, vagy kicsit átpriorizálja, de a lényeg, hogy ennek a megbeszélésnek a végén befagyasztjuk a feladatlistát. Az ügyfél szinte végig jelen van a ciklus tervezésnél, és majdnem minden ponton beleszólhat. Ezzel zárul a tervezés, és megkezdődnek a ciklus hétköznapjai.

A fejlesztők által összeállított tennivalók akkorára vannak szabva, hogy egy embernek kb. 1, max 2 napját tegye ki. A ciklus közbenső napjain mondjuk reggel átbeszéljük az előző napot, ki hol tart, és mit szeretne a tennivalók közül ma megcsinálni. Mindenki kérhet neki tetsző feladatot. Frissítjük a táblázatban, hogy mennyi feladat van hátra, így minden nap pontos képünk van arról, hogy hány órányi munka marad a ciklus végéig.

Ciklus hétköznapjai alatt a feladatlista nem változhat! Se mi, se az ügyfél nem változtathatja meg. Ha erre mégis szükség van, akkor - elvileg - le kéne lőni a ciklust és újra csinálni, persze csak nagyobb változtatásokhoz. A gyakorlatban, ha ilyen szitu van, akkor egyezkedések kezdődnek: ok bevesszük még ezt a feladatot, de akkor ezt meg ezt kivesszük stb. Ilyenkor résen kell lenni a rendszer függőségei miatt.

Fontos, hogy egy feladat az egy komplett feature, egy elejétől a végéig befejezett funkciója a rendszernek, egy olyan dolog, aminek elkészültsége könnyen mérhető. Hiába van meg pl. egy kalkulációs rész logikája, ha nincs rendesen kivezetve a felületre, akkor még nem használható így nincs készen.

Ciklus végén megmutatjuk az elkészült funkciókat az ügyfélnek. Ez konkrétan azt jelenti, hogy fogunk egy projektort és a fejlesztők ki-ki a maga által (vagy pont mások által) készített részt bemutatja, ledemozza. Az ügyfél ezt a prezentációt végignézi és, ha minden megbeszélt feladat elkészült, akkor elfogadja a ciklust. Ez azt jelenti, hogy megkapja a terméket, és fizet az addigi munkáért. Ha nem fogadja el a ciklust, akkor nem kell fizetnie, de (ez is egyezkedés eredménye) esetleg a termék újabb feature-eit sem kapja meg. A fejlesztő cégnek ott a kockázat, hogy 1-2 havi munkáját nem fizetik ki, az ügyfélnek meg ott, hogy 1-2 hónapot vár és esetleg nem kap semmit.

Fontos, hogy a határidők (pl. ciklus vége) nem változtatható. Nincs olyan, hogy megleszünk az összes feladattal, de egy hetet csúsznánk. Olyankor meg kell beszélni az ügyféllel, hogy figy. az a helyzet ,hogy nem lesz meg minden feladat. Lelövöd a ciklust, vagy még így is akarod?

A módszer bizalomra épül. Az ügyfél belelát a munkába. Bármikor megnézheti az előrehaladást a feladatlistában. Ott lesz, hogy ki melyik tennivalót csinálja és mennyi van még hátra. (persze lehet trükközni, kijátszani az ügyfelet, de csak legvégső esetben érdemes.

A felelősségek szerepekre vannak bontva. Van Project Owner-i szerep. Ő képviseli az ügyfelet. Ügyfél oldali döntéshozó. A fenti leírásban ami ügyféllel kapcsolatos feladat azt mind ő látja el. Őt az ügyfél adja. Vele tartjuk a kapcsolatot. Kicsit olyasmi mint egy projekt manager.
Van a Scrum Master szerep. ő a mentora a fejlesztő csapatnak. ő vezeti a reggeli megbeszéléseket. Hozzá fordulnak a fejlesztők ha bármi problémájuk, panaszuk van. Lassú a számítógép, a Józsi nem hagy békén stb. Célja, hogy a csapat hatékonyan működjön. Utasítani nem utasíthat, csak javasolhat, tanácsolhat.
Végül van a Team. Ő a fejlesztő csapat (a scrum master is tagja). Olyan mint egy cserkész őrs: együtt szívunk, együt örülünk. Ha valaki nem dolgozik, vagy elkalandozik, lusta stb. akkor nem az egyén szív, hanem az egész csapat, ha emiatt bebukják a ciklust, tehát a Team szól rá az egyénre, nem egy főnök vagy ilyesmi. A team tartja kézben saját magát.

Nem minden projekt esetében tud az ügyfél egy teljes embert teljes időben a projektre szánni. Ilyenkor van lehetőség rá, hogy a fejlesztő cég adjon Project Owner-t az ügyfélnek. Az ügyfélnek teljesen meg kell bíznia abban az emberben és minden döntési jogkört meg kell kapjon, ezért ez elég ritka. Inkább csak összeszokott partnereknél fordul elő.

Létezik olyan is, hogy kívülről (ügyfél irányból) nem látszik, hogy scrum-mal dolgozik a cég, mert minden szerepet a fejlesztő cég lát el, és kvázi belső projektként kezelik. Belső meetingek vannak a feladatlistát is belül állítják össze. Persze le lehet egyezteti az elkészült feladatlistát. A ciklusok végén lehet prezentációt csinálni. de a ciklus elfogadása/elutasítása már nem tudom hogyan kivitelezhető.

Sajnos a ruby-s binding-ok használhatatlanok.

Hunspell-hez létezik JNA itt: http://dren.dk/hunspell.html

suggest, misspelled működik, de stem és az analyze nem. A JNA csomagban van előre fordított hunspell lib, de vmi régi verzió, amiben ezek a funkciók még kísérleti fázisban vannak. A használatához újra kellene fordítani —with-experimental kapcsolóval. Próbáltam elszáll számos helyen: befejezetlen a kód.

Leszedtem legfrissebb hunspell-t, amiben ezek már alapból benne vannak. lefordítottam. stem megy. Az analyze-hoz kicsit módosítani kell a JNA-t, mert nincs megírva a binding. Semmi vész egy copy paste az egész. A HunspellLibrary.java file-ban felveszed a Hunspell_analyze metódust, Hunspell_stem alapján, illetve Hunspell.java-ban lemásolod a stem metódust és átírod a nevét.

Végül ant clean aztán ant és kész.