As you may have noticed, this is my third post of the day.
This is part of my new policy to post thrice daily.
It has occurred to me that when it comes to blogs, quantity is of much higher importance than quality.
I think everyone will agree that three posts each day is much better than a good post every few days or weeks.
Don’t you think so?
If you don’t you are tottaly wrong and stupid.
As you may have noticed, I’ve updated the design of my blog a bit.
Using my superior web design and CSS skillz.
I think everyone will agree that this is much better.
Don’t you think so?
If you don’t you are tottaly wrong and stupid.
After three weeks of not posting, some people may have begun to assume I had died, but in reality it was all part of an elaborate April Fools prank. Gotcha!
Others may have assumed that I was just being lazy and not posting. April Fools! It was also part of an elaborate April Fools prank … umm … to make you think that I was lazy. Yeah! That’s totally it!
In honor of this beloved holiday, I’m going to outline a few of the jokes I’ve seen today.
The thing that makes this joke so funny to me is that the writer thinks he’s being ridiculous, but it’s obvious he’s never seen Gobo Linux before. The only ridiculous part is the assumption that applications would need to be modified to work.
Also, he didn’t include the /Programs directory, which is the best part of Gobo Linux.
What makes this even more amusing is that recently I’ve been considering the possibility of creating a script which would allow the installation of Debian packages on a Gobo system. Something like Apt-Gobo, even, which could even pull packages and dependencies from Apt, but install packages in a Gobo-compatible manner. It would be the best of both worlds, since there are far more binary packages for Debian than there are for Gobo, but Gobo has a much nicer filesystem layout.
Anyway, I’m going to move on before people start to think that this is a joke…
I always enjoy these every year. They get wackier and wackier. My favorites this year are “Super Pii Pii Bros” and the ZapCam YouTube Tazer.
I wonder how much time it took to come up with all of these, especially considering they have videos of all of the joke products this year.
Every year, Geeks.com sends out an April Fools new product email. This year they advertise “The Latest in Biometric Security Technology” along with “Dog Bark Voice-Print” and “Pet Paw Print” access analyzers.
The first one of these emails that I got years ago advertised a circular monitor, with something along the lines of “No more annoying corners on your screen!” I can’t find the old joke on their website (I didn’t look that hard, though.)
This is one you just have to see. It would ruin it if I gave an explanation here. It’s basically the best April Fools day joke. Serously, check it out.
In an effort to get some work done on personal projects, I decided that I need to program them in a language I enjoy more than PHP. The idea is that it will seem less like work and more like fun. It seems to be working so far, though there’s always a bit of a learning curve to get used to a new framework.
Speaking of frameworks, I chose Django, since it seems pretty mature and well thought-out.
One of the things that really strikes me as a really good idea (aside from ORM done right and and awesome automatic admin interface) is the concept of “template inheritance”.
Template inheritance allows you to define a base template with blocks, and then in “child” templates, to simply override those blocks which you wish to replace. This really helps to reduce the amount of template code, and even the number of template files, that you have to write.
I am sitting here, drinking a warm Diet Dr. Pepper, trying to relax a bit and calm myself down.
This morning, I wake up, and I’m feeling very groggy. Angie and I were out until 3:30am, and it’s not even 11 yet.
I have a little bit of breakfast, but what I really need is caffeine. Of course, we don’t have any in the house.
We have some black tea and some Oolong tea, but I want something with a bit more caffeine in it to wake me up. The only coffee we have left is decaf. Useless.
Any time you have a large number of people driving on the same road, you start to notice certain patterns of stupidity, carelessness, or perhaps ignorance.
Almost every day I ask myself: “Do these people not know how to drive, or do they choose to ignore the rules?”
For some reason I still have some sort of faith in humanity, so I will give them the benefit of the doubt and assume the former, rather than the latter.
Plus, the first problem can be solved through education, whereas the second requires a change in attitude, which is much harder to accomplish.
Without further a-do, here is the first in a series of posts with the goal of education the general public on the subtle intricacies of driving.
For my first topic: Signaling.
I grew up in a tiny town in North-West Oregon called Rainier. As of the 2000 census, the population was 1,687. It’s probably not much more than that today (perhaps even less). The sign on the way into town has read “Population 2000″ for as long as I can remember.
To be more specific, I grew up in one of the several “unincorporated communities” surrounding Rainier, so I wasn’t counted in that 2000 census (not for Rainier, anyway). I had a Rainier mailing address and a Clatskanie phone number.
I recently stumbled upon the blog of an old high school friend and fellow ex-Oregonian Chris Brewer. There is a recent post on there about Problems in the Rainier school district, which sparked a some nostalgia and inspired me to check up on my old hometown.
I found Chris’s blog because it is linked to on his Facebook account. Fairly directly, the power of the Internet as a world shrinker has been shown to me. Because I decided to log into Facebook I now know more news about my home town that I would have otherwise, way down here in Austin, Texas.
Not only that, but I just spent most of my lunch break finding and reading various information about Rainier. There’s quite a bit of history behind the little city, more than I’d ever thought to even look into during my 18 years of living there.
It’s interesting how people can be brought back together, at least in a virtual manner, from all the places they have scattered around the world. That’s the real value of social networks to me: keeping in touch with people you already know, not meeting of new people. Either way, they seem to work pretty well at bringing people together. I can’t see social networking going away in the near, or even in the distant future for this very reason.
Perhaps this social networking business isn’t such a bad thing to be in the middle of after all.
I’ve had both dogs and cats as pets over the years, but I’ve always preferred the cats.
I figure it could be an interesting exercise to put some thought into why this is so.
After some time thinking I came up with a list of attributes of cats and comparable attributes of dogs. It’s clear I have a strong bias toward cats.
The list I came up with, after the jump…
Joshua Clanton posted a guest post on Jarkko Laine’s blog yesterday, talking about how to get into a state of “flow” to increase your productivity.
I commented that I seem to be able to get into a state of flow better when I have a large chunk of time allocated to work on a task.
To me there’s nothing worse than coming back to something I had to stop in the middle of. It takes far too much time to get back up to speed on what I was doing, and often I’ll have forgotten about something essential, which results in bugs.
Joshua pointed out in another blog post that it helps flow to have not only big blocks of time but also to have your tasks divided into big blocks as well.
I definitely agree with Joshua on the “big block method,” though this is the first time I’ve put much conscious thought into it. Looking back, it seems that I’ve done better work when I’ve used this method, and I’ve always hated working in short bursts, since it feels like I’m wasting too much time in “context switching.”
There’s one question I’m not really sure of the answer to yet: How big should a big block be?
The first answer that comes to mind is “Just big enough, but no bigger” (a modified Einstein quote)
So far my technique has been to just pick what seems to be a single functional unit, or perhaps a piece of functionality that all belongs together.
I suppose that different people will have different definitions of what a big block task is, but to me it works out that it’s something that is a complete unit. A complete unit can be a full module, or one step in the implementation of a full module. The key is, though, that there is a clear stopping point and something isn’t left unfinished.
For example, working on my browser, I have index cards (old business cards, actually) which each have an individual task on them. I sort these cards by the order I plan to do them in. These cards contain something like “Implement DOM 2 HTML” or “Rendering Engine support for inline elements.”
The former is a complete module which could (and was) finished in one big block section of time.
The latter won’t result in the final version of the layout engine, but it will get it to a point where it is functioning, and then the next step would be to support block elements. Absolutely and relatively positioned elements would be yet another separate task.
Well, I’ve made some progress on the HTML layout engine, but it still isn’t complete enough to run yet.
When I got to the point where I needed to call ViewCSS.getComputedStyle from the DOM, I stopped to actually implement it, and decided that it was a good time to actually see if the DOM HTML code I had written would run.
It didn’t, of course.
So I spent some time fixing all the little bugs here and there, and set up some test code to pull a page from the internet and parse it into a full HTML DOM tree.
Since I’m using pxdom’s parsing functions and pxdom only knows how to parse proper XML, I also run the HTML through the python tidy lib first to ensure that it’s proper XHTML. Without doing that I couldn’t even parse the Google home page.
Here it is if you’d like to check it out. It needs pxdom to work. The parseString function will take a string containing HTML and return an HTMLDocument.
Right now it’s usable for manipulating and traversing the DOM with all the attributes you are used to being able to access from Javascript, and if you combine it together with this simpleget module (requires domhtml and utidy from above), you can use it for some basic web scraping purposes.
Remember, it is basically pre-alpha code, since I haven’t tested everything yet. I might get around to writing up some unit tests at some point, but until then I can’t guarantee that there are no errors.
I didn’t spend all my time in the last couple of days just fixing up my DOM HTML implementation. I also did some research on JavaScript interpreters, and I think I’ve decided that I’m going to wrap SEE, a JavaScript interpreter written in C, with a Python module and use it for the scripting engine for my browser.
I considered using Spidermonkey, but after looking through the documentation for each, SEE seems like it will be much easier to wrap, and as far as I can tell, it supports JavaScript exceptions in an easier-to-use (and easier-to-integrate-with-Python-exceptions) way than Spidermonkey does.
SEE also handles memory management for you and you can fully separate interpreter instances so you don’t have to worry about thread safety, which is two less things to have to worry about.
