swine:~ msq$ irb
>> $_ = "weird,stuff,comes,here"
=> "weird,stuff,comes,here"
>> nil.send(:split, ",")
=> ["weird", "stuff", "comes", "here"]
Looks very confusing, could be used as one of method to obfuscate code :)
Wednesday, July 30, 2008
The Beauty of Ruby
Well this is kind of weird:
Looks very confusing, could be used as one of method to obfuscate code :)
Looks very confusing, could be used as one of method to obfuscate code :)
Friday, July 11, 2008
Migrations are useless.
Recently I started doubting in all the migration-stuff in MVC frameworks. Why should we use them? Consider a small application (blog or whatever) using an MVC framework. What are the benefits of using migrations? Not-yet-deployed app doesn't need migrations, because no data is in the database, once you've developed it and consider it quite stable you release it to production and than what? I don't think that this kind of application would need so desperately a mechanism to convert your database schema/data to another format, keeping the possibility to revert the changes. This would require much more complicated schema, a simple script would be ok.
But then, with a complicated schema it gets very hard to migrate the data one way, not saying about reverting the migration. You end up with not revertible migration (raises exception on backward migration).Again, wouldn't a script be sufficient?
Also maintaining migrations is very hard. Let's say you have destroyed your database and want to remigrate it (even in test env). Having 100 migration classes all of which preload and all of which where created in different time you are tied to one, latest implementation of each class in your app.
Say ModelA in revision 1 had an no after_save. We used it in our migration, then in revision 2 we added after save to create 2 ModelB's for each ModelA created. Remigrating database from scratch gives you ModelA _with_ after_save because that's your current revision.
So, knowing all this, and having some experience with bigger application and it's migrations, I say that they are quite nasty mechanism and really not needed. You either have an easy app or it's just too complicated to maintain them, you end up with 2-hour-migration-fix knowing that you will probably never use the revert function.
But then, with a complicated schema it gets very hard to migrate the data one way, not saying about reverting the migration. You end up with not revertible migration (raises exception on backward migration).Again, wouldn't a script be sufficient?
Also maintaining migrations is very hard. Let's say you have destroyed your database and want to remigrate it (even in test env). Having 100 migration classes all of which preload and all of which where created in different time you are tied to one, latest implementation of each class in your app.
Say ModelA in revision 1 had an no after_save. We used it in our migration, then in revision 2 we added after save to create 2 ModelB's for each ModelA created. Remigrating database from scratch gives you ModelA _with_ after_save because that's your current revision.
So, knowing all this, and having some experience with bigger application and it's migrations, I say that they are quite nasty mechanism and really not needed. You either have an easy app or it's just too complicated to maintain them, you end up with 2-hour-migration-fix knowing that you will probably never use the revert function.
Subscribe to:
Posts (Atom)
