Monday, May 29, 2006

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 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 (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.

Andrew Birkett's MethodFinder in Ruby

Found this via RedHanded, but he didn't explain it as well as the original page.

It is a method that lets you find the name of another method given its arguments. Pretty neat what you can do with Ruby.

Sunday, May 28, 2006

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.

Saturday, May 27, 2006

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.

Wednesday, May 24, 2006

How to have multiple Submit Buttons on one form

The Rails Diary | Two Submit Buttons

I was pretty sure that there was someone else out there that might have had the same problems as me when it came to having two submit buttons on one form.

And of course, I found a simple solution.

Tuesday, May 16, 2006

'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.

Sunday, May 14, 2006

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.285x10^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.285x10^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.

Monday, May 08, 2006

Mozilla Sunbird bug, fixed in 12 minutes

My roommate submitted a bug into mozilla's calendaring application, sunbird today, and got the bug fixed in 12 minutes. That's pretty amazing. The fixer asked for a bug trace, and it was as my roommate was submitting it, so he got it in three seconds. That's even more amazing. :)

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 =>

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.

No mo' asserting flash in rails

Flash messages in Rails 1.1.2 doesn't seem to work in tests anymore.

I use to have some asserts in the test that go:

assert flash.has_key?(:error), "Flash doesn't have an error message"

But now, flash gets erased before returned to the test. I'm guessing they added an extra stage on top of the method being tested, so it gets cleared before execution gets back to the test.

So, no more testing flash in rails!

Sunday, May 07, 2006

The problem with making things

The problem with making things is that:

The dreamer has the creative idea, but doesn't understand the theoretical principles to make it plausible. Nor do they care as much as they should.

The scientists understand the theoretical principles, but don't understand proper software architecture to retain it in the long run. Nor do they care as much as they should.

The programmers design functional and architectually maintainable software, but can't design a usable interface for everyday people. Nor do they care as much as they should.

The designers design an aesthetically pleasing interface, but they are not the ones that are going to be using it everyday. Nor do they care as much as they should.

The users of the product just want to accomplish their task at hand, but can't stop purchasing things that are hard to use. Nor do they care as much as they should.

The making of everyday objects has become specializations of specializations. Each aspect and stage of a product's birth requires specialized knowledges that are quite discreet from another. However, I still think that one should learn a bit about the process before and after:

Physists should learn good programming and creative imagination.
Programmers should learn complex math and usability design.
Designers should learn good programming and actually use their products.

Tuesday, May 02, 2006

Slingfeed 1.0 beta

Announcing Slingfeed( from 3cglabs. It's something we've been working on that allows you to read blogs and news from feeds all in one place, and you can 'sling' interesting articles to your friends. If you sign up and add my gmail address as a friend, I can sling you interesting articles that I read on my feeds.