18 juni Amsterdam: meeting met David I

[Marcel]

http://www.barnsten.com/events-agenda.aspx?item=128
Op 18 juni is er in Amsterdam een meeting met David I. NLDelphi is uitgenodigd om daarbij aanwezig te zijn en uiteraard ben jij ook uitgenodigd.


We krijgen de mogelijkheid om David I alle vragen te stellen over Delphi, Codegear en de Embarcadero/CodeGear aankondiging. Verder staat er op de agenda:

• The implications of the Embarcadero/CodeGear announcement


• Software Archeology


• Developer UML


• Database programming


• Web 2.0 development

Let op dat je je even moet inschrijven bij Barnsten op de website ..

[jkuiper]

Meteen 2 ingeschreven. Bedankt.

[Marcel]

Wel even een NLDelphi vlag op je wang tekenen ter herkenning he

[jkuiper]

Even een klein verslagje omtrend de meeting met David I.

De zaal was niet erg vol. Ik had eigenlijk verwacht dat er geen plek meer zou zijn. David schijnt toch de Delphi persoon te zijn als het om development gaat maar blijkbaar niet "populair" genoeg.
Wat ik ook had verwacht is dat het een technische sessie zal worden, maar bleek niet echt het geval te zijn, wat volgens mijn gevoel niet bij iedereen niet in goede aarde viel. Maar dat was min gevoel en kan het mis hebben.

Waar is over gepraat
Per 1 juli is het een feit dat codegear wordt ingelijft bij Embarcadero, maar blijft zijn naam houden.
Verder was het een beetje over produkten die codegear levert; Delphi, Ruby, .net, Delphi voor PHP en C. Men hoopt op een goede samenwerking.
David heeft zich verontschiuldigd dat de VCL (basis) van Delphi een beetje is verslonst. Vanaf Delphi is er weinig tot niets aan gedaan (neem alleen al de dbgrid waar geen textveld of afbeelding getoond kan worden). Codegear gaat op korte termijn deze componenten flink opveizelen. Wat ze precies gaan doen is nog niet bekend. Behalve dat ze allemaal wel op basis van UNICODE worden 'enhanced'.
UNICODE is in de volgende upgrade een feit (TIBURON versie). In de zaal was dan de grote vraagstelling: Hoe zit het met de 3rd party componenten?
Er werd n.l. gesuggereerd dat devexpress zijn componenten niet gaat ombouwen naar UNICODE, wat in tegenstelling is van dit bericht van sevensteps. Daarom durfen een aantal niet te gaan overstappen c.q. upgraden naar release 2008.

Er zijn een tweetal demootjes gegeven: DBEXPRESS 4.0 en intraweb. Leuk, maar de demo's wilden niet echt ( geen administrator rechten , ik weet het niet). DBEXPRESS ondersteunt geen FIREBIRD en zal daar ook niet aan beginnen. Jammer, niet iedereen heeft een enterprise versie en maakt gebruik van de dure database providers en 'pissen' daar toch echt naast. Terwijl CODEGEAR toch wel wil dat iedereen gebruik gaat maken vanwege zijn uniformiteit.

Er werd veel gesproken over platform independence, maar dat sloeg niet op Delphi win32. Kylix is in een hoekje gezet vanwege de complexiteit tussen de OS'sen (windows en linux) en door de separatie van Borland en Godegear waren er ook te weinig ontwikkelaars. De reden waarom Codegear eigenlijk naar .Net is gegaan is omdat Heel Noord Amerika in de ban is van .NET. In de rest van de wereld speelt het minder en daar hoeft Codegear dan ook een graantje van mee te nemen. Voorlopig wordt de MAC en Linux / Unix niet van een delphi compiler voorzien. Wel is men druk bezig om een 64 bits versie op de markt te brengen. De datum is ongeveer januari 2009 maar pin Codegear daar niet aan vast.

Kortom, ik had eigenlijk meer verwacht over de technische aspecten van de volgende releasen.

Wat ook leuk was, is dat ik eindelijk een gezicht zag van een van de NLDelphi members. En dat was natuurlijk Marcel, de beheerder van NLDelphi. Het is altijd leuk om te zien met wie je eigenlijk mee correspondeert. Er was nog iemand, maar ben zijn naam vergeten. Eigenlijk jammer dat er niet meer NLDelphi leden waren, maar je weet nooit wat de toekomst zal brengen.

Zo, opgeschreven wat ik nog kon herinneren. Ik hoop dat het een betje duidelijk is voor degene die er niet ( maar mischien heel graag wilden ) zijn geweest.

John

[GolezTrol]

Hé, ik ben bang dat ik deze aankondiging gemist heb. Nou ja, als ik het zo lees, dan heb ik inhoudelijk niet zoveel gemist En hoe Marcel en DavidI eruit zien weet ik al

In ieder geval bedankt voor de verslaggeving, John!

[Marcel]

Uiteraard hebben we uitgebreid gepraat over de Embarcadero overname en de gevolgen daarvan. Ik vind het persoonlijk goed nieuws dat de naam CodeGear blijft en zelfs wordt uitgebreid met het broertje DatabaseGear. Helaas was het (beter bekkende) domein DataGear al vergeven en vroeg de huidige eigenaar er net even teveel voor.

Verder lijkt het mij van groot belang dat Embarcadero een club van ontwikkelaars is waardoor er eindelijk weer een management boven Delphi staat dat weet wat programmeren is, in plaats van een management dat vooral weet hoe grafieken in Excel eruit zien.

David I schetste wat leuke toekomstmogelijkheden die het gevolg zouden kunnen zijn van de samengang, denk aan het volledig integreren van je datamodel in de IDE waardoor je Code Insight op SQL kunt gaan verwachten, in de IDE debuggen van stored procedures, of een breakpoint zetten op een trigger in je database. Maar bijvoorbeeld ook (en dat spreekt veel database ontwikkelaars aan denk ik) het deployen van een datamodel vanuit je project. Dus een veel beter beheer van nieuwe velden, gewijzigde velden en het syncroniseren van die wijzigingen tussen je project en de database. Maar David heeft ook benadrukt dat er ook zeker een Delphi zonder database blijft bestaan. Je hoeft geen database te installeren om een Notepad te programmeren.

Zoals bekend is de overname (samengaan, ...) per 1 juli een feit, dat is ook de reden dat we vandaag nog gewoon "CodeGear from Borland" op de borden zagen staan. Het zal ook niet zo zijn dat op 1 juli opeens alles anders wordt. De roadmaps voor beide kanten (Embarcadero en CodeGear) zullen voor dit jaar niet ingrijpend gewijzigd gaan worden. Pas als deze roadmaps gerealiseerd zijn zullen nieuwe roadmaps gaan laten zien wat de samenwerking gaat brengen. De planning voor de volgende Delphi versie eind dit jaar blijft dus gewoon staan.

We hebben overigens al wel wat leuke marketing beelden verzonnen van een aanmerend Delphi schip aan de kade (embarque = aanmeren), dus misschien moeten we daar nog even snel patent op aanvragen.

De presentaties waren niet allemaal nieuw, maar dat hoeft ook niet natuurlijk. Het was leuk om even bij te praten en luisteren over de overname en alvast wat nieuwe dingen te horen die we in de toekomst kunnen gaan verwachten. En natuurlijk is het altijd leuk om Delphi collega's te ontmoeten!

Dus dankjewel David en dankjewel Barnsten voor de organisatie!

[rik.osstyn]

Codegear gaat op korte termijn deze componenten flink opveizelen

Ik denk dat er nog weinig programmeurs ( in de profesionele wereld ) nog de originele VCL-componenten gebruikt, maar ze meestal vervangen door 3th party-componenten ( DevExpress, Reportbuilder, ... zijn maar een paar, maar zeker niet de enige voorbeelden).

De vraag blijft natuurlijk wat je nog aan een compiler ( en een omgeving ) kunt toevoegen wat je nog niet hebt ( en wel zou kunnen gebruiken ) zonder er een echte ( onbetaalbare ) mastodont van te maken. In een van de pollings stond Delphi 7 nog altijd als één van de populairste versies, en blijkbaar ook niet zonder reden.

[Marcel]

Helaas was ik mijn camera vergeten, maar gelukkig was Johan Parent van de SDN zo vriendelijk om een aantal foto's op te sturen. Dus bij deze: de foto's.

[GolezTrol]

Ik zou persoonlijk wel blij zijn met een opvijzeling van die componenten. Nu gebruik ik inderdaad vaak 3rd party componenten, maar dat is vooral uit nood. Als de Delphi componenten alles kunnen wat ik wil, dan hoef ik niet persé andere componenten te gebruiken natuurlijk. Waar ze alleen wel voor moeten waken, is dat die componenten niet te zwaar gaan worden, of dat er in ieder geval een lichtere variant beschikbaar is. Het louter usen van een enkele DevExpress uinit levert je al snel een executable van 1 Mb of meer op. Het moet niet zo zijn dat nieuwe Delphi applicaties daar straks ook al in de buurt komen als je een enkele (DB)edit op een form zet.

[marcov]

Hetzelfde geldt voor utility units als strutils, dateutils, convutils etc. Hoe minder 3rd party zut, hoe meer standarizatie

[rik.osstyn]

Zoals hoger vermeld gaan we uiteraard enkele uitersten gaan vergelijken: de DbGrid verso de cxGrid en een QuickReports tov een Reportbuilder. Een beetje een vergelijking tussen een bromfiets en een vrachtwagen: op het moment van de omstandigheden kun je pas beslissen wat je het beste gebruikt. Ik vermoed dat de nieuwe componenten er ergens gaan tussen liggen.

Vergeet ook niet dat de toepassingen pas echt zwaar worden als je begint te ‘mixen’: een grid van DevExpress, een planner van TMF, een knopje van Tori, een rapportje van Reportbuilder, …

Uiteindelijk zwengelt je eigen visueel framework de grootte van je EXE ook een groot stuk aan, tenminste dan in de kleinere programma’s, in grotere programma’s het het gebruik van een dergelijke framework eerder voordelig.

Persoonlijk gebruik ik de native componenten van Delphi enkel in kleinere en hobby-toepassingen. Ik bedoel niet dat ze niet goed zijn, maar gezien de gestelde eisen scoren de meeste van de native componenten ( zoals een TdbGrid, TActionBar, TClientDataset, … ) gewoon ver van voldoende.

Tenslotte moet je ook de rekening maken dat een Delphi 2007 ook een serieus stuk zwaarder draait dan bijvoorbeeld een Delphi 7. Waar deze laatste ergens rond de 100 Mb RAM in beslag naam, slurpt Delphi 2007 toch gemakkelijk een 2 Gb aan RAM op. Dit maakt Delphi 2007 natuurlijk niet slechter, maar het is gewoon een feit waar je mee moet rekening houden.

[Marcel]

2 Gb nog wel, het wordt steeds meer, zelfs zonder dat er nieuwe versies van Delphi komen

Inderdaad, met name de visuele componenten mogen een opfrisbeurt krijgen. Maar er zal nooit een Delphi zijn die out of the box meteen doet wat je wilt. Zoveel mensen, zoveel meningen en dat krijg je nooit in één Delphi samengevat. En kijk hier op het forum maar eens wat we er dan vervolgens zelf nog eens bij programmeren. Maar de VCL is altijd één van de speerpunten van Delphi geweest, om dat zo te houden mag het allemaal wat moderner.

[GolezTrol]

Slurpte Delphi 2007 maar 2Gb op, dat zou het misschien werken. Maar toen ik gisteren probeerde een hoop forms te openen, bleef het geheugengebruik steken op iets meer dan 200 Mb, maar kreeg ik al wel foutmeldingen.

Overigens hetzelfde verhaal als in Delphi 7. Je hebt 200 forms. Je opent er 10 of 20, het geheugengebruik stijgt.. Je geeft ze vrij, geheugengebruik blijft gelijk. Je opent er weer 10 en het stijgt weer, net zolang totdat je na een form of 150 een foutmelding krijgt. Blijkbaar hebben ze dat in al die tussenliggende versies nog niet opgelost, of is er nog een soort van 'power close', waarmee je niet alleen de code editor sluit, maar ook echt het form unload?

[Handsaeme]

Zoveel mensen, zoveel meningen en dat krijg je nooit in één Delphi samengevat

Ik zie de VCL van Delphi als een Zwitsers zakmes: Je kunt er ongeveer alles mee doen, maar voor elk component bestaat er iets beters ...

[GolezTrol]

Mooie vergelijking