Kommentarer (4)

Ved Steven Lloyd Watkin , onsdag 6 januar 2010 12:13

For å direkte forespørsler om / sitemap.xml til en tilpasset kontroller og handling i Zend Framework søknaden bare legge til følgende i din application.ini eller alternative config-filen (f.eks jeg bruker navigation.ini):

 resources.router.routes.sitemap.route = "sitemap.xml"
 resources.router.routes.sitemap.defaults.controller = index
 resources.router.routes.sitemap.defaults.action = sitemap

Eksempel på kode for sender ut kan sees ved å opprette en handling i den aktuelle kontrolleren (f.eks min sitemap ligger i indeksen controller, områdekart handling):

 < php
 klasse IndexController
     strekker Zend_Controller_Action
 {
     / **
      * Gjengir et nettkart basert på Zend_Navigation setup
      * /
     offentlig funksjon sitemapAction ()
     {
    	 echo $ this-> Vis-> navigasjon () -> sitemap ();
    	 $ This-> Vis-> layout () -> disableLayout ();
    	 $ This-> _helper-> viewRenderer-> setNoRender (true);
     }
 }

Sitemaps kan raskt og enkelt bli generert ved hjelp Zend_Navigation , er en stor rask tutorial (og generelt svært nyttig for Zend Framework tutorials) Zend overhodekast - dynamisk lage en meny en sitemap og brødsmuler .

Kommentarer (8)

Ved Steven Lloyd Watkin , fredag ​​1 januar 2010 22:40

Jeg har opprettet en oppfølging til dette innlegget som krever mindre konfigurasjon, se Modul Basert Layout - Zend Framework .

Når du bruker Zend Framework med moduler, dets åpenbart at hvis du kjører forskjellige (sub-) sider av samme program du ikke nødvendigvis vil ha samme layout skriptene for hver del. Jeg bestemte meg for å gå med på følgende område struktur:

  / Application
     / Kontrollere
         ...
     / Modeller
     / Moduler
         / Default
             / Kontrollere
             / Layout
                 / Scripts
             / Visninger
                 / Scripts
         / AnotherModule
             ...
     / Scripts

Problemet var å sette opp oppsettet skript på en per-modul basis. Svaret kom gjennom ved hjelp av en handling Helper. Sette opp layoutene på en per-modul basis involverer tre trinn:

1. Application.ini (eller lignende konfigurasjonsoppsettet):
   

     admin.resources.layout.layoutPath = APPLICATION_PATH "/ moduler / admin / oppsett / scripts"
    default.resources.layout.layoutPath = APPLICATION_PATH "/ moduler / default / oppsett / scripts"
    member.resources.layout.layoutPath = APPLICATION_PATH "/ moduler / medlem / oppsett / scripts"
    affiliate.resources.layout.layoutPath = APPLICATION_PATH "/ moduler / affiliate / oppsett / scripts" 

2. Lag din Handling Helper:
   

     <? Php
    / **
     * Setter layout banen på en per-modul basis
     *
     * @ Author Lloyd Watkin <lloyd@evilprofessor.co.uk>
     * @ Siden 2010-01-01
     * /
    klasse Pro_Controller_Action_Helper_SetLayoutPath
        strekker Zend_Controller_Action_Helper_Abstract
    {
        / **
         * Setter layout sti basert på modul
         * /
        offentlig funksjon preDispatch ()
        {
       	 $ Modul = $ this-> GetRequest () -> getModuleName ();
   
   	     if ($ bootstrap = $ this-> getActionController ()
   	                        -> GetInvokeArg ('bootstrap')) {
   
   	         $ Config = $ bootstrap-> getOptions ();
   
   	         if (Isset ($ config [$ modul] ['ressursene'] ['layout'] ['layoutPath'])) {
   	             $ LayoutPath =
   	                  $ Config [$ modul] ['ressursene'] ['layout'] ['layoutPath'];
   	             $ This-> getActionController ()
   	                  -> GetHelper ("layout")
   	                  -> SetLayoutPath ($ layoutPath);
   	         }
       	 }
        }
    } 

3. Og til slutt boostrap handlingen hjelper:
   

     ...
        / **
         * Setter opp layout skript på en per-modul basis
         * /
        beskyttet funksjon _initLayoutHelper ()
   	 {
   	     $ This-> bootstrap ('frontController');
   	     $ Layout = Zend_Controller_Action_HelperBroker:: addHelper (
   	         nye Pro_Controller_Action_Helper_SetLayoutPath ());
   	 }
    ... 

Kommentarer (5)

Ved Steven Lloyd Watkin 30. Onsdag desember 2009 18:30

Jeg har slitt med å sette opp et databaseskjema for et nytt Zend Framework prosjekt. Jeg bruker prøver å bruke Lære ORM for min database modeller. Jeg trenger å sette opp skjemaet slik at det tillot meg å sette en standard dato og tid for en `datetime` kolonne, f.eks når du legger til en ny melding jeg få den gjeldende tidsstempel. Etter mye leting og eksperimentering fant jeg løsningen, så jeg deler det.

I ditt skjema YAML fil bare gjøre følgende:

 Melding:
   Actas:
     Timestampable:
       opprettet:
         navn: created_at
         type: timestamp
         format: Ymd H: i: s
       Oppdatert:
         navn: last_updated
         type: timestamp
         format: Ymd H: i: s
   kolonner:
     id:
       type: heltall
       primære: true
       autoincrement: true
     navn: string (255)
     email: string (300)
     message: string (2000)

Hvis derimot du ikke ønsker en `updated_at` kolonne kan du bruke følgende:

 Melding:
   Actas:
     Timestampable:
       opprettet:
         navn: created_at
         type: timestamp
         format: Ymd H: i: s
       Oppdatert:
         deaktivert: true
   kolonner:
     id:
       type: heltall
       primære: true
       autoincrement: true
     navn: string (255)
     email: string (300)
     message: string (2000)

Kommentarer (3)

Ved Steven Lloyd Watkin , tirsdag 29 desember 2009 22:02

Jeg har lest Head First Design Patterns nylig, og har besluttet å skrive noen av mønstrene som PHP eksempler for min egen fordel. Den første som jeg har besluttet å kode opp er Observer Pattern . Den formelle definisjonen av Observer Pattern er:

Observatøren mønster (en undergruppe av den asynkrone publisere / abonnere mønster ) er en software design mønster hvor et objekt , kalt faget, vedlikeholder en liste av sine pårørende, kalt observatører, og varsler dem automatisk noen stats endringer, vanligvis ved å ringe en av deres metoder . Det er i hovedsak brukes til å implementere distribuerte event håndtering systemer.

Etter hvert som systemene blir mer løst koplet å sørge for at når en hendelse skjer alle systemer som krever er kunnskap om disse oppdateringene informert. For eksempel, et blogginnlegg, etter lagrer et innlegg kan vi trenger å oppdatere en søkemotor (f.eks Lucene), oppdatere våre sitemap, tags, email abonnerer brukere, osv. Observatøren mønsteret lar utviklere å legge til flere lyttere uten å redigere deres observerbare objekt . Ved å injisere observatører (dvs. en søkemotor oppdatere observatør, en sitemap generator, etc) i et fag (dvs. blogginnlegg redigering system) kan vi tillate at det å utføre alle de nødvendige oppdateringene uten noen endringer.

Fortsett å lese 'PHP Design Patterns - Observer Pattern' »

Kommentarer (2)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 11:59

Innledning

Jeg jobber i et selskap hvor vi kjøre mange satsvise jobber behandling millioner av poster av data hver dag, og jeg har tenkt nylig om alle maskinene som sitter rundt hver eneste dag gjør ingenting for flere timer. Ville det ikke være bra hvis vi kunne bruke disse maskinene til å styrke behandlingskapasiteten til våre systemer? I dette settet av artikler jeg skal se på de potensielle fordelene ved å ansette et kontor rutenett med virtualiserte miljøer.

I del 3 skapte vi vår virtuelle behandling maskin og sette opp windows maskiner for å bli inaktiv tid arbeidere.

Kjører den nyeste kode

Uunngåelig etter at du opprettet arbeiderne forretningslogikk vil forandre, vil bugs bli funnet, vil raskere mer effektiv kode bli produsert dermed forlate dine arbeidere satt rundt behandling av data ved hjelp av gamle stinkende kode . Hvordan så sikrer vi at vi alltid bruker den nyeste og beste versjonen av vår behandling skript?

Det er noen veldig enkle enkle måter vi kunne gjøre dette, triks, derimot, er å redusere prosessorkraft og nettverkstrafikk i å oppnå dette. Lar starte med de enkleste løsningene og forbedre den sakte over et par iterasjoner.

Den første metoden ville være å bare koble til jobben vår kontroll server (via samba, FTP eller lignende) og trekk ned den nyeste versjonen av koden. Ikke veldig effektivt, men det vil gjøre jobben. Lar forbedre på at noe, hva med å skape et rsync skript og bruker den hver gang i stedet? Eventuelt hva med å sette våre siste behandling manuset til Subversion sjekke ut koden først, og så bare oppdaterer vår kode på hver kjøring ( svn update )?

Til slutt kan vi ende opp med et bash script (kalt av cron hvert 10. minutt), som ser så enkelt som dette:

  #! / Bin / sh
 hvis ps ax | grep-v grep | grep php > / dev / null
 deretter
     echo "Job er for tiden behandling, exit"
 ellers
     echo "Job ikke kjører, starter nå"
     cd / sti / til / jobbe / kopi
     svn update
     php yourJobProcessingScript.php
 fi 

Nå kan vi være sikker på at med hvert løp er vi definitivt kjører den nyeste koden. Vi er sikre dette ved å oppdatere våre kodebasen hver gang vi utfører en løpetur og redusere nettverkstrafikken ved bare å overføre filen forskjeller på tvers av nettverket vårt.

I min demonstrasjon setup, gjorde jeg akkurat som ovenfor. Subversion ble installert på min jobb behandling server og jeg bare trakk siste koden fra en "arbeidstaker" gren bruker 'svn update'. Jeg har også laget en versjon nummer tag til min prosessering manus som ble returnert til databasen som en del av resultatene retur. På denne måten kunne jeg se at min kode ble oppdatert hver gang jeg kopierte min trunk inn arbeideren grenen dvs at jeg var definitivt kjører den nyeste prosessering script.

Bruke nyeste dataene

Hvis jobben din prosessering gjør bruk av datakilder så på et tidspunkt disse kommer til å bli oppdatert også. Med mindre du ringe datakilder på en svært sjeldne basis du kommer til å oversvømme nettverket med trafikken så snart arbeiderne begynne å bringe alt til en stillstand. For løsning mitt bestemte jeg at jeg vil flytte dataene mine kilder rundt med mine VMer.

Hold du hester dit! Hva om mine datakilder er enorme? Vel, dette er virkelig et tilfelle av hvor mye data snakker vi? Det kan være mer kostnadseffektivt å installere en ekstra større harddisk til hver maskin enn å kjøpe en ekstra behandling server. Dette er et spørsmål om budsjett og er opp til virksomheten å bestemme. Det kanskje at datakildene er så store at det bare unfeasible å holde dette beløpet av data i arbeideren maskiner. I så fall hva ville du gjøre? Vel vi kunne se på ringer en lokal data server, men dette kan føre til problemer med nettverket. I dette tilfellet et rutenett system som dette kan bli urealistisk å inkludere i kontormiljøet. Det kan også være at du kan se på alternativ drift strategier, for eksempel bare å ringe dine arbeidere mellom 20:00 og 6am hver natt og / eller struping datakilde forespørsler.

Flytte på kan si våre datakilder beløpe seg til 100 GB med data. Vel ja det er ganske mye data å flytte rundt nettverket på en oppdatering. Hvordan ville vi sikre at vi har den siste kopien av dataene i dette tilfellet? Rsync er en mulighet, men personlig tror jeg ved å kjøre de nyeste dataene kilden på jobben din behandling server og sette dette opp som en mester i replikering (med en fin lang bin log) kan være veien å gå:

Ved å sette hver av dine ansatte opp som en slave til jobbkontroll server oppdateringer til datakilder vil sildre nedover pent til arbeidere uten en enorm økning i nettverk aktivitet (som er mindre du utfører en stor data oppdatere og alle arbeidere sparke i samtidig). Dette har fordeler framfor rsync på at du ikke ville få en lang pause før hver jobb, som database oppdateringer, mysql vil daemonen på arbeideren din kontinuerlig oppdatere sin data mens behandlingen fortsetter.

Dette er hvordan jeg setter opp min demonstrasjon server. For å sette opp replikering Jeg fulgte guiden på mySQL hotellet ( Sette opp replikering ) og innen 20 minutter hadde jeg min inital arbeideren kopiere jobben kontroll serverne datasett. For hvert ekstra arbeidstaker replikering innstillinger og behandle jobbet hver gang da VM ble kopiert.

Oppsummering

I denne delen av artikkelen har vi sett på hvor enkelt og smertefritt det er å holde prosessering kode oppdatert ved using rsync eller subverion (SVN) for å gjøre arbeidet og redusere nettverkstrafikken på samme time. Vi diskuterte også hvordan å holde datakilden informasjon up-to-date ved at det sildre ned til hver av arbeiderne. Dermed kan vi området som sikrer at vi holder tritt med forretningslogikk og informasjon på vårt kontor bæresystem. Det vil åpenbart være utallige alternativer til å utføre disse oppgavene, men her ble to enkle eksempler for å vise hvor enkelt en løsning er å komme forbi.

Neste gang

I den siste delen av denne serien, treffende navn Del 5 vil vi diskutere distribusjon av dette systemet for. Jeg skal oppsummere hva som har blitt lært og hva jeg klarte å skape.

Kommentarer (3)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 23:37

Innledning

Jeg jobber i et selskap hvor vi kjøre mange satsvise jobber behandling millioner av poster av data hver dag, og jeg har tenkt nylig om alle maskinene som sitter rundt hver eneste dag gjør ingenting for flere timer. Ville det ikke være bra hvis vi kunne bruke disse maskinene til å styrke behandlingskapasiteten til våre systemer? I dette settet av artikler jeg skal se på de potensielle fordelene ved å ansette et kontor rutenett med virtualiserte miljøer.

I del 2 har vi sett på de jobbene en server vil kjøre, og hvordan arbeidsplasser bør være konfigurert for å oppnå størst mengde behandling samtidig sikre at hver jobb blir behandlet uten å lykkes.

Sette opp arbeidstaker - eller limp server

Det neste trinnet i prosessen er å sette opp din virtuelle arbeidere. For dette jeg kommer til å bruke en installasjon av CentOS bruker VirtualBox. Jeg kommer til å installere mySQL og PHP på serveren, også kjent som en limp (Li Nux, m ySQL, P HP) Servera (jeg har kanskje gjort det navnet opp).

• Installer VirtualBox på Windows-maskinen (følg link)
• Last ned og installer CentOS (nåværende versjon 5.3) innenfor et skapt virtuell maskin

Det er ingen vits meg å gå til denne er det sannsynligvis 1000 's flotte tutorials der ute (ok, her er ett: Lage og Managing CentOS virtuelle maskinen under VirtualBox ). Det viktige punkt å merke jeg antar er at jeg ringte min virtuell maskin GridMachine.

Såvidt mitt valg av virtualisering klient og operativsystem går er det ingen stor overbevisende grunn for hvert valg. VirtualBox er noe jeg bruker på min hjemme maskin og er støttet av de tre store operativsystemene. Jeg valgte CentOS som sin en god stabilt OS og jeg bruker det på min egen web server. Jeg er en stor tro på de riktige verktøyene for jobben (selv om jeg søker 'bruk den raskeste og enkleste for deg' mentalitet her), så hvis operativsystemet X kjører koden din raskere og mer effektivt bruke den i stedet:)

Viktigere sørge for at VM bruker DHCP, ellers for hver ny virtuell maskin ville må konfigureres separat som er noe vi ikke want.By bruker DHCP vi ikke trenger å konfigurere nettverksinnstillinger individuelt for arbeideren maskiner, vil DHCP hånd ut IP for deg. Derfor kan du kopiere den virtuelle maskinen rundt i kontoret uten å bekymre deg om å sette hver og en opp (dette forbedrer skalerbarhet og reduserer arbeideren administrasjon).

Prosessen du bør sikte på å oppnå ville være å skaffe en ny fysisk maskin, installere VirtualBox, og deretter ganske mye distribuere virtuelt bilde uten mye annet. Det kan være lurt å sette alle dine arbeidere på et annet subnett, slik at du kan i det minste se hvor mange maskiner kjører. Du trenger også å sette opp maskinene på en lang leieavtale eller ubegrenset lease DHCP.

Hvordan kjøre jobber på arbeideren

Dette er et interessant område og det er flere gyldige metoder for prosessering jobber på arbeideren. Her skal jeg bare diskutere de to mest åpenbare:

• Stadig kjører script: Et skript, det være seg et skall skript eller et PHP-script kjøres en gang på arbeideren og løper som en del av en uendelig loop. Jeg har diskontert denne metoden som et krasj av skriptet og potensielt dine arbeidere vil slutte å kjøre uten noen form for intervensjon.
• Cron baserte skript gjennomføring: Hver X minutter cron daemon starter en samtale til skript for å få ting i gang. Uten noen sjekker dette kan føre til mange mange kopier av arbeideren skript.

Min beslutning var å gå med cron som starter et skall skript hver 10 minutes. My shell script utfører følgende oppgaver:

1. Få en prosess liste og grep dette for 'php'. Hvis ikke fant deretter fortsette.
2. Ring jobben din kode, i mitt tilfelle dette skulle bli noe PHP baseres
3. Worker skript fullfører sin løpe
4. Klar til å gå igjen på neste passende kaller

Min bash script ser omtrent ut som følgende:

  #! / Bin / sh
 hvis ps ax | grep-v grep | grep php> / dev / null
 deretter
     echo "Job er for tiden behandling, exit"
 ellers
     echo "Job ikke kjører, starter nå"
     php yourJobProcessingScript.php
 fi 

Merk: echo-er er nesten helt meningsløs, men kan bidra til den neste personen som kommer sammen for å prøve og redigere dem.

Det konkluderer oppsett av arbeideren virtuell maskin, rask, enkel og lett å kopiere til hver ny maskinvare som er mottatt. The 'klokskap' av bæresystemet er virkelig ikke i visualiseres OS, alt å gjøre med koden opprettet for å behandle jobber, jobben konfigurasjon, og i å sørge for at jobben går når det er hensiktsmessig (dvs. når verten er inaktiv ).

Sette opp Windows til å initialisere Workers

Den første oppgaven er å arbeide ut kommandoen kreves for å kjøre den virtuelle maskinen fra windows kommandolinjen. Hvis du har installert VirtualBox på standard plassering, og du har gitt arbeidstakeren GridMachine deretter kommandoen som kreves for å laste opp arbeideren er:

  "C: \ Program Files \ sø \ VirtualBox \ VBoxManage.exe" startvm GridMachine 

Men å kjøre skriptet i en "hodeløs" state vi trenger å bruke:

  "C: \ Program Files \ sø \ VirtualBox \ VBoxHeadless.exe"-startvm GridMachine - vrdp = off 

Dette vil starte den virtuelle maskinen uten GUI og la den for å spare staten grasiøst. Det andre argumentet slår av RDP så det ikke kommer i konflikt med vinduer RDP, eller gi deg en beskjed om å lytte på port 3389. Den virtuelle maskinen navn er store og små bokstaver!

Deretter må vi sette vinduene opp til kick off våre arbeideren VM når maskinen er uvirksom. For å gjøre dette (på Windows XP) du trenger for å gå Start -> Alle Programmer -> Tilbehør -> Systemverktøy -> Planlagte oppgaver som følger:

Neste klikk på "Legg til planlagt oppgave" etterfulgt av bla å legge til et egendefinert program. Naviger til VBoxManage skriptet og trykk ok. Planlegg din oppgave for noen av alternativene (vi kommer til å endre dette i ett minutt) og fortsette. Etter å hoppe over det neste skjermbildet windows vil spørre deg hvem du vil kjøre denne oppgaven, vil jeg foreslå enten 'Administrator' eller opprette en ny privilegert bruker. Husk at vi ikke ønsker å forstyrre standard personalet konto på maskinen på noe punkt. Klikk Neste og sjekk viser avanserte alternativer for denne oppgaven.

Til slutten av oppkjøringen tekstboksen legge vår "startvm GridMachine 'streng og sørge for at bare kjøre når du er innlogget er igjen merket av. Besøk planlegge oppgaven neste og endre planen falle ned til alternativet 'når idle ", velge hvor mye tid du ønsker at maskinen skal være inaktiv før du går videre til neste fane.

Endelig fjern merket det alternativet som sier stopp oppgaven hvis den har kjørt X tid, men merk muligheten til å stoppe oppgave hvis maskinen er ikke lenger ledig.

Det er det da for windows host setup!

Oppsummering

I denne delen har vi satt opp en virtuell maskin til å fungere som en arbeidstaker, samt måten vi kaller og gjennomføre vår jobb behandling skript (for meg et PHP-script). Herfra ser vi på hvordan du setter opp vår kopier av vinduene for å starte opp den virtuelle maskinen i hodeløse modus når maskinen blir inaktiv, og lagre tilstanden når brukeren gjenopptar bruken av maskinen. Forhåpentligvis på dette punktet du ser hvor enkelt det er å sette opp et slikt system, og er spent på å få noen eksperimenter gang selv!

Neste gang

I Del 4 vil vi se på bruk av verktøy for å sikre at du kjører den nyeste versjonen av koden og datakilder, slik at oppnådde resultater er alltid up-to-date med de nyeste forretningsinformasjon og logikk.

Kommentarer (1)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 11:23

Innledning

Jeg jobber i et selskap hvor vi kjøre mange satsvise jobber behandling millioner av poster av data hver dag, og jeg har tenkt nylig om alle maskinene som sitter rundt hver eneste dag gjør ingenting for flere timer. Ville det ikke være bra hvis vi kunne bruke disse maskinene til å styrke behandlingskapasiteten til våre systemer? I dette settet av artikler jeg skal se på de potensielle fordelene ved å ansette et kontor rutenett med virtualiserte miljøer.

Som en PHP utvikler jeg kommer til å bruke verktøy som jeg bruker hver dag nemlig, Linux, MySQL , PHP, VirtualBox og Subversion (SVN). Men jeg håper denne guiden vil tilpasse seg andre språk og teknologier like bra.

Løsningen jeg gir blir svært løst basert på den type behandling vi hadde behov for å oppnå men dette kan ikke være sant gjennom hele artikkelen som jeg skal forandre ting for enkelhet, eller for å produsere mer interessant bruksscenarioer.

Disse virtualiserte miljøer som vil kjøre på windows maskiner siden dette er hva de fleste av kontorer løpe. Behandlingen at kontormaskiner ikke skulle forstyrre personalet bruker disse maskinene, bør kreve noe vedlikehold på maskinen, og være lett deployerbare til nye maskiner som de blir tilgjengelige. I tillegg bør nye virtuelle maskiner ikke krever noen ekstra konfigurasjonen som dette i stor grad reduserer skalerbarhet og lette der bæresystemet kan forlenges.

Hvorfor Distribuere et Office Computing Grid?

For det første du tenker kanskje, hvorfor ikke bare bruke en cloud computing ressurs som Amazons EC2-plattform ? Vel grunnene kan være flere, for eksempel:

• Du vil ikke overlate visse data til en cloud computing miljø
• Du kan ikke sette visse data i en cloud computing miljø for juridiske årsaker (f.eks data forlater landet), potensielt for juridiske årsaker, f.eks NHS poster.
• Du ønsker å holde processing units nært og har full kontroll over maskinvaren også
• Du har ikke prosjektmidlene til å kjøre sky tilfeller
• Kontoret ikke har en tilknytning til internett og derfor det ikke mulig å bruke en sky ressurs
• Du liker ikke regn, skyer foreslår regn, derfor holde god avstand

Jeg er sikker på at listen kunne fortsette, men jeg tror det er nok for nå.

Fordeler med en Office Computing Grid

Vel, lar gjøre litt matte (og i ekte fysikk stil lar gjøre noen feiende forutsetninger). Tenk deg at du har store beefy prosessering server som kjører 100 arbeidsplasser per dag. På kontoret har du 50 maskiner som er idle 16 timer i døgnet, hver av disse maskinene er 10% like kraftig som beefy prosessering sever. (Alle resultatene her er avrundet for å undervurdere ytelse økning).

Så kan en maskin * 10% strøm * 2 / 3 gang = 0,067 dvs 1 desktop behandling i idle tid prosessen seks fulle jobber per dag.

Hvis du nå skalere dette opp det tar 15 idle stasjonære å behandle så mange arbeidsplasser per dag som din viktigste behandlingen server gjør.

Så i vår late kontoret til 50 maskiner kunne vi øke vår prosesseringskraft fra en server opp til 4 full prosessering servere, eller vi kan behandle 400 arbeidsplasser per dag i stedet for 100.

Legg merke, for ingen investering i ny maskinvare firmaet har nettopp økt sin batch prosesseringskapasitet 4 ganger! Potensielt du kommer til å øke strømforbruket, men fra de fleste kontormiljøer jeg har vært i maskiner er generelt igjen på natten uansett, så du kan se dette som et grønt initiativ.

Andre fordeler også bety at investeringer i ny (eller oppdatert) behandling servere kan bli forsinket hvis kontormaskiner er tilstrekkelige og at når du forbedre ytelsen i kontormaskiner kontoret grid blir kraftigere automatisk.

Technologies

Hva du trenger? (Eller mer korrekt hva gjorde jeg bruker):

• Idle kontormaskiner (i mitt tilfelle en reserve gamle windows XP laptop)
• VirtualBox (eller et annet virtualisering klientprogramvaren)
• En virtuell maskin med PHP, mySQL running kjører et kutt ned OS, jeg ringer disse mine Limp servere:)
• Jobs til å kjøre
• Job server (kan være en annen virtuell maskin sted)

Typiske Jobs

Hvilke typer jobber som dette systemet er designet for å kjøre er som følger:

• System mottar en liste med data hvorpå vi trenger for å matche og returnere resultater
• Matching innebærer å sjekke / søker flere (ganske statisk) datakilder
• Resultater fra datakilder kan kreve ytterligere validering, sammenslåing, kontroll av flere datakilder i respons til resultater
• Data er tilbake med samsvarende poster, fullt validert og bearbeidet
• Hver post i en jobb er uavhengig av resten

Så i utgangspunktet vi ser på kjører jobber som krever en blanding av database oppslag og noen tallknusing, et ganske typisk scenario i et bedriftsmiljø.

Grid-løsninger er ikke bare en fordel for behandling jobber av denne typen. I utgangspunktet kan enhver prosess som kan deles inn i selvstendige enheter kjøres parallelt. Se denne Wikipedia for eksempler og mer informasjon: Grid Computing , men et par kjente eksempler er Seti @ Home og BIONC . Det er rammeverk for å kjøre databehandling rutenett, og disse er vel verdt å se inn.

Hva vil vi oppnå?

Ved slutten av disse artiklene håper jeg å vise at distribusjon av et kontor grid trenger ikke være veldig dyrt eller tidkrevende. Jeg kommer til å diskutere:

• Sette opp jobben styresystem, jobb konfigurasjon
• Opprette en passende behandling virtuell maskin
• Hvordan sette opp systemet på en windows maskin
• Sikre du bruker den nyeste kode og data
• Distribusjon og benchmarking
• Ser framover

Jeg vil bli bygget (ok jeg bygget, da skrev dette) et eksempel program for å teste konsepter på en lokal maskin med Windows XP og min "GridMachine" virtuell maskin. Min jobb kontroll serveren vil være min viktigste maskin som kjører Fedora 11 .

Dette er på ingen måte ment å demonstrere en fullt fungerende robust system, betydde det mer av en demonstrasjon og diskutere viser at disse tingene kan oppnås i en rimelig kort tid, og ved liten kostnad. Kan du gjerne sende meg noen kommentarer, rettelser eller forbedringer og jeg skal gjøre mitt beste for å holde denne artikkelen oppdatert å matche.

Neste gang

I del 2 vil jeg starte med å se på jobben kontrollsystemet, og se på hvordan jobbene skal være konfigurert for å oppnå størst mengde behandling samtidig sikre at hver jobb blir behandlet uten å lykkes.

Kommentarer (1)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 11:23

Innledning

Jeg jobber i et selskap hvor vi kjøre mange satsvise jobber behandling millioner av poster av data hver dag, og jeg har tenkt nylig om alle maskinene som sitter rundt hver eneste dag gjør ingenting for flere timer. Ville det ikke være bra hvis vi kunne bruke disse maskinene til å styrke behandlingskapasiteten til våre systemer? I dette settet av artikler jeg skal se på de potensielle fordelene ved å ansette et kontor rutenett med virtualiserte miljøer.

I del 1 ga jeg en oversikt over systemet og teknologiene jeg skal bruke så vel som diskutert noen av de mulige årsakene til at du ønsker å opprette et kontor rutenett.

Job Kontroll

Hvis du skal kjøre jobber så du kommer til å trenge noen måte å håndtere dem. Din jobb kontroll system (på jobben din server) må være veldig godt gjennomtenkt før du selv forsøker å kjøre et kontor rutenett. Så det første, hva er oppgaver for en jobb kontroll system:

• Del ut jobbene på forespørsel fra arbeiderne
• Fortell arbeidere hvilken type jobber å kjøre
• Spor jobber
• Sørg for at jobbene er kun kjørt en gang
• Gi jobbdata til arbeiderne, eller i det minste fortelle dem hvor de skal få det

Systemet må også være utvidbart, en løsning som fungerer for nå i et enkelt tilfelle kan utvides til å kjøre flere typer jobber som bedriften ser verdien i et rutenett løsning. For eksempel kan jobber gain prioriteringer, mer enn én type jobb kan foreligge (dvs. flere code baser), til slutt kan du også kjøre flere forskjellige arbeider maskiner som er optimalisert for hver type jobb (selv om det beveger seg bort fra den "generiske arbeideren 'idé). Prøver alltid å tenke på fremtiden når utvikle systemer, kan et kortsiktig syn føre til lengre sikt frustrasjon og økt utvikling tid.

Job Server

Vi kommer til å trenge et sted å kontrollere vår jobber fra, bør dette være den eneste systemet i nettet ditt som har en fast resource locator, være at en IP-adresse, vertsnavn, URL (bruk av interne DNS), osv. Dette er fordi behov for arbeiderne å vite hvor du skal lete etter jobber, arbeidere trenger å finne den jobben kontrollsystemet (ikke jobben kontrollsystemet finne arbeiderne).

Jobben serveren selv egentlig ikke har en komplisert oppgave (i et grunnleggende system hvertfall), det er behov for å lagre en liste over jobber, dele ut jobber, får resultater, og deretter lagre dem for senere henting. Hvordan disse delene (som "hand out jobber") er definert kan være svært grunnleggende. Senere kan vi utvide systemet til å inkludere et administrasjonsgrensesnitt for å legge til, redigere, slette, suspendere jobber, men dette er hinsides denne øvelsen.

Det er ingen grunn overhodet da at jobben din server ikke kunne være en virtuell maskin som kjører innenfor ditt viktigste behandlingen serveren forutsatt at det ikke tappe for mye ressurser fra det. Jobben server imidlertid ikke trenger høy tilgjengelighet, hvis det går ned på en fredag ​​kveld du kommer til å miste en hel helg med behandling, potensielt koste deg et par uker igjen av behandlingstid (i forhold til dine viktigste behandlingen server alene) . Det kan være lurt å vurdere å sette jobben din server på et lass balansert miljø for høy tilgjengelighet.

Basic Setup

The basic setup for our job server will consist of what I'm calling one of my LiMP servers (that is Li nux, m ySql, P HP). The code running on the workers will actually work out what jobs it can run by interacting with with job control system databases. Later on we could create a web service and actually hand out jobs rather than having the workers do the hard work themselves, but for now we'll continue using the KISS principle (Keep it Simple, Stupid!).

So, lets create three mySQL tables to deal with jobs. These will be `jobs`, `jobRecords`, and `jobResults`.

Here I'm using SQL Buddy a great little alternative to phpMyAdmin just because its easier to install on centOS (for others see: 10 Great alternatives to phpMyAdmin )

This table consists of 5 simple fields,

• id: Uniquely identify the job
• name: Could be a client reference, or any number of other identifiers
• Status: You need to know where the job is at, eg
  • 0: Not started
  • 1: Picked up
  • 2: Completed
• started_by: Who's started doing the job? This isn't entirely required but is a nice to have. I'd suggest tracking workers by their IP address on your network
• started_at: When did the worker start the job? By tracking jobs that have not completed within X amount of time we know we need to pick up the job once again and start processing by another worker. Workers could stop processing/go offline for any number of reasons, power failure, crash, network loss, etc.

It is easy how this table could be extended with a few additional fields to allow for statistics tracking, a finish time column to see how long the job took, a counter to see how many workers picked up the job (obviously this needs to tend to 1), job priority, the list can go on and on. In more complex job scenarios it would be possible to specify how much memory the worker would need access to (and therefore only use suitable workers), or even what type of worker would be required.

Lets add a few example jobs:

The next table again is quite simple to understand, these are our job records. They are linked to the main jobs table by a column `jobs_id`. The make up of this table very much depends on the data that you need to supply to your workers, lets make a very simple example where we have four columns:

• id: ID of the record
• name: Person's name
• address: Person's address
• jobs_id: The job ID that this record is linked to

The third and final table consists of a results table, it has much the same make up as our records table, and with the addition of some columns could be part of the records table:

• job_record_id: Link the result to the job table
• result: The result data

…and that's all you need for job control! (albeit at a very basic level) In my case I'm pointed to another table where my data to process was located, but this could just as easily been a file, parameters to run simulation code, you name it.

Selecting a job

Som nevnt tidligere, vil arbeiderne gjøre jobben vår ledelse for oss for nå, så alt vi trenger for virkelig å gjøre er å finne en jobb som trenger behandling og få informasjon. Hvordan ville vi gjøre dette? Vel plukke jobben vår utvalgskriterier og lete etter jobber, i SQL gjorde jeg følgende:

1. Ta noen jobber som ikke er merket som komplett, men fra arbeideren vår og nullstille dem (innbytter __ME__ med en identifikator, ville enkleste være IP-adresse):

     UPDATE `jobb` SET `status` = 0 HVOR `status` = 1 AND `started_by` = __ME__; 

2. Ved hjelp av vår jobb seleksjonskriterier, velger du en jobb og fortelle kontrollsystem som denne arbeideren har å gjøre med det:

     UPDATE `jobb` SET `status` = 1, `started_by` = __ME__, `started_at` = NÅ () HVOR `status` = 0 eller
    (`Status` = 1 AND `started_at`> DATE_SUB (NÅ (), INTERVALL X HOUR)) ORDER BY `id` ASC; 

   Ved å ta tak i jobber som ikke har returnert resultater i X tid vi sikre at alle jobber kjøres i tilfelle en arbeidstaker å krasje eller gå AWOL.

3. Neste tak i jobbene detaljer etterfulgt av postene selv:

     SELECT * FROM `jobb` HVOR `started_by` = __ME__ LIMIT 1;
    SELECT * FROM `job_records` HVOR `id` = __JOBID__; 

Ved ferdigstillelse av jobben vi sette inn våre resultat poster og mark jobben som fullført. Husk som jobber kan suspendere / gjenoppta når som helst la for noen robusthet i skriptet. Det kan være at oppgaven suspenderer halvveis gjennom oppdatering jobben kontrollsystem, så sjekker antall poster i en jobb og antall resultater lagres tilbake til jobben styresystem ville være et klokt trekk.

In addition, whilst this demonstrates how jobs can be selected and managed from an SQL-query frame you should really be abstracting your job control so that if you decide to switch to using a web service, a file based system, XML , or any other number of systems it will not affect the code above it.

Job Configuration

The next aspect to consider is job size and configuration. By playing with job configuration we can strike an excellent balance between speed, process replication, and reliability. Take a couple of scenarios:

1. Jobs take 1 day each to run: This means that your workers need 15 days to process each job (remember 10% of the power for 2/3rds of the time). This is clearly not a wise configuration, your job size is way too big! It would take at least double the time to get a job processed should the initial worker go AWOL (time to pick up that it hasn't returned a result plus reprocessing time). In an ideal you'd have at least one full job easily cleared by the end of each long idle period, that way you keep the jobs ticking over and at worst case a job would take two days to process should the first go missing.
2. Jobs take 1 minute to run: This means that your workers take about 15 minutes to run each job. Whilst this may initially seem ideal, you gain additional work processing during lunch time, coffee breaks, meetings, etc this scenario puts strain on other areas of your system and introduces its own problems. For example, firstly your setup/processing time ratio is going to go right down, therefore losing system efficiency. Your network is going to be constantly streaming job information to the various workers frustrating staff who are dong their day to day work. You're also going to put more strain on your job processing server as it has to dish out lots and lots of small pieces of work on a regular basis. Lastly, in this situation if your job server goes down you're going to create a huge back log of uncompleted work whereas bigger jobs could of continued processing blissfully unaware that the job server was experiencing difficulties.

In reality there will be no one ideal configuration for your grid setup, much depends on the available resources, types of job, job turnaround time requirements, network capability, and so on. However some guidelines would be:

• Size jobs so that each worker can get through at least 3-4 jobs in a period of 15 hours (the longest likely idle time period)
• Play with the job size so that setup time becomes fairly insignificant compared to the processing time (bearing in mind the above point).
• If a job doesn't complete in double the amount of time (maybe less) you expect it to complete it assume that its gone AWOL and start processing it with another worker. This means you may have to wait up to three times the normal length of a job for it to complete (possibly longer if the subsequent job fails). You may want to reduce this time, but be careful not to reduce it too much as you may start duplicating processing tasks on a regular basis.
• Jobs should be independent of outside requirements as much as possible. The job server, for example, should only be contacted at the start and end of every job.
• Don't saturate your network, this will have two negative effects, your daytime staff will find using the network frustrating and problems may be experienced with connections timing out a problem that will only get worse as you scale your grid.
• Ensure jobs can run on your workers. If jobs become too memory intensive or disk space intensive jobs will start aborting and the only thing you'll notice is a drop in number of jobs processed with no real reason why.

Submitting Results of a Job

When submitting the results of a job it is important to check that results have not been submitted by another worker, especially if the current worker has been dormant for some time.

When results are submitted ensure that the number of results matches the number of records within the job.

As stated previously, and can not be over emphasised, build fault tolerance into job retrieval and results submission. The workers can (and most likely will) go into suspend mode at the most inconvenient of times and this needs to be catered for. Also once again abstracting away your results submission will help cater for future changes to your job control system much easier to deal with.

Oppsummering

In this section we have looked at what a job control server needs to do and how to get a very basic system set up. We discussed how to retrieve a job from the control system and how best to configure jobs to get the most our of your office grid system. To finish, a paragraph or two on submitting results back to the job control server was presented.

• A job control server manages jobs and ensures that all work units are completed
• By abstracting your job select/results submission we can change the technology of the control server without much problems
• Configure your jobs to ensure that they are run quickly and efficiently without putting too much pressure on your network infrastructure, and without duplicating processing tasks on a regular basis.
• Ensure that you build fault tolerance and error checking into your routines, workers can suspend and resume and the most inconvenient of times. Remember to check if results have already been submitted by another worker.

Next time

In part 3 we'll create our virtual processing machine and set up our windows machines to become idle-time workers.

Kommentarer (3)

By Steven Lloyd Watkin , Friday 4th December 2009 11:03 pm

Innledning

I work in a company where we run many batch jobs processing millions of records of data each day and I've been thinking recently about all the machines that sit around each and every day doing nothing for several hours. Wouldn't it be good if we could use those machines to bolster the processing power of our systems? In this set of articles I'm going to look at the potential benefits of employing an office grid using virtualised environments.

In Part 4 we looked at using tools to ensure that we're running the latest version of the code and data sources so that obtained results are always up-to-date with the latest business information and logic.

Pre-Deployment

Before deploying your grid system if there's one thing you do and one thing alone it's benchmark your current system ! No matter what you tell colleagues about how much extra work your system is going to do unless you have numbers to back this up your guarantees are nothing. So,

• how many records can you process currently? Per Day? Per Hour?
• How long does it typically take to turn around a job?
• How much more capacity do you have?

There's also additional questions:

• If your processing server (or one of your processing servers) goes down how will this affect your capabilities, will you be crippled?
• What advantages do you hope/expect to get from a grid system?
• Are your office machines capable of running the jobs?
• Are your (or can you jobs be converted) to wrok in this style of running?

The last major point is to take your time on any major change like this. Update your processing code to work using the new methodology, benchmark again. Possibly set up your processing server to run a virtual machine, after all your processing server will just be another worker (just a very powerful one relatively). Allow the new process to settle.

Deployment

My suggestion would be to pop into the office one weekend perform all the installations and setup. Do this just before a fortnight's holiday and leave so other poor chap to deal with the consequences… maybe not…

Distribusjon for et system som dette trenger å være treg. Despite it being relatively simple to set up this system will affect your entire office infrastructure (well the digital one). Firstly, roll out to a couple of machines at a time, monitor network traffic, how the worker hosts perform on a day-to-day basis. You may need to alter your job configuration in response to your findings.

Once the system has settled with a few machines (lets say 10% of all office machines, ie 5) keep monitoring network traffic and host machine performance. Next benchmark again, you should now be processing 33% more jobs than your first benchmarks. Check this is so, or that you're at least in this ballpark. If not, investigate what is going on before moving on. Repeat this cycle until you happily have all office machines running without killing individual machine performance or grinding your network to a standstill.

At all times keep benchmarking, even after all deployments are made. Check how new code updates affect speed of your system, check all workers are reporting in and processing jobs. Slowly (very slowly) increment your job configuration to get the best from your workers and network.

Stop!

What if you want to stop your workers from running at some time? They are all out there running, regenerating, and trying their best to process data like hungry insects. The answer may seem obvious but its worth adding just in case its overlooked. Simply edit your processing script with an exit(0) or die() or some other statement to kill your processing job. An important reason why we always try to update to the latest processing script before any run!

Demonstration System

In order to write this set of short articles I created a very small grid to demonstrate the technologies and methodologies. I read lots of articles, tutorials, and used various tools to setup and monitor what was going on. By no means have I gone out and saturated a whole office with traffic and nor have I had access to a regular staff members PC to see how host performance was affected.

My demonstration system was very humble indeed. I used my regular desktop set up as a job control server. On this I had installed mySQL server installed set up as a master in replication, PHP , and SVN linked through apache (for access via worker VM).

I then created a centOS worker machine on VirtualBox on a 6 year old windows XP laptop. I setup scheduled tasks as specified after copying the VM onto the machine and let it go.

The virtual machine was set up with PHP, subversion, and mySQL. I checked out a branch named 'worker' from my job control servers repository and made sure it could be updated using 'svn update'. Next I setup mySQL as a slave and checked that data was replicating from mySQL on the job control server down to the worker VM. After all this I setup the bash script and the cron job.

My processing script basically went along the lines of this (very simple stuff):

• Read in the name field
• Counted the number of similar names in a table from the data source held on the VM
• Counted the number of names as above but splitting the name by spaces (ie forename, middle, surname)
• Repeated this process 1,000 times

Each job took approximately 20 minutes to run. At one point I opened several copies of the worker VM on the windows laptop and watched the jobs be checked off by each of the worker IP addresses. At this point I also confirmed that replication automatically restarted.

Leaving the laptop to idle resulted in a worker starting to process jobs from the job control server. When resuming laptop usage there was a delay of about 30-60 seconds, this is a fair amount of time and staff would need to be made aware that their machine may pause for a short while when returning to the machine. Newer machines may not have a pause of this long. The benefit of the amount of processing performed by these machines during idle periods would more that outweigh staff members having to wait a short period (say 1 minute) on arriving at their machines of a morning (I frequently wait longer that this for a Windows Defender update to take place) provided they were made aware of this (useful time to grab a morning coffee!).

Overall I feel confident that I have demonstrated the technologies that could be used to create such a system. I have shown that such a system does work on a (very) small scale and with some more experimenting could be scaled up utilise the resources of an office's machines. If I don't get to the point of doing this I would be very interested to know/see when someone else does.

Conclusions / Evaluation

The next obvious step would be to actually get a real world example and start to deploy a system such as this within an office environment and see what happens. Asking a business to commit to this without a trail blazing company to prove the technology and effectiveness may be a little difficult. Grid/Distributed computing is very popular is some circles and has some large applications (BIONC, SETI@Home, Folding@Home, etc). I did not, however, find a smaller scale and simple system like this in my searches that could be rolled out within an office environment.

I created a basically free system using mostly open source software and tools available in almost any office. The technologies were basically demonstrated and show to perform and work as expected. Hopefully I have show that with not much work and with a very simple setup you can deploy an office grid computing system that is powerful, cheap, and scalable all at the same time.

Once a system is up and running there is almost no end to the amount of customisation and improvements you can make. For example statistics / benchmarking can easily be added showing the worth of such a system every day. New machines can be added quickly and easily as and when they arrive with upgrades to existing hardware bolstering your processing power.

I hope you've enjoyed reading this series of articles and its given you food for thought on running an office grid system. The solution presented here won't necessarily work in all situations but should be adaptable to allow you to get your data processing done using your own solution.

Please feel free to send me any comments, corrections, or improvements and I'll do my best to keep this article updated to match.

Kommentarer (3)

By Steven Lloyd Watkin , Saturday 28th November 2009 10:42 pm

My employer recently paid for a group of us developers to take the Zend Framework: Fundamentals course, here I'll summarise my thoughts and opinions on the course for others. For those looking to save time, here's my summary:

For developers who haven't had time to look at the Zend Framework this course (Zend Framework: Fundamentals) offers a good overall picture of the framework introducing you to the key areas and giving enough information in order to continue. For those who have spent time looking at the framework and have followed one or two tutorials this course does not offer much beyond.

Bakgrunn

I've been a PHP developer for around 5-6 years, and have started working with the Zend Framework on a component basis over the last 6 months. I've developed and/or been a developer on a couple of small Zend Framework MVC sites. I'll be honest, I haven't had a huge amount of exposure to other frameworks from a coding point of view but have spent several hours researching the project websites and evaluating them. The framework and the community surrounding Zend Framework it is quite exciting and there seem to be huge possibilities in where its going.

About the Course

The course is delivered over 9 two hour webex sessions (with a 10-minute break in the middle). The time is spent going through a set of slides provided by Zend with discussion at any time. You can use a microphone to talk to the instructor, but to be honest I didn't see anyone use anything more than the chat window. In addition a VMWare Ubuntu machine is provided that has example code and projects set up an a trial version of Zend Studio. The course leader talks to attendees either over an integrated VoIP solution, or you can dial in using one of the many worldwide dial in numbers.

During the course the material consists of a brief overview of the Framework and the MVC pattern before heading into a sample guestbook application. The discussion demonstrated bootstrapping, Zend_Application, Db Tables, Database access, Forms, Filtering, ACL, Validating, etc, etc. Basically covering all the topics you'd require to get a basic site up an running all the time giving you the tools to go and get more advanced in the framework (although this did amount to 'See the website' much of the time).

Time is given to code up some examples, and to develop the 'guestbook' and simple 'wiki' application. Personally I felt that providing the code or each app and then asking us to develop what was essentially a copy alongside didn't really provide a good learning experience. I would have preferred to develop an application similar, but not identical. to the example application with the benefit of having a guide to refer to. Alternatively building the applications from scratch with the demonstrator would of possibly led to more questions about why and how , thus giving a better understanding of the framework, after all you can look up specifics after the course.

The last lecture consisted of working on the wiki application with help/guidance from the instructor. After the course feedback was taken, it was emphasised several times through the course that Zend takes feedback very seriously, in fact apparently our version of the course was quite new. Some of the other developers in the company will be taking the course soon so it will be interesting to see if this has happened.

The course style was informal, allowed for feedback and collaboration between attendees and the instructor. The course leader was friendly, approachable (email addresses were shared for questions), and whilst his presentation from the slides was a bit shaky seemed fully competent in the framework. He was clearly someone who used the framework on a regular basis rather than someone who is taught to teach the course, I liked the 'real world' experience in that respect.

Overall Feeling

In some ways I found the course a waste of time, in others it was very handy. Hopefully I'll get my reasons across clearly, and maybe provide some food for thought or useful feedback (knowing me this is unlikely!).

For myself this course was aimed at too low a level. Having gone through the quickstart guide, read Rob Allen's Zend Framework in Action, and worked with the framework a little I didn't really get anything too much. I would of liked the course to pick up from the end of the quickstart and develop additional skills.

That said, the course title does clearly state “Zend Framework: Fundamentals ” and in that aspect the course achieves what it sets out to do. Other members of the development team that haven't spent the time looking into the framework finished each session with enthusiasm and asked questions which was really nice to see.

All was not lost, it was good to spend time confirming the basic details of the framework and get to ask a couple of questions in areas where I wasn't 100%. It was also time that I got to sit down each day and think about coding using the framework and future projects, something I wouldn't of been able to do otherwise (can you imagine your company agreeing to that? :) ). Last but not least you also get a nice certificate from Zend to say that you attended the course (albeit by email).

Zend Framework Certification

This was one question that kept coming to mind during the course, would it prepare me for the certification? The quick, easy is a resounding No . The course instructor was quite clear on that with the additional advice that for the certification you should really be using the framework on a day to day basis and feel very comfortable and confident in its usage and methodologies.

Oppsummering

Given everything I've written above, I'll summarise everything in two easy bullet points:

• New to Zend Framework: This course does exactly what you'd expect, it gives you a nice introduction to the framework and a good grounding on the basics from which you can build. The course seems to generate interest and enthusiasm for the framework amongst developers.
• Used the Zend Framework: While it was nice to shore up some of the very basics I felt the time, effort, and funds to take the course could of been better spent elsewhere. It will be nice to see Zend create a new higher level course to take developers to the next level – at least to the standard of certification and beyond. For that I would sign up immediately.