Freeware:

                |

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.

→

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.

→

"How can i do C++ for free?"

2018-08-30 10:54  freecpp     [permalink]

Someone at work asked me "Is there a way to do some C++ for free?", and told me to mail some links. I did and thought it's a kind of nice overview, so I post it here as well.

If you're looking for a free C++ development environment, the first thing I can think of is:

http://www.codeblocks.org/ 

but one of the main trendsetters has ofcourse always been Microsoft Visual C++, you can obtain here:
https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=15 

or ex-Borland's version with language extensions to make its UI designer work:

https://www.embarcadero.com/products/cbuilder/starter

if you're willing to get to work with just a compiler, then this one is getting good remarks recently, not only because it's giving usefull error messages: 
https://clang.llvm.org/ 

but there are plenty more:
https://gcc.gnu.org/ 
https://digitalmars.com/download/freecompiler.html 
http://openwatcom.org/download.php 
https://software.intel.com/en-us/c-compilers 
https://www.embarcadero.com/free-tools/ccompiler (or perhaps this one https://edn.embarcadero.com/article/20633 )

(or the list from the creator of C++ itself: http://www.stroustrup.com/compilers.html  )

but C++ is getting some negative remarks lately:
https://duckduckgo.com/?q=why+C%2B%2B+sucks 

so what is recommendable to learn? currently good candidates are:

https://dlang.org/ 
https://golang.org/ 
https://www.rust-lang.org/en-US/ 
https://www.lua.org/ 
https://docs.microsoft.com/en-us/dotnet/csharp/ 

and ofcourse:
https://www.embarcadero.com/products/delphi/starter/free-download 

→

RSS is far from dead!

2018-08-08 00:55  feeder      [permalink]

I've been using RSS/Atom feeds on and off since I've learned about them. A long time ago, Google had a nice feed reader, but decided to discontinue it. Users were left to search something new, and I settled on The Old Reader, combined with gReader since I had a smartphone, and all was well. For a while. After some time you notice you still get disturbed by some tiny issues you can't seem to get to go away, either with tweaking the configuration or with Stylus. So what does a developer do? Start to think about developing their own solution. Then plan to develop their own solution. Then develop their own solution. So I'm somewhat proud to present this little thing I've been tinkering on in off-hours the last month:

→ github.com/stijnsanders/feeder

I have a live version to try out here: http://yoy.be/home/feeder/ but it uses the neighbouring instance of tx for authentication. I should enable Google/Facebook/Github OAuth things instead, but finding out how that works is a few items lower on my wish-list (of things I wished I had the time to put into).

I wanted a feed reader without the extra's. I wanted to mark items as read that move out of view by scrolling down, and plays somewhat nice with the surrounding HTML and the browser. For now I like how it works. There's an issue with emoji's that apparently get eaten by UTF8Decode, but that could be a bug that got solved since good old Delphi 7. But now that Delphi has a community edition, I think I should bring most if not all of my other projects to this version instead of sticking to Delphi 7... But that's another story. (One you might notice some time in the future on my Delphi RSS feed...)

→

How to do timezones?

2018-07-17 23:53  timezones      [permalink]

I feel stupid. I guess I've been put out of my comfort zone. I was thinking about doing something, and then I did, and I thought I'll just primarily make it work for me, but then I noticed "new" items were still two hours behind. Ofcourse that's due to the bias against UTC we have here in my current local timezone. So there you have it. All my programming career, I would just parse dates, and stop before this "+0200" or "-0900" thing that's there at the end. So the right thing to do is go all the way, and with a little effort make it work correctly for not just me, but for any user of this little thing.

But how? I remember these drop-downs with timezones where I typically look-up Brussels or Paris. But it's summer daylight-saving-time for the moment. So it switches to and from only one hour between UTC twice a year (until policy changes), how do I keep track of that? Is there something that I can have the system do this automatically for me? It feels like these are things I should have known all along, but dont. I guess I'll have to start reading somewhere...

→

StackOverFlow/Delphi: new blood?

2018-07-12 21:30  sodnewbies      [permalink]

→ Stack Overflow — Newest 'delphi' questions

Am I seeing this correctly? I've been following this page somewhat less closely lately, but the majority of new questions is by people with not too high of a reputation score. And that's actually a good thing. Let me explain:

A while ago it looked like we were 'past StackOverflow peak'. StackOverflow started as an alternative to outperform all other question-and-answer sites for techies, by having a really well developed reputation system that allows a community to self-regulate. And it did. Both the reputation-system created a really fine repository of good questions and good answers, and all other question-and-answer websites were oblitherated (at least from the google top results on typical search-queries).

A few years later, StackOverflow appeared to struggle with having lost it's reason d'être: people with actual questions would easily mistake StackOverflow as a forum and saw most questions rapidly closed and reprimanded for not attaining an expected level of quality the community would hold to. This is a bad deal for newcomers and in general a source of bad feelings. They know about this over at StackOverflow. And have committed to take action. I haven't kept up to speed about what they're exactly plannig to do, but it could already be working.

Specifically for the questions tagged 'delphi', it's not only good that this way more people that just started collecting a reputation saldo, are posting valid questions and are getting helpful responses; I also think you can derive from it that more people are getting into Delphi. It's not up to me to tell whether that's in part because the most recent Delphi versions also successfully target mobile platforms, but if it's true I'm glad to know more people are about to experience the solidness of the Delphi eco-system, both in tooling and available components, and in solidity and reliability of your final result you're offering your users.

→

Archive... Search...