DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Heel beperkt icm Logstash en Kibana.quote:Op vrijdag 14 november 2014 18:27 schreef TwenteFC het volgende:
Heeft iemand hier toevallig ervaring met Elasticsearch?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Dan kan jij misschien mijn vraag beantwoorden;quote:Op vrijdag 14 november 2014 18:33 schreef Monolith het volgende:
[..]
Heel beperkt icm Logstash en Kibana.
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
Denk dat ik het al gevonden heb, ze verstoppen alles wel in de documentatie.http://www.elasticsearch.(...)-filtered-query.html
Je zou ook kunnen kijken naar faceted search in SOLR. Volgens mij is dat zo ongeveer wat je wilt.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Dit is inderdaad exact wat ik wil, thx.quote:Op vrijdag 14 november 2014 18:44 schreef Monolith het volgende:
Je zou ook kunnen kijken naar faceted search in SOLR. Volgens mij is dat zo ongeveer wat je wilt.
Maar eens even mee gaan spelen.
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?
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | <?xml version="1.0" encoding="UTF-8"?> <mobile_orderdetail_ack xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <messagebody> <subscription> <products> <bundleproduct> <bundleproductid>114</bundleproductid> <bundleproductname>Managed Mobile Blue 1GB</bundleproductname> <startdate>2014-07-07</startdate> </bundleproduct> <bundleproduct> <bundleproductid>74</bundleproductid> <bundleproductname>Data Pack 1000 (Blue)</bundleproductname> <startdate>2014-07-07</startdate> </bundleproduct> <bundleproduct> <bundleproductid>46</bundleproductid> <bundleproductname>SMS Pack Unlimited</bundleproductname> <startdate>2014-07-07</startdate> </bundleproduct> </products> </subscription> </messagebody> </mobile_orderdetail_ack> |
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?
| 1 2 3 4 5 6 7 8 9 10 | <?php $xml = new SimpleXMLElement ( $bericht ); foreach ( $xml->messagebody->subscription->products as $products ) { print_r ( $products ); } ?> |
quote:
| 1 2 3 4 5 6 7 8 9 10 | <?php foreach ( $xml->messagebody->subscription->products->bundleproduct as $bundleproducts ) { $products[] = get_object_vars ( $bundleproducts ); } print_r ( $products ); ?> |
Op deze manier kan ik $products aanroepen als een array
Dit zal vast slordig zijn, maar dit kon ik vinden op Google
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.
Gelukkig kan ik ook geen voorbeelden vinden hoe het wel moet. Overal zeggen ze: "gebruik dit en je bent klaar".
| 1 2 3 4 5 | <?php $variables = array( 'Foo' => 'Bar', 'Baz' => 'Test' ); $json = new JsonModel( $variables ); return $json; ?> |
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.
Gebruik de json view helper: http://framework.zend.com(...)ew.helpers.json.htmlquote:
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".
[ code verwijderd ]
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.
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
Kan dit niet eenvoudiger/beter?
$airday bevat Monday-Sunday
$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)
| 1 2 3 | <?php $nextdate = strtotime(date("d-m-Y", strtotime("first ".$airday." of ".$date[0]." ".$date[1]))." ".$airtime." ".$timezone); ?> |
$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)
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
When the student is truly ready, the teacher will disappear.
Iemand al gespeeld met de develop versie van Laravel 5?https://github.com/laravel/laravel/commits/develop
Taylor is er maar weer druk mee, ziet er goed uit zover.
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?
Veiligheid?quote:Op vrijdag 28 november 2014 15:55 schreef KomtTijd... het volgende:
Waarom zou je dat uberhaupt willen?
Depreciation?
Het is wel mogelijk, maar dan moet je denk een veel te ingewikkelde regex schrijvenquote:Op vrijdag 28 november 2014 15:36 schreef boskameel het volgende:
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?
Zul je toch handmatig moeten doen.
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.quote:
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.quote:[..]
Het is wel mogelijk, maar dan moet je denk een veel te ingewikkelde regex schrijven
Zul je toch handmatig moeten doen.
Maar die oude mysql-functies worden wel degelijk verwijderd toch?quote:Op vrijdag 28 november 2014 18:00 schreef KomtTijd... het volgende:
[..]
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.
Is het niet al weg in 5.6?quote:
[..]
Maar die oude mysql-functies worden wel degelijk verwijderd toch?
Dan is het toch niet deprecated meer maar echt weg? Kan me voorstellen dat je dan als bedrijf wilt switchen van mysql* naar PDO.quote:
Als het daar om gaat kun je gewoon alle mysql_* functies vervangen door mysqli_*.quote:
[..]
Maar die oude mysql-functies worden wel degelijk verwijderd toch?
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Dat kan ook ja, maar ik kan me voorstellen dat mensen het dan gelijk helemaal goed willen doen.quote:
[..]
Als het daar om gaat kun je gewoon alle mysql_* functies vervangen door mysqli_*.
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.quote:
[..]
Dat kan ook ja, maar ik kan me voorstellen dat mensen het dan gelijk helemaal goed willen doen.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
quote:
[..]
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.
Erm... Nee. Echt niemand gaat betalen voor het ombouwen van een applicatie die uiteindelijk precies hetzelfde kan als daarvoor.quote:
[..]
Dat kan ook ja, maar ik kan me voorstellen dat mensen het dan gelijk helemaal goed willen doen.
1000'en keren dergelijke functies gebruiken klinkt vooral als een heel erg slecht ontworpen applicatie.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Je moest eens weten wat voor gedrochten er bestaan. Code die compleet onveilig is vanwege luiheid, tijdsgebrek, etc.quote:
1000'en keren dergelijke functies gebruiken klinkt vooral als een heel erg slecht ontworpen applicatie.
Zeker met code die al verouderd is heb je vaak problemen of met slecht gebouwde CMS systemen (joomla).
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.quote:
[..]
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).
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
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?
In theory there is no difference between theory and practice. In practice there is.
Omdat er nog veel oude tutorials en dergelijke op internet circuleren denk ik.quote:
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?
Goed punt inderdaad.quote:
[..]
Omdat er nog veel oude tutorials en dergelijke op internet circuleren denk ik.
Smile like you mean it
www.wefut.com
www.wefut.com
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.quote:
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
Dat is geen argument imo. Of... misschien ook wel. Ze hadden dus veeeeeeel eerder die mysql*_ meuk moeten deprecaten en verwijderen.quote:
[..]
Omdat er nog veel oude tutorials en dergelijke op internet circuleren denk ik.
In theory there is no difference between theory and practice. In practice there is.
Mee eens.quote:
[..]
Dat is geen argument imo. Of... misschien ook wel. Ze hadden dus veeeeeeel eerder die mysql*_ meuk moeten deprecaten en verwijderen.
Gewoon ter zelfbescherming voor de mensen die het anders fout zouden doen.
Probleem is dat de grootste kracht van PHP ook gelijk de grootste zwakte is, praktisch iedere idioot kan ermee aan de slag.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
PDO heeft een iets hogere leercirve. Mysql_* is lekker makkelijk.quote:
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?
Eigenlijk wel ja.quote:
Probleem is dat de grootste kracht van PHP ook gelijk de grootste zwakte is, praktisch iedere idioot kan ermee aan de slag.
Hogere leercurve? Explain.quote:
[..]
PDO heeft een iets hogere leercirve. Mysql_* is lekker makkelijk.
In theory there is no difference between theory and practice. In practice there is.
Zelf vind ik PDO echt heel makkelijk in gebruik. Ik kan het me echt niet voorstellen dat mensen daar moeite mee hebben.quote:
Prepared statements en shit. En OO en classes begreep ik echt nog niet in het begin (toen ik nog mysql_* gebruikte)quote:
Ik word er niet gek van, want ik heb niks te maken met wat anderen doenquote:
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?
[ Bericht 0% gewijzigd door Tijn op 29-11-2014 13:08:54 ]
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 ]
PHP-programmeurs verdienen gemiddeld minder:
http://tweakers.net/revie(...)erdienen-icters.html
[ Bericht 1% gewijzigd door #ANONIEM op 29-11-2014 12:53:05 ]
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 zoietsquote:
Opvallend trouwens.
PHP-programmeurs verdienen gemiddeld minder:
http://tweakers.net/revie(...)erdienen-icters.html
Wellicht ja.quote:Op zaterdag 29 november 2014 13:10 schreef Tijn het volgende:
[..]
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
Ik denk dat mensen die echt heel goed met bepaalde frameworks kunnen werken en echt goed OOP in PHP kunnen programmeren wel redelijk gelijklopen.
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!
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!
"if it ain't broken, don't fix it" versus "if you stand still, you fall behind".quote:
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!
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.
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
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.quote:Op zaterdag 29 november 2014 15:07 schreef papernote het volgende:
[..]
"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.
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 ]
