Embedding IPython on Your Python App

Found in a comment of Python: Coding in the Debugger for Beginners, on Shannon -jj Behrens blog:

Jordan G said...

Since you mentioned IPython, I thought I'd drop this in here:

Its really easy to embed IPython into your programs and use them in a similar (but MUCH more powerful way) to the debugger.
Just put:
from IPython.Shell import IPShellEmbed
at the top of your program, and when you would break into the debugger, run:
shell=IPShellEmbed()
shell()

This allows you to poke at the state of your program with all the power of IPython!

Extremely useful!

Doctests for Ruby

I'm a big fan of Python doctests. They are easy to write (copy and paste from your interpreter), very clean (no subclassing, no assert*, etc.) and serve very well as documentation.

Compare this test:

def testFactorial(): 
    assertEquals(120, fac(5)) 

With this other:

>>> fac(5)
120

[If you don't understand the later, you should learn a language that provides a REPL. Really.]

So, someone working in Ruby saw the light and implemented it. Nice.

Doctest simplicity is a really poweful concept. The more impressive example is minimock, a mock library built on top of it. Aside from keeping the tests very understandable, the implementation is just 25 lines of python code. How about porting that to Ruby too?

I'm not against patterns. I'm against languages that rely too much on them.

Some people misunderstood my last rant as a direct attack against patterns. It's not. It's indirect.

So here I go again: I'm not saying that some patterns are bad by themselves. I'm just saying that many patterns are workarounds for limitations of programming languages that aren't expressive enough. Good workarounds, but workarounds anyway. And that's OK. Some languages are designed to not be very expressive (assembler being the extreme example). But when you start to fill your code with such patterns then it's a good time to question whether you have chosen the right tool for the job.

Look how the abstract iteration over a collection (the Iterator pattern) has become a very common language construct nowadays. It's even in Java 5. Now the pattern is invisible, avoiding distracting noise (example: Node node = (Node)nodesIterator.next())

Look how writing the producer side of an iterator is really easy to do in Python, via generators and the yield keyword. As far as I understand, Ruby's yield works similarly. Hey!, even Javascript got it's own yield (also in spanish).

See? In sufficient expressive or specialized languages, many patterns are invisible, which is a Good Thing.

More examples:

• Strategy is the way to go only when you miss first class functions (suspect on every class that only have an execute or run method).


• Abstract Factories are also overkill once classes and functions are regular objects


• The stupid FactoryFactory and the clever Javascript Module pattern I talked about before
  

So here is my point: Patterns are not bad. But their abuse is a symptom that something is bad. And often, the "something" is a bad language choice.

Why am I blogging in english?

Short answer: To exercise my english.

Not-so-long answer: As the majority of the people who starts a blog, I don't really expect to have much readers. So, I found another reason to blog: learning to express some ideas in a language that I don't master. I'm very good at reading english, as it is a very needed skill if you are a programmer. But at writing, I'm not so good. I'm forced to spend too much time on every english text I write, and think that's just matter of practice.

So, if you (the imaginary reader) find any error on my writings, please correct me.

I also have to admit that I'm bad at speaking and listening english. I'm watching english movies with english subtitles to fix the later, but don't know how to improve the former.

I have my own domain (and know my postal code too)

Well, for no very special reason I registered leosoto.com the last weekend. It was almost an accident.

In fact, I was just curious about Google Apps, so I went to the registration process and saw an option to look for a new domain name if you didn't have one. As that was my case, I followed that and after trying with some not very original names that were obviously taken, I tried with my name and it was available. So I took it and proceeded with my Google Apps registration. And I was happy :).

Looking from the other side of this situation, that's how you get happy customers: Offer them what they may want.

But they had another surprise later in the process.

Now it was Google Checkout. It seems a eat-your-own-dogfood practice by Google: When Google Apps wants to charge you for the acquired domain, it uses Google Checkout. So I filled the typical fields when you are buying something on Internet: Name, Credit Card, Address, Postal Code. But when you live outside USA, not every site forces you to specify the postal code. Moreover, I was used to left it blank because, some months ago, when I tried to get my postal code using correos.cl, it didn't work.

But now, Google Checkout complained that I don't filled my postal code. And provided a link to find it. I don't believed that the link would be useful (Yeah, I said, the typical link to help people living in the USA, but nothing for us outside), but it was. The link opened this popup of Correos de Chile Which wasn't the one that failed me before. In fact, this one actually works.

So what?. Google guided you to purchase a new domain and had a fairly simple database of pages that help you to get your postal code depending on your country, big deal!, may say you. And you would be right. What I experienced wasn't some cool 3d holographic (and sexy!) assistant that asked me in natural language what I wanted and made it possible instantly. It was just simple helps in the right place. Luckily that seems enough too make customers happy sometimes.

Oh, and by the way, http://blog.leosoto.com is my new blog URL. I have to justify my investment, haven't I?

Overengineering and design patterns

Today, a bit of documentation of the Apache WS stack got the attention of many people. Why?. Well, the interface name says all by itself: RequestProcessorFactoryFactory. Then you notice that the default implementation is called "RequestProcessorFactoryFactory.RequestSpecificProcessorFactoryFactory". Now I get why 80 characters per line is a problem for some people!.

Over-over-engineering.

Without getting into fully understand that crazy documentation, let's just assume that it is just a central place to get the factories (sorry, I can't say "central place..." again) that are used to get a damn "request processor". Two levels of indirection! Wait, no. Another level of indirection may exist, because something should be responsible of selecting the right "factory factory". That's worse than the abstract factory pattern .

Wait again. Did I imply that the abstract factory pattern is bad? Maybe.

It's just that I buy the argument that many "design patterns" are workarounds for the shortcommings of programming languages. You want two levels of indirections in a sufficient expresive language?. Even that insanity is straightforward:

class TheImplementation:
    pass

def factory():
    return TheImplementation

def factoryFactory():
    return factory

theInstance = factoryFactory()()()

See? No boilerplate pattern involved.

Another example of a workaround pattern? To be somewhat original, I will point to this "javascript module pattern". Please don't get me wrong. I think that it is good. I mean, a good way to workaround the lack of namespaces in javascript.