Valt wel mee eigenlijkquote:Op dinsdag 3 juli 2018 18:23 schreef FlippingCoin het volgende:
[..]
Krijg je dan 's avonds niet weer trek?
Ah ja is ook zo, ik ontbijt weer niet uitgebreid meestal.quote:Op dinsdag 3 juli 2018 18:25 schreef DevFreak het volgende:
[..]
Valt wel mee eigenlijk
Maar als je in de ochtend en tijdens de lunch zwaar eet heb je in de avond aan een niet te grote snack wel genoeg. Zit hier Pringoooals weg te kanen.
Ghehe, ik zei er bewust niet bij dat er dipsaus naast staatquote:Op dinsdag 3 juli 2018 18:25 schreef FlippingCoin het volgende:
[..]
Ah ja is ook zo, ik ontbijt weer niet uitgebreid meestal.![]()
Pringles zijn ook lekker.
Ik vind een singleton het meest overschatte en het meest misbruikte design pattern ever. Het is een simpel pattern en daardoor is het waarschijnlijk ook "populair" maar in tegenstelling tot wat veel mensen denken die net beginnen met OO is het slechts heel zelden nodig en vaak een keurslijf waar je later verstrikt in kan komen te zitten.quote:Op dinsdag 3 juli 2018 17:20 schreef FlippingCoin het volgende:
[ afbeelding ]
Wat vinden jullie van deze singleton oplossing? Ik vind die losse variable met de instantie die iedereen zo maar kan pakken niet zo netjes maar ik weet niet zo goed hoe ik dit moet oplossen.
Ik wil van mijn database class in Go een singleton maken, en een singleton factory is weer een overkill denk ik.
Oh ja die once.do functie wordt maar een keer uitgevoerd en is thread safe, wordt dus echt maar een keer uitgevoerd.
Komt hiervandaan. http://marcio.io/2015/07/singleton-pattern-in-go/
En in mijn geval, met een database resource is een singleton toch een prima pattern?quote:Op dinsdag 3 juli 2018 20:49 schreef Farenji het volgende:
[..]
Ik vind een singleton het meest overschatte en het meest misbruikte design pattern ever. Het is een simpel pattern en daardoor is het waarschijnlijk ook "populair" maar in tegenstelling tot wat veel mensen denken die net beginnen met OO is het slechts heel zelden nodig en vaak een keurslijf waar je later verstrikt in kan komen te zitten.
Ja? Heb je altijd maar 1 database dan?quote:Op dinsdag 3 juli 2018 20:50 schreef FlippingCoin het volgende:
[..]
En in mijn geval, met een database resource is een singleton toch een prima pattern?
Ja, en ik wil ook maar een verbinding met die database.quote:Op dinsdag 3 juli 2018 20:52 schreef Farenji het volgende:
[..]
Ja? Heb je altijd maar 1 database dan?
Dat wil je nu, maar morgen als je applicatie en/of db groeit en die ene connectie wordt een bottleneck, wat doe je dan? Of je wil misschien wel een connectie met een andere db maken, of misschien een extra connectie onder een andere user (bijv met andere rechten) en daar zit je dan met je singleton.quote:Op dinsdag 3 juli 2018 20:54 schreef FlippingCoin het volgende:
[..]
Ja, en ik wil ook maar een verbinding met die database.
Hmmm ja daar zeg je wel iets. In principe is het een micro service en zou die niet moeten groeien maar mogelijk is een singleton wel té beperkend, wat stel jij voor dan?quote:Op dinsdag 3 juli 2018 20:56 schreef Farenji het volgende:
[..]
Dat wil je nu, maar morgen als je applicatie en/of db groeit en die ene connectie wordt een bottleneck, wat doe je dan? Of je wil misschien wel een connectie met een andere db maken, of misschien een extra connectie onder een andere user (bijv met andere rechten) en daar zit je dan met je singleton.
Het max aantal connecties moet je niet in je applicatie regelen maar in je db server. Laat je db maar besluiten of die een nieuwe connectie maakt of een bestaande open connectie gebruikt. Dat is veel flexibeler. Je kan niet van te voren voorzien hoeveel en welke resources een app gaat gebruiken, dus dat wil je niet hardcoden maar flexibel houden.quote:Op dinsdag 3 juli 2018 20:58 schreef FlippingCoin het volgende:
[..]
Hmmm ja daar zeg je wel iets. In principe is het een micro service en zou die niet moeten groeien maar mogelijk is een singleton wel té beperkend, wat stel jij voor dan?
Oké zo heb ik het nooit aangepakt dan moet ik daar over lezen, en de applicatie op dat gebied zo dom als mogelijk houden?quote:Op dinsdag 3 juli 2018 21:02 schreef Farenji het volgende:
[..]
Het max aantal connecties moet je niet in je applicatie regelen maar in je db server. Laat je db maar besluiten of die een nieuwe connectie maakt of een bestaande open connectie gebruikt. Dat is veel flexibeler. Je kan niet van te voren voorzien hoeveel en welke resources een app gaat gebruiken, dus dat wil je niet hardcoden maar flexibel houden.
Leg de verantwoordelijkheden neer bij de partijen die daar het meeste verstand van hebben. Als ik een maaltijd bestel in een restaurant boeit het me niks hoeveel mensen er in de keuken staan en hoe groot de pannen zijn, zolang het eten maar lekker en betaalbaar is en ik niet te lang hoef te wachten.quote:Op dinsdag 3 juli 2018 21:04 schreef FlippingCoin het volgende:
[..]
Oké zo heb ik het nooit aangepakt dan moet ik daar over lezen, en de applicatie op dat gebied zo dom als mogelijk houden?
Cool thanks, dan ga ik daar naar zoeken.quote:Op dinsdag 3 juli 2018 21:11 schreef Farenji het volgende:
[..]
Leg de verantwoordelijkheden neer bij de partijen die daar het meeste verstand van hebben. Als ik een maaltijd bestel in een restaurant boeit het me niks hoeveel mensen er in de keuken staan en hoe groot de pannen zijn, zolang het eten maar lekker en betaalbaar is en ik niet te lang hoef te wachten.
Seperation of Concerns, zoals Robert C. Martin het noemt.quote:Op dinsdag 3 juli 2018 21:13 schreef FlippingCoin het volgende:
[..]
Cool thanks, dan ga ik daar naar zoeken.
Jaaa binnen de programmatuur probeer ik dat al zo goed mogelijk toe te passen en met micro services ook al wat daarbuiten maar had er met databases nooit aan gedacht, en moet ook eerlijk zeggen dat ik niet weet waar ik dat zou moeten doen nu maar dat kan ik wel vinden.quote:Op dinsdag 3 juli 2018 21:53 schreef DevFreak het volgende:
[..]
Seperation of Concerns, zoals Robert C. Martin het noemt.
Je moet je geen zorgen maken over dingen die nog geen probleem zijn. In een vroeg stadium het aantal db connecties (en je schaalbaarheid) zo drastisch beperken uit performance overwegingen lijkt me een schoolvoorbeeld van "premature optimization" en dat is volgens Donald Knuth "the root of all evil".quote:Op dinsdag 3 juli 2018 22:20 schreef FlippingCoin het volgende:
[..]
Jaaa binnen de programmatuur probeer ik dat al zo goed mogelijk toe te passen en met micro services ook al wat daarbuiten maar had er met databases nooit aan gedacht, en moet ook eerlijk zeggen dat ik niet weet waar ik dat zou moeten doen nu maar dat kan ik wel vinden.![]()
Ben niet zo'n database expert.
Je db is helemaal niet kritiek, zeker niet bij een microservice dus hoef je dat ook niet te optimaliseren. Pas als je db server uit het geheugen loopt of de boel heel traag wordt moet je misschien eens gaan denken aan optimalisatie op dat gebied, maar waarschijnlijk is de oplossing dan eerder het profilen en verbeteren van je queries, of het upgraden van je server, dan het beperken van het aantal connecties.quote:"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
Oké cool dus if it aint broke dont fix it.quote:Op dinsdag 3 juli 2018 22:51 schreef Farenji het volgende:
[..]
Je moet je geen zorgen maken over dingen die nog geen probleem zijn. In een vroeg stadium het aantal db connecties (en je schaalbaarheid) zo drastisch beperken uit performance overwegingen lijkt me een schoolvoorbeeld van "premature optimization" en dat is volgens Donald Knuth "the root of all evil".
[..]
Je db is helemaal niet kritiek, zeker niet bij een microservice dus hoef je dat ook niet te optimaliseren. Pas als je db server uit het geheugen loopt of de boel heel traag wordt moet je misschien eens gaan denken aan optimalisatie op dat gebied, maar waarschijnlijk is de oplossing dan eerder het profilen en verbeteren van je queries, of het upgraden van je server, dan het beperken van het aantal connecties.
Hierop terugkomend.quote:Op dinsdag 3 juli 2018 18:15 schreef DevFreak het volgende:
[..]
Inderdaad, want Google heeft als motivatie naar voren gebracht dat ze irritaties uit andere talen op wilden lossen...
Mocht je er achter komen wat de reden is, deel het dan met ons
Ik moet je eerlijk bekennen dat dit me niet heel veel zegt allemaal.quote:Op dinsdag 3 juli 2018 22:59 schreef FlippingCoin het volgende:
[..]
Hierop terugkomend.
Komt voort uit eenvoud behouden in combinatie van kleine packages, als je een attribuut of methode niet wilt gebruiken gebruik deze dan niet.
Door de kleine packages heb je gelijk herbruikbaardere componenten.
Ongeveer volgens mij. Een go package is meestal niet zo groot op de main package na. Als ik bijvoorbeeld een boom datastructuur zou maken in go, plaats ik deze in een package en ook gelijk in een eigen repository en kan ik die makkelijk hergebruiken. In een andere project kan ik die dan direct uit bijvoorbeeld github importeren.quote:Op donderdag 5 juli 2018 14:18 schreef DevFreak het volgende:
[..]
Ik moet je eerlijk bekennen dat dit me niet heel veel zegt allemaal.
Het klinkt een beetje als Java packages, of is dat weer iets heel anders?
Leukde dingen zijn dat ja.quote:Op woensdag 4 juli 2018 23:10 schreef cablegunmaster het volgende:
Vandaag een leuk issue met een Data Transfer Object de functie .clone() op uitgevoerd en dan omdat het als base werd gebruikt voor meerdere Data Transfer Objects waren de pointers in het eerste DTO object allemaal hetzelfde.
Dit kwam omdat de variabele die de gedeelde pointer hadden maar een enkele keer ooit zijn aangemaakt bv: "List<> stringArray = new ArrayList();" bovenaan in de DTO.
Om daar maar eens achter zien te komen , waarom er opeens aparte waarden in de stringArray stonden .
Nice.quote:Op donderdag 5 juli 2018 12:05 schreef Bosbeetle het volgende:
Als oefening toch maar even mijn evo class generic gemaaktlangzaam leren is goed.
Alleen moet ik nu in de klasse blijven testen wat voor type het is want een kleur evolueer je anders een integer natuurlijk.
Cool klinkt goed.quote:Op donderdag 5 juli 2018 14:21 schreef DevFreak het volgende:
Maarre... Boom yeah!
Net de laatste bugs uit mijn project gevist en een nieuwe VPS besteld met goede specs. Met 1000 GB opslagruimte moeten we denk ik wel een tijdje vooruit kunnen.![]()
Ik heb uiteindelijk gekozen voor een afsplitsing als het gaat om de codebase. Ik heb een basale image uploader voor FOK! gemaakt en de code voor mijn andere grotere project leeft op zichzelf.
Vanmiddag of morgen de boel migreren en dan gaan we echt bčtastatus in.
Geen idee nog, in eerste instantie alleen een website met hotlinkverbod buiten FOKquote:Op donderdag 5 juli 2018 15:10 schreef FlippingCoin het volgende:
[..]
Cool klinkt goed.
Gaat die ook in FOK! zelf komen?Of is dat juridisch niet te doen.
Ja is ook zo, maar omdat Danny zo bang was voor dikke claims.quote:Op donderdag 5 juli 2018 15:36 schreef DevFreak het volgende:
[..]
Geen idee nog, in eerste instantie alleen een website met hotlinkverbod buiten FOK
Ik weet verder niet hoe de toekomst eruit gaat zien voor de website. Zullen misschien nog wat extra features bij komen, maar een echte integratie in FOK zou misschien leuk zijn.
Verder ben ik gewoon een hobbyende particulier, ik zet gewoon die website neer en als iemand wat te zeiken heeft kunnen ze een DMCA claim indienen, dan ga ik er achteraan...
Misschien dat over een tijd mee ga ontwikkelen aan FOK als er behoefte aan is en ik de tijd heb naast mijn werk. Even kijken hoe het allemaal gaat lopen.
| Forum Opties | |
|---|---|
| Forumhop: | |
| Hop naar: | |