Heeft het zin om mensen te vragen voor PHP 7?
We werken hier met antieke software gebouwd in PHP7.2. Daarom heb ik een project gestart om voor eens en voor altijd daar vanaf te komen. Helaas heeft de baas er een stokje voor gestoken wegens financiën. Wellicht start hij het project een jaar later op zodat we alsnog dán kunnen starten met de upgrade.
Maar voor nu, ik wil niet meer in mijn eentje aankloten. Want zo voelt het als je zwemt in oude software. Als je niet meer echt goede upgrades kunt inbouwen, omdat de spaghetticode en oude databases je tegenwerken.
Kun je in zo'n situatie tóch iemand vinden die zijn/haar klauwen erin wil zetten om er toch nog wat van te maken? Iemand die ondanks dat die vast alle ins en outs kent van de nieuwste technieken zich wil vastbijten in oude tools? Om dan na een jaar wellicht wel over te stappen op nieuwe technieken? Uiteraard heb je dan wel invloed op welke richting we gaan in de toekomst. Alleen voordat we die toekomst ingaan moet je dan dus wel vrede hebben met de verouderde werkomgeving.
Heeft het zin om vacatures uit te zetten? Dan ga ik nu direct naar HR.
Ik zit een beetje in een negatieve spiraal door dit nieuws, dus ik heb denk ik wel even iets positiefs nodig van iemand daarbuiten. Maar wel realistisch. Als het niet kan, kan het niet.
Dank jullie voor de informatie.
Maarten
Andere problemen zijn dat het WMS negatieve voorraden veroorzaakt.
Er is ook geen support voor barcode scanners wat straks nodig is als we in het nieuwe pand zitten.
De applicatie is ook totaal niet responsive, waardoor werken met een tablet eigenlijk niet mogelijk is. Als we dat zouden willen, zouden we een stand alone app moeten maken die communiceert met dezelfde database. Maar de huidige applicatie responsive maken is niet te doen.
De planningtool is ook sterk verouderd en werkt zeer traag en onoverzichtelijk.
En nog veel meer. Er zijn ontwikkelingen in the field, klanten willen weten hoeveel % natuurlijk hun product is. Klanten willen werken met SSCC barcodes. Orders moeten gesplitst kunnen worden of deelleveringen moeten gedaan worden en dat kan allemaal niet.
Dit allemaal inbouwen in het huidige systeem lukt mij wel, maar je werkt in een grote kom spaghettisoep. Dus voor een nieuwe programmeur is het eerst de uitdaging de applicatie te leren kennen.
Heb je meer info nodig? De vraag die van mij uit gaat is niet wie wil, maar zijn er uberhaupt enthousiaste en GOEDE PHP programmeurs te vinden die bereid zijn te werken in verouderde omgevingen?
Dank voor jullie huidige en toekomstige reacties!
Groet
Maarten
Ik weet wat je bedoelt met dergelijke omgevingen. Ikzelf heb ooit ook eens gewerkt bij een bedrijf die een groot en log systeem hadden met inefficiënte queries en databases. Soms is het even door de zure appel heen bijten, verbeteren wat je kan verbeteren, en je erdoorheen slaan. Soms moet je wel de afweging maken of bepaalde features in te bouwen zijn. Als je goede argumentatie kan geven aan je leidinggevende waarom functie A enkel met heel veel moeite in te bouwen is, dan is dat al een mooie stap in de richting dat die hopelijk meer budget vrij kan maken voor een nieuw systeem.
Heeft het zin om een vacature uit te zetten waarin je vraagt om met verouderde tools te werken? Ik kan in de vacature wel neerzetten dat we toewerken naar iets nieuws en dat je daar volledig je ei in kwijt kan, maar je zult sowieso 1 jaar volledige toewijding moeten hebben in een sterk verouderd systeem.
Is er enige kans daarin mensen te vinden? Het moeten minstens mediors zijn. Ik heb geen tijd om een junior op te leiden.
Dank!
- Ariën - op 20/03/2024 11:23:17:
PHP 7.2 is zeker niet antiek. Wat zijn momenteel de problemen waar je bijvoorbeeld tegen aanloopt?
Nou, dat dacht ik dus zeker wel. Zelfs PHP 8.1 is al oud, met nog minder dan een jaar te gaan.
Met alleen nog wat security updates, daar ga je daar geen tijd meer in investeren.
Je gaat toch ook niet nu nog op een PC Windows 10 installeren als je ook nog een alternatief hebt als Windows 11 of Linux?
Ik denk dat de baas verstandig is, door geen nieuw geld te willen investeren in een product dat binnen 3 jaar weer herzien moet worden, tenzij daar een duidelijk verdienmodel achter zit. Dat is niet voor een losse tool, daarvoor kan je beter een andere tool of taal voor gaan gebruiken.
Wat betreft de vraag of je genoeg ontwikkelaars kunt krijgen voor PHP 7, is het antwoord natuurlijk: ja, dat kan. Het hangt er maar net vanaf hoeveel je ze wilt betalen. PHP 7 zit voornamelijk vol met dezelfde valkuilen als 5 en 8, dus iemand die redelijk wat kilometers heeft gemaakt zal in alle drie de versies kunnen werken. De nieuwe versies zijn voornamelijk meer 'sexy' omdat bestaande code meer is geoptimaliseerd en uitgebreid. Maar niet echt een stuk beter.
Toevoeging op 20/03/2024 22:02:31:
Maarten Baars op 20/03/2024 11:10:39:
Ik zit een beetje in een negatieve spiraal door dit nieuws, dus ik heb denk ik wel even iets positiefs nodig van iemand daarbuiten. Maar wel realistisch. Als het niet kan, kan het niet.
Ja dat snap ik met PHP, ik heb dat ook gehad. Eerst moest de database van dat @#$% Latin1 naar UTF-8 (utf8mb4, maanden werk!), toen moest de database over van dat @#$% MySQL naar Postgres (half jaar werk), dat wel fatsoenlijk kan schalen en alle functionaliteit standaard aan boord heeft.
En uiteindelijk heb ik de PHP broncode overgeschreven naar Rust (9 maanden werk voor 2MB source code). Ik werd gedurende een aantal jaren goed ziek van alle nieuwe features van PHP 8, zonder dat ze structureel dingen verbeterde. En tegelijk werd wordt wel elke 3 jaar je eigen code gemold door alle backward incompatible changes. Fijne gedachte wanneer je iets wilt maken in PHP. Constructief ook van PHP devs die schijt hebben aan 'userland' code. Of zoals de Engelsen zouden zeggen: easy come, easy go. Ook veel mensen hier op dit forum vonden mijn frustraties niet grappig meer.
Maargoed, het kan dus wel, maar het gaat niet zomaar. Ik ben nu nog steeds aan het refactoren van een suffe intranetapplicatie naar een progressieve webapplicatie vanuit web assembly, ook al gebruik ik geen PHP meer. Ik heb zelf ook niet de ambitie om terug te willen naar PHP, niet meer nu ik verwend ben met Rust.
En wat ik daarboven typte is echt zo, als je mensen genoeg betaalt willen ze heus wel met PHP 7 werken. PHP-ers zijn gewend om vanuit een suboptimale situatie te werken. En zoveel verschil zit er niet in PHP versies, het gaat om hoe een programmeur denkt, of hij/zij/het echt begrijpt wat-ie aan het doen is. Al zou ik als het budget het toelaat meteen een senior iemand willen aanhaken.
Ad Fundum op 20/03/2024 21:45:05:
Nou, dat dacht ik dus zeker wel. Zelfs PHP 8.1 is al oud, met nog minder dan een jaar te gaan.
Antiek vind ik een overstatement. Zwaar verouderd komt meer in de buurt... ;-)
Off topic: Aan de andere kant lijkt het wel alsof onze maatschappij moeite heeft met het accepteren van ouderdom.
Toen ik puber was, was iemand van 18 voor mij al volwassen, ook al wilden ze daar zelf niet aan.
Zelfs veel mensen van middelbare leeftijd (40-60) willen alleen maar horen dat ze jong zijn.
En ouderen (60-70) vinden zichzelf ook vaak 'zo jong als ze zich voelen'.
Ben je eenmaal bejaard (70-80) of hoogbejaard (80+) dan willen mensen soms wel toegeven dat het allemaal wat minder gaat, maar pas bij hoge uitzondering want ze weten dat ze niet gewenst zijn zodra ze de maatschappij tot last zijn.
En weer on-topic: gewoon verouderd is een prima term voor PHP 8.0 en daarvoor.
De baas heeft het niet afgeketst omdat hij weet dat hij over 3 jaar de hele programmering weer moet herzien. Daar heeft die helemaal geen verstand van.
Maar even off topic, want wat je zegt is interessant. Je zegt dus dat PHP als nadeel heeft dat na elke update van deze programmeertaal je maanden werk hebt aan het updaten van de code. Rust is dus anders. Maar in hoeverre voorkom je dat je met Rust na een update van de progammeertaal je je eien code moet updaten?
Het nieuwe afgeketste project zou gemaakt worden in TypeScript. Die heeft als overenkomst met Rust dat het ook een compliled language is, als ik me niet vergis. In mijn "Hello world" tutorials schreef ik code dat op javascript leek, maar om het echt te runnen moest je het wel compiliren naar 'echt' javascript.
Ik zie ook wel dat PHP het populairste is op het web, maar dat dit alleen komt omdat Wordpress zoveel websites heeft. Prachtige maatwerk projecten zie je volgens mij nauwelijks in die taal. En dat is wat ons project precies moet zijn; een prachtig maatwerk project.
Vandaar mijn vraag over Rust, want ik zie PHP niet als het enige walhalla voor ons project.
Bedankt!
Maarten Baars op 21/03/2024 11:07:07:
Ik zie ook wel dat PHP het populairste is op het web, maar dat dit alleen komt omdat Wordpress zoveel websites heeft. Prachtige maatwerk projecten zie je volgens mij nauwelijks in die taal. En dat is wat ons project precies moet zijn; een prachtig maatwerk project.
Vandaar mijn vraag over Rust, want ik zie PHP niet als het enige walhalla voor ons project.
Vandaar mijn vraag over Rust, want ik zie PHP niet als het enige walhalla voor ons project.
PHP is altijd populair geweest, omdat het een makkelijke instap is om te programmeren dat op zowel Linux als Windows werkt. Wordpress bestond toen nog niet eens, en in de beginperiode van PHPhulp waren er dagelijks wel tien topics met vragen over PHP en het bouwen van websites, waarbij er ook diverse concullegae-sites waren zoals WMcity, Webfanaat en Webmensen. Inmiddels is oude ambacht van het programmeren meer verschoven naar off-the-shelf producten zoals Wordpress en Joomla, en lijken steeds meer mensen de weg naar documentatie en knowledgebase (Stackoverflow) te hebben gevonden, en daarbij is AI een nieuwkomer die het best goed doet.
Maar een echte taal is PHP nooit helemaal geworden. Het volgt de weak-typing van C, alle functionaliteiten zijn nooit een samenhangend geheel geworden (alleen al de parametervolgorde). De meeste functionaliteiten zijn geen onderdeel van PHP, maar van extensies met zoveel afhankelijkheden qua besturingssysteem, configuratie van de omgeving, PHP-compilatie, instellingen en nog meer instellingen dat je er een boek over vol kunt schrijven.
Uitdagingen zijn bijvoorbeeld het instellen van een locale, werken met Unicode, asynchroon programmeren (zit niet standaard in PHP, zie AMPHP).
Niets is perfect natuurlijk, maar PHP is zo imperfect dat per PHP 8 zelfs de booleaanse logica is aangepast. Aan dit en meer kan je goed zien dat PHP nooit vooraf als taal is doordacht, het is zelf (de interne werking) bijna nogal spaghetti.
Het core development team maakt zelfs geen verschil tussen major en minor versies, te veel is niet of slecht gedocumenteerd op PHP.net, en ga zo maar door, de lijst is ontzettend lang.
En elke release wordt er wel wat verbeterd, maar het is te marginaal. En zorgt er vaak voor dat je code het niet meer doet, waardoor je weer je hele programma moet testen of alles nog wel werkt. Zonder TDD ben je nergens. En @Ward heeft in dit forum aangegeven dat hij zelfs unit tests had voor strict types, of een variabele bijvoorbeeld wel een integer bevat. En mijn probleem is met de community; ze zijn heel lief en vriendelijk totdat je de minpunten benoemd. Die kennen ze zelf ook wel maar ze kunnen er niets aan doen en zijn het normaal gaan vinden. Of vinden het niet erg genoeg en merken niet hoeveel tijd er elke keer in gaat zitten.
En dan is het net als met printers. Je koopt er 1 voor 50 euro, maar je betaalt je scheel aan inkt. Datzelfde is met PHP: je stapt o zo eenvoudig is, maar als je voor langere tijd iets zoekt dan blijkt dat PHP daar minder geschikt voor is dan andere oplossingen.
Ik heb na 20+ jaar PHP gezocht naar een alternatief. Ik kwam uit op C++, maar durfde dat niet aan. Niet omdat ik die taal niet beheers, maar omdat ik van mijzelf weet dat ik een mens ben en fouten maak. Ik weet niet of jij je de SSL Heartbleed-bug nog kan herinneren? Hieruit blijkt dat zelfs de meest ervaren programmeurs de meest stupide fouten kunnen maken met grote gevolgen.
Rust is vrij nieuw en als goed uitgedachte taal neergezet. Sinds een paar jaar is het niet meer exclusief van Mozilla en gebruiken Google en Microsoft het om hun besturingssytemen (mobile en desktop) veel veiliger te maken. Ook in de Linux-wereld wordt Rust de standaard voor nieuwe projecten. Rust is zeer ergonomisch en bezit de kracht van C/C++ (zero cost abstractions) en is memory-safe, wat inhoudt dat je veel meer moeite moet doen om stupide bugs met grote gevolgen te maken. Het opent nieuwe mogelijkheden (gezien vanuit PHP) naar bijvoorbeeld web assembly.
Je kunt Rust installeren via rust-lang.org, met Codium (+ Rust Analyzer) als IDE, en het boek lezen waarbij je een nadeel van Rust zal ontdekken: de leercurve. Rust is erg precies en echt strict typed. Zo heb je bijvoorbeeld het verschil tussen een array van bytes (a la PHP), een String (a la mbstring), een string 'slice' (combi van begin- en eindpositie) en een CoW (combinatie van array en String). Rust is ook niet precies OOP, het hanteert composition over inheritance. Maar als je code schrijft geeft de linter wel duidelijk aan hoe je het beter kunt doen, de foutmeldigen zijn behulpzaam (itt. C/C++). Het is ook erg belonend, aan het eind van het boek staat een voorbeeld van hoe je zelf een multithreaded webserver kunt maken (a la php-fpm).
Als er al een nieuwe Rust uitkomt (eens in de 3 a 4 jaar is het idee geloof ik) dan blijft bestaande code gewoon werken. Je kunt via een configuratiebestand van je project (Cargo.toml) via een opt-in aangeven met welke 'editie' van Rust je wilt werken. Rust heeft een groot aantal dingen niet in de standaard library, libraries kan je vinden via de site crates.io (a la PHP extensies / PEAR, maar dan uitgebreider).
Rust is meer denkwerk en iets meer typwerk, maar als je iets wilt refactoren geeft de IDE precies aan wat er nog niet goed zit (PHP verzwijgt sommige foutmeldingen) en heb je meteen een impact-analyse. Je kunt je code auditen via de CLI met 'cargo audit' en statisch analyseren met 'cargo clippy'.
Rust zit in een ander segment dan PHP. Snel een site bouwen met Rust zit er niet bij. Een serieus CMS maken en onderhouden (a la Wordpress) zou beter kunnen met Rust dan met PHP, al heb je dan niet zoveel extensies (met zoveel security bugs). Er is geen vraag over Rust die niet beantwoordt wordt op Stack Overflow. Rust wordt daarom ook wel saai gevonden. Toch is het de meest favoriete taal van alle developers wereldwijd gemeten over de afgelopen paar jaren.
Rust en PHP kunnen ook goed samenwerken. Via HTTP, sockets, of zelfs als library, dat je iets in Rust maakt en er een PHP extensie van maakt (ext-php-rs). Het is niet of/of, maar en/of, en ook en/en.
Maarten Baars op 21/03/2024 11:07:07:
Maar even off topic, want wat je zegt is interessant. Je zegt dus dat PHP als nadeel heeft dat na elke update van deze programmeertaal je maanden werk hebt aan het updaten van de code.
Valt nogal mee hoor. Het kan eens een keertje zijn dat je na een paar jaar iets moet aanpassen. Dat is dan in een uurtje gefixt. Ad Fundum klaagt hier nogal vaak over PHP, maar PHP is prima geschikt voor veel websites en webshops. Eveneens voor custom projecten. Persoonlijk zou ik het verhaal van Ad Fundum dan ook met een klein korreltje zout nemen. PHP is prima geschikt voor zeer veel toepassingen, dus laat je niet uit het veld slaan door de mening van een enkeling.
De discussie over PHP leidt vervelend af: zolang PHP ten onrechte wordt aangewezen als de boosdoener, wordt de werkelijke problematiek niet opgelost. Die ligt, als ik zo lees, bij slecht projectmanagement, falend leiderschap, het ontbreken van een universele kwaliteitsvisie, een onhandige allocatie van mensen (tijd) en middelen (budget), enzovoort.
Dit project was evengoed ontspoord als het was geschreven in C#, Java, Python, Ruby... Of Rust.
Om terug te keren op de oorspronkelijke vraag: ja, elke ervaren PHP-developer is het gewend om te werken met een oude codebasis én kan software rot verhelpen. Refactoring hoort bij het dagelijks werk van elke programmeur.
Je gaat niet domweg twee jaar lang in spaghetticode staan roeren, maar werkt met het eergevoel van een padvinder: alle code die je aanraakt, laat je netter achter dan je die aantrof. Dat is de Boyscout Rule van Uncle Bob, die het credo ook wel stelliger formuleert:
We will not ship shit.
Gewijzigd op 23/03/2024 06:54:56 door Ward van der Put
PHP is een toolkit en geschikt om snel websites en andere webdingen in elkaar te zetten. Dat is ook de kracht waar de toolkit om bekend staat. (Sorry voor deze herhaling).
Het nadeel is dat door dit gemak ook vaak gemakkelijk gedacht wordt over een PHP-project, omdat een makkelijke oplossing vaker voorkomt in een situatie die meer beperkt wordt door tijd en geld. Wat je dan wel vaker krijgt is dat een kleine groep, die wel weet wat kwaliteit is en wat je daarvoor moet doen, tegen de bierkaai moet vechten om management overtuigd te krijgen. (Sowieso komt het bij management voor dat ze te makkelijk denken over de meeste dingen). Dat probleem komt minder vaak voor bij fijnmaziger programmeertalen. Zo verdient een Rust-programmeur gemiddeld anderhalf keer zoveel als een PHP-programmeur (met reden). Dat soort dingen maken dat management er serieuzer mee om moet gaan, het kan er niet zo gemakkelijk over denken als over PHP, waar mensen en techniek sneller vervangen worden.
En wat Ozzie zegt klopt ook een aardig eind; niet alle wijzigingen kosten veel tijd. Maar daar wil ik tegenoverstellen dat sommige wijzigingen heel veel tijd kosten, terwijl je daar geen keuze in hebt.
Bijvoorbeeld in PHP 5.4 ofzo (ik ben die versienummers aan het vergeten, gaat de goede kant op) was de default ineens UTF-8 in plaats van Latin1. Moet jij eens vanuit een medior programmeur proberen te redeneren wat er allemaal veranderd moet worden in PHP aan je programma om van Latin1 naar UTF-8 te gaan. Naast de Unicode tutorial op phphulp.nl heb je ook nog zoiets als buffering in PHP, met automatische transcoding. Zelfs iets simpels als DOMDocument->saveHTML() wil geen Unicode uitvoeren, zonder dat je iets speciaals doet wat niet is gedocumenteerd.
In een groter project tellen ook kleinere wijzigingen. PHP zit vol met valkuilen omdat de toolkit informatie direct doorstuurt naar verschillende API's van derden, met elk hun eigen valkuilen. PHP wil graag zoveel mogelijk voor je verbergen, wat betekent dat je code kan hebben waarvan je DENKT dat die het doet, maar ondertussen fijn iets anders doet. Bijvoorbeeld integers overflowen niet, die worden impliciet gecast naar een float. Wanneer ze dat doen hangt af van het aantal bitjes van het systeem waar het voor gecompileerd is en waar het op draait. Dat soort dingen kan dus verschillen per hosting-omgeving. Dit soort gedrag maakt het onzettend ingewikkeld om zeker te zijn en blijven van de kwaliteit van je eigen code in PHP.
Dus wanneer er jaarlijks tig wijzigingen komen, hoe subtiel ook, moet je soms echt vanalles opnieuw controleren, dan is het niet in een uurtje gefixed. Ik zie het al helemaal voor me dat je daarbij ondoorgrondelijke en ongedocumenteerde spaghetti tegenkomt van eerdere junior-collega's die het dan niet meer doet in een unit-test, die je dan weer mag gaan refactoren. Dit raakt ook weer het verhaal van Ward.
En het is niet zo dat ik ongelijk heb, of Ozzie of Ward.
Hoe je iets voor elkaar krijgt is ieders eigen keuze. Misschien kan iemand juist wel heel handig een spijker in de muur krijgen met een heggeschaar, en zijn er voldoende argumenten te bedenken waarom een heggeschaar handiger is dan een hamer. Je hebt bijvoorbeeld minder gereedschap nodig bij een klus, en dat kan tijd sparen. Dat is natuurlijk helemaal prima.
Je kunt ook kiezen voor een stalen hamer. Kost wat meer misschien, en je moet er ervaring mee opdoen. Het is niet geschikt om dingen mee door te knippen. Het hangt er maar net vanaf waar jouw situatie om vraagt en wat je zelf denkt te kunnen.
Ward van der Put op 24/03/2024 07:18:28:
Een PHP-forum lijkt mij juist de aangewezen plaats voor kritiek op PHP.
Er is een verschil tussen enkel kritiek spuien en positieve feedback leveren. Dat laatste kan zinvol zijn, het eerste niet. Het gaat om de intentie waarmee je iets doet en op welke plek je dat doet. Veel topics worden vervuild omdat Ad Fundum z'n beklag gaat doen over PHP en onderwijl ook nog even de vraagsteller aanmoedigt om over te stappen naar RUST. Dat is wat mij betreft niet de juiste intentie en zeker niet de juiste plek. Ad Fundum kan dan beter een eigen topic beginnen waarin hij de minder goede punten van PHP benoemt, met daarbij een oplossing hoe je die punten kunt tackelen. Dán hebben we er iets aan. Als ieder topic wordt misbruikt/gekaapt om te klagen, dan niet.
Voordat een totaal verkeerde indruk ontstaat, wil ik er nog wel even bij zeggen dat Ad Fundum wel degelijk nuttige bijdrages levert aan het forum. Echter, iedere keer het riedeltje met minpunten benoemen, voegt niks toe. Het komt niet ten goede aan de sfeer. Er zijn hier nog maar weinig leden over en het zou jammer zijn als dat er nog minder worden. Als iemand een post plaatst, doet hij/zij dat om geholpen te worden met PHP. Niet om geconfronteerd te worden met alle mogelijke minpunten. Als je daar iets over kwijt wilt, prima, maar maak daar dan een apart topic van en voer de discussie in dat specifieke topic.
Als je tot oplossingen wilt kunnen komen moet je ook negatieve kanten mogen benoemen.
Bijvoorbeeld: het is fijn dat PHP een lage instap heeft. Goedkope ontwikkelaars genoeg, da's fijn voor elk project.
Tegelijkertijd kan je in PHP vanalles op tig manieren doen. Dat zorgt er voor dat nieuwe mensen veel tijd kwijt zijn om uit te vinden wat nou eigenlijk de beste oplossing is.
Neem nou SQL-queries. Iedereen zou dat standaard via prepared statements moeten doen. Toch is er voor MySQL nog altijd geen mysql_query_params() functie zoals voor PostgreSQL. Er is ook niets in de documentatie te vinden wat daar naar wijst.
Ondertussen is SQL-injection (CWE-89) al tijden #3 op de ranglijst van 25 meest gevaarlijke security bugs: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
Het loopt zelfs zo erg de spuigaten uit dat de FBI er voor waarschuwt: https://www.security.nl/posting/835348/FBI+roept+softwareontwikkelaars+op+einde+aan+SQL+Injection+te+maken
Wat doet PHP er aan? Niets.
Wat doen ze wel? Ze maken eindelijk utf8_encode() en utf8_decode() deprecated, want dat kan je ook nog op 3 manieren doen (zie vooral de beschrijving):
* mb_convert_encoding() - Convert a string from one character encoding to another
* UConverter::transcode() - Convert a string from one character encoding to another
* iconv() - Convert a string from one character encoding to another
Je kunt deze kritiek als bevuilend opvatten voor het forum, maar hoeveel mensen zijn hier zich nou eigenlijk echt bewust van beveiliging?
PHP is dankzij de (veelal verborgen) complexiteit een compleet universum, waarin goede keuzes moeilijk zijn als je ook maar een beetje afwijkt van de defaults.
Gelukkig zijn er ook sites waarvan je een boel kunt opsteken:
- https://phptherightway.com (hoe het dan wel moet)
- https://cheatsheetseries.owasp.org (hoe je wel veilige software maakt)
- https://r.je/views-are-not-templates (waarom MVC niet werkt)
Persoonlijk vind ik mijn posts redelijk genuanceerd. Het staat je natuurlijk vrij om het daar niet mee eens te zijn.
Ik heb gezegd wat ik wilde zeggen en stop deze discussie nu. Ik laat het verder over aan de admins om er wel of niet iets van te vinden.
@Maarten Baars:
Oprecht sorry voor het off topic gaan en het kapen van jouw topic. Heb je inmiddels voldoende antwoord op je vraag? Zo niet, laat het dan gerust weten!
Dit topic is gesloten.