Light | woensdag 22 oktober 2014 @ 21:02 | |||||||
![]() 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! | ||||||||
Light | woensdag 22 oktober 2014 @ 21:10 | |||||||
Dat bedoel ik ![]() | ||||||||
wipes66 | woensdag 22 oktober 2014 @ 21:27 | |||||||
ja die strings in de eerste output die ik gaf klopte niet, maar de timestamps blijven hetzelfde en de volgorde ervan snap ik nog steeds niet helemaal. toen ik een unit test schreef ging ik er van uit dat amsterdam in het midden zou zitten qua timestamp voor "today", maar dat klopt dus niet ![]() | ||||||||
Aether | woensdag 22 oktober 2014 @ 22:03 | |||||||
Light gaf het al aan: timestamps gaan van UTC uit (tijdzone 0). Misschien dat het duidelijker is als UTC:
New York loopt 4 uur achter t.o.v. UTC. Als het daar middernacht is, is het 4 uur 's ochtends UTC. Sydney loopt 11 uur voor op UTC. Als het daar middernacht is, is het 24 - 11 = 13 uur 's middags UTC (omdat het op het moment van meten al een dag later is in Australië). Vanuit UTC gezien is Nederland de kleinste timestamp, daarna New York en dan Sydney. | ||||||||
Light | woensdag 22 oktober 2014 @ 22:18 | |||||||
Nee, Sydney is de kleinste, dan Nederland, en New York is de grootste. De reden dat het mis lijkt te gaan voor Sydney is dat het daar inmiddels 07:18 is op 23 oktober waar Nederland en New York nog in 22 oktober leven. | ||||||||
Light | woensdag 22 oktober 2014 @ 23:04 | |||||||
Amsterdam zit in het midden als je het over dezelfde dag hebt. Maar 'today' is niet voor alle tijdzones hetzelfde. Als je het over een uur weer probeert, is de timestamp van Sydney voor 'today' wel kleiner dan die van Amsterdam voor 'today'. | ||||||||
papernote | donderdag 23 oktober 2014 @ 09:01 | |||||||
En zowaar geschiedde:
| ||||||||
slacker_nl | donderdag 23 oktober 2014 @ 18:43 | |||||||
Wat wil je eigenlijk bereiken, dit lijkt namelijk op een unittest van DateTime zelf.. | ||||||||
wipes66 | donderdag 23 oktober 2014 @ 19:03 | |||||||
een class testen, die inderdaad niet veel meer dan datetime gebruikt. maar goed, het komt wel vaker voor dat je dingen test die gebruik maken van iets dat op zichzelf ook al getest wordt toch ![]() [ Bericht 0% gewijzigd door wipes66 op 23-10-2014 19:19:51 ] | ||||||||
Light | donderdag 23 oktober 2014 @ 22:05 | |||||||
Over het algemeen maak je dan gebruik van mocks. Die kun je namelijk configureren zodat ze precies doen wat je wilt en je niet afhankelijk bent van de interne werking van die class. | ||||||||
xaban06 | zaterdag 25 oktober 2014 @ 17:53 | |||||||
Iemand bekend met text uitlezen uit foto's? Rekening houdend met: - Je weet van te voren niet hoe groot de plaatje dus, kan altijd verschillend zijn. - Je weet wel de opbouw van de text, is altijd <xx> karakters lang. - Je weet de kleur van de tekst (zwart, maar zal uiteraard altijd een ander tint zwart zijn, want foto's). - Je weet de achtergrondkleur van de tekst. Zijn hier libraries voor? | ||||||||
bondage | zaterdag 25 oktober 2014 @ 18:05 | |||||||
Zoiets? http://sourceforge.net/projects/phpocr/ | ||||||||
xaban06 | zaterdag 25 oktober 2014 @ 18:23 | |||||||
Daarmee kan je tekst uit screenshots lezen, ik heb het echt over foto's. Geen screenshots oid. | ||||||||
Monolith | zaterdag 25 oktober 2014 @ 18:34 | |||||||
Nee, voor dat soort specifieke gevallen zijn geen libraries. Wat je natuurlijk zou kunnen doen is het voorbewerken van de afbeelding en dan een standaard OCR oplossing gebruiken. Als de achtergrondkleur van het plaatje altijd hetzelfde is, dan moet je vrij makkelijk kunnen vinden waar de tekst staat en dat vlak uit het plaatje in een nieuw plaatje kunnen stoppen bijvoorbeeld. | ||||||||
KomtTijd... | zaterdag 25 oktober 2014 @ 19:20 | |||||||
zijn het uploads? Zo ja zou je eventueel een javascript crop/rotate-tool kunnen gebruiken om de gebruiker zelf de tekst te laten croppen. | ||||||||
Darkomen | donderdag 30 oktober 2014 @ 11:34 | |||||||
Ik heb wat hulp nodig, ben bezig met een bashscriptje welke mysql aanroept en een variabele moet doorgeven aan een sql script. Dit ging mis dus heb ik alles terug gebracht naar de basics Commandline:
testSqlMetParamenter.sql:
Roep ik het volgende aan dan krijg ik wel een record, natuurlijk zonder de variabele mysql -h localhost -uUSERNAME --password=PASSWORD < ./testSqlMetParamenter.sql Iemand een idee wat ik fout doe? EDIT: fixed
[ Bericht 7% gewijzigd door Darkomen op 30-10-2014 11:40:48 ] | ||||||||
TwenteFC | vrijdag 31 oktober 2014 @ 00:56 | |||||||
![]() Nu in een uurtje dit er uit gerammeld, morgen maar eens kijken naar de winnaars berekening. En zorgen dat je/er ingezet wordt. ![]() Wanneer het af is zal ik de code wel op github gooien. | ||||||||
slacker_nl | vrijdag 31 oktober 2014 @ 08:46 | |||||||
Ken je dit al? https://www.cs.rochester.edu/~ferguson/poker/ipp.html | ||||||||
TwenteFC | vrijdag 31 oktober 2014 @ 18:19 | |||||||
Kende deze nog niet nee, ziet er wel handig uit. Maar ik ben stiekem een beetje eigenwijs en wil het even op mijn eigen manier doen ![]() | ||||||||
TwenteFC | zaterdag 1 november 2014 @ 17:18 | |||||||
![]() ![]() | ||||||||
xaban06 | zaterdag 1 november 2014 @ 21:04 | |||||||
Geeft het volgende weer (zonder de sterretjes):
Maar ik wil alleen de rijen zien waar een sterretje voor staat. Mijn auto weegt 1370. Ik vind in welke categorie deze door te kijken wat kleiner is dan 1370, dat is dus 1351. Alles daaronder wil ik niet zien. Hoe moet mijn query zijn? Ik kan wel GROUP BY `provincie` doen, maar dan krijg ik de verkeerde resultaat terug, namelijk:
| ||||||||
Monolith | zaterdag 1 november 2014 @ 21:13 | |||||||
Beetje onduidelijke inschrijving maar je wilt volgens mij toch gewoon WHERE gewichtstart = 1351 ipv < 1370 hebben? | ||||||||
Rockfire | zaterdag 1 november 2014 @ 21:22 | |||||||
| ||||||||
slacker_nl | zaterdag 1 november 2014 @ 21:31 | |||||||
Simplified:
Mogelijk zou je het met een join kunnen doen. Maar dat laat ik aan jou over. | ||||||||
xaban06 | zaterdag 1 november 2014 @ 21:38 | |||||||
Zit nu mobiel, kan niet testen, maar ik wil de resultaat van ieder provincie. Dus niet alleen de duurste provincie. | ||||||||
xaban06 | zaterdag 1 november 2014 @ 21:38 | |||||||
Deze zou wel eens kunnen werken. Thanks! | ||||||||
Rockfire | zaterdag 1 november 2014 @ 21:46 | |||||||
Die van slacker_nl is denk ik beter:
| ||||||||
slacker_nl | zaterdag 1 november 2014 @ 21:46 | |||||||
Eigenlijk wil je dit doen: https://dev.mysql.com/doc(...)olumn-group-row.html Het ging je toch om het gewicht, de subquery pakt de max van het gewicht en gaat die opzoeken. Als je dat per provincie wilt doen.. | ||||||||
xaban06 | zaterdag 1 november 2014 @ 22:30 | |||||||
![]() | ||||||||
Robuustheid | zondag 9 november 2014 @ 22:36 | |||||||
Een vraag:
Bij de exception ontbreekt de throw. Dan vraag ik mij af of de exception ook de string kan weergeven? | ||||||||
ralfie | zondag 9 november 2014 @ 22:53 | |||||||
throw gooit een exception naar de eerstvolgende errorhandler (een catch statement of een globale errorhandler). Zolang een exception niet gegooid wordt, zal er niks gevangen worden. Veel php function hebben de 'throw' ingebouwd. Mocht echo 'blah' een exception tegenkomen,creert deze een Exception() en throwt deze naar je catch statement. Jij hoeft dit niet expliciet te doen, tenzij je zelf de exception maakt:
| ||||||||
Robuustheid | maandag 10 november 2014 @ 12:11 | |||||||
Bedankt voor je duidelijke antwoord. Een nieuwe vraag. Sommigen van jullie kennen waarschijnlijk de spl_autoload_register, dat als er een fout ontstaat, een handeling uitgevoerd wordt. Levert dat ook niks op, dan wordt er alsnog een error weergegeven. Voorbeeld:
Stel, je instantieert een object met "$voorbeeld = new voorbeeld;" Maar de PHP kan geen class met voorbeeld vinden, omdat je hem niet geïncluded hebt. Dan probeert-ie eerst require_once(jemap/includes/php/voorbeeld.php), met daarin de class voorbeeld. Levert dat alsnog het gewenste resultaat op, dan wordt er geen error weergegeven. Zie ook dit: php.net/manual/en/function.spl-autoload-register.php Ik wil hetzelfde ook doen met objecten instatieren. Dus:
Dan is het niet meer nodig om eerst het object vooraf te instantieren met $voorbeeld = new voorbeeld. Alleen, dit werkt vreemd genoeg niet. Ik weet niet waar dat aan ligt. Iemand een idee? | ||||||||
Monolith | maandag 10 november 2014 @ 12:40 | |||||||
Zo uit m'n hoofd wordt die autoload enkel uitgevoerd bij het ontbreken van een class of interface definition, niet bij het niet bestaan van een variabele. | ||||||||
Robuustheid | maandag 10 november 2014 @ 12:55 | |||||||
Ah, dat verklaart! Dank. Zijn er evt. nog alternatieven, om een variable volgens bepaalde methode te declareren indien deze nog niet gedeclareerd is? | ||||||||
Monolith | maandag 10 november 2014 @ 12:58 | |||||||
Je kunt de error lvl setten en een custom error_handler definiëren. | ||||||||
Light | woensdag 12 november 2014 @ 00:32 | |||||||
Niet echt. Als je probeert te schrijven naar een variabele die niet bestaat, wordt de variabele aangemaakt. Als je een niet-bestaande variabele wilt lezen, wordt een E_NOTICE melding getriggerd (maar dat is afhankelijk van je error_reporting() instellingen). Als zo'n melding komt, kun je dat nog wel als nette melding naar de gebruiker tonen maar heb je geen kans meer om gewoon verder te gaan. Over het algemeen geeft het aan dat je iets niet goed doet als je probeert een niet-bestaande variabele te lezen (bijvoorbeeld een tikfout in de naam). Het is dan ook een goed idee om je error_reporting hierop stuk te laten gaan. En als je weet dat een variabele onder bepaalde omstandigheden wel of niet bestaat, kun je met isset() kijken of de variabele een waarde (anders dan null) heeft. | ||||||||
qu63 | woensdag 12 november 2014 @ 19:41 | |||||||
SQLtabel:
[ Bericht 37% gewijzigd door qu63 op 12-11-2014 19:47:03 ] | ||||||||
mstx | woensdag 12 november 2014 @ 19:51 | |||||||
On duplicate key update geeft 2 terug als een waarde is geupdate, zie manual. http://php.net/manual/en/mysqli.affected-rows.php 1e comment | ||||||||
qu63 | woensdag 12 november 2014 @ 20:03 | |||||||
Ah, de comments had ik niet bekeken. Thanks! | ||||||||
qu63 | woensdag 12 november 2014 @ 22:57 | |||||||
Hoe kan ik beste achterhalen welke van de onderstaande kolommen een nieuwe waarde hebben gekregen door deze query?
| ||||||||
Light | woensdag 12 november 2014 @ 23:10 | |||||||
Tip: Maak de id-kolom unsigned. Dan kun je er 2 keer zoveel records in kwijt (een auto-increment levert altijd positieve getallen op). Niet dat ik verwacht dat je in de buurt van de grens van een signed kolom komt, maar toch ![]() | ||||||||
qu63 | woensdag 12 november 2014 @ 23:23 | |||||||
Ik denk niet dat ik boven de 2147483647 id's uitkom ja ![]() Teller staat nu op 10.733 en zal niet veel meer stijgen ![]() | ||||||||
TwenteFC | donderdag 13 november 2014 @ 13:28 | |||||||
Je zou het ID veld misschien ook wel compleet kunnen verwijderen. | ||||||||
qu63 | donderdag 13 november 2014 @ 13:30 | |||||||
In dit voorbeeld wel ja ![]() | ||||||||
KomtTijd... | donderdag 13 november 2014 @ 13:41 | |||||||
| ||||||||
qu63 | donderdag 13 november 2014 @ 13:45 | |||||||
En deze uitvoeren voor de UPDATE neem ik aan? | ||||||||
KomtTijd... | donderdag 13 november 2014 @ 13:51 | |||||||
Jup. | ||||||||
qu63 | donderdag 13 november 2014 @ 13:54 | |||||||
Dan ga ik daar even mee puzzelen ![]() Thanks! | ||||||||
qu63 | donderdag 13 november 2014 @ 14:47 | |||||||
Als ik de query in PHPMyadmin draai dan zie ik ze wel ![]() | ||||||||
KomtTijd... | donderdag 13 november 2014 @ 14:48 | |||||||
een associative fetch doen. | ||||||||
qu63 | donderdag 13 november 2014 @ 14:50 | |||||||
Duh.. ![]() Dank u! | ||||||||
TwenteFC | vrijdag 14 november 2014 @ 18:27 | |||||||
Heeft iemand hier toevallig ervaring met Elasticsearch? | ||||||||
Monolith | vrijdag 14 november 2014 @ 18:33 | |||||||
Heel beperkt icm Logstash en Kibana. | ||||||||
TwenteFC | vrijdag 14 november 2014 @ 18:39 | |||||||
Dan kan jij misschien mijn vraag beantwoorden; Is het bruikbaar voor het doorzoeken van documenten met een X aantal verschillende die een verschillend type kunnen hebben. subdocumenten? En dan gaat het me vooral om het heel flexibel toepassen van dit document moet als child X hebben, en ook Y en Z. Voorbeeld; Notebook - Type: Electronica - Kleuren: Geel,Rood,Zwart,Groen - Kenmerken: USB3, Intel, AMD Wanneer ik dus filter op Rode AMD Electronica moet deze te voorschijn komen. Maar wanneer het Type dat niet is, dan wil ik hem ook niet zien. Maar het kan ook een optie zijn om dit product toch te tonen wanneer bijv. alleen de gezochte kleur niet beschikbaar is of als er gezocht wordt op USB2 | ||||||||
TwenteFC | vrijdag 14 november 2014 @ 18:42 | |||||||
![]() http://www.elasticsearch.(...)-filtered-query.html | ||||||||
Monolith | vrijdag 14 november 2014 @ 18:44 | |||||||
Je zou ook kunnen kijken naar faceted search in SOLR. Volgens mij is dat zo ongeveer wat je wilt. | ||||||||
TwenteFC | vrijdag 14 november 2014 @ 18:49 | |||||||
Dit is inderdaad exact wat ik wil, thx. Maar eens even mee gaan spelen. ![]() | ||||||||
wobbel | zaterdag 15 november 2014 @ 14:32 | |||||||
Hoe loop ik door een XML als deze heen? Ik wil alle productnames eruit halen en hun ID en deze in een array stoppen maar ik ben er nog niet helemaal achter hoe ik dat precies moet doen.
Met onderstaande code kan ik dmv print_r wel alle info laten zien, maar ik heb werkelijk geen idee hoe ik voor alles de specifieke data in een array stop. Het gaat dan met name hoe ik door de <bundleproducts> heen loop. Moet er dan een tweede foreach in mijn huidige foreach?
| ||||||||
slacker_nl | zaterdag 15 november 2014 @ 14:37 | |||||||
Array push? | ||||||||
wobbel | zaterdag 15 november 2014 @ 14:39 | |||||||
Op deze manier kan ik $products aanroepen als een array ![]() ![]() | ||||||||
Pakspul | zondag 16 november 2014 @ 16:13 | |||||||
Kan iemand mij uitleggen waarom ik een view bestand nodig heb wanneer ik JSON output genereer via JsonModel in Zend Framework 2? Ik heb een array en die gooi op eruit, de view voegt totaal niets toe ![]() Gelukkig kan ik ook geen voorbeelden vinden hoe het wel moet. Overal zeggen ze: "gebruik dit en je bent klaar".
Dit werkt niet! Nouja, het werkt wel. Hij toont de layout niet, maar de view mag ook optieven en hij moet mij Json string tonen. | ||||||||
papernote | zondag 16 november 2014 @ 16:33 | |||||||
Gebruik de json view helper: http://framework.zend.com(...)ew.helpers.json.html | ||||||||
qu63 | zondag 16 november 2014 @ 17:27 | |||||||
Kan dit niet eenvoudiger/beter?
$date[0] bevat Jan-Dec $date[1] bevat een jaartal in 4 cijfers (2014) $airtime bevat een tijd (09:00 pm) $timezone bevat de tijdzone (America/New_York) | ||||||||
Aether | zaterdag 22 november 2014 @ 17:34 | |||||||
What’s New in MySQL 5.7? | ||||||||
Reemi | zaterdag 22 november 2014 @ 18:51 | |||||||
nvm. | ||||||||
TwenteFC | woensdag 26 november 2014 @ 21:34 | |||||||
![]() https://github.com/laravel/laravel/commits/develop ![]() | ||||||||
Feola | vrijdag 28 november 2014 @ 15:36 | |||||||
Wat zouden de makkelijkste manier zijn wanneer je een website hebt met daarin 1000'en querys die nog met mysq_query opgemaakt zijn en je wilt naar pdo overgaan? Is hier een oplossing voor of ontkom je er niet aan alles te herschrijven? | ||||||||
KomtTijd... | vrijdag 28 november 2014 @ 15:55 | |||||||
Waarom zou je dat uberhaupt willen? | ||||||||
#ANONIEM | vrijdag 28 november 2014 @ 17:47 | |||||||
Veiligheid? Depreciation? Het is wel mogelijk, maar dan moet je denk een veel te ingewikkelde regex schrijven ![]() Zul je toch handmatig moeten doen. | ||||||||
KomtTijd... | vrijdag 28 november 2014 @ 18:00 | |||||||
Als je applicatie niet veilig is moet je het lek fixxen, niet rucksichtsloss je database driver vervangen. En functies worden júíst deprecated (ipv verwijderd) zodat bestaande applicaties niet aangepast hoeven worden. Als je overgaat op PDO moet je je queries ook parameteriseren. Althans, niet per se, maar als je dat niet doet heeft het écht geen enkele zin. En eigenlijk gewoon (zo veel mogelijk) OO gaan werken. Overgaan op PDO is dus veel ingrijpender dan alleen maar een andere database-connectie. | ||||||||
#ANONIEM | vrijdag 28 november 2014 @ 21:50 | |||||||
Maar die oude mysql-functies worden wel degelijk verwijderd toch? | ||||||||
Tijn | vrijdag 28 november 2014 @ 22:37 | |||||||
Is het niet al weg in 5.6? | ||||||||
#ANONIEM | vrijdag 28 november 2014 @ 22:38 | |||||||
Dan is het toch niet deprecated meer maar echt weg? Kan me voorstellen dat je dan als bedrijf wilt switchen van mysql* naar PDO. | ||||||||
mstx | vrijdag 28 november 2014 @ 22:39 | |||||||
Als het daar om gaat kun je gewoon alle mysql_* functies vervangen door mysqli_*. | ||||||||
#ANONIEM | vrijdag 28 november 2014 @ 22:39 | |||||||
Dat kan ook ja, maar ik kan me voorstellen dat mensen het dan gelijk helemaal goed willen doen. ![]() | ||||||||
mstx | vrijdag 28 november 2014 @ 22:41 | |||||||
Onze klanten in ieder geval niet. Als ze kunnen kiezen tussen het vervangen door mysqli functies in 5 minuten of alle queries ombouwen naar pdo met parameters voor tientallen uren werk weet ik wel wat ze kiezen, want niemand ziet het verschil. | ||||||||
TwenteFC | vrijdag 28 november 2014 @ 22:55 | |||||||
![]() | ||||||||
Tijn | vrijdag 28 november 2014 @ 23:31 | |||||||
Erm... Nee. Echt niemand gaat betalen voor het ombouwen van een applicatie die uiteindelijk precies hetzelfde kan als daarvoor. | ||||||||
Monolith | vrijdag 28 november 2014 @ 23:35 | |||||||
1000'en keren dergelijke functies gebruiken klinkt vooral als een heel erg slecht ontworpen applicatie. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 01:50 | |||||||
Je moest eens weten wat voor gedrochten er bestaan. Code die compleet onveilig is vanwege luiheid, tijdsgebrek, etc. Zeker met code die al verouderd is heb je vaak problemen of met slecht gebouwde CMS systemen (joomla). | ||||||||
Monolith | zaterdag 29 november 2014 @ 11:30 | |||||||
Ik ben ermee bekend hoor. Doe zelf de laatste jaren gelukkig niets meer met PHP, maar ik weet wat voor een ellende daarmee geproduceerd wordt. ![]() | ||||||||
slacker_nl | zaterdag 29 november 2014 @ 12:07 | |||||||
Worden jullie PHP'ers niet gek van die comtinue discussie over PDO vs mysql*_-functies? Ik verbaas me echt continue dat er zoveel over gesproken moet worden. Gebruik PDO, 10 jaar geleden was dat het devies en nog steeds heb je idioten die het niet gebruiken. Waarom? | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:09 | |||||||
Omdat er nog veel oude tutorials en dergelijke op internet circuleren denk ik. | ||||||||
Reemi | zaterdag 29 november 2014 @ 12:11 | |||||||
Goed punt inderdaad. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:14 | |||||||
Daarbij is PHP ook echt de taal bij uitstek waar veel mensen gewoon een beetje mee experimenteren. Ik heb het idee dat weinig mensen echt een serieus boek over PHP lezen. Veel mensen hebben verschillende stijlen van werken. Als ik iets nodig heb kijk ik op php.net naar documentatie. De beginnerlingen zoeken sneller dingen als: "Mysql php database connection tutorial" Als je dan een beetje op verkeerde sites komt, zie je al snel dingen als dit: http://www.freewebmasterhelp.com/tutorials/phpmysql/4 | ||||||||
slacker_nl | zaterdag 29 november 2014 @ 12:22 | |||||||
Dat is geen argument imo. Of... misschien ook wel. Ze hadden dus veeeeeeel eerder die mysql*_ meuk moeten deprecaten en verwijderen. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:24 | |||||||
Mee eens. ![]() | ||||||||
Monolith | zaterdag 29 november 2014 @ 12:27 | |||||||
Probleem is dat de grootste kracht van PHP ook gelijk de grootste zwakte is, praktisch iedere idioot kan ermee aan de slag. ![]() | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:29 | |||||||
PDO heeft een iets hogere leercirve. Mysql_* is lekker makkelijk. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:31 | |||||||
Eigenlijk wel ja. ![]() | ||||||||
slacker_nl | zaterdag 29 november 2014 @ 12:32 | |||||||
Hogere leercurve? Explain. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:32 | |||||||
Zelf vind ik PDO echt heel makkelijk in gebruik. Ik kan het me echt niet voorstellen dat mensen daar moeite mee hebben. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:38 | |||||||
Prepared statements en shit. En OO en classes begreep ik echt nog niet in het begin (toen ik nog mysql_* gebruikte) | ||||||||
Tijn | zaterdag 29 november 2014 @ 12:48 | |||||||
Ik word er niet gek van, want ik heb niks te maken met wat anderen doen ![]() [ Bericht 0% gewijzigd door Tijn op 29-11-2014 13:08:54 ] | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 12:52 | |||||||
Opvallend trouwens. PHP-programmeurs verdienen gemiddeld minder: http://tweakers.net/revie(...)erdienen-icters.html [ Bericht 1% gewijzigd door #ANONIEM op 29-11-2014 12:53:05 ] | ||||||||
Tijn | zaterdag 29 november 2014 @ 13:10 | |||||||
Kwestie van vraag en aanbod. Als je iets kan dat weinig anderen kunnen, kun je een hoger salaris vragen. Scripten in PHP is niet een voorbeeld van zoiets ![]() | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 13:12 | |||||||
Wellicht ja. ![]() Ik denk dat mensen die echt heel goed met bepaalde frameworks kunnen werken en echt goed OOP in PHP kunnen programmeren wel redelijk gelijklopen. | ||||||||
KomtTijd... | zaterdag 29 november 2014 @ 15:03 | |||||||
Persoonlijk vind ik PDO ook makkelijker dan de oude database functies, en ik zou ook iedereen aanraden alleen nog pdo te gebruiken als een ORM class geen optie is. Maar dat betekent niet dat je goedwerkende applicaties moet gaan ombouwen puur voor The sake of it. If it aint broken, don't fix it! | ||||||||
papernote | zaterdag 29 november 2014 @ 15:07 | |||||||
"if it ain't broken, don't fix it" versus "if you stand still, you fall behind". Persoonlijk ben ik vóór actief onderhoud aan applicaties, ook al zijn ze niet "broken". Updaten en het geleidelijk inbrengen van nieuwe technieken hoort daar bij, naar mijn mening. | ||||||||
KomtTijd... | zaterdag 29 november 2014 @ 15:17 | |||||||
Ja geleidelijk inbrengen idd. En dan kom je op een gegeven moment op een punt dat je die laatste paar functies ook maar gaat refactoren. Maar dat is iets anders dan een hele applicatie omschrijven puur omdat het kan. edit: het ligt er ook aan wat voor applicatie het is. Bij een proprietary maatwerk product geldt eerder het eerste, bij een opensource massaproduct absoluut dat laatste. [ Bericht 8% gewijzigd door KomtTijd... op 29-11-2014 17:54:57 ] | ||||||||
KomtTijd... | zaterdag 29 november 2014 @ 17:51 | |||||||
Dat denk ik ook ja. Maar je hebt met PHP natuurlijk wel veel van die veredelde ammateurs (zoals ondergetekende ![]() | ||||||||
Monolith | zaterdag 29 november 2014 @ 18:09 | |||||||
Punt is natuurlijk wel dat het toepassingsgebied relatief beperkt is. Je zult ook niet bepaald veel PHP-mensen tegenkomen die zich bezighouden net zaken als Enterprise architecture e.d. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 20:01 | |||||||
Owja nog iets leuks, mijn baas weigert php code op linux servers te draaien, omdat hij niet weet hoe hij deze moet instellen... Nu constant problemen met rechten en bullshit. | ||||||||
Monolith | zaterdag 29 november 2014 @ 20:04 | |||||||
Ik weet niet of ik daar heel hard om moet lachen of juist huilen. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 20:08 | |||||||
![]() ![]() ![]() | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 20:18 | |||||||
Dat krijg je als een niet technisch persoon je baas is xD Zolang hij me betaald vind ik het best, ik blijf er alleen wel over zeuren. Hier wordt je nog vredrietiger van: Hij laat sommige klanten eigen code op dezelfde server draaien... Dus ook Joomla en Wordpress... Afgelopen week is de server op de blacklist gekomen vanwege gehackte Joomla sites die al jaren onbeveiligd staan. Owja en de server draait letterlijk op het OS IPV een virtuele server... [ Bericht 2% gewijzigd door #ANONIEM op 29-11-2014 20:21:29 ] | ||||||||
papernote | zaterdag 29 november 2014 @ 20:36 | |||||||
Je baas moet zich, als niet-technisch persoon, daar niet mee bemoeien. En jij moet de ballen hebben om dat tegen 'm te zeggen. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 20:38 | |||||||
Hebben mijn collega's al jaren daarvoor gedaan, maar hij luistert niet ![]() Ik werk er pas 2 maanden xD | ||||||||
papernote | zaterdag 29 november 2014 @ 20:40 | |||||||
Dan is hij geen baas, maar een schijt-irritante bemoeial die ontslagen moet worden. Een goede baas weet wanneer hij z'n bek moet houden. Zeker als er personeel met meer kennis rondloopt. Maar hij is zeker zo'n baas die denkt alles zelf beter te weten en z'n werknemers meer als uitvoerende slaven ziet, dan als mensen die ook zelfstandig iets kunnen? Ik zou maar vast uitkijken naar een nieuwe plek. | ||||||||
bondage | zaterdag 29 november 2014 @ 20:40 | |||||||
Ga maar vast leren in .net te programmeren. | ||||||||
KomtTijd... | zaterdag 29 november 2014 @ 20:41 | |||||||
Daar zou je je zelfs als programmeur niet mee bezig hoeven houden. Regel een managed server als er geen server beheerder is. | ||||||||
papernote | zaterdag 29 november 2014 @ 20:41 | |||||||
Als je kunt programmeren, dan is de taal irrelevant. | ||||||||
bondage | zaterdag 29 november 2014 @ 20:42 | |||||||
Andere namen voor functies etc. Moet je toch ff leren. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 20:44 | |||||||
Het is zijn bedrijf, maar volgende week gaan we sowieso ff praten over wat dingen die niet echt kosten efficient zijn. Het is meer dat hij geen tijd wil steken en het opnieuw opzetten van een server (ze draaien bij ons op locatie). Nouja we hebben heel veel vrijheid, ik mocht zelf een PHP framework uitkiezen om een nieuwe SAAS applicatie in te schrijven. Daar zit er ook 1 van ![]() Nouja ik vind serverbeheer niet erg om te doen, maar het moet gewoon goed werken. | ||||||||
bondage | zaterdag 29 november 2014 @ 20:47 | |||||||
Dat is de grap natuurlijk ![]() ![]() | ||||||||
Monolith | zaterdag 29 november 2014 @ 20:48 | |||||||
Als je enkel PHP kent gaan zaken als threading en concurrency je nog wel tegenvallen hoor. | ||||||||
KomtTijd... | zaterdag 29 november 2014 @ 20:48 | |||||||
Ik ook niet, maar dan moet je er wel de tijd voor hebben/krijgen om er ook echt wat aan te doen zo af en toe. Kortom ik ben blij dat wij dat inmiddels allemaal uitbesteed hebben ondanks dat het wel eens lastig is dat je niet FF snel iets kunt installeren ofzo... | ||||||||
papernote | zaterdag 29 november 2014 @ 20:50 | |||||||
Dan kun je dus niet programmeren. | ||||||||
KomtTijd... | zaterdag 29 november 2014 @ 20:51 | |||||||
![]() | ||||||||
Monolith | zaterdag 29 november 2014 @ 20:52 | |||||||
Prolog, Lisp, cobol kun je ook gewoon met enkel imperatieve ervaring? | ||||||||
bondage | zaterdag 29 november 2014 @ 20:54 | |||||||
Denk dat het weinig zegt over hoe goed iemand kan programmeren. Het is maar net wat je gewend bent. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 20:59 | |||||||
Ahww dat valt bij jou toch reuze mee? Maar inderdaad. Dat denk ik ook. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 21:05 | |||||||
Ik snap ook niet wat het voordeel van .net over andere talen zou moeten zijn... | ||||||||
papernote | zaterdag 29 november 2014 @ 21:07 | |||||||
![]() Een goede opleiding bevat alle programmeerparadigma's. Een goede programmeur kent alle paradigma's, al zal door ervaring en gebruik het ene er wat beter in zitten dan het andere. Maar iemand die zich "programmeur" noemt, maar nooit verder is gekomen dan in z'n vrije tijd wat html rondslepen in visuele editor van Frontpage zal daar inderdaad moeite mee hebben. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 21:08 | |||||||
.net is een framework, geen taal. Het is een mooi ecosysteem en C# is een fijne taal. Groetjes van een MS-hater. ![]() | ||||||||
Monolith | zaterdag 29 november 2014 @ 21:11 | |||||||
Dat gaat dan over iemand met een goede opleiding. In principe kan iemand een prima programmeur zijn zonder formele opleiding. Bovendien raak je tijdens een opleiding echt nog maar de basis aan van veel zaken en leer je veel dingen pas in de praktijk. Simpelweg roepen dat een goede programmeur alles kan is was te kort door de bocht. | ||||||||
#ANONIEM | zaterdag 29 november 2014 @ 21:21 | |||||||
Ik heb zelf ook nog nooit een opleiding ervoor gedaan, sterker nog die was er gewoon niet. Die kwamen pas 2 jaar nadat ik al van school af was. | ||||||||
qu63 | zaterdag 29 november 2014 @ 21:56 | |||||||
Wanneer kan je dan wel programmeren? Als je maar beheerst wat je nodig hebt voor je taak is t goed, toch? http://www.quora.com/How-(...)er/George-Gonzalez-5 | ||||||||
remi1986 | zondag 30 november 2014 @ 06:02 | |||||||
precies .. of het efficiënt, structureel en veilig is, om maar wat dingen te noemen, maakt dan ook niet uit ![]() EDIT: heb 2-3 maanden geleden zarGon geholpen met zijn FOK! crew systeem. Hij is daarbij geholpen door mensen van FOK! die er zogenaamd verstand van hebben ![]() - PHP en HTML kriskras door elkaar, waardoor je de queries tussen de cellen vandaan kan vissen - Ene keer gebruik gemaakt van de mysql_ functies, de andere keer weer PDO (soms in 1 bestand ![]() - In ieder bestand een nieuwe mysql_connect of PDO object. - Het verkeerd gebruik maken van de PDO functies. SQL injectie is niet meer mogelijk, mits je het goed toepast. Zag een query met ->prepare("SELECT ... FROM WHERE veld = '".$phpvariabele.'" i.p.v. placeholders/labels te gebruiken). - In index.php werd een $_GET variabele opgevangen en in een mysql_ query gegooid, zonder een escape_string er omheen. Ik ben toen voor hem overnieuw begonnen, en na 24 uur was ik verder dan hij was, na maanden werk. Ja dat wat er was, werkte en zou voldoen aan de taak, maar of je het vakkundig PHP kan noemen? [ Bericht 21% gewijzigd door remi1986 op 30-11-2014 06:44:07 ] | ||||||||
remi1986 | zondag 30 november 2014 @ 06:55 | |||||||
Kom op KomtTijd. Je doet in heel DIG alsof je overal verstand van hebt... Deprecated betekent dat de functie in een volgende versie er niet meer is (ja verwijderd ja). Heb je een groot probleem als je alles met mysql_ hebt gemaakt en je host opeens aankondigt over te gaan op MySQL 5.5. Ik weet ook dat dit niet van de één op de andere dag gebeurt, maar vroeg of laat upgraden ze allemaal. Dan ben je dus te laat. | ||||||||
remi1986 | zondag 30 november 2014 @ 07:00 | |||||||
de mensen die nog echt PHP/MySQL hebben geleerd, zouden met PDO geen moeite moeten hebben. Vind het er allemaal juist makkelijker op geworden. Echter, doordat veel mensen zich een bepaald framework eigen maken en zich vervolgens tot PHP Programmeur bekronen, zijn er steeds minder mensen die nog standaard PHP en queries kunnen schrijven. Dat hebben we tijd terug gezien bij ons op het werk toen we een nieuwe developer zochten. | ||||||||
remi1986 | zondag 30 november 2014 @ 07:13 | |||||||
als je servers tot de belangrijkste onderdelen van je bedrijf behoren en je klanten afhankelijk zijn daarvan, neem je jezelf gewoon niet serieus als je dat zelf niet in beheer hebt. Als er een server uitligt, moet je vervolgens gaan wachten tot die andere partij het oplost. Zelf ff inloggen via SSH en een restart doen is paar seconden werk. En serverbeheer is helemaal niet moeilijk, en al helemaal niet als het allemaal goed gedocumenteerd is. Toen ik begon bij het bedrijf waar ik nu werk, kreeg ik een aparte pc en werd mij verplicht Gentoo te gaan leren en te gaan stoeien met dingen waar je dagelijks mee te maken kan krijgen. We hebben weleens gehad dat de MySQL replica helemaal de mist in ging. Dan is het heerlijk als je dat zelf binnen een paar minuten hebt opgelost i.p.v. maar hopen dat die andere partij het doet. | ||||||||
qu63 | zondag 30 november 2014 @ 13:48 | |||||||
Dat viel voor mij onder beheersen ![]() | ||||||||
Monolith | zondag 30 november 2014 @ 13:55 | |||||||
Sorry, maar dat is echt volstrekte kolder. Het is veel makkelijker om een gespecialiseerde externe partij te hebben met 24/7 ondersteuning, uptime garantie middels SLA's, enzovoort. | ||||||||
TwenteFC | zondag 30 november 2014 @ 15:55 | |||||||
Wij schieten gewoon een ticket in bij TRUE en het is sneller opgelost dan ik kan uitzoeken wat er allemaal precies mis is. Als je een partij hebt met professionals die dit 24/7 doen, dan moet je zelf niet gaan lopen aan kloten. | ||||||||
remi1986 | zondag 30 november 2014 @ 16:06 | |||||||
Wij willen niet dat onze klanten de dupe worden van fouten van een derde partij. Onze klanten zijn afhankelijk van het systeem, anders kunnen die de dag naar huis. En als je zelf de expertise in huis hebt, waarom dan uitbesteden. En daarbij, vind ik het wel leuk om zo nu en dan met wat nieuwe dingen bezig te zijn. Hele dag code kloppen is ook niet alles | ||||||||
TwenteFC | zondag 30 november 2014 @ 16:15 | |||||||
Monitoren jullie ook alles zelf dan? Wanneer er 4 uur s`nachts iets mis gaat. | ||||||||
remi1986 | zondag 30 november 2014 @ 16:22 | |||||||
Wij monitoren inderdaad alles zelf. Tijdje terug nog om 01:30 in het datacenter gestaan. We kwamen er remote niet meer in. Die server was helemaal gecrashed, dus moesten we er heen | ||||||||
TwenteFC | zondag 30 november 2014 @ 16:23 | |||||||
En hoelang duurde het voordat jullie ter plaatse waren? ![]() | ||||||||
remi1986 | zondag 30 november 2014 @ 16:27 | |||||||
20 min, half uurtje misschien? We hebben trouwens ook een Master-Slave systeem. Als er één server het begeeft, neemt de andere het over (die servers staan in weer een ander datacenter). De klant zou er dan ook helemaal niets van gemerkt hebben, want het verkeer werd al automatisch doorgeleid naar die andere server. | ||||||||
KomtTijd... | zondag 30 november 2014 @ 20:55 | |||||||
Dat is niet zo, er zijn meerdere voorbeelden van functies die meerdere versies deprecated geweest zijn of nog steeds zijn. Ook de mysql_ functies die sinds 5.5 deprecated zijn, zitten er in 5.6 nog steeds in. Daarbij, zeker als je maatwerk producten draait, is het helemaal niet gek om gewoon een oudere PHP versie te blijven draaien als dat beter uitkomt. Alleen bij massaproducten of applicaties waar actief aan ontwikkeld wordt heeft het zin om grootscheepse refactor acties te doen. Dan kun je die moeite namelijk nog terugverdienen. | ||||||||
KomtTijd... | zondag 30 november 2014 @ 21:00 | |||||||
Zoals ik al zei, dat werkt alleen als je daar de capaciteiten toe hebt. Heel veel ontwikkelaars zullen zich niet met serverbeheer kunnen, willen of mogen bemoeien en lang niet alle softwareproducenten hebben een aparte server beheerder in dienst. En dan ben je echt beter af met een managed server van een hosting partner dan dat je zelf ergens een vergeten bak in een stoffige berging gooit waar nooit iemand naar omkijkt. | ||||||||
TwenteFC | zondag 30 november 2014 @ 21:22 | |||||||
![]() | ||||||||
Nattekat | maandag 1 december 2014 @ 17:14 | |||||||
Ik ben een site aan het maken waarbij het de bedoeling is om iedere keer als de zoveelste rij erbij komt de eerste rij te verwijderen. Nou is dit al werkend gekregen, maar ik kom er maar niet uit hoe ik de IDs weer opnieuw kan rangschrikken, want nu begint de eerste rij met 2 ipv 1. Is er een manier om dit voor elkaar te krijgen? ![]() | ||||||||
KomtTijd... | maandag 1 december 2014 @ 17:14 | |||||||
Goftedomme zeg. Moet ineens hals over kop wat klussen aan een oude applicatie (die er over een paar maanden hopelijk uit gaat), blijkt gewoon 3 kwart van de tabellen geen enkele index te hebben. Goh, dus daarom duren de queries een halve seconde ![]() | ||||||||
KomtTijd... | maandag 1 december 2014 @ 17:18 | |||||||
Lijkt me dat je dat in je code wilt oplossen en niet in de DB. In de DB blijven ID's (normaliter) gewoon uniek. | ||||||||
Monolith | maandag 1 december 2014 @ 17:20 | |||||||
Definieer rangschikken. Je kunt natuurlijk vrij eenvoudig gewoon "UPDATE table SET id=id-1" doen na het verwijderen van de eerste en toevoegen van de nieuwe rij, maar doorgaans is het niet zo bijster handig om op een dergelijke manier met IDs te gaan lopen klooien. | ||||||||
Nattekat | maandag 1 december 2014 @ 17:21 | |||||||
Was ik al bang voor. Heb wel wat gelezen over het herschrikken, maar niks gevonden dat werkt. Om het simpel te houden was het idee een enkele query te hebben om ipv id 2 tot 101 id 1 tot 100 te hebben, dat wil ik ook bereiken. | ||||||||
Monolith | maandag 1 december 2014 @ 17:24 | |||||||
Je wilt dus gewoon 'de eerste 100' hebben? | ||||||||
KomtTijd... | maandag 1 december 2014 @ 17:24 | |||||||
als je gewoon een query maakt met LIMIT(0,100), dan heb je dat toch? | ||||||||
Monolith | maandag 1 december 2014 @ 17:25 | |||||||
En een ORDER BY ID voor het geval dat niet de default is. | ||||||||
Nattekat | maandag 1 december 2014 @ 17:27 | |||||||
Het probleem daarmee is dat er dan onnodige gegevens behouden blijven, en dat is niet wat ik wil bereiken. | ||||||||
Monolith | maandag 1 december 2014 @ 17:27 | |||||||
Welke onnodige gegevens blijven er behouden? | ||||||||
KomtTijd... | maandag 1 december 2014 @ 17:28 | |||||||
Ik ben altijd groot voorstander van het zoveel mogelijk bewaren van (onnodige) gegevens. Waarom weggooien als je er geen last van hebt. | ||||||||
#ANONIEM | maandag 1 december 2014 @ 17:45 | |||||||
Inderdaad. ![]() Vooral in een database waar alles toch netjes gestructureerd is. | ||||||||
TwenteFC | maandag 1 december 2014 @ 18:09 | |||||||
![]() | ||||||||
Nattekat | maandag 1 december 2014 @ 18:11 | |||||||
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem. Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql. | ||||||||
#ANONIEM | maandag 1 december 2014 @ 18:12 | |||||||
Je data kun je super makkelijk selecteren met query's, dus de hoeveelheid maakt niet zoveel uit. ![]() | ||||||||
TwenteFC | maandag 1 december 2014 @ 18:12 | |||||||
Gewoon softdeleten, heeft bij mij vaak ook de voorkeur boven verwijderen. | ||||||||
KomtTijd... | maandag 1 december 2014 @ 18:19 | |||||||
Dat wel ja. Gelukkig loop ik nog tegen genoeg andere problemen aan om dat weer te compenseren ![]() Het is ook niet de bedoeling dat je dagelijks via database-management tools in de database gaat kijken of je data er niet slordig uit ziet. Databases zijn er niet om er netjes uit te zien, daar heb je je queries voor. Dit moet ik mijn baas ook nog wel eens uitleggen ![]() | ||||||||
Monolith | maandag 1 december 2014 @ 18:54 | |||||||
Nou ja, het kan natuurlijk wel degelijk voor traagheid zorgen wanneer overbodige data niet wordt opgeruimd. Zeker bij grotere hoeveelheden data wordt archiveren of aggregeren op een gegeven moment gewoon noodzaak. Het voordeel van niet verwijderen maar bijvoorbeeld met een deleted flag te werken is dan weer dat je de data gewoon weer zichtbaar kunt maken. | ||||||||
KomtTijd... | dinsdag 9 december 2014 @ 15:20 | |||||||
Wat is nou een relaxte databasetool voor als je PHPMyAdmin zat begint te raken? Webbased of linux, en een beetje eenvoudig en overzichtelijk. Heb wel eens wat met HeidiSql maar die vond ik ook irritant (en lelijk). [ Bericht 48% gewijzigd door KomtTijd... op 09-12-2014 15:41:18 ] | ||||||||
Monolith | dinsdag 9 december 2014 @ 15:44 | |||||||
Gewoon MySQL workbench? | ||||||||
ursel | dinsdag 9 december 2014 @ 15:51 | |||||||
werk thuis met sqlYog | ||||||||
Juicyhil | dinsdag 9 december 2014 @ 15:57 | |||||||
Alleen jammer dat het zo'n vreselijk trage en buggy applicatie is. Vind Sequel Pro ook wel fijn werken ![]() | ||||||||
KomtTijd... | dinsdag 9 december 2014 @ 16:16 | |||||||
Ik kom er net achter dat PhpStorm ook een ingebouwde DB manager heeft. Ga ik ook eens proberen. | ||||||||
#ANONIEM | dinsdag 9 december 2014 @ 16:31 | |||||||
Hier heeft het de bijnaam MySQL CrashBench gekregen. ![]() Kun je wel mooie ERD's in maken. | ||||||||
Monolith | dinsdag 9 december 2014 @ 16:36 | |||||||
Ik doe zelf eigenlijk erg weinig DBA werk de laatste jaren, zeker op SQL gebied. Hooguit wat met RoboMongo en dergelijke. | ||||||||
Rockfire | dinsdag 9 december 2014 @ 16:53 | |||||||
HeidiSQL ![]() | ||||||||
KomtTijd... | dinsdag 9 december 2014 @ 16:58 | |||||||
Ik hoef niets ingewikkelds, moet gewoon af en toe kunnen zien wat er in de database gebeurt als ik mijn code uitvoer. Of wat testrecords verwijderen ofzo. Op zich is PhpStormPhpMyAdmin prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van. [ Bericht 5% gewijzigd door KomtTijd... op 09-12-2014 17:55:19 ] | ||||||||
Rockfire | dinsdag 9 december 2014 @ 16:59 | |||||||
Adminer misschien? http://www.adminer.org/ Hoewel ik dat zelf niet echt wat vind | ||||||||
#ANONIEM | dinsdag 9 december 2014 @ 17:54 | |||||||
Waarom ben je phpmyadmin zat dan? | ||||||||
KomtTijd... | dinsdag 9 december 2014 @ 17:55 | |||||||
sorry zie edit ![]() | ||||||||
TwenteFC | dinsdag 9 december 2014 @ 18:48 | |||||||
Leuk dat je PHPStorm wegstreept, je kan in PHPStorm je database sources toevoegen en dan heb je daar ook een autocomplete op. Verder gebruik zelf ook HeidiSQL zoals Rockfire zegt. ![]() | ||||||||
#ANONIEM | dinsdag 9 december 2014 @ 19:24 | |||||||
HeidiSQL draait in Wine op Linux. ![]() | ||||||||
MrNiles | maandag 29 december 2014 @ 21:58 | |||||||
ik wil graag uit verschillende folders 1 image halen heb nu dit, maar dan krijg ik toch alle foto's te zien met toevoegen van => $value kom ik er ook niet aan uit Hie kan ik dit het beste oplossen?
| ||||||||
#ANONIEM | maandag 29 december 2014 @ 22:06 | |||||||
Je checkt niet op index. | ||||||||
MrNiles | maandag 29 december 2014 @ 22:09 | |||||||
iets in deze richting? | ||||||||
#ANONIEM | maandag 29 december 2014 @ 22:10 | |||||||
Value is de index. Je wil altijd alleen de eerste index hebben, dus moet je value checken op 0. [ Bericht 1% gewijzigd door #ANONIEM op 29-12-2014 22:10:35 ] | ||||||||
MrNiles | maandag 29 december 2014 @ 22:20 | |||||||
maar dan krijg ik alle indexen te zien volgens mij nog even doorspelen nog een duidelijk tip? als ik dit aanpas
dan krijg ik wel de eerste foto, maar alleen van de folder | ||||||||
Monolith | maandag 29 december 2014 @ 22:22 | |||||||
value => image in plaats van andersom. | ||||||||
MrNiles | maandag 29 december 2014 @ 22:23 | |||||||
bijna een snelle edit gedaan...heb ik dus gedaan maar dan krijg ik alleen de eerste foto van de eerste folder | ||||||||
mstx | maandag 29 december 2014 @ 22:23 | |||||||
Ja of je echo't gewoon $images[0] ![]() | ||||||||
#ANONIEM | maandag 29 december 2014 @ 22:24 | |||||||
Laat TS ff lekker kutten met arrays, anders snapt hij het nooit ![]() | ||||||||
mstx | maandag 29 december 2014 @ 22:25 | |||||||
dan moet je eerst een readdir doen van de root map, door de mappen loopen en per map de afbeeldingen ophalen en de eerste tonen. | ||||||||
Monolith | maandag 29 december 2014 @ 22:26 | |||||||
Even uitzoeken hoe globs werken en dan toepassen op je directory structuur. In een glob matcht ** alles inclusief directory separators en * alles behalve directory separators. | ||||||||
MrNiles | maandag 29 december 2014 @ 22:28 | |||||||
Die had ik al eens geprobeerd, maar dan krijg ik een loop van foto1 uit folder1, geen andere folders Zeker waar | ||||||||
Aether | maandag 12 januari 2015 @ 11:44 | |||||||
Voor als iemand testgegevens nodig heeft: http://www.generatedata.com/ | ||||||||
TwenteFC | maandag 12 januari 2015 @ 21:59 | |||||||
https://github.com/fzaninotto/Faker | ||||||||
Chandler | donderdag 15 januari 2015 @ 10:14 | |||||||
Korte vraag mbt zoeken op grote tabellen. Voor een vriend mag ik een importeer scriptje schrijven voor het importeren van ruim 7 miljoen videos met oa de volgende gegevens titel, tags, duur Nu heb ik al een scriptje geschreven die dit alles importeert in een database tabel waarbij ik titel, tags als fulltext indexeer en wil apart daarvan de duur (lengte van het filmpje) ook nog gaan indexeren (zodat de gebruiker daar ook op kan zoeken) Nu heb ik net een query uitgevoerd op deze tabel en dat duurde echt erg lang Tabel: 7,217,116 MyISAM latin1_swedish_ci 4,8 GiB
Nu duurt de volgende query:
Met limit 0,30 duurt deze query 0.0240 secs Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel? | ||||||||
Reemi | donderdag 15 januari 2015 @ 10:17 | |||||||
Ik zou sowieso de tags los opslaan in een andere tabel, in plaats van als één string in een kolom. Dus tag-video_id paren. Dat zal inderdaad al een stuk sneller worden. | ||||||||
mstx | donderdag 15 januari 2015 @ 10:17 | |||||||
Een LIKE beginnend met % is altijd traag. Tags in een aparte tabel en een koppeltabel tussen tags en videos is de beste oplossing. Dat scheelt je ook nog een boel dubbele data. | ||||||||
bondage | donderdag 15 januari 2015 @ 10:54 | |||||||
Ik heb zelf slechte ervaringen met zoeken in grote tabellen, zowel MyISAM als InnoDB. Is dit misschien een optie? http://astellar.com/2011/(...)-search-with-sphinx/ | ||||||||
Chandler | donderdag 15 januari 2015 @ 11:39 | |||||||
Ik ga eens een import draaien die tags in een apart tabel zetten + een tabel voor video/tag links. Eens kijken hoe lang dit gaat duren... ![]() | ||||||||
Monolith | donderdag 15 januari 2015 @ 13:17 | |||||||
LIKE negeert sowieso de fulltext index. Wil je daar gebruik van maken, dan kun je bijvoorbeeld MATCH gebruiken, zie ook de documentatie. Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera. | ||||||||
TwenteFC | donderdag 15 januari 2015 @ 19:20 | |||||||
![]() ![]() | ||||||||
Chandler | donderdag 15 januari 2015 @ 19:25 | |||||||
Het duurde ff maar dan heb je ook wat. 304k aan tags kleine 69miljoen tag links ![]() Nu nog een leuke query browsen... | ||||||||
Light | vrijdag 16 januari 2015 @ 00:50 | |||||||
Je kunt het iets beter krijgen door geen subquery te gebruiken:
Da's zeker een optie die het overwegen waard is, helemaal omdat het over redelijk grote datasets gaat. | ||||||||
Chandler | vrijdag 16 januari 2015 @ 08:05 | |||||||
Klopt Light! ![]() Echter heeft de hosting waar dit straks moet gaan draaien blijkbaar geen zoekplatformen of de mogelijkheid daarvoor, ik ga eerst eens spelen met tags en kijken hoe ik daar het meeste uit kan halen. Eventueel het tijdelijk opslaan van data sets... zodat hergebruik stukken sneller gaat... | ||||||||
Light | vrijdag 16 januari 2015 @ 15:25 | |||||||
Die tags in een aparte tabel opslaan is alvast een stap, mits je de indexes goed zet en gebruikt. Maar je zit tegen de grenzen van wat met MySQL mogelijk is en als je spannendere dingen wilt, moet je op zoek naar een hoster die wel een zoekplatform aanbiedt (of zelf de hosting doen). | ||||||||
Chandler | zondag 18 januari 2015 @ 08:51 | |||||||
Ik ben bang dat hij dan naar een andere hoster opzoek moet, ben zelf nu aan het spelen de database zonder zoekplatform en heb in eerste instantie mijn tags maar eens beperkt.. En wat video's geskipped met onzin titels.. Eerst een kleine 8m aan videos, nu 7,2m. Eerst 188k aan tags, nu 44k. Eerst 70m aan tag links, nu 48m. Scheelt toch wat... nu weer verder klooien met die queries... | ||||||||
Chandler | maandag 19 januari 2015 @ 12:08 | |||||||
ff een queries gespeeld, is niet gemakkelijk zeg ![]() Query result: Query:
En met bestaande velden home en alone is het resultaat: Dat kan sneller toch? ![]() Deze pagina gaf me aardig wat info: http://tagging.pui.ch/pos(...)ms-performance-tests -edit- Koppel ik ze los dan heb ik dit SELECT * FROM tags WHERE name in ('home','alone') == 0,000 secs (2 resultaten) SELECT video_id FROM video_tag_link WHERE tag_id IN ( 2316, 290 ) LIMIT 0 , 300000 == 20 secs (15292 resultaten). SELECT * FROM videos WHERE id IN (763,) == 1 secs (15292 resultaten). Is een stukje sneller... ![]() [ Bericht 13% gewijzigd door Chandler op 19-01-2015 12:23:37 ] | ||||||||
Aether | maandag 19 januari 2015 @ 12:21 | |||||||
Voer de query eens uit met EXPLAIN aan het begin. Dan kun je zien waar het beste indices geplaatst kunnen worden. | ||||||||
Chandler | maandag 19 januari 2015 @ 12:25 | |||||||
![]() | ||||||||
Monolith | maandag 19 januari 2015 @ 13:13 | |||||||
Het ziet er in ieder geval uit als een hele kromme query. Gebruik je nou IN en HAVING om enerzijds te selecteren op twee tag names en anderzijds te checken of ze allebei gevonden worden? In dat geval zou ik eens kijken of je middels WHERE EXISTS niet sneller resultaat krijgt. Verder valt er vrij weinig te zeggen over je query zonder de onderliggende db structuur te kennen. | ||||||||
Chandler | maandag 19 januari 2015 @ 17:09 | |||||||
Ik zal het eens bekijken en uitproberen ![]() Bij deze ![]()
| ||||||||
Light | maandag 19 januari 2015 @ 19:36 | |||||||
Je mist een index in je koppeltabel
Voor video_id heb je geen aparte index nodig, dat wordt afgehandeld door de unique key. Je zou ook de unique key kunnen aanpassen naar (`tag_id`, `video_id`) en dan een aparte index op `video_id` zetten. In beide gevallen wordt je tabel groter (want meer index-ruimte nodig) en worden queries een stuk sneller. | ||||||||
Monolith | maandag 19 januari 2015 @ 19:41 | |||||||
Volgens mij doet hij altijd een query op beide velden in de index, dus zou dat op zich goed moeten gaan. Hoewel het lang geleden is dat ik me in detail met indices in MySQL heb beziggehouden. | ||||||||
Light | maandag 19 januari 2015 @ 19:49 | |||||||
Er wordt een full table scan gedaan bij een query waar je dat niet verwacht, dus de indices staan niet goed. Dat die full table scan op de video's-tabel wordt gedaan en niet op de koppeltabel, komt omdat die laatste tabel veel groter is (7mln vs 48 mln rijen). | ||||||||
Monolith | maandag 19 januari 2015 @ 19:53 | |||||||
Ah, ik had de explain even gemist. ![]() | ||||||||
Chandler | maandag 19 januari 2015 @ 20:18 | |||||||
Helaas, Ook geen profijt... ![]() Ik speel gewoon verder ![]() -- gelijk een vraagje ![]() Kan iemand mij deze regel uitleggen? ![]() CONSTRAINT `image_fk` FOREIGN KEY (`image_id`) REFERENCES `image` (`image_id`), [ Bericht 32% gewijzigd door Chandler op 19-01-2015 22:08:23 ] | ||||||||
Light | maandag 19 januari 2015 @ 23:42 | |||||||
De tabel waar die regel in staat heeft een foreign key constraint met de unieke naam image_fk. De waarde in de kolom image_id verwijst naar een waarde in de kolom image_id in de tabel image. Je kunt dus geen waarde opslaan die niet ook in image.image_id staat. Bijkomend effect is dat er een index op de kolom image_id is in de tabel waar die regel staat. En als je je afvraagt waarom (`image_id`) tussen haakjes staat; het is ook mogelijk om een foreign key constraint te maken over meerdere kolommen. Die moeten dan wel verwijzen naar evenveel kolommen die allemaal in dezelfde tabel staan. Of dat nuttig is, weet ik niet. Het verklaart de haakjes, en het is nuttig om te weten dat een foreign key ook over meerdere kolommen kan gaan. | ||||||||
Chandler | vrijdag 23 januari 2015 @ 09:34 | |||||||
Thanks Light! Snap er nog weinig van maar al iets meer dan ervoor.. Qua indexes loopt het nog steeds voor geen meter, heb nu eerst mijn mysql configuratie aangepast. (van 64MB naar 6GB ![]()
Index voor video_tag_link
Index voor tags
En index voor videos
Het veranderen van een indexen etc (meerdere keren gedaan, kost me zo'n 5 uur per index...) ![]() | ||||||||
TwenteFC | vrijdag 23 januari 2015 @ 18:47 | |||||||
Een ander type database gebruiken? ![]() Zou je ook eens een explain van je query kunnen posten? | ||||||||
Chandler | vrijdag 23 januari 2015 @ 19:47 | |||||||
Die staat in mijn 1e quote. Het rare is namelijk dat zoeken in tabel videos, veld tags (like %tag%) vele malen sneller is dan het uitlezen van tags tabellen (normaliseren). ![]() Wil wel even een dump maken hoor ![]() ![]() | ||||||||
TwenteFC | vrijdag 23 januari 2015 @ 21:31 | |||||||
Denormaliseren? Gewoon om te kijken wat het doet. | ||||||||
Chandler | vrijdag 23 januari 2015 @ 21:32 | |||||||
Ja ![]() ![]() | ||||||||
ursel | vrijdag 23 januari 2015 @ 21:57 | |||||||
Zit je stiekem sexfilms te zoeken? ![]() | ||||||||
Chandler | zaterdag 24 januari 2015 @ 08:32 | |||||||
7 miljoen? beetje te veel, maar je zit aardig in de buurt ![]() | ||||||||
bondage | zaterdag 24 januari 2015 @ 10:45 | |||||||
Welke storage engine gebruik je? Heb je bijvoorbeeld al InnoDB geprobeerd? En: https://blogs.oracle.com/(...)ncement_in_full_text [ Bericht 6% gewijzigd door bondage op 24-01-2015 10:52:25 ] | ||||||||
#ANONIEM | zaterdag 24 januari 2015 @ 11:47 | |||||||
Sowieso MariaDB in plaats van MySQL | ||||||||
Monolith | zaterdag 24 januari 2015 @ 11:58 | |||||||
En waarom zou dat gaan helpen? Zoals al aangegeven is de beste optie om gewoon een fatsoenlijk zoekplatform te gebruiken, maar die mogelijkheid heeft hij niet. | ||||||||
Chandler | zaterdag 24 januari 2015 @ 12:01 | |||||||
Nee ![]() ![]() ![]() | ||||||||
#ANONIEM | zaterdag 24 januari 2015 @ 12:02 | |||||||
Het was meer een zijspoor. ![]() | ||||||||
Chandler | zaterdag 24 januari 2015 @ 13:28 | |||||||
Jeej, Volgende query doet het best ![]()
Doet ook aan filesort maar vind in totaal 5638 resultaten in ruim 1 seconde... ![]() | ||||||||
TwenteFC | zaterdag 24 januari 2015 @ 16:41 | |||||||
![]() | ||||||||
Chandler | zaterdag 24 januari 2015 @ 16:52 | |||||||
Nee ![]() ![]()
| ||||||||
henrivo | zondag 25 januari 2015 @ 00:10 | |||||||
Jeuw. Symfony2 kenners hier? Wanneer ik form_row a en b oproep in een view, worden direct eronder ook meteen form_row c en d weergegeven. Terwijl ik die niet wil laten zien in die view. {{ form_start(form) }} {{ form_row(form.a) }} {{ form_row(form.b) }} {{ form_end(form) }} Even als voorbeeldje hoe ik het heb | ||||||||
henrivo | zondag 25 januari 2015 @ 11:09 | |||||||
Inmiddels een workaround gevonden, nu blijf ik weer hangen bij de melding "Notice: Array to string conversion". Als iemand dat bekend voor komt, laat even weten hoe je dat hebt opgelost ![]()
| ||||||||
Diabox | zondag 25 januari 2015 @ 17:59 | |||||||
Dat komt door de regel:
Array to string conversion notice komt simpelweg doordat je ergens een array als argument meegeeft terwijl er een string wordt verwacht (zonder code gaan wij niet kunnen uitvinden waar dat vandaan komt). | ||||||||
henrivo | zondag 25 januari 2015 @ 19:59 | |||||||
Helemaal overheen gelezen, domdomdom ![]() Zo ver was ik al ![]() ![]()
| ||||||||
TwenteFC | donderdag 29 januari 2015 @ 23:52 | |||||||
Gewoon omdat ik het hier eigenlijk nooit voorbij zie komen, maar wie hier gebruikt er wel eens op regelmatige basis triggers, functies en dergelijke in mysql? | ||||||||
Intrepidity | vrijdag 30 januari 2015 @ 13:16 | |||||||
Nee, want MySQL is totaal niet de plaats om allerlei logica in te gaan dumpen. | ||||||||
mstx | vrijdag 30 januari 2015 @ 13:27 | |||||||
Nooit nodig gehad. 1x een collega gehad die daar dus iets in verstopt had, na uren zoeken had ik dus eindelijk gevonden hoe er opeens bepaalde waardes in kolommen werden weggeschreven. ![]() | ||||||||
Monolith | vrijdag 30 januari 2015 @ 14:45 | |||||||
Soms kan het vanuit performance oogpunt handig zijn. Zeker ORM is lang niet altijd optimaal efficiënt. Nou merk je dat bij een gemiddeld websiteje niet, maar als het om wat grootschaligere applicaties gaat, dan zijn dat soort zaken wat belangrijker. Ook qua security biedt het extra mogelijkheden. Triggers kunnen dan wel weer nuttig zijn voor auditing en data integrity. Vaak is het wel zo dat als je je over dergelijke zaken druk dient te maken, MySQL sowieso niet meer de juiste database is. ![]() | ||||||||
KomtTijd... | vrijdag 30 januari 2015 @ 18:35 | |||||||
Ik zit er ook over te denken om bepaalde subqueries die in een bepaalde applicatie meerdere keren terugkomen per query, in een routine samen te vatten. Maar ik ga die hele applicatie nog herschrijven dus daar denk ik tzt nog wel een keer over na. (Het is een reports applicatie voor een CRM, en die is nu een beetje lelijk omdat ik de queries om heb moeten schrijven naar een nieuwe versie van het CRM. Maar uiteindelijk moeten de reports gewoon in het CRM geïntegreerd worden) | ||||||||
Diabox | zaterdag 31 januari 2015 @ 01:43 | |||||||
Botte vraag en niet geheel on-topic (maar hier redelijke kans op antwoorden): wat verdienen jullie ongeveer als webprogrammeur? Ik heb een salarisaanbod gekregen die ik maar moeilijk kan plaatsen. Ik heb bijna 4 jaar professionele werkervaring als web developer, en heb daarnaast een BSc en MSc (informatica en SE); 15 eu p/u. Leek mij niet in verhouding met mijn ervaring en opleidingen (werk momenteel daar op freelance basis voor een veelvoud van dat bedrag). | ||||||||
bondage | zaterdag 31 januari 2015 @ 02:04 | |||||||
15 is imo te weinig, ik zit daar een paar euro boven met 6 jaar ervaring. Het werk is op HBO niveau maar ik ben er tussen gerold met een MBO4 diploma. | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 06:16 | |||||||
Anderzijds moet Diabox ook rekening houden dat in deze tijd het hebben van een vaste baan ook wel een lekker zekerheidje is want wil jij niet, dan neemt men met gemak (gezien het gigantische aanbod van werklozen in alle sectoren) een ander. | ||||||||
Rockfire | zaterdag 31 januari 2015 @ 09:32 | |||||||
nou dat 'crisis'-verhaal gaat echt niet in elke sector op hoor. Ik ben twee jaar geleden geswitched van werkgever en had gewoon keuze... En wij willen op het werk al geruime tijd en goede programmeur erbij maar die zijn heel lastig te vinden | ||||||||
qu63 | zaterdag 31 januari 2015 @ 09:39 | |||||||
Mijn bijbaan als touringcarchauffeur op MBO4 niveau heeft dat zo ongeveer als minimum (bruto) ![]() Hobbyprogrammeur hier ![]() | ||||||||
Monolith | zaterdag 31 januari 2015 @ 10:52 | |||||||
Ik krijg toch echt wekelijks vele aanbiedingen. Dat is wel voornamelijk in de Java hoek. | ||||||||
Tijn | zaterdag 31 januari 2015 @ 11:04 | |||||||
Ik moet de eerste werkloze programmeur nog tegenkomen, hoor. | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 11:12 | |||||||
Ik zit met ~7 jaar (parttime @ ~20 uur per week) ervaring op ongeveer 13 euro per uur ![]() Toch maar eens babbelen met de baas ![]() Nu ik erover nadenk, ik verdiende als systeembeheer-sjappie in 2007, 50 cent meer dan dat ik nu doe ![]() [ Bericht 6% gewijzigd door #ANONIEM op 31-01-2015 11:20:12 ] | ||||||||
Robuustheid | zaterdag 31 januari 2015 @ 11:23 | |||||||
Zijn dat vaste banen die je aangeboden krijgt? | ||||||||
Monolith | zaterdag 31 januari 2015 @ 11:29 | |||||||
Yep. Dan moet je natuurlijk nog wel een sollicitatieprocedure door, maar toch. Op de markt voor mensen met kennis van Java (en allerhande gerelateerde technologieën) is ook nog wel een stuk meer schaarste dan op die voor PHP / front-end developers. | ||||||||
Tijn | zaterdag 31 januari 2015 @ 11:53 | |||||||
Er zijn misschien meer PHP en front-enders, maar een groot deel daarvan is tamelijk clueless en zijn eigenlijk meer hobbyisten dan serieuze programmeurs. | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 11:57 | |||||||
Die worden er tegenwoordig gelukkig wel vrij snel uitgegooid ![]() ![]() | ||||||||
Rockfire | zaterdag 31 januari 2015 @ 12:04 | |||||||
Inderdaad, de prutsers vallen toch vrij snel door de mand. Als wij bij de sollicitatie twijfelen over het niveau laten we ze een kleine opdracht doen. En anders heb je inderdaad de proeftijd nog... | ||||||||
Monolith | zaterdag 31 januari 2015 @ 12:04 | |||||||
Oh zeker, ik heb ook wel wat werk in die hoek gedaan en heel vaak was het echt huilen met de pet op. Het verschil tussen de Java community en de PHP community is qua professionaliteit sowieso wel aanzienlijk hoor. | ||||||||
bondage | zaterdag 31 januari 2015 @ 12:08 | |||||||
Dat is echt weinig ![]() | ||||||||
Tijn | zaterdag 31 januari 2015 @ 12:08 | |||||||
Maar dat zorgt er dus ook wel voor dat de schaarste in die hoek groter is dan-ie lijkt. Een PHP'er vinden is niet zo'n probleem. Een goede vinden daarentegen... | ||||||||
Diabox | zaterdag 31 januari 2015 @ 12:11 | |||||||
Nou, wat betalen jullie? ![]() | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 12:13 | |||||||
Echt veel is het niet inderdaad, maar reken ik het om naar fulltime dan kom je toch op zo'n 2200 euro per maand. Niet echt goed, maar het is geen minimumloon oid. Geld is geld ![]() Er zijn helaas niet veel bedrijven die part-time programmeurs aannemen. [ Bericht 4% gewijzigd door #ANONIEM op 31-01-2015 12:15:51 ] | ||||||||
Rockfire | zaterdag 31 januari 2015 @ 12:15 | |||||||
Ik verdien (met bijna 10 jaar werkervaring en HBO + WO opleiding) in ieder geval wel ruim meer dan die 15 euro per uur ![]() ![]() | ||||||||
Monolith | zaterdag 31 januari 2015 @ 12:16 | |||||||
Mwoah, ook binnen die hoek is er een enorme differentiatie. Java kent ook een vele malen breder ecosysteem dan PHP, wat hoofdzakelijk web development is, met daardoor ook vele malen meer specialisaties als zoekplatformen, webapplicaties, ESBs, Android apps, enzovoort. Maar ik ben het inderdaad met je eens dat een goede PHP developer vinden vrij lastig is. In het gros van de gevallen ontbreekt ook gewoon het echte begrip van de taal. Iets dat zeker met de relatief beroerde implementatie van PHP vrij belangrijk is. | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 12:24 | |||||||
Verschil is ook wel dat Java er bij iedere informatica opleiding ingebeukt wordt (de basis althans). En php alleen bij wat media-achtige opleidingen als soort van mini-cursus door een docent zonder enige vorm van kennis. Waardoor je bij php voornamelijk 2 groepen hebt, hobbyisten zonder diepe kennis die maar wat aankloten en de autodidacten die (fatsoenlijke) literatuur lezen en zichzelf naar knap niveau werken. En laat nou net die laatste groep relatief klein zijn ![]() [ Bericht 7% gewijzigd door #ANONIEM op 31-01-2015 12:24:41 ] | ||||||||
bondage | zaterdag 31 januari 2015 @ 12:27 | |||||||
Heb je ook extra voordelen zoals een laptop en mobiel van de zaak? Betreft inkomsten zit ik net iets boven de 3000 per maand bruto fulltime en heb mobiel en laptop van de zaak welke ik ook deels privé mag gebruiken. En natuurlijk paar thuiswerkdagen in de week ![]() Overigens wordt er wel van het team (waarvan ik deel uitmaak) verwacht dat we zelfstandig kunnen werken. Projecten komen binnen nadat ze langs een lang traject zijn geweest en zodra het bij ons ligt moeten wij bepalen hoeveel tijd en capaciteit we ervoor nodig hebben en uiteindelijk komen met een werkend product welke goed getest is en in principe klaar voor productie. | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 12:30 | |||||||
Nope, helemaal niks ![]() 't is wel een klein bedrijfje trouwens. Toen ik er 4 jaar geleden begon was er de baas (zelf ook programmeur) en een designer. Dit heb ik sindsdien zien groeien naar zo'n 15 man totaal en weer zien krimpen tot de huidige situatie waarin ik de enige werknemer ben naast de baas ![]() [ Bericht 3% gewijzigd door #ANONIEM op 31-01-2015 12:31:53 ] | ||||||||
Monolith | zaterdag 31 januari 2015 @ 12:34 | |||||||
Mja, maar in principe stelt PHP met Java ervaring niet zo gek veel voor. Het hele OO-gedeelte is toch grotendeels gejat bij / geïnspireerd door Java. Ook veel PHP frameworks hebben wel aardig leentjebuur gespeeld bij Spring, Hibernate, enzovoort. Andersom wordt het een ander verhaal. Alleen al iets als basaals threading is vaak een hele pittige kluif voor mensen die die stap maken. Ik ben het wel met je eens dat er veel baggeraanbod is op de PHP markt. Een collega van me mocht onlangs nog even de PHP codebase gaan doorspitten van de applicatie van een aangekocht bedrijfje. Daar kwam vrij veel gevloek bij kijken. ![]() | ||||||||
bondage | zaterdag 31 januari 2015 @ 12:36 | |||||||
Dus eigenlijk mag je van geluk spreken dat je nog een baan hebt... Aan de andere kant, als je er inmiddels 4 jaar werkt mag je imo wel wat hoger zitten qua loon. Of je moet al een echte klaploper zijn die een beetje aan het knutselen is maar dat is waarschijnlijk niet het geval ![]() Ik zit zo nu en dan wel eens op T.net te kijken wat voor vacatures er allemaal zijn betreft PHP en kom aardig wat tegen, meeste daarvan zijn echter wel fulltime. Er is trouwens wel een nadeel: ik moet drie dagen in de week van Assen naar Amersfoort. Ik heb het er voor over maar heb soms dagen dat ik daar minder zin in heb. | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 12:38 | |||||||
Zou kunnen, hehe. Maar nadat het bedrijf in november 2013 over de kop ging mocht ik als enige terug komen bij de nieuwe zaak. Dus ik denk dat ik iets goed doe ![]() Maar inderdaad, een baan is een baan in deze tijden. ![]() [ Bericht 1% gewijzigd door #ANONIEM op 31-01-2015 12:40:47 ] | ||||||||
bondage | zaterdag 31 januari 2015 @ 12:43 | |||||||
Blijkbaar doe je het goed. Ik had ook niet verwacht dat mijn manager zo over mij te spreken zou zijn, is toch een mooi compliment en zet me aan om nog beter te worden. Wel jammer dat het zich wat minder in loon vertaald maar ja, beter dan thuiszitten met een uitkering. Bij ons zijn jaarlijkse beoordelingen en de daarbij behorende loonsverhoging (in geval van goede beoordeling) verplicht. Maar ja, het bedrijf waar ik voor werk is 'iets' groter dus dat is allemaal veel strakker geregeld. | ||||||||
Diabox | zaterdag 31 januari 2015 @ 14:02 | |||||||
Nope, helaas wat te ver rijden. Ik ben momenteel bezig om de PHP codebase van het bedrijf in kwestie te refactoren. Alles is full-potato geprogrammeerd in gigantische bestanden met bergen if-statements en PHP, queries en HTML alles doorelkaar heen (>100k regels). | ||||||||
Monolith | zaterdag 31 januari 2015 @ 15:05 | |||||||
Zo erg was het ook weer niet. Maar als je professionele Enterprise architecturen gewend bent, is de gemiddelde PHP applicatie echt om te huilen. ![]() | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 15:31 | |||||||
Herkenbaar ![]() Al heb ik zelf ook een keer meegedaan. Leek toen der tijd een goed idee om alles overzichtelijk bij elkaar te houden in 1 taal. Dus had een helper geschreven zodat ik alle jquery kon produceren in php.. ![]()
![]() ![]() * Was voor een boekhoud ding die volledig in de front-end draaide. Alles werd zonder reloads ingeladen met een stel achtergrond threads. Dus dit "leek" een goed idee om dingen bij users die al 8 uur de boel open hadden staan aan te kunnen passen ![]() [ Bericht 6% gewijzigd door #ANONIEM op 31-01-2015 15:39:21 ] | ||||||||
Monolith | zaterdag 31 januari 2015 @ 16:30 | |||||||
Er zijn wel frameworks als GWT waarbij je enkel Java voor schrijft, ook voor het front end gedeelte. Wel XML templates voor de HTML. Vervolgens wordt de JS gewoon gegenereerd, evenals alle Ajax calls e.d. | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 18:14 | |||||||
Hngg. Turkse karakters worden niet correct weergegeven in de browser... - PHP-bestand met dit erin: - Encoding van het bestand: UTF-8 without BOM (Notepad++) - Collation van MariaDB-database en -tabellen: utf8_turkish_ci - Browser: Firefox (/IE) Ik krijg het gewoon niet voor elkaar om de Turkse karakters zoals ç en ş correct weer te geven... Iemand een idee waar ik moet kijken/wat ik moet veranderen? Edit: Dit toegevoegd aan 'new PDO()' en het werkt nu goed. [ Bericht 1% gewijzigd door #ANONIEM op 31-01-2015 18:45:03 ] | ||||||||
#ANONIEM | zaterdag 31 januari 2015 @ 18:44 | |||||||
Al een kijkje genomen in je locale van PHP? Edit: Nevermind ![]() [ Bericht 5% gewijzigd door #ANONIEM op 31-01-2015 18:45:10 ] | ||||||||
Aether | zondag 1 februari 2015 @ 17:26 | |||||||
Voor wie zelf PHP-extensions in C++ wilt schrijven kwam ik deze bibliotheek tegen: PHP-CPP. | ||||||||
qu63 | maandag 2 februari 2015 @ 01:49 | |||||||
Ok, echte Dummie-vraag: Hoe sla ik een naam als "Lasse Hallström" het beste op in mijn database? htmlspecialchars()? htmlentities()? En hoe geef ik het dan weer leesbaar weer? htmlspecialchars_decode()? Iets anders? En hoe kan ik die naam invoegen in een url? dus "bla.php?search=Lasse Hallström" Lasse Hallström | ||||||||
mschol | maandag 2 februari 2015 @ 02:01 | |||||||
ik zou zorgen dat zowel php, mysql als de connectie tussen php<>mysql utf-8 als character set heeft.. dan kan je volgens mij gewoon die exacte naam in een insert query, zonder dingen als htmlspecialchars, gooien.. maar het is nogal een tijd geleden dat ik gebruik heb gemaakt van php/mysql, dus wellicht zijn er weer wijzigingen geweest.. | ||||||||
qu63 | maandag 2 februari 2015 @ 02:10 | |||||||
Ga ik daar eens naar kijken ![]() Gelukkig draait mijn host oude versie van zowel php als mysql ![]() | ||||||||
Intrepidity | maandag 2 februari 2015 @ 09:11 | |||||||
We kunnen allemaal wel haten op de API van PHP, maar toch mogen we van geluk spreken dat er ook nog front-enders zijn om de javascript te schrijven ![]() ![]() | ||||||||
Aether | maandag 2 februari 2015 @ 09:14 | |||||||
| ||||||||
Monolith | maandag 2 februari 2015 @ 11:20 | |||||||
Javascript is inderdaad zo ongeveer ook de enige taal die bijna net zo beroerd in elkaar steekt als PHP. Dit blijft toch ook altijd wel een aardige opsomming. ![]() | ||||||||
Tijn | maandag 2 februari 2015 @ 11:22 | |||||||
Het voordeel van Javascript is dat er een subset van de taal is die wel goed in elkaar steekt. Als je je beperkt tot alleen dat deel, valt het allemaal reuze mee. Met PHP is het niet zo'n feest, dat is gewoon altijd een puinhoop. | ||||||||
Monolith | maandag 2 februari 2015 @ 11:29 | |||||||
Je hebt ook ongeveer 0,0 serieuze alternatieven voor Javascript. | ||||||||
Tijn | maandag 2 februari 2015 @ 11:33 | |||||||
Uiteindelijk is Javascript de enige programmeertaal die je kunt gebruiken in de browser. Dus of je nou wil of niet, als je iets maakt dat in browsers moet draaien, kun je je maar beter in Javascript verdiepen. Iets waarvan veel programmeurs denken dat het niet nodig is trouwens, omdat ze denken dat ze de taal zo wel snappen omdat de syntax ze bekend voorkomt. | ||||||||
Monolith | maandag 2 februari 2015 @ 11:39 | |||||||
Het enige wat je nog kunt doen is gebruik maken van talen of Frameworks die compileren naar Javascript. Ik haalde eerder al GWT aan, waarbij je gewoon code in Java ontwikkelt (met alle voordelen van een fatsoenlijke taal) en die vervolgens gecompileerd wordt tot Javascript. | ||||||||
ursel | maandag 2 februari 2015 @ 11:42 | |||||||
Hey, zit jij ook al op phpnl slack.? ![]() Kwam hem daar ook al tegen | ||||||||
Tijn | maandag 2 februari 2015 @ 11:47 | |||||||
Ja, je hebt wel meer van dat soort vertalers, ook voor andere talen zoals Perl, Ruby en C# (zelfs PHP trouwens ![]() Maar persoonlijk schrijf ik liever de code die daadwerkelijk bij de client wordt uitgevoerd dan het via zo'n vertalingslaag te doen. | ||||||||
Monolith | maandag 2 februari 2015 @ 11:51 | |||||||
Mja, er zitten wel behoorlijke voordelen aan hoor. GWT is best geavanceerd, dus je kunt ook echt je Java code (die eigenlijk naar Javascript gecompileerd is) debuggen in je IDE. Wat een heel stuk prettiger werkt dan JS debuggen in browsers en aanverwante tooltjes. Daarnaast heb ik ook nog wel Google Closure gebruikt. Dan schrijf je nog wel steeds javascript, maar heb je wel allerhande annotations om private / public access te checken, 'strong typing' te hanteren, enzovoort. | ||||||||
Tijn | maandag 2 februari 2015 @ 12:01 | |||||||
Mja, ik ben meer een hacker dan een enterprise figuur. Ik zie niet echt het voordeel van strong typing om eerlijk te zijn ![]() Private / public variabelen en methods kun je ook gewoon zo in Javascript maken, daar heb je niks speciaals voor nodig:
| ||||||||
Monolith | maandag 2 februari 2015 @ 12:10 | |||||||
Een heel belangrijk voordeel van strong typing is dat je al die ellende met het optellen van strings en ints / doubles enzovoort door elkaar die hier net voorbij kwam niet hebt. Ik weet dat het in Javascript kan hoor, maar het is omslachtig. Met @private / @public annotations is het een stuk eleganter. Belangrijker nog, vaak heb je door dat soort frameworks ook IDE ondersteuning (al dan niet via een plug-in) waarmee je terwijl je aan het developen bent al kunt zien of je ergens een fout maakt. | ||||||||
Aether | maandag 2 februari 2015 @ 12:30 | |||||||
Ik gebruik nu (voor kleinere projecten) af en toe TypeScript waarmee o.a. beter op typen kan worden gecontroleerd. Vooral de laatste versie 1.4 biedt veel nieuwe opties. | ||||||||
Chandler | vrijdag 13 februari 2015 @ 11:35 | |||||||
Korte update over mijn index probleem (pagina 5). Oplossing is kappen met joinen... Heb nu meerdere testen gedraaid zonder dikke joins. Ieder tabel een query.. Grappig is dat dit vele malen sneller is... Van 80secs naar 0.5!! | ||||||||
KomtTijd... | vrijdag 13 februari 2015 @ 11:40 | |||||||
Mijn ervaring is dat je vanuit een grote tabel prima kunt joinen naar een kleine tabel, maar niet andersom. SELECT * FROM hugetable LEFT JOIN smalltable gaat prima, SELECT * FROM smalltable LEFT JOIN hugetable, beter niet. Zeker niet als je meerdere joins moet doen. | ||||||||
Chandler | vrijdag 13 februari 2015 @ 13:43 | |||||||
Nee precies, en aangezien ik meerdere grote tabellen join (2gb + 1gb + 3gb ![]() Wat ik nu ook zoek, het zit allemaal ruim onder de 1 seconde... (zonder te cachen).. | ||||||||
Chandler | maandag 16 februari 2015 @ 10:29 | |||||||
Toevoeging ![]() Hoe kom ik af van deze filesort? indexes staan goed... lijkt me... maar mogelijk zit ik fout..
Explain geeft het volgende
Iemand een idee? | ||||||||
Tijn | maandag 16 februari 2015 @ 11:16 | |||||||
Heb je al geprobeerd om "ORDER BY NULL" toe te voegen? | ||||||||
Chandler | maandag 16 februari 2015 @ 11:51 | |||||||
Nee, maar ff geprobeerd en helaas, same result.. | ||||||||
Aether | maandag 16 februari 2015 @ 12:27 | |||||||
Heb je een gecombineerde index op tag_id en video_id? | ||||||||
raptorix | maandag 16 februari 2015 @ 13:24 | |||||||
Mag ik vragen waarom je trouwens een group by video_id doet? Doe je dit om er voor te zorgen dat je geen dubbele items krijgt? | ||||||||
Monolith | maandag 16 februari 2015 @ 14:32 | |||||||
Een having clause zonder Group By wordt wat lastig. Zoals ik z'n query lees wil hij de ID's vinden van video's die beide tags uit de where clause hebben, vandaar de count=2. Het zijn mij echter iets te veel fragmentjes informatie verspreid over deze reeks om nou echt een advies te kunnen geven over wat hij het best kan doen. ![]() | ||||||||
raptorix | maandag 16 februari 2015 @ 14:46 | |||||||
Ja dat snap ik ![]() Bedoelde meer waarom hij daar een aggregate functie voor gebruikt, zijn over algemeen dure queries vandaar. | ||||||||
raptorix | maandag 16 februari 2015 @ 14:52 | |||||||
Misschien een hele domme tip, maar zou je eens voor de grap het IN statement voor een exacte match kunnen vervangen? "IN" kan soms nogal evil zijn. Ik ben geen MySql expert dus kan het mishebben. | ||||||||
Chandler | maandag 16 februari 2015 @ 16:15 | |||||||
Yup! ![]() Precies Wat mis je dan aan informatie? mijn tabel opzet? video_id int, tag_id int en daarop een unique en 1 extra qua index voor tag_id/video_id Omdat ik er vanuit ging dat deze daar voor bedoeld waren. Klopt, heb nu even deze query getest
![]() | ||||||||
Monolith | maandag 16 februari 2015 @ 16:26 | |||||||
Als ik je goed begrijp heb je geen index op video_id an sich? Dat lijkt me dan sowieso een probleem aangezien je een group by op video_id hanteert. Als je die wel hebt, dan kun je nog eens kijken of je met FORCE INDEX wel het gebruik kan forceren. Wat ik vooral bedoelde aan ontbrekende informatie is ook de use case. Je hebt hier nu bijvoorbeeld een voorbeeldje met twee tag_ids. Is dat altijd zo? Of is dat een variabel aantal? | ||||||||
Chandler | maandag 16 februari 2015 @ 16:37 | |||||||
Nee ik heb geen index op video_id an sich... ga dat eens proberen.. Het is een zeer variabel aantal, kan ook 1 zijn maar ook 8?! ![]() -edit- Wordt zelfs erger dan ![]() Using where; Using index; Using temporary; Using filesort [ Bericht 8% gewijzigd door Chandler op 16-02-2015 16:43:07 ] | ||||||||
raptorix | maandag 16 februari 2015 @ 23:14 | |||||||
Volgens mij heeft een index geen zin op een integer, maar daar twijfel ik even over, of dat puur op numeriek is of een autoID (bestaat dat in MySql?) |