With the security updates for the OpenSSL project that come out, I started to face an issue as a developer who uses them in projects that I develop. I get an update, and I need to make sure that the new DLLs are put into the “distribution” directories for the projects, so that next time they are built the new DLL will be included “automatically”. But my projects are all over the place, and manually finding and remembering which ones to update is time consuming. Sure, I can use a search tool, but that leave the “go to the location and paste the files”.
So I wrote a tool to scan my disks and tell me which version is in situ. And then, if I want, to update them. The optional part is important because not all applications should be updated – there may be incompatibilities. An update is now much easier. You can put the new files, “ssleay32.dll” and “libeay32.dll” in the same directory as the updater if you want. It will create a “fileoptions.xml” file in the same directory too (so don’t put the updater in Program Files or other similar reduced access rights directory). The folders to scan can be separated with a semi-colon, so “C:;D:” will scan the C and D drives. Note that there must be a trailing ”. Then scan (it is a background thread for speed). Click to select any you wish to update, and it will do so.
One thing I often ponder is why I like the RemObjects SDK for my developments, when things like REST are “free” and perhaps more standard. The simple answer is that my code looks just like any other code I write. For this example, I have written a demonstration “chat” application. You log in, you can post messages, and you get all the messages from the server. This is the procedure that sends a message to the server:
procedure TfrmLogin.SendMessage(szMessage : String); begin m_xChatService.SendMessage(szMessage, SendMessageComplete, OnLinkError); end;
There’s no building up a URL, no encoding of parameters. Just a normal function call to a class member. If this wasn’t a WebBuilder function, I’d not have the SendMessageComplete callback – it would just wait until the call returned, but the browser is always asynchronous, so we have the callback:
procedure TfrmLogin.SendMessageComplete(nResult : Integer; szHumanResult: String); begin Report('Sent: ' + szHumanResult); end;
That’s all there is in the client for normal coding. On the server, this is the code that implements the service:
function TChatService.SendMessage(const szMessageJSON: Utf8String; out szHumanResult: Utf8String): Integer; begin Result := 1; g_xMessageList.Add(szMessageJSON); end;
The finished result:
I backed the Pebble watch on the second day, so I got my shipped Pebble fairly early in the delivery process. I was asked by a friend recently how I was getting on with it, so I emailed a response, and he said “I wasn’t expecting a blog post”, but why not post it anyway?
Overall the Pebble is exactly what I thought it would be, and done very well. There was a lot of talk about the iWatch type stuff and how Apple would do one with a touch interface and apps and concepts on how you would select them. But that misses the point in my opinion – what you want is an interface you don’t have to look at. One night I went to bed in a hotel room and wore the Pebble. I was able to listen to a podcast and to turn it off when I was about to go to sleep without having to look at anything – I can feel the buttons to know which one to use, and the order. In the middle of the night, I could check the time by shaking the watch and using the big number style so my blurry eyes without glasses could still make it out. Podcast control is great, and handy to pause from across the room when the kids come in making noise, to rewind a bit after, or to skip adverts. You cannot do those when your watch needs you to do fancy touch gestures.