Waarom?quote:Op zondag 17 maart 2019 21:35 schreef DevFreak het volgende:
[..]
valt mee, maar ik probeer de webserver ertussenuit te slopen
Ghehe. Volgens mij is het in NodeJS heus niet gemakkelijker dan in PHP.quote:Op zondag 17 maart 2019 21:54 schreef embedguy het volgende:
[..]
Webserver? Nginx/apache bedoel je? Dan is dat wel een stuk makkelijker dan dit ja met php. Ben zelf eigenlijk niet anders gewend, tja; nodejs :p
Wat is dat [nosml] gebeuren eigk voor?
Omdat webservers als jaren absolete zijn. Door zelf met sockets te werken hoef je slechts één instance van Laravel te starten en daarmee per server tot 50.000 clients verwerken, inclusief shared resources.quote:
Nope, hetzelfde idee als dit. Maar ik bedoelde dat de 'normale php' manier makkelijker is. Tja, dan heb je de voordelen ook niet.quote:Op maandag 18 maart 2019 11:39 schreef DevFreak het volgende:
[..]
Ghehe. Volgens mij is het in NodeJS heus niet gemakkelijker dan in PHP.
NodeJS is ook geen taal, maar een platform.quote:Op maandag 18 maart 2019 11:39 schreef DevFreak het volgende:
Verder is PHP als taal natuurlijk een heel stuk volwassener en meer gebruikt dan NodeJS.
Beide zijn rottalen.quote:Op maandag 18 maart 2019 22:59 schreef Monolith het volgende:
[..]
NodeJS is ook geen taal, maar een platform.
JavaScript is verder ook niet meer of minder volwassen dan PHP in mijn ogen.
Ben maar begonnen met C leren, dat is pas een leuke taal Hoi slakquote:
Vind je?quote:Op woensdag 20 maart 2019 22:38 schreef WyriHaximus het volgende:
[..]
Ben maar begonnen met C leren, dat is pas een leuke taal Hoi slak
Pak dan gewoon gelijk Rust.quote:Op woensdag 20 maart 2019 22:38 schreef WyriHaximus het volgende:
[..]
Ben maar begonnen met C leren, dat is pas een leuke taal Hoi slak
Daar ben ik nu ook soort van mee bezig. Ik wil iets in git krijgen en doe soms wat met de lastpass cli client. Beide zijn geschreven in C. Best leukquote:Op woensdag 20 maart 2019 22:38 schreef WyriHaximus het volgende:
[..]
Ben maar begonnen met C leren, dat is pas een leuke taal Hoi slak
Hmm, PHP is met 7.3 toch wel volwassener en beter dan je denkt...quote:Op maandag 18 maart 2019 22:59 schreef Monolith het volgende:
[..]
NodeJS is ook geen taal, maar een platform.
JavaScript is verder ook niet meer of minder volwassen dan PHP in mijn ogen.
Hoe weet je dat? Ik vergelijk PHP en JavaScript.quote:Op donderdag 21 maart 2019 09:43 schreef DevFreak het volgende:
[..]
Hmm, PHP is met 7.3 toch wel volwassener en beter dan je denkt...
7.4 komt er ook aan en brengt nog veel meer verbeteringen met zich mee.
Ach, kom... het zijn twee totaal verschillende talen met verschillende doeleinden.quote:Op donderdag 21 maart 2019 09:45 schreef Monolith het volgende:
[..]
Hoe weet je dat? Ik vergelijk PHP en JavaScript.
Klopt, ik vind het allebei niets.quote:Op donderdag 21 maart 2019 09:47 schreef DevFreak het volgende:
[..]
Ach, kom... het zijn twee totaal verschillende talen met verschillende doeleinden.
Ik vind PHP zelf eigenlijk een vrij robuuste taal. Wat me derhalve wel stoort zijn de frameworks. Ze zuigen állemaal. Je moet goed bij blijven omdat migreren anders bijna niet te doen is.quote:Op donderdag 21 maart 2019 09:48 schreef Monolith het volgende:
[..]
Klopt, ik vind het allebei niets.
Maar dat doet niets af aan het feit dat de één niet meer of minder volwassen is dan de ander.
Doe mij maar gewoon Java of C# in een enterprise omgeving, iets als Haskell voor nichetoepassingen en van die wat hippere dingetjes als Go, Kotlin en Rust om een beetje mee aan te klooien vooralsnog.quote:Op donderdag 21 maart 2019 09:53 schreef DevFreak het volgende:
[..]
Ik vind PHP zelf eigenlijk een vrij robuuste taal. Wat me derhalve wel stoort zijn de frameworks. Ze zuigen állemaal. Je moet goed bij blijven omdat migreren anders bijna niet te doen is.
Ik zit opm ijn werk nu ook met een groot Laravel 4.2 platform, dat ze willen migreren naar 5.8. Nu is het sowieso wel kut geschreven allemaal, maar ik verwacht dat ik de komende 6 maanden nog bezig ben met dit grapje.
Welk vak?quote:Op woensdag 20 maart 2019 22:44 schreef FlippingCoin het volgende:
[..]
Vind je?
Moet nu voor een vak met sensoren werken met C maar vind het meegeven van arrays en itereren over verzamelingen en zo maar een gekut vergeleken met een taal als Go.
Oh voor studie.quote:
Laravel 4.2, die is bijna prehistorisch! Er is heel veel gebeurd sinds de pakweg 5 jaar dus upgraden zal best een klus zijn inderdaad. Ik werk inmiddels al een jaar bijna uitsluitend met laravel en vind het op zich best goed, zeker voor niet al te grote sites. Bij echt grote complexe applicaties loop je toch uiteindelijk tegen de beperkingen aan, en al die magic die er onder de motorkap gebruikt wordt daar word ik ook steeds minder fan van.quote:Op donderdag 21 maart 2019 09:53 schreef DevFreak het volgende:
[..]
Ik vind PHP zelf eigenlijk een vrij robuuste taal. Wat me derhalve wel stoort zijn de frameworks. Ze zuigen állemaal. Je moet goed bij blijven omdat migreren anders bijna niet te doen is.
Ik zit opm ijn werk nu ook met een groot Laravel 4.2 platform, dat ze willen migreren naar 5.8. Nu is het sowieso wel kut geschreven allemaal, maar ik verwacht dat ik de komende 6 maanden nog bezig ben met dit grapje.
Ja I know. Ze snappen het ook gewoon echt niet hier dat het migreren weleens langer dan 4 maanden kan duren, zeker met die belachelijke kutcode waar het nu uit bestaat...quote:Op donderdag 21 maart 2019 10:43 schreef Farenji het volgende:
[..]
Laravel 4.2, die is bijna prehistorisch! Er is heel veel gebeurd sinds de pakweg 5 jaar dus upgraden zal best een klus zijn inderdaad. Ik werk inmiddels al een jaar bijna uitsluitend met laravel en vind het op zich best goed, zeker voor niet al te grote sites. Bij echt grote complexe applicaties loop je toch uiteindelijk tegen de beperkingen aan, en al die magic die er onder de motorkap gebruikt wordt daar word ik ook steeds minder fan van.
Maar dat php een robuuste taal is, daar ben ik het echt niet mee eens. Dankzij het dikke tapijt van laravel is het te doen maar plain php blijft een gammele bende vol pitfalls. De nieuwere versies voegen wel wat leuke dingen toe maar de basis verandert niet echt en daar loop ik nog steeds wel eens tegenaan. Wat dat betreft liever python of perl, daar is beduidend beter over nagedacht.
Maar wacht even...quote:Op donderdag 21 maart 2019 10:43 schreef Farenji het volgende:
[..]
Laravel 4.2, die is bijna prehistorisch! Er is heel veel gebeurd sinds de pakweg 5 jaar dus upgraden zal best een klus zijn inderdaad. Ik werk inmiddels al een jaar bijna uitsluitend met laravel en vind het op zich best goed, zeker voor niet al te grote sites. Bij echt grote complexe applicaties loop je toch uiteindelijk tegen de beperkingen aan, en al die magic die er onder de motorkap gebruikt wordt daar word ik ook steeds minder fan van.
Maar dat php een robuuste taal is, daar ben ik het echt niet mee eens. Dankzij het dikke tapijt van laravel is het te doen maar plain php blijft een gammele bende vol pitfalls. De nieuwere versies voegen wel wat leuke dingen toe maar de basis verandert niet echt en daar loop ik nog steeds wel eens tegenaan. Wat dat betreft liever python of perl, daar is beduidend beter over nagedacht.
Het gaat al mis bij de implementatie van basale data structures.quote:Op donderdag 21 maart 2019 13:45 schreef DevFreak het volgende:
[..]
Maar wacht even...
Wanneer je tien jaar geleden had gezegd dat PHP een bende is vol pitfalls had ik het met je eens geweest. Ben je wel goed op de hoogte van alle ontwikkelingen en verbeteringen die PHP 7+ gebracht heeft? Ik zou graag een concreet voorbeeld willen zien van dingen waar je tegenaan loopt t.o.v. Python, want ik vind het erg meevallen.
Ik vind vooral de variable scope van php superkut. In php zijn alle variabelen vanzelf global dus als je binnen een block (bijv een loop) een variabele zet dan is ie buiten dat block opeens ook gezet. Dat is gaar. Maar functies hebben dan opeens weer een eigen scope, waardoor je overal met "function ($foo) use ($bar)" moet werken. Geen enkele andere taal die ik ken doet dat zo. Daardoor is het ook onmogelijk om bijv een "strict pragma" te hebben wat je in perl hebt. Dan word je gedwongen om alle variabelen te instantieren voordat je ze gebruikt en compileert je applicatie niet eens meer als je bijv ergens een tikfout in een variabelenaam hebt. PHP geeft minder fucks hierom en dan zou je onvoorspelbare resultaten kunnen krijgen.quote:Op donderdag 21 maart 2019 13:45 schreef DevFreak het volgende:
[..]
Maar wacht even...
Wanneer je tien jaar geleden had gezegd dat PHP een bende is vol pitfalls had ik het met je eens geweest. Ben je wel goed op de hoogte van alle ontwikkelingen en verbeteringen die PHP 7+ gebracht heeft? Ik zou graag een concreet voorbeeld willen zien van dingen waar je tegenaan loopt t.o.v. Python, want ik vind het erg meevallen.
1 | function (Foo $foo) {} |
1 | function (string $i) {} |
1 2 3 4 5 6 7 8 | <?php $vorigedag = date('d-m-Y',strtotime("-1 days")); // 20-03-2019 $vorigejaar =date("Y",$vorigedag); // 2019 $vorigemaand =date("m",$vorigedag); // 03 $vorigeday=date("d",$vorigedag); // 20 $vorigeNaamvanDag = date("l", mktime(0,0,0,$vorigemaand,$vorigeday,$vorigejaar)); $vorigedagTXT ='./'.$vorigejaar.'/'.$vorigemaand.'/'.$vorigedag.'.txt'; // 2019/03/21-03-2019.txt ?> |
1 | 1970/01/21-03-2019.txt |
1 | 2019/03/21-03-2019.txt |
1 2 3 | <?php $vorigedagTXT = ". /". date("Y/m/d-m-Y", strtotime("-1 day")). ".txt" ; ?> |
Inhoudelijk heb je deels zeker gelijk, maar het andere deel klopt niet. Ik kom hier later nog op terug.quote:Op donderdag 21 maart 2019 16:33 schreef Farenji het volgende:
[..]
Ik vind vooral de variable scope van php superkut. In php zijn alle variabelen vanzelf global dus als je binnen een block (bijv een loop) een variabele zet dan is ie buiten dat block opeens ook gezet. Dat is gaar. Maar functies hebben dan opeens weer een eigen scope, waardoor je overal met "function ($foo) use ($bar)" moet werken. Geen enkele andere taal die ik ken doet dat zo. Daardoor is het ook onmogelijk om bijv een "strict pragma" te hebben wat je in perl hebt. Dan word je gedwongen om alle variabelen te instantieren voordat je ze gebruikt en compileert je applicatie niet eens meer als je bijv ergens een tikfout in een variabelenaam hebt. PHP geeft minder fucks hierom en dan zou je onvoorspelbare resultaten kunnen krijgen.
Verder vind ik het kut dat php geen aparte types voor hash (dictionary) en array heeft. Dit zijn heel andere types met andere werking maar in php is het allemaal hetzelfde, een "associative hash". Die numerieke keys kan hebben of string keys, met allemaal pitfalls. En dan heb je ook nog de StdClass objecten. Verwarrend en irritant.
En dan iets wat php nog steeds heeft is die shitload aan inconsequente functies allemaal binnen de core. Tig verschillende sort functies waar 1 had volstaan, functie argumenten die anders zijn, de ene keer $needle, $haystack en de andere keer $haystack, $needle, bijvoorbeeld. Je hebt "str_replace" maar ook "strcomp", zonder underscore opeens.
En dan de type hinting die op zich nice is, maar ook inconsequent is. Doe je:
[ code verwijderd ]
En je geeft daar een Bar instance aan mee borkt ie, terecht. Maar doe je:
[ code verwijderd ]
En je geeft daar een int aan mee, dan borkt ie niet maar cast ie je int gewoon stilletjes naar string. Het is het allemaal gewoon net niet.
Just a note;quote:Op vrijdag 22 maart 2019 14:02 schreef NoXia het volgende:
Iemand die mij kan helpen?
[ code verwijderd ]
Output:
[ code verwijderd ]
in plaats van
[ code verwijderd ]
Wat doe ik fout?
Wanneer ongeveer? :p Ben wel benieuwd.quote:Op vrijdag 22 maart 2019 16:38 schreef DevFreak het volgende:
[..]
Inhoudelijk heb je deels zeker gelijk, maar het andere deel klopt niet. Ik kom hier later nog op terug.
Of een library gebruiken die daar rekening mee houdt.quote:Op maandag 25 maart 2019 09:32 schreef slacker_nl het volgende:
Als je gaat rekenen met tijd moet je altijd de tijd converten naar UTC dan de berekening doen en daarna weer terug naat je lokale tijdzone. Dan ben je in 99,999999% van de tijd veilig.
Rekenen met tijd is echt kut door alle tijdzones, daglichtspaartijden, veranderingen van bovengenoemde op willekeurige momenten (google op Amsterdamse tijd en eventueel op 1mei 1940 voor als je met software werkt waarbij je software potentieel met bejaarden werkt).
Dit klopt deels. Je refereert nu waarschijnlijk naar procedureel geschreven PHP-code, waarbij dit in ieder geval het standaardgedrag was onder versie 5.x. Ik ken echter geen enkele programmeur die hedendaags nog procedurele PHP-code schrijft. Tegenwoordig is het object-georiënteerd programmeren actueel, waarbij je dan werkt met classes, properties en functies met hun eigen visibility levels.quote:Op donderdag 21 maart 2019 16:33 schreef Farenji het volgende:
[..]
Ik vind vooral de variable scope van php superkut. In php zijn alle variabelen vanzelf global dus als je binnen een block (bijv een loop) een variabele zet dan is ie buiten dat block opeens ook gezet. Dat is gaar. Maar functies hebben dan opeens weer een eigen scope, waardoor je overal met "function ($foo) use ($bar)" moet werken. Geen enkele andere taal die ik ken doet dat zo. Daardoor is het ook onmogelijk om bijv een "strict pragma" te hebben wat je in perl hebt. Dan word je gedwongen om alle variabelen te instantieren voordat je ze gebruikt en compileert je applicatie niet eens meer als je bijv ergens een tikfout in een variabelenaam hebt. PHP geeft minder fucks hierom en dan zou je onvoorspelbare resultaten kunnen krijgen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | namespace TCPChat { use React\EventLoop\Factory; use React\Socket\ConnectionInterface; use React\Socket\Server; /** * Class Application * @package TCPChat */ final class Application { /** * @return void */ public static function main(): void { // Je code hier } } Application::main(); } |
Dit is volstrekte nonsens. De Zend-engine biedt ons verscheidene datastructuren aan, zoals je hier kunt lezen:quote:Verder vind ik het kut dat php geen aparte types voor hash (dictionary) en array heeft. Dit zijn heel andere types met andere werking maar in php is het allemaal hetzelfde, een "associative hash". Die numerieke keys kan hebben of string keys, met allemaal pitfalls. En dan heb je ook nog de StdClass objecten. Verwarrend en irritant.
Dit gedrag is in PHP >7.0 allang aangepast en dus niet meer van toepassing. In PHP 7.4 wordt het zelfs allemaal nog veel mooier, met onder andere static typed class properties. Ik kan niet wachten tot december.quote:En dan iets wat php nog steeds heeft is die shitload aan inconsequente functies allemaal binnen de core. Tig verschillende sort functies waar 1 had volstaan, functie argumenten die anders zijn, de ene keer $needle, $haystack en de andere keer $haystack, $needle, bijvoorbeeld. Je hebt "str_replace" maar ook "strcomp", zonder underscore opeens.
En dan de type hinting die op zich nice is, maar ook inconsequent is. Doe je:
[ code verwijderd ]
En je geeft daar een Bar instance aan mee borkt ie, terecht. Maar doe je:
[ code verwijderd ]
En je geeft daar een int aan mee, dan borkt ie niet maar cast ie je int gewoon stilletjes naar string. Het is het allemaal gewoon net niet.
^ zie hierquote:Op dinsdag 26 maart 2019 20:44 schreef bloemetjeklaver het volgende:
[..]
Wanneer ongeveer? :p Ben wel benieuwd.
Bedoel zelf heb ik het idee dat hij gelijk heeft in wat hij zegt maar dat hij gewoon de voorkeur voor strict heeft om het zo maar te zeggen. PHP is wat losjes, dat weet iedereen, om dan te gaan zeggen dat je dat persoonlijk helemaal niet fijn vindt, tjah oke. Is je eigen voorkeur/mening. Voor mij werkt het prima, niet omdat ik niet precies genoeg werk, misschien wel juist omdat ik precies genoeg werk met een taal waarbij dat niet nodig is waardoor het niet helemaal haywire gaat.
Als je moeite hebt met scope etc van een taal omdat deze afwijkt van een andere taal dan tjah.. superkut dan voor hemzelf zoals hij al zegt
1 | select * from ip_database where IP = 'ip adres hier'' |
Nee door ''' i.p.v. ''quote:Op vrijdag 29 maart 2019 09:33 schreef NoXia het volgende:
SQL hell!
Gaat hij over zijn nek door de puntjes?
quote:
1 | SELECT * FROM `ip_database` WHERE IP = "8.8.8.8" |
Lijkt me dat er een bepaalde omzetting nodig is, cast ofzo om het overeen te laten komen.quote:Op vrijdag 29 maart 2019 10:26 schreef NoXia het volgende:
[..]
[ code verwijderd ]
levert ook niets op terwijl de row wel gewoon in de database staat.
Thanks. Ik had deze ook op varchar staan maar die kreeg ik er ook niet uit gepompt. Daarna veranderd naar varbinary. Maar dit werkte ook niet.quote:Op vrijdag 29 maart 2019 10:41 schreef phoenyx het volgende:
[..]
Lijkt me dat er een bepaalde omzetting nodig is, cast ofzo om het overeen te laten komen.
Bedoel als je in de database kijkt met phpmyadmin of een workbench kan het best zo zijn dat je 8.8.8.8 ziet omdat die het omzetten naar iets leesbaars. Zij weten immers dat het varbinary is dus zetten 0x5468697320697320612074657374 om naar 8.8.8.8 of wat dan ook.
Dus je moet de 8.8.8.8 converten of casten ofzo naar varbinary voordat je vergelijking iets op gaat leveren. Sla zelf ook ip's op maar gewoon als varchar, nooit echt aan binary gedacht om zoiets mee op te slaan
1 | SELECT * FROM `ip_database` WHERE `IP` LIKE "%8.8.8.8%" |
Oke misschien spaties die hij dan meeneemt in de vergelijking?quote:Op vrijdag 29 maart 2019 13:46 schreef NoXia het volgende:
Als ik
[ code verwijderd ]
doe krijg ik hem wel
Deze kon ik niet. Hier ga ik naar kijken.quote:Op vrijdag 29 maart 2019 13:56 schreef zoem het volgende:
Had je al gekeken naar inet_pton() en inet_ntop()? Dan kun je ipv4/6 converteren van/naar binary. Voor ipv4 only kun je kijken naar int in combinatie met inet_ntoa() en inet_aton().
Leek mij inderdaad ook logisch. Maar heb geen spatie kunnen ontdekken. Vaag hoor.quote:Op vrijdag 29 maart 2019 13:57 schreef phoenyx het volgende:
[..]
Oke misschien spaties die hij dan meeneemt in de vergelijking?
1 | UPDATE ip_database SET IP = LTRIM(RTRIM(IP)) |
ja ik was aan het werk of factorio aan het spelen laatst Factorio (vervolg op openttd) maar dan machinaal.quote:
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.Werkt Perfect (althans single threaded getest als ik meerdere connecties heb moet ik nog eens kijken of ik alle variabelen goed gezet heb maar meerdere berichten achter elkaar kan het versturen en ontvangen .
[ Bericht 44% gewijzigd door cablegunmaster op 20-06-2019 11:03:24 ]Redacted
Meer Composer: https://getcomposer.org/quote:Op zondag 19 april 2020 18:25 schreef slacker_nl het volgende:
Vroegah, had PHP Pear voor als een repository voor packages, waarbij men modules en zulks kon delen. Is dat nog steeds een ding of is het inmiddels iets anders geworden?
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |