elarson’s posterous

One of the things that I've learned as a programmer is that you spend the majority of your time reading code. While it is possible that as a developer your sole responsibility is cranking out brand new code, it is more likely that you have a job where there is an existing codebase. Even if your goal is to create new features or applications, it is still likely that you'll be writing tests, working with API's and utilizing libraries. The point here is that if you're a programmer, you're going to be reading a lot of code.

When you're reading code you rarely are gleaning that much information from. It is rare that you can glance at some foreign snippet and immediately know what is going on. Soon after you read code, you end up playing with. Throwing in a print statement or firing up a debugger to see what is happening. Everyone has different methods to how they approach learning about what is happening in a codebase. Personally, I'm someone who uses print statements. Ot her folks like to get things into a REPL, with others setting break points.

At some point though, there comes a point where you are out of ideas. You've followed every code path you can imagine, but you can't seem to find out why the application is doing something that appears utterly impossible. You've hit a debugging wall. It is at this point you separate the good developers from the great ones. I'm convinced that great developers have a knack at endlessly inventing new ways to debug problems. This allows them to not only find answers, but it allows them a better sense of focus as there is always something else to try. At least that is my theory. I wouldn't consider myself a "great" developer. Sure, I read the blogs and program in my free time. The idea of programming as a craft or art is definitely fitting in my vision of the world. At the same time I realize that the mythical EricOS or IonEditor will never see the light of day. The especially rare LPL (Larsong Prog ramming Language) will continue to be a mere glimmer in an exceptiona lly old version of myself. In other words, I'm one of the regular guys that needs to keep practicing.

The big question then is what should be practiced. I've hit a wall more times than I'd like to admit and other than simply asking someone else, it is rare that I find my way out by myself. This might simply be a fact of life, but there is a nagging voice in the back of my head saying that is not the case. Just as there are many different programming models, testing methodology and design patterns, it seems inevitable that there should be a set of debugging practices that help to provide a consistent stream of new insights when looking at a problem. I'm really hoping others chime in with suggestions because I'd love to see what sorts of suggestions people have for getting past a debugging wall.

To help lead by example, one thing that has been helpful getting out of a funk is to start looking at a problem from the other end. For example, if you notice something odd in the output and can't find it looking at the code that does the writing, start from the initial request in the UI and start working your way back. Often times it seems inefficient, but when you're spinning your wheels on a problem, what does it matter if you try spinning them somewhere else in the code.

Hopefully as our field continues to progress, the debugging side of programming will get more attention. The fact that TDD has been such a well received practice, it seems as though debugging could be the next big thing. I for one would welcome the influx of ideas helping me improve the part of my job that seems to always take up the most amount of time an energy. Wouldn't you?

Loading mentions Retweet

It is tough to describe but I've become rather tired of object oriented design. Part of this is because I'm not very good at it. But a larger part is because it seems to muddle two important aspects into one. I'm talking about data and functions of course. The idea makes sense to replicate real world "object" in code and have those object interact. The model sounds so elegant and correct, one can't help but believe it is the right way to go. Yet, in practice, it just gets frustrating.

Folks who know languages like SmallTalk probably have a different take. While I've never done anything with the language, my understanding is that OO in practice broke some very important constructs that made SmallTalk as a language very nice to program with. Specifically, the idea of message passing was meant to be the intended means of interacting with objects.

This small aspect might be just the reason OO has never really sat well with me. Passing messages makes more sense beca use you have an object that provides functionality, but interacts via messages of data. There no longer is a dependency on some object's attribute and any API immediately becomes more stable through the assumptions necessary passing messages. This is part of the reason I really liked WSGI and why functional programming seems so powerful.

When you mix your data in your objects you remove a level of abstraction that is actually helpful. I realize in Java the whole getter and setter pattern is pretty abysmal, but that is because the idea is flawed. The purpose of OO is to make code more reliable by isolating data and cohesively organizing functionality. Things like getters and setters are wrong because they are isolating the data at the language level. As folks in the Python world would argue, that is silly, we're all adults. But, as someone designing an application a more effective means of hiding or protecting data is to use message passing. Just to be clear, in my mind I simply see message passing as calling functions where the message is the set of arguments. You can go in two directions with that by using a dictionary or set of arguments. In this way you can define how lenient your contract is between two objects. If you need a rather strict interface, declare every argument, otherwise, passing in dictionary that is the "message" might be helpful if the object only needs to act on one part of it.

The other helpful aspect of this is that you remove much of the potential confusion found by things like operator overloading. This is very different from designing a model object that acts like a native object or has certain attributes that are dynamically created. This is a natural abstraction that makes sense. Where it doesn't make sense is in objects that are primarily there to perform actions. It is very similar to performing operation in a web application based on GET parameters. This is a bad idea because the understanding is that the operation is idempotent and safe. One would think that accessing a n attribute is safe, but if that attribute does some set of operations, then it is better to use a function so it is clear. Likewise, using actual functions for functionality helps describe the operation in the same way hyperlinks help on the web. You can easily find that function and see what is happening. The more the isolated, the less hunting around in the different objects you have to do to find what some attribute might be.

None of this suggests you shouldn't use objects. It is just making a clear distinction that if an object has a lot of data, it might be best to act on that data via some other object or function. You then have the opportunity to keep things easy to follow and find where something is going wrong. It acts like a map of a code path that helps narrow down where something is broken. This lets you test and isolate issues more effectively and keep the cognitive requirements much lower.

Loading mentions Retweet

Dave wrote a rather long piece blaming bands for not taking the music industry to the next level. I'm not going to say that I don't agree, but I do have problems with the arguments. I don't want to be a whiner either because at the end of the day, if a band wants to make it, they have to work like crazy, which is something we've always tried to do.

One thing Dave mentions is the "Fifth Beatle" character that a band may need. I think this idea is spot on in theory, but I can say for a fact finding a person to actually perform that task without getting paid is huge challenge. There are two routes that seem possible in finding such a person. The first is finding a fan you connect with and trust. The big issue here is that person will be a limited resource and doesn't have the same investments a band member has. The result can be a lack of quality or disinterest over a short time period. The second route includes finding a manager type person. This is a little more practical because in the end there is the potential promise of getting paid if things go well. The downside here is that managers take money and often do not work as hard as band members. Also, it is extremely difficult to find a manager that has the passion, time and entrepreneurship needed to head up an rather inventive band's brand. My guess is that the solution is finding that passionate fan and hope that person ends up the manager. Again, from what I've read, that is rare in terms of finding that person and finding success.

One thing that I agree with entirely is that bands need to make things valuable and timeless. This points to the more common idea that content is king, which has proven itself time and time again both online and off. The innovation Dave brings to this idea is that musicians need to be aware of the synergy tha t needs to happen when bringing excellent content to the web. Unlike many tech start ups, it would be a good idea to consider how you will actually make money earlier rather than later. I think Dave's point is that if you are creatively releasing quality content you should be able to forgo the traditional confines of a label, which brings me to my last issue..

The biggest problem I have with Dave's argument is that there is an assumption that musicians should expect to be in poverty or at least not making much money. My issue is not that musicians are no longer likely to become rich and famous, but rather that there is now an expectation to create complex and amazing work, release music themselves and presumably do so without the support of a label. On the one hand it is definitely possible. I've met some amazing artists that do exceptional work and basically blow my mind with their creative force. Some of these artists, I've come to find out, have a rather wealthy background that allows them to focus the majority of their time and energ y to their art. This is not a negative comment! It is just an observation that many artists who find success have not had to do so within the confines of poverty or financial hardship. Yes there are exceptions, but overall, projects like the hones Dave mentioned have some other party financing things. This does mean that Dave's point regarding setting musician financial expectations isn't valid. But it does mean that bands need to overcome economic factors to have any hope of fulfilling the ideas Dave is proposing.

Dave mentioned the scarcity of attention on the web, but what is not mentioned is the scarcity of talent. It has become trivial to install Wordpress and start blogging, but creating an interesting art piece is totally different. The social web started out free, so going back and asking for money is not an option. The current tools help a great deal with the basics of publishing on the web, but is limited to relatively static content. The fac t is that if you are going to do something innovative on the web, you 're going to have to pay for it. There are ways to find people to help you create this sort of media, but like finding your fifth beatle, it is not trivial to land that magical balance of creativity, quality and price. If you are a DIYer, you can learn to program and try building it yourself. Again, that is not trivial. Most programmers are not very good (myself included). It is rare that you would be an amazing musician that also has the ability to balance a life of coding and playing an instrument. I can say it is worth trying and that is exactly what we are doing. But, as the coder in the band, my job is partly to keep the lights on while more creative ladies have the opportunity to create.

Dave's point regarding the label as a distributor is totally correct. Signing away copyrights to get a record in Best Buy is a huge waste. But, I'd argue that what labels can hopefully offer now are the resources to create with innovation. The label can help to fund the video proj ect you've been thinking about and get it on the web. They can see the vision in a six month single series, help monetize the result and do the fulfillment. I'd guess that the label's were the one funding the examples of valuable and timeless content Dave posted. If the labels are trying to make money, then they seem better suited to find the resources to make creativity on the web flourish. It is as if the label is the producer for a band's brand.

I'm not sure my vision of a label is going to be accurate, but I still believe if a band wants to "break", there is most likely going to be a label or at the very least a manager involved. What is definitely different now is that before to "break" meant selling a lot of records. Now, breaking means finding that critical mass of fans. This is the best part of the new media, the fans. Just because a band can use the canned resources available doesn't mean they have the world at their fingertips on the web. Before labels handle d distribution, but now they need to help push a band beyond the hund reds of terrible music discovery sites and create really innovative content. They need to do this to get fans.

Really, I think Dave and I are probably closer to being on the same page than I might let on. As a programmer with a limited amount of time, I see how difficult it is to find the time and ability to create truly amazing artistic work on the web. In fact that is the reason I'm a programmer and not a designer as I originally set out to be with my interest in computers. Bands do need to accept the web, but they also are going to have to find some serious resources to overcome the scarcity of talent out there. Hopefully labels will realize this and again start putting out the web version of 7" for all the new-punk brewing.

Loading mentions Retweet

I'm making a concerted effort to do a lot more testing at work. Up until this point, tests have always been an afterthought. Something to provide a sanity check that helps to be sure things don't randomly break. There was obviously a little voice in my head nagging me that I should do a better job testing. The goal is to create a more stable environment where we can better evaluate a release. This is an important goal because it establishes the real point of testing, providing better software.

One observation I've found is that unless you start doing TDD or have some sense of what the tests should look like, it can be very difficult to get tests in order. Some might argue that if the tests are difficult to write, it is indicative of the code needing some refactoring. I honestly couldn't tell you if that is true, but my gut suggests that might very well be the case. On the other side of the spectrum, great tests do not make users happy through more usable applications or libraries. There has got to be a balance.

One thing I'm noticing in our own application is a set of global state that seems to always muck up the works. It can be a pain in the neck to always pass around variables instead of relying on a global. You have to consider if that mutable variable you just gave to one object will be modified and potentially affect another object's use of the variable. One solution is to try to pass variables where ever possible, but at that point we've somewhat missed some of the advantages of objects. With that in mind the globals we do have seem relatively benign as they traditionally are wrapping some storage or persistence piece that doesn't logically make sense to always pass around. This doesn't even begin to answer the questions of handling thread safety.

When I start thinking about all these things it really makes me frustrated. It is definitely a morale killer because improving the code slows momentum to a crawl. You want to refactor things to get something more testable and reliable, yet in doing so, you can easily create regressions by changing the previously working tests. Along the same lines refactoring tests seems like a recipe for disaster as you are changing the one bit of code that stands as a benchmark for functionality and quality. Today was particularly frustrating because it felt like every time I started working on cleaning up some piece of code, it became intertwined in the code I was trying to isolate. At this point it seems clear that there is real need, which is a good thing. Hopefully tomorrow things might be a bit clearer on how to start untangling things in a way actually helps improve the reliability of the code and makes for a better user experience.

Loading mentions Retweet

One aspect of time management that is critical to success is finding a way to focus on tasks. For many people, myself included, it is a pretty serious battle that takes tons of practice and creative techniques for fooling yourself to stick to the task at hand. One such technique is the Pomodoro Technique. I haven't read the book or would consider myself an expert by any stretch, but the basic idea seems simple enough to run with it despite formal training.

In a nutshell, you give yourself 25 minutes to complete a task and then take a short 5 minute break before moving onto the next task. From what I understand, the book emphasizes using an egg timer that is visible to make the whole process convenient. Seeing as I'm a programmer and there are multitude of ways built into my desktop to get my attention, it seemed like a good opportunity to create a simple tool.

The result is Focusr. This is really simple timer that helps to complete Pomodoro like cycles. You say you want to start a task, it starts the 25 minute timer, lets you know when the times up and does the same for the break. Rinse and repeat. It is super simple and surprisingly effective.

You can grab it from the web or install it with easy_install or pip. It uses libnotify's

notify-send

command to do the actual notification. Also, I created a simple Emacs function so I could start it easily.

 
(defun pomo ( ) 
 "Start a pomodoro task 25 minutes working and 5 off" 
 (interactive) 
 (setq msg (read-string "What do you want to work on? ")) 
 (setq cmd (concat "focusr " msg)) 
 (comint-simple-send (make-comint "pomodoro-task" "bash") cmd)) 

While I'm sure buying the book could be helpful, it seems more helpful to understand what Pomodoro is actually doing. For myself, it presents a attainable period of time focus on a task. I've read over and over again that one key to better productivity is breaking large tasks into smaller tasks. This is easier said than done though. By taking on the day in 25 minute chunks you're forced to consider how you can break up tasks such that you finish a task with in the time limit. In addition to getting better practice breaking up tasks, you also are exercising your estimation skills and getting a better understanding of how much work you can really do.Like I said before, the concepts are really simple with or without formal training.

For myself, I also appreciate the obvious openness of the system. Becoming more productive is partly effectively utilizing systems while always evolving your techniques. As a person you have an innate ability to hack around your own efforts. I think this technique is simple enough that it can be used many different ways to help keep your mind guessing, which in turn helps to truly learn how to get more focus.

Loading mentions Retweet

I read this article by Lily Allen on music piracy. While I'd like to think that music should be free, after looking at a few offers we've received from labels it is difficult to deny that music piracy has been considered part of the equation.

The big issue is not that record labels are struggling. This is a good thing. Labels have been loan sharks for entirely too long so good riddance. But, as crappy as big labels can be, there are a wealth of smaller labels that do aim to release great music to people because they appreciate what artists are doing. These range from friends that have friends in bands they want to help out, all the way up to labels who have established themselves as viable businesses. For bands, often times a label is the sole party that really can break a band.

There are are plenty of other ways a band can break, but the most common is through a label. The label puts out a record, pays for press, helps improve the bands stature and spreads the word with the result being the band finds a fanbase. The most important thing in this whole scenario for a band is finding the fans. While the critics can be nice to sway and Carling massive attention on blogs has its perks, the real deal is to get your music to fans. As a band, the closer you get to your fans and the more direct relation you build, the better the payout.

In the past bands could make money selling records. It was a big lottery, but it was still possible. Bands also were given the responsibility to do with their money as they chose. A band gets a big advance from the label and uses the funds to build their business (or buy drugs). Now, labels don't make nearly as much money selling music, so they are looking for other revenue streams. This means "partnering" up with an artist. The negative term has become the 360 deal where a label effectively can act as a manager, taking a percentage of the gross income. The more common occurrence from what I've seen is that labels aim to find targeted income areas to cover costs through the artist.

This in and of itself isn't too bad. It can be a huge help keeping the band funds liquid. If a band lands a huge tour or gets massive success, every t-shirt size they don't have is money lost. If a label can make sure you have enough shirts, hoodies and vinyl, that is a definite benefit. Labels can also help find placements and synchs for songs, which can be very lucrative. Again, very nice.

The problem is that while these benefits can be helpful, they can also preclude you from building your own business. If your label is your merchandising outlet, you probably can't make t-shirts yourself. If you have a three record deal, that is probably 3-5 years lost building part of your business. You won't be able to build up your own relationships with another manufacturer or put together your own fulfillment facilities. Likewise, if your label owns some of your publishing, that can end up being a lot of money. Say you have one song that gets 5 placements a year. If you average $2k per placement that is $10k. Over 20 years, that is $200K, which seems pretty good. Take 25% and give it to the label, pay another 20% in taxes and split it up between band members and it quickly becomes rather depressing. Couple that with the fact some labels are asking for actual percentages of tour revenue as well. Also realize that the band is most likely having to pay a lawyer, manager and booking agent (and in some cases a tour manager). Many of these support staffs used to take flat rates, but now all focus on percentages.

Before, if a band got 12% of a record sale they were doing pretty well. They could go on the road and make good money. Now, you don't get any money from record sales even though your percentage might be 50%. In addition to that, you are effectively taxed by your "team" on everything else you do. 5% for your lawyer, 10-15% for your manager, 10-15% for your booking agent, 10-20% for a tour manager, and 10-15% from your label. So, between 45% and 70% of the money you make disappears before you see it. Even if you do "break" and get a decent following, getting $5k a show doesn't mean much over the course of a year. In the famous words of Bill Cosby, "You have eaten yet!" Even if you take home half of the $5k for 30 dates ($2500 * 30 = $75k) you've yet to pay for gas, food, lodging, equipment and taxes. When you consider this money has to cover all the band members living expenses both on the road and off, things start to get rather tight. This doesn't even consider off road maintenance such as wardrobes and props (fog machines and can lighting is not cheap).

I honestly have to agree with Lily that music piracy doesn't really help the artists. It does help destroy the old system, which I do think is a good thing. But, unless there are some provable models for being an artist that don't involve taxes by everyone that helps you break, it doesn't seem like it is any better for artists. In a sense it is potentially worse because at least before, labels sold a product. The initial investment or R&D were directly tied to selling music. Now, everyone wants to get shares in the artists career.

The music business has been compared to the tech industry and venture capital, but I don't think that comparison is quite right. Music doesn't scale the same way technology does. Craigslist is a great example where a really small group of people have been able scale a small business from one city to a whole country. A band simply can't all of a sudden put out an album a day while touring non-stop. They need others to help keep the message out there and no one works for free. The result is that in order to break and make enough money to be reasonably stable, the actual revenue needs to be pretty huge.

With all this said, the fact still remains that I love playing music. It is an honor that people want to invest money in the music that I help create. While we plan on trying to be as shrewd as possible in terms of music as a business, the performers and artists inside just want to get our music out to as many people as possible. It is really all about fans and making that connection, so if that means giving up some ownership in order to help get our name out there, I'm kind of OK with that. The only requirement is that if you want a share of our music, you need to really earn it and be a fan.

Loading mentions Retweet

It feels as though web development has begun to focus on other parts of the stack. Up until recently, the framework decisions seem to be the biggest focus, with MVC based patterns reigning in the masses. At this point though, there is a wealth of documentation and options that make trying out the latest and greatest MVC framework slightly passe. To combat this stagnation in hip web technology, the focus has changed slightly to server technology.

Here are few recent articles to make point regarding the state of web development:

• Unicorn is Unix
• Python is Unix
• Announcing Tornado
• Announcing Diesel

While most of these ideas and concepts are not relatively new in the realm of computer science, they are new to me. I represent a rather large audience of web developers who did not necessarily see web develop from socket libraries to Rails. Instead, my experience began with PHP and didn't include any understanding of what actually happens on the web. Fortunately though, my own forays into web development exposed some consistent patterns that helped me understand what was really happening. So, with these new-ish ideas coming around, it seemed like a great learning opportunity to become better acquainted with more the lower level aspects of web development.

While I have a few projects laying around my home directory for each of the ideas mentioned above, this one is specific to Diesel. I'm somewhat partial to for social reasons. When thinking of an idea for something that might very well benefit from being asynchronous (that is not a chat server), I came up with the idea for a database hub.

The idea for Repeater is that you set up a proxy that will "repeat" the requests to a set of services. For example, if you were using CouchDB, you could set up Repeater, which would be a round robin proxy for the different instances and allow updating all the instances with one request. This doesn't work yet! But that is the idea.

What does work is a basic proxy that will balance between some set of services. It works pretty well from the stand point of basic tests not failing, but I have no idea if it would be extremely slow in practice. The thing that got me stuck is how to handle more requests without blocking when requesting the other site. From the code, you can see where I started messing around with threads to make sure I don't block. The gotcha in all this was that I couldn't figure out a way to effectively yield a sleep or join where the join is when the thread has finished making the request. I'm sure there is a way to do it, but my experiments were not very fruitful.

My overall impressions are pretty good. I'm still a bit hazy on the applications where an async system is an order of magnitude better than a threaded or forking (or both) system. The chat example seems obvious because you have a direct relationship between a client connection and a single process that needs to make responses in order. This is similar to a database connection in that it may need to handle a large amount connections, but at the same time, as soon as you start doing things like requests over the web, it seems inevitable that blocking will be an issue. Although, it seems very solvable.

Loading mentions Retweet

We recently returned from a tour. While on the road, I'm still working. I have a slick bean bag chair, curtains and MiFi router, which makes it possible to get my work done while cruising down the freeway. This is something I've discussed before.

My two recent annoyances with my setup are not having an automatic way of completing an email address and slow updates to the server. So far, the slow updates will probably involve setting up a local IMAP server to sync to and from. It is something that I've started looking into, but haven't spent that much time on it. It ends up being easy enough to just ignore email and save the time. What is rather annoying is having to enter email addresses.

It is not that bad, but it is relatively time consuming. My typing could be much better and it can be easy to make mistakes. Also, there are many times I'm copying the email address from some other resource such as a web page or IRC, in which case, there is a lot of buffer management to deal with. Again, not a huge deal but enough to warrant looking into solutions.

Fortunately, like most things in the Emacs landscape, there was already a good solution in place. The BBDB or the Insidious Big Brother Database. I initially tried using the tips mentioned on emacs-fu but found it didn't work. Fortunately, I found the solution was incredibly convenient and directly in the Wanderlust docs. The result, is now I'm collecting email addresses for completion much like I would get in gmail in addition to having an actual addressbook I might consider using. Pretty nice ROI for googling a bit.

This is realization you need a feature is a pretty common occurance in Linux. The conceptual basis is usually there to create a solution, but often times it takes a bit of work to really get things configured. Emacs is very similar, with the exception being it is almost expected that the configuration might very well be writing a new mode or piece of functionality yourself. It serves as a good reminder that I shouldn't go recommending Emacs to my parents anytime soon. Although it would be pretty cool if I did get a call from my dad asking about setting up a keybinding for some lisp function he wrote.

Loading mentions Retweet

The other day I got rather caught up in the whole * is Unix discussion and wanted to get a better understanding of some of the more low level details associated with writing servers. Eventually, I had a crude version of CherryPy that forked instead of used threads. The benchmark in CherryPy seemed to suggest it was a great deal faster, but honestly I think that was a fluke, especially considering I'm pretty sure there are some serious deficiencies in terms of process management. When Bob posted his forking example on the CherryPy list and mentioned signals, it was clear that I was missing some pretty important understanding.

One thing I thought seemed helpful was that it seemed to use both processors on my system. My understanding is that calling fork will create two separate processes, which effectively should place at least some of the forked processes on different processors. My understanding is that this is how the multiprocessing module works (on Linux at least). With this new cursory knowledge under my belt it was interesting to see an article in my ACM Communications magazine remark on the future of computing and the need to handle multiple processors in a similar manner as sequential paradigms. I should note that this is one of the very few times there was anything remotely interesting to me in my ACM magazine, so I felt compelled to check it out. The idea is not new to me and while the arguments that this is a huge issue is pretty valid, I also started thinking that maybe it is not as big a deal in practice.

The reason for this is the web. Back in the early days of computing people had dumb terminals and logged into a server where all the actual "computing" was performed. While thick clients have been the rage for quite a while, the web is effectively becoming the mainframe in the sky in terms of where people are doing their computing. This should be very helpful in making the jump to parallel computing because there s a definite history and set of tools that have been developed to scale that allow parallel processors. In other words, who really cares if your computer has 2 quad core processors when your searching email online, browsing facebook, checking your bank statements and reading the news through your web browser.

On the web, what really matters is that the sites doing the processing have optimized their architectures to handle the load. The other side of the equation is the browser, but in reality, this is an area that is already becoming more robust. Google Chrome is a good example with its separate processes for each tab, but I would even argue that Javascript is well suited to handle distributed tasks. We've seen a ton of articles on using async servers. Javascript is already using an async model that is only getting faster with the recent developments in new Javascript engines. None of this means that parallel computing and utilization of more processors is not very important. I just don't think it is quite as critical as some might think. That doesn't mean programmers shouldn't try to understand it. After all, it is a hard problems and programmers typically like hard problems. My whole point though, is that the problem might be more of a fad than an actual crux for the IT industry.

Loading mentions Retweet

Some folks are tired of ORMs and raise a good point regarding exposing SQL generation in ORM libs. Most of the time when I use an ORM, there is a moment where I wish I could just get on with things. The declarative approach for creating tables usually is one hurdle that annoys me. Another is defining relations, since it seems so trivial to do that sort of thing in the query. At the same time, I'm far from a heavy database user and can imagine my "it's so simple" mindset quickly deteriorating to massive complexity without much work. Though, I always did like the web.py db layer. It pretty much gave you queries and returned the results in objects. Pretty simple stuff. I think it also let you update those objects and that would be persisted in the DB, but I could be wrong about that. At one time I tried to use it on its own but didn't have much luck. One gotcha is that the db layer depended on running within web.py and had expectations for keeping a threadpool and the like. Thinking back, it could have been very helpful if web.py's db layer did provide some helpers for writing SQL. Based on the article and the comments, it sounds like SQLAlchemy is already able to expose the query mechanism. I'm not sure how this works within the scope of providing model objects, but it sounds pretty promising nonetheless. Likewise, Dejavu, a personal favorite excels an improving queries via translation from language constructs. The NoSQL movement is partially exciting because instead of thinking about relational algebra you think about looping and applying functions. Dejavu uses the same ideas and exposes the Python to SQL translation with its Geniusql lib. Even though I don't really use databases very often, it is interesting to see how people are handling the progressive issues of using an ORM in the real world. Just as databases aren't dead, I believe ORMs are still very important and will most likely become even more important. There is a ton of well tested boilerplate code in ORMs that make creating models much easier. My guess is that even in a world full of NoSQL, we'll still see ORMs help out when it comes to keeping tabs on domain objects. What we won't see is one ORM that supports every database or persistence layer known to man, although there will be people who try to write it.

Loading mentions Retweet