yoy.be "Why-o-Why"

E17: enkele nederige voorstelletjes

2019-05-21 21:42 E17 [permalink]

Ik kan het niet laten. Met al dat nieuws over mobiliteit in het nieuws heb ik toch zelf eens de kaart bij de hand genomen en wat lijntjes gezet, met hoe het met wat verbeelding er zou kunnen uit zien. Niet gehinderd door enige kennis van zaken.

→ http://yoy.be/home/ys/E17/E17.html

→

Nog dichter tegen de verkiezingen...

2019-05-21 20:45 vk2019 [permalink]

Wat kiezen, wat kiezen? Het is weer tijd om na te denken over wat te kiezen. Je kan denken wat is een druppel water in een oceaan, maar gezien we toch “moeten gaan” als iedereen gewoon even een minimum aan gezond verstand aan de dag legt en een beetje op zoek gaat naar een zinnige keuze, dan komen we wel dichter bij een effectieve toets van de politieke gevoeligheden onder de bevolking. Al was het door de keuze van door wie we ons laten vertegenwoordigen in het wetgevend orgaan.

De gespecialiseerde pers volgen krijg ik hoofdpijn van, en buikpijn eigenlijk ook, als ze door elkaar praten versta ik er toch niets van. Dus zal ik maar weer teruggrijpen naar de methode van eliminatie. De conservatieven zijn me te conservatief. De extremisten zijn me te extreem. Groen heeft me — opnieuw — niet kunnen overtuigen met hun offensieve oppositie. Rood lijkt me nog altijd niet klaar met hun interne problemen, ik blijf in blijde verwachting dat ze zichzelf heruitvinden en naar voor komen met een essentieel pakket aan doordachte oplossingen die voorzichtig maar standvastig naar een groot ideaal toewerkt die goed is voor iedereen, hetzij begrotingsminister, ondernemer of gewone stervelingen zoals wij.

Dan is er een gele partij die niet snapt dat een Duits model in België niet kan werken, alleen al omdat onze deelstaatjes zodanig sterk verschillen in grootte en opbouw. En de ene dag wel fel naar rechts lijken opgeschoven, maar een andere dag erg het centrum willen aanspreken. Mij valt vooral op hoeveel belastinggeld er daar door hun communicatiedienst wordt opgestookt. Wat we niet zien is hoeveel er overblijft voor hun onderzoeksbureau, er zijn kwatongen die beweren dat daar vreemd genoeg hulp van het buitenland is te bespeuren, waar wat daar van aan is weet ik niet.

Dus wat blijft er over? Liberaal. Tja. Ja zeker? Hopelijk doen ze na de resultaten geen ellebogenwerk zoals in Gent. Zou het om aandacht te vestigen op hun sociaal programma zijn dat de voorzitster een bril-montuur gekozen heeft in de lijn van grote socialistische figuren van de late vorige eeuw? Misschien is net rechts van het midden stemmen nog wel een goed antwoord op de verrechtsing en de verzuring van heden ten dage. Het zou goed zijn als er wat meer realisme en gezond verstand worden toegepast. En nuance, dat moet er ook meer zijn.

→

Verkiezingen komen er aan...

2019-05-15 00:06 p201905 [permalink]

Het wordt tijd dat ik nog eens een scherm met tekst vul over wat ik vind van de politiek en actualiteit van heden ten dage. Iets minder dan een jaar dacht ik "Over een week zitten we met oorlog." Maar gelukkig had ik ongelijk. Hoewel het er nu weer uit ziet dat het er alsnog van zou kunnen komen. Hoewel, eigenlijk zijn er terzake wel wat verwarrende berichten doorgekomen. Door een grondig onderzoek naar een meeting tussen mensen van het campagne-team van Trump en mensen die onrechtstreeks iets met Rusland te maken hebben, valt op dat de echt uitzinnige verzoeken van de centrale figuur, door de eerste lijn bodes meestal omzichtig benaderd worden, en doorgeschoven naar agenten in tweede lijn. Deze hebben last van ofwel incompetentie, ofwel gezond verstand, ofwel gewoonweg geen tijd want te druk bezig met andere miserie op te lossen. Gevolg is gelukkig dat zo de collectieve mensheid bespaard is gebleven van groter ergs. Maar er vertrekt wel een oorlogsbodem naar het midden oosten. Dat is nog gebeurd. Misschien zijn de nieuwsmakers wat in de war en spreiden ze dat te groot uit. Hopelijk varen ze niet op elkaar in. Intussen gaat het al weer over China hoor ik. En dat Chinese dingen duurder worden voor Amerikanen om aan te kopen. Vreemde manier om de oorlogskas te spijzen, lijkt me. En lastig voor bedrijven als Tesla. Als die al afgewerkte auto's tot in China en Europa krijgt, komt er plots minder geld voor binnen.

Maar genoeg buitenland. Het bleef tot nu toe op een negeerbaar niveau, maar nu mag toch echt wel duidelijk zijn dat het open bloederige gevecht voor uw stem is losgebarsten. Aan de kleurrijke linkerkant wordt als vanouds geprobeerd iets te bereiken met offensieve oppositie. Een bepaalde partij die recent wat success kende wordt traditiegetrouw belaagd met alernatieve interpretaties van hun eigen mededelingen. Een andere partij die recent geen success meer kende doet ook gewoon verder zoals het vorige eeuw ging, misschien volgen ze gewoon wat ze lezen uit de Bijbel. Helemaal aan beide uitersten blaken ze dan weer in vertouwen in het denken te beschikken over de enige echte Waarheid en dat nuance en inschikkelijkheid niet op het politieke forum thuishoren. Vreemd, want daar ben ik nu net naar op zoek. Tevergeefs.

Dus dan denk je, ik open mijn open source HTML-client, zoek een adres van een stem-tester en doorloop de vraagjes. Als de voorspelling daar klopt, dan is het enigzins verrassend welke partij het meest in de lijn van mijn antwoorden ligt, maar viel ik van mijn stoel dat deze het slechts voor 40% deed. Begrijp ik dat juist? Van alle partijen die riskeren de kiesdrempel te halen, ligt er geenenkele grotendeels in lijn met mijn mening over maatschappelijke kwesties. Ik ben nu wel een vreemde vogel, maar zelfs als dit met een fractie van de bevolking het geval zou zijn, dan kunnen we zeker zijn dat het politieke establishment helemaal de trappers kwijt is. Samen met het groeiende ongenoegen en ontevredenheid van voorgenoemde stemgerechtigden, lijkt me toch iets ernstig aan de hand.

Ik wou dat ik er iets aan kon doen. Net zoals de zucht naar rechts van de laatste decennia, zullen we moeten ondergaan en zien waar het ons leidt vrees ik. Voorlopig zie ik me beperkt tot voorzichtige voorspellingen die vaag genoeg blijven zodat ze achteraf nóg blijken te kloppen. Zoals dat de verantwoordelijken voor de regering te doen vallen, niet elektoraal zullen worden beboet. (De regering was toch gevallen, niet?) Of zoals dat de campagnevoering waarschijnlijk opvallend weinig over het milieu zal gaan, onder meer omdat het nu duidelijk is dat het niet meer zal lukken om dat wel te doen en dan in een uitvoeringsplan niets of weinig concreet inzake milieubeleid te hebben. Zijn er eigenlijk provincieraadverkiezingen nu? Ah, daarom dat ik nog niets gehoord heb over de provincies af te schaffen.

→

Microsoft is too big! Time to split it up in pieces.

2019-04-26 22:41 splitms [permalink]

The Microsoft Corporation reached a valuation of $1·10¹², this could mean the US dollar is losing its value and thus its international relevance, but more probably that the company is positively humungous. Just like the behemoths is has recently joined, it's a worldwide employer, does worldwide business and is sitting on a big pile of cash it's not quite clear even how it could spend it. So when things like this happens, voices speak up about splitting up in pieces. But how? I'm listing just a possible set of fraction lines here through the little I know of the enterprise and what I understand about it. Please feel free to differ, or revel at the level of insight of this outsider, whichever feels most appropriate.

Department: Hardware

Products: Surface, XBox, HoloLens, other peripherals (and what's left of Zune and Nokia)
Revenue: from selling devices

Operating system and out-of-the-box software would no longer be available from a source in-house, so they'll have to shop around like the rest of us, or (try to) go with freeware.

Department: Developer Tools

Products: Visual Studio, compilers.
Revenue: licensing

Do prices need to go up? Will this scare people away? Are the free community editions still possible? And what about Visual Studio Code? There's perhaps even a small chance of access to documentation turned into a payable service, but I hope it's clear that this most probably will scare away an important portion of the public. Anyway, this is where the true legacy of Microsoft lies, if you consider BASIC as one of early Microsoft's first successfull products, and the success of its compilers and platforms going hand in hand with the rise of Windows.

Department: Operating Systems

Products: Windows
Revenue: licensing

As I said before, Windows could do Coca-Cola and go open-source, and what people would be buying is the certified binaries to install, and — perhaps more importantly — a continuous stream of system updates refining (new) features and assuring better security. With an open-source Windows, one could go and try at it for oneself, carrying the full set of risks, and it's a big part of the equation if you're really sure that's what you want. Then again, it would open the playing field, and the few that could build up the substance to offer an alternative with a similar degree of dependability would at least get a fair chance. Don't forget, if this plays out and a few big ones compete like this, it keeps all of them on their tows, and typically will compete in innovative features and cooperate for collective security. Something that may regretfully be reverting in the field of web-browsers now that Microsoft too switched to a WebKit-derivative, and all we've got for technically true alternatives is Mozilla's offering.

Department: Productivity Software

Products: Office, Team System
Revenue: licensing

Microsoft has been accused before of having an unfair advantage from the people building Office sitting next door to the people building Windows, being able to open hidden undocumented features for exclusive use. To their credit, they have been able to disprove any such claim, and have opened up the documentation on both sides about how it's all done, and how anyone could do the same. Still, as separate corporate identities, this would truly open the market, and offer a chance of other players to form a collection of stake-holders to jointly push for required features and revisions the operating system should provide.

Department: Business Software

Products: SQL Server, BizTalk
Revenue: licensing

Much like with Office, the general public gains from having full transparency about how SQL Server embeds with the system. Unlike with Office, this hasn't been as much of a problem with SQL Server, perhaps because with advanced systems administration you naturally learn about the nooks and crannies of the system when it has to perform under load. Also with the port to Linux and other Unix-derivates complete, this is no longer an issue. What may be an issue in recent days — in my opinion — is the current pricing and how it may be employed to push people towards the cloud. I've heard from a number of instances in the field, that it's not working, and large projects are moving to PostgreSQL instead. Sometimes even also with a (partial) move to the cloud (and almost never Azure I noticed). But I could be wrong, and/or this could all be changing as cloud offerings are in continuous flux. But seperating this in to independent units would offer more operability and tranparency, I guess.

Department: Services

Products: Azure cloud
Revenue: cloud resource use billing

As with the hardware division, operation system and developer tools would no longer come from in-house, except perhaps the system modules and libraries used server-side specifically for running virtual payloads and managing the cloud services in use by the customers. But this also means that any services used and access to system internals provided by external providers, would be accessible to anyone else as well. Also as I've mentioned before, cloud offering is relatively new and in constant flux, and I expect an era of renewed interoperability between all kinds of cloud services of all providers. For now all we can do is frown upon vendor-lock-in very hard if we notice it, and only grudgingly accept if we really find no other viable alternative.

Department: Research

Products: ?
Revenue: ?

This is a hard one. If you split the research endeavour into a separate unit, it's not clear what you would expect of it. Research in hardware is important to advance the state of the art and develop new devices. Reasearch in development tools is important because of the constant influx of new developers learning to code and the quality of work we should be able to expect from them. Research in software is important because modern devices keep increasing performance and capabilities, and offers new options for human interaction that need to get developed. So each independent unit may need its specific research lab, but there's still a section of independent research done in the over-arching field of computer use, networking, man-machine psychology, how hardware and software could have less impact on the planet, etc. Where's the business model in this, I don't know, but if we have a peek over the fence, I guess the way ex-Google's X is managed by the Alphabet Corporation may serve as a nice example. Try new things here and there, and if anything sticks, spin it off, and house it with a different company in the group, or let it loose on the world on its own.

→

I'll be there: Delphi Day 2019 - Brussels 9 May

2019-04-23 11:39 delphiday2019 [permalink]

May 9: Delphi Day 2019

I'll be there.

→

idee: antibiotica-quotum per huisdokter

2019-04-04 13:06 antibio [permalink]

→ vtm: Ondanks prijsverhoging kopen we nog te veel antibiotica

Ik heb net een gek idee: zou het mogelijk zijn om een antibiotica-quotum op te leggen aan huisdokters? Een argument van de huisdokters is dat bepaalde klanten hardnekkig blijven volhouden dat ze antibiotica moeten voorgeschreven krijgen. De opleiding en bijsturing van de huisartsen zou hier moeten van belang zijn om dit tegen te gaan, maar wat de mensen in het veld betreft kan ik ze heel goed begrijpen dat je ze toch maar moet zien overtuigd te krijgen, en dat soms echt niet lukt. Plus in bepaalde medisch ernstige gevallen is het nu echt wel aangewezen te behandelen met antibiotica. Wat van belang is voor de volksgezondheid is als we dat te veel doen we het risico lopen dat er meer resistentie zou ontstaan, en zo kwam ik al snel op een quota uit. In het begin zet je het quotum best op iets zodat gemiddeld het mogelijk blijft een normaal voorschijf niveau aan te houden inzake anti-biotica. Zo lopen de zonderlingen die het nu blijven fout doen al snel tegen de lamp zonder dat je ze specifiek viseert. Daarenboven zou — verplicht of vrijwillig — de gevallen waar het van medisch belang is moeten kunnen worden aangeboden aan een orgaan die dan kan beslissen per geval dat ze niet meetellen voor het quotum. (Is er al een overzichts-raad van huisartsen? Kunnen die het extra werk er bij nemen? En hoe zit het met de informatisering van de administratie, want die zou dit wel moeten kunnen betrouwbaar vervullen...) Maar zo'n gekke ideeën ver van mijn gebruikelijk activiteitsdomein komen natuurlijk op de zotste momenten in mijn hoofd. Best dat ik ze dan maar ergens neerschrijf zeker?

→

Tja, de kranten...

2019-03-12 23:27 qoudkranten [permalink]

Ocharme de kranten, wat hebben ze het moeilijk. Nog een slachtoffer van het digitale tijdperk? Ik ben het nog niet zo zeker. Je moet je altijd aanpassen aan de tijd van tegenwoordig. En met die tijd van tegenwoordig is iets ernstig aan de hand. Laatst las ik iets in de trand van "internet is geen nuance-machine"... Dat laat weinig aan de verbeelding over. Jammer genoeg klopt dat wel. Als je een omgeving hebt waar extreme meningen meer weerklank vinden, dan loopt het vroeg of laat wel eens fout. Intussen wordt pijnlijk duidelijk dat het ook voor de rest van ons tot gevolgen kan leiden.

Maar wat moeten de kranten dan doen? De formule van een goedkoop gedrukt wegwerp-ding te kopen met de dingen van gisteren op, is goed en wel achterhaald. Het vertalen naar een online-verhaal waar je de titels toont en de mensen laat betalen om verder te lezen, pakt gewoon niet. Niet in een abonnement-verhaal, niet met micro-payments per artikel. En al helemaal niet als je denkt dat je kan meedoen op dit nieuwe platform dat is gegroeid uit openheid, maar geen links naar de specifieke artikels op je website wil...

Soms lijkt het dat ze enkel het kosten-plaatje zien, en niet te ver durven kijken. Als ze durven flemen met meer sensatie-beluste insteek, dan gaat het inhoudelijke snel achteruit en trek je misschien niet het publiek aan dat je eigenlijk wil hebben. Ik denk dat ze net terug naar de essentie van de journalistiek moeten teruggrijpen. Vroeger was een krant het eind-product van een goed geölied team dat elk zijn essentiële taak vervulde, en net zo'n pipelines krijgen het overal in deze moderne tijd zwaar te verduren. Dus ook hier: skip the middle man. Ik weet dat nieuws voortvloeit uit een redactie. Als journalist moet je actief op de hoogte blijven van wat er staat te gebeuren. Moet je weten hoe je de ontwikkelingen kan bevestigd krijgen, waar je meer kan weten over de keerzijde van de medaille. Waar je andere perspectieven kan raadplegen en precies de nodige nuance kan vinden en aanbrengen.

Dit zit allemaal netjes verborgen achter wat wij uiteindelijk te lezen krijgen als consument. Misschien moet dat maar eens veranderen. Ik wil de kwelling en hitte van een redactie wel eens zien afspringen van een informatie-platform waar je meer dan het huidige nieuws te verwerken krijgt. Alles dat leeft bij de mensen of over de telex binnenkomt, moet toch worden gefilterd, gekaderd, bevestigd. Wij zijn niet onnozel. We kunnen dat aan. Meer nog, misschien moet je net de mensen betrekken er in. Lijkt misschien een vreemd voorstel als je ziet wat er doorgaans in de comentaarrubriek binnen komt, maar hier kan je misschien een verdien-model in je voordeel gebruiken. Je laat een gratis ingangs-niveau niet zomaar aanbrengen, maar mensen die bewezen hebben dat ze iets waardevols te bieden hebben luister je wel naar. Of dat waardevols deel uitmaakt van het omzetcijfer is een andere vraag, maar dat is voor een andere keer.

Ik beeld me dus in dat je op een centrale plek alles te zien krijgt. Zelfs al is dat aangetoond een leugen, of nog in afwachting van een bevestiging. Stel dat er iets binnenkomt dat te sterk of te eenzijdig is opgesteld, kan het worden gevlagd. Kan je het toetsen met meer gematigde versies en of die dan niets van de essentie verliezen. Groepeer de ontwikkelingen per oorlogsgebied, ramp of regio en laat de mensen mee beslissen of een bij-verschijnsel een nieuw onderwerp moet worden. Lok de mensen met een lijst van wat ze willen zien, maar hou ze bij met een lijst van dingen die daaraan toevoegen en de nuances die eromtrend spelen, en je kijk op de zaken verruimen.

Vreemd genoeg lijken mij het dingen die allemaal al bestaan. Sites zoals slashdot.org en stackoverflow.com werken al jaren zo. Hoewel ze niet zozeer op een verdienmodel draaien, gaan ze ook niet bepaald om de brede actualiteit. Wel zijn ze van en voor een specifiek publiek die weet waar het om gaat. Misschien dat daarom wel eens naar wikipedia.org wordt verwezen, waar je ook een kleiner specifiek publiek hebt dat over de inhoud waakt terwijl het in theorie wel open staan voor het brede publiek. Van dezelfde mensen is er iets met nieuws, maar ik ga er van uit dat deze niet zo alles-omvattend en doorgezet kan zijn als je zou kunnen verwachten van een redactie met professionele journalisten.

In afwachting van het duidelijk wordt waar ze naartoe willen, blijf ik lekker free-loaden op de RSS feeds die ik kan vinden. Zolang ik de nodige achtergrond kan oppikken van de dingen waar de mensen het over hebben, en ik in de loop van de dag al kan gissen waar het in het avondjournaal over zal gaan, ben ik al tevreden.

Update: Als ik dit lees zitten ze mogelijk ook op een vergelijkbaar spoor...

→

Local variables don't cost nothing!

2019-03-08 22:45 nocostvar [permalink]

O my god. I can't believe I have to keep explaining this. To a years-long colleague with some more years on the counter than me, the other day. He repeated a function call with the same arguments a few times in a few adjacent lines of code, with a guarantee in place that this will result the same value every time.

I asked him why. It couldn't be to have less typing: the extra var a:integer; would replace far much more code it took for the repeated function calls. It couldn't be performance: even if the function would just be getting a value from a memory location, the call and return, building a stack frame and tearing it down it again, would end up in a multiple of the instructions the processor needs to work through.

I don't know who launched the idea the compiler should be smart enough to pick things like this out — what I read about Rust and other modern languages, I know research is actively looking at things like that — but as we currently have it, our good old trusted compiler doesn't. What is does do, and typically really well if we work a little with it, is mapping local variables onto the available registers of the CPU. In the best case no memory whatsoever is allocated for local variables.

Even if in theory some local variables get a temporary address on the stack, modern CPU's have multiple levels of cache so that the values don't even reach your DRAM silicon before you're function call completes. We're supposed to keep all functions and methods as short as possible, but even if we don't, the compiler knows if a local variable is only used for a short section of the code. So in some cases it's even better to have an extra local variable instead of re-using a local variable somewhere up front and then later near the end of a larger block, and still not pay with any performance of memory consumption...

So when in doubt, take an extra local var. It's what they're there for. It helps the compiler do better analysis. It helps you, now and later. All I need to do now is name them a little better. I know I have the nasty habit of things like var a,b,c,d,e,f,g:integer; but I think I'm improving... Slowly...

→

PostgreSQL: update set from (join)*

2019-03-05 15:56 updatefrom [permalink]

In SQLServer schreef ik wel eens een query van de vorm:

update MyTable set Field1='Value1',Field2=3
from MyTable T1
inner join SomeOtherTable T2 on T2.Field3=T1.Field3
--eventueel nog joins
where T1.Field1='Value0'

Maar dan probeer je hetzelfde te doen in SQLite: noppes

Of in PostgreSQL, daar blijkt het wel te bestaan maar hij plakt de referentie naar de tabel van de update niet aan het gebruik van de tabel in je from of join. Omdat je zo dan eigenlijk geen velden van de tabel in de where hebt staan, doet hij de update op alle records, ongeacht je selectie. Maar dat is gemakkelijk op te lossen natuurlijk:

update MyTable set Field1='Value1',Field2=3
from MyTable T1
inner join SomeOtherTable T2 on T2.Field3=T1.Field3
where MyTable.MyPrimaryKeyField=T1.MyPrimaryKeyField --in de veronderstelling dat dit je primary key veld is natuurlijk
and T1.Field1='Value0'

Maar daar moet je dus wel zelf aan denken, lastig als je het anders gewoon was...

→

VPN problemen? rasphone

2019-02-03 21:51 rasphone [permalink]

Dit is er eentje om te onthouden. Ik had problemen met de VPN connectie naar het werk. Het is te zeggen, het werkte vlot en naar behoren op mijn vorige laptop. Ik koop me na x jaren eens een nieuwe laptop, neem de instellingen over, noppes. Waarom precies is me niet duidelijk aan de error. In de event log vind ik RasSstp die zegt dat het of een timeout of een certificaat-probleem is. Dus was ik al de certificate (stores! wist ik veel of het de computer of service of persoonlijke store is) aan het uitpluizen voor een eventueel verschil. Ik had zelfs al netsh ras set tracing * enabled gevonden maar daar vond ik helemaal niets in terug... En dan kom ik plots toevallig langs deze (lap, vergeten de URL van waar ik het zag bij te houden):

C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk

Blijkt daar niet alleen precies inderdaad een cruciaal verschilletje te zitten in één van de honderden parametertjes daar, blijkt ook dat je gewoon extra files in die folder kan zetten en ze verschijnen auto-magisch in het netwerk-menu onder het icoon op de taakbalk. En voila, probleem geflikskts.

→

Tweedehands diesels raken niet verkocht

2019-01-26 12:27 diesel [permalink]

→ Standaard: Tweedehands dieselwagens raken niet verkocht

Eerst dacht ik “in plaats van te demonstreren, zouden ze niet beter massaal hun diesels verkopen en voor dat geld nieuwe zuinige benzinewagens kopen? En voor die die echt veel kilometers doen op gas.” Maar als het al zo ver is dat er geen vraag is om dat extra aanbod te slikken (zelfs in het buitenland), dan geeft dat opnieuw reden om in opstand te komen. Maar wat moet je dan doen als staat? Is het eigenlijk mogelijk om dieselmotoren om te zetten zodat ze op iets draaien van mindere smeerlapperij? Waarschijnlijk niet met minder uitstoot en lagere prijzen aan de pomp...

Zelf al was het mogelijk een je geeft voluit premies, krijg je gegarandeerd een scheefgetrokken situatie die daarna dan weer tientallen jaren meesleept. (Zonnepanelen, iemand?) Dus komen weer bedrijfswagens in beeld. Misschien nog zo'n slecht idee niet eigenlijk. Als ik het juist begrepen heb hangt er heel veel af van de geschatte waarde bij verkoop na 4 jaar, en van die nieuwe auto's is dat nog helemaal niet zeker.

Zou dat geen mooie rol te spelen zijn door vadertje staat? Gewoon voor vier jaar garant staan dat door auto's nog goed verkocht gaan raken na hun contractduur? Op zich kost het niets een de kans is groot dat ze uiteindelijk vlot toch een nieuwe eigenaar vinden aan een eerlijke prijs. Maar in ons Belgenlandje zit je dan over het einde en begin van legislaturen. Aj. Tja, noppes dan zeker? Soit, ik ben benieuwd wat ze wel gaan uitvinden. Misschien kunnen we er nog eens goed om lachen.

→

jsonDoc v1.2

2019-01-18 08:53 jsondoc12 [permalink]

I don't really know where my open-source/freeware projects get used by other people (and I don't really care all that much, really), but ofcouse where I use my private libraries in the projects of my day job, I've got a first-row seat to see how they perform. No, even better, I'm the stagehand. I know it's important to keep the two separated though. At work I can only use and call libraries, never work on them. I can make changes, but I would have to do so like anybody else: clone a local repository, store the changes there, and when they're ready have the good manners of sending out a pull request. If 'at-home’-‘hobbyist-programmer’-me decides to merge it, it makes my employer a co-creator of the project, creating a new legal situation that my employer would need to know about.

What I can also do, ofcourse, is let private-me know that ‘at-work’-me would really like this or that extra feature or interface, and then when I can put some evening time into programming, I can see if I get round to it. Github issues are nice for that. Or Post-It's on my car key...

But recently I've got a real decent suggestion from a collegue. It didn't come in over a pull request, but it made sense, so why not put it in at the base:

https://github.com/stijnsanders/jsonDoc/commit/fb01e0865fa888c7441234726dc4a90b0c802582

The IJSONDocument interface has Parse to load data from a string holding JSON data, and a function ToString to convert the contents back to a string. For jsonDoc (and bsonDoc before that) I want concise syntax, so I though I'd make Parse a function that returns Self so you can chain calls. But my collegue wondered why IJSONDocument doesn't have a property AsString:WideString;. In theory it would have read ToString write Parse, except Parse needs to be a procedure, not a function. So I had a close look and changed it around. Another option would be to add an extra procedure SetString, but that would mean the virtual method pointer table for the IJSONDocument interface would have an extra item, to a method with exactly the same behaviour, which makes little sense.

So I changed it around. If you really like/need chaining, there's still the function JSON overload that takes a Variant. If you pass it a string, it'll call plain function JSON to get a new instance, and call Parse for you on the string.

→

Open source is nice, but is the protocol also open (enough)?

2019-01-15 08:57 openproto [permalink]

→ Hacker Noon: Bitcoin’s Biggest Hack In History: 184.4 Billion Bitcoin from Thin Air; Satoshi Hard Forks, Saves Bitcoin

See, this is something I'm very very worried about: things like Bitcoin — big public successful open-source projects — have the appearance of being complete open and public, but the protocol isn't really.

When I was first looking into Bitcoin and learning what it is about, really, I'm quite sure this can only have originated out of a tightly connected bunch of people that were very serious about 'disconnecting' from anything vaguely institutional. Any structure set up by people to govern any kind of transactions between them, has the tendency to limit liberties of people, for the people taking part in the system and sometimes also for those that don't. So it's only natural that Bitcoin at its code is a peer-to-peer protocol.

But. How do people that value anonymity and independence from any system, even get to find each-other and communicate to build things together? Well, the internet of course. But perhaps more importantly — and also since long before the internet — cryptography. Encoding messages so that only the one with the (correct) key can decode and read the message, helps to reduce the cloak-and-dagger stuff to exchanging these keys, and enables to send messages in the open. To the uninitiated onlooker it looks like a meaningless block of code, and in a sense it's exactly that. Unless you what to do with it, and have the key — or would like to have it.

Another use of encoded messages is proving it's really you that originally encoded a message. It's what's behind the Merkle tree that the blockchain runs on. That way the entire trail of transactions is out there in the open, all signed with safely stored private keys. The reader can verify with the public keys, and in fact these verifications buzz around the network and are used to supervise the current state of the blockchain, building a consensus. Sometimes two groups disagree and the chain forks, but that's another story.

The protocol, or the agreement of how to put this into bits and bytes in network packets, can get quite complex. It needs to be really tight and dependable from the get-go, see the article I linked to above. You could write it all down and still have nothing that works, so what typically happens is you create a program that does it and test it to see how it behaves. In this case it's a peer-to-peer networking program so you distribute it among your peers.

But when things get serious, you really need the protocol written out at some point. If you try that and can't figure out any more what really happens, you're in trouble. The protocol could help other people to create programs that do the same, if they would want to. This was something the early internet was all about: people got together to talk about "How are we going to do things?" and then several people went out and did it. And could interoperate just fine. (Or worked out their differences. In the best case.) It typically resulted in clean and clear protocols with the essence up front and a clear path to some additional things.

The existence of the open-source software culture it another story altogether, but I'm very worried it is starting to erode the requirement for clean protocols more and more. If people think "if we can't find out how the protocol exactly works, we can just copy the source of the original client/server" nobody will take the time to guard how the protocol behaves in corner cases and inadvertently backdoors will get left open, ready for use by people with bad intent.

→

NoSQL agent with SQL back-end(s)

2018-12-29 15:41 nosqlidea [permalink]

It happened again. I get this great idea that slowly develops, and gives the feeling I'm on to something, but nowhere near any time in the forseeable future to put in to it and get a proof-of-concept of a first project that makes it work. So, for what it's worth, I write it down here fast in the hope sharing it with you may give more chance to this idea getting useful.

I've read that some NoSQL solutions are actually about eventual consistency, meaning in the best case of a query for data that was just inserted or updated could already return this new data if the server(farm) ad already fully processed it. Worst case is that it just for a few milliseconds totally disappears, but that's another story altogether.

I haven't done anything serious with NoSQL yet, and really a lot on good old SQL, and recently with SQLite which I've really grown to love in a short period of time. But still there's something there that's really suited for the new style of programming that is going on with all the new web projects and this 'Internet of Things' everything is on about... To find out, I've been trying interfacing with a number of them from Delphi in the most direct way I could possibly find and make work with reasonable effort. I like how TMongoWire worked out, to talk with PostgreSQL all you need is in the libPQ.dll, but a number of others just stick with a plain HTTP API where you PUT and GET things on their own URL. There's a beauty to that, really. The structure of your documents is nicely contained in JSON, and HTTP is such a stable platform you're sure to be able to access it from almost any platform.

So that's where the idea came from: what if I made my own service where you can just put or get JSON documents? But on the back-end jsonDoc would do the heavy lifting and the storage itself could be in a decent SQL service. And/or it could be in something intermediate like memcached. And/or the saving to storage could be asynchronous somewhere close after the actual PUT call (hence the eventual consistency).

For example, you fill a collection of items with things with a number of fields, for example one is "Price", but later you need the items above or below a certain price, you would do SQL "select * from Items where Price<@p". So in this service I'm imagining, there would be meta-description on the collection that you've provided a SQL database somewhere, but the service is responsible for having done the "create table Items (ID some primary key, DATA json, Price decimal(8,2))" and filling it with the data.

And this would be the beauty of it: if you need an extra column later, you just say so, and the connector would be responsible for the "alter table Items add ..." and filling that column with the data from the stored items. Perhaps even slowly, asynchronously together with the other work. Or even another connector alltogether, let's say PostgreSQL and MySQL side by side, perhaps even as a fail-over for eachother.

But I'm dreaming. It would be a load of work just to get something to work, and even more work to get enough connectors to work good enough to even demonstrate how it would work. And then there's the performance trails... And the evangelising to see wether it solves other people's problems anyway... It would be a really great opportinity to finally cut my teeth on this IOCP thing.

→

Update to SQLite 3.26 as soon as possible

2018-12-24 14:52 sqlite326 [permalink]

It's very rare something turns up in the SQLite package, but when it does is best to give it some attention. So, very esteemed users of TSQLite — and anyone else, really — I strongly suggest you upgrade to version 3.26 of sqlite3.dll since recently some dangerous vulnerabilities have been uncovered. I checked, and nothing extensive changed to the API so chances are nothing should break if you only update sqlite3.dll and not SQLite.pas and SQLiteData.pas. Also, happy Christmas!

→

TOML? YAML? ini-files? JSON? Loosen up!

2018-12-10 11:26 jsonloose [permalink]

TOML? YAML? plain old INI-files? or shiny and new — but strict — JSON? Nàh. I've made myself something better. In jsonDoc.pas I've recently added an optional compiler define JSONDOC_JSON_LOOSE that makes the JSON parser a whole lot genter to work with. Some things are no longer required: the root document doesn't need to start and end with braces ("{}"), the quotes around the key names are no longer required (unless they contain special chars), the comma's between key-value pairs are no longer required, it accepts equal ("=") between keys and values instead of colon (":") and can even do entirely without.

And while I was at it there's also JSONDOC_JSON_PASCAL_STRINGS that allows you to write string literals the Delphi way: between single quotes, and double single quotes where you want a single quote in the string value. This way — really handy in Windows environments — it doesn't require you to escape backslashes.

The only downside maybe is that you need to add the defines to the compiler parameters, but for plain old configuration something like this:

x=5
y=10
output='C:\test\output\'

looks a lot nicer and like what we're used to, and gets parsed just the same as if it was written like this:

{
  "x":5,
  "y":10,
  "output":"C:\\test\\output\\"
}

→

xxm 2.0? About the big plan

2018-11-28 22:50 xxm2plan [permalink]

Should I begin on xxm v2.0? Delphi having a Community Edition is really really great news, not only for all of the Delphi community, but also for me as a hobbyist programmer with a number of freeware opensource projects out there. Except I was one of those that stuck with Delphi 7 up till now, so next to myself being fully convinced to finally take the step, I also need to have a look project-per-project how to lift them into these modern times and upgrade them to full Delphi 10 projects.

One of my darlings is xxm. You can compile xxm with modern Delphi just fine. I switched string to AnsiString or WideString explicitly nearly everywhere, so you shouldn't get as much as a hint. (Except mayby somwhere where I still have case x in ['A'..'Z'] of or something like that where x is a char and thus is a WideChar, and the compiler doesn't like that). But I'm worried about how I chose to set up the project. I thought I was best to just inherit from IUnknown and define a decent interface and build everything around that. But several xxm projects later, some that are even running some decent production load at work, I learned some things, most importantly these two:

It looks like xxm doesn't need to work with object instances. Requests are coming in, something needs to build a response, but having to have your objects set up first before you can get crackin' now appears as something I should have tried to avoid. Specifics and identities are handled by the underlying communication framework anyway, so you can get by with just a reference, and request more with that reference only just when you need it.

The other is that with the dynamics of IUnknown pointers, you're still dragging this COM thing with you. Yes it may be wafer-thin really and proven tech, but it's still something removing you from what really counts: pointers to where the code is to run. If you're really (really!) pushing to get the last drop of jouce from the orange performance-wise, it may be just that last thing that's in the way. Even when you avoid any locking in reference counting.

So this is the big plan for the moment: if I get to put some decent time into the project, over the next year(s), I'm considering starting a blank project xxm 2.0, start with a plain C style interface with just procedure and function pointers — a really really ancient looking interface — that has everything that IXxmContext and related interfaces have now. Then re-start with xxlProto and xxmHttp to make that work, then a new xxmCGI, xxmSCGI, xxmISAPI, xxmAhttpd (and perhaps now really a xxmFastCGI, but no xxm IInternetProtocol any more, sorry) and then have a first new push to see how it performs, with IOCP and http pipelining, and who knows HTTP/2 or HTTP/3 that'll have materialized by then.

After that I was thinking I need a new implementation of IXxmContext that just patches through to the new xxm 2.0 calls, so you can very easily and without a worry add it to an existing xxm v1 project and run it with the xxm v2 handlers, enjoy the performance benifits and slowly change things over to xxm v2 where you need to — or not at all, really.

I hope it's a good plan, but for now it's all a dream. I haven't been able to put much time into my hobby projects lately, but it fluctuates and if it picks up some I'll see how far I'll get. Along the way I still hope to find more people that are searching for a good way to combine good old web-scripting with the power and speed of the Delphi compiler, and can count on xxm to offer good debugging, easy live-updating and a stable and secure platform for their web projects.

→

Don't panic: Bitcoin's usual pre-end-of-year dip is here.

2018-11-23 00:29 btceoy [permalink]

Don't worry. The price is going down a bit, yes. But I think there's no reason for massive public panic and the cyber-world's equivalent of a run on the bank. The holiday season is here. Black Friday. We need presents for the family, and that costs money. We may have chosen to put the value of our earnings into this new thing designed especially for that, and now need to convert some back to good old local currency, so it probably pushes the exchange rate a bit down. It may even be a good sign of institutionalisation that automated agents kick in and join in on the selling, pushing rates even further down, dramatically so. But it's best for all of us if that's only a marginal effect. If I were speculating, I would guess it would start to look like a buying opportunity, if I could statistically detect when the bottom would come into view, but I am not. Actually I don't care. But since we're guessing, I guess things will bounce back in January. It did last January. Perhaps it won't get to the same levels as we had up till before this dip, but that's OK. If it's all rather stable for a few months, that would be good, but if it follows real events in the real world, that's also good. It's just normal. I'm not worrying. Perhaps next year we'll be paying Christmas gifts in bitcoin. (Though I wouldn't put money on that...)

→

TMongoWire on jsonDoc v1.1.8

2018-11-01 17:24 mwjd118 [permalink]

→ TMongoWire commit 78c7c62: jsonDoc v1.1.8

I may have decoupled the bit that works with structured data (using Variants), and converts to/from JSON, into a separate project jsonDoc, and have converted TMongoWire to run on jsonDoc, I also should take the time to update TMongoWide when jsonDoc gets improvements. The fact is I'm doing much more with JSON than on MongoDB recently, so I risk letting this slip out of sight.

What I also should do is set the TMongoWire repository up so it uses the jsonDoc repository as a git module, but for now it's just about one single file so I'll see when I get to it (...).

→

Browsers with less and less UI...

2018-10-05 17:19 browserslessui [permalink]

Here's a wicked idea: With browsers trying to have less and less UI, the line of death getting more and more important to help guard your safety, and some even contemplating seeing the address bar as a nuisance — who types a full URL there nowadays anyways? — what if there was a browser that always opens fully full screen. No need for F11. You still need a back and a refresh button, and something that gives access to all the rest like settings, stored page addresses, and if you really really need it, the address of the current page. But it is hidden from view most of the time, except when you make a certain gesture, like a small counter-clock-rotation. It should look different enough so it contrasts with the page, and should be different every time, so it isn't corruptable by any webpage. And even then should be obviously not part of the page.

And people need to find it intuitive and self-explanatory.

Oh never mind.

→

Barney Cools: Tunes

2018-10-02 23:31 bct [permalink]

O jee, ik heb in een eeuwigheid niets meer geblogd over muziek! Terwijl er toch wel een hoop te vertellen is. Hoewel, zoveel nu ook weer niet. Na meer te willen weten over Oliver Koletzki, en SoundCloud ontdekt te hebben, kwam ik daar langs deze:

→ Barney Cools: Tunes

Eerst wist ik niet goed wat er van te maken, huis-mixes van een open-lucht-zwembad-beach-bar in Australië? Blijkt het een kleding-merk te zijn die ook mixes de wereld in zet. Tot nu toe vind ik ze behoorlijk de moeite. Op hun beurt zijn ze dan ook weer een manier om nieuwe artisten te leren kennen. Zoals Aeonix of Haert. Of dit pareltje... Of deze!

Verder vind ik het vreemd dat je zo weinig hoort van dat Chvrches nieuw werk heeft...

→

ECB should plan to issue a digital currency!

2018-09-18 00:07 nodraghi [permalink]

→ Reuters: ECB has no plan to issue digital currency: Draghi

Here's an idea. Just an idea, floating it here to see what you think, no concrete plans yet. The internet should float a new digital currency. "Wait, what? We have Bitcoin/Litecoin/Ether/... already, are those not internet's digical currencies?" I hear you think. Well, no. They're intended to perhaps become currency, but that kind-of totally failed. The world wasn't ready for Bitcoin when it hit us, and all the nice plans kind of prescribed to one day use bitcoin as currency, but as the hype and dust are now somewhat settling, it's clearly unfit for that purpose. It's still great at what it does though, and it could perhaps serve really well as something like gold: something that holds value you can buy and sell and will most probably get bought and sold in the forseeable future, according to current market behaviours. And there's the blockchain which it all runs on, it's a great proof-of-concept of a public ledger that some industrial settings could greatly benefit from, who knows perhaps in a slow movement from the fortified castle paradigm to the zero-trust concept.

But as a currency? No. Currency is allergic to strong ups and downs in the inherent value. "Didn't we have all this already, the US dollar doesn't have inherent value as well, since we've let go of the Gold Standard?" Well, no. The price of gold may now be free-floating, but since the entire US economy and a sizable part of the world's economy is running on US dollars, you could consider the entire economy as what's carrying the real value of all those dollars. I'm oversimplifying here, but some big large-scale economic metrics appear to work reversed for the US-dollar because of this. A currency as we know them now also had a central body that goversn both the internal use of it, and the powers that exert on it from outside, other currencies and macro-economic movements.

So here's my idea: because Europe is looking to do something about copyright on the web, and newspapers — and perhaps journalism in general — are struggling, something like the European Union should float a digital currency, specifically to make micro-transactions on the web. And I really mean micro. Listening to a song? Bam, something tiny moves from your online wallet to the musician(s). Viewing a video? Bam, something tiny moves from your wallet to actors, directors, lighters, screenwriters and background-painters. Read an article? Bam, you get the idea. How much? How many articles are in an avarage newpaper? How much does a regular newspaper cost? Calculate back from that to get a good first unit of value.

As an alternative way of payment, it could complement the Euro, and only later move up the ladder if there's a base of users with accustomedness. But to get there some important details need to be set up just right. It will need a governing something, but I wouldn't hand it over to Frankfurt. The time is right to involve the people. Bitcoin is doing just right without central oversight, but the required checks and balances need to be baked in. Anything new like this should also be design 'of and for the people'.It will need its proper legislation to get to serve as anything official, an get it accepted as a bearer of value, but by limiting who can exchange how much to and from real currency, for example a weekly global limit on conversion, could dampen the risk of large-scale mutations induced by panic. Or by limiting the maximum amount you could hold per user or per device or per account, could limit the importance of this new stream of cash in regard with the entire economy.

Also as an internet-centric application, every user wanting to participate needs to run the software, but it should be entirely open so each of us can govern that our security and privacy is catered for. Only then it's ready for designing the conduit with which you let the websites you visit know what credit you provide when consuming songs and articles. There needs to be something like a public ledger, since that would make it a new skool digital currency, but requiring every mobile device to keep a full copy of the ever growing full ledger is absurd. And it is also limiting the maximal number of transactions that can get processed in limited time, so that needs to get decentralised as well. I'm not sure how, but I'm sure there are people smarter than me that have been deep enough into the theoreticals that could draft what it takes.

But I'm just dreaming aloud here. Innovation hurts and is hard work. And there are always those that don't want anybody to challenge the status quo.

Update: look, look, this is also about something like that!

→

"Leren programmeren is even belangrijk als leren lezen schrijven"

2018-09-11 14:38 nwsprog [permalink]

→ VRTNWS: Leren programmeren is even belangrijk als leren lezen schrijven

O jee. Hoe gaat het lesmateriaal daarvoor er uit zien? Wie zou dat kunnen samenstellen? En wat gaan ze geven als programmeren, want het is intussen best een behoorlijk breed kennisdomain met veel onderverdelingen. Bepaalde dingen van het computerwereldje liggen bepaalde mensen zelfs beter dan andere dingen. Denk maar aan het verschil tussen taal-vakken en wetenschap-vakken.

Maar misschien nog belangrijker: zit er ook een stuk etiek in? Je kan alles programmeren wat je maar wil, en dus ook programma's die doelbewust misbruik maken van het vertrouwen van de achteloze gebruiker. Of erger nog, schade berokkenen. Om nog maar te zwijgen van de recente revelatie dat alle complexe software die werkt op maatschappelijke data blijkbaar ook latent racisme en discriminatie braafjes toepast zonder verpinken.

Toen ik het middelbaar doorworstelde hadden ze net een vak 'technologische opvoeding' ingevoerd. We hebben een bureaulamp gemaakt. En iets gedaan met blauwe bakjes met in het groot "OR" en "AND" op. Het zou uiteindelijk een verkeerslichtje moeten doen maar dat werkte niet (meer?). En er was ook iets met kleine baksteentjes en lijm in plaats van mortel, maar dat had het gelukkig niet gehaald van de onzin-filter die de professionals vooraan in de klas gelukkig aan de dag leggen.

Ik herinner me dat we enkele jaren later toch al wat puntjes konden verdienen met een mooie pivot-chart of een etiketten mail-merge. Dus ergens denk ik als ze nu eerst zien dat scholen iets gemakkelijker wat computers in de klassen krijgen, dan zal de rest wel volgen.

→

Waarom niet gewoon zomaar wat belastingen bij?

2018-09-08 16:50 belasting [permalink]

Iedereen met een laag loon gewoon een bedrag bij geven is een slecht idee. Alleen al vanwege het drempeleffect. Voor iedereen net boven de limiet voelt heel sterk dat ze net uit de boot vallen, iedereen net onder de limiet zal vreemd genoeg zelfs een inspanning moeten doen om iets minder te verdienen om het voordeel te behouden. En in een situatie waar je net de grootste moeite hebt om aan een inkomen te raken, is dat ongewenst en het zelfs ontwrichten.

Ik dacht een tijdje terug aan een ander voorstel. We betalen in theorie allemaal inkomstenbelasting. Zelfs al is dat de ronde som van 0€, je doet jaarlijks een aangifte van dingen die belast worden of je een vermindering opleveren. Stel dat de berekening no zo wordt aangepast dat het finale cijfer voor iedereen nog eens door een formule moet van de tweede graad. Een dergelijke parabolische exponentiële Curver kent een verloop met opstaande armen zowel links als rechts en een breed diep dal. Mits te kiezen voor specifieke factoren in de formule kan je dat zo mikken dat een origineel bedrag van 0€ uitkomt op 500€ (of meer), en dan gradueel naar beneden gaat, misschien zelfs onder nul voor de modale burger met een gemiddeld loon, en daarna terug omhoog voor de veelverdiener, en bijgevolg extreem hoog voor de absurd onbeschaamde geldscheppende.

Dit plan lijdt niet onder nadelige gevolgen van een opgelegde drempelwaarde, maar valt mogelijk wel door de mand als je rekening houdt met de gewoonte van mensen die met meer geld omgaan dan de modale burger om creatieve boekhouders aan te spreken zodat er een aanzienlijk deel toch niet onder de inkomstenbelasting valt.

Maar ik ben dan ook geen doorwinterde legistator die daar wel iets op kan bedenken.

→

Done! Feeder now on PostgreSQL

2018-08-31 20:25 feederpq [permalink]

Tadaa! Thanks to DataLank, I was able to switch feeder from SQLite to PostgreSQL in roughly one evening. You just need to change ifnull to coalesce, (and SQLiteData.pas for LibPQData.pas ofcourse) and storing Delphi's TDateTime values now map to genuine timestamp values, so it's a little different to do arithmetic with...

But I was getting some 'database locked' errors, so I guess it was the best thing to do, since SQLite works really well but isn't quite designed for use by a website, let alone multiple processes. Sorting by timestamps appears to take a little more processing power than I was expecting, so I may try to change back to storing them as double (since that's also the value TDateTime uses internally), or I may just be missing an index that could speed up the query. It takes some investigating to find out, but that's for another day...

Update 2018-10-12: With some regret, I need to inform you that I have switched back to SQLite, perhaps for the time being. Though operation was acceptable, I noticed quite some performance was lost on queries that depend on the values in the fields of type timestamp without timezone. I've had a look if I could fix this by adding indexes, but wasn't successful. I was also thinking about changing the date-time fields to float, as that's what's actually used in the Delphi code that handles the values, and would probably get better performance in comparing and sorting in PostgreSQL, but the time it would take to switch that around would exceed the time it takes to switch back to SQLite. And switching back to SQLite offers a situation that has shown to perform well in all cases. With this switch I can find some time (somewhere?) to read up on PostgreSQL and timestamp fields, and what I'm missing that was causing some queries to take abnormally long. The query that averages times between posts, prior to checking feeds for new posts would regularly take over 100 seconds, a query that SQLite would only take seconds over.

→

Archive... Search...