Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast
Results 46 to 60 of 76

Thread: Delphi Meetup bij Coolblue: Behind the Scenes Delphi - 29 november

  1. #46
    Met name omdat we de middleware niet (per se) in Delphi willen bouwen. Voor zover ik heb begrepen is kbmMW, net als DataSnap, een specifieke client-server implementatie, en niet iets dat je helpt om tegen zomaar elke REST server aan te praten.

    En eigenwijzigheid speelt natuurlijk altijd een grote rol.
    1+1=b

  2. #47
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,708
    Quote Originally Posted by GolezTrol View Post
    En eigenwijzigheid speelt natuurlijk altijd een grote rol.
    Wel apart... dat is niet echt een eigenschap die je van programmeurs zou verwachten.
    TMemoryLeak.Create(Nil);

  3. #48
    En eigenwijzigheid speelt natuurlijk altijd een grote rol.
    die is ook belangrijk. Met Erik hebben jullie ook een hele goede architect in huis. Wat jullie van je client framework lieten zien was ook erg knap.

    Ben benieuwd naar wat we morgen te zien krijgen en wie weet wat meer te horen van het server platform waar jullie uiteindelijk wel voor gekozen hebben.

  4. #49
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509
    ik hoop dat het een geslaagde avond was, ik heb op het laatste moment af moeten zeggen (ziek, niet in staat om te reizen). Iemand die een klein soort verslag kan geven ?
    (bv. waarom geen kbmMW ?)
    Erik

  5. #50
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,708
    Een kleine sfeerimpressie van ons bezoek bij Coolblue:
    Click image for larger version. 

Name:	20181129_211205_resized.jpg 
Views:	150 
Size:	93.5 KB 
ID:	7837
    Click image for larger version. 

Name:	20181129_211212_resized.jpg 
Views:	118 
Size:	89.4 KB 
ID:	7838
    Click image for larger version. 

Name:	20181129_211322_resized.jpg 
Views:	118 
Size:	97.5 KB 
ID:	7839
    Click image for larger version. 

Name:	20181129_211357_resized.jpg 
Views:	125 
Size:	81.2 KB 
ID:	7840
    Click image for larger version. 

Name:	20181129_212657_resized.jpg 
Views:	129 
Size:	97.6 KB 
ID:	7841
    Ik wil Embarcadero nog hartelijk danken voor de organisatie en de leuke sokken.
    Last edited by VideoRipper; 30-Nov-18 at 12:04.
    TMemoryLeak.Create(Nil);

  6. #51
    Het was allemaal heel erg netjes geregeld door CoolBlue en daarom een grote dank aan CoolBlue voor deze avond.
    Wat mij betreft had dit wel langer mogen duren :-)
    Daarnaast is het altijd zeer interessant om te horen hoe collega Delphi ontwikkelaars het aanpakken.
    Nederlandse Firebird Nieuwsgroep
    Hoe meer je weet, hoe meer je beseft hoe weinig je weet.

  7. #52
    het was een interessante avond, virtual interfaces lijkt interessant dus eens in gaan duiken.

    kbmMW is in de lezing niet ter sprake geweest Eric . Maar dat ze hun huidige pad hebben gekozen is heel logisch, zeker na de lezing van Erik. Ze hadden natuurlijk een enorme monoliet die gebouwd was in een ouderwetse c/s opzet, gelukkig wel op basis van een framework (dat van Erik Stok). Bijkomende uitdaging is dat ze aanpassingen moeten doen in een live omgeving die niet even een paar uur off line kan.

    Ik vond de oplossing zoals ze nu hebben bedacht ook niet verkeerd en op zijn Erik's was het mooi van een abstractie sausje voorzien, zodat je een redelijk generieke oplossing krijgt. Ze hebben voor hun client gekozen voor REST, op zich een prima keuze al verwacht ik dat ze daar op de lange termijn ook mee vast gaan lopen omdat responses te lang op zich laten wachten. Gevolg zou dan zijn dat je op je client met threads moet gaan werken of moet gaan pollen.

    Vroeg of laat zul je daar dus ook zaken als messagebussen gaan zien, of zaken zoals rabbit-mq.

    kbmmw is een platform wat ik vooral zie als een server omgeving (don't shoot me Kim ). Helemaal terecht is dat overigens niet omdat een hele hoop losse modules gewoon clientside (of zelfs los van middleware) kunnen worden gebruikt. Een van die dingen zijn bv de marshal en de-marshal zaken. Coolblue heeft er zelf iets voor gemaakt, kbmMW heeft het al een aantal jaren standaard in zich.

    Dat coolblue voor hun serverkant, het verplaatsen van pl/sql naar middleware, flexibel wil zijn is begrijpelijk. Door te kiezen voor "standaarden" zoals rest en rabbit-mq kun je je server bouwen in de taal waar je de mensen voor beschikbaar hebt. Voor de stukken in delphi is kbmMW een goede optie, al weet ik niet of ze al een delphi server framework hebben nu.

    Een uurtje is ook weinig voor een introductie in zo'n complexe omgeving. Compliment voor Coolblue, Erik en zijn team dat ze er open over durven zijn en ook gewoon vertellen over de hobbels die ze tegenkomen. Toch weer wat zaken om over na te denken, iets wat te weining gebeurt met al dat gescrum tegenwoordig.

    Jammer dat ik je niet even de hand kon schudden Eric. Naast een leuke avond ben je nu ook de Barnsten AKV-kit misgelopen . Maar we maken dat vast nog een keer goed op een volgende bijeenkomst.

  8. #53
    Senior Member Wok's Avatar
    Join Date
    Dec 2002
    Location
    Alkmaar
    Posts
    2,085
    Het was een leuke leerzame avond, al steeg een deel van de tweede presentatie voor mij net een stapje boven mijn kennis niveau uit,
    Ik heb inmiddels de pdf gedownload, en zal de komende tijd me hierin gaan verdiepen.

    Presentatie van Eric Stok over het hart van Coolbkue
    Presentatie van Michal Kulczycki over virtual Interfaces

    Helemaal top, alle credits voor iedereen die dit mogelijk gemaakt hebben.
    10.4.2, Delphi2010, of Lazarus 2.2.0

  9. #54
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509
    Dank voor jullie info, zeker ook interessant zijn de presentatie-pdf's !
    Ik had het erg op staan , maar als het lichaam het niet wil ...

    en wat betreft de AKV-kit: zolang ik niet weet wat er in zit, hoef ik niet jaloers te zijn
    Erik

  10. #55
    Om even een paar dingen uit Benno's post aan te kaarten:

    - Nee, we hebben geen Delphi server framework, maar dat is omdat we (vrijwel) geen webservices in Delphi hebben. De paar die we hebben (bijvoorbeeld genereren van de factuur-pdfs) hebben weinig baat bij zo'n framework. We hebben wel wat achtergrondprocessen in Delphi services, maar dat zijn gewoon Windows services. Daar hebben we ook wel een frameworkje voor, maar dat is niet zo spannend en ook weinig vernieuwd. De meeste REST API's worden tegenwoordig in C# geschreven, want die lui zijn weer minder goed in schermpjes bouwen.

    - Het marshalen doen we maar deels zelf. We hebben heel dapper geprobeerd om de standaard REST componenten van Delphi te gebruiken, in de hoop dat deze ook gaandeweg beter worden. We hebben daar vooral wat bij moeten hacken om met o.a. nullable types om te kunnen gaan. Die nullable types zelf zijn weer gebaseerd op de nullables uit Spring.

    - Op dit moment genereren we code voor het praten met de rest services. Dat wordt gegenereerd op basis van de beschikbare OpenAPI beschrijving (voorheen Swagger), van de service. De verwachting is dat we op termijn minder code hoeven te genereren, omdat we dit m.b.v. virtual interfaces veel generieker kunnen maken.

    - Message busses, zoals RabbitMQ en AWS SQS gebruiken we inderdaad al. Persoonlijk ben ik daar geen groot fan van, omdat mensen er vaak vanuit gaan dat deze systemen onfeilbaar en altijd up zijn, maar ook omdat het lastig is om te zien wat er nog in de queue staat, en wat er voorheen in stond. Een tabelletje met een state is wat transparanter, en asynchrone data tussen services kan je m.i. beter pullen dan pushen (en een MQ is beide). Maar er zijn zeker goede toepassingen, dus dat zullen we wel blijven gebruiken (en waarschijnlijk zelfs meer in de toekomst). We kijken gewoon per geval wat we denken dat het handigst is, en soms komen we daar na een paar maanden op terug en doen het alsnog anders.

    Verder

    Op de korte termijn moet het demo-project van Mike in deelbare staat zijn (dus o.a. niet rechtstreeks afhankelijk van onze database). T.z.t. zal ik dat ook hier delen.

    De Swagger/OpenAPI code generator waar Erik het over had moet op termijn ook open source worden, maar daar zit nog wat meer werk aan.
    1+1=b

  11. #56
    - Nee, we hebben geen Delphi server framework, maar dat is omdat we (vrijwel) geen webservices in Delphi hebben. De paar die we hebben (bijvoorbeeld genereren van de factuur-pdfs) hebben weinig baat bij zo'n framework. We hebben wel wat achtergrondprocessen in Delphi services, maar dat zijn gewoon Windows services. Daar hebben we ook wel een frameworkje voor, maar dat is niet zo spannend en ook weinig vernieuwd. De meeste REST API's worden tegenwoordig in C# geschreven, want die lui zijn weer minder goed in schermpjes bouwen.
    Een deel van die uitstap naar services is toch ook om jullie PL/SQL te gaan verplaatsen naar een middleware laag, of heb ik dat stukje fout begrepen?

  12. #57
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Heb al eens eerder gespeeld met de TVirtualInterface. Ik kan omgaan met de techniek en snap ongeveer wat ie doet.
    Wat ik niet heel goed begrijp aan het concept is waarom je een virtualinterface instantieert met een event. Bepaal je in het event wat er moet gebeuren?
    Waar zit de daadwerkelijke code die doet wat ie moet doen?
    Ik had er eigenlijk heen moeten gaan...

  13. #58
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    - Het marshalen doen we maar deels zelf. We hebben heel dapper geprobeerd om de standaard REST componenten van Delphi te gebruiken, in de hoop dat deze ook gaandeweg beter worden. We hebben daar vooral wat bij moeten hacken om met o.a. nullable types om te kunnen gaan. Die nullable types zelf zijn weer gebaseerd op de nullables uit Spring.
    Hoet stabiel is Delphi dan voor grote bedrijven als men geen gebruik kan maken van de standaard oplossing, die geboden wordt?
    Had Embarcardero niet iets voor jullie kunnen betekenen om toch het resultaat te krijgen, wat jullie wilden hebben?
    (Ik weet dat jullie team grootse dingen in staat zijn om dingen te omzeilen voor het juiste resultaat)
    Delphi is great. Lazarus is more powerfull

  14. #59
    Je blijft toch wel hameren op de standaard componenten van Delphi he John....

    Delphi is naar mijn mening juist groot geworden door de 3th party componenten, de community componentenbouwers (freeware en commercieel) en het gemak waarmee je componenten gebruikt.

    Volgens mij is er geen enkel bedrijf dat niet externe componenten of eigen afgeleides gebruikt en op zijn minst een basic eigen framework heeft. Dat is niet alleen met delphi zo maar ook met andere talen zoals C#. Talen zoals python, Go en ruby zijn juist populair geworden omdat je overal componenten vandaan kunt plukken (al heten ze dan geen componenten).

    Embarcadero, codegear, borland heeft ook geen goed trackrecord met nieuwe dingen. Ik denk ook dat de meeste enterprise gebruikers ook minstens 2 delphi versies achterlopen. Altium (een grote delphi gebruiker en maker van pcb ontwerpsoftware) draaide bv nog niet zo lang geleden nog op d2010.

  15. #60
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Wat mij opviel is het gebruik van de Devart componenten:
    - dbForge for Oracle
    - ODAC

    Dit vanwege de stateless verbinding naar de database.
    Delphi is great. Lazarus is more powerfull

Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •