I did not attend FOWA in Miami last week, but after just 20 minutes of following the twitter stream of #FOWA, I wished I had. The twitter stream was very informative and provided some great quotes and tips from the superb lineup of speakers they had. The organizer of FOWA should make it a point at future conferences to market the twitter feed, because following it led me to realize I absolutely must attend the next one.

I compiled a list of my favorite twitterered quotes and tips from the FOWA feed. Note: Each tip indicates the speaker first, then the tip, and then who provided it via twitter:

• @garyvee: the sucky people are going to lose jobs and people with real skills are going to flourish = “market correction” (via @whitneyhess)
• @spolsky: Breaking bread together every day is critical for team dynamic. Daily team meal keeps them all motivated, connected (via @whitneyhess)
• ?: “If you want 2 create the next phenomenal app stop treating your programming like an assembly line + more like a movie studio.” (via @snoebiz)
• @spolsky: You have to create conversations about your app… advertising isn’t going to work anymore. (via @dimensionmedia)
• @halvorson: Your content is a strategic asset for your brand. Treat it as such. (via @alexdc)
• @spolsky: How to scale your dev team: Lower barriers. Recognize that Jedis are rare, & you need to keep them focused on their core competancies (via @whitneyhess)
• ?: You need uninterrupted time to get work done. Too many people are doing work “moments” throughout their day. (via @orian)
• @jasonfried: if you want to be productive stay the hell away from each other (via @vincefrantz)
• @jasonfried: HTML email gets better results than text emails (via @genuine)
• @jasonfried: Percentage coupons seem to drive more sales than dollar off coupons. (via @jseifer)
• @jasonfried: People are going to trust free services/products less. People will look at companies that are stable. (via @refreshdetroit)
• @jasonfried: I don’t pay attention to the competitors, I don’t care about the competition. I focus on building a great product (via @frederickduboi)
• @jasonfried: Don’t focus on the competition. We’re in a world where 100 companies doing the same thing can be very successful (via @whitneyhess)
• @jasonfried: is there a culture of failure for startups in tech? Jason Fried is saying that fail early and fail often is the current mantra (via @carybran)
• @jasonfried: Fail early and fail often” is not a good credo. Don’t learn from mistakes, better to learn from your successes (via @Murrayiz)
• @jasonfried: “Somehow failure became cool.” Wouldn’t tell a farmer to fail early & fail often. Why do we think it’s ok in software? (via @whitneyhess)

I’m always drawn to reviews of the best places to live (probably because I know where I currently live is not on my top 100). Money recently published a top 100 list, but unlike any previous list I’ve seen before, Money took the time to map them on a Google map. Nice use of technology. I’d much prefer to see the list that way, than to scroll through the list of 100 to see which ones I want to read about. There are some parts of the country I’m less likely to visit or move to than others, so with the map I can look for my preferred areas.

See the map at Money’s web site.

Tripbase is a travel site with an interesting Ajax interface. The site is designed to help the user find travel destinations according to their preferences and interests. For the Ajax interface, sliders are first provided allowing the user to set the type of destination they are looking for, by weighing their preferences on Nightlife, Dining, Shopping, Nature, and Attractions. After that initial selection is done, a list of top suggestions is presented on the page, and further preference customizations are given, including the dates and duration you want to travel, where you are departing from, your preferred weather, your budget, the type of trip you are looking for, the continents you are interested in, and if you want to travel in a high or low tourist season.

As you adjust the preferences on the left, the suggestions update live on the right side of the screen. In this section, it shows one photo of the suggested destination, and shows the cost per day and the population, with a link for more information.

When you click for more information on any of the suggestions, a window appears over the results with the detail information. The detail window shows the temperature, tourist season and rainfall for the period of travel indicated; has photos, and links to articles; a list of things to do, dining, nightlife, lodging, shopping, nature, and then has links to search for flights or hotels (using a different web site).

The interface is easy to use and was very responsive on my laptop using Firefox 2.

Note: I haven’t touched on it much on my site, but I will in the coming weeks. I’ve become a huge fan of Ruby on Rails and have been doing a lot of coding in it during my spare time. It has brought back the fun I used to have developing Internet software from years ago.

Ruby Inside has posted an interview with the developer of Trawlr, Ben Smith. Some of my favorite highlights are:

Almost all the readers I looked at kept each feed separate and behaved like email where you had to keep marking items or feeds as read to prevent a huge, overwhelming backlog.

The way I use RSS is to subscribe to a large number of feeds (over 300) and then simply ‘dip in’ and read when I have time.

When I first discovered the REST features in Rails (via DHH’s “World of Resources” presentation) I didn’t really get it. Once I started to understand that REST is all about modeling ‘things’ and their relationships by creating rich associations it started to make sense.

The additional benefit of using the same code to respond according to the requesting user agent is a major bonus. Within trawlr I mainly use the REST features to keep the code DRY for different response types; rss and opml being two current examples. In the future I hope to add a mobile version.

Read the entire article at Ruby Inside.

After further thought and consideration, I retract my statement that HTML should never be sent back to an AJAX request. There was a reason I made that statement, however I can’t fill you in on it yet (hint: I have to wait for a future software release). But, even with that reason, I have no issue with using HTML in an AJAX response. I wrongly applied a wise and fully correct architectural principle, which I will elaborate on in a future post, to the AJAX situation.

Hopefully at some point in the future, I can go into more detail on why I first wrongly concluded that this should never be done. Until then, rest assured, I will use whatever format fits the circumstance (JSON, HTML, XML).