Ionrock Dot Org

My Weblog

Making Music and Scarcity on the Web

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.

Sick of Object Orientation

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.

The Debugging Wall

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?

Upgrades and Fixes

Recently I upgraded to Ubuntu 9.10 and while I was pretty surprised things went relatively smoothly, things still broke. The most noticeable thing that broke was the gnome-panel. It actually didn't "break", but simply didn't continue to work as nicely with StumpWM, so in my mind, that is broken. This has take up a large amount of small moments where I try to find a solution, quickly forgetting what I was doing in the first place.

My Resolution then is to go ahead and drop Gnome. Instead I'll try to only use StumpWM and some select tools to make life easier. Trayer is one such tool and Thunar is another. Hopefully I'll find some others.

One tool that I wished I had was an application folder like in OS X. Most people (including myself) use things like quicksilver or a launch bar to run applications. When you are using Linux and your distro often installs ton of applications that you don't even know what they do. Needless to say, every once in a while it is fun to click things in the application menu to see what you find.

With this ridiculous use case in my head, I took a glance at creating a quick web UI using a PyGTK and WebKit. Looking through a tutorial or two, it became clear that this was something that I wouldn't use very often, so spending the time learning it just didn't make sense. In fact, it didn't make much sense to have a GUI at all since the majority of the time I'm in or near a command line. With that in mind, it seemed fun to create a command line tool to browse the available applications and see what wa s available. Some basic features I had in mind was searching the diff erent categories and automatically running it. Essentially like a command line quicksilver.

I began looking around to see where the heck all those menus get generated and came up all the Freedesktop specs. I started writing some code as I read how the menus should be constructed and quickly became overwhelmed. Things didn't correlate with the menu I was used to. Eventually, I made a breakthrough and saw the default application directory and was in business. My basic task to print all the names and commands for all the entries in the menu was step one and it ended up being the last step.

At that point I looked at the list and realized that I was pretty much done. If I want to search the list there is grep. If I want to try and start some application based on the result, I can either just type it in or pipe it some other helpful program. With a simple listing of application names, categories and executables, I had finished w hat I set out thanks to the power of the command line. What's more, I wrote a bare minimum of code and have actually found it to be useful.

This is the kind of experience I really love. It is great to write a solution to a problem that works and is incredibly simple. A part of me regrets that I didn't come up with a slick new UI concept or something else that might put my name on the programmer landscape, but in the end I'm really OK with that. It is definitely more rewarding to set a small goal and complete it than to set a lofty one and have a constant reminder sitting around your filesystem.

As for going all StumpWM all the time, we'll see how things pan out. One negative that I've found is that it is next to impossible to really use my computer without two hands. But, honestly, other than clicking to another workspace and using a browser there wasn't much I could do anyway without some dedication to the keyboard. I think that overall it is a pretty healthy co nstraint for me.

Weighing Decisions

Sometimes it can extremely difficult for me to make decisions. The idea that one choice could have an extremely long lasting consequences can be rather debilitating. Specifically, we've been looking at some recent record offers and it is really tough to make decisions. They all have their pluses and minuses, which makes it extremely difficult to decide the best course of action. I should mention that I'm extremely grateful to even have an option at all. I know we work pretty hard, but the music business is so subjective with talent being one of the major contributors to success, that I can't help but feel extremely lucky to have any options whatsoever.

No matter what stroke of luck we managed to catch, it still remains that if we make the wrong decisions now, it could effectively nullify any gains we have managed to make. This is an excruciating idea. Music is not like programming in that there is no concept of scaling. With music, you can try to become more prolific but very quickly quality suffers. If you create an application, that knowledge is usually directly applicable to some other application almost immediately. Whether that is a new web framework, programming language or library, you have new tools that can be extremely helpful in overcoming fields. If your album doesn't get enough attention, that is it. Those songs have been used and in some cases sold. There is no taking the lyrics and reusing them a few hundred times over or taking a riff and adding it to all the songs in the next record. Failure has a very deep permenance.

This makes decisions regarding your career very serious. If you choose incorrectly, you potentially lose time, creative output, money, control and the opportunity to succeed. At one point this gamble was very much worth it for bands because they could often get a big enough advance that if they were smart would help in setting up things to move on, even though a band might have failed. Now, labels d on't give you anything and yet still want to take everything. In some cases that might be OK. In the end fans drive everything, so if a label has a good route to helping you find fans, then it might be worth it. This might come in the form of paying for publicity (the bare minimum) to paying for things like videos, special projects and events. Having a backer in your corner can sometimes be worth giving up some "intellectual property" in order to get implementation support. Likewise, it can be just as beneficial to keep the ties as small as possible and hope that the label has the secret sauce to make the smaller mentions count enough that they reverberate through the industry and eventually land on the steps of fans. This is appealing because it is cheaper, which means who ever pays for it is not going to expect to gain control over large portions of the artist's career. The downside is you're rolling the dice in terms of the effectiveness of the resources. More money means you can cover all the bases, even if they may not be the most effecti ve. It is a classic breadth vs. depth problem.

The social media guru would most likely point out that you could do it all on your own using the power of the web. I consider it a given that bands try to utilize their abilities to create as large of an online presence as possible. With that in mind, you still can't dispute that with enough money you can do pretty much anything in terms of exposure. It doesn't necessarily always propagate to dedicated fans and it absolutely will require giving most freedoms as an artist, but nonetheless, it is important to realize that while the gatekeepers are changing and expanding, there is still quite a bit of the old system in place.

Getting back to making a decision, I hope it has become somewhat apparent that no matter what you do, you're effectively gambling. If you win and get fans, you might have sacrificed your ownership, in which case you don't get paid. If you win and get ownership, the number of fans might be limited t o the point you still don't paid. There is always the possibility tha t you simply choose incorrectly and you get nothing. The real kicker is that we're talking music. I enjoy hitting a jackpot on some video poker like anyone else, but betting my songs and a potential career as a musician makes it really tough to choose.

When it is all said and done, I do believe there is a right choice to be made. That choice will be the one that no matter the outcome, we'll feel we evaluated the pros and cons and developed our plan assuming the worst and the best. Even though the decision will be really hard, the up side is that it will just be the beginning of many more decisions exciting work.

Some Emacs Tips

Recently I've been making an effort to automate mundane tasks within Emacs. It makes it easy to include things in my development environment and generally helps keep more things conveniently accessible. Here are some tips that have helped me get more out of Emacs.

Using the Shell

I'm a big fan of shell-mode because it lets you use a shell within an Emacs buffer. This makes things like copying and pasting much more intuitive. It also makes little things like using less and more pointless because you can use the same keybindings you would in a file. One thing that takes a little getting used to is where bash keybindings collide with Emacs. For example, in bash C-p will get the last command you entered but in shell-mode that will move the cursor up. Generally, in shell-mode you can just use the meta modifier instead and get the bash behavior. I've found this to be very natural and find myself wishing I had the same bindings in real shells.

Shell-mode is also nice for running servers. If you develop Rails or Python web apps you usually have a set of command line script you run for things like tests or web servers. Running these in shell mode makes it nice to have an IDE like experience where you can consistently see the running process within your editor. Likewise, you get to review and move around in the output like you would a normal file. This can be really helpful if you made a change that caused a ton of tests to fail and the output is rather overwhelming.

Command Line Applications

As most Emacs users probably do not program in Lisp professionally it is good to consider ways you can use your programming language of choice within Emacs. The shell-command-on-region function is one such tool that helps to make integrating your scripts simple and easy. The function lets you select a region in a buffer and send that as stdin to some application. Just to give you an idea of what you can do, I wrote a small Python script for accepting stdin and pasting it to a company pastebin. I then wrote a simple wrapper function for automatically calling the shell-command-on-region and immediately found an exceptionally helpful tool. Here is the code:

(defun qpaste ( )   "Pastes the selected area to the work pastebin."   (interactive)   (let (string)     (unless (mark)       (error "There is nothing selected."))     (shell-command-on-region (point) (mark) "qpaste -u elarson")))

I can't even describe how helpful this has been pasting tracebacks and diffs that I've gotten via my shell in shell-mode.

Automating Server Starting

One thing IDEs can do well is create an environment where you can start up a set of services to establish a development environment. There are around 5 or 6 different services I need running for development. This ranges from MongoDB to web servers and supporting applications. For these sorts of things there is comint-mode, which is the mode that shell-mode is based on. Here is an example starting a web sever, mongodb and a supporting search service:

(defun foo-mongo ( )    (interactive)    (setq cmd "mongod --dbpath=/home/eric/Work/foo/db")    (comint-simple-send (make-comint "foo-mongo" "bash") cmd)) (defun foo-web-server ( )    (interactive)    (setq cmd "cd ~/Work/foo/web/ && workon foo && paver run_web")    (comint-simple-send (make-comint "foo-web-server" "bash") cmd)) (defun foo-search-server ( )    (interactive)    (setq cmd "cd ~/Work/foo/web/ && workon foo && paver run_search")    (comint-simple-send (make-comint "foo-search-server" "bash") cmd)) (defun foo-start-all ( )    (interactive)    (foo-mongo)    (foo-search-server)    (foo-web-server))

This lets you run M-x foo-start-all and get your entire stack running in a shell-mode like buffer each named according to what is running. You can use this basic pattern to do things like run tests as well and even send the result to your own script using the shell-command-on-region to do things with the output. The possibilities are endless, but more importantly, you can make Emacs more helpful through automating mundane tasks really easily.

Organize Your .emacs

This is a really basic aspect, but being able to load your own functions like the ones mentioned above means you might write a lot of them. You might even have some hooks that create them whenever you start a new project. With that in mind it is helpful then to break up your .emacs file into manageable bits. One thing that makes reading through your .emacs easier is getting rid of the customize settings. This is as easy as:

(setq custom-file "~/.emacs-custom.el") (load custom-file)

This will save all your customization settings in a .emacs-custom.el file. In my case, I had a pretty extensive color customization for font-faces, so avoiding having to see that every time I visited my .emacs was a big win.

As you start writing your own functionality, you can create your own files for those functions as well. This is also really easy to do. Here is an example:

;; foo-app-functions.el (defun foo-tests ( )   (interactive)   (setq cmd "cd ~/Work/foo/web/ && workon foo && paver tests")   (comint-simple-send (make-comint "foo-tests" "bash") cmd)) (provide 'foo-app-functions) ;; in your .emacs (require 'foo-app-functions)

That is it! It's really simple and lets you easily organize your .emacs. Along the same lines, I have a site-lisp directory that I keep all my extra modes and custom files. Just add it to the load path and require the necessary functionality.

(add-to-list 'load-path "~/site-lisp")

Wrapping Up

That is pretty much it. As you can probably tell, I'm far from a guru. But even with these few small tips, I've found Emacs to be a much nicer place. I've managed to start using it for my email, IRC, shell and I even blog with it thanks to Posterous. Even if you don't use Emacs, I think it is clear that having the ability to use and customize a piece of software like this is critical to becoming a better developer. It helps you to take on the role of a user and acknowledge places where things can improve. It also forces you to consider what is going to be "good enough". Hopefully these tips help to get a little more value from your Emacs experience.

More Getting Past Programmer’s Block

Walking into a large code base is a real challenge. I’ve talked about reading code before, but it seems that no matter what happens you can never become a primary source. There have been plenty of times when debugging a problem you come across code that doesn’t make sense and an effort is made to determine what the original author might have been thinking. This isn’t analyzing the person’s state of mind or anything deep, but it is simply trying to understand what the programmer was worried about.

I frame this as “worry” because that is what I do. When I’m writing code, there are usually situations or cases that I’m protecting myself against. Honestly, these are probably premature optimizations, but at the same time, why introduce a bug that is easy to fix. In my mind this seems pretty reasonable, but in looking back at what others have done, my conclusion is it is a terrible idea. Code is there to tell the computer what to do and not what some requirement was at the time or the intent of the programmer. In school we learn to write criticisms dealing only with the subject of critique, yet as programmers, we often inject small snippets of code that really require some background to make any sense at all.

Lately, when I hit snags in my understanding of the code, my recourse has been to step away and try writing something about it. This may be a waste of time, but it does help battle the morale beating nature of reading code. There is nothing worse than having a large piece of code in your editor and constantly putting print statements all over the place only to keep missing the one detail that is important. You feel as though you’re incompetant and in adequant and indeserving of the title “programmer”. So, when this happens, it only makes sense to try a little deconstruction of the issues you’re facing and write about it in hopes someone else might find help or you can talk through the problem.

The technique is not new, but it is still difficult to master. When I worked in an office, there were many times where I’d close the door to really focus. That privacy often led me to start talking to myself, which in turn ended up being an effective means of working through a problem. When I was young, we took a test that help reveal what kind of learner you were. I ended up auditory, which makes a good deal of sense as I’m also a musician. The obvious downside of simply writing about problems is that I don’t get the auditory aspects of the process. That said, I think it is still useful as it means there is still a requirement to improve my communication skills, something that is always useful.

Someday, I really hope that my understanding of the code base is like that of a primary source. It is really nice to have the confidence and understanding of the problem and implementation when maintaining code. If you are the one writing code for the first time, please consider this second source maintainer. This is kind of a “duh” idea to most programmers, yet in practice, I’d argue that most developers miss their non-x86 audience.