I think you'll like this song. It's about the problems MSIE developers have because of the lock in:

IE is being mean to me song

Full Disclosure: One of my employees, Scott, wrote this song (and I recorded it). The inspiration came from one of our dev teams that was constantly complaining about the problems the browser gave them.

I know I am completely biased but I have a high level of confidence that what I say is true even though it is subjective.

Many of my employees have told me that this is the best place they've worked at and I've had some of them break down in tears while they've said it. Other people we've invited to our Christmas dinner have said that the atmosphere is so positive in a way that they've never seen before. We play games for the last hour of every Friday for bonding. When we make sprint goals every 3/4 weeks, we go out somewhere and just play (canoeing, planetarium, movies). In our new division, which I've been running for the last couple years, we've never had anybody quit. At Christmas I offered to match donations to charities and I like philanthropy. Last few Christmas I've given things like PSPs, Nintento DSs and we have a gift giving competition with big prizes. I can't remember the last time anybody asked for a raise because I pay people fairly. We are all great friends yet we are all quite different. And the 2nd best company award in BC (Canada) is awarded based on what employees say in person to person interviews in private, not on what the owners say.

I agree that it is easy to deceive yourself and so I try to stay fairly conscious of the fact that it can happen. This is why I often ask for feedback and provide feedback. When people don't like what I'm doing, they do tend to tell me, and we always resolve it.

Here's the thing. I actually knew another financial advisor (he had a firm) that I felt was morally bankrupt. This was around the same time as I met the one I talked about above. The morally bankrupt one lost all his money and I know several of his employees who seem to all hate him. When I met my lawyer, the very nice and honest one I mentioned, he was not a partner and he is now a partner and very successful. In my personal experience, the morally upstanding people have succeeded in much higher proportion to those who haven't. I'm not saying there is a correlation between success and a moral compass but at the same time, I definitely haven't seen any signs of an inverse correlation as suggested by the Ferrari comment. The news may say different but all the morally upstanding Ferrari owners probably never make the news nor do they make for great movies.

Sunny

Wow, seriously?

How do this get modded up? It seems like the only kind of people that you can stereotype and prejudice safely are the rich. "Most" people that I know who own expensive cars or boats are amongst the nicest and most moral people I know. Not everything is like television or the movies.

I'm not sure whether it's worth admitting but I own a Ferrari and I would consider myself having a very high moral code. I treat my employees really well (One of my companies was rated 2nd best company to work for in BC), I pay all my business taxes (in an audit we were caught something like $50 for an accidental missing receipt out of millions) and I declare every last thing at the border.

I know that anecdote (especially personal anecdote) is not data but also my accountant is quite wealthy (he is one of the most morally upstanding accountants I know and somehow his clients are all rich. He is also a philanthropist.), my financial manager runs the Vancouver branch of a financial firm and he is upstanding. And believe it or not (and you probably won't), my lawyer is one of the nicest and one of the most honest and upstanding people I know.

Ok, so those people don't own a Ferrari (I actually don't know any other Ferrari owners), but one owns an expensive classic car and another owns a nice boat and they all could probably afford one.

So are there bad versions of the same? Of course. But being somewhat rich, I don't find that being rich has anything to do with being slimey. I know plenty of people who are both rich and poor who are morally bankrupt and morally upstanding. Generally speaking, in my circles though, the rich people are more morally upstanding as a proportion. That being said, my sample size is small and I'm sure I have a huge selection bias in who I associate with.

Sunny

At the voting booth, you are required to relinquish one of your stubs, either the real or fake one (it's up to you). The boss only has one to choose from.

Not sure if I like the entire idea, but this could be a workaround for your specific problem.

This is a response to these other postings.

Somebody asked this question on reddit
http://www.reddit.com/r/programming/comments/9s3ww/would_you_hire_a_programmer_that_does_not_write/

A while ago my company interviewed someone who, in the course of some standard question, said that after the 5 o'clock whistle blows, they avoid computers totally. They don't have any hobbies involving their PC and often don't turn it on unless they are expecting an important email or need to look up directions. I followed up to ask how they got into programming and they said they took the right courses in college and now has had a few jobs doing it.

Would you hire a software engineer who isn't a hobbyist programmer? What if they avoid computers totally at home? Does it matter if a candidate has strictly a professional interest in software and just pretends it doesn't exist outside the office?

And was answered with this:

http://github.com/raganwald/homoiconic/blob/master/2009-10-08/no_hire.md
No, I Wouldn't Hire a Programmer That Has No Interest in Programming Outside of Business Hours

Here's another way to frame this question: Would I even interview a programmer who only works their programming job from 9-5? If not, why not?

The answer is remarkably simple. No, I would not interview them, for the simple reason that I don't know who they are and they don't know who I am. When I am hiring, my first and best source of prospective colleagues is my network. Industry people I know. Where do I get to know people? Conferences. Open source. Blogging. Twitter. I don't advertise my job openings on monster.com. So how did this person come to sit in front of me to tell me he(?) pretends software doesn't exist outside of the office?

I think you have to align your values with your complete hiring process, not just with your interview questions. If you value people who are passionate about their craft, you have to use a different means of selecting prospects than if you value having warm bodies sitting in chairs. If you want a warm body with a certain minimal competence in a chair, you use monster.com and recruiters to find people. if you value community and craft, you use your network and your community.

Done this way, questions like the above tend to take care of themselves.

The system works pretty well in Vancouver, Canada.

You can use coins as normal or you can dial a phone number to pay by credit card. Each meter has a number used to identify it.

The first time you use it, you have to register a license and your credit card number. After that, it remembers it based on your caller id I would imagine. You can register multiple cars no problem. It's a bit of a pain enter your license the first time you use it (it would be nice if you could try to use voice recognition first) but after the first time, it's pretty smooth.

The nice thing is that you don't have to go back to your car when you run out of time. To me, that is the biggest pain of street parking. Forget that you have to go half a block to pay for parking. If you have to run back from a few blocks, or in the middle of eating, that is even worse. With the system, we just call the number again and it asks if you want to extend your time. You just enter how many minutes.

I usually use it like this: (a) put in as many coins as I have and take a picture of the meter which has the id number with my iPhone (b) if I'm not back by the amount of time I got from the coins, I call and add time.

This is a fantastic idea and having used monitors in portrait mode (vertically oriented) instead of landscape mode, I can never go back. Better yet, there are many monitors that have a built in pivot. You can fit twice as many lines of code and still take very little desk space.

This monitor is a good example.

http://accessories.dell.com/sna/products/Monitors/productdetail.aspx?c=ca&l=en&s=bsd&cs=cabsdt1&sku=320-6272

It is 24" but if you scroll down, you will see how it probably doesn't take any more room than a 17" in landscape mode.

Seriously, as a developer, designer, writer, etc. this is one of the best upgrades you can make.

The assertion that historic jets could shoot this target down may be true, however, the calculation appears flawed because you are assuming that:

(a) the plane is shooting directly up which means it needs to be able to have a completely vertical trajectory at the flight ceiling (or at least that the gun pod can aim directly up which does not seem to be the case from the photos though I could be wrong)

(b) that the range of its gun pod when shooting directly up is not less due to the effects of, say, gravity. I'm guessing that the range estimation of 3000m is assuming a target that is roughly horizontal from the plane. I suppose there could be an increase in range due to reduced air resistance at high altitudes though?

That's a false dichotomy. Many Rails developers are really smart but they won't use Oracle for other reasons. The major roadblock with Oracle is not that it's the wrong tool, it's that it is not free (neither as in beer nor speech).

I don't think we're disagreeing on this point. Your hypothesis is that if you have clustering in a db, then it is easy. I'm simply stating the fact that nobody uses dbs that support clustering with Ruby (MySQL supports clustering but it is an in-memory database). If clustering was well supported in open source databases, I'd agree with you. Also, it's not unheard of for ORMs to support clustering. Sequel, another Ruby ORM engine growing in popularity, has rudimentary support for clustering. I noticed that Rails 2 has implemented many ideas from Sequel already. I wouldn't be surprised, that ActiveRecord starts including some rudimentary support for sharding in the future as well.

That's good for you. But how many OTHER people would be able to incorporate your code into their app. What if they wanted your wiki to support clustering on their open source database? What if they store their uploaded files in S3 and your wiki stores them in MogileFS or just a mapped drive? What you are really building then is a set of best practices that works for you. As an experienced Rails developer, perhaps this is everything that you need; however, most everyone has different deployment needs. What I'm really advocating is that all the same problems that people encounter simply be standardized. This is just like how ActiveRecord standardized database access.

It wasn't too long ago that in the Ruby world, you used a MySQL library, a PostgreSQL library, etc. Then your applications was locked into the database you developed for. ActiveRecord removes the ugliness associated with switching databases and it becomes about developing your app, not about DEPLOYING your app.

Yeah, you're right, some of it is self-contradictory. Let me clarify better then. I don't like the magic that makes it hard to read the Rails code. You seem to not like the word magic. I'm not using it in an evil way. I think most Rails developers actually agree and know that there is a lot of magic in Rails. The problem is that there is so much of it, that it makes it hard to figure out what the code is doing.

All this said, I think the suggestion about no magic is probably more a suggestion for OTHER framework in Ruby that might come out. Rails is too much a framework about magic already. Merb was actually committed to "no magic".

I wouldn't move MP3 manipulation into the ORM because it's not a common problem. In other words, it's "non-relevant junk" as you say. File manipulation and image manipulation is part of pretty much any modern Rails application.

Some might argue that ActiveRecord should not belong in the framework either. What is the dividing line between "in" and "out"? I think it should depend on the commonality of the problem. Database access is so common that making it a part of the framework means that the community gets to share knowledge and improve the data access layer.

In fact, in Merb, ActiveRecord is not part of its framework. I can respect these decisions. I'm just saying that Rails seems to have made the important psychological jump that it's okay to have a "full stack" framework and bills itself as such. In fact, that phrase is one that David Hansson uses to describe Rails. In following that description, it goes that "file" and "image" management become part of that stack. I think this will take longer but I also think some version of this will eventually make its way into Rails.

Well, I don't mean "you" as in the individual. I mean "you" as in each person using Rails. Everybody has to figure out their own way of doing very similar things.

When somebody tries to do something and he says it's hard, then it IS hard for that person. It may not be hard for you, but it is hard for that person. This is a completely different argument than a person saying Java is slow without doing benchmarking. You see, the test for something being hard is that he/she finds it difficult. I know over a dozen programming languages and I know Ruby well enough to have developed a framework with it that, arguably, is larger in scope than Rails. I find doing certain things in Rails so hard that I decided to write that new framework. I've also written image processing engines with a parser in C#, a chat server in Java, embedded Lua, written parsers including a generic one, and I've read and written Gems (though not released any yet). In Rails, easy things are easy and hard things are "possible". I believe this is DHH's words.

For elegant designs where simple things are easy and hard things are, well pretty damn easy, look at Rack. It is the most brilliant piece of library design that I've seen. The entire implementation of the framework comes down to pretty much one method call. I love that simplicity yet there is so much flexibility in it. I wouldn't have believed it's possible until I saw it. This is what great design can lead to. Seriously. Check it out.

My framework was built on my own framework engine before. It is now built on Rack. And as a Rails lover, you should know that Rails, in its conversion with Merb, is intending to (already has?) use Rack as its back end.

Well, I probably don't agree Couch should go into Rails right now because it's not a common problem yet. I think once key/value stores become popular, it makes absolute sense to make it part of Rails. But yeah, not now.

Before I respond, I just want to reiterate the I like Rails and that I really respect its creator; that said, a framework is just a tool and as such it can and should be improved and also that there are other ideas that are different (and sometimes even more radical) that work too.

I agree that clustering would be better solved in the database but I also wish my apps would just write themselves. Neither is realistic or true. The fact is, clustering right now (at least in open source) must be in the application or the framework (note MySQL clustering does not solve the issue). The number of Rails apps using Oracle as a backend are approaching 0%. With the choice between the developer having to write a clustering implementation for every different application and having the framework handle it, I would much rather have the solution in the framework.

The real problem is that if you don't design your app to use clustering at the beginning (which most people don't) then when they need it, it becomes a major issue. It isn't easy to convert a large software project, constantly in flux, to support clustering. Shouldn't you instead just focus on building your app and then when you need clustering, just flip a switch?

You are misunderstanding but understandable so. Actually, I haven't seen any framework solve this problem so it's easy to not see what this really means and if so, if it is possible.

How many reusable features do you see out in the Rails world? I can't remember running across one (though perhaps there is some out there). This is because it takes a lot of work to make a feature reusable. If the framework is designed to not just support reusability (which any framework can do) but instead make it so that any feature you build is AUTOMATICALLY reusable, that is the difference.

Say you build a nice wiki app. Later you decide that would fit in well with your project manager. How much work would it take to get it to work? Normally. A lot. The reason you don't see a lot of reusable components is that it's really difficult to do conversion. Imagine if you needed a forum so you just grabbed the best forum Gem on Ruby and included it in your app with one line of code. Oh, by the way, its also fully clusterable because that's built in to and the same across all features. 0 code changes except the extra line to add it.

This is one that I just can't understand why you don't agree with this. Sure you can have a scalable file system but you have to choose which one and then you can't change it easily. Its okay for ActiveRecord to abstract databases (which everybody thinks is a good idea) but the file system interfaces are different for every system? Just like in ActiveRecord you develop an app for ANY database but WHICH database to use is a deployment issue not a development issue). File systems should be the same way.

For example, say you decide to use local file system. Then your app becomes so popular that you want to move to MogileFS. Now you have to do a rewrite. Then you decide you'd rather not handle this internally and put it to Amazon S3. Another rewrite. Uh oh, I want uploads to go to a local drive and permanent storage on S3. Rewrite again to handle both. Why not just say "/temp" maps to "/local/drive" and "/permanent" maps to an S3 drive.

Also, each additiona filesystem is just another Gem. The framework might come built in with just a local filesystem handler. Then you can just "gem install" the other filesystems. But the point is you don't need to change any of your code. Instead, you just change the config file.

Do you use Rails? There is magic all over the place. Convention over configuration is fine. I like it. But that's not the magic I'm talking about.

You may or may not agree that magic is a good thing, but there is no debate that there is lots of magic in Rails. All the automatic method generation (method missing), autoloading based on names, conversions from singular to plural. That's what I mean by magic. I had considered making my framework more magical but it made it hard to debug. I don't think it's necessarily bad for a language. It means you gain readability of application code at the expense of readability of the framework code. Rails is code is really hard to work on compared to Merb code. I'm hoping that their coming together will help these issues.

I respect what you're saying but I believe it's wrong because every developer needs to figure out a way to store files in the database (usually with some sort of pointer) and then figure out how to manage files in the actualy file system as they are added and deleted. This problem happens to every developer in exactly the same way. To me, that is a prime candidate for moving the problem scope into the framework.

I think I'd agree with you that it should not be in the framework if this is an edge case but pretty much every application requires you to be able to store files or images in the database with a pionter. I wouldn't use a BLOB field due to performance and scalability issues although if you wanted to, you could just define a custom field type like :file_as_blob which might be different than :file.

Don't understand why it would ruin it. It is again a problem that you will come across over and over. Why solve the problem multiple times? Just to be clear, an image is just one custom field type. If you don't like it, don't use that field type. It is not a lot of code. You can also create your own implementation of a field type. The fact is, who hasn't had to figure out how to serialize an object into the database? Why not just give it a field type and then you can insert the object directly into the database and all the serialization happens in one place. Not only that, the custom field type will ensure that ONLY that object type gets inserted. Also, if you decide you want to serialize and object differently, you can fix the code in one place instead of all over your app.

Sorry, the large number of people saying its hard to make Rails do what it's not designed specifically to do says otherwise.

Yep.

In this case, Rails has some ActiveCouch type plugins. I think it would be nice for key/value stores to be supported in the future like CouchDB but not limited to just CouchDB. Not sure with the differences in implementation that this would be possible. key/value stores are definitely not as stable as SQL databases in terms of feature set.

Rails has a lot of problems mixed in with a lot of greatness. For a great many projects, its greatness overcomes its probems.

Its biggest problem, IMHO, is that it does not grow well with the needs of a developer over time. Some things:

  * Doesn't scale well
  * Not easy to do anything outside the Rails world

I had a conversation with Ezra back when he was starting Merb, and I remember the large resistance to the idea that there were problems with Rails at all. As Merb got released and then popular, it was clear that there are holes in Rails (yes I know they are merging).

At about the same time, I started my own framework (the Caffeine framework now the Go framework) which has not been made open yet (and is not complete yet), but there are several issues that it addresses which could help (a) improve Rails or (b) create other frameworks that can fill holes. I'll mention some of the ideas below.

Note that the original goal was to use Rails for our "very cool application" (tm). Unfortunately we have some pretty lofty goals and Rails turned out to be the wrong tool. I am the CEO of a successful Internet company CityMax (about 30 employees) so I do have experience with the problems that happen after launch and success. They are not the same problems as during the startup phase.

Here are some things that an ideal framework has that I believe are missing or lacking in Rails. Again, I do want to stress that Rails has greatness and that I really respect its creator. That said, I think frameworks can grow to another level.

# Built in scalability and clustering. Should require zero changes (except some configuration) to go from single database to a cluster of databases.
# Reusable code. If you build a feature (like a message board) for one application, that same code should be reusable in another app with zero code changes. It should also be reusable multiple times in the same application. For example, a blog app might use the message board in each blog but there might also be a support message board for the whole system.
# Built in scalable file system. The file should be storable in local, Amazon S3, MogileFS, network share or whatever. Directories can be mapped to any file store (e.g. temp directories might be local, permanent storage might be S3 and archives might be a network share). Should be easy to remap directories and migrate from one data store to the other.
# No magic. Hate it. Makes it hard to figure out and debug the code.
# Custom field types for database, particularly the ability to insert files and images into a database record. The actual files and images are stored in the scalable file system and automatically managed (basically automatic garbage collection for files).
# An image field type where you can change the image sizes (e.g. thumbnail, preview, full size) at will and images are automatically regenerated in those sizes the first time they are needed. This is one of those problems that comes out as you get bigger. Say your shopping cart app stores images in 3 sizes. Now you have 10 million products and you want to add another size. Without this, you are basically stuck with the decision you made at the start.
# Make easy things easy and make hard things easy. In Rails, the solution is usually to memorize the option that allows you to do what you want. With the right design, the problems should be solvable using just Ruby and the framework. This helps keep the framework light and easy to learn over time.
# Discoverable. The framework needs to be easy to figure out on ones own. Merb was more like this. Rails was less.
# Multi-threading. This was one of the primary reasons I didn't want to use Rails originally. I understand that threading is in Rails 2 now but I'm not sure how good it is.
# CouchDB. Okay, this feature is a little cutting edge but the biggest issue after launch is migrating the database. Add a new feature that requires a new column on a table with a bajillion records and you're doing many long midnight runs with your crew. A good CouchDB implementation makes migrations a thing of the past. Ideally switching between your db and couchdb should be easy (they should share models and extend them for the differences between each engine).

So far I've implemented all of these features except the last one which I'm working on now. I'm also refactoring a database API to use the same models as the CouchDB ones to reduce code complexity.

The biggest thing during the whole process though is to keep the code small and clean. If you look at the code, in a lot of cases you might wonder why it took so long. I've rewritten many parts from scratch with each version being smaller than the last. I've had my developers look at my code and they could figure it out quiet easily. Reading Rails code gives me a headache. I think the Merb/Rails merger will help this though.