Evolving Design Patterns

I like the idea of cleaning up after yourself as you’re coding. I find that I do that more and more, however, I get impatient if I spend most of my time, doing ‘cleaning’, rather than actual ‘cooking’.

There’s several tasks that I tend to be doing when I’m coding. Creating, designing, refactoring, debugging, and testing. I probably spend 70% of my time refactoring, debugging, and testing. But this is usually 10% of the fun. Where I find fun is in the creation, but I only get to do that 30% of the time.

Though I feel like refactoring, debugging, and testing (RDT) are necessary for good code, it’s like cleaning your room…you have have to develop an OCD pride in having clean code to derive pleasure from it. However, you must always balance it with GETTING STUFF DONE.

It’s hard to motivate yourself when nothing’s actually being done for too long.

While testing has gotten easier and more automated with unit testing, and dare I say it…fun (to watch it say, you passed!), I feel like there isn’t a good handbook yet on evolving design patterns.

Much of the time, I find the design patterns in the GoF book to be overkill. However, you do want to think about the future so you can extend it for flexibility later.

So the language that you’re working in should allow the flexibility for you to sketch ideas, and then beef them up with ink later. The problem is, unlike drawing, you don’t often know what’s the best way to beef things up.

Certain types of solutions to problems have varying degrees of flexibility. For example, if I were to write a lexer/parser, I could just write a big loop line by line with a case statement inside it. But what if there are recursive elements? What about callbacks? There are more flexible architectures of lexers and parsers to handle that. However, no book I’ve ever seen delves into the topic of how to transform a bare bones lexer/parser into a full fledged lexer/parser.

Therefore, you can take the minimum level of complexity that you need, and be able to refactor it later if you need to.

Beowulfs @ Home

Lately, I was wondering what to do with the four old computers that are sitting in my parent’s basement. I looked online, only found one article from PC mag, and none of them seem very neat or enticing.

It was then that I went back to reading about beowulf clusters, but other than the experience of setting one up, I only have one problem I’d like to solve in parallel, which is the simulation of sexual selection on the genetic algorithm.

But yet, reading about cells yesterday, I’m wondering if it was possible to use parallel computers to take advantage of this dataflow programming paradigm. While I’m doing guesswork here with very little details, at the very least, it seems that one can assign a processor to a number of cells to update within a program. However, it might not be feasible, if the messaging system of cells has a lot of overhead.

This would be something neat to try.

Rounded corners in CSS

Ahh, yes, the elusive rounded corners in CSS design. A number of people have come up with all sorts of hacks and solutions to rounding corners.

Presented is the ‘sliding doors’ method, where you segment the window into various divs and put an image in each for a more fluid layout.

However, I feel like ultimately, rendering this is the job of a CSS property and the browser. Isn’t there a clipping property in CSS?
div#contents {
clip: rect(10px, 5px, 10px, 5px)
}

Now, I only know of shape being ‘rect’ in CSS2. Why can’t there be other shapes, like, ’round_rect’?

Briefly looking through CSS3 spects on W3C, I didn’t see anything at all. Does it make sense or no to implement this in the browser, instead of having CSS designers hack up designs?

PyCells and complex and emergent systems

Through this blog post on “BlueSky” about PyCells, I delved further into this seemingly new (to me) programming paradigm, called Cells, by Kenny Tilton.

It basically takes the concept of a cell in a spreadsheet that get updated automatically to programming where there are a lot of internal data states that are dependent on one another in a chain, or a complex graph of dependencies. Like, the color of a button depends on whether you selected a radio button or not. Or, shut down the motor if the sensor reads above 100 degrees (example given in text).

In only the brief one hour that I’ve been reading about it, it seems like you make declarative statements about WHAT is chained to what, and the cell system will be able to make deterministic and discrete updates to keeping data internals consistent, so that it eliminates race conditions and deadlocks.

A better explanation of it by a better informed Bill Clementson will help you understand it, in addition to this long explanation of cells by Phillip Eby. While it might sound academic, it’s currently under the summer of code 2006 for google, under the python foundation. They’re trying to make a port of it from Lisp’s CLOS to Python. I wonder if anyone’s doing it in Ruby?

However, even if it does really remove deadlocks and race conditions, I imagine other problems will crop up. It seems very analogous to cellular automata, except in this instance, the cells are heterogeneous, and there can be any number of neighbors. I expect that for even simple systems, you can get unintended and complex behavior from them, as most likely, they will be non-linear systems. How can we harness these unintended behaviors to design systems that are more than the sum of its parts? Of all the complex systems literature I’ve read, they’ve mostly been descriptive, rather than predictive. I’m not sure how to design emergent systems.

‘templates’ is a reserved word in Rails

I’m glad I didn’t spend too much time stabbing around in the dark on this one. I had a controller/model named ‘templates’, but there was a weird error that popped up:
undefined method `assign_variables_from_controller' for #
That’s because ‘templates’ is a reserved word in Rails, so you can’t use it for your controller name.

Finite number of pictures

When you think about it, the number of distinguishable photographs is countable. The human vision system has a limited resolution. Nowadays, five megapixels is hardly distinguishable from a four megapixel image. So that means that each picture is about 5 million pixels for a 5 megapixel picture. Human vision is pretty sensitive to color, but it’s limited at about 24-bits, or 16,777,216 colors. So there are 5 million * 16.77 million = 8.285×10^13 distinguishable pictures.

That’s a lot of pictures, and it’s hard to comprehend how big that number is. The vast majority of these pictures would be noisy-like. But when you think about it, every frame that you’ve ever seen on your TV, every digital photo you’ve ever seen on flickr, every image you’ve seen on your monitor have been a subset of these 8.285×10^13 pictures. And yet, you have not seen the vast majority of these pictures. Some of these are pictures of people you know, people you don’t know, places that you’ve never seen, deserts, planets, stars, aliens on their home planets in their vacations, even. Pictures of the imaginary, of dreams, of the impossible.

render_component different from link_to options

This one got me stuck for about an hour. I couldn’t figure out why this wasn’t calling the method of the component, but it was rendering the view of the component.

render_component :controller => "poll", :action => :show, :id => @event.poll

It ends up that this would be all fine and dandy if it was a call to link_to() rather than render_component even though the nature of the parameters is practically the same. So for render_component(), it should be:

render_component :controller => "poll", :action => "show", :id => @event.poll.id

it needs strings instead of symbols for :action, and it doesn’t convert an ActiveRecord object to its id–it needs to be explicitly stated.