Feeds:
Posts
Comments

In “The State of the Octoverse ” for 2019 Github writes:

And for the first time, Python outranked Java as the second most popular language on GitHub by repository contributors.

Not bad – JavaScript takes first place, Python and Java follow.

Talking about Python allows me to announce that I hacked my first Python application ;-)

You see, I’m still running an old version of Trac to track issues and document my developments. Old means: version 0.10.5, and the problem is that I don’t have the time at this moment to upgrade to the latest version. So when I had to move to a brand-new Windows 2016 server I just took the existing installation instructions and got Trac running fine, although not under the wings of IIS. Except for one thing: the new server was behind a firewall and a virtual IP address (VIP), the latter also taking care of HTTPS to HTTP conversion. So when my browser sends an HTTPS request, Trac sees HTTP traffic and responds with HTTP redirects when replying to certain actions. Those replies turn into error pages in the browser, since HTTP traffic from the browser does not pass the firewall and is not intercepted by the VIP…

I have been reading up on Python, but I can’t say I have developed anything seriously in it. Python is however sufficiently readable so that I easily found my way in the code. To solve my problem, I just had to force Trac to always redirect to HTTPS URLs. As far as I can tell, I had to change but a single line of code to make that happen. Here’s the code of the ‘_reconstruct_url’ function after my hack:

Image of the Python code for the function '_reconstruct_url'

I changed lines 226-227 to the single statement in line 228

I’m calling this a hack because it only solves my problem; this is not something you want to submit to a public repo. It also means that the application no longer responds to standard HTTP requests. But it’s good enough for now.

From what I have seen on the Trac website there are solutions for running later versions of Trac over SSL, but most (all?) of them seem to rely on an SSL front on the same server as Trac. Too bad that such a solution won’t work for me. Guess I’ll have to study Python and Trac a lot deeper to find the best way to cope with the architecture at work.

I can’t help it: when I see a BMW R1100S for sale online, I have to check out the pictures and the specs. These days, a user called Julien is selling this Randy Mamola edition of the R1100S. It cannot be denied: the bike is looking fine after about 15 years on the road. It’s a bit too flashy for me – I don’t go racing every weekend, or ever.

A BMW R1100S in a nice and sunny setting

Nice bike, nice picture!

Will it fetch the asking price of 6000€ ? No idea. Will its new owner like it? Sure hope so!

Contrary to what happened in the previous months, our solar panels delivered 112% of the average photovoltaic electricity in November months for our system. November 2019 will thus help us reach yet another year with over 2MWh – even a dark December should deliver enough to make that possible (at least, that’s what I hope).

 

I have been using Grive2 for a couple of years, to help me get the numbers from our photovoltaic panels into Google Drive storage. That has been going very well… until today.

The new or updated files from my panels did not show up today, although they had been created correctly on the EeePC. When I tried the Grive2 synchronisation by hand, the tool reported a 401 error: access not allowed. I suspected an issue with the Apps authorisation for the Google account concerned, so I deleted the existing ‘grive’ App and launched a new registration request. Alas, to no avail; this is what Google had to say:

Why, oh why, Google?

All I can say is: come on, Google! This has been working fine for a couple of years – why cut it off now? If you really had to cut off access, why not alert the its users first? And what is “temporarily”: a day? a week? forever?

I will copy the files by hand for a few days, but that solution won’t last long. After all, we automate processes so we don’t have to remember doing them, the more so when the process is tedious. Copying files by hand is tedious, and error-prone too…

This (my!) Macbook Pro from 2012 is still in a fine condition, and very usable, e.g. to maintain this blog. It may be 7 years old, but is by no means too old to be productive. I have no trouble keeping it up to date, at least until now: it is running Mac OS Catalina.
About window of the Macbook Pro

Since I took the screenshot Catalina has been updated to version 10.15.1.

Exactly 10 years ago it took just a few hours to install 16 photo-voltaic panels on our (flat) roof. We chose Solyndra panels, because of the ease of installation (that part was certainly true). We knew those solar tubes would be a bit less efficient than traditional flat panels, but less weight on the roof counted for something too, in our eyes. Given the available surface on the roof, we hoped to cover somewhere between 40% and 50% of our annual electricity consumption.

Unfortunately the end of 2019 was also the period when Solyndra started having problems delivering on their promises. I suspect that the panels we finally received are not as productive as promised. In numbers: we’re only now (calendar year 2018) seeing the (almost) 40% coverage of our yearly electricity consumption that we aimed for, and that’s because one of children isn’t living here anymore, not because the panels are so powerful ;-) Oh, and we also tried to reduce our consumption, if only by a fraction of the total.

solarpanels.jpg

The reflective foil below thee panels isn’t white anymore…

Even so: according to the pvoutput.org website where I keep track of the numbers, we have already saved more than 22 tons of CO₂. That’s not earth-shattering, but it’s a start. In theory, we’re only halfway through the lifetime of the installation. We’ll see how that turns out a decade from now ;-)

A few days ago I tried to use KeePassium on the iPhone. Yet another KeePass app, you say? Yes – because it pays to be open to change, and in this case because KeePassium promises to sync automatically with any of a list of cloud storage providers. That promise means you can not just use DropBox, but also Google Drive, iCloud Drive, Synology NAS, and more, to store your file(s). It’s nice to have more choices when it comes to safely storing your passwords.

My current KeePass app, MiniKeePass, requires an explicit manual “Save to…” and “Open in MiniKeePass” actions to keep your cloud copy in sync on multiple devices. I tend to forget those “Save“s and “Open“s now that a iPhone is my daily phone; on my Galaxy S7, Keepass2Android requires just a “Sync” to figure whether to save its local copy to the cloud or to get the cloud version if that is more recent (and vice-versa, of course).

So I downloaded KeePassium, and pointed it to a copy of my .kdbx file. Unfortunately, the app wouldn’t / couldn’t open it, although it claims to compatible with all versions of KeePass files. Strange – or perhaps a bad copy on my side? I don’t know, since the error message wasn’t very clear. This means I will stick with MiniKeePass for the time being, knowing that I will have to look out for another KeePass-compatible app soon…

Why should I replace MiniKeePass? To begin with, the MiniKeePass app is no longer actively maintained, going by the updates to the source code on Github: the latest updates are from late 2017. And it shows: in iOS 13 I can see a few mix-ups in the user interface. For example, look at this:

Is MiniKeePass in Serious Trouble?

It’s not the only KeePass-compatible iOS app that is getting (too?) old to be worthy of attention. Check out the list of ‘Unofficial KeePass Ports‘ and even a cursory glance at the majority of entries will turn out to be (very dated). One version even goes back to 2010 – that’s almost the prehistory in IT terms. Others are more recent but require payment to get rid of ads – without any guarantee that the app will work with my files.

Let me be clear: I don’t mind paying for an app, especially for an app that will guard the hundreds of passwords I have to store. But then I want an app with a better-than-just-good UI, since I will be using it every day; I want automatic syncing with a choice of cloud storage providers; I want serious support, at least in the form of regular and continuing updates to comply with Apple’s progress. And ideally the source code of that app should be audited by independent security specialists, to make sure that it is indeed a secure and safe implementation, worthy of a user’s trust. I’ll keep looking! Your suggestions are most welcome, too.