Lightly Seared On The Reality Grill

Random expat geekery from The Low Countries

Browsing Posts in Linux

Looptastic

No comments

While playing around with Dicetastic earlier this week, I started to feel the need to optionally loop the program so that I didn’t have to repeatedly re-execute the command. This is now implemented and the latest and greatest version has been committed to GitHub.

The changes are documented on the Dicetastic page but the shorter version is that if you start Dicetastic with a -l or --loop, it will loop until you attempt to roll 0d0.

As part of this, I have added two methods to the Dicelib library, get_sides and get_count. They are documented, but their usage should be obvious.

flattr this!

I have, over the past few months, noticed a bit of an oddity in my IT-related behaviour (I already knew about the rest of my behaviour). I work as an IBM i developer and, over the years, I have jumped on an started using pretty much every graphical tool I can find. Then I go home, boot up my Linux powered laptop, and spend half my evening in the terminal.

So why the disconnect?

I think it comes down to the fact that modernisation has become a hot topic within the IBM i community over the past few years, and it’s a bandwagon that many people jump into without pausing to define what they mean by ‘modern’. The result is that a great deal of emphasis is placed on the application front end with nowhere near enough thought being given to what overheads these tools incur.

Obviously, graphical tools have many advantages. A well designed GUI is intuitive, easy to use and can put a great deal of information onto a screen in an easily digestible form. There is, however, a performance overhead to be taken into account – both in terms of network traffic and the load on the local user’s CPU. For many applications, especially applications aimed at the business end-user, this performance cost is well worth paying.

For the technical user, though, it’s not quite so clear cut.

Once you know your way around an operating system, and the text-based tools that come with it, it is often the case that the command line is a quicker and more effective method of completing a task. In these cases, the GUI approach gets in the way of achieving stuff and becomes a source of noisy frustration (as the unfortunates who share an office with me can attest).

GUI based applications do have their uses, of course, and there are plenty of tasks for which a graphical approach is the most appropriate. But sometimes it isn’t.

The challenge, therefore, when faced with a shiny new tool is to ask yourself this: How will this tool make my life easier?

flattr this!

It was in the middle of last year that I implemented what I rather ambitiously referred to as a wallpaper switcher for Gnome 2. What Macsen’s Transitioning Background does is generate an XML file based on the images in a selected folder and then let the Gnome background switcher handle the rest.

With the switch to Gnome 3 this functionality is no longer supported. At least, not as far as I can tell.

I do still like the idea of using an XML file to control the background and have been toying with the idea of knocking together myself. As a first step towards this, I have tidied up some of the code.

The latest version of the source can be found on GitHub. The generated XML can be used to power a transitioning background in Gnome 2 and – if I ever find the time – I will start knocking together something that will work under Gnome 3.

flattr this!

Linux distributions already make it easy to try them out without comitting yourself beyond your comfort zone. Most will guide you through partitioning your disk so that you don’t lose what is already installed, and may provide live media which allow you to boot from a CD, DVD or USB stick and try out the distro without any risk whatsoever.

Canonical, the folks behind Ubuntu, have now made it even easier to try out their distro with a virtual desktop online (which I found via +rich scadding).

While Unity is not for me (Gnome Shell FTW) I do think that this is a great idea, and one that has been very well implemented.

flattr this!

I mentioned yesterday that I had been playing around with Pylint and slowly cleaning up my existing code. The first result of this can now be seen online – I have just just committed the cleaned up code for Dicetastic to my GitHub repository.

flattr this!

I spent most of yesterday evening playing around with Pylint, a static analysis tool that reads your source code and looks for common mistakes. I found a lot.

You can find Pylint in the Sabayon repositories, so it can be installed with a simple equo install pylint and then you’re off.

Running Pylint over a random module, the first thing that surprised me was just how much information the application provides. The first thing it gives you is a line-by-line list of issues – this tells you exactly what problems your code has, and where these problems are. In my case, the vast majority of these were Convention and Warning types, indicating that I really do need to clean up my Python coding style.

It then provides a number of reports which gives you a stack of metrics by which to measure the quality of your code. These were interesting, but would probably be more useful if I was running Pylint over a larger source file.

The approach I found most useful was to go through the list of issues and, for the obvious ones, just fix them. For less obvious issues, I found myself going to the Python documentation to understand why the issue had been raised and what was wrong with my existing approach.

There is a lot of documentation available for Pylint and a goodly set of configuration options. I have looked at neither so far because the reports that it generates are so self-explanatory that it is very easy to jump right in.

This is a tool I can see myself using for a long time to come and, as codebases grow, this is a tool that will become increasingly useful.

flattr this!

Just a quick note to confirm that a Dicetastic project page has now been added to this site.

I do, at some point, want to put a graphical front end on this but I tend to find GUI programming annoyingly fiddly so I won’t make any promises as to when this might appear.

flattr this!

When I started trying to teach myself to program in Python, one of the first applications I wrote (apart from the online and printed exercises I could find) was a simple dice rolling application. For a selected number of dice, it would calculate the rolls and return them as a list.

As time went on I tinkered with this a bit more, separating the guts of the application from the (admittedly simple) terminal interface. I have now cleaned this up a bit and put it on GitHub. Dicetastic consists of a library and a simple program that uses the library.

I’m not convinced that anyone will actually find this useful, but I do know that it isn’t doing anything just sitting on my hard drive.

I will put together a project page on this site for the application (probably tomorrow) but, for now, the code is up and you are welcome to take a look.

flattr this!

Xfburn FTW

No comments

When Brasero starts repeatedly freezing, Xfburn saves the day.

That is all

flattr this!

When Gnome 3 was released I have to admit to being less than enthusiastic. So much so, after trying out a live USB, that I was seriously expecting to end up switching to XFCE. However, having used it fore a little over two weeks, my opinion has rapidly changed. It is true that the Gnome 3 desktop attempts to impose a new workflow but, going with it, I have found that dividing tasks across different workspaces does allow me to focus far more on the task at hand. This brings me to the point of this post.

Much electronic ink has already been spilled over the question of minimise and maximise but the shorter version is that the Gnome team wants people to organise tasks by workspace and not by having lots of minimised windows. Fortunately, you can switch these buttons back on and I was quite pleased to discover that the Sabayon implementation does this by default. This made the transition to Gnome 3 a lot less painful than it could have been.

Now, however, I find that I really don’t use these buttons any more. So, with a strong feeling of removing the training wheels, off they go.

I really do like the way that Gnome 3 has been designed. The UI is polished, works well and stays out of the way when you don’t need it. It is also notable, for a desktop environment, just how little I find myself needing to use the mouse.

It’s not perfect and there is is still a way to go, but so far I am finding it to be a polished and very productive desktop environment.

flattr this!