abonnementen ibood.com bol.com Gearbest
  vrijdag 14 juli 2017 @ 19:19:45 #176
118011 BrainOverfloW
Fok! around the Clock!
pi_172420348
registreer om deze reclame te verbergen
quote:
10s.gif Op vrijdag 14 juli 2017 17:20 schreef KomtTijd... het volgende:
Ja lekker is die he? Daar gebruik ik fuck ook het meest voor.

Ik moet ook nog eens wat handige aliases voor git commando's invoeren. -am gebruik ik nooit meer trouwens, dat heeft me iets te vaak in de kont gebeten met onbedoelde diffs.
Ja die werkt prima, dank voor de tip ^O^.

Ik doe meestal nog wel even snel een git status en/of git diff om te zien wat ik commit. Uiteraard netjes gealiassed naar 'gs' en 'gd'. Daarmee tot nu toe nog geen hele grote errors gemaakt.

De enige fout die ik nog wel makkelijk maar is om mijn commit te maken, en soms al te pushen, om er dan achter te komen dat een nieuw gemaakt bestand nog niet toegevoegd is.
Whether or not you can become great at something, you can always become better.
And one day you'll wake up and find out how good you actually became, having transcended whatever limits you might have thought you couldn't pass.
Neil Degrasse Tyson
  zondag 16 juli 2017 @ 16:24:19 #177
459997 DevFreak
Still got the blues.
pi_172461521
quote:
1s.gif Op vrijdag 7 juli 2017 19:57 schreef Monolith het volgende:

[..]

Afgezien van het beperkte toepassingsgebied van een taal als PHP is het grootste manco van de taal net als bij JavaScript gewoon dat er heel veel mis is met het fundament. Het is en blijft een laagdrempelig mengelmoesje van een niet al te consistente C wrapper en een halfbakken poging om OO principes uit Java over te nemen.

Net als bij JavaScript zijn er wel heel wat frameworks en libraries die de problemen met het fundament repareren, maar het laat zo veel ruimte over voor enorm slechte code dat dat in de praktijk ook erg gebruikelijk is.

Ik heb er zelf ook al tijden niets meer mee gedaan, maar als ik zo even zoek op multithreading in PHP kom ik uit op pthreads. Als ik dat lees dan komt dat in de verste verte niet in de buurt bij wat volwassen talen als C# en Java bieden. Dit is echt de minimale implementatie die 20 jaar geleden al in Java zat.

C# had ik overigens ook al een jaar of acht niet meer gedaan, maar recentelijk weer een project mee gedaan en die taal heeft echt wel flinke stappen gemaakt.

Java is wat conservatiever qua ontwikkeling ook ivm backwards compatibility, maar de kracht van de JVM is dan weer dat je er ook gewoon andere talen op kunt bouwen die de gigantische diversiteit aan Java libraries kunnen gebruiken, dus als Java als taal je niet bevalt pak je Scala of Kotlin.
Sorry, ik ben een aantal dagen "off the line" geweest.

C# heeft zeker grote stappen gemaakt. Kijk alleen al hoe gemakkelijk MS het heeft gemaakt om asynchroom te programmeren.

Ik zit er over na te denken een klein spelletje o.i.d. te maken en zou graag een combinatie willen zien van PHP en SignalR (webpagina's serven en authenticatie etc. met PHP, en SignalR integreren). Ik zou ook over kunnen gaan op ASP.NET, maar ik blijf liever gebruik maken van PHP.

Ik denk dat het technisch wel mogelijk zou moeten zijn maar heb op het moment nog geen idee hoe dit vorm zou kunnen geven.
Appels niet met peren vergelijken.
pi_172462505
quote:
7s.gif Op zondag 16 juli 2017 16:24 schreef DevFreak het volgende:

[..]

Sorry, ik ben een aantal dagen "off the line" geweest.

C# heeft zeker grote stappen gemaakt. Kijk alleen al hoe gemakkelijk MS het heeft gemaakt om asynchroom te programmeren.

Ik zit er over na te denken een klein spelletje o.i.d. te maken en zou graag een combinatie willen zien van PHP en SignalR (webpagina's serven en authenticatie etc. met PHP, en SignalR integreren). Ik zou ook over kunnen gaan op ASP.NET, maar ik blijf liever gebruik maken van PHP.

Ik denk dat het technisch wel mogelijk zou moeten zijn maar heb op het moment nog geen idee hoe dit vorm zou kunnen geven.
Gewoon de Javascript client van SignalR gebruiken in je PHP applicatie als je staat op PHP.
Of simpelweg gewoon zelf websockets gebruiken. Ik weet niet wat je precies wilt gaan doen verder, maar er zijn vast de nodige PHP libraries te vinden die daarvoor al wat basisfunctionaliteit bieden.
“I did not mean that Conservatives are generally stupid; I meant, that stupid persons are generally Conservative. I believe that to be so obvious and undeniable a fact that I hardly think any hon. Gentleman will question it.“
  zondag 16 juli 2017 @ 17:09:00 #179
459997 DevFreak
Still got the blues.
pi_172462999
registreer om deze reclame te verbergen
quote:
0s.gif Op zondag 16 juli 2017 16:55 schreef Monolith het volgende:

[..]

Gewoon de Javascript client van SignalR gebruiken in je PHP applicatie als je staat op PHP.
Of simpelweg gewoon zelf websockets gebruiken. Ik weet niet wat je precies wilt gaan doen verder, maar er zijn vast de nodige PHP libraries te vinden die daarvoor al wat basisfunctionaliteit bieden.
Ik zit te denken aan iets heel simpels zoals boter-kaas en eieren spelletje of een chatprogramma, zodat ik mezelf eindelijk eens bekend kan maken met SignalR. Heb er al veel over gelezen en gehoord en heb het ook al in actie gezien. Ik kan er behoorlijk enthausiast van worden.

Mijn kennis van ASP.NET is echter beperkt dus daarom blijf ik voor simpele dingen als het serveren van webpagina's en inloggen liever nog even hangen op PHP. Maar dan is dus de vraag hoe je het C# programma beveiligd. Ik moet nog even uitzoeken hoe dit allemaal zit. Op basis van wat ik tot nu toe gezien heb, heb je sowieso IIS/Azure nodig.
Appels niet met peren vergelijken.
pi_172463702
quote:
7s.gif Op zondag 16 juli 2017 17:09 schreef DevFreak het volgende:

[..]

Ik zit te denken aan iets heel simpels zoals boter-kaas en eieren spelletje of een chatprogramma, zodat ik mezelf eindelijk eens bekend kan maken met SignalR. Heb er al veel over gelezen en gehoord en heb het ook al in actie gezien. Ik kan er behoorlijk enthausiast van worden.

Mijn kennis van ASP.NET is echter beperkt dus daarom blijf ik voor simpele dingen als het serveren van webpagina's en inloggen liever nog even hangen op PHP. Maar dan is dus de vraag hoe je het C# programma beveiligd. Ik moet nog even uitzoeken hoe dit allemaal zit. Op basis van wat ik tot nu toe gezien heb, heb je sowieso IIS/Azure nodig.
Er is geloof ik ook een .Net Core variant van SignalR, dus die is dan cross platform en niet afhankelijk van een Windows server.

Als je toch met SignalR aan de slag gaat zou ik eerlijk gezegd PHP er toch echt wel tussenuit knikkeren. Als je in PHP fatsoenlijke applicaties bouwt met bijvoorbeeld een MVC structuur, dan is dat in C# niet heel anders. Bouw je front-end in iets als Angular en bouw back-end services gewoon als REST.
“I did not mean that Conservatives are generally stupid; I meant, that stupid persons are generally Conservative. I believe that to be so obvious and undeniable a fact that I hardly think any hon. Gentleman will question it.“
  zondag 16 juli 2017 @ 17:56:03 #181
159335 Boze_Appel
Vrij Fruit
pi_172464647
quote:
1s.gif Op zondag 16 juli 2017 17:29 schreef Monolith het volgende:

[..]

Er is geloof ik ook een .Net Core variant van SignalR, dus die is dan cross platform en niet afhankelijk van een Windows server.

Als je toch met SignalR aan de slag gaat zou ik eerlijk gezegd PHP er toch echt wel tussenuit knikkeren. Als je in PHP fatsoenlijke applicaties bouwt met bijvoorbeeld een MVC structuur, dan is dat in C# niet heel anders. Bouw je front-end in iets als Angular en bouw back-end services gewoon als REST.
Laravel REST en dan is het verder weinig boeiend wat voor frontend er tegenaan babbelt. Zou zelf voor React gaan. Veel mooier in de zin hoe het omgaat met verschillende statussen waar je applicatie zich bevindt,
Carpe Libertatem
pi_172464800
registreer om deze reclame te verbergen
quote:
7s.gif Op zondag 16 juli 2017 17:56 schreef Boze_Appel het volgende:

[..]

Laravel REST en dan is het verder weinig boeiend wat voor frontend er tegenaan babbelt. Zou zelf voor React gaan. Veel mooier in de zin hoe het omgaat met verschillende statussen waar je applicatie zich bevindt,
Ja, maar het gaat hier om het gebruik maken van SignalR. Dan moet je toch is C# gaan ontwikkelen en is een PHP laagje voor andere zaken eigenlijk loze ballast.
Ik zou eens kijken naar zoiets:
https://docs.microsoft.co(...)cations-with-signalr
“I did not mean that Conservatives are generally stupid; I meant, that stupid persons are generally Conservative. I believe that to be so obvious and undeniable a fact that I hardly think any hon. Gentleman will question it.“
  zondag 16 juli 2017 @ 18:01:14 #183
159335 Boze_Appel
Vrij Fruit
pi_172464830
quote:
1s.gif Op zondag 16 juli 2017 18:00 schreef Monolith het volgende:

[..]

Ja, maar het gaat hier om het gebruik maken van SignalR. Dan moet je toch is C# gaan ontwikkelen en is een PHP laagje voor andere zaken eigenlijk loze ballast.
Ik zou eens kijken naar zoiets:
https://docs.microsoft.co(...)cations-with-signalr
Oh, sorry, my bad, ik dacht dat ik in het PHP/MySQL-topic zat.
Carpe Libertatem
pi_172464879
quote:
16s.gif Op zondag 16 juli 2017 18:01 schreef Boze_Appel het volgende:

[..]

Oh, sorry, my bad, ik dacht dat ik in het PHP/MySQL-topic zat.
Het afraden van PHP past ook prima in zo'n topic. :P
“I did not mean that Conservatives are generally stupid; I meant, that stupid persons are generally Conservative. I believe that to be so obvious and undeniable a fact that I hardly think any hon. Gentleman will question it.“
  zondag 16 juli 2017 @ 18:05:08 #185
159335 Boze_Appel
Vrij Fruit
pi_172464928
quote:
1s.gif Op zondag 16 juli 2017 18:03 schreef Monolith het volgende:

[..]

Het afraden van PHP past ook prima in zo'n topic. :P
Jaja, Bart.
Carpe Libertatem
  zondag 16 juli 2017 @ 18:23:29 #186
459997 DevFreak
Still got the blues.
pi_172465358
Meh.
PHP gaat hem niet worden.

Morgen maar verder aan mijn ASP.NET cursus. :)

Het werd eigenlijk sowieso wel tijd om aan ASP te beginnen. Wat nieuws leren kan nooit geen kwaad.
Appels niet met peren vergelijken.
pi_172487664
quote:
7s.gif Op zondag 16 juli 2017 17:56 schreef Boze_Appel het volgende:

[..]

Laravel REST en dan is het verder weinig boeiend wat voor frontend er tegenaan babbelt. Zou zelf voor React gaan. Veel mooier in de zin hoe het omgaat met verschillende statussen waar je applicatie zich bevindt,
Omtrent React speelt overigens wat gedoe met licensing.
“I did not mean that Conservatives are generally stupid; I meant, that stupid persons are generally Conservative. I believe that to be so obvious and undeniable a fact that I hardly think any hon. Gentleman will question it.“
pi_172503415
quote:
0s.gif Op maandag 17 juli 2017 18:09 schreef Monolith het volgende:

[..]

Omtrent React speelt overigens wat gedoe met licensing.
Ja, ze zijn aan het zijkwijven, dat weet ik. Denk niet dat het ergens heen gaat. Het is spierballen laten zien.
Carpe Libertatem
  dinsdag 18 juli 2017 @ 18:29:20 #189
187069 slacker_nl
Sicko pur sang
pi_172509381
quote:
0s.gif Op vrijdag 14 juli 2017 14:31 schreef BrainOverfloW het volgende:

[..]

Wat ik, inmiddels succesvol, wou bereiken is dat ik zonder nadenken commando's af kan vuren in mijn terminal om dingen van/naar git te sturen.

Die upstream melding onderbrak dat steeds omdat Git dan zeurt dat de stream niet bestaat. Dan moet ik met de cursor de suggestie selecteren en plakken om door te kunnen.

Nu met de suggestie van KomtTijd... kan ik voor iedere branch de zelfde serie commando's door blijven typen tot het gepushed is.

Wat ik nu doe, met zelfgemaakte shortcodes, is
[ code verwijderd ]
Ik heb voor het up-to-date houden van m'n master niks nodig, ik fetch gewoon 1x per dag m'n upstream en dan ben ik "bij", voordat ik m'n code aanbied rebase ik en dan is het klaar.

ik heb wel een mini shell functie die de tracking branch voor me opzet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
nr FOO-XXXXX Dit is mijn vet kekke feature of bug branch

# vim vim vim

git gui # dit werkt zoveel fijner dan git add -p

# Dit kan je automaten, maar .. meh.
git co sprint
git reset --hard upstream/sprint
git merge -
git push upstream sprint:sprint

# Rinse repeat
nr FOO-XXXXX Nog meer dingen

Het nr scriptje/alias ding is dit:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
nr=alias new_repo upstream/master

new_repo () {
        if [ $# -lt 3 ]
        then
                echo "Empty branch, ticket or name" >&2
                return 1
        fi
        local branch=$1
        local ticket=$2
        shift
        shift
        local name=$(echo [email protected] | sed -e 's/ \+/_/g')
        ticket=$(echo $ticket | sed -e 's/^FOO\-\?//i')
        local br="FOO-$ticket-$name"
        git co -t $branch -b "$br"
        if [ $? -eq 0 ]
        then
                git push origin "$br:$br"
        fi
}

Ik denk overigens wel dat jij moet kijken naar: https://git-scm.com/docs/git-config, en dan in het specifieke naar push.* config items. Zie ook: https://stackoverflow.com(...)pstream-all-the-time
In theory there is no difference between theory and practice. In practice there is.
pi_173539736
Iemand hier een idee of een MyISAM tabel gebruik kan maken van meerdere threads? Ik kan er bijzonder weinig over vinden en het meeste is oude meuk. Wat ik wel kan vinden is dat het beter is over stappen op InnoDB, deze engine zou dat wel moeten kunnen.

Ik vraag dit omdat mij opvalt dat MySQL maar een enkele core gebruikt als ik een zware query uitvoer, het doorzoeken van een DB met 120.000.000 records duurt dan ook onnodig lang.

htop_mysql.png

Voordat ik de tabel om ga zetten (tijdrovende klus) wil ik echter zeker weten of het gaat helpen of dat het eventueel toch mogelijk is met MyISAM.

De serverversie die ik gebruik is: 5.7.19-0ubuntu0.16.04.1
pi_173557146
quote:
8s.gif Op zaterdag 2 september 2017 10:28 schreef bondage het volgende:
Iemand hier een idee of een MyISAM tabel gebruik kan maken van meerdere threads? Ik kan er bijzonder weinig over vinden en het meeste is oude meuk. Wat ik wel kan vinden is dat het beter is over stappen op InnoDB, deze engine zou dat wel moeten kunnen.

Ik vraag dit omdat mij opvalt dat MySQL maar een enkele core gebruikt als ik een zware query uitvoer, het doorzoeken van een DB met 120.000.000 records duurt dan ook onnodig lang.

[ afbeelding ]

Voordat ik de tabel om ga zetten (tijdrovende klus) wil ik echter zeker weten of het gaat helpen of dat het eventueel toch mogelijk is met MyISAM.

De serverversie die ik gebruik is: 5.7.19-0ubuntu0.16.04.1
Het klinkt alsof je een query uitvoert waar je geen goede indexes voor hebt. Dan moet MySQL een full table scan doen, en met 120 miljoen rijen duurt dat even. Ik zou beginnen met een EXPLAIN SELECT voor die zware query om te zien waar de verbeteringen kunnen worden gedaan.
pi_173557393
quote:
0s.gif Op zondag 3 september 2017 09:50 schreef Light het volgende:

[..]

Het klinkt alsof je een query uitvoert waar je geen goede indexes voor hebt. Dan moet MySQL een full table scan doen, en met 120 miljoen rijen duurt dat even. Ik zou beginnen met een EXPLAIN SELECT voor die zware query om te zien waar de verbeteringen kunnen worden gedaan.
Er zit een index op het veld waar ik op query. Ik heb een hele simpele uitgevoerd, dit duurt ongeveer een halve minuut om weer te geven...

Dit is de EXPLAIN output:

1
2
id     select_type     table     partitions     type     possible_keys     key     key_len     ref     rows     filtered     Extra     
1      SIMPLE          fok_post  NULL           ref      year              year    2          const     12029801     100.00     NULL

Ik zie verder ook niet heel veel schijfactiviteit als ik de query uitvoer. De server bevat twee 15k SAS schijven in RAID1, ik kan me haast niet voorstellen dat dit het probleem veroorzaakt.
pi_173557613
In de EXPLAIN kun je zien dat MySQL 12M rows moet doorzoeken, dus dat is niet efficient. Hoe ziet de query eruit? Overigens kan een index op jaartal relatief inefficiënt zijn door de lage selectiviteit.
pi_173557768
quote:
0s.gif Op zondag 3 september 2017 10:23 schreef zoem het volgende:
In de EXPLAIN kun je zien dat MySQL 12M rows moet doorzoeken, dus dat is niet efficient. Hoe ziet de query eruit? Overigens kan een index op jaartal relatief inefficiënt zijn door de lage selectiviteit.
Gewoon, zo: SELECT * FROM `fok_post` WHERE `year` = 2012

Ik heb nog meer indexen, het jaar veld en index gebruik ik om de set te minimaliseren tijdens het bijwerken van de Sphinx index. Simpele select query's zijn overigens wel gewoon snel, als ik een topic zoek aan de hand van een id dan gaat dat in milliseconden. Het is alleen bij grote resultaat sets dat het zo lang duurt.

Of zijn mijn verwachtingen te hoog? Ik zou haast denken dat een server met 24 cores en 96 gig aan geheugen dit wel aan zou moeten kunnen. Het is echter net zo snel/traag als mijn vorige server die een simpele twee core Celeron en 16gig geheugen had :')
pi_173558047
Id's zijn uniek, dus logisch dat je vrijwel instant resultaat hebt. Bij de jaartallen zijn er waarschijnlijk ~20 unieke waardes, dus het kan zijn dat de optimizer kiest voor een full table scan. Gezien filtered op 100% staat lijkt dat ook het geval te zijn.
pi_173558141
Sowieso zou ik de snelheden van queries als

1SELECT * FROM fok_post WHERE year = 2012
1SELECT * FROM fok_post WHERE id < 12000000

Dan neem ik aan dat je in beide gevallen ongeveer evenveel records terugkrijgt. (Dat kun je nog vergelijken met een SELECT COUNT(*))

Data transfer bij zulke aantallen rijen is ook een belangrijke factor.
pi_173558480
quote:
0s.gif Op zondag 3 september 2017 10:52 schreef zoem het volgende:
Id's zijn uniek, dus logisch dat je vrijwel instant resultaat hebt. Bij de jaartallen zijn er waarschijnlijk ~20 unieke waardes, dus het kan zijn dat de optimizer kiest voor een full table scan. Gezien filtered op 100% staat lijkt dat ook het geval te zijn.
Als hij een full scan doet lijkt me het nog redelijk snel... Op zich maakt het niet zoveel uit dat het 30 sec. duurt voordat Sphinx de resultaten heeft, het viel me gewoon op dat ik weinig verschil merk ten opzichte van mijn vorige server en dat er slechts één core wordt gebruikt als ik de query uitvoer.

quote:
0s.gif Op zondag 3 september 2017 10:57 schreef Light het volgende:
Sowieso zou ik de snelheden van queries als
[ code verwijderd ]

[ code verwijderd ]

Dan neem ik aan dat je in beide gevallen ongeveer evenveel records terugkrijgt. (Dat kun je nog vergelijken met een SELECT COUNT(*))

Data transfer bij zulke aantallen rijen is ook een belangrijke factor.
1SELECT * FROM fok_post WHERE id < 12000000

Dat duurde ongeveer 2 seconden... Het totaal is inderdaad redelijk gelijk aan elkaar.

Disk I/O even getest, dit is de output:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[email protected]:~# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   16568 MB in  2.00 seconds = 8291.40 MB/sec
 Timing buffered disk reads: 594 MB in  3.00 seconds = 197.76 MB/sec

[email protected]:~# time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

1024+0 records in
1024+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.0728517 s, 1.4 GB/s

real    0m0.774s
user    0m0.008s
sys     0m0.072s
pi_173558725
Naar InnoDB converteren zou ik zelf wel gedaan hebben. MyISAM wordt niet echt meer doorontwikkeld en in MySQL 5.6+ kent MyISAM amper nog voordelen boven InnoDB.

Ik vrees dat je deze query met de huidige dataset niet kan versnellen. Wellicht valt de data anders op te vragen (in batches met year=A and id BETWEEN x AND y) of kijken of partitioning iets kan betekenen.
pi_173558873
quote:
0s.gif Op zondag 3 september 2017 11:31 schreef zoem het volgende:
Naar InnoDB converteren zou ik zelf wel gedaan hebben. MyISAM wordt niet echt meer doorontwikkeld en in MySQL 5.6+ kent MyISAM amper nog voordelen boven InnoDB.

Ik vrees dat je deze query met de huidige dataset niet kan versnellen. Wellicht valt de data anders op te vragen (in batches met year=A and id BETWEEN x AND y) of kijken of partitioning iets kan betekenen.
Ik ga een kopie van de tabel maken en hem omzetten, kan ik eea testen. Het omzetten gaat een middagje duren denk ik...
abonnementen ibood.com bol.com Gearbest
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')