I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Ik heb een applicatie die mijn testers al twee keer afgewezen hebben op super anale gronden*. Zit hem net nog een paar keer door te klikken en ik ontdek dat alles finaal de mist in gaat bij > 3 minuten achtergrondactiviteit.
Whoops.
*sommige dingen vertalen gewoon niet lekker uit het Engels.
iOS developer
Uit zijn 16 jaren levenservaring.
If money talks then I'm a mime
If time is money then I'm out of time
Verwijderd
Ik snap niets van wat je nu schrijft. Wat probeer je precies te doen, en waarom veranderen je ID's? En heb je het in deze context niet gewoon stiekem over array keys die veranderen nadat je een element verwijdert uit de array?F.West98 schreef op vrijdag 29 augustus 2014 @ 21:34:
[...]
Dit probleem is geen issue die je normaal zou merken in het gÃbruik, dat is gewoon weergeven van de informatie.
Ik probeer echter intelligentie toe te voegen en wijzigingen te detecteren... Dat lukt dus gewoon niet
(Uit de algemene voorwaarden van NS met het afsluiten van een product bij ze, Traject vrij bij mij).Algemene voorwaarden voor het vervoer van Reizigers en Handbagage van de Nederlandse Spoorwegen (AVR-NS) geïnformeerd te worden via ns.nl/voorwaarden
Zou deze geschreven zijn door een mede-tweaker?
Ghehe, maaruhm, wanneer gaan we eens stoppen met F.West zo te pesten?
No trees were harmed in the creation of this message, but several thousand electrons were mildly inconvenienced.
Waarom zouden we daar ooit mee stoppen?Robbiedobbie schreef op zaterdag 30 augustus 2014 @ 11:54:
Ghehe, maaruhm, wanneer gaan we eens stoppen met F.West zo te pesten?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Geen idee, want als dat gebeurt is het hek van de dam natuurlijk. Je zult zien dan we binnen de kortste keren dan niets negatiefs over PHP meer mogen zeggen en dan kunnen we de Coffee Corner wel gaan sluiten
Ik probeer info te parsen uit dit bestand: http://www.roosterpg.nl/data/roostergegevens_1435_1444.txtVerwijderd schreef op zaterdag 30 augustus 2014 @ 10:34:
[...]
Ik snap niets van wat je nu schrijft. Wat probeer je precies te doen, en waarom veranderen je ID's? En heb je het in deze context niet gewoon stiekem over array keys die veranderen nadat je een element verwijdert uit de array?
Dat probeer ik nu al een half jaar.
Nu vond ik ineens dat voor elke entry een ID staat. (42a, 1928a, ....)
Op het moment dat de roostermaker deze data wijzigt, wordt dit bestand opnieuw gegenereerd met nieuwe ID's.
Voor enkel weergeven van de data geen probleem, maar als je de wijzigingen in de data wil bijhouden is dat zo goed als onmogelijk, omdat zowel de ID's als de data veranderen.......
En als mens zie je niet dat die ID's veranderen, kwam ik pas achter toen het mis ging :
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Los daarvan, is het misschien beter om die persoonsgegevens niet zo openbaar op internet te hebben?F.West98 schreef op zaterdag 30 augustus 2014 @ 12:55:
[...]
Ik probeer info te parsen uit dit bestand: http://www.roosterpg.nl/data/roostergegevens_1435_1444.txt
Dat probeer ik nu al een half jaar.
Nu vond ik ineens dat voor elke entry een ID staat. (42a, 1928a, ....)
Op het moment dat de roostermaker deze data wijzigt, wordt dit bestand opnieuw gegenereerd met nieuwe ID's.
Voor enkel weergeven van de data geen probleem, maar als je de wijzigingen in de data wil bijhouden is dat zo goed als onmogelijk, omdat zowel de ID's als de data veranderen.......
En als mens zie je niet dat die ID's veranderen, kwam ik pas achter toen het mis ging :
Nou hadden ze dat op mijn oude middelbare school beter voor elkaar, gewoon netjes de klassenlijsten publiekelijk op internet
No trees were harmed in the creation of this message, but several thousand electrons were mildly inconvenienced.
Bij mijn HBO opleiding stond vroeger alles openbaar (gewoon op onze academiesite). Zowel de sheets van de lessen, als de blokboeken en de toetsuitslagen.Kobus Post schreef op zaterdag 30 augustus 2014 @ 12:58:
[...]
Los daarvan, is het misschien beter om die persoonsgegevens niet zo openbaar op internet te hebben?
Nou hadden ze dat op mijn oude middelbare school beter voor elkaar, gewoon netjes de klassenlijsten publiekelijk op internet
Sinds 1,5 jaar is alles achter inlog gekomen. Grootste nadeel is hierdoor dat je minder makkelijk vakken kunt 'volgen' die niet in je lespakket zit (ik volg soms lessen die ik al gehaald heb of van een andere opleiding die ik wel interessant vind).
Tja. Op deze bestanden zit normaal ook een .htaccess bestand, maar ze draaien IIS.Kobus Post schreef op zaterdag 30 augustus 2014 @ 12:58:
[...]
Los daarvan, is het misschien beter om die persoonsgegevens niet zo openbaar op internet te hebben?
Nou hadden ze dat op mijn oude middelbare school beter voor elkaar, gewoon netjes de klassenlijsten publiekelijk op internet
Overigens, op de website zelf (gewoon root) hebben ze het minder 'openbaar'.
Maar zoek op Google maar eens naar 'Infoweb'. Heeeel veel van die websites, en veel openbare /data mappen
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Nog steeds geen ramp.. in feite heb je altijd een 'table' met een unieke x&y waarde, bijv. tijd in uren & de dag. Dus elk vakje is wel degelijk uniek en zo kun je wel degelijk bijhouden wat er is veranderd.F.West98 schreef op zaterdag 30 augustus 2014 @ 12:55:
[...]
Ik probeer info te parsen uit dit bestand: http://www.roosterpg.nl/data/roostergegevens_1435_1444.txt
Dat probeer ik nu al een half jaar.
Nu vond ik ineens dat voor elke entry een ID staat. (42a, 1928a, ....)
Op het moment dat de roostermaker deze data wijzigt, wordt dit bestand opnieuw gegenereerd met nieuwe ID's.
Voor enkel weergeven van de data geen probleem, maar als je de wijzigingen in de data wil bijhouden is dat zo goed als onmogelijk, omdat zowel de ID's als de data veranderen.......
En als mens zie je niet dat die ID's veranderen, kwam ik pas achter toen het mis ging :
Het is geen API, dus dan zorg je dat je de data wel uniform opslaat in je eigen systeem om vervolgens dan pas 'queries' erop los te laten.
Die ID's zijn dus niet wat jij wilt dat ze zijn. Het is dus niet "een issue" in de software van derden maar een foute aanname aan jouw kant.F.West98 schreef op zaterdag 30 augustus 2014 @ 12:55:
Nu vond ik ineens dat voor elke entry een ID staat. (42a, 1928a, ....)
Op het moment dat de roostermaker deze data wijzigt, wordt dit bestand opnieuw gegenereerd met nieuwe ID's.
Voor enkel weergeven van de data geen probleem, maar als je de wijzigingen in de data wil bijhouden is dat zo goed als onmogelijk, omdat zowel de ID's als de data veranderen.......
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Never explain with stupidity where malice is a better explanation
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
uh wat ik keek meer naar het plaatje op je beeldschermFiresphere schreef op zaterdag 30 augustus 2014 @ 17:52:
Toch niet voor niets Java 5 gestudeerd!
[afbeelding]
Nothing to see here!
Verwijderd
Ergo: de nummers zijn dus geen ID's. Je gehele denk- en werkwijze is gestoeld op een verkeerde aanname. Daarbij heb je weldegelijk een identifier, namelijk de voor- en achternaam. Lijkt me stug dat iemand zijn of haar naam verandert. Maar dan nog: ook dat is en blijft een aanname, en we weten wat dat betekent.F.West98 schreef op zaterdag 30 augustus 2014 @ 12:55:
Voor enkel weergeven van de data geen probleem, maar als je de wijzigingen in de data wil bijhouden is dat zo goed als onmogelijk, omdat zowel de ID's als de data veranderen.......
Overigens, volgens mij klopt er geen reet van de structuur/inhoud van dat document. Vind het nogal inconsistent voor een export van roosterdata.
Nou, hoeveel systemen ken jij die een *.txt bestand aanleveren als geëxporteerde data? Los van de inhoud (ziet eruit als een tab-separated document met gekke sectioning) is dat natuurlijk wel echt uitzonderlijk. Verbaast mij overigens niets hoor. ICT + overheid = faal. Zal vast een vriendje van een vriendje van zijn geweest die dik heeft lopen cashen op deze troep.Douweegbertje schreef op zaterdag 30 augustus 2014 @ 17:43:
Waarom is een txt export van wat data direct een beroerd systeem? Lekker boeiend hoe dat eruit ziet.. kijk, als het nu een soort public api was geweest die allemaal 'vage' dingen had.. ok prima.
[ Voor 28% gewijzigd door Verwijderd op 30-08-2014 18:35 ]
Deze?Rutix schreef op zaterdag 30 augustus 2014 @ 18:26:
[...]
uh wat ik keek meer naar het plaatje op je beeldscherm

Ik probeerde troep op m'n bureau buiten beeld te houden, die achteraf gezien inderdaad wel een *kuch*interessant*kuch* perspectief opleverde
Ik merk aan je spellings-skills dat je enigszins was afgeleid trouwens
[ Voor 10% gewijzigd door Firesphere op 30-08-2014 18:32 ]
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Nope. Vaak genoeg geprobeerd, maar niet betrouwbaar te krijgen door menselijke invoer-fouten van de roostermaker.Douweegbertje schreef op zaterdag 30 augustus 2014 @ 16:40:
[...]
Nog steeds geen ramp.. in feite heb je altijd een 'table' met een unieke x&y waarde, bijv. tijd in uren & de dag. Dus elk vakje is wel degelijk uniek en zo kun je wel degelijk bijhouden wat er is veranderd.
Het is geen API, dus dan zorg je dat je de data wel uniform opslaat in je eigen systeem om vervolgens dan pas 'queries' erop los te laten.
Zo heb je bijvoorbeeld meerdere lessen het 1e uur op maandag. Waar kan je dan nog meer op sorteren? Klas? Nee, kan best een vervallen les en een nieuwe les zijn, of een vergadering, zonder klas... Docent? Zelfde. Lokaal? Zelfde, en gym heeft vrijwel altijd dubbele lessen en lege lokalen. Combinatie? Niet foutloos te krijgen, de data verandert immers (lokaalwijziging o.i.d.)....
Die aanpak HAD ik, tot ik dit weekend dacht dat die ID's wel handig zouden zijn
Nog steeds, als data ineens kan verdwijnen, dan valt dat ook nauwelijks te tracken, zonder alle items langs te gaan en de niet-meer-bestaande te verwijderen in de db. Ook weer heel erg duur qua performance.
Oplossing nu:
Alle data wissen, en alles opnieuw opslaan. Dan maar niet de wijzigingen detecteren....
Als ik de PHP-site source bekijk (te downloaden op internet..) wordt bij het verwerken van de data dat veld wel mooi 'id' genoemd....Verwijderd schreef op zaterdag 30 augustus 2014 @ 18:31:
[...]
Ergo: de nummers zijn dus geen ID's. Je gehele denk- en werkwijze is gestoeld op een verkeerde aanname. Daarbij heb je weldegelijk een identifier, namelijk de voor- en achternaam. Lijkt me stug dat iemand zijn of haar naam verandert. Maar dan nog: ook dat is en blijft een aanname, en we weten wat dat betekent.
Overigens, volgens mij klopt er geen reet van de structuur/inhoud van dat document. Vind het nogal inconsistent voor een export van roosterdata.
En de identifier voor- / achternaam gebruik ik niet. Als je een (heel groot) stuk naar beneden gaat kom je ergens #### KLASSEN tegen en dan krijg je het rooster per klas. Daar staan ook alle lessen in, dus performancetechnisch veel sneller. Dat gebruik ik dus ook. Dan pleur ik alle lessen in één grote tabel in mijn DB, en dan tijdens ophalen via mijn API kan je dat prima sorteren en alles. Bij updaten van mijn data gaat het dan mis, ik moet DB-entries aan .txt-entries koppelen, en er is geen constante tussen die twee. Niet gegarandeerd tenminste.
En het is vrij consistent als je weet wat het is
Bovenaan heb je enkele settings, naam-value gesplitst met TAB.
Daarna heb je een nieuwe sectie, elke sectie is gemarkeerd met 7x# en dan de naam (tab).
De leerlingen hebben llnr - tab - voornaam - tab - tussenvoegsel - tab - achternaam - tab - lessen (gescheiden met tabs)
Een les is opgebouwd uit een aantal delen, gescheiden met komma.
Daarna lerarenrooster: leraarafkorting - tab - lessen
Daarna lokalen- en klassenrooster, zelfde.
Daarna leerlingverzamelingen, welke leerlingen in welke klas zitten, tabgescheiden again. Same for docent- en lokaalverzamelingen.
Overigens is dit het standaard-rooster, je hebt een roosterwijzigingenbestand (/roosterwijzigingen_wkxx.txt) met daarin alle wijzigingen. Dan heb je eerst alle wijzigingen, wijzigingnummer (array-key), oude les, nieuwe les. 0 = niet aanwezig (vervallen - of extra les).
Als het rooster gewoon keurig zo zou zijn, geen probleem. Wijzigingen kun je herkennen aan het standaard-rooster, als die niet zou veranderen. Dat gebeurt dus wel, als de roostermaker een permanente wijziging wil maken. Dan verandert hij het standaardrooster. En dan gaat alles 100% mis
TL;DR:
Deze data is niet geschikt voor mijn doel, en eigenlijk hoort dit hier helemaal niet
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
In dit geval lijkt het me symptomatisch voor het hele systeem (de sites maken gebruik van frames en imagemaps
En die softwarebouwer verdient veeeeeeel geld (en nog een keer veel geld met cursussen voor een programma dat volgens mij voor zich zou moeten kunnen spreken), en ik vind het een aanfluiting voor ons vak.
Never explain with stupidity where malice is a better explanation
Niets mis met een goede XML of een goed gedocumenteerde TXT.incaz schreef op zaterdag 30 augustus 2014 @ 19:07:
Ik vind het in 2014 al bijna niet meer te verantwoorden om voor dit soort zaken geen json te nemen maar iets vaags legacy-achtigs dat zo inflexibel is als wat. Dat is niet noodzakelijkerwijs altijd fout, maar verdomd vaak wel.
In dit geval lijkt het me symptomatisch voor het hele systeem (de sites maken gebruik van frames en imagemapsom inderdaad maar te zwijgen over het feit dat het systeem standaard blijkbaar gewoon al je leerlingen online gooit, ik heb idd even gegoogled, en, wow) - een onvoorstelbaar beroerd geprogrammeerde ononderhoudbare bende die gedoemd is voor altijd in 1999 te blijven hangen.
En die softwarebouwer verdient veeeeeeel geld (en nog een keer veel geld met cursussen voor een programma dat volgens mij voor zich zou moeten kunnen spreken), en ik vind het een aanfluiting voor ons vak.
Als de content maar documented is, en bruikbaar is (e.g. geen onleesbare brij waar je maar 15 regexes op moet loslaten om er iets zinnigs uit te krijgen. En ja, dat heb ik gehad), dan maakt het format niet uit.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Zelf parsers schrijven is vrijwel atijd een slecht idee en leidt alleen maar tot lezers die onderhouden moeten worden. Zeker als er ook maar de kleinste kans is dat er andere software opnieuw tegenaan moet praten, of zelfs maar je eigen software op meerdere plekken, is het gewoon vrijwel nooit de juiste oplossing. Want je blijft dan vrijwel standaard zitten met problemen van backwards compatibility. En ook is je informatie behoorlijk unportable, want je moet voor elke taal weer een nieuwe parser schrijven.
Het gebruiken van standaardformaten en standaardparsers zou een hele belangrijke Best Practice moeten zijn - iets waar je pas vanaf wijkt als je heel goed duidelijk kunt maken waarom het in die specifieke situatie echt grote meerwaarde heeft die flink uitstijgt boven de nadelen van een custom format.
Never explain with stupidity where malice is a better explanation
Dan is het waarschijnlijk niet TXT?Firesphere schreef op zaterdag 30 augustus 2014 @ 19:09:
goed gedocumenteerde TXT
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Waarom niet? Als het een txt is met duidelijk line endings, of de content is een XML?
Beetje stom natuurlijk, maar het gebeurd en het kan.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Helemaal mee eensincaz schreef op zaterdag 30 augustus 2014 @ 19:07:
Ik vind het in 2014 al bijna niet meer te verantwoorden om voor dit soort zaken geen json te nemen maar iets vaags legacy-achtigs dat zo inflexibel is als wat. Dat is niet noodzakelijkerwijs altijd fout, maar verdomd vaak wel.
In dit geval lijkt het me symptomatisch voor het hele systeem (de sites maken gebruik van frames en imagemapsom inderdaad maar te zwijgen over het feit dat het systeem standaard blijkbaar gewoon al je leerlingen online gooit, ik heb idd even gegoogled, en, wow) - een onvoorstelbaar beroerd geprogrammeerde ononderhoudbare bende die gedoemd is voor altijd in 1999 te blijven hangen.
En die softwarebouwer verdient veeeeeeel geld (en nog een keer veel geld met cursussen voor een programma dat volgens mij voor zich zou moeten kunnen spreken), en ik vind het een aanfluiting voor ons vak.
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Als de content XML is, dan is het dus XML, niet willekeurige plain text.Firesphere schreef op zaterdag 30 augustus 2014 @ 19:25:
[...]
Waarom niet? Als het een txt is met duidelijk line endings, of de content is een XML?
Beetje stom natuurlijk, maar het gebeurd en het kan.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Als die XML in een txt is gepropt, is de parsing wel iets anders, dus ja, het is andersRayNbow schreef op zaterdag 30 augustus 2014 @ 19:31:
[...]
Als de content XML is, dan is het dus XML, niet willekeurige plain text.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Wij op ons werk ook frames (iframe dan) om rekenboxen aan te leveren voor 3e partijen. Wij kunnen binnen 5 seconden een gehele implementatie aanleveren die ook nog gedeeltelijk custom is voor de klant.
Hoewel ik ook weet dat dit enigszins achterhaald is, was het wel de manier van werken ongeveer 10 jaar geleden. Ik weet ook dat het niet meer helemaal van deze tijd is, maar uiteindelijk is het een vrij simpele rekensom. Het gaat ons zeer zeker ~400 uur al dan niet meer kosten om dit om te bouwen naar iets met WSDL (meeste van ons is soap).
Uiteindelijk is het dan een vrij simpele rekensom dat dit er nog niet is (staat wel geplanned in de roadmap medio 2015 maar toch).
Hoewel ik als programmeur er een hekel aan heb, snap ik het wel.
Los van dat, ik vraag me af of FWest te horen heeft gekregen van "dit is onze 'API'".. volgens mij vond je deze data en wie zegt dat dat hun 'api' is?
beetje tl;dr.. oude code bestaat gewoon. Don't fix if it ain't broke. Het werkt, iedereen werkt er blijkbaar nog mee. Los van dat vind ik het ook nog wel een kwalijk puntje dat al die namen public zijn...
De iframe is gewoon ééntje, naar een subfolder die gewoon de index.php bevat. Werkt prima.
Verder vond ik deze data idd (eerder parsete ik gewoon de website), en ik heb ook nergens gezegd dat dit de API is. Zeker omdat dit normaal afgeschermd is met een .htaccess, maar school IIS draait....
Maar die namen zijn ook (minder) public gewoon op het rooster zelf zichtbaar. Was ook ooit het plan om die achter een login te zetten, maar dat was 'technisch niet mogelijk' (ze draaien al IIS, op dezelfde server als waar het hele leerlingsysteem op draait, met AD logins. Is toch makkelijk te koppelen?)
Maar als je de source downloadt is het ook best 'slechte' code, variabele namen als $hetRoosterDatIkMoetTonen, $waarde = magIkDitRoosterTonen($hetRoosterDatIkMoetTonen) == "Ja";
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
It is broke. Niet alleen hier trouwens, maar we zitten als maatschappij met een hoeveelheid legacyshit omdat ontwikkelaars elkaar aanpraten dat het ok is. Ook bij banken en ziekenhuizen - het zou normaal moeten worden om op z'n minst een beetje kwaliteit te leveren. Dat software-bedrijf incasseert wel elke keer heel veel geld - daar zouden ze ookt iets behoorlijks voor kunnen leveren.Douweegbertje schreef op zaterdag 30 augustus 2014 @ 19:39:
beetje tl;dr.. oude code bestaat gewoon. Don't fix if it ain't broke. Het werkt, iedereen werkt er blijkbaar nog mee.
Never explain with stupidity where malice is a better explanation
Één vinkje in IISF.West98 schreef op zaterdag 30 augustus 2014 @ 20:03:
Maar die namen zijn ook (minder) public gewoon op het rooster zelf zichtbaar. Was ook ooit het plan om die achter een login te zetten, maar dat was 'technisch niet mogelijk' (ze draaien al IIS, op dezelfde server als waar het hele leerlingsysteem op draait, met AD logins. Is toch makkelijk te koppelen?)
Een beetje verbose, en die "Ja" is ook mooiMaar als je de source downloadt is het ook best 'slechte' code, variabele namen als $hetRoosterDatIkMoetTonen, $waarde = magIkDitRoosterTonen($hetRoosterDatIkMoetTonen) == "Ja";
We are shaping the future
Wat is er mis met image maps?
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Het zijn tenminste nog omschrijvende namenF.West98 schreef op zaterdag 30 augustus 2014 @ 20:03:
Maar als je de source downloadt is het ook best 'slechte' code, variabele namen als $hetRoosterDatIkMoetTonen, $waarde = magIkDitRoosterTonen($hetRoosterDatIkMoetTonen) == "Ja";
Ze schalen rot?
Maar ok, er is niets mis met image maps in algemene zin. Zoals er ook niks an sich mis is met tables en divs. (Ok, over tables wil men nog wel eens clashen, maar voor tabular data vind ik het te verantwoorden in bepaalde gevallen.)
Het zit dan ook vooral in de toepassing.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| <table id="root" style="width: 10000px;"> <tr> <td id="header" colspan="2"> </td> </tr> <tr> <td colspan="2" id="tweedebalk"> Laatste update rooster is van: vr, 29 aug 2014 13:04:27 </td> </tr> <tr> <td id="menu"> <img src="styles/SubSilver//images/menuboven.gif" ismap="ismap" style="border: none; margin-bottom: 100px;" usemap="#IHIP_NEW" alt="" /> <map name="IHIP_NEW" id="IHIP_NEW"> <area shape="rect" coords="35,5,56,26" alt="home" href="index.php" /> <area shape="default" alt="" nohref="nohref" /> </map> <div onclick="document.location='index.php?ref=2';" class="knop" onmouseover="this.style.backgroundImage='url(styles/SubSilver/images/knop_d.gif)';" onmouseout="this.style.backgroundImage='url(styles/SubSilver/images/knop.gif)';" ><span>leerlingroosters</span></div><div onclick="document.location='index.php?ref=3';" class="knop" onmouseover="this.style.backgroundImage='url(styles/SubSilver/images/knop_d.gif)';" onmouseout="this.style.backgroundImage='url(styles/SubSilver/images/knop.gif)';" ><span>docentenroosters</span></div><div onclick="document.location='index.php?ref=4';" class="knop" onmouseover="this.style.backgroundImage='url(styles/SubSilver/images/knop_d.gif)';" onmouseout="this.style.backgroundImage='url(styles/SubSilver/images/knop.gif)';" ><span>lokalenroosters</span></div><div onclick="document.location='index.php?ref=5';" class="knop" onmouseover="this.style.backgroundImage='url(styles/SubSilver/images/knop_d.gif)';" onmouseout="this.style.backgroundImage='url(styles/SubSilver/images/knop.gif)';" ><span>klasroosters</span></div> </td> <td id="content"> |
Maar als er mensen zijn die echt gaan verdedigen dat dit best een prima manier is om een simpel navigatiemenuutje opzetten, dan word ik toch heel verdrietig
Never explain with stupidity where malice is a better explanation
Verwijderd
En als de XML in een .json is gepropt, is de parsing ook heel anders. De intrinsieke data verandert niet door de extensie van het bestand te veranderen.Firesphere schreef op zaterdag 30 augustus 2014 @ 19:32:
[...]
Als die XML in een txt is gepropt, is de parsing wel iets anders, dus ja, het is anders
1
2
3
4
5
6
7
8
9
10
| $myXml = file_get_contents('my_xml.xml'); // Even wegschrijven naar .txt file_put_contents('my_xml.txt', $myXml); // Even wegschrijven naar .zip file_put_contents('my_xml.zip', $myXml); // Even wegschrijven naar .exe file_put_contents('my_xml.exe', $myXml); |
Los van de overduidelijke semantische betekenis van een extensie, boeit het natuurlijk geen reet om data weg te schrijven naar wat voor extensie dan ook. Je impliceert nu echter dat data "iets anders" is doordat je XML in een .txt wegschrijft, en dat is gewoon écht niet zo. Sterker nog, een extensie geeft alleen een hint wat de data kan zijn. Wat de enen en nullen daadwerkelijk allemaal voorstellen, staat natuurlijk geheel los van de naam van het bestand.
Hoezo?
1
2
3
4
5
6
| area { top: 10%; left: 10%; width: 5%; height: 5%; } |
Schaalt prima. Onzin. Schaalt idd voor geen meter, want je moet natuurlijk absolute coordinaten geven.
/me biertje maar wegzet.
[ Voor 13% gewijzigd door Verwijderd op 30-08-2014 20:57 ]
Dat kan je niet ontkennen neeMartijn19 schreef op zaterdag 30 augustus 2014 @ 20:43:
[...]
Het zijn tenminste nog omschrijvende namen
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Xml is helemaal niet altijd zinloos want json kan helemaal niet hetzelfde als xml.incaz schreef op zaterdag 30 augustus 2014 @ 19:23:
Xml kan maar vind ik vrij zinloos - json kan hetzelfde maar is leesbaarder en heeft beduidend minder overhead.
Metadata om maar iets te noemen...
En zo zijn er nog een hele zooi dingen. Dat soms (vaak) xml wordt misbruikt terwijl iets anders (simpelers) volstaat doet niets af aan hoe nuttig xml kan zijn.
Lekker op de bank
Dus omdat ik ooit een kwaliteitsproduct heb geleverd, moet ik 5 jaar later het helemaal opnieuw voor ze maken? Het is ooit van kwaliteit geweest, tijd heeft er voor gezorgd dat het niet meer fatsoenlijk is. Wie moet er voor betalen dan? Waar haal je de tijd even vandaan?incaz schreef op zaterdag 30 augustus 2014 @ 20:12:
[...]
It is broke. Niet alleen hier trouwens, maar we zitten als maatschappij met een hoeveelheid legacyshit omdat ontwikkelaars elkaar aanpraten dat het ok is. Ook bij banken en ziekenhuizen - het zou normaal moeten worden om op z'n minst een beetje kwaliteit te leveren. Dat software-bedrijf incasseert wel elke keer heel veel geld - daar zouden ze ookt iets behoorlijks voor kunnen leveren.
Het is iets te simpel om te redeneren dat als iets legacy is, dat je het maar opnieuw moet maken. Elk fatsoenlijk bedrijf die dat zou doen, zou direct failliet gaan. Je moet gewoon prioriteiten stellen, en elk stukje legacy code vernieuwen is eenmaal geen prioriteit. Waarom zou je, het is helemaal niet broke. Het werkt. Dat jij er misschien niet goed mee kan omgaan(irritant er in werken etc.) en dat eventuele dev tijd 30% hoger ligt maakt het nog niet broke.
Als het gaat om 'nu', dat je nu een applicatie krijgt met een .txt als koppeling en iframes. Ok prima. De applicaties waar we het nu over hebben, zijn dingen die al jaren bestaan.
Onze applicatie is zo groot, dat als we alle legacy dingen zouden herschrijven, zouden we pas over 1 jaar klaar zijn en dan is het eerste stukje wat we hebben herschreven al weer legacy. Wij kunnen niet eens over naar PHP 5.5 omdat dan dingen uit elkaar vallen. Stuk voor stuk worden dingen verbetert en bij nieuwe features pakken we oude dingen aan wat in we weg zit. Soms wordt er een project opgezet om een bepaald onderdeel te herschrijven c.q. verbeteren en thats it.
Ik snap heel goed je punt, maar je denkt er eigenlijk net iets te simpel over. Er speelt wel wat meer dan een stukje code typen.
mja, misschien hier en daar wel broken ipv broke
[ Voor 67% gewijzigd door Douweegbertje op 30-08-2014 22:20 ]
ReferenceError: aopen is not defined in Firebug
Nieuwe berichten functie werkt niet meer in bepaald topic.
[ Voor 29% gewijzigd door _David_ op 30-08-2014 22:26 ]
I thought fail2ban would keep the script kiddies out but somehow you still seem to be able to login.
Ik snap niet dat zoveel mensen JSON verkiezen BOVEN XML.incaz schreef op zaterdag 30 augustus 2014 @ 19:23:
Xml kan maar vind ik vrij zinloos - json kan hetzelfde maar is leesbaarder en heeft beduidend minder overhead. (Csv is overigens wel zinvol voor tabular data.)
Beide hebben een hele ander soort toepassing!
Ik werk veel in de enterprise wereld (ERP systemen), en daar MOETEN wij heel veel validaties doen in de data (zowel wat binnenkomt als wat wij eruit sturen). Dit wordt heel veel gecheckt door middel van XSD's.
Kan je ook de data valideren met JSON? blijkbaar kan het ook wel, zie quote hieronder
In de MEESTE gevallen kan ik wel begrijpen waarom JSON veel beter is, maar om te concluderen dat JSON > XML is mij een beetje te kort door de bocht!
Spuit 11, zoals ZaZ al zei
[ Voor 5% gewijzigd door Ryur op 30-08-2014 22:49 ]
Ja, je kan ook data valideren met JSON.Ryur schreef op zaterdag 30 augustus 2014 @ 22:34:
[...]
Ik werk veel in de enterprise wereld (ERP systemen), en daar MOETEN wij heel veel validaties doen in de data (zowel wat binnenkomt als wat wij eruit sturen). Dit wordt heel veel gecheckt door middel van XSD's.
Kan je ook de data valideren met JSON?
Elk ding heeft zijn doel, maar 9/10 worden dingen gedaan met XML die je simpeler kon oplossen met JSON. Nu gebruik ik dan weer toevallig overal XML voor, omdat we nou eenmaal die koppeling met een ander pakket hebben.Ryur schreef op zaterdag 30 augustus 2014 @ 22:34:
[...]
Ik snap niet dat zoveel mensen JSON verkiezen BOVEN XML.
Beide hebben een hele ander soort toepassing!
Ik werk veel in de enterprise wereld (ERP systemen), en daar MOETEN wij heel veel validaties doen in de data (zowel wat binnenkomt als wat wij eruit sturen). Dit wordt heel veel gecheckt door middel van XSD's.
Kan je ook de data valideren met JSON? blijkbaar kan het ook wel, zie quote hieronder
In de MEESTE gevallen kan ik wel begrijpen waarom JSON veel beter is, maar om te concluderen dat JSON > XML is mij een beetje te kort door de bocht!
Spuit 11, zoals ZaZ al zei
De 'haat' zit hem (naar mijn mening) meer in bepaalde systemen waarbij je misschien maar 2-3 dingen hoeft te sturen en waar opeens de 'code eromheen' 3x groter is dan de data die je verstuurd.
Nothing to see here!
no shit. Moet je maar eens bij ons op de vloer zitten
Sowieso thuis nog 10 stuks liggen van die oude OEM dingen die ik dan lekker kapot kan slaan
Verwijderd
Euh, hoezo? Wat kan je nou niet met JSON, wat je wel met XML kan?Ryur schreef op zaterdag 30 augustus 2014 @ 22:34:
[...]
Ik snap niet dat zoveel mensen JSON verkiezen BOVEN XML.
Beide hebben een hele ander soort toepassing!
Ik zie XML voornamelijk als de oudbollige variant (voorloper?) van JSON, toen we nog in de goede oude tijd van XML-RPC en SOAP leefden en je wel via XML moest communiceren omdat er simpelweg geen andere goede standaarden waren op dat moment. Ik heb niet lang geleden een applicatie gebouwd met JSON-RPC, waarbij clients in de browser middels CORS via XHR gestandaardiseerde requests doen naar een aparte JSON-RPC server. Heel erg vet, en zonder ook maar een letter code te hoeven schrijven om XML requests te moeten decoden. Het verbaast mij best wel hoe vaak er nog over XML-based systemen/oplossingen gesproken wordt, zelfs hier op GoT. Juist omdat er ook aan de serverkant nu echt hele slimme en makkelijke oplossingen zijn om data naar JSON om te gooien, zonder dat je XML documenten moet gaan zitten opbouwen.In de MEESTE gevallen kan ik wel begrijpen waarom JSON veel beter is, maar om te concluderen dat JSON > XML is mij een beetje te kort door de bocht!
Hoe je het ook wendt of keert: XML is passé en eigenlijk gewoon heel knullig/omslachtig om te implementeren, in ieder geval vergeleken met een relatief modern formaat als JSON.
In de Java EE wereld is het nog altijd de standaard manier van communicatie en daar zal weinig aan veranderen.
Ik ben zelf best wel van van JSON, maar voor betrouwbare communicatie is er weinig beter dan XML met een XSD.
Dat JSON schema kende ik niet, maar het ziet er juist er verbose uit en ik betwijfel of de validatie zo uitgebreid is als in een XSD.
JSON en XML zijn beide geschikt voor andere toepassingen en zullen daarom gewoon naast elkaar blijven bestaan tot er een betere oplossing komt.
Sommige dingen zijn nooit fatsoenlijk geweest...Douweegbertje schreef op zaterdag 30 augustus 2014 @ 22:02:
[...]
Dus omdat ik ooit een kwaliteitsproduct heb geleverd, moet ik 5 jaar later het helemaal opnieuw voor ze maken? Het is ooit van kwaliteit geweest, tijd heeft er voor gezorgd dat het niet meer fatsoenlijk is.
En als mensen jaarlijks licentiekosten betalen, dan lijkt me dat een van de verplichtingen is als leverancier dat die dingen met de tijd mee kunnen groeien. Niet per se dat je nieuwe features aanbiedt, maar wel dat je jezelf niet in een hoek geschilderd hebt waarbij je de features uberhaupt nooit kunt implementeren, omdat je basis beroerd is.
Da's dus een beetje het punt: als je het geld dat nu verdient wordt met ontieglijke bagger gewoon zou steken in behoorlijke ontwikkeling ipv ver overbetaalde consultants, dan zou het heel prima mogelijk zijn.Wie moet er voor betalen dan? Waar haal je de tijd even vandaan?
En als we als maatschappij gewoon gaan eisen dat dingen gewoon vanaf het begin min of meer goed gebouwd worden, dan zou dat een boel tijd en geld schelen.
Je verdraait mijn standpunt dan ook flink, want dat was niet wat ik beweerde.Het is iets te simpel om te redeneren dat als iets legacy is, dat je het maar opnieuw moet maken.
Sommige dingen hadden nooit geschreven mogen worden. En wat niet fout geschreven is, hoef je ook niet als legacy te supporten.
Niet echt op de bal wel? Maar nee, het probleem is niet dat ik er niet mee om kan gaan. Ik kan het wel. (En ik heb zelfs een behoorlijk betaald bijbaantje gehad waar ik handmatig zut moest converteren omdat de gigadure consultants dat niet konden.)Dat jij er misschien niet goed mee kan omgaan(irritant er in werken etc.) en dat eventuele dev tijd 30% hoger ligt maakt het nog niet broke.
Maar het is wel gigantische verspilling van al die zaken die nu als lapmiddel op lapmiddel worden gebouwd, steeds weer. Al die tijd gaat niet in vernieuwing en innovatie zitten, het is werkverschaffing, waarbij mensen veel geld verdienen met zwaar onderpresteren. En dat gebeurt dus ook in sectoren waar je het lef niet zou mogen hebben - waar het gemeenschapsgeld is dat met tonnen tegelijk naar de consultants verscheept wordt.
Frames, geen iframes. En nee, de applicatie bestaat minder lang dan je zou hopen. Maar belangrijkste: je betaalt ook nu nog gewoon geld. Geld voor iets dat gewoon niet meer behoorlijk voldoet.Als het gaat om 'nu', dat je nu een applicatie krijgt met een .txt als koppeling en iframes. Ok prima. De applicaties waar we het nu over hebben, zijn dingen die al jaren bestaan.
* incaz gaat ook maar eens van de bal af...zouden we pas over 1 jaar klaar zijn en dan is het eerste stukje wat we hebben herschreven al weer legacy.
Dan schrijf je wel beroerd slecht. Als je niet iets kunt coden dat wat langer meegaat dan een jaar, dan ben je toch geen goede programmeur? Goede separation of concerns, goeie loose coupling en behoorlijk geimplementeerde testing, en je hebt nauwelijks nog legacy code die moet blijven ondanks dat het bagger is - want zodra de noodzaak wegvalt kun je het vervangen door iets dat wel werkt. Zonder dat je hele applicatie in elkaar dondert.
Hoog tijd dat we eens wat meer kwaliteitseisen gaan stellen, Op dit moment storten devs hun fundering nog vol met puin en troep van de vorige bouwklus. Dat mag niet bij aannemers, laten we dat in dit vakgebied ook niet doen.
Never explain with stupidity where malice is a better explanation
En daar vergeet je even heel klein ding. De omvang van het project. Sorry maar wij kunnen onmogelijk de omvang van het project van Douweegbertje bepalen. We kunnen dus al helemaal niet bepalen of dat iets één jaar duurt om te refactoren.incaz schreef op zondag 31 augustus 2014 @ 10:33:
[...]
Dan schrijf je wel beroerd slecht. Als je niet iets kunt coden dat wat langer meegaat dan een jaar, dan ben je toch geen goede programmeur? Goede separation of concerns, goeie loose coupling en behoorlijk geimplementeerde testing, en je hebt nauwelijks nog legacy code die moet blijven ondanks dat het bagger is - want zodra de noodzaak wegvalt kun je het vervangen door iets dat wel werkt. Zonder dat je hele applicatie in elkaar dondert.
Hoog tijd dat we eens wat meer kwaliteitseisen gaan stellen, Op dit moment storten devs hun fundering nog vol met puin en troep van de vorige bouwklus. Dat mag niet bij aannemers, laten we dat in dit vakgebied ook niet doen.
Verder heeft een project altijd een bepaalde scope die je van te voren met de klant afspreekt.Het is een afweging of je de applicatie zo maakt dat hij in een later stadium makkelijk uitbreidbaar is of niet. Met die afweging is weer onze grote vriend geld gemoeid. Het is dus de vraag of dat de klant wil betalen voor extra toekomstige functionaliteit die er misschien nooit zal komen. Daarnaast is het natuurlijk ook nog zo dat wat nu mooie separation of concern code is of loose coupling code ( om maar een aantal standaard vaktermen te gebruiken ) of een mooie koppeling misschien over een jaar als complete rommel wordt gezien.
JSON bestaat nog niet zo heel erg lang maar wordt nu al door veel mensen de hemel in geprezen. Waarom? Omdat je zo verdomde makkelijk er mee kan werken en je de validatie layer van XML niet/nauwelijks beschikbaar is iets wat heel handig is want JSON is toch leesbaar? (
Daarnaast is het zo dat bij de applicatie waar het allemaal om begon, de rooster app, het misschien helemaal niet de bedoeling is geweest om hier extern mee te koppelen. Dat iemand er voor kiest om dat dat dan wel te doen is de fout van die persoon en niet van de maker. immers een externe koppeling zat niet in de scope van het project en is dus ook nooit als zodanig gemaakt.
[ Voor 15% gewijzigd door Webgnome op 31-08-2014 10:55 . Reden: Verklaringen hier en daar ]
Verwijderd
Nee hoor, PHP heeft best slimme XML-related dingen. Alleen is en blijft het gewoon omslachtig vergeleken met een JSON object opbouwen.Tacow schreef op zondag 31 augustus 2014 @ 10:13:
Het feit dat PHP geen handige XML ondersteuning heeft, betekent niet dat het in andere talen ook zo omslachtig is om XML te implementeren.
Het is oubollig (zonder d) en betekent misschien niet helemaal wat jij denkt dat het betekentVerwijderd schreef op zondag 31 augustus 2014 @ 08:02:
Ik zie XML voornamelijk als de oudbollige variant (voorloper?) van JSON
Het vervelende van XML tov json vind ik vooral:Hoe je het ook wendt of keert: XML is passé en eigenlijk gewoon heel knullig/omslachtig om te implementeren, in ieder geval vergeleken met een relatief modern formaat als JSON.
• Verbose
• Geen datatypes (alles is een string)
• Ambigu - gebruik je attributes of data nodes voor je content?
Nou heeft json ook wel zijn nadelen
• Officieel ondersteunt het geen comments
• Het gebruik van delimiters (de komma in objects en arrays) zorgt vaak voor fouten als je met de hand dingen aanpast (zoals het verwijderen van het laatste element in de array, en vergeten de komma op de vorige regel te verwijderen).
Ik heb beide issues overigens opgelost in mijn eigen json parser - eindigen met een komma is dan gewoon geen probleem meer, net als in C(++).
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
.oisyn schreef op zondag 31 augustus 2014 @ 11:23:
Het vervelende van XML tov json vind ik vooral:
• Geen datatypes (alles is een string)

Stringly-typed programming
Maar geeft je parser wel een warning, o.i.d.? Als je namelijk een JSON vervolgens ergens anders heen stuurt, zou het daar fout kunnen gaan namelijk.Ik heb beide issues overigens opgelost in mijn eigen json parser - eindigen met een komma is dan gewoon geen probleem meer, net als in C(++).
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Verwijderd
• Comments in data? Huh? Daar hebben we toch XSD danwel JSON-Schema voor, om te documenteren?.oisyn schreef op zondag 31 augustus 2014 @ 11:23:
Nou heeft json ook wel zijn nadelen
• Officieel ondersteunt het geen comments
• Het gebruik van delimiters (de komma in objects en arrays) zorgt vaak voor fouten als je met de hand dingen aanpast (zoals het verwijderen van het laatste element in de array, en vergeten de komma op de vorige regel te verwijderen).
• Vind ik geen argument. In XML kan je net zo goed vergeten om een element af te sluiten, of een element verkeerd af te sluiten. Structurele validiteit en het moeten gebruiken van correcte syntax is juist een voordeel, geen nadeel.
Overigens heb je dan een parser geschreven die non-standard JSON dus vreet. Een komma aan het einde van een array mag weliswaar in Javascript (althans, mits je niet <IE9 gebruikt), maar in JSON zeer zeker niet.
[ Voor 15% gewijzigd door Verwijderd op 31-08-2014 11:39 ]
Let op: Mijn post bevat meningen, aannames of onwaarheden
Tijdens het developpen kan 't wel handig zijn? Voorbeeld:Verwijderd schreef op zondag 31 augustus 2014 @ 11:35:
[...]
• Comments in data? Huh? Daar hebben we toch XSD danwel JSON-Schema voor, om te documenteren?
1
2
3
4
| { "server": "localhost:8000" /* for testing only */ // "server": "altaddr:1337" } |
Je kunt dan snel dingen wijzigen en testen.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
YAML, XML, ini; ondersteunen allemaal comments. JSON zie je echter niet vaak als config-file gebruikt worden, meer als een soort cross-platform data transfer. JSON is ook niet echt vriendelijk om met de hand te schrijven, gezien het vrij fout-gevoelig isRayNbow schreef op zondag 31 augustus 2014 @ 11:39:
[...]
Tijdens het developpen kan 't wel handig zijn? Voorbeeld:
JSON:
1 2 3 4 { "server": "localhost:8000" /* for testing only */ // "server": "altaddr:1337" }
Je kunt dan snel dingen wijzigen en testen.
Let op: Mijn post bevat meningen, aannames of onwaarheden
Verwijderd
1
2
3
4
5
| if (APPLICATION_ENV === 'development') { $data = json_encode(['server' => 'localhost:8080']); } else { $data = json_encode(['server' => 'my.awesome.server:1337']); } |
Ik zou echt _nooit_ gaan prutsen in data met comments. Iets met foutgevoeligheid enzo.
Handig als het programma gecompileerd is, en je wilt ontwikkelen op iemand anders computer die port 8080 al bezet heeft.Verwijderd schreef op zondag 31 augustus 2014 @ 11:41:
Of:
PHP:
1 2 3 4 5 if (APPLICATION_ENV === 'development') { $data = json_encode(['server' => 'localhost:8080']); } else { $data = json_encode(['server' => 'my.awesome.server:1337']); }
Ik zou echt _nooit_ gaan prutsen in data met comments. Iets met foutgevoeligheid enzo.
In zulke gevallen is het makkelijk dat de config in XML staat waardoor je zo even de server waarmee die moet verbinden kunt aanpassen.
Ik kan dat niet ontkennen dat sommige code van mensen/partijen slecht is en sure dat zou ook zeker verbetert moeten worden. Alleen kom ik echt weer terug op het feit dat dit heel lastig gaat worden. Dit heeft niets met iemand zijn programmeer skills te maken maar puur over hoe het bedrijfsleven werkt.incaz schreef op zondag 31 augustus 2014 @ 10:33:
[...]
Sommige dingen zijn nooit fatsoenlijk geweest...
En als mensen jaarlijks licentiekosten betalen, dan lijkt me dat een van de verplichtingen is als leverancier dat die dingen met de tijd mee kunnen groeien. Niet per se dat je nieuwe features aanbiedt, maar wel dat je jezelf niet in een hoek geschilderd hebt waarbij je de features uberhaupt nooit kunt implementeren, omdat je basis beroerd is.
[...]
Da's dus een beetje het punt: als je het geld dat nu verdient wordt met ontieglijke bagger gewoon zou steken in behoorlijke ontwikkeling ipv ver overbetaalde consultants, dan zou het heel prima mogelijk zijn.
En als we als maatschappij gewoon gaan eisen dat dingen gewoon vanaf het begin min of meer goed gebouwd worden, dan zou dat een boel tijd en geld schelen.
Dit gebeurt net zo goed in de bouw, als met het maken van auto's.
Lees simpelweg maar eens over wat bouwprojecten die uiteindelijk 5 jaar langer duurder en miljoenen euro's duurder kosten
Daarnaast zijn ontzettend veel huizen met een slechte fundering.. of andere 'verborgen' gebreken.
Los van dat gaat de tijd in de IT wereld enorm snel. Een stuk code wat ik één jaar geleden heb geschreven kan best voelen als legacy. Vaak genoeg het gevoel gehad: "Als ik het nu opnieuw zou maken zou ik het zo én zo doen"..
Maar goed, ik denk dat jij ervaring hebt met projecten waarbij je ziet dat een 3e partij en/of consult die 4x meer verdient als jouw ontzettende bagger aanlevert (ook al niet, dan toch even het volgende;
Hoewel ik je helemaal snap en je zeker gelijk geef op bepaalde punten wil ik toch zeggen dat het niet allemaal zo simpel is. Stel dat je een bedrijf hebt met alleen maar "incaz'en" qua 'gedachtegang' dan zou dat bedrijf niet lang bestaan. Dat heeft dan helemaal niets met kwaliteit te maken maar puur dat stukje bedrijfsvoering en de hardheid daarin.. Dat bedrijf zou het niet overleven.
Kun je eigenlijk naar PHP kijken heGamebuster schreef op zondag 31 augustus 2014 @ 11:38:
Ik bedenk me net... Browsers zullen altijd, van ieder blok HTML dat ze krijgen, een correcte pagina proberen te tonen. Hoe zou een programmeertaal en/of compiler eruit kunnen zien die bij iedere invoer, hoe correct of incorrect deze ook is, zal proberen een correct antwoord te geven?
tik hem zelf wel in
[ Voor 8% gewijzigd door Douweegbertje op 31-08-2014 12:56 ]
Ik snap niet helemaal wat ze ermee willen ook, want het is NL-software, maar de docs van die API zijn in het Engels en het is niet openbaar. Net zo min als de oude tekstbestanden openbaar zouden moeten zijn.koesie10 schreef op zondag 31 augustus 2014 @ 11:16:
Het systeem waar F.West het over heeft, wordt ook niet meer ondersteund en het bedrijf zelf erkent ook dat het niet ideaal is. Ze hebben een nieuw systeem ontwikkelt dat wel een normale API heeft dmv REST en JSON, alleen dat is nog een pilot jammer genoeg.
Overigens denk ik niet dat men snel zal overstappen naar het nieuwe systeem.
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Maar het begint door te blijven hameren dat rotzooi rotzooi is. Dat het niet aanvaardbaar is om allerlei best practices te negeren, zeker niet zodra je je software op grote schaal gaat verkopen. De lat wordt zo laag gelegd, en er zijn zo ontzettend veel mensen die precies uitleggen waarom we niks beters mogen verwachten of eisen, dat er nauwelijks verandering mogelijk is.Douweegbertje schreef op zondag 31 augustus 2014 @ 12:54:
[...]
Ik kan dat niet ontkennen dat sommige code van mensen/partijen slecht is en sure dat zou ook zeker verbetert moeten worden. Alleen kom ik echt weer terug op het feit dat dit heel lastig gaat worden.
Door te blijven hameren dat het veel beter kan - zonder significant meer kosten (en op middellange en lange termijn zelfs flink lagere kosten) kan dat besef een beetje doordringen. Maar het moet niet meer normaal zijn dat beroerde software wordt goedgepraat. (En dan denk ik bv ook aan de belastingdienst en de ov-chip en dergelijke zut. Ook de softwarewereld moet zo langzamerhand eens een beetje een standpunt innemen dat dat soort dingen niet nodig en niet aanvaardbaar zijn.)
En hoewel mijn denken vaak heel utopisch wordt gezien, blijkt het in de praktijk best mee te vallen, en gaat het vaak ook om vrij kleine dingen. Het is veel meer een houdingsomslag dan iets dat veel kost qua tijd en geld, en mijn pleidooi is niet om alles meteen op het hoogste niveau om te gooien, maar simpelweg het voornemen om goede grondslagen te nemen, programmeren volgens behoorlijke webstandaards, standaardbestandsformaten, redelijke principes, en dat je afwijkingen van dergelijke grondslagen pas doet als je kunt omschrijven waarom. Dan ben je al een heel eind. Het is wat dat betreft niet anders dan het aanhouden van simpele code standaarden zoals begrijpelijke variabelenamen, nette indenting en documenteren van 'why' als je iets onverwachts doet. Kost niet gigantisch veel tijd en moeite, als je het jezelf maar even aanwent en niet te makkelijk genoegen neemt met het niet doen. Daarmee krijg je een project als dat dramaroostergebeuren niet meer zomaar op de rit, maar dat soort applicaties mogen gewoon niet meer ontstaan tegenwoordig - die tijd is geweest en voorbij.
Never explain with stupidity where malice is a better explanation
Verwijderd
Eens met je hele verhaal hoor, maar vind je die mentaliteit écht gek? Dat past immers perfect bij ons genivelleerde onderwijs waarbij we inmiddels uitblinken in middelmatigheid. Het is echt te triest voor woorden.incaz schreef op zondag 31 augustus 2014 @ 14:27:
[...]
Maar het begint door te blijven hameren dat rotzooi rotzooi is. Dat het niet aanvaardbaar is om allerlei best practices te negeren, zeker niet zodra je je software op grote schaal gaat verkopen. De lat wordt zo laag gelegd, en er zijn zo ontzettend veel mensen die precies uitleggen waarom we niks beters mogen verwachten of eisen, dat er nauwelijks verandering mogelijk is.
* F.West98 kan niets vinden op Google
[ Voor 17% gewijzigd door F.West98 op 31-08-2014 15:10 ]
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Ja dat werkt prima in crappy phpVerwijderd schreef op zondag 31 augustus 2014 @ 11:41:
Of:
PHP:
1 2 3 4 5 if (APPLICATION_ENV === 'development') { $data = json_encode(['server' => 'localhost:8080']); } else { $data = json_encode(['server' => 'my.awesome.server:1337']); }
Ik zou echt _nooit_ gaan prutsen in data met comments. Iets met foutgevoeligheid enzo.
Nothing to see here!
Quick Return pattern
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
Quick return?F.West98 schreef op zondag 31 augustus 2014 @ 15:10:
Ik probeer zo'n balk te implementeren als in de FB/Twitter-apps die weggaat als je scrollt. Maar hoe noem je zoiets nou....
* F.West98 kan niets vinden op Google
iOS developer
Een nummer is gewoon een double precision floating pointBikkelZ schreef op zondag 31 augustus 2014 @ 15:20:
JSON en XML zuigen allebei precies even hard waarbij JSON wat minder bandbreedte gebruikt en je bij het ontbreken van dubbele quotes er van uit kan gaan dat er geen string bedoeld is (hopelijk) maar het blijft JavaScript dus "1" is een integer met de waarde 1. Of true. Soms? Meestal? En wat gebruik ik voor datums?
Datum is gewoon date toJson (dus gebruik je de js standaard..)
Boolean is domweg true of false
Dan heb je nog array, object en null
Ik snap niet helemaal wat je nu probeert te zeggen. Zolang je zelf maar je ding normaal doet is er helemaal niet zo veel mis met de datatypes..
Niet gek, wel verkeerd. Reden te meer om er dus steeds de aandacht op te blijven vestigen en niet toe te staan dat mensen het goedpraten of doen alsof het niet anders kan. Dat kan het wel. We kiezen ervoor om te doen alsof het onveranderlijk en noodzakelijk is.Verwijderd schreef op zondag 31 augustus 2014 @ 15:00:
[...]
Eens met je hele verhaal hoor, maar vind je die mentaliteit écht gek? Dat past immers perfect bij ons genivelleerde onderwijs waarbij we inmiddels uitblinken in middelmatigheid. Het is echt te triest voor woorden.
Overigens is de inrichting van ons onderwijs eerder een gevolg van dezelfde mentaliteit dan de oorzaak. Al houdt het elkaar ook in stand.
(Maar in dit specifieke probleem, slechte softwarekwaliteit, is een van de problemen dat veel developers neerkijken op saaie kwaliteitsstandaarden. Dat mensen liever creatieve en elegante code schrijven dan robuste en degelijke, en veel liever een idee hebben dan de saaie details uit te werken. Daar is dus eerder meer saaie middelmatigheid nodig dan meer (ongeleide) excellentie.)
Never explain with stupidity where malice is a better explanation
Verwijderd
BikkelZ schreef op zondag 31 augustus 2014 @ 15:20:
JSON en XML zuigen allebei precies even hard waarbij JSON wat minder bandbreedte gebruikt en je bij het ontbreken van dubbele quotes er van uit kan gaan dat er geen string bedoeld is (hopelijk) maar het blijft JavaScript dus "1" is een integer met de waarde 1. Of true. Soms? Meestal? En wat gebruik ik voor datums?
Iets met dubbele quotes = string. Getal zonder dubbele quotes = getal. Boolean = boolean. Snap het probleem wat je schetst niet zo.
En voor datums gebruikt iedereen toch hopelijk gewoon ISO-8601 of een ander gestandaardiseerd formaat?
Als het je te doen is om json die met de hand te bewerken moet zijn kun je misschien beter yaml gebruiken, dat is een superset van json die onder andere trailing comma's toestaat, inline comments ondersteunt, en over het algemeen leesbaardere syntaxes ondersteunt (zoals een markdown-achtige notatie voor lists en dictionaries)..oisyn schreef op zondag 31 augustus 2014 @ 11:23:
Nou heeft json ook wel zijn nadelen
• Officieel ondersteunt het geen comments
• Het gebruik van delimiters (de komma in objects en arrays) zorgt vaak voor fouten als je met de hand dingen aanpast (zoals het verwijderen van het laatste element in de array, en vergeten de komma op de vorige regel te verwijderen).
Is dat nou wel zo verstandig? Als er een trailing comma in zit is het geen geldige JSON, en dan kan je parser het dus beter wijgeren. Of hebben we nou niets geleerd van HTML de afgelopen 20 jaar?Ik heb beide issues overigens opgelost in mijn eigen json parser - eindigen met een komma is dan gewoon geen probleem meer, net als in C(++).
Oeps, mooie spuit 11
[...]
• Comments in data? Huh? Daar hebben we toch XSD danwel JSON-Schema voor, om te documenteren?
Ja comments in data ja.
Dan snap je niet wat ik bedoel. In XML kun je bijvoorbeeld gewoon een element toevoegen of verwijderen zonder dat je daarvoor omliggende regels hoeft aan te passen.Vind ik geen argument. In XML kan je net zo goed vergeten om een element af te sluiten, of een element verkeerd af te sluiten.
1
2
3
4
5
| [ "aap", "noot", "mies" ] |
Regel 4 uitcommenten of verwijderen, en je json is niet meer valid. Vervolgens haal je ook de komma op regel 3 weg, maar als je dan later regel 4 weer uncomment dan heb je weer een probleem als je de komma niet terugplaatst. Met XML heb je dat niet:
1
2
3
4
5
| <items> <item>aap</item> <item>noot</item> <item>mies</item> </items> |
En het grappige is dat het in javascript zelf dus wel gewoon mag: [1,2,3,] is valide JS syntax.
No shit sherlock. Maar die syntax kun je aanpassen om het toe te staan. Dan heb je dus een andere syntax, maar nog steeds een welldefined syntax die je kunt documenteren enzo.Structurele validiteit en het moeten gebruiken van correcte syntax is juist een voordeel, geen nadeel.
Klopt, maar in mijn geisoleerde case komt het héél vaak voor dat je even wat dingen wilt verwijderen of uitcommenten. Voor interactie met andere systemen is het idd niet bijzonder handig, en by default staat die optie dan ook uit.Overigens heb je dan een parser geschreven die non-standard JSON dus vreet. Een komma aan het einde van een array mag weliswaar in Javascript (althans, mits je niet <IE9 gebruikt), maar in JSON zeer zeker niet.
[ Voor 14% gewijzigd door .oisyn op 31-08-2014 16:59 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wikipedia: Robustness principledeadinspace schreef op zondag 31 augustus 2014 @ 16:27:
Is dat nou wel zo verstandig? Als er een trailing comma in zit is het geen geldige JSON, en dan kan je parser het dus beter wijgeren. Of hebben we nou niets geleerd van HTML de afgelopen 20 jaar?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Bij die laatste regel gaat het dus al fout. Waarom maak je hier de aanname dat de data gegenereerd is?Verwijderd schreef op zondag 31 augustus 2014 @ 16:59:
Comments in data, het aanpassen van (gestandaardiseerde) syntax, even snel dingen wijzigen in data (waarom niet de routine aanpassen die de data genereert?)
Wat betreft die comments in data, jij mag eens uit gaan leggen waarom dat niet robuust zou zijn.
[ Voor 11% gewijzigd door .oisyn op 31-08-2014 17:02 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Dus jij schrijft handmatig XML? Voor configuratiebestanden en dergelijke zou ik het wel snappen (alhoewel.. daar heb je weer betere formaten zoals .ini voor), maar ik mag hopen dat de meeste XML waar je mee werkt gewoon automatisch uit een scriptje rolt. Zeker met zo'n strikt formaat als XML lijkt het mij niet echt relaxed om met de hand in te gaan werken, zeker als het een wat groter document betreft..oisyn schreef op zondag 31 augustus 2014 @ 17:01:
[...]
Bij die laatste regel gaat het dus al fout. Waarom maak je hier de aanname dat de data gegenereerd is?
Ik zou de documentatie van een datastructuur juist los houden van de intrinsieke data zelf, en niet de twee gaan samenvoegen in één file. Er bestaat in het geval van XML niet voor niets iets als XSD, wat precies daarvoor bedoeld is. Als je een documentatie van ergens van wilt aanpassen, is het toch veel beter om dat te kunnen doen zonder dat je daadwerkelijk code/data mogelijkerwijs sloopt?.oisyn schreef op zondag 31 augustus 2014 @ 17:01:
Wat betreft die comments in data, jij mag eens uit gaan leggen waarom dat niet robuust zou zijn.
[ Voor 32% gewijzigd door Verwijderd op 31-08-2014 17:07 ]
Nee, JSON.
Dat is het dus precies.Voor configuratiebestanden en dergelijke zou ik het wel snappen
Sorry maar dit slaat werkelijk waar nergens op. INI beter dan een gestructureerd formaat zoals JSON en XML?(alhoewel.. daar heb je weer betere formaten zoals .ini voor)
Je kijk op development is hopeloos beperkt. Vrij veel mensen typen rechtstreeks XML. Neem bijvoorbeeld (X)HTML en XAML.maar ik mag hopen dat de meeste XML waar je mee werkt gewoon automatisch uit een scriptje rolt
En wederom denk je te beperkt. Waarom zou je je datastructuur gaan commenten in de JSON zelfVerwijderd schreef op zondag 31 augustus 2014 @ 17:03:
Ik zou de documentatie van een datastructuur juist los houden van de intrinsieke data zelf
[ Voor 36% gewijzigd door .oisyn op 31-08-2014 17:16 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Nee, maar dat stel ik ook nergens. Alleen is het nogal raar om configuratiebestanden in markup of JSON op te bouwen, aangezien dat daar helemaal niet voor bedoeld is. Configuratie/initialisatie van applicaties horen in een INI bestand thuis, juist omdat daar geen sprake is van allerlei syntax-gerelateerde obstakels of het al dan niet kunnen plaatsen van comments..oisyn schreef op zondag 31 augustus 2014 @ 17:07:
Sorry maar dit slaat werkelijk waar nergens op. INI beter dan een gestructureerd formaat zoals JSON en XML?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| [development] ; Database db.name = "mydb" db.user = "dbuser" db.password = "mypass" ; Allowed methods allowed.methods[] = "method_1" allowed.methods[] = "method_2" ; allowed.methods[] = "method_3" ; Commented out for now [production] ; Database db.name = "my_prod_db" db.user = "produser" db.password = "mypass123" ; Allowed methods allowed.methods[] = "method_4" |
Maargoed. Als jij het jezelf zo moelijk mogelijk wil maken door een dataformaat ergens voor te gebruiken waar het juist nét niet voor bedoelt is: ga gerust je gang.
Volgens mij is (X)HTML in deze context niet zo relevant, los van de (overduidelijke) verschillen in syntax, striktheid, doeleinden, enzovoort.Vrij veel mensen typen rechtstreeks XML. Neem bijvoorbeeld (X)HTML en XAML.
Jammer dat je op de man speelt. Hier laat ik het dan ook bij, als je het niet erg vind.Je kijk op development is hopeloos beperkt.
Eigenlijk is dat een drogredenatie van jewelste. De vraag is of het handig is. Of het ervoor bedoeld is is van ondergeschikt belang. Bovendien zou ik het nogal knap vinden als jij kunt aantonen dat het inderdaad niet de bedoeling was om configbestanden er mee te gaan opstellen. Het "human-editable" gedeelte van zowel XML als JSON is nogal een belangrijk punt.Verwijderd schreef op zondag 31 augustus 2014 @ 17:20:
Alleen is het nogal raar om configuratiebestanden in markup of JSON op te bouwen, aangezien dat daar helemaal niet voor bedoeld is.
Het feit dat er niet echt een structuur mogelijk is in .ini is nogal een beperking op zich.Configuratie/initialisatie van applicaties horen in een INI bestand thuis, juist omdat daar geen sprake is van allerlei syntax-gerelateerde obstakels of het al dan niet kunnen plaatsen van comments.
En dan nu een array van objecten.INI:
1 2 3 allowed.methods[] = "method_1" allowed.methods[] = "method_2" ; allowed.methods[] = "method_3" ; Commented out for now
Nogmaals, je redeneert in dogma'sMaargoed. Als jij het jezelf zo moelijk mogelijk wil maken door een dataformaat ergens voor te gebruiken waar het juist nét niet voor bedoelt is: ga gerust je gang.
Ik zie niet in waarom. Blijkbaar zijn gigantisch veel mensen in staat dagelijks XML of een afgeleide daarvan te tikken, maar ondertussen hoop je "dat de meeste XML waar ik mee werk uit een scriptje rolt". Sorry maar dat is gewoon niet echt reëel.Volgens mij is (X)HTML in deze context niet zo relevant, los van de (overduidelijke) verschillen in syntax, striktheid, doeleinden, enzovoort.
Tja, jammer dat jij het "op de man spelen" vindt. Maar vooralsnog lijk je expres verkeerde voorbeelden te verzinnen om het gebruik van een concept in het algemeen te diskwalificeren. En zie het vorige punt.Jammer dat je op de man speelt. Hier laat ik het dan ook bij, als je het niet erg vind.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Problem solved EN een standaard.
Maar dat 'liberal in what you accept' is al meerdere keren heroverwogen, en blijkt helemaal niet zo'n goed principe te zijn. Het leidt tot behoorlijk wat undefined behavior waar de hele chain vervolgens van afhangt, en zeer obscure bugs, die makkelijk voorkomen hadden kunnen worden als je de boel gewoon aan alle kanten door een standaard validator haalt. Robustness is veel vaker dat je goede libs gebruikt, goede standaarden, fouten vroeg opspoort en zeer specifiek throwt en duidelijk vermeldt (niet 'an error occurred'), en dat je helemaal niet zo liberal bent.
Maar goed, om op een eerdere vraag terug te komen. Nee, we hebben niets geleerd van al die wtf's waaronder html en browserdrama's, en men wil het niet leren ook, dat is duidelijk.
Never explain with stupidity where malice is a better explanation
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik heb ongeveer dezelfde kritiek op JSON maar het jammere is dat je nu dus niet eenvoudig meer los-staande applicaties kunt maken die met dezelfde data werken..oisyn schreef op zondag 31 augustus 2014 @ 17:53:
Maar oh wee als je daar iets over zegt, want dan krijg je een berg van onpragmatische theoristen over je heen
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Ik hoef ook echt geen purist te zijn om het purist zijn (hell, ik schrijf mijn openingsaccolades in javascript op dezelfde regel en in php op de volgende regel! Hoe flexibel wil je het hebben!), maar ik heb zo ontzettend vaak gezien dat verbetering / nieuwe feature x niet kan worden geimplementeerd omdat "ja, nee, je zou denken dat dat makkelijk is omdat je het al als xml/json/csv hebt en je het dus makkelijk kunt importeren, alleen het is geen standaard xml/json/csv, dus we zitten vast aan onze legacy parser en dus kan het niet."
En DAT stoort me. Als die slechte bestandsformaten en eigen implementaties geen gevolgen zouden hebben, en niemand er wat mee te maken zou hebben, dan zou ik me er ook niet echt druk om maken. Maar het gebeurt wel, echt heel vaak, en dat hindert de ontwikkeling en innovatie en dat vind ik niet goed te praten.
Never explain with stupidity where malice is a better explanation
Ja, het volgende op de agenda is geloof ik static declarations.Douweegbertje schreef op zondag 31 augustus 2014 @ 19:25:
Hadden we de XML / JSON discussie nou al eens eerder gehad?
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Verwijderd
Firesphere schreef op zondag 31 augustus 2014 @ 19:25:
[...]
Ja, het volgende op de agenda is geloof ik static declarations.
[ Voor 59% gewijzigd door Verwijderd op 31-08-2014 19:26 ]
Anders bouwen we er even een schema op? Elke keer dat Tesla mauwt, schakelen we naar het volgende onderwerp.Ealanrian schreef op zondag 31 augustus 2014 @ 19:34:
Het zou best handig zijn als we alle discussies op volgorde houden. Dan kan je je horloge er op gelijk zetten
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Dit topic is gesloten.
![]()
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.