abonnement bol.com Unibet Coolblue
  zaterdag 4 oktober 2014 @ 20:08:02 #151
91039 mstx
2x1/2 = 1/2 x 1/2
pi_145194458
quote:
0s.gif Op zaterdag 4 oktober 2014 20:04 schreef Rockfire het volgende:

[..]

Ik heb het al degelijk wel eens meegemaakt. Switchen van database (van MySQL naar Postgres) en helaas was er geen gebruik gemaakt van PDO -O-
Ja ok, maar hoe zit dat dan met de queries zelf? Moet je dan niet alsnog bepaalde syntax zoals LIMIT...OFFSET aanpassen voor postgres? :?
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_145194505
quote:
0s.gif Op zaterdag 4 oktober 2014 20:08 schreef mstx het volgende:

[..]

Ja ok, maar hoe zit dat dan met de queries zelf? Moet je dan niet alsnog bepaalde syntax zoals LIMIT...OFFSET aanpassen voor postgres? :?
Jawel, maar als dat alles is is het veel minder werk dan ook nog de code ombouwen naar PDO-gebruik
------___------ 53
----.(___).---- 42
---(o\_!_/o)---
  zaterdag 4 oktober 2014 @ 20:13:10 #153
91039 mstx
2x1/2 = 1/2 x 1/2
pi_145194617
quote:
0s.gif Op zaterdag 4 oktober 2014 20:09 schreef Rockfire het volgende:

[..]

Jawel, maar als dat alles is is het veel minder werk dan ook nog de code ombouwen naar PDO-gebruik
In principe heb je gelijk, maar het ligt er ook aan hoe de applicatie is opgebouwd. Ik maak nu zelf gebruik van mysqli maar ik zou het in een paar minuten kunnen ombouwen naar PDO of iets anders omdat ik het gewoon in een database-classje heb zitten dus ik hoef maar een paar functies aan te passen. :Y
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
  zaterdag 4 oktober 2014 @ 20:28:28 #154
187069 slacker_nl
Sicko pur sang
pi_145195072
quote:
0s.gif Op zaterdag 4 oktober 2014 20:08 schreef mstx het volgende:

[..]

Ja ok, maar hoe zit dat dan met de queries zelf? Moet je dan niet alsnog bepaalde syntax zoals LIMIT...OFFSET aanpassen voor postgres? :?
Dat regelt de ORM voor ons. Whieeee.
In theory there is no difference between theory and practice. In practice there is.
pi_145210094
quote:
14s.gif Op donderdag 2 oktober 2014 21:55 schreef KomtTijd... het volgende:
InnoDB tabellen zou je als het goed is niet moeten kunnen kopiëren door de bestanden in het filesystem te kopiëren. Althans, misschien kan het goed gaan maar het wordt uitdrukkelijk afgeraden en niet ondersteund.
Tot op heden geen probleem, maar die kunnen nog komen hoor :D
Just say hi!
pi_145278387
:P Gewoon even omdat ik graag van input van anderen hou,

Hoe zouden jullie de volgende situatie aanpakken;

Een groothandel met een ~10,000 klanten die regelmatig wat bestellen uit een assortiment van 60,000 producten die zijn onderverdeeld in ongeveer 150 categorieën.

Waarbij er per klant/inkoopgroep korting gegeven kan worden complete groepen, individuele producten, staffelkorting, uitzonderingen binnen groepen waarop geen korting gegeven mag worden, actie periodes waarvoor een andere prijs geldt, kortingen vanaf een bepaald bedrag en kortingen die zowel als een prijsafspraak of als een percentage kunnen worden gegeven en combinaties hiertussen.

Dit werkt op dit moment allemaal nog "on the fly" maar ik merk zelf dat de performance wanneer bijvoorbeeld gechecked moet worden op staffelkortingen die gegeven worden op een combinatie van een merk en een groep niet is wat het zou moeten zijn.

Is het een gek idee om kortingen voor een klant op het moment van het aanmaken van een regel,en bij het wijzigen / aanmaken van een product wordt gecontroleerd of er klanten zijn die in aanmerkingen komen voor korting. op te slaan in een database, zodat deze berekeningen niet constant in de winkelwagen, bij wijze van hoeven plaats te vinden?
pi_145285025
Ik zou eerst eens uitzoeken welke queries zo lang duren en waarom, en of je daar iets aan kunt optimaliseren.
pi_145285575
quote:
19s.gif Op maandag 6 oktober 2014 23:22 schreef TwenteFC het volgende:
:P Gewoon even omdat ik graag van input van anderen hou,

Hoe zouden jullie de volgende situatie aanpakken;

Een groothandel met een ~10,000 klanten die regelmatig wat bestellen uit een assortiment van 60,000 producten die zijn onderverdeeld in ongeveer 150 categorieën.

Waarbij er per klant/inkoopgroep korting gegeven kan worden complete groepen, individuele producten, staffelkorting, uitzonderingen binnen groepen waarop geen korting gegeven mag worden, actie periodes waarvoor een andere prijs geldt, kortingen vanaf een bepaald bedrag en kortingen die zowel als een prijsafspraak of als een percentage kunnen worden gegeven en combinaties hiertussen.

Dit werkt op dit moment allemaal nog "on the fly" maar ik merk zelf dat de performance wanneer bijvoorbeeld gechecked moet worden op staffelkortingen die gegeven worden op een combinatie van een merk en een groep niet is wat het zou moeten zijn.

Is het een gek idee om kortingen voor een klant op het moment van het aanmaken van een regel,en bij het wijzigen / aanmaken van een product wordt gecontroleerd of er klanten zijn die in aanmerkingen komen voor korting. op te slaan in een database, zodat deze berekeningen niet constant in de winkelwagen, bij wijze van hoeven plaats te vinden?
Zoals gezegd, kijk eerst waar de bottleneck precies ligt. Alles in MySql proppen is ook niet ideaal, zeker niet als je later besluit om nog eens van Database technologie te wisselen. Het zou bijvoorbeeld ook best kunnen zijn dat het handiger is om hier een back-end service voor in te richten. PHP is niet bepaald optimaal voor zware berekeningen en daarbij kun je met een dergelijke oplossing gebruik maken van caching. Bovendien is het non-blocking, oftewel, de gebruiker hoeft er niet op te wachten. Een andere oplossingsrichting is bijvoorbeeld het gebruik maken van web workers om in de browser asynchroon iets te laten uitvoeren.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_145285887
Sowieso, mocht je voor 1 of 2 berekeningen een pagina op moeten houden, kun je die beter als asynchrone request uitvoeren.
pi_145301387
quote:
19s.gif Op maandag 6 oktober 2014 23:22 schreef TwenteFC het volgende:
:P Gewoon even omdat ik graag van input van anderen hou,

Hoe zouden jullie de volgende situatie aanpakken;

Een groothandel met een ~10,000 klanten die regelmatig wat bestellen uit een assortiment van 60,000 producten die zijn onderverdeeld in ongeveer 150 categorieën.

Waarbij er per klant/inkoopgroep korting gegeven kan worden complete groepen, individuele producten, staffelkorting, uitzonderingen binnen groepen waarop geen korting gegeven mag worden, actie periodes waarvoor een andere prijs geldt, kortingen vanaf een bepaald bedrag en kortingen die zowel als een prijsafspraak of als een percentage kunnen worden gegeven en combinaties hiertussen.

Dit werkt op dit moment allemaal nog "on the fly" maar ik merk zelf dat de performance wanneer bijvoorbeeld gechecked moet worden op staffelkortingen die gegeven worden op een combinatie van een merk en een groep niet is wat het zou moeten zijn.

Is het een gek idee om kortingen voor een klant op het moment van het aanmaken van een regel,en bij het wijzigen / aanmaken van een product wordt gecontroleerd of er klanten zijn die in aanmerkingen komen voor korting. op te slaan in een database, zodat deze berekeningen niet constant in de winkelwagen, bij wijze van hoeven plaats te vinden?
Als eerste zou ik uitzoeken waarom die berekeningen zo lang duren en of er niet wat te optimaliseren valt.

Daarnaast zou ik zeker de resultaten van berekeningen in een cache opslaan (in de sessie van de klant, welke in een file, db, memcached, etc... staat). Dan alleen bij wijzigingen die invloed hebben op de berekening dingen updaten.
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
  dinsdag 7 oktober 2014 @ 19:27:02 #161
355592 Djurres
Knowledge, Fuck it.
pi_145304514
quote:
0s.gif Op zaterdag 4 oktober 2014 20:04 schreef Rockfire het volgende:

[..]

Ik heb het al degelijk wel eens meegemaakt. Switchen van database (van MySQL naar Postgres) en helaas was er geen gebruik gemaakt van PDO -O-
Das wel balen, anders had het in principe alleen een nieuwe handler gekost.
Tadumtiedum.
pi_145326795
Ik ben aan het stoeien met een 'upload' module voor CMSMS. Ik wil de naamgeving van de bestanden aanpassen aan wat de user aangeeft. Dat kan met onderstaande code:

1<p>{$prompt_destname} <input type="text" name="{$actionid}input_destname" value="" size="40" maxlength="255"/></p>

Ik wil aan de naamgeving een timestamp toevoegen. Hoe kan ik dat het beste oplossen?
Feitelijk moet de input value gecombineerd worden met
1{current_date format="%y%m%d%T"}
pi_145327058
uit de documentatie van de uploads module:

quote:
(optional) prefix="0" - Een boolean die aangeeft of bestandsnamen een prefix moeten hebben
(optional) prefix_feu="0" - Een boolean parameter die aangeeft dat de prefix van de huidige auteur gebruikt moet worden of, als deze niet opgegeven is, de prefix van de huidige tijd (in dechex formaat)
Misschien is de engelse helppage wat duidelijker, mocht je er niet uit komen.

[ Bericht 8% gewijzigd door KomtTijd... op 08-10-2014 13:18:55 ]
  woensdag 8 oktober 2014 @ 13:34:39 #164
187069 slacker_nl
Sicko pur sang
pi_145327857
quote:
14s.gif Op woensdag 8 oktober 2014 13:12 schreef KomtTijd... het volgende:
uit de documentatie van de uploads module:

[..]

Misschien is de engelse helppage wat duidelijker, mocht je er niet uit komen.
Noem het dan gewoon has_prefix, prefix_author, dan is het in een keer duidelijk. Naamgeving van dingen.. blergh.
In theory there is no difference between theory and practice. In practice there is.
pi_145327942
Ik denk eerder dat de omschrijvingen gewoon brak vertaald zijn, geen zin om het weer te checken gezien dat met 10 seconden trial-and-error ook wel vast te stellen valt.
pi_145328437
Bedankt voor de feedback. Nu weet ik in ieder geval in welke hoek ik het moet zoeken.

Juist die helppagina vind ik nogal verwarrend. De code heb ik toegevoegd aan de template voor het formulier (bovenstaande code) dat werkte niet. Vervolgens als de code op de pagina en ik krijg het niet aan de praat.
  woensdag 8 oktober 2014 @ 14:00:36 #167
187069 slacker_nl
Sicko pur sang
pi_145328878
quote:
14s.gif Op woensdag 8 oktober 2014 13:36 schreef KomtTijd... het volgende:
Ik denk eerder dat de omschrijvingen gewoon brak vertaald zijn, geen zin om het weer te checken gezien dat met 10 seconden trial-and-error ook wel vast te stellen valt.
Het is ook niet naar jou toe hoor. Ik zie het in onze eigen code base ook. Ding krijgt een naam ala: user_id terwijl we het over een haar_kleur_id hebben. Argh! Dan heb ik liever dat ze het foo noemen.
In theory there is no difference between theory and practice. In practice there is.
pi_145329255
Het scheelt als je de value op "1" zet natuurlijk. :')

Ik denk dat ik er wel uit ga komen.

Thanks!
pi_145330969
quote:
0s.gif Op woensdag 8 oktober 2014 14:00 schreef slacker_nl het volgende:

[..]

Het is ook niet naar jou toe hoor. Ik zie het in onze eigen code base ook. Ding krijgt een naam ala: user_id terwijl we het over een haar_kleur_id hebben. Argh! Dan heb ik liever dat ze het foo noemen.
Van myVar1 t/m myVar392 en myTemporaryVar1 t/m myTemporaryVar921 word ik meestal ook niet echt vrolijk. Eén van de redenen dat ik blij ben dat ik nauwelijks meer met PHP developers te maken heb. :P
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
  woensdag 8 oktober 2014 @ 15:24:36 #170
12221 Tijn
Powered by MS Paint
pi_145331748
quote:
0s.gif Op woensdag 8 oktober 2014 15:04 schreef Monolith het volgende:

[..]

Van myVar1 t/m myVar392 en myTemporaryVar1 t/m myTemporaryVar921 word ik meestal ook niet echt vrolijk. Eén van de redenen dat ik blij ben dat ik nauwelijks meer met PHP developers te maken heb. :P
Dit speelt natuurlijk niet alleen onder PHP-developers, he :P

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
pi_145331895
quote:
2s.gif Op woensdag 8 oktober 2014 15:24 schreef Tijn het volgende:

[..]

Dit speelt natuurlijk niet alleen onder PHP-developers, he :P

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Nee, maar de kracht van PHP is echter dat het simpel en laagdrempelig. Dat is ook gelijk het probleem. Bijna iedere debiel kan er mee werken en helaas doen ook veel te veel debielen dat. :P
Je kunt prima programmeren in PHP, hoewel de taal zelf al wel enorm slordig en chaotisch is, maar het gebeurt veel te weinig.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
  woensdag 8 oktober 2014 @ 15:35:52 #172
12221 Tijn
Powered by MS Paint
pi_145332145
Ik heb wel het idee dat het mede dankzij de toolset van vandaag de dag (Composer, Symphony etc.) en de ontwikkelingen in de taal (deprecaten van mysql_ functies enzo) het de laatste tijd wat beter gesteld is.

Maar om eerlijk te zijn zie ik eigenlijk niet zoveel PHP-code van anderen om echt een idee te hebben van wat mensen over het algemeen doen :+

[ Bericht 0% gewijzigd door Tijn op 08-10-2014 16:19:40 ]
  woensdag 8 oktober 2014 @ 15:41:53 #173
62215 qu63
..de tijd drinkt..
pi_145332336
quote:
2s.gif Op woensdag 8 oktober 2014 15:35 schreef Tijn het volgende:
Ik heb wel het idee dat het mede dankzij de toolset van vandaag de dag (Composer, Symphony etc.) en de ontwikkelingen in de taal (deprecaten van mysql_ functies enzo) de laatste tijd wat beter gesteld is.

Maar om eerlijk te zijn zie ik eigenlijk niet zoveel PHP-code van anderen om echt een idee te hebben van wat mensen over het algemeen doen :+
Ik zal je mijn code verder besparen dan ;)

Het werkt nu zoals t moet (geloof ik), optimaliseren komt daarna :P
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
pi_145333778
quote:
0s.gif Op woensdag 8 oktober 2014 15:04 schreef Monolith het volgende:

[..]

Van myVar1 t/m myVar392 en myTemporaryVar1 t/m myTemporaryVar921 word ik meestal ook niet echt vrolijk. Eén van de redenen dat ik blij ben dat ik nauwelijks meer met PHP developers te maken heb. :P
Of van die mensen die constant bestaande variabelen OPNIEUW in een andere zetten en dan er uiteindelijk niks mee doen :')

1
2
3
4
<?php

$name 
$_POST['name'];
echo 
$name//WAAAAAAAAAAAAAAAAAAAAAAAAAAAAROM!!!!!


[ Bericht 27% gewijzigd door #ANONIEM op 08-10-2014 16:23:49 ]
pi_145334093
quote:
2s.gif Op woensdag 8 oktober 2014 15:35 schreef Tijn het volgende:
Ik heb wel het idee dat het mede dankzij de toolset van vandaag de dag (Composer, Symphony etc.) en de ontwikkelingen in de taal (deprecaten van mysql_ functies enzo) de laatste tijd wat beter gesteld is.

Maar om eerlijk te zijn zie ik eigenlijk niet zoveel PHP-code van anderen om echt een idee te hebben van wat mensen over het algemeen doen :+
Voor de wat grotere projecten wel ja, maar het neemt niet weg dat PHP in de basis nog steeds heel beroerd ontworpen is. Zie bijvoorbeeld deze vermakelijke klaagzang.
Verder wordt er nog heel wat aangeklooid in de PHP wereld.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
  woensdag 8 oktober 2014 @ 16:38:03 #176
12221 Tijn
Powered by MS Paint
pi_145334228
quote:
0s.gif Op woensdag 8 oktober 2014 16:33 schreef Monolith het volgende:

[..]

het neemt niet weg dat PHP in de basis nog steeds heel beroerd ontworpen is
Het is helemaal niet ontworpen. Het is samengesteld uit ingestuurde patches vanuit de community. Dat is de reden dat het zo inconsistent is, maar dat is ook de reden dat het bijvoorbeeld een van de eerste talen buiten Javascript was die JSON ondersteunde. PHP's makke is ook z'n kracht, namelijk dat het kan zijn wat de mensen willen dat het is.
pi_145334487
quote:
14s.gif Op woensdag 8 oktober 2014 16:38 schreef Tijn het volgende:

[..]

Het is helemaal niet ontworpen. Het is samengesteld uit ingestuurde patches vanuit de community. Dat is de reden dat het zo inconsistent is, maar dat is ook de reden dat het bijvoorbeeld een van de eerste talen buiten Javascript was die JSON ondersteunde.
Dat is geen excuus natuurlijk. Legio projecten werken met community contributions. Dat betekent echter niet dat elke wijziging blind geaccepteerd wordt of dat er geen hele heldere eisen kunnen worden gesteld waar de bijdragen aan moeten voldoen.

quote:
PHP's makke is ook z'n kracht, namelijk dat het kan zijn wat de mensen willen dat het is.
Zoals ik al zei. Iedere debiel kan het in principe gebruiken, dat is zowel een voordeel als een nadeel. Voor mij als developer toch voornamelijk een nadeel. :P
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
  woensdag 8 oktober 2014 @ 17:04:47 #178
187069 slacker_nl
Sicko pur sang
pi_145335121
quote:
2s.gif Op woensdag 8 oktober 2014 15:24 schreef Tijn het volgende:

[..]

Dit speelt natuurlijk niet alleen onder PHP-developers, he :P

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Klopt. Op mijn werk is het Perl en JS (angular) wat de klok slaat.
In theory there is no difference between theory and practice. In practice there is.
  woensdag 8 oktober 2014 @ 18:36:28 #179
12221 Tijn
Powered by MS Paint
pi_145337856
quote:
0s.gif Op woensdag 8 oktober 2014 16:46 schreef Monolith het volgende:

[..]

Dat is geen excuus natuurlijk. Legio projecten werken met community contributions. Dat betekent echter niet dat elke wijziging blind geaccepteerd wordt of dat er geen hele heldere eisen kunnen worden gesteld waar de bijdragen aan moeten voldoen.
Maar meestal hebben die projecten wel iemand aan het hoofd die de baas is en een visie heeft. Dat is er bij PHP niet. Niemand is de baas en er is geen plan over wat PHP moet zijn. Het is gewoon wat het is.

quote:
Zoals ik al zei. Iedere debiel kan het in principe gebruiken, dat is zowel een voordeel als een nadeel. Voor mij als developer toch voornamelijk een nadeel. :P
Misschien, hoewel je je met kwaliteit wel kunt onderscheiden van de meute. Ik denk dat het voor de wereld als geheel positief is dat er een populaire laagdrempelige programmeertaal bestaat die makkelijk is in te zetten voor het web.
pi_145338133
quote:
2s.gif Op woensdag 8 oktober 2014 18:36 schreef Tijn het volgende:

[..]

Maar meestal hebben die projecten wel iemand aan het hoofd die de baas is en een visie heeft. Dat is er bij PHP niet. Niemand is de baas en er is geen plan over wat PHP moet zijn. Het is gewoon wat het is.
Je hoeft geen echte centrale leider met een visie te hebben hoor. En er is wel degelijk een PHP team. Releases zijn natuurlijk centraal geregeld. Ik heb op PHP conferenties ook vaak genoeg smeekbedes van ze gehoord om ook wat bij te dragen. Op de vraag waarom de grotere partijen als facebook dat niet doen hadden ze dan niet echt een bevredigend antwoord. :P


quote:
Misschien, hoewel je je met kwaliteit wel kunt onderscheiden van de meute. Ik denk dat het voor de wereld als geheel positief is dat er een populaire laagdrempelige programmeertaal bestaat die makkelijk is in te zetten voor het web.
Oh het voldoet prima voor simpele webtoepassingen. Wil je meer performance dan moet je toch zoals facebook wel je eigen compilers gaan schrijven.
En als je niet zoals facebook groeit vanuit een hobby project dan begin je voor Enterprise level applicaties gewoon gelijk met bijvoorbeeld Java.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
abonnement bol.com Unibet Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')