De Devschuur Coffee Corner - Iteratie ⓬

[gekkie]

Ik vind nog het vervelendste dat het voornamelijk het paard achter de wagen spannen is.
Als je fijn op je client automagisch cookies blokt, loop je iedere keer weer te hoop tegen de cookiewall aan en mag je handmatig actie ondernemen .

Nog een voor de vrienden van FOSDEM, moet zeggen dat de streaming vandaag prima functioneerde. Alleen die microfoons blijven lastige gevallen geloof ik.

[ThomasG]

gekkie schreef op zondag 3 februari 2019 @ 19:41:
Ik vind nog het vervelendste dat het voornamelijk het paard achter de wagen spannen is.
Als je fijn op je client automagisch cookies blokt, loop je iedere keer weer te hoop tegen de cookiewall aan en mag je handmatig actie ondernemen .

Dit. En van die websites die de pagina gaan herladen als je de cookies accepteert (of weigert). Wordt je doorverwezen naar een bepaalde website, maar die cookie balk zit steeds half over de tekst heen die je wilt lezen. Dus accepteert ik maar de cookies odat ik het beter kan lezen, wordt de pagina herladen... Daar kan ik mij echt dood aan ergeren.

[gekkie]

ThomasG schreef op maandag 4 februari 2019 @ 10:01:
[...]
Dit. En van die websites die de pagina gaan herladen als je de cookies accepteert (of weigert). Wordt je doorverwezen naar een bepaalde website, maar die cookie balk zit steeds half over de tekst heen die je wilt lezen. Dus accepteert ik maar de cookies odat ik het beter kan lezen, wordt de pagina herladen... Daar kan ik mij echt dood aan ergeren.

Ik denk er dan maar uit af te kunnen leiden dat diegene die de regeltjes verzinnen, kennelijk geen cookies blokkeren.
Achja Nu.nl is wat dat betreft ook wel apart, met hun jij cookies (en/of ads) blokken, dan geen videotjes bij berichten kijken. Net alsof ze überhaupt unieke content zouden hebben .

[ Voor 13% gewijzigd door gekkie op 04-02-2019 10:06 ]

[Mugwump]

Of ik nog gratis kaarten wilde voor de Tweakers dev summit. Vooruit dan maar weer.

[mcDavid]

gekkie schreef op maandag 4 februari 2019 @ 10:04:
[...]

Ik denk er dan maar uit af te kunnen leiden dat diegene die de regeltjes verzinnen, kennelijk geen cookies blokkeren.
Achja Nu.nl is wat dat betreft ook wel apart, met hun jij cookies (en/of ads) blokken, dan geen videotjes bij berichten kijken. Net alsof ze überhaupt unieke content zouden hebben .

Nu.nl en soortgelijke copy-paste websites kijk ik al jaren niet meer naar. Doe mij maar een medium wat nog aan onderzoeksjournalistiek doet, dan wil ik er gerust voor betalen. Een beetje de bekende nieuwsfeeds scrapen wordt niemand wijzer van.

[ThomasG]

mcDavid schreef op maandag 4 februari 2019 @ 11:35:
[...]


Nu.nl en soortgelijke copy-paste websites kijk ik al jaren niet meer naar. Doe mij maar een medium wat nog aan onderzoeksjournalistiek doet, dan wil ik er gerust voor betalen. Een beetje de bekende nieuwsfeeds scrapen wordt niemand wijzer van.

Ik kom niet vaak op nu.nl, maar als ik er kom is het vooral om de reacties te lezen Echter, sinds de reactiemogelijkheid terug is worden de reacties nog sterker gecencureerd dan voorheen (als in: ze verwijderen ineens alle reacties en doen het op slot).

[dev10]

rutgerw schreef op vrijdag 1 februari 2019 @ 20:50:
[...]


Moest direct aan dit denken: https://2018.bloomca.me/ (een parodie op al die dingen die je weg moet klikken). Al jouw klachten komen voorbij!

Ik mis er hier nog eentje in: die pop-up die je wel eens krijgt bij de eerste pageview van een website om te kijken wat er verbeterd kan worden op die website en je mening te geven.

Dat weet ik nog niet, want ik krijg niet eens de kans om goed rond te kijken.

En daarna krijg je die pop-up dus never nooit meer heh.

[.oisyn]

dev10 schreef op maandag 4 februari 2019 @ 12:26:
Dat weet ik nog niet, want ik krijg niet eens de kans om goed rond te kijken.

Dat weet je dus wel, die popup is irritant

[dev10]

Dat klopt ja.

Maar het is gewoon stom dat ze direct op de eerst pageview gelijk al dit pop-up tonen.

[GateKeaper]

ThomasG schreef op maandag 4 februari 2019 @ 11:38:
[...]
Ik kom niet vaak op nu.nl, maar als ik er kom is het vooral om de reacties te lezen Echter, sinds de reactiemogelijkheid terug is worden de reacties nog sterker gecencureerd dan voorheen (als in: ze verwijderen ineens alle reacties en doen het op slot).

Ook leuk als je 's avonds het nieuws leest:

De moderator is naar huis. Je kan morgen weer reageren. Maar dan is het artikel wel van de voorpagina af.

Het medium is er inderdaad niet beter op geworden. De reacties zijn nu dan wel van iets hoger niveau dan voorheen. Maar het discussiëren is vrijwel onmogelijk gemaakt door de slechte integratie (en het standaard uit staan) van reactie notificaties.

[mcDavid]

Och, de reacties die de moeite waard zijn komen toch wel langs op /r/nujijinactie. Hoef je niet voor te lurken op nu.nl zelf

[Jegorex]

Ik ben dit weekend gebanned in Aion (MMO) omdat mijn wachtwoord te lang was...
Blijkbaar mag een wachtwoord niet meer dan 16 tekens bevatten en als er iets fout gaat tijdens het wijzigen van je account wordt je onmiddelijk gebanned.

[ThomasG]

Jegorex schreef op maandag 4 februari 2019 @ 15:03:
Ik ben dit weekend gebanned in Aion (MMO) omdat mijn wachtwoord te lang was...
Blijkbaar mag een wachtwoord niet meer dan 16 tekens bevatten en als er iets fout gaat tijdens het wijzigen van je account wordt je onmiddelijk gebanned.

Buffer overflow, en nu zijn de database velden na het wachwoord overschreven waardoor het systeem denkt dat je verbannen bent

[Jegorex]

ThomasG schreef op maandag 4 februari 2019 @ 15:17:
[...]
Buffer overflow, en nu zijn de database velden na het wachwoord overschreven waardoor het systeem denkt dat je verbannen bent

Hopen dat het systeem de volgende keer denkt dat ik een admin ben

In theorie zou de lengte van een wachtwoord niet uitmaken toch als je hem hashed in de database?
Een wachtwoord van 1 teken zal net zo lang zijn als een wachtwoord van 1000 tekens na het hashen.

[ Voor 23% gewijzigd door Jegorex op 04-02-2019 15:24 ]

[ThomasG]

Jegorex schreef op maandag 4 februari 2019 @ 15:22:
[...]

Hopen dat het systeem de volgende keer denkt dat ik een admin ben

In theorie zou de lengte van een wachtwoord niet uitmaken toch als je hem hashed in de database?
Een wachtwoord van 1 teken zal net zo lang zijn als een wachtwoord van 1000 tekens na het hashen.

Voor de lengte van de hash maakt het niet uit. Maar hoe langer het wachtwoord hoe hoger de stress op het systeem. Als er helemaal geen limiet op zou zitten, kun je daarmee natuurlijk relatief gemakkelijk het systeem onderuit halen omdat het overvraagd wordt. Maar een limit van 16 tekens is, zeker in deze tijd, volkomen onnodig. Tenzij ze de wachtwoorden niet (goed) hashen natuurlijk.

De lengte van een wachtwoord is juist een van de factoren voor een veilig wachtwoord: hoe langer, hoe beter. Maximum lengtes van minder dan 500 tekens slaat gewoon nergens op

[Mugwump]

GateKeaper schreef op maandag 4 februari 2019 @ 13:38:
[...]


Ook leuk als je 's avonds het nieuws leest:


[...]


Het medium is er inderdaad niet beter op geworden. De reacties zijn nu dan wel van iets hoger niveau dan voorheen. Maar het discussiëren is vrijwel onmogelijk gemaakt door de slechte integratie (en het standaard uit staan) van reactie notificaties.

Mja, websites met summiere nieuwsberichtjes trekken toch een zekere 'reaguurderspopulatie' aan die doorgaans niet de meest beschaafde discussies voeren.
Tweakers heeft op de wat gevoeligere topics in de actualiteitenfora ook wel strenge moderatie en dan is men hier over het algemeen nog best beschaafd.

[alienfruit]

Volgens mij heb ik een geheugenlekje:

code:

[17579:0x102801000]   137838 ms: Mark-sweep 1343.9 (1468.4) -> 1343.8 (1468.4) MB, 2292.6 / 0.1 ms  allocation failure GC in old space requested
[17579:0x102801000]   139211 ms: Mark-sweep 1343.8 (1468.4) -> 1343.8 (1437.4) MB, 1372.8 / 0.1 ms  last resort GC in old space requested
[17579:0x102801000]   140371 ms: Mark-sweep 1343.8 (1437.4) -> 1343.8 (1437.4) MB, 1160.3 / 0.1 ms  last resort GC in old space requested

[gekkie]

ThomasG schreef op maandag 4 februari 2019 @ 15:32:
[...]
De lengte van een wachtwoord is juist een van de factoren voor een veilig wachtwoord: hoe langer, hoe beter. Maximum lengtes van minder dan 500 tekens slaat gewoon nergens op

Wat voor wereld schokkends gaat er dan gebeuren met 499 tov 500 ?
(altijd leuk arbitraire exacte limieten )

[ Voor 31% gewijzigd door gekkie op 04-02-2019 15:54 ]

[ThomasG]

gekkie schreef op maandag 4 februari 2019 @ 15:53:
[...]

Wat voor wereld schokkends gaat er dan gebeuren met 499 tov 500 ?
(altijd leuk arbitraire exacte limieten )

Was gewoon nattevinger werk Ik vond 1000 weer wat overdreven. Aan de andere kant gerbruik ik wel 4K ssh keys. Dus wachtwoorden van max 8K is wel een leuk maximum

[Douweegbertje]

alienfruit schreef op maandag 4 februari 2019 @ 15:50:
Volgens mij heb ik een geheugenlekje:

code:

[17579:0x102801000]   137838 ms: Mark-sweep 1343.9 (1468.4) -> 1343.8 (1468.4) MB, 2292.6 / 0.1 ms  allocation failure GC in old space requested
[17579:0x102801000]   139211 ms: Mark-sweep 1343.8 (1468.4) -> 1343.8 (1437.4) MB, 1372.8 / 0.1 ms  last resort GC in old space requested
[17579:0x102801000]   140371 ms: Mark-sweep 1343.8 (1437.4) -> 1343.8 (1437.4) MB, 1160.3 / 0.1 ms  last resort GC in old space requested

Volgens mij Tweakers ook... het laad allemaal erg traag

ThomasG schreef op maandag 4 februari 2019 @ 16:06:
[...]
Was gewoon nattevinger werk Ik vond 1000 weer wat overdreven. Aan de andere kant gerbruik ik wel 4K ssh keys. Dus wachtwoorden van max 8K is wel een leuk maximum

Behalve dat ik liever geen post request heb van 8k karakters.. Sowieso zal dat out of de box denk ik niet werken met de default waardes van nginx/apache e.d. in de headers and such

[ Voor 26% gewijzigd door Douweegbertje op 04-02-2019 16:26 ]

[.oisyn]

Douweegbertje schreef op maandag 4 februari 2019 @ 16:24:
[...]


Volgens mij Tweakers ook... het laad allemaal erg traag

En jij ook, je kennis van grammaticaregels zijn geswapt naar disk denk ik

[Douweegbertje]

.oisyn schreef op maandag 4 februari 2019 @ 16:31:
[...]

En jij ook, je kennis van grammaticaregels zijn geswapt naar disk denk ik

Ugh ja. Ik ben er sowieso slecht in maar met zakelijke meuk stop ik er dermate veel energie in dat ik op bijvoorbeeld een fora m'n meuk neergooi en het direct verstuur

[GateKeaper]

Sorry, je hebt deze laten vallen: .,

[Douweegbertje]

[Lethalis]

Mijn Docker avontuur
Zo... heb mij de afgelopen dagen / weken verdiept in Docker en Linux kernel namespaces.

We leven eigenlijk in een bizarre wereld. Een wereld waarin iedereen te graag processen als root wil draaien, wanneer dat vaak niet nodig is.

Het begon er allemaal mee dat ik SQL Server 2017 voor Linux ging testen met Docker. Eerst heb ik mij verdiept in de mogelijke gevaren qua data corruptie. Ik wou dus dolgraag weten hoe een Docker "container" zijn data wegschrijft. Blijkt dat je met bind mounts simpelweg direct met het onderliggende bestandssysteem praat en je wat dat betreft relatief safe zit (zolang je op Linux zit, op Windows wordt het stiekem een CIFS mount die data onterecht uit een cache kan lezen, detail ).

Daarna wou ik natuurlijk meer weten over process management en kwam ik er geleidelijk achter dat "containers" helemaal geen containers zijn, maar gewoon processen die door Linux namespaces beperkt zijn in hun doen en laten.

Zo heb je een namespace die bepaalt welke processen je mag zien (pid), een namespace die bepaalt welke mounts je kunt zien (mount), enzovoorts (network, uts, ipc en user).

En langzamerhand kwam dan bij mij het "holy fuck" moment dat een hoop dingen voor Jan met de korte achternaam als root draaien.

Zo dus ook de standaard Docker container voor SQL Server 2017 van Microsoft. Die notabene alleen maar met een unprivileged TCP port (1433) praat.

Installeer je SQL Server 2017 gewoon direct op Ubuntu dan draait hij als mssql gebruiker, gebruik je Docker dan is het root die we met geweld minder rechten proberen te geven. Een standaard installatie van Docker gebruikt ook geen user remapping (anders zou je root nog kunnen mappen naar nobody, of wat je ook maar wil).

Best practice is dan ook om een proces in een Docker "container" niet als root te laten draaien.

Why Microsoft? Why?

Vervolgens blijkt dat veel Docker images die je kunt halen van Dockerhub root gebruiken

Conclusie
Aaaaaaaaaaaaaaargh

Ik ben in ieder geval geneigd SQL Server normaal te installeren (het schijnt sowieso best practice te zijn om database servers niet te containerizen voor productie, ook omdat ze anders schalen dan stateless services).

Ach ja, heb weer een hoop geleerd

Voor wie meer wil weten, mijn bronnen:
https://opensource.com/ar...st-say-no-root-containers
https://opensource.com/business/14/7/docker-security-selinux
https://opensource.com/business/14/9/security-for-docker
Wikipedia: Linux namespaces
https://www.ibm.com/devel...unt-namespaces/index.html
Wikipedia: cgroups
https://www.infoq.com/articles/build-a-container-golang

[Koenvh]

Douweegbertje schreef op maandag 4 februari 2019 @ 16:24:
[...]


Behalve dat ik liever geen post request heb van 8k karakters.. Sowieso zal dat out of de box denk ik niet werken met de default waardes van nginx/apache e.d. in de headers and such

Oplossing: Maak er een get request van
Mocht je dan je wachtwoord kwijt zijn kun je gewoon je geschiedenis of serverlogs nazoeken

Hoe lang zou KeePass er wel niet over doen om een wachtwoord van achtduizend tekens in te voeren?

[DHH]

Ik had vandaag weer het genot om te mogen werken met een dataset waar datumwaarden als strings zijn opgeslagen:

Create_date:
2019-01-15
15-01-2019
2019/01/15
15.01.2019
01.15.2019
15-01-20019
15,01,2019
15-Jan-2019

In onze rapportagesoftware heeft een oud-collega kennelijk ooit een dappere poging gedaan om er chocola van te maken met 80 (!) geneste replace-functies...

Het ergste is nog dat dit uit een SQL-database komt en er dus geen enkele reden is om het niet als datum-waarde op te slaan.

[Scott]

Is het niet makkelijker om een formaat te kiezen en geleidelijk aan alles daar naartoe om te zetten? Dus 1 query vervangt het formaat mm-dd-yyyy naar yyyy-mm-dd, dan een volgende query zet mm.dd.yyyy naar yyyy-mm-dd, etc.

[sig69]

DHH schreef op dinsdag 5 februari 2019 @ 19:18:
...

In onze rapportagesoftware heeft een oud-collega kennelijk ooit een dappere poging gedaan om er chocola van te maken met 80 (!) geneste replace-functies...

Het ergste is nog dat dit uit een SQL-database komt en er dus geen enkele reden is om het niet als datum-waarde op te slaan.

Dan kan je die 80 geneste functies mooi gebruiken om het voor eens en altijd op te ruimen, heeft hij mooi al het zware werk voor je gedaan

[NMH]

DHH schreef op dinsdag 5 februari 2019 @ 19:18:

15.01.2019

01.15.2019

Dat krijg je alvast nooit meer goed voor dagen <= 12.

[DHH]

NMH schreef op dinsdag 5 februari 2019 @ 21:07:
[...]


Dat krijg je alvast nooit meer goed voor dagen <= 12.

Creatief gebruik van mm-dd-yyyy en dd-mm-yyyy is ons niet vreemd.
Ik zie zo even geen andere optie dan een nieuw veld in de database aanmaken als 'date' en te kijken of we het merendeel van de datumwaarden nog kunnen overzetten (en de rest dan maar null of 01-01-1900 o.i.d.).

Gelukkig gaat het niet om één tabel en zijn er vele velden die als datum aangemaakt hadden moeten worden. Varchar voor alles!

[nescafe]

DHH schreef op dinsdag 5 februari 2019 @ 19:18:

15.01.2019

01.15.2019

NMH schreef op dinsdag 5 februari 2019 @ 21:07:
Dat krijg je alvast nooit meer goed voor dagen <= 12.

Ik zie nog wel een uitdaging om Create_date te relateren aan een identity-column of record-ID

datum vorige record <= Create_date <= datum volgende record

En afhankelijk van branche weekenden/feestdagen laten vervallen..

[ Voor 5% gewijzigd door nescafe op 05-02-2019 21:29 ]

[BertS]

nescafe schreef op dinsdag 5 februari 2019 @ 21:28:
[...]


[...]


Ik zie nog wel een uitdaging om Create_date te relateren aan een identity-column of record-ID

datum vorige record <= Create_date <= datum volgende record

En afhankelijk van branche weekenden/feestdagen laten vervallen..

Behalve als de identity-column een GUID is (past mooi in de varchar-voor-alles-filosofie)

[NMH]

nescafe schreef op dinsdag 5 februari 2019 @ 21:28:
Ik zie nog wel een uitdaging om Create_date te relateren aan een identity-column of record-ID

datum vorige record <= Create_date <= datum volgende record

En afhankelijk van branche weekenden/feestdagen laten vervallen..

Goed punt, ik had er even over heen gelezen dat het een creation date is. Wellicht dat uit gerelateerde records ook nog meer afgeleid kan worden. Overigens, als het inderdaad simpelweg de dag is dat het record aangemaakt is een tweede WTF dat de waarde met de hand ingeklopt wordt ipv dat gewoon in software de huidige dag gepakt wordt.

[Douweegbertje]

BertS schreef op dinsdag 5 februari 2019 @ 21:30:
[...]

Behalve als de identity-column een GUID is (past mooi in de varchar-voor-alles-filosofie)

Afhankelijk van de type GUID kan je ook op basis van de GUID de tijd uitlezen.. en het mac adres

Het voordeel van slechte pseudo random nummers

[.oisyn]

Ok... anders kom ik er na een jaar oid achter dat mijn headset een volumeknop heeft. En ik was al aan het orienteren op een koptelefoonversterker omdat ik hem zo zacht vond klinken

[DHH]

.oisyn schreef op woensdag 6 februari 2019 @ 00:58:
Ok... anders kom ik er na een jaar oid achter dat mijn headset een volumeknop heeft. En ik was al aan het orienteren op een koptelefoonversterker omdat ik hem zo zacht vond klinken

[Woy]

.oisyn schreef op woensdag 6 februari 2019 @ 00:58:
Ok... anders kom ik er na een jaar oid achter dat mijn headset een volumeknop heeft. En ik was al aan het orienteren op een koptelefoonversterker omdat ik hem zo zacht vond klinken

Je weet dat je ook op je computer het volume aan kunt passen he

[Mugwump]

.oisyn schreef op woensdag 6 februari 2019 @ 00:58:
Ok... anders kom ik er na een jaar oid achter dat mijn headset een volumeknop heeft. En ik was al aan het orienteren op een koptelefoonversterker omdat ik hem zo zacht vond klinken

Een jaar is wel heel lang.
Ik ben wel eens drie weken aan het prutsen geweest met drivers en settings voor de mic van m'n headset om er vervolgens achter te komen dat ik de mic gewoon iets verder in de headset had moeten drukken.

[ThomasG]

Mugwump schreef op woensdag 6 februari 2019 @ 09:51:
[...]


Een jaar is wel heel lang.
Ik ben wel eens drie weken aan het prutsen geweest met drivers en settings voor de mic van m'n headset om er vervolgens achter te komen dat ik de mic gewoon iets verder in de headset had moeten drukken.

Klinkt een beetje als altijd eerst kijken of de netwerkkabel er wel goed in zit, voordat je verder gaat met troubleshooten

[.oisyn]

Woy schreef op woensdag 6 februari 2019 @ 08:29:
[...]

Je weet dat je ook op je computer het volume aan kunt passen he

Dat was dus het probleem, zelfs op max vond ik 'm niet hard genoeg .

Grappige was, een paar weken geleden zat hij niet goed op mijn hoofd dus verstelde ik 'm, en toen klonk ie opeens harder. Dus ik dacht aan een kabelbreuk oid. Gisteren kwam ik eraan en toen ging hij ineens weer zachter. Bij nadere inspectie vond ik de volumeknop

In my defence, hij valt niet enorm op

[ Voor 5% gewijzigd door .oisyn op 06-02-2019 10:55 ]

[DevWouter]

.oisyn schreef op woensdag 6 februari 2019 @ 10:53:

In my defence, hij valt niet enorm op

[Afbeelding]

Nou, die hendel aan de zijkant valt mij wel op.

[Woy]

.oisyn schreef op woensdag 6 februari 2019 @ 10:53:
[...]


Dat was dus het probleem, zelfs op max vond ik 'm niet hard genoeg .

In my defence, hij valt niet enorm op

[Afbeelding]

Je dacht dat die deuk voor je vinger vooral voor de airodynamica was?

[ThomasG]

Woy schreef op woensdag 6 februari 2019 @ 11:01:
[...]

[Afbeelding]


[...]

Je dacht dat die deuk voor je vinger vooral voor de airodynamica was?

Ja, en dat andere ding is de bluetooth anthene

[.oisyn]

Woy schreef op woensdag 6 februari 2019 @ 11:01:
[...]

[Afbeelding]

Is Joke kwijt? Of waarom staat er een pijl naar het niets met Joke erboven?

[mcDavid]

de "that's what she said" ging aan je voorbij, is denk ik de essentie

edit

Mugwump schreef op woensdag 6 februari 2019 @ 09:51:
[...]


Een jaar is wel heel lang.
Ik ben wel eens drie weken aan het prutsen geweest met drivers en settings voor de mic van m'n headset om er vervolgens achter te komen dat ik de mic gewoon iets verder in de headset had moeten drukken.

Zo was ik er bijna van overtuigd dat de buttons in het kabeltje van mijn koptelefoon het niet deden (iig niet i.c.m. mijn telefoon) toen ik op een gegeven moment een halve kilo stof uit de jack-connector peuterde en sindsdien werken die knopjes vlekkeloos.

De USB-C connector van diezelfde telefoon heb ik overigens vervangen omdat het kabeltje er niet meer in bleef zitten. Je raad het al, bleek ook stof te zijn.

[ Voor 91% gewijzigd door mcDavid op 06-02-2019 12:02 ]

[.oisyn]

mcDavid schreef op woensdag 6 februari 2019 @ 11:56:
de "that's what she said" ging aan je voorbij, is denk ik de essentie

Wat zei ze dan? En wie is "ze"? Joke?

[ Voor 89% gewijzigd door .oisyn op 06-02-2019 12:27 ]

[Ryur]

.oisyn schreef op woensdag 6 februari 2019 @ 12:26:
[...]

Wat zei ze dan? En wie is "ze"? Joke?

Dank je! Daar ging mijn koffie door mijn neus!

[Laurens-R]

huis tuin en keuken router vervangen met een pfsense router. Kijkt deze ochtend in firewall log: Binnen 4 uur tijd 300+ pogingen om remote desktop (3389) of SQL server verbindingen (1433) te maken... Laat staan alle pogingen die binnen komen op port 80 of 443. Ik zie ook heel veel random porten voorbij komen (port scans?)

Zo word je als gemiddelde consument nog maar eens op de feiten gewezen dat het gebruik van een goede firewall essentieel is. Iedere IT'er weet natuurlijk dat je jezelf nooit veilig moet wanen, maar door zoiets simpels als een firewall log word het nogmaals extra duidelijk. Dan kijk ik toch extra zorgelijk naar de soms erg matige routers die door ISPs worden geleverd.

[ Voor 4% gewijzigd door Laurens-R op 06-02-2019 12:43 ]

[RobertMe]

Laurens-R schreef op woensdag 6 februari 2019 @ 12:39:
huis tuin en keuken router vervangen met een pfsense router. Kijkt deze ochtend in firewall log: Binnen 4 uur tijd 300+ pogingen om remote desktop (3389) of SQL server verbindingen (1433) te maken... Laat staan alle pogingen die binnen komen op port 80 of 443. Ik zie ook heel veel random porten voorbij komen (port scans?)

Zo word je als gemiddelde consument nog maar eens op de feiten gewezen dat het gebruik van een goede firewall essentieel is. Iedere IT'er weet natuurlijk dat je jezelf nooit veilig moet wanen, maar door zoiets simpels als een firewall log word het nogmaals extra duidelijk. Dan kijk ik toch extra zorgelijk naar de soms erg matige routers die door ISPs worden geleverd.

Ik denk niet dat routers die door ISPs worden geleverd iets op poort 3389, 1433 etc hebben draaien Zolang er nog gebruik wordt gemaakt van NAT hoef je niet perse een goede/extra firewall te hebben. Immers zolang die poort niet open staat in de router en het geen service is die op de router draait ben je al "veilig". Want als je bv een Windows PC met poort 3389 open achter je router hebt draaien zal die router niet alle binnenkomende verkeer van poort 3389 doorsturen naar die PC.

Overigens maakt dat NAT uiteraard geen firewall. Maar zolang NAT wordt toegepast ben je wel "veilig" (tenzij je zelf poorten gaat forwarden).

[Woy]

.oisyn schreef op woensdag 6 februari 2019 @ 11:41:
[...]

Is Joke kwijt? Of waarom staat er een pijl naar het niets met Joke erboven?

Joke is de autoriteit op het gebied van volume op koptelefoons, je heb haar blijkbaar net gemist.

[.oisyn]

Woy schreef op woensdag 6 februari 2019 @ 12:50:
[...]

Joke is de autoriteit op het gebied van volume op koptelefoons, je heb haar blijkbaar net gemist.

Ah shoot. Waarschijnlijk omdat mijn koptelefoon te hard stond (nu wel)

[ThomasG]

RobertMe schreef op woensdag 6 februari 2019 @ 12:48:
[...]

Ik denk niet dat routers die door ISPs worden geleverd iets op poort 3389, 1433 etc hebben draaien Zolang er nog gebruik wordt gemaakt van NAT hoef je niet perse een goede/extra firewall te hebben. Immers zolang die poort niet open staat in de router en het geen service is die op de router draait ben je al "veilig". Want als je bv een Windows PC met poort 3389 open achter je router hebt draaien zal die router niet alle binnenkomende verkeer van poort 3389 doorsturen naar die PC.

Overigens maakt dat NAT uiteraard geen firewall. Maar zolang NAT wordt toegepast ben je wel "veilig" (tenzij je zelf poorten gaat forwarden).

Tegenwoordig heeft vrijwel iedere consumenten "router" UPnP standaard ingeschakeld, en er is heel veel software wat gebruik maakt van UPnP. Als je een IP range van provider X af zou gaan en zoeken naar remote desktop poorten e.d. heb je wel een paar keer beet.

[.oisyn]

ThomasG schreef op woensdag 6 februari 2019 @ 12:52:
[...]
Tegenwoordig heeft vrijwel iedere consumenten "router" UPnP standaard ingeschakeld, en er is heel veel software wat gebruik maakt van UPnP. Als je een IP range van provider X af zou gaan en zoeken naar remote desktop poorten e.d. heb je wel een paar keer beet.

Dat software van UPnP gebruik maakt wil natuurlijk niet zeggen dat RDP dat ook standaard doet

[Laurens-R]

De genoemde poorten waren uiteraard voorbeelden. Of het remote desktop is of wat anders doet er volgens mij niet echt toe. Het was voor mij meer een eye opener dat het zo veel pogingen waren in zo'n korte tijd op een "simpele" verbinding van een consument. Ik zag ook genoeg andere poorten voorbij komen. Nu ben ik de eerste die toegeeft dat ik verre van een infra expert ben, maar ik heb genoeg ervaring met hackers om te weten dat ze vaak een weg vinden... Ook als het "volgens het boekje" niet zou moeten kunnen. En ja dan kijk ik toch bedenkelijk naar standaard geleverde routers die bijvoorbeeld van een exotisch Chinees merk zijn.

[ Voor 5% gewijzigd door Laurens-R op 06-02-2019 13:11 ]

[ThomasG]

Ik vind dat altijd wel leuk als ik de access log van onze webservices bekijk. Iedere dag duizenden wordpress hackpoingen, terwijl we helemaal geen wordpress draaien Ik heb wel eens het idee gehad om deze requests naar een nep wordpress pagina te laten wijzen, maar ik ben bang dat het dan enkel erger wordt.

[Douweegbertje]

Het zijn gewoon botnets die basic meuk uitvoeren en bij een hit automatisch een payload meegeven voor bijv. een shell of whatever. Ik heb dit paar keer gecheckt door honeypots op te zetten en dan zie je soms best awesome shells voorbij komen.

Dit soort dingen; wat gewoon een volwaardige shell+file management en semi 'C&C' script is, decrypted.


Met relatief weinig moeite kan je het gehele internet doorscannen. Puur op port 80 zou je dat binnen een paar uur reden.

https://www.shodan.io/ is eigenlijk een search engine waarbij je zelf niet hoeft te scannen. Zie het als de google voor open services Als je de porten weet en de eventuele meta-data die er bij hoort kan je met 1 simpele query toegang krijgen tot dingen waar je eigenlijk geen toegang tot behoord te krijgen. Puur omdat het niet dicht stond en nu gemakkelijk te vinden was.

Ik kan er niet te veel over zeggen wat ik bijvoorbeeld allemaal heb gevonden maar het was iets van een core management systeem van een ISP om router firmware te pushen naar klanten

Het is ook easy om routers en domotica systemen te vinden. Ik heb wel een keer de lampen uit/aan gezet en de verwarming op 24 graden waarna ik de wifi name had aangepast met "zet er een pass op".

[ Voor 6% gewijzigd door Douweegbertje op 06-02-2019 16:38 ]

[NMH]

Douweegbertje schreef op woensdag 6 februari 2019 @ 16:30:
Met relatief weinig moeite kan je het gehele internet doorscannen. Puur op port 80 zou je dat binnen een paar uur reden.

Kennelijk kan het tegenwoordig al in een paar minuten met het goede gereedschap: https://github.com/robert...scan-mass-ip-port-scanner.

[Douweegbertje]

NMH schreef op woensdag 6 februari 2019 @ 22:26:
[...]

Kennelijk kan het tegenwoordig al in een paar minuten met het goede gereedschap: https://github.com/robert...scan-mass-ip-port-scanner.

Jup, met de juiste tools
Dit is dezelfde dude: YouTube: Massscanning the Internet - Defcon 22 (2014) . Sowieso een erg leuke talk! Ondanks dat het uit 2014 komt.

[gekkie]

Laurens-R schreef op woensdag 6 februari 2019 @ 12:39:
huis tuin en keuken router vervangen met een pfsense router. Kijkt deze ochtend in firewall log: Binnen 4 uur tijd 300+ pogingen om remote desktop (3389) of SQL server verbindingen (1433) te maken... Laat staan alle pogingen die binnen komen op port 80 of 443. Ik zie ook heel veel random porten voorbij komen (port scans?)

Zo word je als gemiddelde consument nog maar eens op de feiten gewezen dat het gebruik van een goede firewall essentieel is. Iedere IT'er weet natuurlijk dat je jezelf nooit veilig moet wanen, maar door zoiets simpels als een firewall log word het nogmaals extra duidelijk. Dan kijk ik toch extra zorgelijk naar de soms erg matige routers die door ISPs worden geleverd.

Meh, ik kreeg een paar jaar geleden ook ineens een hoop vaag verkeer binnen op de firewall. Bleek allemaal niet voor mijn IP bestemd, eens wireshark er aan gehangen en het verkeer eens bekeken.
Moraal van het verhaal is dat men hier in de buurt in iedergeval geen smaak heeft wat purno betreft (en dat de ISP z'n routering niet op orde had). Duurde nog weken na de melding voordat het gefixt was .

[F.West98]

Pff... * F.West98 klimt vertwijfeld een rabbithole uit.

Ik werk aan een webapplicatie (NodeJS) die bij mij al een tijdje bij sommige pagina's extreem traag is (>1min laadtijd). Dus ik wil nou wel eens uitzoeken hoe dat komt. Tijdens die load is er verder geen CPU-gebruik of wat dan ook. Dus even checken: op productie is het prima. Op Vagrant in Virtualbox werkt het prima. Maar op Vagrant in Hyper-V gaat het dus op z'n bek... Nou weet ik dat in Vagrant op Hyper-V alle shared folders via CIFS gemount worden, en dat Node + CIFS niet altijd heel fijn samen gaan. Dus de code even kopiëren naar een lokale map binnen de VM, alles werkt prima.

Dan maar eens uitzoeken wat er precies bijzonder is aan deze paar pagina's die kapot gaan, ik kan niet zozeer iets vinden. Dus dan de CIFS maar monitoren op read/writes. Blijkt dus dat de 'kapotte' pagina's een aantal config files openen en er dan 30 seconden niets mee doen. Dus nu nog uitzoeken waar in de code die bestanden gebruikt worden. Na wat zoeken heb ik de exacte regels code gevonden waartussen een lange delay zit. Geen idee waarom het fout gaat, want het is code die ook voor alle andere config files gebruikt wordt en dan gaat het wel goed...

EN TOEN HIELD HET PLOTSELING OP! Ineens was de bug volledig verdwenen, alles was volledig snel, zowel met als zonder debugging aan. Ik heb dus niets aangepast aan de code. Geen settings veranderd in Vagrant of in Windows. Ik snap er helemaal niets van. Lang leve Heisenbugs

Nou slaap lekker dan maar hè!

[GateKeaper]

NodeJS ontwikkelen op Windows is sowieso behoorlijk waardeloos. Ik werk aan een iets grotere applicatie. Waar builden op Linux of Mac binnen 5 seconden gefixt is, doet Windows er ongeveer een minuut over. Dat is, de eerste keer na een verse reboot.

Na een aantal keer builden (wat je toch al snel doet met Node), loopt dat op tot 3 minuten, en over de dag stijgt dat na meer dan 5 minuten.

[F.West98]

GateKeaper schreef op donderdag 7 februari 2019 @ 12:18:
NodeJS ontwikkelen op Windows is sowieso behoorlijk waardeloos. [..]

FTFY Geef mij maar .NET (Core) met C#
Het is dat het goed verdient en niet al te ingewikkeld werk is, anders was ik al weggeweest. Maar dit soort bijverdiensten zijn het als student toch wel waard.

[GateKeaper]

Mwah, daar ga ik niet direct in mee. Ik heb jaren met C# gewerkt. En ja, dat werkt geweldig. En ja, soms mis ik type safety wel binnen Node (al heb je daar typescript voor als je zou willen).

Ik vind het zelf heerlijk dat je niet hoeft na te denken over threads, dat je server en client code gewoon probleemloos kan delen. En dat je met React, ondanks dat het nog steeds html is, eigenlijk nog maar in 1 taal schrijft.

Andere talen zullen het ongetwijfeld hebben, maar het 'hot-reloading' waardoor je wijzigingen vrijwel direct zichtbaar zijn, of het nu client of server side is, werkt al net zo lekker. Om het nog maar niet te hebben over de eindeloze hoeveelheid packages die je met een `npm install` kan installeren.

Het heeft zijn gebreken, ongetwijfeld. De grootste is wellicht het gebrek aan een type system. Maar het levert ook enorm veel voordelen op.

Overigens vermoed ik dat je met .NET meer kan verdienen. Juist omdat node (javascript) een lager instapniveau heeft.

[Tjolk]

GateKeaper schreef op donderdag 7 februari 2019 @ 12:18:
NodeJS ontwikkelen op Windows is sowieso behoorlijk waardeloos.

FTFY

Disclaimer: ik heb ruime ervaring met ontwikkelen op Windows, OS X en Linux, en dat laatste heeft -ondanks het minste ervaring gerekend in jaren- toch echt mijn voorkeur.

[ThomasG]

Tjolk schreef op donderdag 7 februari 2019 @ 14:03:
[...]

FTFY

Disclaimer: ik heb ruime ervaring met ontwikkelen op Windows, OS X en Linux, en dat laatste heeft -ondanks het minste ervaring gerekend in jaren- toch echt mijn voorkeur.

Het meest irritante van ontwikkelen op Windows blijft gewoon dat je niet op een fatsoenlijke low-maintenance manier de tools die je nodig hebt op je PATH kunt zetten. Windows is leuk bij GUI-only werk, zodra je de shell induikt is het redelijk om te huilen.

[bauke1994]

Tjolk schreef op donderdag 7 februari 2019 @ 14:03:
[...]

FTFY

Disclaimer: ik heb ruime ervaring met ontwikkelen op Windows, OS X en Linux, en dat laatste heeft -ondanks het minste ervaring gerekend in jaren- toch echt mijn voorkeur.

Dat laatste kan ik met je over meepraten, Mac OS heb ik geen ervaring mee. Ik ben zelf ruim een jaar geleden overgestapt naar Ubuntu en dat is echt een verademing.

GateKeaper schreef op donderdag 7 februari 2019 @ 13:29:
...

En dat je met React, ondanks dat het nog steeds html is, eigenlijk nog maar in 1 taal schrijft.

...

Om het nog maar niet te hebben over de eindeloze hoeveelheid packages die je met een `npm install` kan installeren.

...

Die 2 dingen zijn voor mij alleen al reden om heel ver bij nodeJS vandaan te blijven.

[GateKeaper]

bauke1994 schreef op donderdag 7 februari 2019 @ 14:10:
Die 2 dingen zijn voor mij alleen al reden om heel ver bij nodeJS vandaan te blijven.

Dat zijn dan waardeloze argumenten. Want die twee dingen zijn volledig optioneel.

[Tjolk]

bauke1994 schreef op donderdag 7 februari 2019 @ 14:10:
[...]
, Mac OS heb ik geen ervaring mee.

Ik heel even.
Volgens mij een klein jaartje nadat het macOS ging heten heb ik dat ding aan de wilgen gehangen in de kast gezet. Opvallend genoeg in een bedrijf van 200-ish man staat-ie daar een jaar later nog steeds...

[gekkie]

GateKeaper schreef op donderdag 7 februari 2019 @ 14:11:
[...]
Dat zijn dan waardeloze argumenten. Want die twee dingen zijn volledig optioneel.

Meh .. toch nog een FTFY dan maar:

GateKeaper schreef op donderdag 7 februari 2019 @ 13:29:
Om het nog maar niet te hebben over de eindeloze hoeveelheid packages die je met een `npm install` kan installeren geinstalleerd krijgt, bij een ogenschijnlijk simpele en containbare dependency.

(niet dat er helemaal aan te ontkomen valt, maar bij de meeste talen is het nog wel binnen de perken gebleven)

Jolly .. git bisect'en ... nu maar even duimen dat dat gaat werken en er niet allemaal andere meuk tussen in ook kapot blijkt te gaan.

[ Voor 17% gewijzigd door gekkie op 07-02-2019 15:07 ]

[GateKeaper]

Tjah, maar als het "simpel en containbaar" is, waarom installeer je er dan uberhaupt een package voor?

[gekkie]

GateKeaper schreef op donderdag 7 februari 2019 @ 16:03:
Tjah, maar als het "simpel en containbaar" is, waarom installeer je er dan uberhaupt een package voor?

Maar misschien is het probleem meer het gebrek aan een redelijk uitgebreide en goed in elkaar stekende standard lib. Zodat je niet 1001 packages hebt die iets über simpels doen, waarvan dan 20 implementaties zijn .. waarbij iedereen depend op een andere implementatie dan wel lockt (of het nodig is of niet) op een andere versie van die dependency.

Alles is een trade-off, maar er zijn toch wel wat optima her en der te benaderen. NPM kan ik er niet echt bij in de buurt vinden zitten.

[ Voor 10% gewijzigd door gekkie op 07-02-2019 16:22 ]

[NMH]

gekkie schreef op woensdag 6 februari 2019 @ 22:58:
[...]

Meh, ik kreeg een paar jaar geleden ook ineens een hoop vaag verkeer binnen op de firewall. Bleek allemaal niet voor mijn IP bestemd, eens wireshark er aan gehangen en het verkeer eens bekeken.
Moraal van het verhaal is dat men hier in de buurt in iedergeval geen smaak heeft wat purno betreft (en dat de ISP z'n routering niet op orde had). Duurde nog weken na de melding voordat het gefixt was .

Heh, dat doet mij denken aan een issue bij AWS jaren geleden; als je daar je servers achter een ELB (loadbalancer van AWS) had, dan kon je soms verkeer van andere AWS gebruikers zoals Netflix op je backends krijgen. Leuk als je een lief klein servertje draait en er dan een horde bingewatchers overheen dendert.

[F.West98]

GateKeaper schreef op donderdag 7 februari 2019 @ 13:29:
Mwah, daar ga ik niet direct in mee. Ik heb jaren met C# gewerkt. En ja, dat werkt geweldig. En ja, soms mis ik type safety wel binnen Node (al heb je daar typescript voor als je zou willen).

Ik vind het zelf heerlijk dat je niet hoeft na te denken over threads, dat je server en client code gewoon probleemloos kan delen. En dat je met React, ondanks dat het nog steeds html is, eigenlijk nog maar in 1 taal schrijft.

Andere talen zullen het ongetwijfeld hebben, maar het 'hot-reloading' waardoor je wijzigingen vrijwel direct zichtbaar zijn, of het nu client of server side is, werkt al net zo lekker. Om het nog maar niet te hebben over de eindeloze hoeveelheid packages die je met een `npm install` kan installeren.

Het heeft zijn gebreken, ongetwijfeld. De grootste is wellicht het gebrek aan een type system. Maar het levert ook enorm veel voordelen op.

Overigens vermoed ik dat je met .NET meer kan verdienen. Juist omdat node (javascript) een lager instapniveau heeft.

Ik ben het met je eens hoor. Node zal best wel heel lekker kunnen werken, vandaar ook de populariteit.

Maar het probleem zit 'm in dit geval denk ik ook enigszins in de codebase. De opzet is niet per se geweldig (maar niet slecht), en dan met af en toe wat onduidelijke naming, een snufje feature creep, een flinke dosis Node v6 en daarmee callback hell (10 levels diep ) en toch alles in de async gooien maakt het enigszins lastig beheersbaar. Dusdanig dat ook PHPStorm de IntelliSense in een groot deel van de code opgeeft. En dan nog een inconsistente development omgeving (de anderen werken gewoon op de productie server in vim aan een instance op een andere poort dan 80....) waardoor dingen ook steeds kapot gaan.

Ik ben nu bezig met upgraden naar v10 in de hoop e.e.a. op te kunnen schonen. De performance improvement is iig al fijn.

[GateKeaper]

daarmee callback hell (10 levels diep )

True, dat was een behoorlijk gebrek in de voorgaande jaren. Maar vandaag de dag is echt niet meer nodig.

Dit is juist iets at MS voor ons gefixt heeft. Promisses hadden ook zo hun nadelen nog, maar async / await, rechtstreeks vanuit C# geport naar Typescript, overgenomen in Ecmascript/Node. Wat een verademing!

Dusdanig dat ook PHPStorm de IntelliSense in een groot deel van de code opgeeft.

Geen ervaring mee. Maar kan dat zijn omdat WebStorm bedoeld is voor Node ontwikkeling? Dezelfde leverancier, ander product? Ik heb echt 0 problemen met error reporting in WebStorm. Eslint / prettier plugin, alles met rode kriebeltjes is gefixt zodra ik opsla.

En dan nog een inconsistente development omgeving (de anderen werken gewoon op de productie server in vim aan een instance op een andere poort dan 80....) waardoor dingen ook steeds kapot gaan.

I feel your pain. Maar die mensen moeten onslagen worden. Dat kan je Node niet kwalijk nemen. Anders is *kuch* PHP net zo slecht, en ook .NET kan je met "de juiste tools" nog "hotfixen" op productie.

[Crazy D]

GateKeaper schreef op vrijdag 8 februari 2019 @ 09:49:
I feel your pain. Maar die mensen moeten onslagen worden. Dat kan je Node niet kwalijk nemen. Anders is *kuch* PHP net zo slecht, en ook .NET kan je met "de juiste tools" nog "hotfixen" op productie.

Maar als je dat gewoon continues delivery noemt...

[Douweegbertje]

GateKeaper schreef op vrijdag 8 februari 2019 @ 09:49:
[...]


True, dat was een behoorlijk gebrek in de voorgaande jaren. Maar vandaag de dag is echt niet meer nodig.

Dit is juist iets at MS voor ons gefixt heeft. Promisses hadden ook zo hun nadelen nog, maar async / await, rechtstreeks vanuit C# geport naar Typescript, overgenomen in Ecmascript/Node. Wat een verademing!


[...]


Geen ervaring mee. Maar kan dat zijn omdat WebStorm bedoeld is voor Node ontwikkeling? Dezelfde leverancier, ander product? Ik heb echt 0 problemen met error reporting in WebStorm. Eslint / prettier plugin, alles met rode kriebeltjes is gefixt zodra ik opsla.


[...]


I feel your pain. Maar die mensen moeten onslagen worden. Dat kan je Node niet kwalijk nemen. Anders is *kuch* PHP net zo slecht, en ook .NET kan je met "de juiste tools" nog "hotfixen" op productie.

Je hebt het wel over de packages dat zoiets optioneel is en derhalve geen argument is. Ik vind die packages anders wel een core onderdeel ervan, iets wat je niet kan verwaarlozen.

Uiteraard bepaald de implementatie van een dev het eind resultaat en ik snap je hint richting PHP. Wat echter het verschil is dat PHP sinds de 7.x branche echt enorm gegroeid is. Het kan in feite net zo strict zijn als een C# / C++ en op elk gebied wordt het alleen maar volwassener; tooling, docs, exts, etc. Zoiets is ook gewoon mogelijk omdat naar mijn inziens de basis wel 'okay' is. Dat gevoel heb ik een stuk minder met node.

[.oisyn]

Douweegbertje schreef op vrijdag 8 februari 2019 @ 10:33:
Het kan in feite net zo strict zijn als een C# / C++

Oh echt? Hoe declareer je dat een variabele alleen maar een boolean mag zijn, bijvoorbeeld?

quote: http://php.net/manual/en/language.types.type-juggling.php

PHP does not require (or support) explicit type definition in variable declaration

---

Haha, deze error:

PHP:

<?php

function foo(boolean $b)
{
}

foo(true);

Uncaught TypeError: Argument 1 passed to foo() must be an instance of boolean, boolean given

(Het had bool moeten zijn, wat natuurlijk raar is omdat 1. hij wel zegt dat ik een 'boolean' opgeef, en 2. 'boolean' wel gebruikt kan worden bij een cast)

[ Voor 35% gewijzigd door .oisyn op 08-02-2019 11:00 ]

[Douweegbertje]

.oisyn schreef op vrijdag 8 februari 2019 @ 10:53:
[...]


Oh echt? Hoe declareer je dat een variabele alleen maar een boolean mag zijn, bijvoorbeeld?


[...]

---

Haha, deze error:

PHP:

<?php

function foo(boolean $b)
{
}

foo(true);

Uncaught TypeError: Argument 1 passed to foo() must be an instance of boolean, boolean given

(Het had bool moeten zijn, wat natuurlijk raar is omdat 1. hij wel zegt dat ik een 'boolean' opgeef, en 2. 'boolean' wel gebruikt kan worden bij een cast)

Met strict_types=1

Ok fair, wellicht moet ik niet zeggen dat het 100% identiek is aan C# maar als je ziet waar het was met < 5.6 dan komt het nu dichtbij

Expliciet vermelden wat een var moet zijn werkt net iets anders; als in dat je dit in de arguments / return types kan mee geven. Maar nee, het staat je nog steeds vrij om binnen die scope een int var naar een string te maken. Echter als je het goed opzet kan je het daar ook deels op z'n bek laten gaan doordat je de strict melding van bijvoorbeeld: "A non-numeric value encountered" krijgt als je int + string doet.

[Mugwump]

Douweegbertje schreef op vrijdag 8 februari 2019 @ 11:21:
[...]


Met strict_types=1

Ok fair, wellicht moet ik niet zeggen dat het 100% identiek is aan C# maar als je ziet waar het was met < 5.6 dan komt het nu dichtbij

Expliciet vermelden wat een var moet zijn werkt net iets anders; als in dat je dit in de arguments / return types kan mee geven. Maar nee, het staat je nog steeds vrij om binnen die scope een int var naar een string te maken. Echter als je het goed opzet kan je het daar ook deels op z'n bek laten gaan doordat je de strict melding van bijvoorbeeld: "A non-numeric value encountered" krijgt als je int + string doet.

Mja, ik vind toch dat hele 'in theorie zou je het min of meer kunnen afdwingen op een heel omslachtige wijze' nooit zo overtuigend. Het geeft eigenlijk al aan dat de ondersteuning gebrekkig is en de (mis/ge)bruiker zelf kan bepalen hoe hij ermee omgaat. Mijn bezwaar tegen PHP (of eigenlijk dynamische scripttalen in het algemeen) is ook niet zozeer dat je er geen goede code in zou kunnen schrijven, maar dat het weinig gebeurt. Moest een Pythoncollega van me laatst ook nog weer uitleggen dat wanneer je een class definieert het niet de bedoeling is dat je dan binnen je class doodleuk variabelen gaat gebruiken die toevallig iets hoger in je script buiten de hele class definition worden gedeclareerd. Een gecompileerde taal zonder scriptmogelijkheden voorkomt in ieder geval dat je dat soort zaken kunt doen. Geen garantie dat er fatsoenlijke code wordt opgeleverd natuurlijk, maar het voorkomt de ergste rotzooi.

[Tjolk]

Fatsoenlijke code krijg je alleen van fatsoenlijke programmeurs. Als die hun tools kennen en juist toepassen, dan krijg je fatsoenlijke code, of dat nou PHP, C# of COBOL is.

Net zo goed als PHP ingangen biedt om slechte code te schrijven, kan een knurft C# om zeep helpen terwijl het toch compiled. Uiteindelijk blijft het gewoon een vak, net zoals ieder ander.

[F.West98]

GateKeaper schreef op vrijdag 8 februari 2019 @ 09:49:
[...]


True, dat was een behoorlijk gebrek in de voorgaande jaren. Maar vandaag de dag is echt niet meer nodig.

Dit is juist iets at MS voor ons gefixt heeft. Promisses hadden ook zo hun nadelen nog, maar async / await, rechtstreeks vanuit C# geport naar Typescript, overgenomen in Ecmascript/Node. Wat een verademing!

Nee daar ben ik dus nu ook hard mee bezig.

[...]


Geen ervaring mee. Maar kan dat zijn omdat WebStorm bedoeld is voor Node ontwikkeling? Dezelfde leverancier, ander product? Ik heb echt 0 problemen met error reporting in WebStorm. Eslint / prettier plugin, alles met rode kriebeltjes is gefixt zodra ik opsla.

Voor zover ik weet bevat IntelliJ alles van PHPStorm en meer, en bevat PhpStorm alles van WebStorm en meer. Bij mij lijkt de type detection op variabelen het nooit goed te doen, altijd overal gele kringeltjes omdat hij denkt dat variabele "name" ineens de type "Exception" heeft. En foo.[tab] geeft als IntelliSense ook de property 'foobar' omdat die gedefinieerd is een class ergens compleet anders die niet eens geimport is in het huidige bestand.

Maar misschien gaat het wel goed als je behoorlijke code schrijft

[...]


I feel your pain. Maar die mensen moeten onslagen worden. Dat kan je Node niet kwalijk nemen. Anders is *kuch* PHP net zo slecht, en ook .NET kan je met "de juiste tools" nog "hotfixen" op productie.

Neem ik Node ook niet kwalijk, maar het maakt het werk aan dit project gewoon niet fijn. Zo zijn er sinds kort unit tests, maar die zijn niet consistent.
- Op productie werkt het prima
- Op een andere instance op productie-server werken een paar tests niet, soms.
- Op Vagrant op Hyper-V werken er 20 niet wegens nog steeds die vreemde 30 sec wachten (en dan hit ie een timeout)
- Op Vagrant op Hyper-V als ik alle bestanden lokaal in de VM zet werken er 4 niet, onduidelijk waarom
- Op Vagrant op VirtualBox op Windows werken er 59 niet, allemaal off-by-one errors, onduidelijk waarom
- Op Vagrant op VirtualBox op macOS werken er ook een flink aantal niet, totaal andere fails dan op alle andere manieren

Tjolk schreef op vrijdag 8 februari 2019 @ 14:08:
Fatsoenlijke code krijg je alleen van fatsoenlijke programmeurs. Als die hun tools kennen en juist toepassen, dan krijg je fatsoenlijke code, of dat nou PHP, C# of COBOL is.

Net zo goed als PHP ingangen biedt om slechte code te schrijven, kan een knurft C# om zeep helpen terwijl het toch compiled. Uiteindelijk blijft het gewoon een vak, net zoals ieder ander.

Dat is natuurlijk ook zeker waar. Uiteindelijk lukt het ook wel in PHP/JS maar ik mis toch gewoon wat language features. Strict typing is er zeker één van, maar bijvoorbeeld method overloading mis ik ook wel vaak.

[Mugwump]

F.West98 schreef op vrijdag 8 februari 2019 @ 14:29:


Voor zover ik weet bevat IntelliJ alles van PHPStorm en meer, en bevat PhpStorm alles van WebStorm en meer. Bij mij lijkt de type detection op variabelen het nooit goed te doen, altijd overal gele kringeltjes omdat hij denkt dat variabele "name" ineens de type "Exception" heeft. En foo.[tab] geeft als IntelliSense ook de property 'foobar' omdat die gedefinieerd is een class ergens compleet anders die niet eens geimport is in het huidige bestand.

Volgens mij heeft IntelliJ niet veel van doen met PHPStorm. Je hebt wel alle Webstorm functionaliteit en wat van DataGrip, maar met PHP heb je niets van doen.
PyCharm heeft b.v. ook weer functionaliteit van Webstorm omdat je nou eenmaal vaak server side Java / PHP / Python combineert met client side code / frameworks.

[Ryur]

Mugwump schreef op vrijdag 8 februari 2019 @ 14:51:
[...]


Volgens mij heeft IntelliJ niet veel van doen met PHPStorm. Je hebt wel alle Webstorm functionaliteit en wat van DataGrip, maar met PHP heb je niets van doen.
PyCharm heeft b.v. ook weer functionaliteit van Webstorm omdat je nou eenmaal vaak server side Java / PHP / Python combineert met client side code / frameworks.

Klopt. Ik gebruik zelf RubyMine (sluit ik nu net af, want weekend!).
En ondanks je bij IntelliJ zelf de Ruby plugin kan installeren, merk ik dat er nog genoeg features missen t.o.v. RubyMine.

Daarom heb ik ook die "Toolbox" van Jetbrains, met alle producten.
Behalve mij heel goed eigenlijk! Ook dat ik bij de enige IDE niet wordt gestoord met plugins die ik bij de ander niet nodig heb (zoals vroeger Rubocop, die had ik natuurlijk alleen nodig bij RM & niet bij PHPStorm)

[Mugwump]

Ryur schreef op vrijdag 8 februari 2019 @ 15:19:
[...]

Klopt. Ik gebruik zelf RubyMine (sluit ik nu net af, want weekend!).
En ondanks je bij IntelliJ zelf de Ruby plugin kan installeren, merk ik dat er nog genoeg features missen t.o.v. RubyMine.

Daarom heb ik ook die "Toolbox" van Jetbrains, met alle producten.
Behalve mij heel goed eigenlijk! Ook dat ik bij de enige IDE niet wordt gestoord met plugins die ik bij de ander niet nodig heb (zoals vroeger Rubocop, die had ik natuurlijk alleen nodig bij RM & niet bij PHPStorm)

Ja ik heb ook de volledige bak aangezien ik o.a. IntelliJ, Resharper, PyCharm en WebStorm regelmatig gebruik. Voordeel is dat je ook altijd dezelfde keyboard shortcuts binnen alle IDEs (en ook bij een plugin als Resharper)

[Douweegbertje]

Mugwump schreef op vrijdag 8 februari 2019 @ 11:33:
[...]


Mja, ik vind toch dat hele 'in theorie zou je het min of meer kunnen afdwingen op een heel omslachtige wijze' nooit zo overtuigend. Het geeft eigenlijk al aan dat de ondersteuning gebrekkig is en de (mis/ge)bruiker zelf kan bepalen hoe hij ermee omgaat. Mijn bezwaar tegen PHP (of eigenlijk dynamische scripttalen in het algemeen) is ook niet zozeer dat je er geen goede code in zou kunnen schrijven, maar dat het weinig gebeurt. Moest een Pythoncollega van me laatst ook nog weer uitleggen dat wanneer je een class definieert het niet de bedoeling is dat je dan binnen je class doodleuk variabelen gaat gebruiken die toevallig iets hoger in je script buiten de hele class definition worden gedeclareerd. Een gecompileerde taal zonder scriptmogelijkheden voorkomt in ieder geval dat je dat soort zaken kunt doen. Geen garantie dat er fatsoenlijke code wordt opgeleverd natuurlijk, maar het voorkomt de ergste rotzooi.

Dat klopt wel wat je zegt. Je hebt overigens wel te maken met meerdere factoren (even los van eigen kwaliteit code).

De reden dat het een optie is; is dat men wel kan upgraden naar de laatste versie zonder dat de gehele code-base op zijn gat gaat. Ik weet vrij zeker dat als we een paar iteraties verder zijn dat het alleen maar stricter wordt en het ook een default value gaat worden in plaats van visa-versa.

Wat je nu steeds vaker ziet is dat mensen bewuster zijn over de versies en steeds betere / stabielere code gaan schrijven. Op het moment dat het een geforceerde functie was geweest had je nu nog steeds mensen op php5.6. Iets wat IMO pijnlijker is dan wel/niet strict.

Bij elke nieuwe versie van PHP zien we steeds meer verbeteringen op dit gebied. Zeker als we het gaan vergelijken met de pre 7 releases is het echt een wereld van verschil.

Als je dan de wat grotere PHP projecten gaat bekijken worden er echt goede standaarden gehanteerd om een zekere vorm van kwaliteit te garanderen. Mooie testen, codechecks, etc, etc. Dat was er 2-3 jaar geleden absoluut nog niet op dat niveau.

[Mugwump]

Douweegbertje schreef op vrijdag 8 februari 2019 @ 16:29:
[...]


Dat klopt wel wat je zegt. Je hebt overigens wel te maken met meerdere factoren (even los van eigen kwaliteit code).

De reden dat het een optie is; is dat men wel kan upgraden naar de laatste versie zonder dat de gehele code-base op zijn gat gaat. Ik weet vrij zeker dat als we een paar iteraties verder zijn dat het alleen maar stricter wordt en het ook een default value gaat worden in plaats van visa-versa.

Wat je nu steeds vaker ziet is dat mensen bewuster zijn over de versies en steeds betere / stabielere code gaan schrijven. Op het moment dat het een geforceerde functie was geweest had je nu nog steeds mensen op php5.6. Iets wat IMO pijnlijker is dan wel/niet strict.

Bij elke nieuwe versie van PHP zien we steeds meer verbeteringen op dit gebied. Zeker als we het gaan vergelijken met de pre 7 releases is het echt een wereld van verschil.

Als je dan de wat grotere PHP projecten gaat bekijken worden er echt goede standaarden gehanteerd om een zekere vorm van kwaliteit te garanderen. Mooie testen, codechecks, etc, etc. Dat was er 2-3 jaar geleden absoluut nog niet op dat niveau.

Oh dat geloof ik best hoor. Ik zie alleen de unieke toegevoegde waarde van PHP dan niet zo.
In mijn ogen ligt de kracht van PHP toch vooral in het feit dat oneerbiedig gezegd iedere debiel iets in elkaar kan knutselen dat min of meer werkt. Dat ben je een beetje kwijt als je heel veel structuur en kwaliteitseisen gaat introduceren.

[Ryur]

Mugwump schreef op vrijdag 8 februari 2019 @ 15:35:
[...]


Ja ik heb ook de volledige bak aangezien ik o.a. IntelliJ, Resharper, PyCharm en WebStorm regelmatig gebruik. Voordeel is dat je ook altijd dezelfde keyboard shortcuts binnen alle IDEs (en ook bij een plugin als Resharper)

Eigenlijk heel apart, binnen alle IDE's gebruik ik dezelfde keymap instellen.
Behalve Resharper/C#. Daar heb ik de Resharper keymap.

[Douweegbertje]

Mugwump schreef op vrijdag 8 februari 2019 @ 16:41:
[...]


Oh dat geloof ik best hoor. Ik zie alleen de unieke toegevoegde waarde van PHP dan niet zo.
In mijn ogen ligt de kracht van PHP toch vooral in het feit dat oneerbiedig gezegd iedere debiel iets in elkaar kan knutselen dat min of meer werkt. Dat ben je een beetje kwijt als je heel veel structuur en kwaliteitseisen gaat introduceren.

Ik kan net zo goed iets in C# of C++ maken wat op hetzelfde niveau zit van jouw beeld wat iemand kan knutselen met PHP

Met alles wat benodigd is om tegenwoordig de wat fancy spulletjes te draaien/deven in PHP is het makkelijker om een simpel .sln projectje te hebben Ik zie af en toe devs strugelen voor uren om een project lokaal te draaien. Met de komst van wat tools zoals vagrant, docker, etc. is dat beter... maar toch

De onderscheid tussen de beunhaas dev en de wat meer senior is nu wel beter zichtbaar, om er iets positiefs uit te halen!

[Mugwump]

Douweegbertje schreef op vrijdag 8 februari 2019 @ 17:37:
[...]


Ik kan net zo goed iets in C# of C++ maken wat op hetzelfde niveau zit van jouw beeld wat iemand kan knutselen met PHP

Met alles wat benodigd is om tegenwoordig de wat fancy spulletjes te draaien/deven in PHP is het makkelijker om een simpel .sln projectje te hebben Ik zie af en toe devs strugelen voor uren om een project lokaal te draaien. Met de komst van wat tools zoals vagrant, docker, etc. is dat beter... maar toch

De onderscheid tussen de beunhaas dev en de wat meer senior is nu wel beter zichtbaar, om er iets positiefs uit te halen!

Php blijft zonder toeters en bellen gewoon een wat lagere learning curve hebben dan bijvoorbeeld C# of Java. Mijn punt was dat dat juist de kracht van PHP was en dat ik het voordeel bij grote projecten ten opzichte van een C# of Java project niet echt zie.

[Douweegbertje]

Mugwump schreef op vrijdag 8 februari 2019 @ 18:20:
[...]


Php blijft zonder toeters en bellen gewoon een wat lagere learning curve hebben dan bijvoorbeeld C# of Java. Mijn punt was dat dat juist de kracht van PHP was en dat ik het voordeel bij grote projecten ten opzichte van een C# of Java project niet echt zie.

Qua code-wise ben ik het daar ook mee eens. Bepaalde projecten zouden er een voordeel aan doen om in een andere taal te zijn geschreven. Ik gok dat het een kwestie is van andere "stakeholders" voor zo'n project.

- Het blijft makkelijker om er mee te beginnen. Dus qua community en development hierin heb je imo een grotere backing. Zoals je zegt, kan iedere gek bijdragen. Door de juiste tools eromheen begeleid je dat ook goed. Stiekem valt dit soms alleen wel tegen
- Domweg de dev kosten zelf. Een Java dev is nou eenmaal 1.5x zo duur (Gok ik ongeveer wel goed denk ik). Ok prima je kan nog de som maken wat zo'n iemand kan bereiken in die tijd maar...
- Over het algemeen kunnen deliverables sneller worden opgeleverd.

Zo zullen er vast meer dingen zijn.

Ik vind bijvoorbeeld Jira e.d. wel een mooi voorbeeld waarin een web app veel beter tot zijn recht komt met Java dan het zou kunnen met PHP. Mede door de diverse koppelingen en de achtergrond processen die draaien.

Ik ben overigens wellicht een beetje biased omdat ik voornamelijk met PHP projecten betrokken ben geweest.

[gekkie]

Is het grootste voordeel van PHP gewoon niet dat het gemiddelde script wat bij een request wordt geexecute wordt een vrij korte runtime heeft en daarna in z'n geheel als garbage afgevoerd wordt ?
En daarmee vrij vergevingsgezind is wat betreft resource gebruik en dan met name memory leakage ?

[GateKeaper]

Douweegbertje schreef op vrijdag 8 februari 2019 @ 10:33:
[...]
Uiteraard bepaald de implementatie van een dev het eind resultaat en ik snap je hint richting PHP.

Mwah, ik noemde PHP alleen omdat ik mij uit een ver verleden herriner dat ik ook wel eens wat php-scripts op de productie server heb zitten aanpassen. Daar zat de overeenkomst dus.

Verder heb ik absoluut te weinig kennis om iets over de laatste versies van PHP te zeggen. Ik gok dat ik daar al meer dan 10 jaar niks meer mee heb gedaan.

Van PHP naar .NET gegaan (c#), en nu al een 3 - 4 jaar bezig in NodeJS. Ook Node (Ecmascript) veranderd best snel. Maar aan een typesystem wordt voor zover mij bekend nog niet gedacht.

Ik denk dat dat ook een stuk moeilijker gaat worden, omdat je dan elke website mee zou moeten krijgen. De kracht van Node is juist dat het (vrijwel) gelijk is aan dat wat in je browser draait.

Dat gat wordt echter prima opgevuld door Flow, en nog beter door Typescript.

Als je strict typing wilt, geen probleem. Wijk uit naar Typescript zou ik zeggen.

[Ed Vertijsment]

Ik ben frontender, heb full stack ervaring en als ik backend zou doen dan zou dat Python/Django zijn. Echter heb ik ook ruime ervaring met PHP, en hoewel het de nodige kritiek krijgt (en deels ook echt wel terecht) doet het gewoon één ding heel goed.

PHP is code once run everywhere avant la lettre. Je maakt iets lokaal. FTP't het naar provider A. En als je naar provider B wilt dan verkas je het net zo makkelijk.

Daarmee is PHP heel toegankelijk en universeel. Er zijn zeker nadelen aan PHP maar het het is eenvoudig te leren en super simpel om in productie te krijgen. Als je de Django leert ben je nog nowhere near het opzetten van een productie omgeving. Bij PHP is de brug veel kleiner.

Veel moderne dynamische talen doen aan garbage collection en daar is PHP echt niet uniek in. PHP is gewoon een makkelijk te leren taal waarin je gewoon snel aan de slag kan. Dit is iets wat meer "correcte" talen nogal een uit het oog verliezen. Uiteindelijk moeten mensen er namelijk ook mee leren werken.

Ik kan helemaal leip gaan aan waarom pretty much elke taal beter is dan PHP maar tegelijkertijd zal ik 90% van de mensen die een website willen aanraden om gewoon een wordpress'je op PHP in elkaar te flansen. Kost een fractie van maatwerk in taal X en volstaat voor de meeste mensen.

[Douweegbertje]

gekkie schreef op vrijdag 8 februari 2019 @ 23:11:
Is het grootste voordeel van PHP gewoon niet dat het gemiddelde script wat bij een request wordt geexecute wordt een vrij korte runtime heeft en daarna in z'n geheel als garbage afgevoerd wordt ?
En daarmee vrij vergevingsgezind is wat betreft resource gebruik en dan met name memory leakage ?

Niet zeker of het een voordeel is maar ja volgens mij klopt die werking zoals je dat zegt wel. Je kan in "runtime" ook al garbage collecten door bijv. dingen te unsetten. Hoe dat nou helemaal onderwater zit weet ik ook niet exact, ik weet wel dat er cycles zijn en dat je expliciet ook nog dingen kan forceren.

Daarbij dan misschien ook direct het nadeel; omdat je denkt dat alles automatisch wordt geregeld, immers is het 1x een execute en dan is je 'thread' weg, zie je veel high memory meuk voorbij komen. Magento2 recommend 2gig (!!!!!) voor je memory limit. Dat is echt ranzig veel.

Met Doctrine / ORM / DBAL kan je dat prima managen, door dus niet een volledige table op te halen en dat te gaan loopen maar elk stukje te gaan fetchen waneer dat expliciet nodig is.

Anyway, ik denk persoonlijk dat veel PHP programmeurs niet de ins-outs weten van het systeem en wat er nu precies gebeurd. Dan ga je ook niet nadenken hoe het efficiënter kan en kom je meestal uit op wat brakkere systemen.

Je kan namelijk ook gewoon een dataset cachen, zei het door efficient gebruik van de juiste datastructuur in je tables of domweg door memcache of search engines (ES / SOLR indexes etc).

[sig69]

Oe garbage collection! Daar ben ik ooit eens heel diep in gedoken (.net dan wel). Ik kreeg er gelukkig de tijd en ruimte voor en heeft uiteindelijk ook z'n vruchten afgeworpen. Hoop van geleerd ook, best interessante materie.

[gekkie]

Douweegbertje schreef op zaterdag 9 februari 2019 @ 01:30:
[...]
Niet zeker of het een voordeel is maar ja volgens mij klopt die werking zoals je dat zegt wel. Je kan in "runtime" ook al garbage collecten door bijv. dingen te unsetten. Hoe dat nou helemaal onderwater zit weet ik ook niet exact, ik weet wel dat er cycles zijn en dat je expliciet ook nog dingen kan forceren.

Daarbij dan misschien ook direct het nadeel; omdat je denkt dat alles automatisch wordt geregeld, immers is het 1x een execute en dan is je 'thread' weg, zie je veel high memory meuk voorbij komen. Magento2 recommend 2gig (!!!!!) voor je memory limit. Dat is echt ranzig veel.

Met Doctrine / ORM / DBAL kan je dat prima managen, door dus niet een volledige table op te halen en dat te gaan loopen maar elk stukje te gaan fetchen waneer dat expliciet nodig is.

Anyway, ik denk persoonlijk dat veel PHP programmeurs niet de ins-outs weten van het systeem en wat er nu precies gebeurd. Dan ga je ook niet nadenken hoe het efficiënter kan en kom je meestal uit op wat brakkere systemen.

Je kan namelijk ook gewoon een dataset cachen, zei het door efficient gebruik van de juiste datastructuur in je tables of domweg door memcache of search engines (ES / SOLR indexes etc).

Naja je komt dus vooral vaak best redelijk weg met buitengewoon matig optimale code en dat is zoals je zegt ook wel potentieel een nadeel omdat je er "net" mee weg komt en men er dus ook niet naar kijkt.
Maar goed dat is tegelijkertijd ook weer onderdeel van het laagdrempelige.

[.oisyn]

Mijn bignum library sloeg zijn digits altijd op in big-endian, maar dat is voor optimalisatiedoeleinden niet heel erg handig. Nou ben ik de boel dus aan het omdraaien, maar ik kan die knop in mijn hoofd maar niet omzetten en raak volledig de weg kwijt

[Marc3l]

Douweegbertje schreef op zaterdag 9 februari 2019 @ 01:30:
[...]
Daarbij dan misschien ook direct het nadeel; omdat je denkt dat alles automatisch wordt geregeld, immers is het 1x een execute en dan is je 'thread' weg, zie je veel high memory meuk voorbij komen. Magento2 recommend 2gig (!!!!!) voor je memory limit. Dat is echt ranzig veel.

Op het werk hebben we een import script laten ontwikkelen door een andere partij (vooral wegens tijd/capaciteit gebrek en om te testen of dat iets voor ons is ). Deze week was het klaar en eerste test...allowed memory size error. In het script gedoken en moet de bedoeling zijn om in een keer een 85 mb (zo groot was de feed) in de laden zonder streamen / in delen importeren.
Contact gezocht met die partij hoe ik dat dan moet doen. Antwoord: memory ophogen naar +3gb

[gekkie]

Hmmm iedereen druk z'n docker, kubernetes of andere container meuk aan het patchen, voordat ze overboord gaan slaan, dat het hier zo rustig is