De Devschuur Coffee Corner - Iteratie 7 Vorige deel Overzicht Volgende deel Laatste deel

Dit topic is onderdeel van een reeks. Ga naar het meest recente topic in deze reeks.

Pagina: 1 ... 21 ... 101 Laatste
Acties:
  • 279.343 views

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

F.West98 schreef op vrijdag 29 augustus 2014 @ 21:34:
[...]

Dit probleem is geen issue die je normaal zou merken in het gebruik, dat is gewoon weergeven van de informatie.
Ik probeer echter intelligentie toe te voegen en wijzigingen te detecteren... Dat lukt dus gewoon niet :(
....
I will not be a sarcastic asshole
I will not be a sarcastic asshole
I will not be a sarcastic asshole

Aww fuck it.

Jij?

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!


  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50

BikkelZ

CMD+Z

Ach.

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


Verwijderd

"Super anale gronden" is er in ieder geval een die zo de analen der Coffeecorner in kan :)

  • Matis
  • Registratie: Januari 2007
  • Laatst online: 03-11 19:19

Matis

Rubber Rocket

Uit zijn 16 jaren levenservaring.

If money talks then I'm a mime
If time is money then I'm out of time


Verwijderd

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 :(
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?

  • Ryur
  • Registratie: December 2007
  • Laatst online: 21:26
Algemene voorwaarden voor het vervoer van Reizigers en Handbagage van de Nederlandse Spoorwegen (AVR-NS) geïnformeerd te worden via ns.nl/voorwaarden
(Uit de algemene voorwaarden van NS met het afsluiten van een product bij ze, Traject vrij bij mij).

Zou deze geschreven zijn door een mede-tweaker? O-)

  • Robbiedobbie
  • Registratie: Augustus 2009
  • Laatst online: 17:02
[bitchmode]Ik zie de NS er wel voor aan om een willekeurige middelbare scholier hun systemen in elkaar te laten flansen :+[/bitchmode]

Ghehe, maaruhm, wanneer gaan we eens stoppen met F.West zo te pesten? :)

  • Kobus Post
  • Registratie: September 2010
  • Laatst online: 21-10 15:46
Lekker dan, kom ik vanochtend in de studio om techniek te doen, is het verdacht stil. Ligt er een hele aardlekgroep uit, waaronder ook de servergroep. Alles weer draaiend gekregen, blijkt er een HDD te zijn overleden, gelukkig wel uit een RAID opstelling, dus geen data verlies. Nu eerst koffie!

No trees were harmed in the creation of this message, but several thousand electrons were mildly inconvenienced.


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

Robbiedobbie schreef op zaterdag 30 augustus 2014 @ 11:54:
Ghehe, maaruhm, wanneer gaan we eens stoppen met F.West zo te pesten? :)
Waarom zouden we daar ooit mee stoppen? >:)

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.


  • Chris7
  • Registratie: Maart 2011
  • Niet online
.oisyn schreef op zaterdag 30 augustus 2014 @ 12:12:
[...]

Waarom zouden we daar ooit mee stoppen? >:)
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 :P.

  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

Verwijderd 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?
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 :

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


  • Kobus Post
  • Registratie: September 2010
  • Laatst online: 21-10 15:46
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 :
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 8)7

No trees were harmed in the creation of this message, but several thousand electrons were mildly inconvenienced.


  • Ryur
  • Registratie: December 2007
  • Laatst online: 21:26
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 8)7
Bij mijn HBO opleiding stond vroeger alles openbaar (gewoon op onze academiesite). Zowel de sheets van de lessen, als de blokboeken en de toetsuitslagen.

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).

  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

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 8)7
Tja. Op deze bestanden zit normaal ook een .htaccess bestand, maar ze draaien IIS.
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


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

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 :
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.

  • farlane
  • Registratie: Maart 2000
  • Laatst online: 09:51
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.......
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.

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.


  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
Nou ja, het is ook gewoon behoorlijk beroerd design van de software natuurlijk. Het is natuurlijk zo dat je niet zoveel mogelijkheden hebt om iets te eisen bij externe software waar je geen invloed op hebt, en ja, het leert je de helaas veel te belangrijke les dat je NOOIT ergens op kunt vertrouwen, maar het is toch echt ook ondubbelzinnig een beroerd opgezet systeem. Laten we de dingen wel juist blijven benoemen :)

Never explain with stupidity where malice is a better explanation


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

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.

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

Toch niet voor niets Java 5 gestudeerd!
Afbeeldingslocatie: http://i.imgur.com/zO6Yy7f.jpg

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!


  • Rutix
  • Registratie: Augustus 2009
  • Laatst online: 05-09-2024
Firesphere schreef op zaterdag 30 augustus 2014 @ 17:52:
Toch niet voor niets Java 5 gestudeerd!
[afbeelding]
uh wat ik keek meer naar het plaatje op je beeldscherm :+

Nothing to see here!


Verwijderd

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.......
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.
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.
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. :)

[ Voor 28% gewijzigd door Verwijderd op 30-08-2014 18:35 ]


  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

Rutix schreef op zaterdag 30 augustus 2014 @ 18:26:
[...]

uh wat ik keek meer naar het plaatje op je beeldscherm :+
Deze?
Afbeeldingslocatie: http://tweakers.net/ext/f/1cim4q8G2dwjaWfrdyUTjCIN/medium.jpg

Ik probeerde troep op m'n bureau buiten beeld te houden, die achteraf gezien inderdaad wel een *kuch*interessant*kuch* perspectief opleverde :D

Ik merk aan je spellings-skills dat je enigszins was afgeleid trouwens :P

[ 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!


  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

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.
Nope. Vaak genoeg geprobeerd, maar niet betrouwbaar te krijgen door menselijke invoer-fouten van de roostermaker.
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....
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.
Als ik de PHP-site source bekijk (te downloaden op internet..) wordt bij het verwerken van de data dat veld wel mooi 'id' genoemd....

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 O-)
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 O-)

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


  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
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 imagemaps |:( om 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.

Never explain with stupidity where malice is a better explanation


  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

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 imagemaps |:( om 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.
Niets mis met een goede XML of een goed gedocumenteerde TXT.

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!


  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
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.)
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


  • RayNbow
  • Registratie: Maart 2003
  • Laatst online: 20:21

RayNbow

Kirika <3

Dan is het waarschijnlijk niet TXT? :p

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

RayNbow schreef op zaterdag 30 augustus 2014 @ 19:24:
[...]

Dan is het waarschijnlijk niet TXT? :p
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!


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

Ik denk dat hij doelt op 'documentatie in het txt" oftewel eigenlijk xml.. en daarom zou het dan geen txt zijn. Jij bedoelt gewoon documentatie in de zin van': 'line 1 is x, gevolgd door 5 lines y etc.

  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

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 imagemaps |:( om 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.
Helemaal mee eens :)

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


  • RayNbow
  • Registratie: Maart 2003
  • Laatst online: 20:21

RayNbow

Kirika <3

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.
Als de content XML is, dan is het dus XML, niet willekeurige plain text. ;)

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

RayNbow schreef op zaterdag 30 augustus 2014 @ 19:31:
[...]

Als de content XML is, dan is het dus XML, niet willekeurige plain text. ;)
Als die XML in een txt is gepropt, is de parsing wel iets anders, dus ja, het is anders ;)

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!


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

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... :?

  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

Ik doelde vooral op de laatste twee regels :)
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


  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
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.
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.

Never explain with stupidity where malice is a better explanation


  • Alex)
  • Registratie: Juni 2003
  • Laatst online: 30-10 15:32
F.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?)
Één vinkje in IIS :)
Maar als je de source downloadt is het ook best 'slechte' code, variabele namen als $hetRoosterDatIkMoetTonen, $waarde = magIkDitRoosterTonen($hetRoosterDatIkMoetTonen) == "Ja";
Een beetje verbose, en die "Ja" is ook mooi :D

We are shaping the future


  • Martijn19
  • Registratie: Februari 2012
  • Laatst online: 28-07 12:47
F.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";
Het zijn tenminste nog omschrijvende namen :D

  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
Sebazzz schreef op zaterdag 30 augustus 2014 @ 20:43:
[...]

Wat is er mis met image maps?
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.

HTML:
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">
      &nbsp;
    </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

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 ;)
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.


PHP:
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?

Cascading Stylesheet:
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 ]


  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

Martijn19 schreef op zaterdag 30 augustus 2014 @ 20:43:
[...]


Het zijn tenminste nog omschrijvende namen :D
Dat kan je niet ontkennen nee :)

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


  • ZaZ
  • Registratie: Oktober 2002
  • Laatst online: 03-11 00:19

ZaZ

Tweakers abonnee

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.
Xml is helemaal niet altijd zinloos want json kan helemaal niet hetzelfde als xml.
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


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

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.
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?
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.

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 18:54
Ik vermoed dat jullie niet broke bedoelen maar broken?

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

VT van break.
mja, misschien hier en daar wel broken ipv broke :+

[ Voor 67% gewijzigd door Douweegbertje op 30-08-2014 22:20 ]


  • _David_
  • Registratie: Februari 2011
  • Laatst online: 05-11 20:39

_David_

FP ProMod

llama llama duck

Nieuwe berichten functie werkt in dit topic niet meer voor mij :X

ReferenceError: aopen is not defined in Firebug 8)7

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.


  • Ryur
  • Registratie: December 2007
  • Laatst online: 21:26
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.)
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

[ Voor 5% gewijzigd door Ryur op 30-08-2014 22:49 ]


  • dcm360
  • Registratie: December 2006
  • Niet online

dcm360

Moderator Discord

HD7767 powered

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?
Ja, je kan ook data valideren met JSON.

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

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
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.

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. 8)7

  • Megamind
  • Registratie: Augustus 2002
  • Laatst online: 10-09 22:45
Beter dan een collega die het leuk vond om webservices met elkaar te laten praten via formcollections :P

  • Rutix
  • Registratie: Augustus 2009
  • Laatst online: 05-09-2024
Wij moeten vaak koppelen met andere systemen en dan heb je vaak niet eens de keus voor JSON omdat de andere partij of XML verwacht of al aanlevert. :)

Nothing to see here!


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

nieuws: Toetsenbordgebruik kan verraden hoe iemand zich voelt

no shit. Moet je maar eens bij ons op de vloer zitten :+ BATS BATS BATS..
Sowieso thuis nog 10 stuks liggen van die oude OEM dingen die ik dan lekker kapot kan slaan oOo

Verwijderd

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!
Euh, hoezo? Wat kan je nou niet met JSON, wat je wel met XML kan?
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!
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.
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.

  • Tacow
  • Registratie: Oktober 2005
  • Laatst online: 04-11 21:45
Het feit dat PHP geen handige XML ondersteuning heeft, betekent niet dat het in andere talen ook zo omslachtig is om XML te implementeren.

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.

  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
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.
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.
Wie moet er voor betalen dan? Waar haal je de tijd even vandaan?
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.
Het is iets te simpel om te redeneren dat als iets legacy is, dat je het maar opnieuw moet maken.
Je verdraait mijn standpunt dan ook flink, want dat was niet wat ik beweerde. :)

Sommige dingen hadden nooit geschreven mogen worden. En wat niet fout geschreven is, hoef je ook niet als legacy te supporten.
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.
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.)

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.
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.
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.
zouden we pas over 1 jaar klaar zijn en dan is het eerste stukje wat we hebben herschreven al weer legacy.
* incaz gaat ook maar eens van de bal af...
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


  • Webgnome
  • Registratie: Maart 2001
  • Laatst online: 19:22
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.
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.

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? ( 8)7 ).

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 ]

Strava | AP | IP | AW


  • koesie10
  • Registratie: Mei 2011
  • Niet online
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.

Verwijderd

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.
Nee hoor, PHP heeft best slimme XML-related dingen. Alleen is en blijft het gewoon omslachtig vergeleken met een JSON object opbouwen. :P

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op zondag 31 augustus 2014 @ 08:02:
Ik zie XML voornamelijk als de oudbollige variant (voorloper?) van JSON
Het is oubollig (zonder d) en betekent misschien niet helemaal wat jij denkt dat het betekent ;). Het is niet gewoon een synoniem van ouderwets, al krijgt het die betekenis wel steeds meer (leesvoer)
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.
Het vervelende van XML tov json vind ik vooral:
• 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.


  • RayNbow
  • Registratie: Maart 2003
  • Laatst online: 20:21

RayNbow

Kirika <3

.oisyn schreef op zondag 31 augustus 2014 @ 11:23:
Het vervelende van XML tov json vind ik vooral:
• Geen datatypes (alles is een string)
Afbeeldingslocatie: http://i.imgur.com/jkEQtMk.jpg

Stringly-typed programming *O*
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(++).
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.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


Verwijderd

.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).
• Comments in data? Huh? Daar hebben we toch XSD danwel JSON-Schema voor, om te documenteren? ;)
• 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. :P

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 ]


  • Gamebuster
  • Registratie: Juli 2007
  • Laatst online: 23-10 08:50
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?

Let op: Mijn post bevat meningen, aannames of onwaarheden


  • RayNbow
  • Registratie: Maart 2003
  • Laatst online: 20:21

RayNbow

Kirika <3

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? ;)
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. :p

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Gamebuster
  • Registratie: Juli 2007
  • Laatst online: 23-10 08:50
RayNbow 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. :p
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 is

Let op: Mijn post bevat meningen, aannames of onwaarheden


Verwijderd

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.

  • Ryur
  • Registratie: December 2007
  • Laatst online: 21:26
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.
Handig als het programma gecompileerd is, en je wilt ontwikkelen op iemand anders computer die port 8080 al bezet heeft.
In zulke gevallen is het makkelijk dat de config in XML staat waardoor je zo even de server waarmee die moet verbinden kunt aanpassen.

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

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.
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.
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 :F . Duizenden auto's die weer terug geroepen worden omdat ze niet werken...
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; :P ). Of in elk geval weet ik helaas zelf ook dat dit soort dingen bestaan.. Wat ik in elk geval bedoel te zeggen is dat het niet per definitie is dat dingen slecht zijn of waren. Meestal kon het niet anders door welke factoren dan ook, en een aantal keren zit er gewoon een partij te kloten met ontzettend slechte meuk.

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.
Gamebuster 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?
Kun je eigenlijk naar PHP kijken he :) Daar kan haast alles *O*
tik hem zelf wel in :Y

[ Voor 8% gewijzigd door Douweegbertje op 31-08-2014 12:56 ]


  • StM
  • Registratie: Februari 2005
  • Laatst online: 15:51

StM

Ik zou eerder JavaScript noemen. 6 chars is voldoende om ieder script mee te schrijven: http://www.jsfuck.com/

  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

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.
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.
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


  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
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.
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.

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

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.
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.

  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

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 :P

[ 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


  • Rutix
  • Registratie: Augustus 2009
  • Laatst online: 05-09-2024
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.
Ja dat werkt prima in crappy php :P maar niet in gecompileerde talen. Daarnaast wil ik helemaal geen code file aanpassen om iets te veranderen. Daarnaast zijn comments in bijvoorbeeld stub bestanden gewoon handig om sommige dingen te documenteren zodat je na zoveel maanden niet vergeet waarom ook weer.

Nothing to see here!


  • F.West98
  • Registratie: Juni 2009
  • Laatst online: 31-10 03:36

F.West98

Alweer 16 jaar hier

Aha.
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


  • koesie10
  • Registratie: Mei 2011
  • Niet online
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 :P
Quick return?

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50

BikkelZ

CMD+Z

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? O-)

iOS developer


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

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? O-)
Een nummer is gewoon een double precision floating point
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..

  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
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.
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.

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? O-)
:?

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?

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 06-11 14:38

deadinspace

The what goes where now?

.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).
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).
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(++).
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?

Oeps, mooie spuit 11 :+

  • Martindo
  • Registratie: November 2010
  • Laatst online: 24-10 11:15
Hmm, misschien dat ik binnenkort maar weer eens een nieuwe versie van mijn portfoliopagina ga bouwen. Dat domein ligt ook nog steeds stil.

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

[quote]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? ;)
Ja comments in data ja.
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.
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.
JSON:
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:
XML:
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.
Structurele validiteit en het moeten gebruiken van correcte syntax is juist een voordeel, geen nadeel. :P
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.
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.
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.

[ 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.


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

deadinspace 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?
Wikipedia: Robustness principle

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

Comments in data, het aanpassen van (gestandaardiseerde) syntax, even snel dingen wijzigen in data (waarom niet de routine aanpassen die de data genereert?).. Klinkt alles behalve robuust. :) :+

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

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?)
Bij die laatste regel gaat het dus al fout. Waarom maak je hier de aanname dat de data gegenereerd is?

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

.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?
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:
Wat betreft die comments in data, jij mag eens uit gaan leggen waarom dat niet robuust zou zijn.
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?

[ Voor 32% gewijzigd door Verwijderd op 31-08-2014 17:07 ]


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op zondag 31 augustus 2014 @ 17:03:
[...]


Dus jij schrijft handmatig XML?
Nee, JSON. :Y)
Voor configuratiebestanden en dergelijke zou ik het wel snappen
Dat is het dus precies.
(alhoewel.. daar heb je weer betere formaten zoals .ini voor)
Sorry maar dit slaat werkelijk waar nergens op. INI beter dan een gestructureerd formaat zoals JSON en XML? :D Hoe definieer jij arrays en objecten in een .ini file? Met allemaal losse sections oid? Nee dat is lekker duidelijk :). Kom dan met het eerder genoemde YAML als voorbeeld. Ben ik dan zelf weer niet zo'n fan van (structuur te afhankelijk van je whitespaces) en is ook wat minder bekend.
maar ik mag hopen dat de meeste XML waar je mee werkt gewoon automatisch uit een scriptje rolt
Je kijk op development is hopeloos beperkt. Vrij veel mensen typen rechtstreeks XML. Neem bijvoorbeeld (X)HTML en XAML.
Verwijderd schreef op zondag 31 augustus 2014 @ 17:03:
Ik zou de documentatie van een datastructuur juist los houden van de intrinsieke data zelf
En wederom denk je te beperkt. Waarom zou je je datastructuur gaan commenten in de JSON zelf 8)7. Dat is dus ook totaal niet waar comments in JSON typisch voor gebruikt worden. Ik dacht dat dat met de inmiddels gegeven voorbeelden wel duidelijk was.

[ 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

.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? :D
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.

INI:
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. :+
Vrij veel mensen typen rechtstreeks XML. Neem bijvoorbeeld (X)HTML en XAML.
Volgens mij is (X)HTML in deze context niet zo relevant, los van de (overduidelijke) verschillen in syntax, striktheid, doeleinden, enzovoort.
Je kijk op development is hopeloos beperkt.
Jammer dat je op de man speelt. Hier laat ik het dan ook bij, als je het niet erg vind. :)

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

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.
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.
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.
Het feit dat er niet echt een structuur mogelijk is in .ini is nogal een beperking op zich.
INI:
1
2
3
allowed.methods[] = "method_1"
allowed.methods[] = "method_2"
; allowed.methods[] = "method_3" ; Commented out for now
En dan nu een array van objecten.
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. :+
Nogmaals, je redeneert in dogma's :)
Volgens mij is (X)HTML in deze context niet zo relevant, los van de (overduidelijke) verschillen in syntax, striktheid, doeleinden, enzovoort.
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.
Jammer dat je op de man speelt. Hier laat ik het dan ook bij, als je het niet erg vind. :)
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.

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.


  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
1 antwoord: yaml.
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


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 16:34

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ik vind je laatste conclusie wel grappig, en bovendien enorm onjuist - natuurlijk hebben we ervan geleerd, anders hadden we deze discussie nu niet. Voor de goede orde, ik had kritiek op het json formaat en zou dat graag aangepast zien, maar ik raad zeker niet aan dat iedereen nou zijn eigen afgeleiden van dataformaten moet gaan maken :). Alleen heb ik die kritieke punten wel opgepakt in mijn eigen json parser (strict dus geen json maar een superset ervan) in een heel erg geïsoleerde case omdat het mijn eigen werk een heel stuk makkelijker heeft gemaakt. Maar oh wee als je daar iets over zegt, want dan krijg je een berg van onpragmatische theoristen over je heen ;)

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.


  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 26-05 17:08
.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 ;)
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.

  • dcm360
  • Registratie: December 2006
  • Niet online

dcm360

Moderator Discord

HD7767 powered

Als in de praktijk alle json-parsers het niet lusten en het niet aan de specificatie voldoet, zou ik het met name geen json noemen, want dat is het ook niet.

  • farlane
  • Registratie: Maart 2000
  • Laatst online: 09:51
Als het non-standaard gedrag ondubbelzinnig is hoef je volgens mij niet de purist uit te gaan hangen. Als het wat toevoegt heb je kans dat meer mensen dat vinden en als het er maar genoeg zijn komt het in de volgende versie van de standaard.

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.


  • incaz
  • Registratie: Augustus 2012
  • Laatst online: 15-11-2022
Ik snap de kritiek op het json-formaat ook heel goed, maar het is gewoon al zo vaak voorgekomen dat die 'handige' aanpassingen alleen maar leiden tot drama (zoals in het bepaald niet uitzonderlijke geval dat mensen goede editors hebben die de problemen allang oplossen, maar die ze niet kunnen gebruiken omdat de bestanden niet aan de standaard voldoen.)

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


  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 30-10 12:53

Douweegbertje

Wat kinderachtig.. godverdomme

Hadden we de XML / JSON discussie nou al eens eerder gehad?

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

Douweegbertje schreef op zondag 31 augustus 2014 @ 19:25:
Hadden we de XML / JSON discussie nou al eens eerder gehad?
Ja, het volgende op de agenda is geloof ik static declarations.

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

Het zal mij niets verbazen als dat een terugkerend fenomeen is. :+
Firesphere schreef op zondag 31 augustus 2014 @ 19:25:
[...]

Ja, het volgende op de agenda is geloof ik static declarations.
:D

[ Voor 59% gewijzigd door Verwijderd op 31-08-2014 19:26 ]


  • Ealanrian
  • Registratie: Februari 2009
  • Nu online
Het zou best handig zijn als we alle discussies op volgorde houden. Dan kan je je horloge er op gelijk zetten :P

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11:22

Firesphere

Yoshis before Hoshis

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 :P
Anders bouwen we er even een schema op? Elke keer dat Tesla mauwt, schakelen we naar het volgende onderwerp.

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!

Pagina: 1 ... 21 ... 101 Laatste

Dit topic is gesloten.

Let op:
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.