Ionrock Dot Org

Yes, you have read the title correctly. I am going to implement some customized pop ups for a client. The usability side is rather silent.

What makes me excited about this project is that I will need to really understand some pieces of Javascript that I haven't really had many opportunities to work with. I understand Javascript relatively well, but with no big projects or even long term daily mucking, Javascript has always been a second hand language. This will have to change.

My basic idea is to create a popup controller that starts a sequence of popups. The controller will send the sequence object to the new popup with the current instance popped off the stack. The stack will continue through for each pop up. Again, not being very familiar with Javascript, we will see if this is what actually happens.

For the actual implementation I have been using Prototype. It is a really great library but I am thinking I might also look more and MochiKit, simply because it is meant to be more like Python whereas Prototype seems to mold Javascript to be more like Ruby. While Ruby is nice and Prototype is pretty familiar, MochiKit is more practical and has more documentation. Wish me luck!

Yesterday I finally finished up an installer for an application I wrote. Making an installer really is pretty easy when you are just installing your own application. The problem comes when you have to tap into other resources on the other machine. In my case I had to make sure there was FrameMaker installed and see what version was installed. This was a hassle to say the least. What was most surprising to me was that you could not debug the installer. It is funny because in the past, using a debugger was not very natural for me. Print statements and logs have always gotten me through the day without many problems but, after working in Visual Studio and C#, I have gotten used to having a debugger.

My work around to the debugging issues was to make a mock installer project and debug the portions that needed debugging outside of a real installer. This worked alright, but overall, I thought it should be possible to use Visual Studio to run and debug an installer. It seems I have come to expect too much from dear Microsoft.

Last night I saw TV on the Radio. It was a great show. The best thing about it was how they connected with the audience. The whole night felt like a fun time, so thanks TV on the Radio!

In other news, I have started using Pylons for my DITA editor and I am a confirmed web framework junkie.

On Friday I saw a need for a new kind of editor. The editor is for writing DITA documents and its implementation is based on creating an effective workflow, in addition to meeting the needs of an organization. As unexciting as this is, I think it is a useful tool that may be helpful. An editor such as this is very important because it implements conceptual practices that are needed by DITA. DITA is a topic based writing format that requires a good deal of abstraction between the appearance of the text and the creation of it. Technical writers often have a tough time fitting their style and ideas into this form because it takes away a good deal of control.

I want to create a small prototype that shows basic user interface details and suggests means of organizing specific workflow into the interface in a way that makes incorrect DITA impossible. In addition to basic compliance, the editor will need to provide other limitations so that documents can be further restricted to fit in the needs of editors. Nay sayers may feel this is lame, but I am somewhat excited about it as practice. Hopefully, I will make something useful.

Today I read this article on how pirating music has been responsible for also raising concert prices. What stuck out was the concept that it is only ticket prices and touring is the only way to make money. The root of this issue can be found at the source. Unfortunately, the source is not the person who created the music, but rather the label that put out the record. The label pays a huge amount of money out to bands to make music. The label assumes it will make this money back, and in fact holds the band liable for advances.

The solution is that bands need to take responsibility for their actions and treat their music career as a business. This sounds shallow but it is the truth. If you want to make money doing anything, you have do it like a business. Music is no exception. Labels have gotten in the habit of trying to put out one big hit because artists do not take responsibility for the risk they take, which means the labels make money on bands whether the bands make money or not.

To direct this back at concert ticket prices, the bands should not consider touring merely advertising as the label does. The bands have an opportunity to make a lot of money with merch in addition to promoting a record. When bands do small things like move their own equipment and use vans instead of buses, the costs start dropping very quickly. Anything a band can do reduce the need for staff will help to make them more money. I am not saying someone like U2 should drop Zoo TV and start traveling in their own van. But, bands that take the time to manage their own tours and understand all the details will be able to use their resources more effectively when the time comes to spend a few million on pyrotechnics and some security guards.

Just to recap, if you are in a band make an effort to enjoy the peripherals around the "biz" and you will be able to enjoy your music that much more.

Today I read a small article on The Morning News. TMN (as it seems to be called) is basically a new site. Having only read one article, it doesn't seem appropriate to make any claims to its content. The article that I read was enjoyable if that is helpful. The most noticeable feature of TMN is the feeling of a regular newspaper. The New York Times does this as well so it is not a surprising design.

The type of design that emulates print media seems odd to me. On one side is the familiarity with the interface. Most people have read a newspaper, so reading a web page that looks like a newspaper should feel familiar. What bothers me is the feeling that using "print" based designs or tactics merely enforces ideas that computers are not entities to themselves. What I mean by this is that in order for computers to be viable and helpful, there needs to be some real world entry point. The "desktop" metaphor and every other user interface metaphor are great examples of this.

As a programmer I am biased, but I do feel it is time to start seeing computers as a medium in itself. Of course there are web pages and sites that do this already and it is obvious that there is software meant to handle electronic data. The point is the paperless office is a total failure because taking paper out of the office is made for using paper. The Internet on the other hand is made for electronic data, so lets move out of the office instead of moving the Internet in.

I have been working on creating an installer for some programs I wrote. This task has been exceptionally simple thanks to Visual Studio. Visual Studio definitly has its warts of course, but when it comes to placing random files on another computer, it rocks.

In other news I spent a good deal of time with Trac. Trac is a project management tool aimed at creating a simple and concise interface for bug tracking, a wiki and viewing a subversion repository. In getting things setup we revealed some bad decisions made in setting up the server it ran on, so we are going to backtrack a bit and see what happens. In the few minutes that I spent working with Trac, I really enjoyed it. There is a current disjoint between the sales staff, support staff and consulting staff that will hopefully be addressed with Trac when everything has stablezed.

Yesterday I also worked on my TourManager project. Just to recap it is a tool for organizing shows and a tours that will facilitate distribution of show info among people who want or need to know. Right now I am still getting around the basic issues of working with TurboGears. This is frustrating at times, but in general the learning curve seems to be leveling out. The design of the system is starting to take shape as well. There are two main components that I am interested in building. One is the actual Manager interface. A band and booking agent could use the tool to keep each others tour schedules and provide helpful information. When we went on tour the last couple times, we had a great book of contracts and everything that could easily be integrated into this sort of system. The other component is a TourXML reader that will function (more or less) like an RSS reader, with the major difference being that it will read the show lists on MySpace. This portion is pretty far off and will be based on some basic code to read TourXML.

With the system design coming together, there are feelings of urgency and excitement. This is such a small issue for bands and yet there is no solution for it that seems to work. My hope is that by the time it is really ready for primetime, I will need to use it pretty consistently.

I wrote this the other day and was trying to post it via my super secret wordpress email address, but things did not work as expected. I chose not to read it over before posting it now so excuse any nonsense. Thanks!

Today I have been working on some C# projects and I had a chance to write a registry key. Being a Linux user for such a long time and having experienced some of the discussion regarding the gconf and its comparison to the registry, it was interesting to get a chance to use it. At this point, I am not really sure what I think. On the one hand, it feels like a hodgepodge place to keep random information. This is the impression that is most often used when describing the nightmare that is the registry. The few times I have typed regedit in my run window purposefully, I was always glad someone else had done this work for me. Gconf, on the other hand, has always seemed more or less intuitive with regard to seeing the organization of the settings. Overall I don't really see the difference between the two systems.

I suppose the largest difference is that the registry is cryptic, not XML and has system information. The cryptic side of things is not that important to me because normal users shouldn't mess with the registry (period). The lack of XML is merely a short coming due to XML not really being available whenever it was designed. The system information then is the only real difference that seems to matter. With Linux, system information is found using standard interfaces using the filesystem and dedicated applications. I suppose that in Windows, this information must be in the registry, which could cause a problem in the case that the registry call is dynamic or cached. For example, if I did some processor specific operation (note, I don't know what this would be), and use the registry settings for my information, then if that information was cached, it could be out of date or corrupted. If the data is updated on the fly, then you have to deal with timing on when to check for updates for different pieces of information.

I have a feeling that the point is moot and gconf is little more than a registry for Linux. I don't have a problem with this because it is a natural issue that needs to be solved. This is the reasoning behind aspect oriented programming after all, there are problems that span across a stack and are not easily handled while keeping code well written. In this case, a standard location and interface to application settings seems like a good idea. Sure, the registry and gconf are probably not the best ideas in the world. But sometimes a problem has got to get fixed and the registry/gconf is as good a solution as anything else so why not. With that said, I still hope to avoid it whenever possible out of shear uninformed fears.

Today I started working on some Javascript for a client. With the rise of AJAX and some very smart folks writing great Javascript code, it is actually a lot of fun to play with. If someone had shown me Object Oriented Javascript when I first saw the language, I believe I would be much different programmer today. It would have been more appealing to understand Javascript and how to use it effectively. Instead, I got into Object Oriented programming through a really junky OO language, PHP.

On the positive side of things, PHP did show me how a language can not have the features needed to do a task. This is why I learned PHP instead of something like Perl or Java (I eventually did learn Java btw). PHP was a great fit for learning to program for the web using simple hosting. When I learned other languages like C++, Java, C# and Python, I went back to PHP and understood design decisions and could appreciate it for what it was, a simple and effective tool for creating template based web pages. I also looked at PHP 5 and realized the vast improvements to the language.

The moral of the story is when looking at languages or technology, context is king. There must be a clear understanding of what the language is useful for and how one can find value in it. This is probably an overly capitalistic representation of my point, but oh well.

In other news, I am off to lunch. I hope to increase my preceived worth to Lauren by giving her a kiss on the cheek when arrive. I am also hoping to increase my value by running an errand for her...

Note: I am making an effort to blog about my work and what I do during the day in hopes that I can learn more from my experiences. So I apologize for assumed knowledge in posts.

Only after you finish something do you think about what sources you could have potentially looked at for solutions to a problem. A great example is a recent table issue I addressed at work. The issue was essentially settings for whether a row or column has a span were getting dropped. Looking back I realize it might have been a good idea to look into how browsers implement this. Of course that would have been a project unto itself.

This is often the case. Today, for example, I wanted to write a blog entry but I didn't want to actually visit my blog admin page. I can't stand using the forms because there is no spelling checking. Yes, I know about firefox extensions and how there are spelling checking tools. The problem is these sorts of tools always get in the way after a while. My blogging solution then was to write a quick script for sending an XML-RPC request to my blog using the MetaWeblog API. This was a seemingly simple task. A few hours later of peripheral browsing while working on my table issue, I find nothing more than a large script for sending the message. This was much more complex than I had hoped and my desire to write a blogging tool quick diminished.

In some ways you could call me a quitter for not spending the time to get done something I wanted to do. In some ways you would be right, but in reality the issue is I have no patience with complexity. The other day I played around with Rails for a moment and realized the biggest contrast compared to something like TurboGears or Pylons. Rails makes assumptions because it is faster. This is arguable of course, but if you assume that it is not, then it is a fact! This is what TurboGears and friends do not do well at all. There is no assumption made about the file names, directories or anything else and this is what hurts it.

The downside is that by making assumptions, it is required that every piece must tested. This was the issue in my table problem. I had to verify every single character I typed, which was very error prone. Fortunately, Rails (and the Python based derivatives) all have good debugging facilities, which was far from anything I had with the table issue. Had I been able to assume a piece of the code was correct, I could have been in a fourth of the time.

Framework rambling aside, I am very proud I fixed the table bug. It was a huge bug that should have been handled a long time ago. Sometimes things slip through the cracks and even though it is a little embarassing when it happens, it feels good fix it in the end.

It is funny to find that you are more pragmatic and practical than you once thought. Now that I am working (full time and everything), my passion for Linux is not what it used to be. I am not sure why this is.

I think part of it is getting my job and seeing some of the difference between Novell and WebWorks. At Novell, everyone that I worked with came from Ximian, a venture capital funded company that never really had a "profitable" product. This is not to say that Ximian didn't accomplish things. They accomplished amazing things. The problem is they didn't make any money doing it. WebWorks, on the other hand, has always been in the black. True, WebWorks hasn't taken off and isn't a Google. But, it has worked hard through hard times to continue to grow and increase profit among its respective field(s) and is now the leading help system vender.

This applies to Open Source because there are many things WebWorks could release that would be beneficial as an Open Source project. The problem is releasing our technology as Open Source doesn't help us get anything done and if we don't get things done, we don't make any money. This is why my faith in Open Source is somewhat fleeting.

I should point out that this is specifically directed towards Open Source as a business model. Open Source software like GNOME and Linux are amazing. I use Windows at work because I have to and the free tools I use everyday are the only way I get things done. We use Python, Eclipse, GVim, Emacs, and Firefox exclusively. We recently started moving our projects over to a Debian box running Subversion. None of this would be possible without Open Source. In fact, I would never have become a programmer had it not been for Open Source software.

With that said, it still doesn't make sense to build OSS for a living. It is viable to use it everywhere you can, make good changes/bugfixes and help OSS development.

I'm done ranting...

In other news, I haven't had a chance to work on TourManager much this weekend, so hopefully I will get a few stolen moments this week to make some progress. I am using TurboGears for a project at work so hopefully, I can get acquainted with it enough to be more productive.

I should say that after using Rails, some of the Python based frameworks are kind of tough. The upside is that the Python frameworks are doing things that is impossible with Ruby. They all seem to use massive amounts of tested an established project sucessfully in a way that allows anyone to put together similar systems. This is the essence of Paste and WSGI and it consistently makes the slightly rougher edges of Python frameworks worth the learning curve.

I worked more on a TourManager application for working with TourXML. It is written using TurboGears (although I also have some code in Pylons). So far it is not much, but I am hopeing things will progress quickly. I am pretty excited to use TurboGears because I found that the author, Kevin Dangoor, created TurboGears to support a desktop app. When I first started as a web developer and began working with Linux, the idea of creating desktop apps in PHP that simply ran on Apache and through a web browser seemed like a good idea. While forcing a user to have Apache is a bit steep, a small Python server seems very reasonable and simple to implement. Once TourManager is working alright, I am planning on making an XML-RPC entry point on the Ume site for keeping the upcoming show up to date.