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 December 2012

vi or emacs?

It might actually make sense to ask this sometimes

A few days ago we were talking with someone who we thought he would join our team (in fact he did a few days later). When all seemed to be asked and answered, half out of wittiness, I asked the "big" question: "vi or emacs?"

Turns out, that question is actually quite valid in a "hiring" situation for a programmer job. It's not that I actually care what people are using (besides, vi is so clearly better, there's no contest). But the resulting discussion gave me some insight into the "geek level" and the approach to many work process related questions of the person sitting in front of me. All in a non-threatening, easygoing topic, since come on, nobody really discusses this on a serious level.

It boils down to: The choice of tool might not define good workmanship, but the approach of how someone chose their tools sure gives some insight. You can feel how sure they are of their work, what level of expertise they have, how they approach learning new tools, and so forth. What if someone would really get on a rant when posed such a question? Well, that gives you an answer too, doesn't it?


Posted by betabug at 18:39 | Comments (0) | Trackbacks (0)
22 December 2012

Public - ποιον κοροϊδεύετε με αυτήν την τιμή;

Ερευνα αγοράς

Χτες βράδυ λόγω εποχής και κίνησης είχα κολλήσει στο Mall στον Αγ. Δημήτριο. Πάω μια βόλτα από το Public εκεί να χαζεύω gadgets. Και τι βλέπω; Είχαν το Bookeen Opus (ebook reader) για "μόνο" 228 Ευρώ. Το "μόνο" είναι σε εισαγωγικά, γιατί online το αγοράζεις στο bookeen.com με 99 Ευρώ. Ποιον κοροϊδεύετε με αυτή την τιμή ρε Public; Περιμένετε να περάσει κάποιος στο χριστουγεννιάτικο στρες που δεν έχει την παραμικρή ιδέα και δεν ξέρει να ψάξει 5 λεπτά online;


Posted by betabug at 14:19 | Comments (0) | Trackbacks (0)
23 December 2012

Playing around with multipath routing on OpenBSD

Two options, two paths

Yesterday the router that was fried in a lightning strike has been replaced. After making the necessary changes to the repeater, I thought it would be a good moment to play around with network stuff, since I have now two network options. There is the reinstated ADSL connection and the mifi that I used as my Plan B.

So I went to the Networking chapter of the OpenBSD FAQ, where I had seen the sample setup for equal-cost multipath routing. I think the instructions are quite clear, but it sure is something that I wanted to try to see how it "feels" and works. Good for me that I have a splendid Laptop with OpenBSD installed, which has an Ethernet port as well as a working wifi card (ok, more or less working, but as long as the router is in the same room, it does work). So my setup is:

  1. ADSL-Connection, passing through an Access Point with OpenWRT that is configured as a repeater. The OpenWRT router has one Ethernet port and here I used that to connect to the em0 interface on the laptop.
  2. Mobile connection (3G / HSDPA, whatever the reception) in the shape of a little "mifi" access point. This little beast is actually faster than the ADSL connection, but then, it's a tiny ADSL connection. I use the iwn0 interface on the laptop to connect to this one.

On the em0 Ethernet interface I set up a static IP in the range 192.168.2.0/24, on the iwn0 wifi interface I have dhcp configured, which gives me an address in 192.168.5.0/24. The last time I tried the mifi with a static address, it didn't like it, something was blocking there, maybe that thing is configured to give access only to DHCP clients in order to be able to limit access to 5 clients? Further investigation will be needed there.

Next thing was to set the sysctl parameter for multipath routing and then to set up the routes, like in the FAQ. Easy enough, I could ping both gateways... but then, I couldn't actually get further out from one of the gateways. Looking at the routes, they had different priorities: em0 had 8, iwn0 12. Maybe this was an effect of having one of the routes created by dhclient. In any case I flushed the routes and created them new, setting -priority 8 on both of them. That did the trick.

Now looking at netstat -r they both had the same priority and both started to have increasing numbers in the "Use" column. The "P" flag for multipath was also present in the routes. Then I opened to terminals with ntop and had fun for a while watching various connections pop up on each interface. The effect could also be felt: I uploaded something big, which likely saturated one of the (tiny) uplinks, but still I was typing in ssh without any delay. Sure I have a nice pf setup with queues and ACK priorization, but with such an upload still there is a little delay noticeable. With the dual uplinks, it seems that the connections balanced out better. Definitely though, the max speed of a connection is defined by the speed of each one of the interfaces, not by the sum of both of them.

I haven't yet understood every detail of how this works, e.g. what algorithm is used to balance connections or which interface is chosen. I guess that once opened, a connection stays on the same interface, as some protocols won't take it well if your source IP jumps around (also see some explanations here). Definitely it also does not do "fail over" out of the box, but there are various solutions for that.

Conclusion: Using this on my laptop is not going to be something that I will do every day. But using an OpenBSD router for example in an office setup, where multiple people access the internet, it could be a nice option. Combine two or more cheaper Internet connections and have people not hinder each other, no matter if someone downloads or uploads some bigger files for a while. Then add some failover capabilities and connectivity through different ISPs and you will gain a little bit of uptime too.


Posted by betabug at 18:16 | Comments (0) | Trackbacks (0)
29 December 2012

An Experiment with PC-BSD on the Thinkpad X220

Not going to buy it anyway, you know

Background: There are some things that you know you're not going to switch to, but still you want to try. For myself, I know that I like the command line. I switched to OpenBSD from the Mac (ok, I still do some things on the Mac, e.g. full scale image editing), after deciding that I spend all my time on the command line anyway. I now use cwm and tmux. Still I wanted to give PC-BSD a try. For one thing, my laptop's hardware is supported very well in OpenBSD, but it's not supported perfectly. Maybe FreeBSD could improve on that, and the easiest way to find out (without having to digg into FreeBSD's config world) would be PC-BSD. And then, I just like to tinker with this stuff...


So I went and downloaded a PC-BSD image (9.1). Or rather: I tried, because the torrent would just sit there and look at me with lonely eyes. After a bit of searching it turns out that the project's torrent servers are out of order. OK, this kind of stuff happens. So I grabbed it off an ftp mirror, dd'ed it to a USB stick and there we go. I had prepared an external disk, with one big OpenBSD partition (need some more backup space) and a smaller, but still comfy FreeBSD partition.

Then I came to where the funky graphical installer lets you select the disk. That was scary. I have two internal disks in this laptop, both of which hold OS data. Sure I have backups, but if an install would wipe one of those disks, it still would mean a hassle and a lot of lost time. There are a few indications that help choosing the disks: Luckily the two internal disks were labelled with the manufacturer info... or at least with some parts of the manufacturer info. Instead of "Hitachi" and "Kingston", there was "itachi" and "ingston". I wonder how they missed such an "in your face" bug, but at least it let me exclude those disks.

Next options were to choose between the USB stick with the installer and the USB disk, which was the desired target for the install. Here I was a bit confused: The disk sizes used (in Megabytes) didn't look really familiar. The FreeBSD partition I had prepared was nowhere to be seen. At one point I thought it's the USB stick, but that is smaller. The installer showed the full disk size (in the "use whole disk" option) and it also listed the OpenBSD partition. In the end, since I had no data on the OpenBSD partition, I chose to use the whole USB disk for now (which means PC-BSD will get deleted faster, since I want that disk space). Did I mention it was scary? In fact I stopped the installer and rebooted into OpenBSD to check the disk sizes.

Once the install started, the blinkenlights and the buzz of the drive reassured me that indeed the right drive was being used. I was thinking a lot if the curses based disk format/select procedure in the OpenBSD installer is any better. I guess it can be pretty scary too, but a.) it forces you to read up on what you do and b.) it does not claim to be newbie-friendly. When I installed OpenBSD on the mSata SSD while having data on the spinning disk, I was a bit worried to chose the wrong drive, but being able to see the manufacturer info helped there. Having had some years of experience with the OpenBSD installer makes me a biased reporter in this respect though.

The actual install went through reasonable fast (USB 2 isn't so fast). Then came up two more problems, which I sometimes couldn't tell apart: For one thing, PC-BSD does not seem to know how to power down this laptop. After telling it to shut down, it just sits there with a black screen, I suppose it's halted. For a second thing: On OpenBSD there is a problem to switch off X and then you can't get back to a console, you just hang there with a black screen. Looks like FreeBSD has the same problem here. So it took several tries to get past the stage where the installer showed me which video driver it had detected (Intel) and if I want to go with it. After it got stuck on that for the first time, I was almost going to abandon the try.

Then I played around with it a bit more, asking for a different video driver (vesa gave a funny color screen and got stuck, wtf) and another with the Intel driver selected manually and finallyy got it one more stage further, where I was asked to select the time zone and set up a user. At the end of that, again a black screen. Another round of force rebooting and I got to a working system. I guess it had taken me 6-8 reboots or so, sometimes it looked like the video went bust, sometimes it looked like the installer tried to restart. The good thing is that the system didn't run any fsck, so restarting wasn't any slower than normal. I don't know, but maybe that is a result of ZFS.

So now I had a running system. Clicking around, it looked kind of ok. The LXDE desktop I had chosen looked and worked a bit like Windows, "Start-Menu" and all. Sound didn't work until I selected another sound device (from a graphical menu), but that wasn't hard to find. Installing Firefox with the graphical app installer was childs play, these are the kind of things that less technical users of the system will adore. Using Firefox I went to Youtube to try out some videos. That worked really well, both in the embedded video and in full screen the video didn't stutter and played flawlessly. I would say the new Intel video driver in FreeBSD 9.1 is really doing a good job there. This really is an improvement to what I get with the same machine on OpenBSD.

Also I guess that Firefox was using the Flash player that was installed with the system- but I haven't really checked if Youtube used that. For a non-technical user what counts is that Youtube just works. After a while I wanted to turn down the sound a bit. The hardware sound buttons didn't work. The taskbar sound slider didn't work. What worked was the sound slider in Youtube. Ugh. (In OpenBSD the X220's hardware sound buttons just work, but without an on-screen-display feedback.)

The OpenBSD iwn wifi driver for the "Intel Centrino Advanced-N 6205" wifi card in this laptop is a bit bad: Basically it works, but I need a really strong signal to connect. We're talking about "access point has to be in the same room" kind of strong signal. A little bit further off and there will be some hassles with disconnects, a bit more and no connection at all. I did not see the FreeBSD version of iwn to improve on that a lot (it didn't connect to the upstairs wifi, where the white macbook with Mac OS X connects perfectly and OpenBSD's iwn on the X220 fails totally), but I didn't experiment more to determine if there is a small improvement.

Frozen screen on trying to suspend the X220 with PC-BSD 9.1

Next hardware check: suspending the laptop. Closing the lid din't have any effect at all. Maybe that has to be set up somewhere (in OpenBSD you have to set it up). So I went to the menu and told the machine to suspend from there. I got a funny screen (see pic) and the machine froze instead of suspending. Same thing for "hibernate" from that menu. With OpenBSD the X220 suspends/resumes works just fine (with one small caveat: after resuming you can't switch to a console from X any more).

Time to round up this short experiment. I powered down the system... oh, in fact, I told it to shut down, then waited a bit to assume that it was done and held the power button till the laptop force shut down.

I have a little theory of mine: Every OS is just a different set of compromises. If a system works for you is determined by which compromises you are willing (or even liking) to take or not. That might be a question of how much Open Source you like your system to be, how much tinker friendly, how much it has to "just work" or "just run the stuff I need". Especially with a laptop, the grade of hardware support is another big source of compromising. Buy a Mac with OSuX and the hardware should interact perfectly with the Software from the same brand (but pay for it and take things like nonreplaceable batteries and ever increasing OS bloat, see what kind of compromises I'm talking about?)

First of all, as expected, PC-BSD is a nice system for someone wanting to work in a real GUI environment, moving around with a mouse and clicking on graphical menues. Not my choice right now, but I knew that much from the start.

As for the hardware: On the plus side, there is a much improved video driver. I'd like to have that, but I can live with the non-accelerated driver in OpenBSD. On the downside, there is no suspend (big outch), the question of why it doesn't power down (only a nuisance), and the non-working sound buttons. I didn't notice a big change with the iwn wifi driver. Looks like in that respect I'm better off with OpenBSD, since my big nuisance there (iwn) didn't improve, while I'd compromise a not-so-important improvement (the video driver) against a big downside (not suspending).

Note to (especially future) readers: If you like PC-BSD, give it a try yourself. By the time you found this blog post (which might be a lot later), there is a good chance that they improved on the hardware support, also you might not have the same exact laptop as me.

Posted by betabug at 21:26 | Comments (1) | Trackbacks (0)
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 betabug.ch-land. 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:

fin

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)
Prev  ...  5   6   7   8   9   10   11   12   [13]   14   15   Next