Sunday, February 19, 2006

Major new release coming soon

We are planning to do a major release within the next few weeks. Our inital alpha test provided us with invaluable data for the system, and gave us a great opportunity to see the system in action. Some of my initial assumptions about the system design turned out to be problematic, and we are now in the process of fixing those problems.

We would like thank all our alpha testers for using the system and all of the great feedback we have received. We are working hard to incorporate all of the feedback we have received. Keep an eye on our blog for news about the upcoming release.

Thursday, February 16, 2006

Regarding Rails Restrictions

The internet definitely gives a platform for people who don't know what they are talking about to make their opinion known. Unfortunately systems that rely exlusively on popularity (ahem digg, reddit) tend to give these people their limelight simply because they make such loud statements.

In particular I'm referring to this rant on the Joel On Software forums. Overhyping a product is just as bad as slandering it with false information, so I'm going to respond to this rant point by point, but I will apologize for my strident tone. I have to admit, I'm not really known for suffering fools gladly, and this guy really rubbed me the wrong way.

A little note before I get started. I have been a professional database developer since 1993, and I have worked with numerous enterprise level database systems and frameworks. I have worked with Rails for about 15 months and I'm now working on my fourth major project in Rails. You can view my commentary with that perspective.

"1. IT TAKES THE RELATIONAL OUT OF RELATIONAL DATABASE MANAGEMENT SYSTEM"

In this section the poster talks about how Rails isn't relational, and it just doesn't grok relational databases. His major point seems to be that Rails should be smart enough to look at your tables and infer the relationships based on the primary keys. First of all it's not clear when he thinks Rails should do this, is that when he's generating his models, or at runtime? Let's just assume he's not stupidly asking for a runtime performance graveyard like that, and he just wants it to happen when he's scaffolding out his models (see sidenote on scaffolding).

The problem with that type of introspection is easy to see on simple inspection. First, what if all of the tables you are joining to with your model don't exist? Should it re-inspect every table in the database every time you create a model? What happens if your naming convention isn't exactly how rails expects it (ie, some_descriptive_tag_table_name_id), the current system easily and expressively handles that situation. What if you have some special select logic that you need to do on your finds? Again the current relationship handles it very nicely. The current system has all the power and expressiveness you need to capture very complex relationships. It seems like he's really arguing that Rails should "just figure it out", which to me is a dubious claim to begin with.

The ranter then mentions something about not being able to leave the table, and Rails has taken a latex glove to his database schema. To be honest this entire section was very confusing and poorly worded, but he did make some relatively clear statements that were of course totally off base.

"There's still no excuse. Because Rails insists I name my foreign key columns table_id if I want to live the good life. When I do so, I shouldn't have to declar has_many and belongs_to."

Um...What? How about this:
belongs_to :user, :foreign_key => "user"

If you want to live the good life? What's that about? Is someone going to throw you in the river if you don't comply? Let me tell you something. Rails is very tolerant, and very nicely handles situations where people don't follow the standard. Personally I can't stand pluralized table names or using id as the primary key for my tables. So to live the good life do I have to do that? Hell no, I put these two settings in my environment.rb:
ActiveRecord::Base.primary_key_prefix_type = :table_name_with_underscore
ActiveRecord::Base.pluralize_table_names = false

at this point I now have the bliss of tablename_id as my primary keys, and I don't have to mess with any of the pluralized table nonsense. My model is named exactly the same as my table, so if I want an ORDER table I make an Order model, or if I do want to pluralize I name my table ORDERS and my model Orders. The point for me is that I don't have to worry about the pluralizer getting it right. In the context of this article, the point is that Rails supports this choice all the way throughout the system. Everywhere that it matters, the system just knows that I've made this choice and everything still works as if I were a normal Rails citizen. Pretty cool huh?

Ok, next the ranter goes off and starts talking about popups. To be honest, I have no clue what he was talking about here. I don't get too many popups at the command line, so I'm at a complete loss as to how to respond here. I'm going to chalk those comments up to either drugs, or complete cluelessness on his part.

So basically this entire point was complete and utter nonsense. This guy wants something that will go and do the work of figuring out what his foreign keys are for him. How does that translate to a restriction of Rails? Seriously, this guy should learn how to use the relationships in rails before he starts ranting about how bad they suck.

***Scaffolding Sidenote***
Ok I have to admit that I hate scaffolding. It was one of those things that got people interested in Rails, but in my world I never use scaffolding. Occasionally, when I just need a bunch of skeleton files I'll scaffold them out, but scaffolding is no more Rails programming than unlocking a car door is the essence of driving. Real true Ruby on Rails programming has almost nothing to do with scaffolding.
***End Scaffodling Sidenote***

"2. RAILS DOESN'T PLAY WELL. WITH ANYONE. NOT EVEN ITSELF."

"But do you remember that moment in the demo when the play turns ugly with a big ole error page? It's when he tried to update his db schema or model or something. It doesn't work because he has to reboot the webserver before those changes take effect. Which he says and moves on quickly."

Seriously, wtf? Did this dude actually write some code in Rails or did he watch the demo and assume that's how the system works? I've been working on the same system now since october and I've had to restart my web server less than 10 times. In fact the only time I've had to restart was when I changed the structure of things I had stored in session variables and I wanted to purge them. I probably didn't even have to restart the server then, but I figured I'd do it for good measure. When it comes to typical active development though, if you are running in development mode, you just don't have to restart that thing....*ever*. I add and remove tables, change the structure, add and remove models, change the assocations, etc, etc. I never have to restart the server in those cases, with the one exception noted above. Seriously this item makes me very seriously doubt the veracity of his claim that he has actually built an application in Rails.

Next he talks about how if you re-scaffold something it will overwrite your files. Which is true, *if*, when you hit the part that says "overwrite files (y/n/a)?" you hit a, or y repeatedly. Now look, Rails does make database programming easier, but it does help if you can use a computer and you understand basic prompts like "hey, you have some crap here, do you want me to overwrite it?".

Once again we have a complete rant section that isn't based on the Restrictions of Rails, but on the ranters own incompetence.

"3. YOU CAN'T READ THE FACKING MANUAL BECAUSE THERE IS NO FACKING MANUAL."

Wow, seriously this is such a load of crap. There are several good manuals written for Rails. Which you can buy from Amazon. The one written by the Pragmatic Programmers is $23 for a 450 page book. Apparently the fact that the book is over 200 pages is a huge problem for this dude, my advice, read the first 200 pages. In that time you'll have read enough information to be significantly farther along than you are now.

He also bashes on the api.rubyonrails.com, which to me is one of the best aspects of the Rails documentation. I don't know of any other language that has such complete documentation online.

Certainly documentation is difficult. It's often times hard to know where to start, or where to look, but everytime I've picked up a language, I head to the bookstore and buy a book that covers the topic I need to learn. If you are completely against buying books, well the problem isn't with the language, it's with your self imposed restrictions.

"4. RAILS ATE MY DATA, OR AT LEAST STOOD IDLY BY WHILE MY DATA WAS EATEN"

Again with the WTF? How is this even a rant about Rails? This guy is just boldly stating that he has no damn clue how to build software. Seriously, Rails has this whole wonderful thing called validations. If you want it to validate your data, you have to tell it to validate the data. Programming languages and frameworks don't write the software for you, they just expose features and functionality that allow you to easily write code. He then complains because Rails knows the database is only 40 characters and it should have checked the data first. The problem here is that most real database systems won't silently fail, so it's a massive waste of CPU to do a check that is completely useless in most cases. That's why you have to explicitly tell Rails to do the check, because it tries not to uselessly waste CPU cycles. Next.

"5. THE FIRST RULE OF RAILS IS: DO NOT TALK ABOUT RAILS' RULES!"

Every significant framework has rules, and lots of them. He complains that none of these rules are out there for people to read. As I said before, if he read the first 200 pages (since that is his limit) all of those rules would have been covered in great detail. If you fail to do even the most basic research, he is right, those rules would be frustrating and irritating if you just kept tripping over them. Again though, the stinging indictment is that he is lazy, not that the information isn't there, and there in abundance.

"6. THERE'S MORE THAN ONE PLACE TO SAY IT"

He is apparentely talking about Engines here. The last time I looked Engines were an add on to Rails, and they weren't part of the core system. Regardless of that, Engines are a way to allow you to build components to re-use across projects. Building systems that you expect to reuse does require a bit more effort than writing that code once, however again that isn't really a restriction of Rails, it's an arbitrary requirement of an add-on libary to Rails.

This entire rant was misguided, and I didn't feel like he made any actual good points. I am certainly not claiming that Rails is perfect, but if you want to fix something it definitely helps if you learn what you are talking about before you write up some long winded post exposing what an idiot you are.

Friday, January 06, 2006

Finally a good article on Python

I came across this article on "How Python wins on the Web". Personally I think this article is excellent because it gets people focused on what is great about Python, instead of having them try to build a copy cat framework of Ruby on Rails.

Python has excellent built in networking, and is really quite good at building network servers. I used it to build a distributed clustering system (which one of these days I'll release open source), while I was building the system I really enjoyed how powerful Python is at the network layer. It has one of the most clean and consistent network api's I've worked with ( generally in Python most things are clean and consistent, except the OO layer ).

I really hope the Python community takes this article to heart, and stops wasting their time trying to build a Rails clone, because frankly that is focusing on a specific area that Python isn't that great at in my opinion.

Monday, December 19, 2005

Alpha Testing now going

We opened alpha testing of the system today. So far we have about 20 users signed up and testing the system. There is still a lot of polishing left to do on the UI, and I'm sure I'll have to do some tweaking of the core algorithm, but now I'll actually have some data to use during the tweaking.

If you are intested in helping with the alpha test, drop me an e-mail at: alphatest.zifus@recursor.net

Friday, December 16, 2005

Avoiding the temptation to gold plate

Developers are notorious for wanting to build every feature possible into their software, particularly features that people don't want or need, but that seem cool to the developer. I am trying very hard to avoid this particular temptation, even as my list of tickets grows. Initially I'm trying to focus on building the main components of the core system, and avoid things that I don't view as essential. Of course there are some things that I think need to be in the software that probably don't *have* to be there. One example is the community ranking system I am incorporating in. The system doesn't have to have it, but in the end, for the site to be successful we need as much community participation as we can possibly get, so I feel like that subsystem needs to be there even to launch an alpha test.

It's interesting because as I initially started building this system, I didn't think it would take this long. If I were going to build a site like digg or reddit I could've had the system done in a matter of days rather than weeks. However my main goal with this system is to build something that will ultimately be more useful than either, and doing that has been both interesting and challenging. To change a phrase from the Princess Bride. Our ranking system will be terribly useful, I think everyone will do it this way in the future.

We are nearing the time where I will be ready for some alpha testers, and my key focus will be how the social algorithm works. Is it useful? Are the news items important and relevant? There are a million digg and reddit clones popping up, but I'm aiming for Zifus to be an evolutionary step beyond those system. Hopefully with the help of the community we'll be able to build a system that bring useful and relevant information to your fingertips.

Thursday, December 08, 2005

Ruby on Rails vs Python Web Frameworks

O'Reilly has posted an interesting factoid. For the first time ever, Ruby book sales have surpassed Python book sales. In the article he also names Rails as the primary catalyst for Ruby's massive growth in popularity. Then he briefly discusses Python's attempt to respond to Rails.

I don't believe Python will be able to catch up to let alone surpass Rails in terms of popularity for a few reasons. By way of background, I have programmed professionally in Python for 3 years, and have been programming as a career for about 13 years now. I have tried a great number of the various web frameworks ASP, ASP/MTS/COM (ugh!), PHP, J2EE, ASP.NET (C#), Cold Fusion, Zope, mod_python, Twisted, Ruby on Rails. I spent significantly more time in some frameworks than others, but I never really *loved* any of them until Rails. In fact J2EE and ASP.NET were so bad in my opinion that I gave up entirely on web programming for a few years and just wrote python scripts to crunch data.

After working with Python for a few years I felt like I was ready to venture back into the world of Web Systems. I thought Python would be the ideal language to use because of it's flexibility and general cleanliness. I thought because Python had a relatively active community I would be able to find a really nice Web Framework to use. However after trying numerous frameworks, I came away with the following conclusion: Python sucks for the web.

The biggest problem for Python on the web is the same thing that makes Python so clean in the first place, significant whitespace. The second biggest problem Python programmers face is the mindset of the Python community, which is that there should be only one way to do things. The "one way to do things" mantra certainly seems nice to someone coming from Perl, but the general inflexibility of this rule began to wear on me after a while. It started to feel like I was using tools that didn't quite match the job. The quintessential example of this inflexibility is the refusal of the python core team to add a case statement to the language. There are numerous cited reasons, but the net effect is you have to use rather ugly nested if / else statements in the place of a well designed case statement. While that mindset may be good for a niche group, most mainstream programmers tend to prefer practical flexibility to dogmatic adherence to aesthetics.

Significant whitespace in your code can be a beautiful and readable thing if you work in a relatively homogenous environment. It's definitely a pain if you have to merge code written by someone else, in a different environment, into yours (especially when they use tabs, or 3 space indents instead of 4). That problem is severely compounded when it comes to web programming. It's so serious in fact, that when it comes to templating, virtually all python web frameworks use some other language to do the templating. Primarily they use Kid and CherryPy. Both of those templating languages grated on me. I wanted something more consistent, more elegantly designed, and definitely something that was better integrated.

Then I came to Rails and my first serious introduction to Ruby. Let me tell you, both Ruby and Rails knocked my socks off. The beauty, simplicity, and power of Rails is rooted in something deep within Ruby itself. Despite the claim that Ruby has weird syntax, I found it's syntax to be very clean and straightforward. As far as languages with syntax go, I would say Ruby has just the right operators in just the right places, which in my opinion make programs very readable.

Something that definitely struck me while using Rails was just how much Ruby is used. It is used absolutely everywhere, to a degree that I have never seen in any other language. Whereas with Python you have to learn another entire mini-language to do web programming, with Ruby I could use the full power and expressiveness inside the .rthml file just as well as I could within the .rb files. Instead of finding some obscure tool and trying to get it setup and installed and working with my Python Web Framework, with Ruby I could just use RubyGems to automatically download and install the latest version of whatever item I needed. It's literally as easy as gem install rails to download and install Ruby on Rails. When it comes to testing my application, Ruby comes with an incredibly powerful tool called Rake. Rake is essentially a build tool similar in concept to Make, but it allows you to express everything in Ruby. Rake is so powerful in fact that deploying to your production server has been canonized into a set of Rake tasks known as SwitchTower (once again included with Rails). With SwitchTower you can deploy effortlessly with rake deploy.

There are numerous things that I could mention about Ruby on Rails that are better than what I've seen in other frameworks. But instead of a laundry list of things that you may or may not like I'll leave you with this comparison. In terms of design, Windows is to the Mac as Python Frameworks are to Ruby on Rails. Windows is a powerful operating system, and you can kind of get it working most of the time. But if you use it a lot, there are things you will find frustrating and poorly designed. Whereas the Mac is a beautifully designed and tremendously well thought out system. The most common description is that it just works. So too with Ruby on Rails, from top to bottom, it just works.

On his blog, Aaron Schwartz, while discussing the Reddit re-write, said he created web.py because all of the other Python web frameworks suck. I agree with his assessment, if not with his conclusion. The Python frameworks don't suck because the people who wrote them are bad programmers. They suck because they are trying to build a framework to solve a problem in an environment that Python is fundamentally not suited for.

Python is a great language in and of itself, and there are numerous things it is well suited to, web programming just isn't one of them. If you are serious about building web applications, I strongly suggest you take a good look at the benefits and productivity offered by Ruby on Rails, I can almost guarantee your competitors will.

Saturday, December 03, 2005

Power vs Popularity

Well I didn't expect to jump right into a vigorous discussion about language, but I'll give it a stab. I came across the following article Why Ruby is an acceptable Lisp. As expected the Lisp guys jumped up and shouted "Ruby is NOT a Lisp" with their typical disdain for anything not Lisp. Then followed the expected obscure examples of what Lisp can do and why the Ruby version is *obviously* inferior.

Don't get me wrong, Lisp is by far my favorite language. I am completely sold that technically Lisp is much better than any other language out there, including Ruby. Despite Lisp's technical superiority it remains a small community while other languages flourish and prosper as they pillage features out of Lisp.

What interests me are a couple of things:
1 - Why is a language like Ruby taking off while Lisp continues to languish in relative obscurity?
2- What is the appropriate trade off between populariy and power?

First, why is Ruby flourishing instead of Lisp? To answer that we have to look at what is fueling Ruby's growth. Ruby On Rails seems to be the primary motivator, Ruby was around for years before Rails was born but it remained a very small community until Rails came along. It's interesting to note then the primary catalyst for Ruby's increase in popularity was a framework written in Ruby, and not the core syntax of Ruby itself. What initially attracted me to Ruby was definitely Rails and it's promised increase in productivity. Perhaps part of the problem Lisp has always had is that "you can do that in Lisp too". Many people can and do write similar frameworks to Rails in Lisp and other languages. While Rails brought me to Ruby it was the power, expressiveness and general clean feel of the language that kept me, instead of defecting back to Python when TurboGears was released.

Further I didn't stumble on to Rails, it came roaring onto the scene. I came across a bold, audacious claim that got posted to Slashdot. David Heinemeier Hansson made the in your face claim that you could improve your productivity by 10 times if you switched to Rails for your database development work. It wasn't just this one article either, Hansson was a wonderful and provacative evangalist for Rails and Curt Hibbs wrote several great introductory articles. Most programmers weren't sitting around going "I am so sick of Java, I need to find a better way to do this..maybe I'll try Ruby" Rather when Rails was released Hansson practically hit them upside the head with the superiority of Rails. Now I'm not claiming most Lispers aren't touting the superiority of their language (I'd wager they have that part down pat), instead I'm saying Lisp needs a better coordinated and more concerted marketing campaign and a product to sell to people beyond core language features. Additionally Lispers would do well to offer a warm and welcoming environment to newcomers.

Now to the second question, what is the proper trade of between popularity and power? I'm going to let you in on a little secret, when I first came to Ruby On Rails the framework wasn't that great. The idea behind it was fantastic, but the implementation was far from complete and it definitely lacked consistency. Of course this is to be expected, it was a very early release and I didn't expect it to be a polished completed framework. What it did have though was momentum. To me this is the key issue. When it comes to core language features you want to have the most powerful language you can get. However when it comes to frameworks and libraries, popularity definitely matters.

It's not so much that I mind writing certain features in Lisp, it's that I don't want to have to write those features at all. For an entrepreneur trying to get a product out the door it seems like a mistake to start in a position where you have to implement a major framework in order to be able to compete effectively. If you enjoy that type of thing, why the crap aren't you writing the full stack Lisp On Rails equivalent? Instead, Lisp has the same problem that Python did before Rails came out, it's not the lack of frameworks, it's the lack of a good integrated framework that is easy to setup and get running.

Something I have learned from books about positioning your product is that you can typically only occupy one place in the consumers mind. You must occupy a niche if you will. The best way to invade a fortified position is through a concentrated attack on a weak part, rather than a generalized attack at all points. If you can do that you will be successful at driving adoption. This advice seems to hold up to real world observation as well. How does this apply to programming languages? Let's see:

Fortran: scientific and mathematical programming
C: Operating System programming
C++: Object Oriented C
Java: Safer and more object oriented version of C++
C#: cheap knockoff of Java (sorry couldn't resist ;) )
Visual Basic: A Beginners Language
JavaScript: scripting language for the web
Php: dynamic web programming language
Ruby: (with Rails) powerful database backended website language
Lisp: AI?
Scheme: Teaching language

Of course this list may not be fully accurate, and I could've gone on much longer, but I think you get the point. Those are the positions those languages seem to take in most people's mind. If Lispers want to drive adoption, they need to build good complete frameworks and I suspect they really need to address the issue of positioning in the mind of the consumer. On the other hand, it's also possible that many Lisp programmers enjoy the position of martyr for a tragically misunderstood language.

Zifus Development Blog

Welcome to the Zifus development blog

What is Zifus?
Zifus is a personalized content aggregator.

Another News Site?
Yes, Zifus is essentially a news system, however I believe our solution to this problem is vastly superior to anything currently available. Our goal is to help you quickly find the most important and most relevant news and content on the web. The entire system is designed to deliver only items that are of interest to you.

What are you writing it in?
For those that are interested, we are building the system in the very powerful Ruby On Rails framework. Rails has been a huge win that has allowed us to focus on our core algorithms instead of fighting the framework at every step. If you are interested in building web applications, I highly recommend Rails.

Who are you?
Doug (Beowulf)
I am a professional software developer that has specialized in building large database applications for 13 years.

When will it be available?
Zifus is currently under very active development. Our plan is for an initial alpha release on January 1, 2006. If you are interested in testing our software please send an email to alphatest.zifus@recursor.net. Let us know if you would like to beta test the software, or if you would just like to be notified when we release the software publicly.