slacker_nl | dinsdag 8 april 2014 @ 08:13 | |||
![]() Als je vragen hebt over PHP/MySQL, dan zit je hier goed met een vaste kliek guru's en een groot aantal regelmatige bezoekers. Beperk je vragen niet tot "hij doet het niet" of "hij geeft een fout" - onze glazen bol is kapot en we willen graag van je weten wát er niet lukt en wélke foutmelding je precies krijgt ![]() Zie ook: • PHP Dataverwerking • Officiële PHP website • PHP Documentatie • MySQL Reference Manual • Yet Another PHP Faq • PHP Cheat Sheet • PHP5 Power Programming - boek met uitleg over OOP, Pear, XML, etc Tutorials: • W3Schools PHP • W3Schools SQL Succes heren met het volgende deeltje! | ||||
Sitethief | dinsdag 8 april 2014 @ 11:53 | |||
Om de stilte maar even te doorbreken, wat zou ik aan deze kleine functie kunnen veranderen? Het doel is dat hij zo snel mogelijk zijn werk doet, zonder veel geheugengebruik. Ik zit te denken aan een for loop ipv foreach omdat alle arrays die erheen gaan toch oplopende keys hebben. Het doel is om arrays met objecten zo om te zetten dat alle objecten in de array een waarde uit het object als key hebben (meestal een bepaalde id) ipv een oplopende key.
| ||||
boem-dikkie | dinsdag 8 april 2014 @ 12:06 | |||
Ik ben er zelf sowieso van om variabelen te gebruiken die beschrijven wat ze in zich hebben. $toFlip is natuurlijk onduidelijk als de pest, en dat je er een comment blok bij zet die zegt dat je $toFlip een array met objecten is helpt ook vrij weinig. Maar dat is kwestie van smaak. | ||||
#ANONIEM | dinsdag 8 april 2014 @ 12:11 | |||
Ik zou sowieso de functie hernoemen en wat testjes doen om te zien of for of foreach sneller is in jouw geval. [ Bericht 50% gewijzigd door #ANONIEM op 08-04-2014 12:12:10 ] | ||||
#ANONIEM | dinsdag 8 april 2014 @ 12:23 | |||
Ook even een test toevoegen of je $flipKey wel bestaat in het object. Maar ik neem aan dat je dit doet omdat je wilt sorteren? Anders zie ik sowieso niet echt het nut in van deze functie. | ||||
Sitethief | dinsdag 8 april 2014 @ 12:55 | |||
In de objecten zitten unieke md5 keys ipv een gewone index die ik van de CouchDB terug krijg. Op deze manier heb ik een array met keys die ik gewoon kan gebruiken voor diverse dingen. Sorteren kan CouchDB gewoon voor mij doen btw. | ||||
#ANONIEM | dinsdag 8 april 2014 @ 12:56 | |||
Je weet dat je Objecten kunt behandelen als arrays? Dan hoef je ze niet eens om te zetten ^^. | ||||
Sitethief | dinsdag 8 april 2014 @ 12:57 | |||
Hij heeft de array in zich die geflipt moet worden? $flipArray dan misschien? Het is een globale functie die overal en nergens ingezet moet kunnen worden in principe. | ||||
Sitethief | dinsdag 8 april 2014 @ 13:04 | |||
Ik zet niks om? Maar hoe bedoel je? Dit zijn de soort arrays die die functie moet omzetten.
| ||||
#ANONIEM | dinsdag 8 april 2014 @ 13:13 | |||
Nouja je zet het nu dus om van dat naar dit?
| ||||
Sitethief | dinsdag 8 april 2014 @ 13:15 | |||
Klopt. Is er een betere methode? Dit was het beste wat ik zelf kon bedenken. | ||||
#ANONIEM | dinsdag 8 april 2014 @ 13:18 | |||
Nouja wat is er mis met de waarde direct uit het object aanroepen? Welke probleem moet dit een oplossing voor zijn? Nu heb je bijvoorbeeld:
Dus sowieso al toegang daartoe. [ Bericht 1% gewijzigd door #ANONIEM op 08-04-2014 13:18:40 ] | ||||
Sitethief | dinsdag 8 april 2014 @ 13:23 | |||
Omdat ik die array op meerdere plekken binnen een class nodig heb voor het opbouwen van verschillende dingen deels gebaseerd op dat ID, ik wil er dan niet iedere keer doorheen loopen of zoeken maar gewoon de key kunnen gebruiken om de juiste data te selecteren. | ||||
#ANONIEM | dinsdag 8 april 2014 @ 13:27 | |||
Heb je voorbeelden? Ik neem aan dat je voor veel dingen maar 1 van de objecten nodig hebt voor data? Even een klein voorbeeld van hoe ik er nu van uitga dat je het nodig hebt
| ||||
Sitethief | dinsdag 8 april 2014 @ 13:36 | |||
Inderdaad, maar ook complexere dingen, zoals kijken of bepaalde gebruikers recht hebben op de data erin gebaseerd op de context, lijsten in HTML bouwen van data uit value met andere items op ID eraan gelinked etc. Dit is stukken makkelijker als ik alle items gewoon op ID kan vinden. | ||||
#ANONIEM | dinsdag 8 april 2014 @ 13:42 | |||
Inderdaad, al zou ik het zelf anders hebben gedaan (niet persee beter, maar anders, waarschijnlijk meer resources uiteindelijk). In dat geval is je huidige code (op wat checks na) gewoon goed en moet je zelf even testen of je for of foreach gebruikt. Bij je foreach kun je $k weghalen aangezien je die niet gebruikt. | ||||
Sitethief | dinsdag 8 april 2014 @ 13:44 | |||
Het verschil is snelheid is er nauwelijks momenteel bij mijn kleine testcase, maar hoe meer er in de array zit hoe meer foreach volgens mij aan geheugen kost omdat die een kopie van de array maakt, dan is for volgens mij gewoon beter, ook omdat de keys altijd een index zijn. | ||||
#ANONIEM | dinsdag 8 april 2014 @ 13:48 | |||
Doe een foreach by reference. Nadeel van for is de count($array), hier maakt hij ook een kopie bij aan. en bij de foreach dus niet. | ||||
Sitethief | dinsdag 8 april 2014 @ 14:25 | |||
Ik vind reference altijd een redelijk lastig concept ![]() Trouwens, ik kan dat niet terug vinden wat jij zegt over count. Wel dat dat aantal opgeslagen is bij de array zelf. (zie o.a. http://stackoverflow.com/(...)-o1-or-on-for-arrays) [ Bericht 16% gewijzigd door Sitethief op 08-04-2014 14:34:20 ] | ||||
#ANONIEM | dinsdag 8 april 2014 @ 14:32 | |||
Hoezo lastig? je hoeft er alleen een & voor te zetten ![]() | ||||
Sitethief | dinsdag 8 april 2014 @ 14:35 | |||
Ik kijk er dan twee weken later over heen dat er & staat als ik die functie ga gebruiken en rare dingen zie gebeuren ![]() ![]() | ||||
#ANONIEM | dinsdag 8 april 2014 @ 14:40 | |||
Ja je moet wel oppassen met referenties ![]() Als je echt veel data gaat gebruiken zou ik adviseren dit even door te lezen: http://matthewturland.com/2010/05/20/new-spl-features-in-php-5-3/ | ||||
Sitethief | dinsdag 8 april 2014 @ 14:47 | |||
Oh boy ![]() ![]() | ||||
#ANONIEM | dinsdag 8 april 2014 @ 14:49 | |||
Ja staat leuke info bij ![]() Ik heb er zelf nog geen gebruik van hoeven maken, misschien kan ik bij mijn huidige werk wat dingen implementeren ooit ![]() | ||||
xaban06 | donderdag 10 april 2014 @ 00:02 | |||
Ik ben bezig met een project om mijn slimme meter uit te lezen en maak hier vervolgens een grafiek van. Ik krijg de resultaten te zien als: 0000.00 Dus 0000.38 is 380 Watt Dus 0012.21 is 12210 Watt Met welke functie kan je deze getallen omzetten? [ Bericht 1% gewijzigd door xaban06 op 10-04-2014 00:10:30 ] | ||||
Light | donderdag 10 april 2014 @ 00:05 | |||
| ||||
xaban06 | donderdag 10 april 2014 @ 00:07 | |||
Whuuut, zo simpel ![]() Thanks. | ||||
#ANONIEM | donderdag 10 april 2014 @ 00:17 | |||
Het is basis wiskunde ![]() daarnaast staat er een fout in de code van light. Getallen zijn niet met quotes. | ||||
xaban06 | donderdag 10 april 2014 @ 00:18 | |||
![]() Huidig verbruik in Watt ![]() ![]() | ||||
#ANONIEM | donderdag 10 april 2014 @ 00:21 | |||
Je kunt gebruik maken van DateTime object. Of gewoon 2 uur toevoegen aan de tijd. | ||||
xaban06 | donderdag 10 april 2014 @ 00:22 | |||
Ik ga zo ntp installeren, tijd moet gewoon kloppen op de server ![]() | ||||
#ANONIEM | donderdag 10 april 2014 @ 00:23 | |||
Misschien klopt het wel, in welke tijdszone staat de server? | ||||
xaban06 | donderdag 10 april 2014 @ 00:24 | |||
In de meterkast ![]() /UTC dus. Even corrigeren ![]() | ||||
#ANONIEM | donderdag 10 april 2014 @ 00:26 | |||
je kunt in php de tijdszone zetten,mocht je dat ooit willen ![]()
| ||||
xaban06 | donderdag 10 april 2014 @ 00:27 | |||
Cool.
![]() | ||||
slacker_nl | donderdag 10 april 2014 @ 07:04 | |||
In PHP zijn references raar. PHP gebruikt copy on write, dus je passed altijd een ref naar een functie, dus in je foreach/for loop heb je alleen maar refs, tenzij je de waardes van de array waarin je loopt aanpast. Als je kan, wilt, gebruik cursors om je data op te halen. | ||||
Light | donderdag 10 april 2014 @ 08:14 | |||
Maar als je ze vanaf een externe bron inleest, zijn het meestal wel strings. | ||||
Sitethief | donderdag 10 april 2014 @ 10:58 | |||
Ik neem aan dat deze post over mijn posts gaat ![]() Ik kwam er ook achter dat je naderhand de waardes in de foreach moet unsetten als je de array gereferenced hebt , anders gebeuren er soms rare dingen. | ||||
#ANONIEM | donderdag 10 april 2014 @ 11:51 | |||
Je zou maar zo'n bug moeten vinden in een bestand met meer dan 2000 regels niet OO code ![]() | ||||
slacker_nl | donderdag 10 april 2014 @ 12:44 | |||
Ja, zat mobiel en geen zin om te quoten ![]() Volgens mij wil je niet gaan referencen in PHP. Ik heb er ooit mee lopen spelen, maar ik kreeg er hoofdpijn van. | ||||
wipes66 | donderdag 10 april 2014 @ 18:03 | |||
weet iemand hoe dit kan? ik krijg steeds de volgende error: ERROR_CODE_22001 (22001) SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'title' at row 1 title is in mysql "varchar(300) utf8_unicode_ci" en ik gebruik een utf8 aware substring functie om hem te verkleinen ![]() | ||||
Light | donderdag 10 april 2014 @ 18:09 | |||
En hoe lang is de data die je in de kolom title wilt stoppen? Uit m'n hoofd weigert MySQL 5.5 data als het niet past, waar eerdere versies de data gewoon truncaten en je dat niet vertellen. Je kunt dat bij MySQL 5.5 nog wel instellen (maar de vraag is of je dat moet willen). | ||||
wipes66 | donderdag 10 april 2014 @ 19:06 | |||
330, maar 200 als utf8. daarom snap ik niet waarom mysql deze error geeft ![]() | ||||
slacker_nl | vrijdag 11 april 2014 @ 08:52 | |||
Zou het hiermee te maken hebben? http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html | ||||
Sitethief | vrijdag 11 april 2014 @ 08:53 | |||
Inderdaad ik ook ![]() | ||||
Sitethief | vrijdag 11 april 2014 @ 08:57 | |||
Zoiets schreef ik 5 jaar geleden, gelukkig vandaag de dag niet meer ![]() | ||||
wipes66 | vrijdag 11 april 2014 @ 10:04 | |||
ja dat is hem ![]() ![]() | ||||
slacker_nl | vrijdag 11 april 2014 @ 10:20 | |||
Nee, je stuurt er LATIN1 naartoe, dus is de lengte van je string 330. | ||||
wipes66 | vrijdag 11 april 2014 @ 11:04 | |||
uhm? alles aan php zijde is gewoon utf8, inclusief chinese tekens. alleen pdo of mysql ging er van uit (gok ik) dat ik iso-8859 instuurde en dus werd het dubbel utf8. [ Bericht 16% gewijzigd door wipes66 op 11-04-2014 12:01:42 ] | ||||
bondage | dinsdag 15 april 2014 @ 17:23 | |||
Is dit netjes om te doen?
Het is namelijk niet mogelijk om een array aan een exception mee te geven en ik moet meerdere parameters aan de uiteindelijke foutmelding toe kunnen voegen. Zo niet; is er een andere manier om dit te fixen? | ||||
zoem | dinsdag 15 april 2014 @ 17:27 | |||
Extenden met een eigen exception class? | ||||
bondage | dinsdag 15 april 2014 @ 17:38 | |||
Die mogelijkheid had ik al iets over gevonden, ik kwam echter niets tegen over het omzetten van de array naar een string en kon daardoor lastig een conclusie trekken wat beter zou zijn. Jij zou dus voor extenden gaan als ik het goed begrijp. | ||||
zoem | dinsdag 15 april 2014 @ 17:53 | |||
Ik ken de context ook verder niet, maar dit kwam als eerste in me op. | ||||
bondage | dinsdag 15 april 2014 @ 17:56 | |||
Ik ga hem extenden. Is het onderscheid ook duidelijker. | ||||
slacker_nl | dinsdag 15 april 2014 @ 21:26 | |||
https://www.destroyallsoftware.com/talks/boundaries | ||||
Sitethief | woensdag 16 april 2014 @ 08:46 | |||
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Kernighan's Law![]() | ||||
#ANONIEM | woensdag 16 april 2014 @ 12:42 | |||
Dan schrijf je toch je eigen error handler die dat wel aan kan? | ||||
bondage | woensdag 16 april 2014 @ 13:13 | |||
Allang gedaan ![]() | ||||
#ANONIEM | woensdag 16 april 2014 @ 13:14 | |||
Geen code om te tonen dan ![]() | ||||
bondage | woensdag 16 april 2014 @ 13:49 | |||
Nu niet, ben nu op kantoor. | ||||
bondage | woensdag 16 april 2014 @ 23:39 | |||
Hierbij
| ||||
wobbel | vrijdag 18 april 2014 @ 11:06 | |||
Help ![]() Vanaf een leverancier wordt er naar ons XML gepusht (dmv POST) naar http://server.tld/test.php. Dit gebeurd zonder variable naam.
Hoe kan ik dit met PHP afvangen? Een foreach met alle POSTS vars blijft angstvallig leeg. Als ik de contents van phpinfo(); naar mijzelf mail krijg ik het volgende: ![]() Dit wil zeggen dat ik met $_POST['<?xml_version'] wel de data op zou kunnen halen, en er later weer '<?xml_version' voor kan plakken maar helemaal netjes lijkt het mij niet. | ||||
mstx | vrijdag 18 april 2014 @ 11:11 | |||
file_get_contents("php://input") ? | ||||
wobbel | vrijdag 18 april 2014 @ 11:20 | |||
![]() | ||||
pascal08 | zondag 20 april 2014 @ 23:56 | |||
Ik ben op zoek naar een PHP library waarmee ik een soort mini-forumpje kan maken, zonder veel poespas, zoals phpBB. Een beetje dit idee: ![]() Ik wil het gebruiken als een soort berichtenprikbord waar iedereen berichtjes op kan plaatsen. Dus geen commentsystem. | ||||
Robuustheid | maandag 21 april 2014 @ 00:50 | |||
Moet je beter zoeken. Er zijn echt volop van dit soort dingen. ![]() | ||||
KomtTijd... | maandag 21 april 2014 @ 09:15 | |||
Succes! | ||||
Tijn | maandag 21 april 2014 @ 09:34 | |||
Waarom gebruik je niet gewoon Disqus zelf? | ||||
Swetsenegger | maandag 21 april 2014 @ 09:35 | |||
Dus eigenlijk wil je een gastenboek? | ||||
pascal08 | maandag 21 april 2014 @ 15:04 | |||
Ongeveer wel ja. | ||||
pascal08 | maandag 21 april 2014 @ 15:08 | |||
Omdat daar een heel gebeuren aan vastzit wat ik helemaal niet nodig heb. | ||||
Tijn | maandag 21 april 2014 @ 21:45 | |||
Valt wel mee toch? Gewoon een accountje maken, includen op de pagina waar je het hebben wil en klaar is kees ![]() | ||||
Maringo | dinsdag 22 april 2014 @ 09:03 | |||
Accountje aanmaken is voor veel mensen een dergelijke grote stap dat ze het maat laten zitten. Leuk voorbeeld is de case van Amazon die het account aanmaken niet meer verplicht stelde vooraf de aankoop. | ||||
Tijn | dinsdag 22 april 2014 @ 09:18 | |||
Ik bedoelde de moeite die het kost om het te installeren. Reageren kan volgens mij ook zonder account. | ||||
pascal08 | dinsdag 22 april 2014 @ 19:51 | |||
Dat is gewoon niet wat ik zoek. Ik heb zelf inmiddels al een code geschreven. Kostte uiteindelijk minder moeite dan een geschikte library vinden. ![]() | ||||
TwenteFC | dinsdag 22 april 2014 @ 19:55 | |||
![]() ![]() | ||||
Light | dinsdag 22 april 2014 @ 21:46 | |||
Interessante praatjes zijn dat ![]() | ||||
bondage | vrijdag 25 april 2014 @ 22:56 | |||
Ik zit al een tijd met mijn handen in het haar betreft de FOK!vriendjes module welke ik sinds kort in het FOK!stats script heb zitten. Het probleem is dat deze erg traag is, het probleem zit in het PHP script welke blijkbaar struggles heeft met de grote hoeveelheid data welke verwerkt moet worden. Het script doet het volgende: 1. Haal alle topic-id's op waar de ingevoerde gebruiker heeft gereageerd 2. Haal alle posts behorende bij de topic-id's op in delen van 32 topics, dit omdat Sphinx is ingesteld op max 10.000 resultaten 3. Loop over alle posts en voeg de bijbehorende topic-id's toe aan een array welke de unieke topic's per gebruiker gevat. Uit bovenstaande stappen hou je uiteindelijk een lijst over van alle topics waar andere gebruikers samen met de ingevoerde gebruiker hebben gereageerd. Zie het volgende stukje code, de array $resultaat["matches"] (afkomstig uit Sphinx) bevat alle unieke topic-id's waar de ingevoerde gebruiker gereageerd heeft.
Iemand een idee hoe ik het script sneller kan maken? Ik heb er nu een limiet van een maand op zitten omdat het anders veel te traag wordt. Het idee is de topics te verkrijgen waar je samen met iemand hebt gepost. Als je vaak in dezelfde topics als de ingevoerde gebruiker post zul je hoger in de lijst van die gebruiker komen te staan. | ||||
zoem | vrijdag 25 april 2014 @ 23:02 | |||
Wat is precies de bottleneck? Om wat voor orde van grootte gaat het in die loops? Zegt bijv. de xdebug profiler iets zinnigs? | ||||
bondage | vrijdag 25 april 2014 @ 23:41 | |||
Bij dit stuk gaat het traag:
Bovenstaande voegt de teruggegeven data uit Sphinx toe aan de array waar de topics per gebruiker staan. Het gaat hier om losse posts, als een gebruiker in bijvoorbeeld 50 topics heeft gepost binnen een gekozen periode dan komt dat neer op ongeveer 15050 posts, ervan uitgaande dat er binnen elk topic 301 posts (incl. OP) staan. Er zijn in dit geval dus 15050 loops nodig om alles bij langs te gaan, het meest trage is de isset en het toevoegen van de gegevens aan de array. Als dit dus op een andere, snellere manier zou kunnen dan zou dat een grote winst zijn aangezien ik de maximaal te selecteren periode dan kan ophogen, dit is nu een maand. De overige stats worden allemaal door Sphinx zelf gegenereerd en dat gaat veel sneller. Deze statistiek is echter niet volledig te doen in Sphinx omdat ik op twee waarden moet groeperen, namelijk user_id en topic_id, dit omdat de topic-id's slechts één keer per gebruiker mogen worden geteld. Een andere optie welke ik heb overwogen is het toevoegen van een gecombineerde waarde (user_id+topic_id) aan de index en daarop groeperen in de Sphinx query. Deze methode maakt de index echter significant groter en kost meer geheugen waar ik al niet teveel van heb in mijn server. xdebug heb ik nog niet geprobeerd en heb ik ook geen ervaring mee. Ik ga daar ff naar kijken. | ||||
Light | zaterdag 26 april 2014 @ 09:31 | |||
Hier vallen me een paar dingen op. Om te beginnen ben ik benieuwd wat er in $auteurId staat en waarom er een != wordt gebruikt voor die vergelijking. Verder heb je de isset()-check niet nodig. Je set de waarde op 1, en als die toevallig al geset was, verandert er niets. En je benadert (ook zonder isset()) $mData['attrs']['auteur_id'] meerdere keren. Niet fout, maar ik zou er een variabele van maken (en dat waarschijnlijk ook doen voor $mData['attrs']['topic_id']), al was het maar voor een betere leesbaarheid. | ||||
Maringo | zaterdag 26 april 2014 @ 10:36 | |||
Ik denk dat in het eerste if statement met de $auteurId wordt gekeken of de post niet van degene zelf is. Die lijkt mij onhandig. De enkele keer dat ie nuttig is, weegt niet op tegen de keren dat ie niet nuttig is. Mijn idee is om die eruit te halen en eventueel na de foreach loop die ene entry uit $users_topics ($users_topics[$auteurId]) te halen. [ Bericht 19% gewijzigd door Maringo op 26-04-2014 11:03:51 ] | ||||
slacker_nl | zaterdag 26 april 2014 @ 11:55 | |||
Kan je deze logica niet veel beter in je SQL oplossen, dat lijkt me vele malen sneller dan het oplossen in PHP. | ||||
bondage | zaterdag 26 april 2014 @ 16:03 | |||
In $auteurId staat het id van de user welke de post heeft geplaatst, aangezien ik de posts van degene waar op wordt gezocht wil negeren (wat Maringo al aangaf) gebruik ik die vergelijking. Die isset is idd niet nodig, dom dat ik me dat niet eerder had gerealiseerd aangezien ik heel goed weet dat het in dit geval geen effect op de resulterende array heeft. Ik haal deze sowieso weg. De waarden in $mData['attrs']['auteur_id'] en $mData['attrs']['topic_id'] zet ik in een variable, zelfs al levert het maar weinig op ben ik al blij. In ieder geval heel erg bedankt voor het meedenken. | ||||
bondage | zaterdag 26 april 2014 @ 16:06 | |||
Dank. Ik ga het ff aanpassen en checken of het winst oplevert ![]() Geprobeerd, met de volgende query:
Helaas een stuk trager dan mijn PHP oplossing ![]() [ Bericht 61% gewijzigd door bondage op 26-04-2014 16:11:06 ] | ||||
Light | zaterdag 26 april 2014 @ 16:58 | |||
Ahja, je wilt een overzicht van vriendjes maken. Hoe moet ik dat zien? Een lijst van users die in dezelfde topics gepost hebben? | ||||
Maringo | zaterdag 26 april 2014 @ 17:20 | |||
Klopt. Zo is dit mijn lijstje wat ie eens op verzoek maakte:
getallen zijn het aantal topics. | ||||
bondage | zaterdag 26 april 2014 @ 17:22 | |||
Exact ![]() | ||||
Light | zaterdag 26 april 2014 @ 17:33 | |||
Ik heb je query wat herschreven, zonder subqueries en right joins. Ongetest, uiteraard.
| ||||
bondage | zaterdag 26 april 2014 @ 17:40 | |||
Oeh, ik ga hem ff testen. | ||||
bondage | zaterdag 26 april 2014 @ 18:07 | |||
Ik heb de twee query's getest met het volgende resultaat (uiteraard SQL_NO_CACHE toegevoegd): Jouw query: Weergave van records 100 - 99 ( 100 totaal, query duurde 0.8366 sec)
Mijn query: Weergave van records 100 - 99 ( 100 totaal, query duurde 4.1594 sec)
Die van jou is een stuk sneller. Ik ga even testen over langere periodes. Als dit goed werkt kan ik dit beter gebruiken dan de PHP oplossing. [ Bericht 7% gewijzigd door bondage op 26-04-2014 18:18:21 ] | ||||
Sitethief | maandag 28 april 2014 @ 09:40 | |||
Is het niet sowieso handiger om zoveel mogelijk het ophalen van de juiste data door een database engine te laten doen ipv dat ik PHP na te gaan bootsen? De database engine zal hierin bijna altijd sneller zijn, tenzij je 10 subqueries ofzo gebruikt. | ||||
bondage | maandag 28 april 2014 @ 10:27 | |||
De rest van de stats worden gegenereerd door Sphinx, echter heeft Sphinx niet de mogelijkheid om op meerdere velden te groeperen. Als ik dit volledig in Sphinx zou kunnen doen zou het een stuk sneller gaan. Maar ik realiseer me nu dat ik dit beter op kan lossen dmv een query ipv de data door php te laten verwerken. Een andere optie is een betere server aanschaffen, daar heb ik echter op dit moment geen geld voor ![]() | ||||
Light | maandag 28 april 2014 @ 19:09 | |||
Voer je die query uit op een 'eigen' server? Als in een database-server die je zelf beheert en waar je indexen kunt aanpassen? Dan moet er nog wel wat snelheidswinst te behalen zijn. | ||||
bondage | maandag 28 april 2014 @ 22:54 | |||
Jup, is mijn eigen server. Dit zijn de velden en indexen die ik momenteel heb: ![]() ![]() | ||||
Light | maandag 28 april 2014 @ 22:59 | |||
Hmm... year heeft een kardinaliteit van 1. Heb je alleen posts uit 2014 in de database staan? | ||||
bondage | maandag 28 april 2014 @ 23:01 | |||
Dat viel mij ook al op idd. Er staat 6 jaar aan data in die tabel. Is het overigens erg dat id een int(15) is? Ik heb deze database ooit van iemand overgenomen en hier niet bij stilgestaan, ik weet echter dat een gewone int niet tot 15 gaat. | ||||
Light | maandag 28 april 2014 @ 23:13 | |||
Mooi ![]() ![]() (Je zou ook nog in plaats van "year" de kolom "tijdstip" kunnen toevoegen, maar ik vermoed dat het verschil vrij klein is terwijl de index veel groter kan worden.) Nee, dat getal maakt alleen uit als je zerofill gebruikt. En dat wil je niet (want voorloopnullen toevoegen hoort de database niet te doen). | ||||
bondage | maandag 28 april 2014 @ 23:19 | |||
Dank, ik ga die twee indices even combineren en de query dan nogmaals testen. Ik gebruik geen zerofill dus dat is dan geen probleem gelukkig. Wat is eigenlijk het voordeel van het combineren van die twee? | ||||
KomtTijd... | dinsdag 29 april 2014 @ 09:59 | |||
Volgens mij kun je year beter helemaal uit de query halen en gewoon zorgen dat je tijdstippen nooit meerdere jaren overspannen. | ||||
bondage | dinsdag 29 april 2014 @ 10:08 | |||
Als ik year uit de query haal en vervolgens dit jaar uitdraai duurt de query een stuk langer dan met year erin. Blijkbaar heeft de index voor dat veld wel effect. Ik had het primair toegevoegd voor het indexeringsproces omdat er per jaar een losse Sphinx index wordt gemaakt, op deze manier hoeft niet steeds alle data opnieuw verwerkt te worden. Dmv het year veld en bijbehorende index is ook die query een stuk sneller. | ||||
Light | dinsdag 29 april 2014 @ 21:23 | |||
Dan wil je wel heel zeker weten dat er een index op (auteur, tijdstip) wordt gebruikt. En ik weet niet hoe goed MySQL omgaat met een index die als range wordt gebruikt (BETWEEN) in combinatie met een andere index. Hoe beperkter het resultaat van een index is, hoe beter. | ||||
Light | dinsdag 29 april 2014 @ 21:27 | |||
Je maakt het MySQL op die manier makkelijker om twee kolommen te gebruiken in een index, waardoor de resultaatset kleiner wordt. En dat helpt weer om de snelheid omhoog te krijgen ![]() Overigens is een index op (auteur, year) ook nog steeds te gebruiken als index op auteur maar het is niet te gebruiken als index op year. Als je die ook los nodig hebt, moet je daar dus een aparte index voor maken / houden. | ||||
bondage | dinsdag 29 april 2014 @ 21:31 | |||
Duidelijk. En de year index heb ik inderdaad nodig aangezien die ook in de query van de Sphinx indexer wordt gebruikt. Ik ga nu de bestaande index op auteur verwijderen en van year en auteur een gecombineerde index maken. De losse year index laat ik gewoon staan. Ik post straks de resultaten incl. de output van EXPLAIN. Het aanpassen van de index gaat wel ff duren aangezien het om een erg grote tabel gaat. Edit: ik kan blijkbaar de bestaande auteur index gewoon wijzigen. Heb year toegevoegd, de server is nu ff bezig. | ||||
bondage | dinsdag 29 april 2014 @ 22:53 | |||
Het duurde even maar de index is klaar. Dit is wat ik nu heb:![]() Ik ga morgen ff testen, nu ff geen tijd meer voor aangezien ik zo naar bed ga. Moet morgen weer vroeg op. | ||||
slacker_nl | woensdag 30 april 2014 @ 15:01 | |||
Omdat ik soms zo loop te miepen over tests:![]() | ||||
Sitethief | woensdag 30 april 2014 @ 15:30 | |||
![]() ![]() | ||||
slacker_nl | woensdag 30 april 2014 @ 17:53 | |||
100% code coverage! (dit laat Devel::Cover zien en aangezien er weinig perl mensjes zijn ging ik de PHP mensjes spammen ![]() [ Bericht 17% gewijzigd door slacker_nl op 30-04-2014 17:58:32 ] | ||||
Light | woensdag 30 april 2014 @ 18:42 | |||
Ziet er wel leuk uit, die statistieken ![]() Maar wat is er zo bijzonder aan die test met als time 85.9? Die duurt wel erg lang. | ||||
slacker_nl | woensdag 30 april 2014 @ 20:59 | |||
Dat is 000-package.t, daarin worden de volgende zaken getest: 1) MANIFEST file ok 2) Modules compilen ok 3) POD (documentatie) syntax ok 4) POD coverage ok (dus doc je ook al je functies) 5) Compilen je scripts ok Die duren wat langer, echt niet zo spannend allemaal. Dat zijn eigenlijk release-only tests. | ||||
Light | woensdag 30 april 2014 @ 21:31 | |||
Dan snap ik wel dat die tests ook lang duren (in ieder geval in verhouding). | ||||
bondage | woensdag 30 april 2014 @ 22:15 | |||
Hmm, de query is met deze nieuwe index trager geworden. Hij duurde eerst 0,83 seconden, nu 3,46. Ik heb exact dezelfde parameters gebruikt als de vorige keer toen de indices nog niet gecombineerd waren. Dit is de explain: ![]() Ik heb de query van Light gebruikt aangezien die sowieso al sneller was dan die van mij.
FORCE INDEX gebruiken misschien? | ||||
Light | woensdag 30 april 2014 @ 22:35 | |||
Hmm... da's wel onverwacht... het (geschatte) aantal rijen voor de eerste query gaat van 12.000 naar 2.400 en toch is de query veel trager... | ||||
bondage | woensdag 30 april 2014 @ 22:36 | |||
Jup, ik snap er ook niets van ![]() | ||||
Light | woensdag 30 april 2014 @ 22:37 | |||
Ik kan me niet voorstellen dat dat helpt, omdat de juiste index al wordt gebruikt. | ||||
bondage | woensdag 30 april 2014 @ 23:15 | |||
Zou een gecombineerde index op topic_id en auteur misschien een optie zijn? | ||||
Light | vrijdag 2 mei 2014 @ 21:50 | |||
Dat lijkt me niet nuttig, in ieder geval niet in die volgorde. | ||||
bondage | maandag 5 mei 2014 @ 16:08 | |||
Heeft de table collation invloed op de gegevens die in de velden staat? Stel dat de table collation op latin1_swedish_ci staat maar de velden in de tabel op utf8_unicode_ci, heeft dit dan gevolgen? De documentatie zegt hier het volgende over: Dit doet mij vermoeden dat het alleen om een standaardwaarde gaat en dit verder geen invloed heeft op de data in de tabel. | ||||
wipes66 | maandag 5 mei 2014 @ 16:43 | |||
nvmd | ||||
TwenteFC | maandag 5 mei 2014 @ 22:06 | |||
Oh god, heb een boek gekocht over Test driven development, gaat het dan toch nog gebeuren? ![]() | ||||
Juicyhil | maandag 5 mei 2014 @ 22:09 | |||
Ik heb alle bedrijven dat wel eens horen zeggen. Maar nog nooit een bedrijf tegengekomen die het geheel volgens het boekje heeft geïmplementeerd. Jammer hoor. Het scheelt zoveel in tijd en kwaliteit. | ||||
TwenteFC | maandag 5 mei 2014 @ 22:17 | |||
Krijg binnenkort de kans om een gehele shop vanaf scrap op te zetten, waarbij de oude database slechts als api wordt gebruikt. ![]() Dat het tijd bespaart wil er bij de hogere heren nog niet in, maar heb als excuus gebruikt dat dit verplicht is voor mijn opleiding. (deeltijd hbo). | ||||
Juicyhil | maandag 5 mei 2014 @ 22:23 | |||
Ja dan is het zeker een goed voornemen om tests te schrijven. Heb het zelf vaak genoeg in projecten geprobeerd erdoorheen te krijgen, maar dan komt er een deadline om de hoek kijken en krijgt het geen prioriteit meer enzo. ![]() | ||||
TwenteFC | maandag 5 mei 2014 @ 22:25 | |||
Hier net zo, een klein bedrijf waar we eigenlijk meer misbruikt worden als helpdesk dan dat we daadwerkelijke nieuwe webapplicaties opzetten. Prioriteit ligt blijkbaar bij het verminderen van het aantal klikjes dat een inkopertje moet doen ![]() | ||||
TwenteFC | maandag 5 mei 2014 @ 22:27 | |||
![]() | ||||
Juicyhil | maandag 5 mei 2014 @ 22:32 | |||
Ik voel je. Dat heb ik ook vaker meegemaakt. Met alle drama zoals security issues en jankende klanten eromheen. Maar dat is nu voorbij ![]() Ik probeer dat soort shit van me af te schuiven. Ga maar eerst investeren in fatsoenlijke software. | ||||
bondage | maandag 5 mei 2014 @ 22:37 | |||
Ok, de enige andere optie die ik kan bedenken is dat ik een snellere server nodig heb en dat de huidige gewoon niet voldoet om dit soort statistieken uit te draaien. In ieder geval bedankt voor het meedenken ![]() | ||||
Darkomen | dinsdag 6 mei 2014 @ 08:51 | |||
Dat herken ik, zo hebben wij 2 sites onder onze hoeden gekregen die zijn gebouwd door een gast in Bangladesh... Toen ik voor het eerst een problemen moest oplossen kwam ik al code tegen welke niks met de site te maken hadden en allemaal uit een ander project van deze gozer kwam. | ||||
slacker_nl | dinsdag 6 mei 2014 @ 09:02 | |||
Lezen? Of daadwerkelijk TDD gaan gebruiken? | ||||
raptorix | dinsdag 6 mei 2014 @ 11:21 | |||
En is de database wel op orde? Als dat namelijk ook niet op orde is loop je alsnog tegen allerlei shit aan, tenzij je wat handige mappers gaat maken, maar dan moet je maar zien of dat ook performed. Overigens snap ik niet waarom bedrijven nog steeds hun eigen webshops ontwikkelen, het is duur in onderhoud, en je haalt nooit de kwaliteit die bestaande software levert. | ||||
Chandler | dinsdag 6 mei 2014 @ 11:44 | |||
Zo herkenbaar... ![]() ![]() Voordeel is wel dat de code gelijk up to date is, je niet steeds je hoeft in te lezen in de 'oude' code. ![]() | ||||
Darkomen | dinsdag 6 mei 2014 @ 12:03 | |||
Helemaal mee eens, maar helaas mag ik het niet herbouwen van mijn baas... kost te veel tijd. En grootte kans dat hij het dan niet meer snapt ![]() | ||||
TwenteFC | dinsdag 6 mei 2014 @ 18:09 | |||
Beide ![]() De database is ook pure troep, maar daar gooien we gewoon een api service tegenaan. Dus de database van het nieuwe product kan ik ook zelf opzetten. En dat bestaande software dezelfde kwaliteit levert dat is niet helemaal waar, wij zullen sowieso functionaliteit gaan missen of welke niet volledig aan onze wensen voldoen. En daarbij krijg je met bestaande software vaak het zelfde als wat we nu hebben; troep. | ||||
Boze_Appel | dinsdag 6 mei 2014 @ 18:51 | |||
Moet je eens kijken hoeveel Magentodevelopers er gevraagd worden om van alles te herschrijven omdat Magento apenballen zuigt. De grootste reden voor eigen webshopsoftware is vaak omdat ze allerlei dingen erin willen hebben die niet met plugins te regelen is en niet standaard in de shops zit, dus dan kan je bestaande code gaan hacken waarvan steeds nieuwe updates komen of een net framework pakken en vanaf daar aan de slag gaan. Bovendien hebben ze vaak al hun eigen facturatiesysteem, dus heel dat stuk heb je niet nodig. | ||||
TwenteFC | dinsdag 6 mei 2014 @ 18:58 | |||
En je bent nog min of meer afhankelijk van een externe partij ook. Nooit leuk. | ||||
Chandler | dinsdag 6 mei 2014 @ 22:42 | |||
Je kunt toch zelf initiatief tonen als je het zo'n leuk project vind om in je eigen tijd het zelf te schrijven? en dan eventueel verkopen (of via half jaar betaald vakantie, ken een persoon die zo een lange tijd vrij was op de kosten van de baas!, betaald vakantie dus.) ? neem aan dat het idee vrij te gebruiken is?! staat dan ook zeer goed op je cv ![]() | ||||
bondage | dinsdag 6 mei 2014 @ 22:46 | |||
Mijn baas snapt ook niet wat ik doe, maakt ook niet uit, ik mag zelf bepalen waar ik aan werk. Als ik maar oplever wat er wordt gevraagd. | ||||
Darkomen | woensdag 7 mei 2014 @ 08:22 | |||
In n vrijetijd ben ik druk met mn eigen sites ;-) Daarnaast is het en project van een klant van ons, dus zij zijn degene die betalen. Als ik dan de hele boel herbouw en zij zeggen, nee gaat mijn baas mij echt geen half jaar vrij geven ![]() Helaas programmeert mijn baas ook mee aan onze projecten. Iemand nog een php developer nodig rond utrecht? ![]() | ||||
raptorix | woensdag 7 mei 2014 @ 10:57 | |||
En wat is je maandelijkse onderhoudsbudget als ik vragen mag? | ||||
raptorix | woensdag 7 mei 2014 @ 10:58 | |||
Waarom je uberhaupt Magento zou gebruiken is me een raadsel, ik heb het ooit wel eens bekeken, wat een bagger zeg, alleen al de honderden zo niet duizenden files waarmee je te maken hebt. ![]() | ||||
raptorix | woensdag 7 mei 2014 @ 10:59 | |||
Een goede webshop in een halfjaar schrijven? GL, gaat je niet lukken. | ||||
Boze_Appel | woensdag 7 mei 2014 @ 11:04 | |||
En je configfile in een .xml die alleen met een .htaccess afgeschermd is. Zit je dus op een gare (shared) server waarbij je niet alle functies van .htaccess kan gebruiken staat je config open voor heel de wereld. ![]() | ||||
slacker_nl | woensdag 7 mei 2014 @ 11:32 | |||
Ik zit me dit echt af te vragen. Geen geld hebben om webshopsoftware naar je wensen aan te passen (door middel van plugins en/of patchen en upstream gooien), maar wel geld hebben om het van scratch te bouwen. Raar. Het lijkt me dat die software inmiddels best lekker is uitgekristalliseerd en je dus makkelijk met een off-the-shelf products aan de gang kan gaan. | ||||
raptorix | woensdag 7 mei 2014 @ 13:51 | |||
Zelf ben ik wel gecharmeerd van NOP commerce, opensource (wel c#/.net). http://www.nopcommerce.com/downloads.aspx | ||||
Chandler | woensdag 7 mei 2014 @ 17:12 | |||
Mag ik vragen waarom niet? en wat is goed? ebay? marktplaats? 1 produkt webshop? je vergelijkt gelijk peren met kruidnoten... | ||||
Boze_Appel | woensdag 7 mei 2014 @ 17:21 | |||
ASP / MS SQL webshop. The horror! ![]() | ||||
TwenteFC | woensdag 7 mei 2014 @ 18:16 | |||
De webshop zelf is 2 jaar geleden opnieuw gebouwd, en qua werk wat er daarna ingestopt is niet erg veel. Programmeer werk dan. Dat zal misschien hooguit 10 uur per maand zijn, en dan schat ik het nog hoog in. Het is vooral de backend van de groothandel die brak in elkaar zit. Maar er moet een nieuwe shop gebouwd worden omdat we onze zakelijke klanten ook een webshop op maat willen leveren en zelf binnen enkele klikken product/merk specifieke webshops willen opstarten op interessante domeinnamen. Waarna er in feite een dropshipment in de backend wordt gezet. | ||||
TwenteFC | woensdag 7 mei 2014 @ 18:18 | |||
![]() Je hebt alleen flexibiliteit nodig om al die seo meuk handelbaar te houden op een lange termijn. | ||||
raptorix | donderdag 8 mei 2014 @ 08:00 | |||
Wat snap je niet aan een goede webshop? | ||||
raptorix | donderdag 8 mei 2014 @ 08:01 | |||
ASP? C#/.net | ||||
raptorix | donderdag 8 mei 2014 @ 08:03 | |||
Ehm, wij werken met een team van een man of 10 ongeveer een jaar aan 1 webshop, en dan gebruiken we ook nog eens een enterprise product, maar goed als jij denkt dat een webshop iets simpels is.... Vandaar dat met mensen als jou de kwaliteit van 99 procent van de webshops bedroevend is. | ||||
mstx | donderdag 8 mei 2014 @ 08:11 | |||
Yep, ik heb nu ook 2 shops in Magento moeten maken, het is ook best wel bagger. ![]() En dan heb je waarschijnlijk nog niet naar de database gekeken, een standaardinstallatie heeft 348 (!!!) tabellen. ![]() ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 08:12 | |||
Veel tabellen zegt niet alles, maar 348 is idioot, ik heb ooit in 1999 mijn eigen webshop geschreven die vrij uitgebreid was, en toen kwam ik volgens mij op een tabel of 25, overigens ook wel eens met een database gewerkt van boven de 1000 tables ![]() | ||||
bondage | donderdag 8 mei 2014 @ 08:23 | |||
Ik mag toch hopen dat er goede documentatie beschikbaar was voor dat monster. Het grootste aantal tables dat ik ooit heb gezien zal ergens rond de 100 liggen. De documentatie was helaas erg beperkt en ik moest zelf uit gaan zoeken welke tables met elkaar te linken waren en op welke velden. Velden hadden, om het nog erger te maken, veelal onduidelijke namen wat dit gedoe er niet makkelijker op maakte. Heeft me erg veel tijd gekost om dat ding in kaart te brengen en alsnog te beschrijven. | ||||
raptorix | donderdag 8 mei 2014 @ 08:26 | |||
Dit was de global product database van Ericson, zat op zich goed en logisch in elkaar, maar alles wat ook maar bekend was qua producten van Ericsson zat in dat ding, opzich als je gewend bent met complexe databases kom je er best goed uit, zaten wel wat vervelende dingen in, omdat zoveel applicaties er van gebruik maakten was men heel huiverig op changes, dus maakte men al snel weer een nieuw table aan. Zo waren er een stuk of 8 tables met regions/landen wat het niet echt mooi maakte. | ||||
mstx | donderdag 8 mei 2014 @ 08:33 | |||
Zolang de tabellen en kolommen maar logische namen hebben. Opencart heeft bijv. ook 115 tabellen maar daar heb ik de documentatie nog nooit voor nodig gehad. Veel simpeler kan het ook niet:
Ter vergelijking, Magento:
![]() | ||||
Chandler | donderdag 8 mei 2014 @ 08:51 | |||
Ik snap niet dat jij zegt dat een goede webshop niet in een halfjaar te bouwen is, weet niet op welk slakken tempo jij typt, maar beetje webshop valt ECHT wel in een halfjaar te ontwikkelen. Maar goed, voor de ene is goed goed en de ander slecht! ![]() Oh en je zegt dat jullie met 10 man werken, mooi man, zal wel een extreem uitgebreid product zijn, met bergen met opties etc.. wat een gemiddelde webshop dus niet nodig heeft, lijkt mij. En als jij zegt dat 99% niet goed is, zowww dan kunnen we beter maar stoppen met internetten want er zijn zoveel webshops geschreven door 1 persoon, die zijn dus bij deze allemaal uitermate slecht.. | ||||
raptorix | donderdag 8 mei 2014 @ 08:57 | |||
Natuurlijk kun je wel een webshop bouwen in een halfjaar, maar we hadden het over een goede webshop, maar mijn punt blijft dat het onzin is om zelf webshops te gaan bouwen, verspilling van tijd en geld, want het loont gewoon niet, er zijn zat prima producten op de markt waarbij men 10.000 uren heeft geinvesteerd om het te optimaliseren, daar kan je gewoon niet tegen op werken. | ||||
slacker_nl | donderdag 8 mei 2014 @ 08:58 | |||
De functionaliteit van een webshop is snel te maken. Tis een CMS met een Ogone koppeling. Echter heb je ook te maken met wat werkt prettig voor de gebruiker. Alles is te maken. Maar ben het met raptor eens dat je ook flink moet investeren in je product als je een goede bruikbare shop wilt hebben. Werkende prototypes zijn een, goed werkende eindproducten zijn een ander verhaal. [ Bericht 0% gewijzigd door slacker_nl op 08-05-2014 10:00:36 ] | ||||
Chandler | donderdag 8 mei 2014 @ 09:07 | |||
Is het absoluut geen onzin, als iedereen dacht zoals jij zaten we nog steeds te internetten op een modem en moesten we downloaden vanaf bbsjes... Juist doordat mensen zelf dingen proberen te maken leert men, kijkt men dingen van elkaar af. Ik heb zat sites ontwikkeld die NOOIT het daglicht hebben gezien, waarom, onvrede van mijn kant over het product wat ik had gemaakt, niet goed genoeg, maar heb ook zat sites wel afgemaakt die ik zo kon 'kopen' ipv zelf te schrijven, maar juist het zelf schrijven is vaak veel leuker dan het moeten werken met bv magento/wordpress/etc. Het is jou mening dat het verspilling van geld en tijd is, ik verspeel ook veel tijd met vissen, uren aan de waterkant en totaal NIETS doen... god wat een verspilling van 'energie en geld'.. maar ik geniet er wel op en top van, leer iedere keer wat... dat heb je niet als je dingen gaat toevoegen aan bestaande producten, je hebt geen flauw idee wat er allemaal in het systeem gebeurd, hebt weinig controle over plus je leert niet hoe het allemaal in elkaar zit. Ik snap best dat je kiest voor pakketten die al bestaan, maar snap niet dat je het afraad om het zelf te maken.. zeg maar.. Ik ben het ook met je eens, maar meeste webshops hoeven geen detail tree, of bergen met opties, die willen producten aanbieden om te verkopen, met betaal mogelijkheid, klanten database... je kunt het jezelf zo moeilijk maken als je zelf wilt, maar het is in mijn ogen de uitdaging om het allemaal zelf te schrijven. Daarom zie je ook bergen met mensen zelf blogs schrijven, vroeger gastenboeken etc maken... waarom? omdat het leuk is om het zelf te doen.. ipv iets te gebruiken wat van een ander is. | ||||
slacker_nl | donderdag 8 mei 2014 @ 09:22 | |||
Qua educational value heb ik er geen bezwaar tegen. Maar we hebben het hier over bedrijven, dan zijn de belangen anders en liggen ze niet bij het 'leren', maar winst maken. | ||||
mstx | donderdag 8 mei 2014 @ 09:31 | |||
Alsof het de klant iets interesseert of je het leuk vindt en er wat van leert. Die wil gewoon zo snel en zo goedkoop mogelijk zijn nieuwe shop online hebben. Als die dan moet kiezen tussen het gebruik van een bestaande oplossing (die zich al heeft bewezen) waar alle functionaliteit in zit die hij nodig heeft, of een custom iets wat from scratch wordt gebouwd, 5x zo veel tijd kost en allerlei kinderziektes heeft is de keuze vaak snel gemaakt. | ||||
Boze_Appel | donderdag 8 mei 2014 @ 10:02 | |||
Staat op hun site. | ||||
slacker_nl | donderdag 8 mei 2014 @ 10:06 | |||
ASP.NET uses the multi-language abilities of the .NET Common Language Runtime, allowing Web pages to be coded in VB.NET, C#, J#, Delphi.NET, Chrome, etc. | ||||
KomtTijd... | donderdag 8 mei 2014 @ 10:07 | |||
Het kan nog wel eens vies tegenvallen wat er aan 'goede' webshops op de markt is. Veel van ditsoort producten zijn ofwel proprietary met alle beperkingen van dien, ofwel van moeilijk belabberde kwaliteit. Als je echt een op maat gesneden oplossing zoekt, is beiden vaak geen optie en is inhouse ontwikkelen vaak echt de beste keus. | ||||
raptorix | donderdag 8 mei 2014 @ 10:11 | |||
Iets doen omdat je het leuk vind of om te leren is heel wat anders dan professioneel een site ontwikkelen, daarnaast kan ik zeggen dat ik juist heel erg voor vooruitgang ben, en daarom liever nieuwe dingen ontwikkel dan het wiel opnieuw uitvinden. | ||||
raptorix | donderdag 8 mei 2014 @ 10:11 | |||
ASP is niet te vergelijken met ASP.NET , ongeveer zelfde om java te vergelijken met javascript. | ||||
Chandler | donderdag 8 mei 2014 @ 10:12 | |||
Dan denken we niet hetzelfde, dat kan hoor ![]() ![]() ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 10:12 | |||
Het probleem met inhouse ontwikkelen is dat je een product aan het maken bent, dat is een compleet andere tak van sport dan het verlenen van een dienst. | ||||
raptorix | donderdag 8 mei 2014 @ 10:13 | |||
Het gaat erom wat het nut is, ik denk dat het veel nuttiger is om nieuwe features van bijvoorbeeld een opensource project te ontwikkelen, profiteren ook nog meer mensen van. | ||||
Chandler | donderdag 8 mei 2014 @ 10:14 | |||
I agree, maar vaak (zeker in jou geval) zal alleen het bedrijf er van kunnen genieten en niet de 'open source' wereld ![]() ![]() | ||||
Boze_Appel | donderdag 8 mei 2014 @ 10:14 | |||
Allebei meuk, dus prima te vergelijken. ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 10:16 | |||
Naja, laat ik niet gaan bashen in het PHP topic ![]() | ||||
Chandler | donderdag 8 mei 2014 @ 10:19 | |||
Wees vrij rap, tis hier toch meer slowchat... dan praten over 'php op zich' ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 10:22 | |||
Ik heb gewoon slechte ervaringen met PHP, nu zal ik de laatste zijn die zal beweren dat er slechte talen zijn, want zelfs in een goede taal kun je slecht programmeren, maar ik vind het in PHP gewoon omslachtig, probeer maar eens c# in visual studio met Resharper en er zal een wereld voor je open gaan. | ||||
KomtTijd... | donderdag 8 mei 2014 @ 10:23 | |||
Mja ik ben zelf bezig met het inhouse ontwikkelen van een CRM systeem. Na een jaar gekut met een open-source CRM systeem (Vtiger) ben ik wel enigszins teruggekomen op deze mening. OS-producten gebruiken is alleen nuttig als er ook daadwerkelijk iets beschikbaar is wat een goeie basis heeft, en dat is lang niet altijd het geval. | ||||
raptorix | donderdag 8 mei 2014 @ 10:24 | |||
Wel eens gekeken naar Salesforce (niet opensource) maar wel zeer betaalbaar. | ||||
Chandler | donderdag 8 mei 2014 @ 10:26 | |||
+1 maar wat voor slechte ervaringen dan? maar C, C++, C# is niet mijn ding, nooit iets mee gedaan en zal het ws ook nooit gaan doen... php/python vind ik wel erg leuk, vooral nu Python omdat het lijkt op PHP maar toch compleet anders is ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 10:31 | |||
Naja het is alweer tijd geleden dat ik er wat mee gedaan heb, ik had veel problemen met configuratie onder windows. Ter voorbeeld, hoe zou je dit in bijvoorbeeld PHP aanpakken?
| ||||
Chandler | donderdag 8 mei 2014 @ 10:34 | |||
Geen idee, zo goed is mijn Python na een maand ook alweer niet ![]() | ||||
Sitethief | donderdag 8 mei 2014 @ 10:38 | |||
Je hebt een lijst met kleuren en wilt alle kleuren zien die blauw in hun naam hebben ofzo? | ||||
Chandler | donderdag 8 mei 2014 @ 10:40 | |||
ok
Jammere van PHP is dat de ene keer je string, zoekwoord hebt en de andere keer zoekwoord, string zo omslachtig is't niet ![]() ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 10:47 | |||
Dat vind ik echt zo heerlijk met Linq, vrij complexe zaken kun je op prachtige manieren shortcutten. | ||||
Rockfire | donderdag 8 mei 2014 @ 10:48 | |||
Maar juist shortcutten kan er ook voor zorgen dat de code onleesbaar wordt als het slecht is geprogrammeerd ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 10:49 | |||
Uiteraard, je moet het niet overdrijven. Ik had laatst deze constructie nodig, simpel en effectie, maar toch leesbaar:
| ||||
Chandler | donderdag 8 mei 2014 @ 10:50 | |||
Nee maar op zich is het best duidelijk en zo moet je natuurlijk geen 10tallen dingen achter elkaar zetten! ![]() ![]() | ||||
Tijn | donderdag 8 mei 2014 @ 10:53 | |||
Strpos geeft de positie van de gevonden string terug, dus dat kan ook 0 zijn. Om te weten of-ie gevonden is, kun je beter een sterke comparison doen met false (dus === false voor niet en !== false voor wel gevonden). En als je stripos() gevruikt, is toLower() niet nodig ![]() | ||||
Chandler | donderdag 8 mei 2014 @ 10:53 | |||
Klopt Tijn, !== moest het zijn maar dan nog, ging even snel om het voorbeeld ![]() | ||||
Tijn | donderdag 8 mei 2014 @ 10:55 | |||
Ook voorbeelden moeten kloppen, je weet nooit wat iemand copy-paste en in z'n applicatie stopt. | ||||
Robuustheid | donderdag 8 mei 2014 @ 10:56 | |||
Je zou bijvoorbeeld in PHP een library kunnen oproepen met daarin de kleuren. Maar voor de overzichtelijkheid, stop ik de kleuren in een array. Dat zou bijv. kunnen uitzien:
| ||||
Chandler | donderdag 8 mei 2014 @ 10:58 | |||
Juist ![]()
| ||||
Tijn | donderdag 8 mei 2014 @ 10:59 | |||
Sowieso is Linq natuurlijk gewoon te implementeren in PHP, als je het echt zo graag zou willen gebruiken ![]() Er zijn meerdere libraries te vinden die je zo kunt toepassen, zoals http://phplinq.codeplex.com | ||||
raptorix | donderdag 8 mei 2014 @ 11:01 | |||
Het punt is dat het niet native in je framework zit, ben wel benieuwd naar de performance op wat grotere collecties. | ||||
Sitethief | donderdag 8 mei 2014 @ 11:01 | |||
In PHP kun je ook gewoon methods chainen... | ||||
Tijn | donderdag 8 mei 2014 @ 11:04 | |||
Tsja, geen idee natuurlijk. Maar ook dan is er vast wel iets te bedenken om het wel te laten performen lijkt me ![]() | ||||
KomtTijd... | donderdag 8 mei 2014 @ 11:05 | |||
Meh, zal al snel net zo duur zijn als dat ik ben, plus dan moet ik er nog steeds tegenaan ontwikkelen. Voor zover dat uberhaupt mag. | ||||
Tijn | donderdag 8 mei 2014 @ 11:11 | |||
Vooral op lange termijn is in-house natuurlijk veel goedkoper, als je het goed doet. Voor zo'n Salesforce mag je voor een klein team al snel 30K per jaar neerleggen, dus als je dat 10 jaar gebruikt heb je 3 ton verbrand. | ||||
Robuustheid | donderdag 8 mei 2014 @ 11:16 | |||
Voorbeeldje? | ||||
Tijn | donderdag 8 mei 2014 @ 11:19 | |||
PDO bijvoorbeeld:
Je kunt dit ook heel makkelijk met je eigen classes doen, het is gewoon een kwestie van de methodes zichzelf laten returnen. | ||||
Chandler | donderdag 8 mei 2014 @ 11:23 | |||
Kan, maar ik zou juist dit los van elkaar willen ivm fouten etc ![]() | ||||
raptorix | donderdag 8 mei 2014 @ 11:26 | |||
Valt juist erg mee, daarnaast is Salesforce perfect om aan te sluiten op je maatwerk omdat je direct een SOAP interface kunt genereren, ik had het binnen een dag aangesloten op een bestaand CMS voor een woningcorporatie. http://www.salesforce.com/nl/crm/editions-pricing.jsp | ||||
Tijn | donderdag 8 mei 2014 @ 11:28 | |||
Mwah, 135,- euro per gebruiker per jaar is met een klein clubje van 20 man toch een slordige 32.400 euro, toch? | ||||
raptorix | donderdag 8 mei 2014 @ 11:29 | |||
Ga jij maar een maatwerk CRM systeem maken voor een club van 20 man, en ga het ook maar eens supporten en onderhouden de komende 10 jaar. Het is algemeen bekend dat het bouwen van maatwerk nooit opweegt tegen licentie kosten. | ||||
Chandler | donderdag 8 mei 2014 @ 11:31 | |||
Zal ongetwijfeld in de meeste gevallen zo zijn, maar dan nog is het erg duur, ongetwijfeld nog duurder als je het zelf gaat ontwikkelen maar goed... | ||||
Tijn | donderdag 8 mei 2014 @ 11:32 | |||
Ik doe dat al. Eenmalig is het een investering voor zo'n club, maar daarna zijn de kosten per jaar om het in de lucht te houden veel lager, waarop het op termijn zichzelf makkelijk terugbetaalt voor een organisatie. | ||||
raptorix | donderdag 8 mei 2014 @ 11:43 | |||
Ik denk niet dat jouw productje ook maar in de buurt komt wat Salesforce bied. | ||||
Tijn | donderdag 8 mei 2014 @ 11:47 | |||
Nee, zeker niet. Ik denk ook wel dat er organisaties zijn waarvoor zoiets als Salesforce een goede uitkomst is, hoor. Maar ik zie een heleboel simpele, kleine clubs in Nederland waar minder dan 30 mensen werken die wel behoefte hebben aan IT, maar niet aan heel uitgebreide systemen. Die willen gewoon een telefoongesprekje invoeren op een webpagina zodat hun collega's ervan op de hoogte zijn of een reminder krijgen 2 maanden voordat een abonnement van een klant afloopt en that's it. Voor zulke simpele eisen is een maatwerkoplossing helemaal geen gek idee, want dan heb je nauwelijks lopende kosten. [ Bericht 0% gewijzigd door Tijn op 08-05-2014 11:56:34 ] | ||||
raptorix | donderdag 8 mei 2014 @ 11:54 | |||
Oh daar ben ik wel mee eens, ik had het meer over wat uitgebreide CRM oplossingen. Het punt wat ik wil maken is dat je je organisatie moet inrichten op product ontwikkeling, en dat dat een hele andere tak van sport is. | ||||
Tijn | donderdag 8 mei 2014 @ 12:00 | |||
Ik weet ook niet of het slim is om het écht in-house te doen als je geen IT-bedrijf bent. Ik zou denken dat bedrijven zich beter kunnen richten op hun core business en voor IT-maatwerk eenmalig een bureau of een competente freelancer kunnen inschakelen. | ||||
KomtTijd... | donderdag 8 mei 2014 @ 12:05 | |||
Dat is wel waar we hier aan zouden zitten ja. Dat hoeft ook helemaal niet. Waarschijnlijk zouden we 90% van de functies nieteens gebruiken en moeten er alsnog heel veel functies bijgeschreven worden. En dat is een handicap die veel kant-en-klaar pakketten hebben. Ze zijn zo uitgebreid mogelijk om een zo breed mogelijke markt te bedienen, maar een maatwerkoplossing hoeft vaak maar een fractie van die functionaliteit te bevatten. En is daardoor ook veel sneller te ontwikkelen en makkelijker te onderhouden. Daarbij komt (voor mijn situatie) dat het misschien ook verkocht kan worden aan zusterbedrijven, en dan levert het ineens geld op ipv dat het geld kost. | ||||
Tijn | donderdag 8 mei 2014 @ 12:10 | |||
Precies. Kleine bedrijven doen over het algemeen maar 1 ding en willen daarom een IT-product dat goed aansluit bij dat ene ding. Dat vind je zelden bij generieke software, terwijl het vaak wel goed te doen is om die ene functie op maat te maken. | ||||
raptorix | donderdag 8 mei 2014 @ 12:35 | |||
Ik ben genoeg van dit soort software gedrochten tegengekomen, en mijn ervaring is dat men er substantieel geld mee verliest omdat de software niet naar behoren werkt of niet aangepast kan worden. | ||||
Tijn | donderdag 8 mei 2014 @ 12:42 | |||
Tsja, uitvoering is alles. Natuurlijk wordt er een hoop rommel geschreven, maar dat wil niet zeggen dat het per se een slecht idee is om een maatwerkoplossing te laten maken. | ||||
TwenteFC | donderdag 8 mei 2014 @ 18:16 | |||
"met mensen als jou" ![]() Dat jullie 10 kleuters zonder enige kennis van webshops aan het werk zetten om er een te bouwen betekent niet dat andere bedrijven wel kennis in huis hebben. Je kan nog niet eens een paar zinnen foutloos typen, wat zegt dat over jullie code. Als we toch op zo'n lekker bedroevend niveau aan het discussiëren zijn. | ||||
Light | donderdag 8 mei 2014 @ 21:00 | |||
Het probleem is dat ze qua structuur volledig vrij willen zijn en toch een MySQL database willen gebruiken. Dat komt waarschijnlijk omdat OpenCart en Magento al een poosje bestaan en er toen niet echt alternatieven waren. Als je nu een webshop gaat schrijven, zou ik serieus kijken naar een NoSQL database (bijvoorbeeld MongoDB of ArangoDB) gebruiken om de producten in op te slaan. En waarschijnlijk ook voor de rest van de data. | ||||
Light | donderdag 8 mei 2014 @ 21:47 | |||
Op die manier doorzoek je de array wel twee keer, eerst voor in_array en daarna voor array_search.
| ||||
raptorix | vrijdag 9 mei 2014 @ 06:45 | |||
NoSQL is een prima ontsluiting van je data, maar ik zou er echt geen klant of transactie gegevens in gaan opslaan, overigens kun je binnen een magento of Opencart of welk ander product ook prima noSQL inzetten, het is gewoon een questie van je data pushen naar je noSQL server, kun je zowel realtime als in batch doen. | ||||
Light | vrijdag 9 mei 2014 @ 07:55 | |||
Waarom geen klantgegevens en transacties in NoSQL? En Magento en OpenCart bieden nu (voor zover ik weet) geen mogelijkheid om productgegevens in NoSQL op te slaan. In plaats daarvan komen ze met een mega-hoeveelheid tabellen in MySQL om maar een flexibele structuur aan te kunnen bieden. | ||||
raptorix | vrijdag 9 mei 2014 @ 08:41 | |||
Omdat je klantegevens en andere business relationeel wilt indelen, en daar ook je queries op kunnen doen, dat gaat je bij noSQL databases niet op een makkelijke manier lukken, daarnaast heeft het ook eigenlijk helemaal niet zoveel zin omdat je juist noSQL gebruikt vanwege performance en losse structuur. Alles kan natuurlijk, maar of het slim is, is een tweede. | ||||
slacker_nl | vrijdag 9 mei 2014 @ 08:52 | |||
Wij gebruiken op werk daarvoor de hstore functionaliteit van postgres: http://www.postgresql.org/docs/9.0/static/hstore.html http://thebuild.com/prese(...)gday-fosdem-2013.pdf http://www.schneems.com/p(...)ing-hstore-in-rails/ | ||||
Tijn | vrijdag 9 mei 2014 @ 10:12 | |||
Het gaat vooral om de eigenachappen van producten waarin je flexibel wilt zijn, toch? Dus waarom niet een column "properties" in de product tabel waar je gewoon JSON in zet? ![]() | ||||
Aether | vrijdag 9 mei 2014 @ 10:17 | |||
![]() | ||||
cablegunmaster | vrijdag 9 mei 2014 @ 12:46 | |||
Nvm , done fixed ![]() ![]() ![]() [ Bericht 27% gewijzigd door cablegunmaster op 09-05-2014 14:20:44 ] | ||||
Juicyhil | vrijdag 9 mei 2014 @ 17:49 | |||
![]() | ||||
n8n | vrijdag 9 mei 2014 @ 17:51 | |||
Gewoon alles met nodejs dit dat | ||||
TwenteFC | vrijdag 9 mei 2014 @ 18:09 | |||
![]() | ||||
#ANONIEM | vrijdag 9 mei 2014 @ 18:42 | |||
Is een middel, geen doel. ![]() | ||||
Light | vrijdag 9 mei 2014 @ 18:54 | |||
Of xml opslaan in zo'n blob. ![]() | ||||
Light | vrijdag 9 mei 2014 @ 19:01 | |||
In zo'n situatie moet je voor- en nadelen van beide mogelijkheden uitzoeken tegen elkaar afwegen. Ik vind het wat lastig om bij voorbaat een keuze te maken, maar ik zou niets op voorhand uitsluiten. Er is ook niets mis mee om een deel van de data in NoSQL te zetten en een ander deel in een relationele database. ![]() | ||||
slacker_nl | vrijdag 9 mei 2014 @ 22:36 | |||
Tis geen PHP, maar met php moet het ook zo kunnen
Zo moeilijk was dat toch niet? | ||||
cablegunmaster | maandag 12 mei 2014 @ 13:31 | |||
Even een simpele moeilijke vraag. - Bestanden uploaden (controle op php extensie en op inhoud of er mogelijk code instaat ) - (plaatjes met extra code erin bvb ) Is dit mogelijk? - Hoe ik de folder afscherm van mogelijk gebruik (toch op een manier een php file geupload en deze folder disablen om de php scripts te draaien). Is dit mogelijk ![]() | ||||
KomtTijd... | maandag 12 mei 2014 @ 13:34 | |||
Ik zou zeggen, probeer je vraag eerst een keer in begrijpbaar Nederlands te stellen. Dan wordt het voor jezelf waarschijnlijk ook al een stuk duidelijker. | ||||
cablegunmaster | maandag 12 mei 2014 @ 13:36 | |||
Je hebt vast gelijk ![]() Even rondgevraagd en die oplossing is al gemaakt.
zocht ik ![]() | ||||
karton2 | maandag 12 mei 2014 @ 16:10 | |||
Op mijn ftpserver draait phpversie: 5.3.28 Nu zit ik op de wikipedia te kijken welke versies dat er zijn en zie dat 5.3 t/m juli 2014 ondersteund wordt. Mijn vraag is nu of het kwaad kan dat mijn server 5.3 heeft en wat eventuele gevolgen kunnen zijn voor mijn website. | ||||
Juicyhil | maandag 12 mei 2014 @ 21:08 | |||
Het zal niet zo zijn dat je website van de ene op de andere dag kapot gaat ![]() Dus als het kan zeker upgraden. | ||||
slacker_nl | maandag 12 mei 2014 @ 22:39 | |||
Welk OS draai je en hoe zit het met de support daarop? Debian doet bijvoorbeeld gewoon de security patches loslaten op bijv. de 5.3.x branch als ze die leveren. Is unsupported http://nl3.php.net/releases/, edoch, krijg ik gewoon security fixes binnen.
[ Bericht 49% gewijzigd door slacker_nl op 12-05-2014 22:44:36 ] | ||||
KomtTijd... | maandag 12 mei 2014 @ 23:34 | |||
De 5.3 branch wordt (nu) ook door PHP nog gesupport dus da's niet zo gek. @karton2: Als het een managed server is, is in principe de hosting partij verantwoordelijk voor je php-installatie. Waarschijnlijk zul je dan binnenkort inderdaad naar 5.4 of 5.5 geslingerd worden. Als je bang bent dat dat je applicaties breekt zou je het vast kunnen testen, maar die kans is niet zo groot hoor. Zeker niet als je een bekend en up-to-date CMS gebruikt. Als je 'm zelf beheert zou ik gewoon zsm updaten. Nadelen heeft het niet en vroeg of laat zal het toch moeten. | ||||
slacker_nl | dinsdag 13 mei 2014 @ 00:08 | |||
Alleen 5.3.28 als ik http://nl3.php.net/downloads.php erbij pak. en de pagina waar 5.3.3 op staat zegt:
| ||||
Light | dinsdag 13 mei 2014 @ 08:25 | |||
Bugfixes worden door Debian gebackport, waardoor je wel altijd op de versie blijft die meegeleverd werd in de distro. Daarom ook zie je PHP 5.3.3-7+squeeze19 staan als versienummer. En zolang Debian 6.0 ondersteund wordt (tot feb 2016 voor i386 en amd64) zullen ze die bugfixes blijven doen (tenzij ze expliciet aangeven dat niet te doen, er is/komt een tooltje om packages te vinden die niet meer ondersteund worden). | ||||
slacker_nl | dinsdag 13 mei 2014 @ 12:33 | |||
Dat zei ik toch ook in m'n allereerste reactie ![]() | ||||
Darkomen | dinsdag 13 mei 2014 @ 14:02 | |||
Klacht: ik mag geen error handler schrijven omdat dat te lang zou duren en moet als oplossing error_reporting(0) gebruiken van mn baas ... | ||||
zoem | dinsdag 13 mei 2014 @ 14:29 | |||
Slechte baas heb je dan ![]() | ||||
Maringo | dinsdag 13 mei 2014 @ 14:33 | |||
Tegenin gaan! Of zorgen voor een error. ![]() | ||||
#ANONIEM | dinsdag 13 mei 2014 @ 14:35 | |||
Ik had mijn baan opgezegd. | ||||
Darkomen | dinsdag 13 mei 2014 @ 14:51 | |||
Dat heb ik al opgegeven, laat hem straks maar zoeken als er iets fout is op de site. Al gedaan, nog 2 maanden, ben op zoek naar iets wat een uitdaging is. | ||||
Feola | vrijdag 16 mei 2014 @ 16:52 | |||
Ik zit al een uur te kutten met het volgende: Op mijn eigen server werkt het wel goed, na het uploaden op een andere host niet. Ik heb een formulier, die een aantal velden heeft. Hij post het formulier naar post.php, welke deze code bevat. Alleen pakt hij mijn postvelden niet, maar een print_r($_POST); op post.php geeft wel alle velden met inhoud die van het formulier afkomen ![]()
Iemand een idee? | ||||
KomtTijd... | vrijdag 16 mei 2014 @ 17:08 | |||
typfoutjes lijkt me? | ||||
slacker_nl | zaterdag 17 mei 2014 @ 11:53 | |||
Wat zegt array_key_exists? | ||||
slacker_nl | zaterdag 17 mei 2014 @ 11:54 | |||
Hahaha. Faalhazerij zeg ik. Overal @voorzetten, @ook @in @je @mails @naar @de @baas. | ||||
Juicyhil | zaterdag 17 mei 2014 @ 12:32 | |||
Of gewoon een kopie van een bounce mail terugsturen ![]() | ||||
cablegunmaster | zaterdag 17 mei 2014 @ 12:49 | |||
Beter issets gebruiken dan @voorzetten. ![]() Jep , meer code neerzetten. Zoals de waarde van je print_r($_POST); dit zal behulpzaam zijn om te weten. (controleer hoofdlettersvan je if statement en je name value) Hoofdletter gevoeligheid speelt mee. Ter verduidelijking: een enkele if statement kan ik niet veel mee. ander dan zeggen dat je $_POST['variabele_naam'] niet gelijk is aan je <input type='text' name='variabele_naam' value='' > [ Bericht 28% gewijzigd door cablegunmaster op 17-05-2014 12:57:18 ] | ||||
ViPeRII | zaterdag 17 mei 2014 @ 16:36 | |||
Ik weet niet of dit het is, maar $_POST['Titel'] is iets anders dan $_POST['titel'] | ||||
Devolution | zondag 18 mei 2014 @ 10:44 | |||
Of misschien is het in het formulier op z'n Engels (title) en in je code in het Nederlands (titel). Dat soort kleine dingetjes kijk je als mens snel overheen maar PHP vergeeft je zulke foutjes niet ![]() | ||||
n8n | zondag 18 mei 2014 @ 10:52 | |||
daarom altijd 1 systeem aanhouden | ||||
Aether | maandag 19 mei 2014 @ 16:01 | |||
Herkend iemand zich ![]() Programming Sucks | ||||
Maringo | maandag 19 mei 2014 @ 16:37 | |||
![]() Mooi stukje verder ![]() | ||||
WyriHaximus | dinsdag 20 mei 2014 @ 09:26 | |||
Ook wel een herkenbaar stukje ![]() | ||||
Skunk-m | dinsdag 20 mei 2014 @ 20:03 | |||
Ik zit me hier op te naaien dat is niet meer normaal.. ik heb een bestand staat enkel en alleen een 1 in als ik die uitlees met file_get_contents of fread en dan if(dat bestand == "1") doe dan is antwoord altijd false.. als ik element inspecteren doe lijkt het alsof er een hele berg white space achter staat, maar die krijg je op geen mogelijkheid weg... Weet iemand hoe ik dit doe? | ||||
zoem | dinsdag 20 mei 2014 @ 20:12 | |||
Misschien dat een stukje code helpt om het probleem te vinden. Wat krijg je als inhoud te zien met var_dump? | ||||
cablegunmaster | dinsdag 20 mei 2014 @ 20:36 | |||
Skunk je antwoord op je vraag. Post wat code waar het gebeurt? ![]() Ik kan niet meelezen met wat je doet. | ||||
Skunk-m | dinsdag 20 mei 2014 @ 20:52 | |||
if(file_get_contents("bestand") == "1"){ doe dit.. } werkt niet.. heb nog trim en rtrim en substr toegepast op die file_get_contents werkt niet.. blijft gewoon 1 echoen en als ik element inspecteren doe zie ik een hoop blanco ruimte erachter. heb ook dit geprobeerd $file = fopen("bestand", 'r'); $z = fread($file, 1); fclose($file); if($z == "1"){ doe dit } zelfde resultaat. En nee het bestand zelf bevat geen witruimte enkel en alleen een 1 | ||||
cablegunmaster | dinsdag 20 mei 2014 @ 20:54 | |||
http://www.php.net/manual/en/function.file-exists.php Probeer file_exists ipv file_get_contents. lees dit bovenstaande stuk even door. mogelijk is de syntax van "bestand" fout. ![]() | ||||
Skunk-m | dinsdag 20 mei 2014 @ 20:56 | |||
a wacht fuck.. sorry dat ik jullie lastig heb gevallen ik ben echt een domme koekebakkert.. lol.. is in zo'n phpbb bestand maar kheb dat wat ie moet doen alleen bij de variabelen die meegeeft aan template neergezet kheb em nog niet in template zelf neer gezet. | ||||
mstx | dinsdag 20 mei 2014 @ 20:56 | |||
Ik ben traag. [ Bericht 98% gewijzigd door mstx op 20-05-2014 20:57:27 (-_-) ] | ||||
Darkomen | donderdag 22 mei 2014 @ 12:59 | |||
Ik zit te oefenen met 'foreign keys' en heb een vraag waar ik niet uitkom. Ik ben bekend met het zetten van een fk welke entries verwijderd uit een tabel(users_groups) als de user verwijderd word uit de db. - vaag bekend met verwijderen Maar wat ik wil is dat wanneer de user of dealer verwijderd word, bij de auto de 'dealer id' of 'user id' op 0 of NULL word gezet. Alleen krijg ik dat niet voor elkaar en ik snap niet waarom ![]() Ps, let even niet op de verschillende talen tussen users en auto's/dealers FF geprobeerd om de entries te verwijderen maar ook dat lukt me niet.
Pss. dat was omdat de tabel niet leeg was. Maar ON DELETE SET NULL lukt dus niet Psss: ja.... 'Null: NO' => 'Null: YES' Dat was hem dus [ Bericht 0% gewijzigd door Darkomen op 22-05-2014 13:25:20 ] | ||||
raptorix | vrijdag 23 mei 2014 @ 13:56 | |||
Ik zou hem niet verwijderen, maar ik zou een flag maken waarin aangegeven is dat de dealer niet meer bestaat, het is in principe bad practice om data te deleten uit je database, tenzij het geen functie meer heeft, bijvoorbeeld logentries. Overigens zou ik iets consequenter zijn in de naamgeving, ik zou bijvoorbeeld fieldnames niet gaan prefixen met de table name, maar als je het dan toch doet doe het dan wel consequent. | ||||
Darkomen | vrijdag 23 mei 2014 @ 14:19 | |||
Het is ook test databaseje om te rotzooien met relaties. Wel een opzet voor een totale rebuild om precies de punten aan te pakken waar jij het over hebt ![]() Site/DB is orgineel gebouwt in Sri Lanka... met gebruik van een voorgaand project van de bouwer, bouwer heeft ook engelse namen vertaald naar nederlands via google translate. Verder heeft niemand hier verstand van relaties... :| | ||||
slacker_nl | zaterdag 24 mei 2014 @ 10:17 | |||
Mannen... | ||||
Darkomen | maandag 26 mei 2014 @ 11:55 | |||
lol | ||||
WyriHaximus | dinsdag 27 mei 2014 @ 16:28 | |||
Het blijft wel lekker angstvallig stil. Nou moet ik wel zeggen dat een compleet eigen communicatie protocol uitwerken aantoont hoe lastig communiceren is en dus ook relaties zijn. | ||||
cablegunmaster | dinsdag 27 mei 2014 @ 18:07 | |||
![]() | ||||
#ANONIEM | dinsdag 27 mei 2014 @ 20:35 | |||
PHP is eigenlijk niet zo slecht met autoloaders. Als je daarnaast van alle procedurele dingen vaak een OOP-alternatief zoekt al helemaal. ![]() | ||||
Aether | woensdag 28 mei 2014 @ 12:19 | |||
PHP Next Generation The PHP Group has put up a post about the future of PHP. They say, 'Over the last year, some research into the possibility of introducing JIT compilation capabilities to PHP has been conducted. During this research, the realization was made that in order to achieve optimal performance from PHP, some internal API's should be changed. This necessitated the birth of the phpng branch, initially authored by Dmitry Stogov, Xinchen Hui, and Nikita Popov. This branch does not include JIT capabilities, but rather seeks to solve those problems that prohibit the current, and any future implementation of a JIT capable executor achieving optimal performance by improving memory usage and cleaning up some core API's By making these improvements, the phpng branch gives us a considerable performance gain in real world applications, for example a 20% increase in throughput for Wordpress. The door may well now be open for a JIT capable compiler that can perform as we expect, but it's necessary to say that these changes stand strong on their own, without requiring a JIT capable compiler in the future to validate them.'" | ||||
Sitethief | woensdag 28 mei 2014 @ 13:43 | |||
http://computerworld.nl/d(...)enen-om-php-te-haten Soms denk ik dat mensen PHP bashen alleen maar omdat het bashen. Maar deze auteur gaat wel heel kort door de bocht... | ||||
#ANONIEM | woensdag 28 mei 2014 @ 13:48 | |||
Wat een faal ![]() 1) Pure domheid van de programmeur, daar helpt geen enkele taal tegen. 2) ![]() 3) Klopt, maar met een goeie IDE is dat geen probleem. 4) ![]() 5) Wacht wat ![]() 6) Dat is toch geen issue meer ![]() 7) Daar valt omheen te programmeren. 8) Tering ![]() 9) Tering ![]() 10) Valide 11) ![]() 12) Daar ben je toch zelf bij ![]() Wat een tenenkrommend slecht stukje, bah. | ||||
slacker_nl | woensdag 28 mei 2014 @ 13:53 | |||
Je hoeft PHP niet te bashen, dat doet het zelf ![]() | ||||
Darkomen | woensdag 28 mei 2014 @ 13:57 | |||
Ik vind het ook een absolute kut taal als ik iets niet weet ![]() ![]() Maar dat heb ik ook met javascript, c, java, asp. | ||||
cablegunmaster | woensdag 28 mei 2014 @ 14:28 | |||
resolved. [ Bericht 15% gewijzigd door cablegunmaster op 28-05-2014 14:40:34 ] | ||||
Aether | woensdag 28 mei 2014 @ 15:05 | |||
Ben het met 4, 6 en 8 eens. Bij punt 12 worden taal en bibliotheken volgens mij als één gezien. | ||||
Sitethief | woensdag 28 mei 2014 @ 15:16 | |||
Mensen die PHP verkeerd gebruiken bashen bedoel je... | ||||
slacker_nl | woensdag 28 mei 2014 @ 18:59 | |||
Nee hoor. PHP is gewoon kut, laten we eerlijk zijn. | ||||
cablegunmaster | woensdag 28 mei 2014 @ 19:02 | |||
Gecombineerd met Smarty en OO PHP kan het nog best aardig werken. Laatste paar weken toch wat meer vertrouwen in PHP gekregen. Een goed werkend framework eromheen bouwen. ![]() | ||||
WyriHaximus | donderdag 29 mei 2014 @ 19:22 | |||
Gebruik dan iets moderns zoals Twig en een goed up-to-date framework er bij. Alles inladen via composer en gaan met die zooi ![]() | ||||
Tijn | donderdag 29 mei 2014 @ 19:32 | |||
Natuurlijk is het niet perfect, maar ze zijn wel goed bezig in de laatste paar versies om nare dingen aan te pakken en goeie nieuwe dingen toe te voegen. Er zijn twee soorten talen: talen waarover wordt geklaagd en talen die niet worden gebruikt. | ||||
slacker_nl | donderdag 29 mei 2014 @ 20:26 | |||
Ik gebruik PHP te weinig om daar wat zinnigs over te kunnen zeggen. Das ook weer waar. Maarja, omdat het gebruikt wordt wilt ook niet alles zeggen. https://jeena.net/images/2012/PHP-The-Good-Parts.pdf | ||||
cablegunmaster | donderdag 29 mei 2014 @ 21:09 | |||
![]() ![]() [ Bericht 7% gewijzigd door cablegunmaster op 29-05-2014 21:39:56 ] | ||||
Tijn | donderdag 29 mei 2014 @ 23:16 | |||
PHP heeft een hele slechte basis en wordt nu voor totaal iets anders gebruikt dan waar het ooit voor gemaakt is. Als je dit ten tijde van PHP 3, 4 of zelfs toen 5 net uit was had gezegd, had je helemaal gelijk gehad. PHP was toen echt heel erg slecht. Het is nog steeds slecht, maar ze proberen nu in elk geval wel serieus de rotste appels eruit te halen en ze zijn bezig om te zorgen dat het langzaam maar zeker een moderne, maar ook veiligere taal aan het worden is. Bovendien zijn er onwijs veel goede tools ontstaan (frameworks als Laravel en Symfony2, depency managers als Composer, template engines als Twig bijvoorbeeld) wat het gebruik van PHP ook een stuk beter te doen maakt. Wat dat betreft zijn de dark ages van mysql_real_escape_string(), register_globals en magic quotes wel voorbij. | ||||
TwenteFC | zaterdag 31 mei 2014 @ 00:33 | |||
Behoorlijk waardeloos artikel, helemaal voor een artikel dat slechts enkele dagen oud is. | ||||
Darkomen | zaterdag 31 mei 2014 @ 12:26 | |||
![]() | ||||
Robuustheid | zondag 1 juni 2014 @ 16:00 | |||
UIt een PHP tutorial:
Waarom moet bij de instantatie van var Stefan, de haakjes bij person gezet worden, en bij jimmy niet? Beide werken gewoon. Is het niet handiger om ze weg te laten? | ||||
mstx | zondag 1 juni 2014 @ 16:06 | |||
Doen allebei precies het zelfde. De haakjes heb je pas echt nodig als je argumenten meegeeft aan de constructor. | ||||
Tijn | zondag 1 juni 2014 @ 16:07 | |||
Ik zou ze niet weglaten, het maakt het duidelijker wat er gebeurt als je de haakjes toevoegt. Maar wat je ook doet, doe het in elk geval consequent. | ||||
Light | zondag 1 juni 2014 @ 18:32 | |||
Het mag allebei. Maar als je argumenten mee wilt geven, moet je wel haakjes gebruiken. Dus ik zou het gewoon altijd doen. Verder lijkt het PHP4-code, en die is al jaren verouderd. Ik zie geen keywords als public, protected en/of private in de code. | ||||
#ANONIEM | maandag 2 juni 2014 @ 20:14 | |||
Hmm. Ik zit erover te denken om Chemistry van Apache een update naar PHP 5 te geven. Alleen durf ik het niet. Overigens is veel ook nog niet geïmplementeerd. | ||||
esv7 | dinsdag 3 juni 2014 @ 13:56 | |||
Is er een mogelijkheid om hetgeen dat je ophaalt met een prepared mysqli statement ophaalt, in een array te stoppen? Ik moet nu met bind_result() evenveel argumenten meegeven als dat er kolommen aan data wordt opgehaald.
[ Bericht 30% gewijzigd door esv7 op 03-06-2014 14:11:34 ] | ||||
Aether | dinsdag 3 juni 2014 @ 14:09 | |||
| ||||
esv7 | dinsdag 3 juni 2014 @ 14:11 | |||
Bedankt voor het snelle antwoord ![]() | ||||
KomtTijd... | dinsdag 3 juni 2014 @ 14:23 | |||
gebruik PDOstatement::fetchall(). Geen idee hoe je dat met mysqli zou doen. | ||||
mstx | dinsdag 3 juni 2014 @ 14:28 | |||
mysqli_result::fetch_all | ||||
Sitethief | dinsdag 3 juni 2014 @ 14:56 | |||
fetchAll(\PDO::FETCH_ASSOC) dan toch? | ||||
n8n | dinsdag 3 juni 2014 @ 14:59 | |||
if ($posts < 300 ? die(); : yolo); |