Zondag, 21 december 2008
Een blog, jawel!
Trackbacks
Trackback-URI voor dit artikel
Geen Trackbacks
Reacties
Geeft reacties weer als
(Lineair | Samengevoegd)
DEVAREA nieuws :)
Beetje jammer inderdaad dat er niets meer over is, gelukkig zitten we nu bij een andere hoster. Laten we hopen dat het developen wat voorspoedig zal verlopen en dat we zo snel mogelijk weer een DEVAREA kunnen gebruiken hoe we dat gewend waren.
Beetje jammer inderdaad dat er niets meer over is, gelukkig zitten we nu bij een andere hoster. Laten we hopen dat het developen wat voorspoedig zal verlopen en dat we zo snel mogelijk weer een DEVAREA kunnen gebruiken hoe we dat gewend waren.
Wat is er dan beter aan PostgreSQL?
Leuk dat jullie terug zijn, ik hoop dat we weer snel DEVAREA kunnen gebruiken!
Leuk dat jullie terug zijn, ik hoop dat we weer snel DEVAREA kunnen gebruiken!
PostgreSQL houdt zich in tegenstelling tot MySQL wel aan de SQL standaard, en waar het uitbreidingen op de standaard implementeert wordt er voor een uitbreiding van de syntax gekozen, ipv bestaande standaardfuncties te overschrijven (bestaande functies overschrijven is wat MySQL dus doet). De performance is een andere factor. PostgreSQL is ontworpen om naast integriteitsbewaking ook nog eens gewoon snel te zijn. MySQL haalt zijn snelheid uit het feit dat er geen controles worden gedaan op de data. Maar het belangrijkste punt natuurlijk: MySQL vindt het leuk om je data te verpesten als het niet helemaal geschikt is voor een bepaalde kolom, en daar kom je pas achter als die data weer wordt teruggelezen. PostgreSQL geeft hier gewoon een foutmelding op.
PostgreSQL kan ook gewoon veel meer. Denk aan domains (user defined datatypen), goed ondersteunde stored procedures, rules en triggers, uitgebreid rechtensysteem etc etc. Het lijkt me dus logisch dat we hier voor een echte database kiezen en niet voor een systeem dat zich met de beste wil van de wereld nog geen database mag noemen. Een database definieert zich met ACID, terwijl MySQL eigenlijk niets van ACID goed of überhaupt implementeert.
PostgreSQL kan ook gewoon veel meer. Denk aan domains (user defined datatypen), goed ondersteunde stored procedures, rules en triggers, uitgebreid rechtensysteem etc etc. Het lijkt me dus logisch dat we hier voor een echte database kiezen en niet voor een systeem dat zich met de beste wil van de wereld nog geen database mag noemen. Een database definieert zich met ACID, terwijl MySQL eigenlijk niets van ACID goed of überhaupt implementeert.
Ow oké, wist ik niet :S. Mijn host heeft, zover ik weet, alleen MySQL.
Gelukkig hebben wij een host die zich bekommert om de wensen van de gebruikers. :)
1 correctie: Postgre houd zich inderdaad beter aan de SQL standaard dan MySQL, maar er zijn toch nog altijd een klein aantal fouten. Als voorbeeld:
SQL standaard: SELECT voornaam v
Postgre/MySQL versie: SELECT voornaam AS v
Hier moet wel bij gezegd worden dat de SQL standaard eigenlijk beide toelaat: via het keyword AS, en zonder.
Voorbeeld 2: hoofdletters: in postgre is SELECT NAAM hetzelfde als SELECT naam. Alle hoofdletters worden omgezet naar kleine letters, tenzij er quotes rond staan.
Hier moet ook bij vermeld worden dat het kleine aantal foutjes in Postgre ook in MySQL terug te vinden zijn! En ja, wat zijn de 2 fouten die in ken in Postgre tegenover de TIENTALLEN van MySQL?
Allemaal naar postgre dus ;)
SQL standaard: SELECT voornaam v
Postgre/MySQL versie: SELECT voornaam AS v
Hier moet wel bij gezegd worden dat de SQL standaard eigenlijk beide toelaat: via het keyword AS, en zonder.
Voorbeeld 2: hoofdletters: in postgre is SELECT NAAM hetzelfde als SELECT naam. Alle hoofdletters worden omgezet naar kleine letters, tenzij er quotes rond staan.
Hier moet ook bij vermeld worden dat het kleine aantal foutjes in Postgre ook in MySQL terug te vinden zijn! En ja, wat zijn de 2 fouten die in ken in Postgre tegenover de TIENTALLEN van MySQL?
Allemaal naar postgre dus ;)
Dit zijn opzich geen fouten, maar je moet het net even weten. Er zit nog een 3e fout bij: het gebruiken van COMMIT of ROLLBACK binnen stored functions is niet mogelijk. Het zijn al met al geen onoverkomenlijke problemen en dus niet de moeite waard om te noemen.
Leuk om te horen dat er al weer druk wordt gewerkt aan de nieuwe versie. Ik moet zeggen dat ik me inderdaad wel af begon te vragen wat er nu aan de hand was met devarea. Ik was zo'n lange down time niet gewend van devarea ;)
Het is anders de tweede keer dat dit gebeurd, en het is 2 keer gebeurd bij dezelfde host...
En om die reden heb ik de hosting overgenomen. Ik zal verder geen woorden meer vuil maken aan itrends, maar ik ben blij dat we het domein te pakken hebben gekregen.
Wat is eigenlijk de reden dat er gekozen wordt om een eigen framework op te zetten? Er zijn tegenwoordig legio keuzes voor frameworks in PHP, maar PHP programmeurs houden er schijnbaar van om het wiel meerdere malen uit te vinden?
Desalniettemin wens ik jullie heel veel succes met de wederopbouw van DEVAREA.
Desalniettemin wens ik jullie heel veel succes met de wederopbouw van DEVAREA.
Vrij simpel: om het wiel opnieuw uit te vinden. :-)
Zouden we bijvoorbeeld CodeIgniter gebruiken, of Zend Framework, of voor mijn part CakePHP, zouden we eerst hopen documentatie moeten doorlezen voordat we überhaupt weten hoe het werkt. Schrijven we het zelf, bepalen we '''zelf''' hoe de code werkt, hoe de code eruitziet, enzovoorts.
Zelf ben ik ook niet tevreden met alle frameworks, ze zijn of te gelimiteerd, of te smerig geprogrammeerd, of veel te uitgebreid. En soms wil ik gewoon een hele andere implementatie. :) We willen eigenlijk vooral een samenwerkingsproject worden voor Nederlandse PHP-ers, iedereen zal uiteindelijk toevoegingen kunnen doen aan de code, en zo het alleen maar groter en groter laten worden. Natuurlijk zal er een groep zijn die dit alles in de gaten houdt, aangezien we graag goede kwaliteit zien. ;)
Meer hierover zal ik binnenkort wel posten. ;)
Zouden we bijvoorbeeld CodeIgniter gebruiken, of Zend Framework, of voor mijn part CakePHP, zouden we eerst hopen documentatie moeten doorlezen voordat we überhaupt weten hoe het werkt. Schrijven we het zelf, bepalen we '''zelf''' hoe de code werkt, hoe de code eruitziet, enzovoorts.
Zelf ben ik ook niet tevreden met alle frameworks, ze zijn of te gelimiteerd, of te smerig geprogrammeerd, of veel te uitgebreid. En soms wil ik gewoon een hele andere implementatie. :) We willen eigenlijk vooral een samenwerkingsproject worden voor Nederlandse PHP-ers, iedereen zal uiteindelijk toevoegingen kunnen doen aan de code, en zo het alleen maar groter en groter laten worden. Natuurlijk zal er een groep zijn die dit alles in de gaten houdt, aangezien we graag goede kwaliteit zien. ;)
Meer hierover zal ik binnenkort wel posten. ;)
Voor mij persoonlijk?
Ik vind het makkelijker om in iets te werken dat ik zelf heb gemaakt, dat ik door en door ken. In bijvoorbeeld Zend Framework kan ik uren zoeken naar iets bepaald, terwijl als ik het zelf schrijf ik al weet wat ik nodig heb.
Voor het project?
- Als voorbeeld; Zend Framework houdt zich in de verste verte niet aan het MVC principe. Ja, je hebt een model, een view en een controller. Maar deze communiceren niet met elkaar zoals het zou moeten.
- Opnieuw als voorbeeld ZF; voor bepaalde zaken wordt je gewoon verplicht om het op de verkeerde plaats te doen. De formverwerking hoort niet thuis in de controller, maar in de model.
- Snelheid; met alle respect voor die gasten van ZF, maar ik denk dat het devarea team tot beter in staat, mede omdat wij met veel minder rekening moeten houden omdat het framework wordt geschreven met devarea in ons achterhoofd.
Ik vind het makkelijker om in iets te werken dat ik zelf heb gemaakt, dat ik door en door ken. In bijvoorbeeld Zend Framework kan ik uren zoeken naar iets bepaald, terwijl als ik het zelf schrijf ik al weet wat ik nodig heb.
Voor het project?
- Als voorbeeld; Zend Framework houdt zich in de verste verte niet aan het MVC principe. Ja, je hebt een model, een view en een controller. Maar deze communiceren niet met elkaar zoals het zou moeten.
- Opnieuw als voorbeeld ZF; voor bepaalde zaken wordt je gewoon verplicht om het op de verkeerde plaats te doen. De formverwerking hoort niet thuis in de controller, maar in de model.
- Snelheid; met alle respect voor die gasten van ZF, maar ik denk dat het devarea team tot beter in staat, mede omdat wij met veel minder rekening moeten houden omdat het framework wordt geschreven met devarea in ons achterhoofd.
Het verhaal rondom het framework is mij duidelijk en was eigen ook wel het antwoord wat ik had verwacht.
Het idee dat iedereen kan meewerken aan de code zie ik dan weer niet helemaal gebeuren, tenzij je mensen echt gestimuleerd krijgt. WMCity doet namelijk met hun nieuwe community precies hetzelfde, maar daar krijg ik echt het idee dat er vrij weinig door mensen bijgedragen wordt aan de ontwikkeling.
Tevens dwing je, met je keuze van je eigen framework, mensen om jouw framework te leren kennen in plaats van een standaard framework dat beter gedocumenteerd is en waar men misschien ook al wel ervaring mee heeft.
Ik zie nog wel wat haken en ogen aan dit verhaal, maar mits de juiste stimulans er is en je de juiste mensen kan krijgen dan kan het absoluut werken. Ik zal het project in ieder geval blijven volgen, maar dan meer vanuit mijn interesse in de organisatie en het project zelf, dan de geproduceerde code.
Succes mannen!
Het idee dat iedereen kan meewerken aan de code zie ik dan weer niet helemaal gebeuren, tenzij je mensen echt gestimuleerd krijgt. WMCity doet namelijk met hun nieuwe community precies hetzelfde, maar daar krijg ik echt het idee dat er vrij weinig door mensen bijgedragen wordt aan de ontwikkeling.
Tevens dwing je, met je keuze van je eigen framework, mensen om jouw framework te leren kennen in plaats van een standaard framework dat beter gedocumenteerd is en waar men misschien ook al wel ervaring mee heeft.
Ik zie nog wel wat haken en ogen aan dit verhaal, maar mits de juiste stimulans er is en je de juiste mensen kan krijgen dan kan het absoluut werken. Ik zal het project in ieder geval blijven volgen, maar dan meer vanuit mijn interesse in de organisatie en het project zelf, dan de geproduceerde code.
Succes mannen!
In de praktijk zullen er ook wel wat meer mensen dan Richard en ik in de code zitten.
En inderdaad, wat je zegt is waar. Iedereen die meewerkt in de code wordt door ons verplicht om zich in dit framework te verdiepen. Of toch niet?
Vanaf het begin kiezen wij duidelijk voor abstractie. Dat betekent dat de persoon die de views maakt, ook alleen maar de views zal maken, en zelfs geen toegang krijgt tot de rest. Daardoor moet die persoon (personen) maar een relatief klein deel van het framework doorgronden (eigenlijk bijna niets).
Verder, van een bestaand framework zal er inderdaad meer geschreven documentatie zijn. Maar ah, in ons framework kunnen wij veel makkelijker de coder voorthelpen omdat wij het toch al door en door kennen, terwijl we in een bestaand FW met zijn allen misschien een week mogen zoeken naar iets bepaald...
Opnieuw, het is een keuze, maar ik denk dat wij voor de juiste hebben gekozen - ondanks het feit dat het misschien meer tijd kost!
En inderdaad, wat je zegt is waar. Iedereen die meewerkt in de code wordt door ons verplicht om zich in dit framework te verdiepen. Of toch niet?
Vanaf het begin kiezen wij duidelijk voor abstractie. Dat betekent dat de persoon die de views maakt, ook alleen maar de views zal maken, en zelfs geen toegang krijgt tot de rest. Daardoor moet die persoon (personen) maar een relatief klein deel van het framework doorgronden (eigenlijk bijna niets).
Verder, van een bestaand framework zal er inderdaad meer geschreven documentatie zijn. Maar ah, in ons framework kunnen wij veel makkelijker de coder voorthelpen omdat wij het toch al door en door kennen, terwijl we in een bestaand FW met zijn allen misschien een week mogen zoeken naar iets bepaald...
Opnieuw, het is een keuze, maar ik denk dat wij voor de juiste hebben gekozen - ondanks het feit dat het misschien meer tijd kost!
Helemaal helder en duidelijk voor me. Het is ook positief om te zien dat deze keuzes ook daadwerkelijk goed doordacht zijn. Geen twijfel over mogelijk dat het dan wel goed moet komen. :)
Kalender
|
Juli '10 | |||||
| Ma | Di | Wo | Do | Vr | Za | Zo |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
Archief
Weblogbeheer
Statistieken
Meest recente artikel: 31-07-2009 11:29
13 artikelen geschreven
146 gegeven reacties