Change is coming to how we get the radio we listen too. Radio listeners will go from having 10 choices on their radios to thousands. Good times, good times.

Sunday, December 31, 2006

Eventful is a great tool

Using Eventful.coms api is about the best tool I know of for bands to get show announcements across the internet. Its powerful because not only does your show get listed on Eventful's site, but other sites use the api to fill in content on their site too. I've even seen more creative uses of Eventful data like Podbop. When people talk about Web 2.0, they are talking about things like Eventful letting other sites access and contribute to its event database. A very cool thing.



I've just pushed an update to 4gauge that allows bands to submit new shows they create to Eventful. It brings a lot of power and usefulness to the site.

Saturday, December 30, 2006

Nextcat

This is a good site for bands to get thier name out there, and hook up with other indie artists / producers / labels.

www.nextcat.com

From their site -
At Nextcat, we’re hoping to create the first global online networking community
for all things relating to the entertainment industry.

We’re 100% independent, and not beholden to any large corporation. With
Nextcat.com, we hope to provide a marketplace of ideas and opportunities for
both established and emerging talent, as well as a forum and meeting place for
fans and enthusiasts.

Friday, December 29, 2006

Puzzles

4Gauge Update

I've put up some new features on 4gauge.com. You can now add photos of shows you've done, and see pictures from other bands who've played the venues on your schedule.





Check it out, and bands should get an account if you don't already have one.





powered by performancing firefox

Podbop

This is soo cool. If you want to know what bands are playing in your town, get this podcast. If you are a band, make sure you're listed.



www.podbop.org





powered by performancing firefox

Friday, December 22, 2006

Good user facing CMS

Allowing users to do their own content management is difficult to get right from a usability standpoint. I've been working on a form that allows users of 4gauge.com to build custom email reminders that will go out to the venues they are scheduled to play.



The first goal is to make it clean and simple to understand. The challenge is to achieve the first goal while still giving the user enough wiggle room that they end up with a product they are happy with.



Here is what I came up with for the email -







I like the way this turned out. The system has control over most of the email, even the dynamic part like band name and show date. Then there is a text box right in the middle of the email. This gives the user a feel for what the final email will look like as they are creating it. I made the background of the email just a little off of white, so the white background of the text field gets pushed to the foreground. That makes it more obvious that there is an area for the user to edit.



What do you think?





powered by performancing firefox

Thursday, December 21, 2006

Heckle Your Tests

Heckle is getting some well deserved attention. I think it is important for development team managers who want to make sure that the code being checked in each week has adequate test coverage.



Gluttonous : Tormenting Your Tests with Heckle



powered by performancing firefox

Trademark vs. Service Mark

We've just spent some time obtaining a Service Mark for the phrase "Like Dating For Jobs" on this site - Climber.com. It raised the question for me, what is the difference between a Trademark and a Service Mark. The answer is kind of subtle. Trademarks are for things you sell. Service Marks are for services you provide. Climber provides the service of finding people jobs in a way very similar to dating, thus its a Service Mark. If we were selling a "Super Duper Resume Spellchecker", that would be a TradeMark.



More here - Trademark vs Service Mark





powered by performancing firefox

Wednesday, December 20, 2006

Happy Holidays

Performancing for the new Blogger

The new Blogger breaks many of the old Firefox plugins that allowed posting to your blog from the page you are viewing. Thankfully, Performancing is the exception. It works nicely.





powered by performancing firefox

acts_as_solr

Acts_as_solr is a great plugin for all your rails apps that need search. It takes all of 10 minutes to install Solr AND the plugin.

http://acts-as-solr.rubyforge.org/

Tuesday, December 19, 2006

Simple Tools for Hardworking Bands

Yesterday 4Gauge went live. It is the beginning of a much larger project, and larger still ambitions. I'm very proud of it.4Gauge is a tool for bands out on tour to easily keep in communication with the venues they are scheduled to play. Bands can choose to send a 7 day reminder, 1 day reminder, or both.

Read more at 4gauge.com

Friday, December 15, 2006

techno weenie

Good things are coming to rails with ActiveResource

Read more at weblog.techno-weenie.ne...

Tuesday, November 28, 2006

How to Build a Universe That Doesn't Fall Apart Two Days Later

Building a community around a band, website, or whatever is hard, keeping it healthy and thriving is a lot harder still. 

Read more at deoxy.org/pkd_how2build...

Sunday, July 09, 2006

Thursday, January 19, 2006

Ubuntu and servers

I love Ubuntu. I really do. I've been using it for about 9 months now, both at home and work. It is flexible and easy to upgrade. Recently, I was spouting off about how great Ubuntu is, and someone asked my why then I wouldn't use it in a server environment. My response?

Mostly the right tool for the job argument. Ubuntu is designed to be a workstation distro. Ease of use often goes hand-in-hand with lax security measures. RedHat is a good choice for home rolled production servers. Debian and Slack if you have a bit more experience. (Debian is pretty darn easy, especially coming from Ubuntu)

The best reason I know of, is when you run into problems on your server, you want active forums of experts who can help you. RH, Debian, and Slackware all have admins with gobs of experience who will help you. The Ubuntu server crowd is not going to be as robust.

Now, all of that being said, I do all of my development (rails included) on a VMWare virtual machine. Most of them are running Ubuntu in server mode. The reason I do this is because it is dead simple to set up, and file structure is exactly the same as my base machine. It makes things easier.

Bottom line, you can certainly use Ubuntu for a production server, but you'll be mostly on your own fighting an uphill battle to get the machine secure. You can do it, but it will take research.

Last word, I've only ever had one machine compromised, and it was a Fedora box. So take all the nice things I said about RedHat with that grain of salt.

Agile schema

I like to start with a database layout when building up a new site, but I go for the minimalist approach. Trying to flush out every table, and every column is right back to the waterfall model of software development. Agile development demands that you do only what is necessary to make the current test pass. If that means having a cusomer table with just an "id" and "name" field, so be it. With TDD its easy to flush out the db design as work progresses. There will be time to add address, phone, and bra size for a customer later. Its even easy to shut down a model and move its pieces around. Its true that changes like this tend to have concequences far and wide, but with tests in place, its easy to know what code needs to be massaged.

The idea is to hold off making structure decisions until the last possible minute. Once a data schema is set, it can get inflexible, even with good tests in place. I want to always leave the maximum amount of flexibility until I have no choice.

Example - does the "first name", "last name" fields go in the customer table, or the credit card table, or both? I've built apps all three ways, and untill you've gotten a lot of use cases, flushed out those cases, and even rewritten them with the user, it can be difficult to know which one is proper.

validator mixins

There was a proposal on the Rails mailing list this morning about divorcing the validation code from ActiveRecord, and making it its own mixin.

------------------------------------------------------------

It seems to me that Validations are quite useful for many objects, even
ones having nothing to do with ActiveRecord.

Common examples are Contact Us forms, multi-step forms, web service
paramater validations, etc.

I took a look at the source for Validations, and it seems that it is
very independent from ActiveRecord. I caught only three depenedencies:

1. validates_numericy --> depends on ActiveRecords' before_type_case
2. The exceptions were from the ActiveRecord namespace
3. Including Validations hooked on methods like save

It would seem to me that Validations would be best off as an independent
mixin. All ActiveRecord would need to do is mix it, add
validates_numericay (1), catch the exceptions and rethrow them as
ActiveRecord exceptions (2), and hook save type methods (3).

What does everyone say? Would this be a good change? Is there an
important reason for *not* doing this?


------------------------------------------------------------

I've been developing a data storage system based on Ferrett that clones the ActiveRecord interface, and having the ability to mixin validation instead of rolling my own makes my brow twitch like Elvis. "Better than a penut butter, bannana sandwich baby"

I've been calling my search based data storage IndexRecord, and the goal for its interface is simple. Have models subclass IndexRecord instead of ActiveRecord, and have them be interchangable. Currently, a model could be used like this. Imagine the power of mixing in validators.

class Page < IndexedRecord
#setting up searchable fields in Page documents
fields :page_number, :text
end

Then you can do stuff like this -

page = Page.new
page.page_number = 23
page.text = "One flew over the cookoo's nest."
page.save

pages = Page.search("text:cookoo") #gives back a hash of unique control_id and summary

Now, imagine with validators mixed in, this model would be one step closer to AcriveRecord functionality.

The end of one thing...

I resigned today from my old post today. That has to be one of the hardest things there is to do in business. Or, I suppose some people are dying to do it because they are unhappy, or whatever. I am not one of those people. In fact, I do not understand how someone can go, day after day, to a job that they do not like. Along with my family, my job fills out my life. Just like raising my boy, it gives me purpose.

That is why leaving is so difficult. I feel like I'm leaving a cause I have poured blood and sweat into. Everyone at my old job is hardworking and dedicated. I do not know if they will eventually be successful, but I do hope that is the case. Good people.

...Is the beginning of another.

So, every ending is followed by a new beginning, and that is what I am looking forward to with Mingle.com. I start officially on the 27th, but have been working on a project for several weeks as a contractor. We are using Rails for web development, and that has been new as well. After a bump in the learning curve, I've began to pick up what I need really quickly. The grammer of Ruby is intuitive, and elegant, making it easy to pick up new knowledge from code examples. The community on the mailing list, blogs, and forums is a real assett for the language as well. If you're trying to learn Rails, get on the list.

Speaking of learning Rails, I can only luke warmly recommend the new Agile book. While I have it, and reference it a lot, it leaves a lot for the 2nd edition. Most importantly, test driven development gets about 3 paragraphs in it. One of the things about Rails that is so attractive is how dead simple unit testing is. TDD was cumbersom at best for web design before Rails. With Rails, TDD is the only way to go, it is the strongest argument for using Rails in an Enterprise size project. The book has it as little more than a footnote.

Worse, when the book does get around to Unit Testing, they completly miss the boat on how to do it. Unit tests are NOT written after the code is in place. Even calling it "Testing" is a misnomer. Testing is for before and during development. Normal work flow goes like this - Test, code, test , refactor. Having the tests lying around is just a bonus ( a big one though! ) They allow you to refactor with confidence that your changes are isolated.

I see a maket for a book that dives into Rails with a TDD model.