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.
Javascript is inderdaad zo ongeveer ook de enige taal die bijna net zo beroerd in elkaar steekt als PHP.quote:Op maandag 2 februari 2015 09:11 schreef Intrepidity het volgende:
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
[ afbeelding ]
Dit blijft toch ook altijd wel een aardige opsomming.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
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.
Met PHP is het niet zo'n feest, dat is gewoon altijd een puinhoop.
Je hebt ook ongeveer 0,0 serieuze alternatieven voor Javascript.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
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.quote:
Je hebt ook ongeveer 0,0 serieuze alternatieven voor Javascript.
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.
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.quote:Op maandag 2 februari 2015 11:33 schreef Tijn het volgende:
[..]
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.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Hey, zit jij ook al op phpnl slack.?quote:
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
[ afbeelding ]
Kwam hem daar ook al tegen
Ja, je hebt wel meer van dat soort vertalers, ook voor andere talen zoals Perl, Ruby en C# (zelfs PHP trouwensquote:
[..]
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.
). Verder heb je nog nieuwe talen die compilen naar Javascript, zoals Coffeescript of Dart.Maar persoonlijk schrijf ik liever de code die daadwerkelijk bij de client wordt uitgevoerd dan het via zo'n vertalingslaag te doen.
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.quote:Op maandag 2 februari 2015 11:47 schreef Tijn het volgende:
[..]
Ja, je hebt wel meer van dat soort vertalers, ook voor andere talen zoals Perl, Ruby en C#. Verder heb je nog nieuwe talen die compilen naar Javascript, zoals Coffeescript of Dart.
Maar persoonlijk schrijf ik liever de code die daadwerkelijk bij de client wordt uitgevoerd dan het via zo'n vertalingslaag te doen.
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.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Mja, ik ben meer een hacker dan een enterprise figuur. Ik zie niet echt het voordeel van strong typing om eerlijk te zijnquote:
[..]
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.
Private / public variabelen en methods kun je ook gewoon zo in Javascript maken, daar heb je niks speciaals voor nodig:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | var myObject = (function() { var privateVar = 'is een baas'; var privateMethod = function() { return 'super secret'; } return { publicVar: 'Tijn', publicMethod: function() { return this.publicVar + ' ' + privateVar; }, anotherMethod: function() { return 'The password is: ' + privateMethod(); } } }()); |
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.quote:Op maandag 2 februari 2015 12:01 schreef Tijn het volgende:
[..]
Mja, ik ben meer een hacker dan een enterprise figuur. Ik zie niet echt het voordeel van strong typing om eerlijk te zijn
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.quote:Private / public variabelen en methods kun je ook gewoon zo in Javascript maken, daar heb je niks speciaals voor nodig:
[ code verwijderd ]
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
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.quote:
[..]
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:
[ code verwijderd ]
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.
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!!
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!!
Just say hi!
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.
SELECT * FROM hugetable LEFT JOIN smalltable gaat prima, SELECT * FROM smalltable LEFT JOIN hugetable, beter niet. Zeker niet als je meerdere joins moet doen.
Nee precies, en aangezien ik meerdere grote tabellen join (2gb + 1gb + 3gb ) en omdat de servers die ik kan gebruiken geen fulltext zoek mogelijkheden/uitbreidingen hebben en minder dan 8gb geheugen (te gebruiken) is dit dan toch wel de beste keuze...
Wat ik nu ook zoek, het zit allemaal ruim onder de 1 seconde... (zonder te cachen)..
) en omdat de servers die ik kan gebruiken geen fulltext zoek mogelijkheden/uitbreidingen hebben en minder dan 8gb geheugen (te gebruiken) is dit dan toch wel de beste keuze...Wat ik nu ook zoek, het zit allemaal ruim onder de 1 seconde... (zonder te cachen)..
Just say hi!
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?
Hoe kom ik af van deze filesort? indexes staan goed... lijkt me... maar mogelijk zit ik fout..
| 1 2 3 4 5 6 | SELECT SQL_NO_CACHE `video_id` FROM `video_tag_link` WHERE `tag_id` IN ('2721','245') GROUP BY `video_id` HAVING COUNT(`video_id`) = 2 LIMIT 0, 20 |
Explain geeft het volgende
| 1 2 3 4 5 6 7 8 9 10 | id = 1 select_type = SIMPLE table = video_tag_link type = range possible_keys = PRIMARY,video_id key = video_id key_len = 4 ref = NULL rows = 8903 exta = Using where; Using index; Using temporary; Using filesort |
Iemand een idee?
Just say hi!
Heb je een gecombineerde index op tag_id en video_id?quote:
Nee, maar ff geprobeerd en helaas, same result..
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.
Mag ik vragen waarom je trouwens een group by video_id doet?quote:
Nee, maar ff geprobeerd en helaas, same result..
Doe je dit om er voor te zorgen dat je geen dubbele items krijgt?
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
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.quote:
[..]
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?
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.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Ja dat snap ikquote:
[..]
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.
Bedoelde meer waarom hij daar een aggregate functie voor gebruikt, zijn over algemeen dure queries vandaar.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
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.quote:
Nee, maar ff geprobeerd en helaas, same result..
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Yup!quote:Op maandag 16 februari 2015 12:27 schreef Aether het volgende:
Heb je een gecombineerde index op tag_id en video_id?
en zelfs 1tje op video_id en tag_id.Preciesquote:
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.
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_idquote: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.
Omdat ik er vanuit ging dat deze daar voor bedoeld waren.quote:
Ja dat snap ik
Bedoelde meer waarom hij daar een aggregate functie voor gebruikt, zijn over algemeen dure queries vandaar.
Klopt, heb nu even deze query getestquote:
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.
| 1 2 3 4 5 6 | explain SELECT SQL_NO_CACHE `video_id` FROM `video_tag_link` WHERE `tag_id` = 2721 OR `tag_id` = 245 GROUP BY `video_id` HAVING COUNT(`video_id`) = 2 LIMIT 0, 20 |
en dat zou moeten kunnen...
Just say hi!
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?
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?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Nee ik heb geen index op video_id an sich... ga dat eens proberen..quote:
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.
Het is een zeer variabel aantal, kan ook 1 zijn maar ook 8?!quote: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?
-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 ]
Just say hi!
