betabug... Sascha Welter

home english | home deutsch | Site Map | Sascha | Kontakt | Pro | Weblog | Wiki

Entries : Category [ digital ]
Things having to do with digital world items go in here.
[digital]  [language]  [life]  [security]  [media]  [zope]  [tourism]  [limnos]  [mac]  [athens]  [travel]  [montage]  [food]  [fire]  [zwiki]  [schnipsel]  [music]  [culture]  [shellfun]  [photography]  [hiking]  [pyramid]  [politics]  [bicycle]  [naxos]  [swim] 

04 January 2013

Attaboy X220 with atactl!

Spin that disk down

My Lenovo Thinkpad X220 has two disks, the Hitachi 320Gig drive it came with and a 64Gig Kingston mSATA SSD that I fit in there myself. The system (OpenBSD) and most of my home dir are on the SSD, which makes for a more responsive system. On the other there is a large partition that I mount into my home dir for the bigger digital cruft that always assembles over time. So in theory I could unmount the spinning disk and get more quiet and less energy consumption, but that didn't happen automatically. Yesterday though, my friend Rodolfo told me about atactl(8). Now that is a fun tool...

What I can do with atactl is first of all to see all kind of techy info about my drive like SMART status and power management state. I don't know why, but the state is always reported as "standby". More important though: The command sudo atactl sd0 sleep will spin down the drive and put it into "sleep mode". You can hear the drive spinning down and then emitting a little "beep", just like it does when powering down the laptop.

I guess this will save me some battery time. A first glance on systat sensors seems to indicate something like 0.5 Watt less draw on the battery, but frankly I have no clue how to interprete these values, they seem to be a bit all over the place. The next time that I will work for a long stretch from the battery I'll compare the time I get and see if there is a meaningful difference.

Spinning down that disk to "sleep" mode also reduces a lot of noise from the laptop. Now there is something that I don't need to measure, especially in a quiet environment. The "wirr" of the disk is gone, while the much lower sound of the fan is still heard.

Once the laptop was in suspend mode and waking it up again, the disk is again in spinning mode. Another way to spin it back up is to issue any other atactl command, even a simple sudo atactl sd0 to read out the settings. Spinning it up takes some time - so long, the first time I thought it wouldn't come back. I haven't tried directly mounting a partition from that drive while it's "sleeping", but I guess the OS will remember to spin it up again, and if not, it's easy to wake it up with atactl.

Update: One downside I just noticed: When the disk is in sleep mode, suspending the laptop takes a long time. Quite obviously the attempt to set the disk in sleep mode first wakes it up again: The disk light is on and the time to wait is about the same as when spinning up the disk manually with atactl.

Posted by betabug at 17:24 | Comments (0) | Trackbacks (0)
29 May 2013

The Island Sprint

A week of programming

It's already some weeks past, but this May 12 - 22 was The Island Sprint, most of it here on Naxos. We were five guys from four countries, who had come here and worked together for one week on our project. We had some new features to build or complete and some other tasks (like testing) to do. For me, the main advantages of a sprint are:

In difference to some other sprints, we were going out for food a bit more, which resulted in a bit less time for work. Also I was quite in the habit of going for bike rides and dragged most of the others along some of the times, some of them a lot of the times.

At the end of the sprint, we had two days that we spent on tourism (seeing a bit more of the island for those new to the place) and ... more bike rides, specifically me and tralala doing a 105km ride, which took us round Apeirantho and Apollona.

One of the most outstanding events was riding home in pitch black night on an almost totally empty country road, 4 guys on bicycles, brainstorming on some work topic. That ride will remain in history.

Posted by betabug at 16:36 | Comments (0) | Trackbacks (0)
27 February 2014

Crash, there Goes the Server

Yes, a lot of stuff doesn't work yet

So, there was a few days of outage here in On Monday morning, the venerable, old G4 crashed hard (as in: hardware). It didn't come back up again. One disk is truncated, one disk spins up, but the controller doesn't "reply". Some data exists in backups, some data exists in backups that consist of a tarball that is damaged.

I would say life is like that, but like is way more than that. I'm also way too busy to say much. I'm working to restore services (a lot already works again, some stuff is still missing). More will come piece by piece. Some stuff seems to be lost, gone. In any case, if there was something you can't find now, I'm sorry.

Posted by betabug at 16:08 | Comments (0) | Trackbacks (0)
01 March 2014

Get me the Book... Now.

Doesn't take long

As I'm slowly getting around to setup more and more of the server's stuff again, I remembered that I had wanted to get me the book Absolute OpenBSD when it came out. Well, it came out some while ago. I hopped over to the publisher and got me the ebook.

At which point I remembered how much longer it would have taken some years ago. I either would have ordered the book online, waiting some days for delivery. Or even ordered through a bookshop, hoping that they would get me the right one. Or I'd go to a bookshop with lots of tech books, hoping that I wouldn't end up with an outdated, older version by mistake.

Now I got the ebook, and if I had wanted it, I could have still gotten the paper version along for a few dollars more. What's more, there is no "DRM" or "copy protection" on the book, so no hassle. I even get the PDF along with the epub,

Posted by betabug at 11:25 | Comments (0) | Trackbacks (0)
11 June 2014

The site is coming back

Not all those who wander are lost

On the 24th of February my server had crashed hard. At first all was gone. Then some backups turned out to be well and kicking... but another important backup turned out to be an emtpy shell of a tarball. Years of data were gone. Nothing too important, nothing too personal.

I got the server's hard disk back, but with the information that it spins up, but the controller doesn't answer. I put it in a drawer and tried to forget about it. I put off fully restoring my site for a while, because I was busy and because it just wasn't a feel-good task.

Last saturday I hooked up the disk with an adapter to my laptop. The controller answered just fine, I could "see" the partitions. I still needed a PowerPC machine to boot the OpenBSD/macppc on the disk. I remembered that there was such a box in the hackerspace in Athens. Went there, booted the disk (worked just fine). It took me a while to get the data off it, because the system wouldn't let me log in from the console. Booting into single user worked, and getting minimal networking up worked too.

I now have my stuff on the laptop, and I'll be restoring more and more stuff as I get to it. You alreayd see the pictures are back at this weblog and the imagelog works again too. Plenty busy at work, so it still might take some time. But it's all there, and that lets me take a big sigh.

Posted by betabug at 14:17 | Comments (0) | Trackbacks (0)
13 June 2014

Getting into the Ruby Debugger

The missing fin

I was trying to debug a ruby script yesterday, so I searched the docs and the web for how to do this. Part one of the problem: various older versions had different ways to do this, having to install some gem or not, etc. Ruby 2.1 has something built in, so there I was. Put this in your code:

require "debug"

Simple enough (in Python it's "import pdb; pdb.set_trace()"). But then I got stuck, because the debugger was somewhere in the debugging code, not in my code. No mention of that in the docs or in the tutorials I'd found.

The solution was to step up from the current frame, with the debugger command:


which is short for fin[ish] - return to outer frame. The h command gives all the help you need - as long as you are used to command line debuggers like Python's pdb. But that fin thing had me searching and wondering for a while.

Posted by betabug at 13:36 | Comments (2) | Trackbacks (0)
30 September 2014

Matryoshka Code

One little class in another little class in...

In programming, a very old pejorative term is spaghetti code. Traditionally this is associated with languages like BASIC, where control structure is done with a lot of nested IF-ELSE structures, combined with jumping around with GOTO and GOSUB. I've seen my share of this and I wrote my share of this too.

But we seem to have a modern variant of this, which I would like to call "Matryoshka Code". The first time this name jumped into my head was when I had to do a bit with some "Zope Interfaces" or "ZTC" style of programming, where almost everything is an "adaptor", but it can be had in your plain old object oriented programming too.

What does it look like? One little class, inside another little class, inside another little class, inside... So your code needs do do something, e.g. a payment. Great, there is a PaymentGenerator class. You feed it some parameters and it spits out a PaymentHandler class thing. Which hands things off to one of a couple of PaymentProcessor based classes (based on if it's a CC payment or some other style of payment), and the actual act of connecting to the payment gateway is handled by the GatewayPaymentProcessor class (or maybe there are multiple subclasses of this, based on which one you're using?). Which hands off to another class for processing the result. You get the point, it's like one of those russian Matryoshka toys.

Oh, and it's not limited to OO programming and classes. You can do the same with plain old method calls of course (I have a very fine example here in some of my code). Classes are just a bit better to hide the actual functionality more, as inside the class obviously things will be done in a couple of methods too.

The good part: Code is served in small portions, often classes are quite small and don't fill more than a screenfull. Frequently they are trivially small. Small is also nicely testable. "This part works, let's go on to the next one."

The bad part: Just like with spaghetti code, if you have to read through and follow the functionality, you have to follow a twisted path. You are going to open a lot of little dolls, find out which little part of the task they do and hunt on for the next little doll. Frequently some parameter is dragged through all this little dolls of code, sometimes passed as a parameter to methods, sometimes set as an instance attribute. If your task is to change or update something, you possibly have to hunt through a lot of methods to check for side effects and parameters being passed in hiding.

You might be off good to test things, because functionality is packaged in small bites, it helps for refactoring some parts. But if you have to change a larger feature and you will find yourself go through multiple tests and methods with an axe. The feeling of "well testedness" evaporates fast.

So, what do I suggest? Nothing really, I'm just observing. If you want well tested code, you do have to cut things into little pieces. Sometimes people overdo it, and then instead of an if-else or case-statement you get a constructor class that spits out various other classes: The if-statement is still there, it's just hidden inside one or more layers of classes. There are moments when a single run of statements with a well presented, compact decision tree of if-statements gives a lot of fresh breath when reading through things.

In coding there is always some amount of "trying to think ahead" involved, a lot of it around which part of the code will be easily adaptable. If our factory class needs to grow another option of what to spit out, that's easy. But if some assumption or constant is hidden somewhere out of the way of the "main decisions", changing this can be a pain. So your "factory" can spit out all kind of vehicles, but somewhere you assume that all vehicles have 4 wheels... you just might need to overhaul a lot of little dolls if you want to start making motorbikes too.

Posted by betabug at 18:28 | Comments (1) | Trackbacks (0)
06 November 2014

Yepp it's broken

Hinge broken on Lenovo Thinkpad X220
Broken hinge on Lenovo Thinkpad X220

For a while there was a bit of play in those hinges. Then little cracks appeared, so small that I was wondering if they were just features of the plastic that always were there. Some days ago when I wanted to close the lid, the plastic cracked. Looks like that "super strong hinges on Thinkpads" thing doesn't always work out. Gotta check if this can be fixed.

Posted by betabug at 14:09 | Comments (0) | Trackbacks (0)
07 May 2015

Catching up with coverage... and finding some bugs

Bebu looking at things

Yesterday I noticed again that on one of my projects the test coverage is slipping. Now test coverage isn't everything, and hey, we're not that bad since lots of projects have no tests at all... but still I'd prefer the coverage to be at 100%. So in a moment of not wanting to touch any new tasks ("just give me something small to hax0r, a few lines"), I looked at the coverage report, trying to fill a few small holes.

A few of those small one or two line holes were quickly filled. A one line function without a test? Tchak, done! Some others were more mysterious. And then there was one that should have been easy to plug, but it evaded me. An if x not in some_list that should raise an exception was not covered. But once I wrote a test with assertRaises, that part of the code was not reached any more. You start to test for something and then it disappears? That would be a new one.

It took me some gazing at the code to discover that a (hidden) similar check a few lines above was already raising the exception. So that part of the code was essentially duplicated and useless. That's the morale of the story: Bringing the test coverage back to 100% might not make your code foolproof, but sometimes it just makes you look at the code again and spot a bug here and there.

Posted by betabug at 12:11 | Comments (0) | Trackbacks (0)
24 May 2015

Weblog Technical Status

What can we clean up?

There are currently some problems with the technical platform that this weblog runs on. Aparently once every while, the process runs out of memory, and then the blog is stuck. Funny, since with the new server, there is more memory available now. I'll have to check if there is some kind of memory leak or refcount leak happening. In the meantime, I've reduced some cache settings, and well, sometimes the blog might be unavailable till I "unstuck" it.

While playing around with the cache settings, I also cleaned up some of the other blogs I'm subscribed to in the sidebar. Sadly, some of them are offline now. Some others moved, and I've adjusted the feeds. I've also removed the links to the Zope planet (does not exist any more), and to the expat blogs site (can't identify with that any more).

Posted by betabug at 08:52 | Comments (0) | Trackbacks (0)
29 May 2015

Starting a New Project Naively Sure is Easier

Experience is not always an advantage

Starting a new pyramid fun project with some friends here. Sometimes I think that having experience with another pyramid project isn't always helpful. Instead of just writing my simple objects and growing them, I'm thinking: "well, for this kind of thing, we added xy and yz, and we made a feature to ..." and then instead of coding along, I'm sitting there, thinking if adding that feature right away makes sense, and if I should copy that bit of code or not.

Sure I could start with the simpler objects, but then I'd have to migrate them later on. On the other hand, if I try to do it all at once now, I can just sit there with a cup of tea for a couple of days and try to "waterfall" it all through. Have to find some middle ground somewhere, and have to accept that at least initially "migration" will be to the tune of "throw away your database and start over". Gotta get moving.

Posted by betabug at 18:04 | Comments (0) | Trackbacks (0)
20 July 2015

Power Failure Fooling Me

I didn't get the memo

This morning, just as I was hooking up the laptop to the big monitor, the power went out. Since the big monitor had displayed a problem with a power cord some days ago (or was it the cord that had the problem?), my first thought was "oh no, the monitor finally broke!" So I tried another cord. I tried another outlet. I moved it around, trying to set the power cord better, where it plugs into the monitor. No luck.

So I unplugged everything from the monitor, and moved it aside. Went to work on the laptop. Turns out, "the Internet" isn't working either. After a few tries and not connecting to the wifi, I finally look at the router: no blinkenlights. Here I must admit, my first thought was: "Oh noes! There was some power spike during the night, and both the monitor and router are fried!" In my defense, all I can say is that it was quite early in the morning.

In fact the power outage was no accident. According to our neighbors, there was an announcement for it. Well, I didn't get the memo, in more than one sense.

Posted by betabug at 13:18 | Comments (0) | Trackbacks (0)
07 October 2015

Begone Mail... Not!!

There she goes

Yesterday evening I was writing a lengthy mail, explaining a nice little idea. The mail was written in English and Greek, spellchecked, re-read, corrected a bit, and then... the battery on the laptop suddenly ran out of steam and the laptop shut down unexpectedly. I didn't feel a single moment of anxiousness. I'm using mutt to handle my mails, and mutt hands off to vim to actually write my stuff. As I know quite well, vim saves temporary copies of my files, so in case of a crash, I'm often asked to recover files. Works quite well.

mutt saves unfinished mails in a "folder" called postponed. Since I had closed and re-opened the draft mail a couple of time, I expected find the unfinished mail there. But it wasn't. Lesson learned: mutt saves those mails there only when you close the message and postpone it. OK, so far, but no problem, since definitely vim had saved my message.

But I couldn't find it. It was gone. It started to take the wind out of my sails, since I had spend some time to make a beautiful little piece of mail, and the thought to do it all again demotivated me. I started going through my disk with a fine comb. I found the path where my files had been. I checked where vim is supposed to save temporary files (the "dir" setting directive), and the documentation gave me a strong hint to what had happened, for that setting the documentation suggested:

"Using "/tmp" on Unix is discouraged: When the system crashes
you lose the swap file"

Explanation: If you save your "swap" backup files in the /tmp directory, when you restart after your crash, the OS will go through /tmp and throw your carefully saved backup file away. This is what had happened to my mail. But why?

In my .vimrc, I hadn't changed the dir setting, and the default is to store files in a list of directories that are reasonably safe: ".,~/tmp,/var/tmp,/tmp". For a moment I was pointing fingers at vim, but it just doesn't make sense.

In fact the culprit is mutt: The mail program tells vim to "edit this file" and to store the needed temporary swap file in /tmp. There is a settings directive to change the place, but the default is the very unsafe /tmp directory. So my suggestion: if you use mutt, check your config to set the "tmpdir" directive to something safe, something where your OS will not clean up at restart time, e.g. on OpenBSD /tmp/vi.recover is spared from the knife.

Posted by betabug at 10:57 | Comments (0) | Trackbacks (0)
28 January 2016

Reading Conflict Markers in Darcs

Doctor, it's an urgent case of RTFM!

Here I had to merge a substancial feature branch in our main development tree, with some complicated conflicts coming up. Since even with a small team of developers it's still rare to get conflicts working with darcs, when it's finally happening, enough time has passed for me to forgot details, and I usually have to look up what to do again.

I found the FAQ page on conflicts in darcs to be a good starting point, but quite often in the past I have gotten stuck on the darn conflict markers themselves. I mean, it's clear enough that here there be conflicts, but which point of the marker is which state?

It's not mentioned in the FAQ page. But that's ok for the FAQ page, since the answer is clearly a case of RTFM. Typing darcs help mark-conflicts into a friendly shell near you gets you:

v v v v v v v
Initial state.
First choice.
Second choice.
^ ^ ^ ^ ^ ^ ^

... which is nice and clear. With multiple conflicts in the same file, the "First choice" and "Second choice" are not always referring to the same patch, but usually things are clear enough for me once I figure out things this far. The hint to run darcs help on mark-conflicts came from the output darcs gives me when I try to apply a patch with conflicts.

Posted by betabug at 10:00 | Comments (1) | Trackbacks (0)
08 February 2016

Am I Lazy?

Let me lay under a tree for a couple of hours and ponder the question
Lying under a tree

In a discussion with a friend over lunch, he told me: "The way you describe your work, one could get the idea that you are lazy!" Indeed I am. Being lazy is a key ingredient to a good programmer. It's what makes us automate tedious, repetitive tasks.

On a further scale, I like things like riding my bike and then sitting somewhere under a tree, pondering all and nothing... and then churr churr my subconscious starts working on those work problems that keep holding the work up.

Being lazy makes me write automated tests for my program code, because a couple of hours writing those tests will save me many, many hours of searching when a problem in that program code appears in a few months. There are many more practical things like that.

Posted by betabug at 22:30 | Comments (1) | Trackbacks (0)
09 February 2016

Is Technical Diversity a Good Thing?

Not everything is equal
Not all gummibears are equal

Speaking to someone who is interested to work for our team, he was surprised that we don't have a standard virtual machine image with all the tools and setup ready. Well... we don't have that. We have a couple of README.txt files, and a setup that each time it's attempted causes a few scratched heads and curses.

But what it also does is ferret out a bunch of problems and bugs each time it happens. "Oh, this library was updated." Usually this is not nice stuff. Stuff that should have been taken care of. Stuff that should have been documented, or even automated. Probably with a bigger team, you'd assign someone to look after this stuff, but we're not a big team. So yes, the procedure to install a new environment can be tedious and time consuming.

But the other reason I like our diversity is that it's basically following the philosophy of what OpenBSD does in developing for a bunch of obscure, strange, and old platforms. It brings out to the light the kind of thing that "works on this platform", but in reality it's just an ugly hack or an -ism of that platform. Making your environment work on a couple of platforms will make things more robust.

(At one point we even tried to go as far as having someone being able to develop on Windows. That simply didn't work out, that "platform" is simply too complicated and needs too many special fixes.)

Posted by betabug at 10:59 | Comments (0) | Trackbacks (0)
Prev  ...  5   6   7   8   9   10   11   12   [13]   14   Next