[permalink]2017 ...
januari (4) februari (2) maart (6) april (3) mei (4) juni (2) juli augustus (1) september (3) oktober (5) november december (1)
2017-03-06 23:03
TRethinkDB
[permalink]
I've given it another try and, in part thanks to a Windows executable that performs well, and thanks to the gentle people over at the rethinkdb-dev group, I've got something working. It appears the basic functions you would expect from a driver work, but more advanced queries need some more extensive testing. (I've read about a driver testing harnass, but to replicate that around my driver, sounds like a separate project in its own.)
There are some strange sections in the design of ReSQL that show it was written for a weakly-typed language, but using variants and interfaces, I hope I've struck a nice balance between versatility and still having the best suitable methods showing up on auto-completion. Something that should be there may be hidden from view this way, but will probably be because of inaccuracy or error of my part.
Which leaves my in roughly the exact same position as I was closely after completing TMongoWire: having success learning about a new(ish) NoSQL DB the hard way by trying to connect to it directly with Delphi, but nothing in the way of an effective application that would use it for something vaguely useful. I've learned some people have effectively created things with TMongoWire (yey!) but I myself don't really have a good idea (or the motivation) to build something on its own that would use the features of these new database services to their best intent.
If you've got a good idea, please let me know. If you want to know more about TRethinkDB, let me know.
2017-03-07 18:53
lijn
[permalink]
Hoe het bij mij zit? Awel kijk. Het is moeilijk om te weten wat er gaat komen. Niemand kan de toekomst voorspellen. Soms is dat jammer, soms lastig. Heel misschien brengt het je angst, maar eigenlijk is het een uitdaging. We moeten ons behelpen met wat we weten van voorgane opvolgingen van oorzaak en gevolg. Dingen die je zelf hebt waargenomen, dingen die andere hebben waargenomen (en al dan niet willen delen). En daar moet je voor een stuk zelf naar op zoek. Je kan wachten tot je het nodige vanzelf oppikt, maar als je weet waar je naar moet zoeken vind je al snel heel veel meer. (Soms zelfs te veel en soms verkeerde dingen, maar da's een ander verhaal.)
Het moeilijkste in het leven is andere mensen dingen doen doen. Dat is zo de laatste paar jaar een motto van me aan het worden. Als het genoegen je te beurt zou vallen dat je van die kleine mensen fatsoen moet bij brengen zal je (nog beter) begrijpen wat ik bedoel. Maar het geldt in het algemeen. Zoals bij katten hoeden is de basis-regel dat je moet proberen maken dat ze willen doen wat het is dat jij wil dat ze doen, maar gelukkig is er nog voor wat hoort wat en misschien zelfs handel in goederen en diensten. Daarbij komt dan een sloot theorie over ethiek en afspraken en gemeenschapsgevoel enzovoort enzovoort...
Misschien lijken die twee niet verwant, maar op een vreemde manier is er wel een fijne samenwerken tussen die twee. Zo is het me gaan opvallen dat als mensen begrijpen dat je iets meer dan de doorsnee bezig bent met wat er komen zal, zowel op korte als lange termijn, en goed over de argumentatie hebt afgewogen, dan krijg je wel eens een doordachte vraag ten gronde over het een of het ander. En dan doet het deugd dat je kan antwoorden en al dat onderzoek van pas komt. Dat er misschien zelfs ook voor nog mensen naast jezelf iets duidelijk wordt over wat er komen gaat. Wat er nog moet gebeuren en wat niet. Dat schept een band. Je wisselt een beetje krediet en/of vertrouwen, en krijg je misschien al eens iets gedaan van mekaar.
Maar dat is een heel gevoelig evenwicht. Het doet goed als dat goed zit, maak ik me zorgen over als dat niet goed zit. Kortom, daar vul ik mijn 10 seconden mee tussen WM_ENDSESSION en Frequency Kenneth.
And for the people that do the speaking in English, a while ago I've written here around about the same things.
2017-03-09 01:22
jsonDoc110
[permalink]
While working on TRethinkDB, I noticed something was wrong with document re-use. My original idea was to re-use a single IJSONDocument instance to process a list of similar documents, but keep the set of keys allocated, only overwriting the values from the new document. (If you're interested about the code, search jsonDoc.pas for FLoadIndex.) Nothing an extra internal-use interface can't fix. Then I noticed that IJSONDocument.ToString could do with a revision because it wasn't using the new IJSONEnumerator, though it should.
Then I noticed the feature I once added to function JSON, where you could declare embedded documents by listing a value of '[', and closing the document with a key of ']'. The problem is that '[' could be a perfectly valid value! If it were to come via a variable, that would change the behaviour of the JSON call, and that's a big no-no. Also square brackets usually mean arrays in JSON-land, so it's perhaps confusing that I chose square brackets because you already need them in the JSON([...]) call. So I changed it into a key suffix of '{', and a closing key of '}', counting on braces being really abnormal in key names. If you really need a key name that ends with '{', don't use the JSON function, but just d['x{']:='y';
A minor downside may be that JSON calls with braces in the string constants, break the comment block if you want to comment out a section of code with braces, but there's always (* *) or //. It by far doesn't outweigh how elegant this new solution is, but it's a breaking change (existing code using '[' values won't work correctly any more), so instead of version 1.0.6 I think it deserves a jump in minor version number to 1.1.0.
While I was at it I fixed some minor issues with jsonV, so remember to update that one as well. Hope you enjoy the changes. (Next up may be replacing TMongoWire's bsonDoc with jsonDoc...)
2017-03-13 15:07
msxml2
[permalink]
O my god I can't believe this isn't somewhere on the net already! I come across this question and ofcourse there's the default discussion about Indy and OpenSSL/LibreSSL, and Arnaud is very (very!) right about proposing to use WinHTTP. I personally would see if I could do it with MSXML2's XMLHTTP object. Contrary to what it looks like, it doesn't really have to do much about XML, and you can do really almost all of what you need out of a HTTP request with open, setRequestHeader, send and responseText or responseStream, with a much more straight-forward syntax. (If you can live with COM.)
Plus there's another pretty sound reason: back in the days, when using WinHTTP and/or VBScript (for the RegExp component...) you would make it very clear it would only work if you got Internet Explorer version 5.5 or newer installed. "How much back was this?" I hear you ask? It depends, but it's so far back that pretty much all of XML things came after, and XML being to closely related to data-processing, Microsoft needed to put MSXML*.dll deeper into the system than its web-browser. If it's tied to the MDAC or the actual core system I'm, not sure, but years of use and the success of AJAX caused it to get very many security updates. I suspect a far bit more than the DLL that handles your WinHTTP calls...
So, without further ado, do as I do and import the "Microsoft XML" type library in the most recent version you can find on your system:
On old Delphi versions (e.g. the venerable version 7) open 'Projects' on the main menu, then 'Import Type Library...', then select "Microsoft XML, v?.0 (Version ?.0)" from the list. Your system may have multiple versions installed, pick the highest version number (in my case 6.0). Uncheck "Generate Component Wrapper" as usually you don't need this, and actually have the added benefit of automatic reference counting when you use interface references to keep track of COM object instances.
On newer Delphi versions, I've noticed the import functionality has centralised, and is now under the 'Components' menu, the 'Import Component...' option and you need to select "Import a Type Library" from the first list, and then search for "Microsoft XML".
This will result in a automatically generated MSXML2_TLB.pas that you otherwise don't need to worry about. Except perhaps include it in all of your projects you'd launch HTTP requests from.
Use the CoXMLHTTP.Create class function to get a new XMLHTTP instance, and it's open and send methods to make magic happen.
uses MSXML2_TLB;
procedure TForm1.Button1Click(Sender: TObject);
var
r:XMLHTTP;
begin
r:=CoXMLHTTP.Create;
r.open('GET','http://www.google.com/search?q=hello+world',false,EmptyParam,EmptyParam);
r.send(EmptyParam);
Memo1.Text:=r.responseText;
end;
There's more ofcourse. This is just the basics. Depending on what you need to do there's HTTP POST and ways to correctly encode values into the request body you pass to send, using setRequestHeader. And if you need to handle larger chuncks of data, you should check out responseBody and perhaps TOleStream declared in AxCtrls.pas.
A story about two task-keeping-applications.
2017-03-18 17:22
s2tka
[permalink]
Let me tell you a story of two task-keeping-applications. Once there was a team that was struggling to keep track of the work it was doing, had done, and still had to do. It was frustrating to work on the team, hard to schedule things, almost impossible to estimate when things where going to get done. And since clients are what they are, changing requirements and additional requests would cause much more disruption than expected of a team that calmly and firmly is determined to deliver the best of market solution.
An internal brainstorming-session about what to do about it, ended in two opposing visions about what decent issue-tracking should be about, and how a system that (co-!)operates with the team members should be structured internally, should behave, and which duties it should perform either by itself, or by effect of using its rules and restrictions correctly as designed.
In an attempt to get to the best solution, two teams were formed to develop each a project based on one of the two views. An evaluation would follow determining a winner, or if would it be possible to synergize the best parts of both into a single system.
A side note: from a managerial point of view this is a very tough decision. Allocating a lot of resources to work on internal structure, takes resources away of the work that brings in revenue, and such undertakings typically risk getting frivolous or spinning out of control. But I guess it's normal that all stop rowing to help keep the boat from sinking. So, apart from being intrinsically aware of the exceptionality of this opportunity, coordinators were given instructions to keep to a strict schedule in these projects and a determined focus on delivering a workable proof-of-concept quick. Sounds like a good work-ethic to apply generally, if you ask me.
A few weeks later progress was made, and the prototypes were already being used to keep track of the issues of these new task-keeping-applications and other projects. The main difference between design visions became apparent soon enough.
One application centered around the list of work items. Care was taken the entry form was extensive enough to have fields for all of the details about a work item, its categorization, its relation to the project, an outline of the projected outcome. An overview would show the current list, possibly filtered for those items assigned to you.
The other application was centered around getting information out of the system, especially structure and relation between items. Users would enter small specific reports, and add them to the best suitable node in a tree-structure, optionally marking relations with other items over branches. The overview showed an expandable structure starting at the root items. It also could have a filter applied, but would potentially show you an entirely different structure of the same data, when using a different relation type.
Having two working prototypes, attention gradually reverted back to the serious work and some of the frustrations of before were abated. After a few months an evaluation was undertaken.
One application had rendered itself useless. The first weeks of usage, a lot of entry happened, but without consensus about categorization, the list was enormous without a clear way of grouping relevant items. Duplicate entries and ambiguous task-descriptions were unresolved, causing confusion.
The other application was doing better. It needed work, but offered a good view of what had to get done.
Enough about the story. Reality, of course, is much more bleak. As no sane manager would make such a shift in resources of a troubled organization, the 'two teams' actually stand for the existing team using an off-the-shelf something badly administered on one side, and on the other side, well, just me, toiling on something potentially better, in my off-time.
I started — like many — with a plain text-file, then a spreadsheet. Then I took the step to design a database for it, but wanted something to do entry and retrieval with roughly the same ease-of-use that a spreadsheet would offer. Working with tree-structures for some other projects, I wanted a single structure to serve as the basis to store data in. Specifically with projects and tasks — as projects tend to have sub-projects, and tasks split into sub-tasks — using branches of a tree would enable to keep this distinction conveniently vague. If you add representation for entities like users and clients into this tree-structure, and relation between nodes over branches, you've got a richness to model much more of the world, and keep track of its changes, past and future.
From there it grew slowly, over years, into what it is now: tx. First versions suffered a notoriously bad interface, but I hope that has improved. For long I was its only user, but some cooperation features have been added since. What's left for me is to keep improving tx where possible, and demonstrating it to people what it's about.
Though entry and structure is important, where a task-keeping-system can really shine is helping to keep an overview. A cleverly designed filter can limit your view to exactly these items that are relevant to you, but in tx you get the additional option of having these items display with exactly those sections of the tree-structure they have in common. Also, I personally feel the most important items on any list, as long as it may be, should be on top. So when tx displays a list of items, they get ordered using their weight, determined by a combination of factors such as task-type and current status. As a task progresses from an active state to a final state, it may move down the list or even fade from view into an archival state.
And there's much, much more I could talk about, but it's all created out of necessity and designed adhering closely to a central vision of what a task-keeping-system should be and what it should be doing for you in order to be able to depend on it.
In conclusion, and for those people that — like me — skip long stories to the last paragraph, it's so very important that information systems succeed at keeping an up-to-date model of reality, and offer you the freedom and easy to update it's view of the world. Especially so with task-keeping software you depend on to keep track of the progress you make with projects, and to help stay on top of what's important. All of that served as the basis for developing tx.
2017-03-24 21:57
boxer
[permalink]
Drats. I thought I'll try something like Clover does, start with SetParent on any top-level window you could find with GetAncestor(GetForegroundWindow,GA_ROOT) and see what it gives. There's this old default MDI child mechanic that starts working, so I thought this might just work. But it looks like over at Microsoft the Windows 10 team decided to cut some corners. The theming doesn't do it's modern stuff and reverts to Vista-style borders, and the newfangled calulator, for example, won't even take the SetParent nicely any more. Oh well. For the time I'm still on Windows 7 at work, I guess it'll come in handy there for the time being. Probably in about a week I'll know if this could work where other desktop-management tools failed or were too cumbersome or too invasive...
How does it work? Boxer starts with an empty window, and will show an icon over the top-right corner of other windows. Click that to 'box' the window. The top bar shows a tab for each boxed window. Right-click to open a menu with options to unbox or close, and drag to reorder. Multiple instances play nice with each-other and show 'boxing handles' next to eachother, the second instance labeled "A", the third "B", etc. To disable the boxing handles, right-click on the top bar to the right of all tabs.
Anyway, if you feel like having a try if you can do better, have a look at the code here. Download a binary here: Boxer.zip (209KB)