• Read more about CouchDB-Lucene, CouchDBX, and CouchRest

I’ve been playing a lot with CouchDB lately and if you’re on OS X there’s really no easier way to do so than by using CouchDBX, a self-contained application that includes CouchDB, Erlang, and all of the dependencies you need to run Couch.

However, recently I wanted to try the power and functionality of couchdb-lucene for full-text indexing of a CouchDB application on which I was working. It wasn’t immediately obvious to me how to make that happen, so I thought I’d share how I got it working for those who might want to do the same. For the record, I am using the following versions of things:

• Mac OS X 10.6 (Snow Leopard)
• CouchDBX 0.9.1 R13B pl2
• CouchDB Lucene v0.4

Unpacking CouchDB Lucene

You will need to place CouchDB Lucene in a convenient location, but first you’ll need to unpack the gZip file. Note that, at least for me, the default Mac unarchiver did not provide a suitable .jar file. Instead,  extract it using the following command:

unpack200 couchdb-lucene-0.4-jar-with-dependencies.jar.gz couchdb-lucene-0.4-jar-with-dependencies.jar

It doesn’t particularly matter where you put it (I put mine in /usr/local/etc) so long as you remember the location.

Editing the CouchDBX .ini File

Next you will need to edit the CouchDBX local.ini file to add the external for full-text indexing. To access the file, right-click CouchDBX and select “Show Package Contents” then navigate to Contents/Resources/couchdbx-core/couchdb/etc/couchdb/local.ini and open it up in your favorite text editor. You will need to add the following lines to this file, taking note to change the directory to match where you stored your Lucene .jar file.

[couchdb] os_process_timeout=60000 ; increase the timeout from 5 seconds.  [external] fti=/usr/bin/java -server -Xmx1g -jar /path/to/couchdb-lucene-0.4-jar-with-dependencies.jar -search  [update_notification] indexer=/usr/bin/java -server -Xmx1g -jar  /path/to/couchdb-lucene-0.4-jar-with-dependencies.jar -index  [httpd_db_handlers] _fti = {couch_httpd_external, handle_external_req, <<"fti">>}

All right, that’s all the setup you need to be running CouchDB Lucene! Now you can start up CouchDBX and set up your first search indexes.

Creating a Full-Text Index View

To create a full-text index view, you simply need to add a “fulltext” field to one of your design documents. The URL structure for accessing CouchDB Lucene searches is as follows:

http://localhost:5984/database_name/_fti/design_doc_name/index_name?q=your+query+here

Where database_name is any database you have on your system, design_doc_name is any design document in your database, and index_name is a fulltext index you defined. For instance, if I had a CouchRest generated design doc for a bunch of music, I might have a design document that looks something like this:

{   "_id":"_design/Song",   "_rev":"af12a4b12af1b24afbf244f1",   "fulltext":{     "my_search":{       "index":"function(doc) { if (!doc['couchrest-type'] == 'Song') return null; var ret = new Document(); ret.add(doc.title); ret.add(doc.artist); return ret; }"     }   } }

I would then be able to access the search results with this URL:

http://localhost:5984/myapp/_fti/Song/my_search?q=Ben+Folds

Awesome! We now have full-text indexing up and running on CouchDBX!

Bonus: CouchRest Lucene

I use CouchRest extensively in my Ruby CouchDB projects, and I wanted to be able to integrate the new Lucene searches easily. I found this post that added a bit of functionality, but I wanted to be able to integrate with ExtendedDocument (and the snippet was also slightly outdated), so I’ve updated it. Just add this sometime after you include CouchRest:

class CouchRest::Database   def search(design, index, query, options={})     CouchRest.get CouchRest.paramify_url("#{@root}/_fti/#{design}/#{index}", options.merge(:q => query))   end end  class CouchRest::ExtendedDocument   def self.search(index, query, options={})     options[:include_docs] = true     ret = self.database.search(self.to_s, index, query, options)     ret['rows'].collect!{|r| self.new(r['doc'])}     ret   end end

What this snippet does is allows you to perform searches on a database directly or by calling a search method on an extended document. Let’s look at a couple examples to see how it would work:

@db = CouchRest.database!("http://localhost:5984/myapp")  @db.search('Song','my_search', 'Ben Folds', :include_docs => true)  # The following is equivalent to the above, but will automatically # include the docs and cast the result rows into ExtendedDocuments Song.search('my_search', 'Ben Folds')

Now that we have this set up, we’re ready to go forth and build full-text search into our CouchDB apps. I hope this is helpful to some who have become somewhat familiar with CouchDB but are looking to push it a little further and try out some of the more advanced usages of CouchDB in their applications.

• Read more about Is It Time to Add “Apps” to Marketing’s Venerable “4 Ps”?

It’s been more than four decades since Michigan State University Professor E. Jerome McCarthy theorized that marketing contained four basic elements: product, price, place (distribution) and promotion, also known as the “Four Ps of Marketing.”

Amazingly, despite the unprecedented upheaval and transformation in marketing strategies, techniques, channels and tactics during the last forty years—not to mention marketers’ penchant for postulating all manner of new philosophies, methodologies, rules and acronyms--the Four Ps of Marketing have remained unchanged.

But perhaps now there is good reason to revisit and refresh marketing’s Four Ps: the emergence of “applications” or “apps” as a new means for organizations to acquire, retain or otherwise engage customers and prospects.

What are “Apps”?

An app is a small, self-contained computer program that provides value or engagement to a mass or targeted audience in a community, marketplace or platform. Think of Scrabulous for Facebook; WeatherBug for the iPhone; NBC’s Saturday Night Live widgets; or the Wall Street Journal’s reader for the Blackberry. Apps are commonly grouped via their method of distribution and/or platform:

* Mobile apps: Designed to leverage the unique characteristics of mobile audiences and smartphones, such as the need for location-based information or lightweight, portable versions of larger, more complex services such as Salesforce.com

* Community- or platform-based apps: Those that are developed exclusively for and can only be used on a particular site such as Facebook; and

* Widgets: Portable apps that can reside on multiple third party sites and blogs.

The App Explosion

The proliferation in the use of apps by large and small businesses, as well as non-profit and government organizations is well-documented. Apps have been developed by brands of all stripes as standalone marketing tools or to target fast-growing, communities such as Facebook (350,000 apps used by more than 70% of Facebook’s 250 million users) or the iPhone (65,000 apps available; 1 billion downloads in first 9 months).

And due to their ability to achieve low-cost global or geographically-targeted distribution; their relatively inexpensive development; and rapid time to market—as well as their virtually unlimited potential for creating unique and valuable user experiences—apps have only begin to reach their potential as a new category of marketing tool.

Let’s examine the explosion of one type of app: mobile. The transformation of the mobile web landscape is reminiscent of the original trajectory of the World Wide Web. Very quickly, the consensus shifted from “Why does my company need a Web site?” to “Why don’t we have a Web site yet?” That shift was caused by the reduced cost of developing sites, their practical and proven use in engaging customers, the increase in available bandwidth; and technological advances that helped organizations deliver more useful and relevant user experiences.

The same phenomenon is occurring today with mobile apps: A recent New York Times article reports that nearly half (48 percent) of phone users shop for apps more than once a week and about the same number (49 percent) report using apps on their phone for more than 30 minutes a day; the cost of developing mobile apps has dropped dramatically; and technological improvements are enabling more speed and a better user experience.

How do “apps” relate to Marketing’s Four Ps?

Apps can deliver some portion of the product experience; promote the brand; place themselves wherever customers are; and/or be priced to stimulate trial or engagement. But while “apps” combine elements of each of the Four Ps, they’re neither fish nor fowl--they don’t neatly fit into any one category.

In other words, apps are not products, promotions, channels or pricing strategies. But an app can have some or all of these elements. Apps are…well, they’re apps. Simply put, apps have become a box you check in your marketing plan, right next to the other Four Ps. It’s hard to imagine a new brand launch, Hollywood film, ad campaign or even a fundraising push occurring without the question being asked, “Should we develop a mobile or Facebook app for this?”

Let us know what you think: Do apps deserve their own slot in the marketing mix pantheon, right alongside the traditional Four Ps? Please join the discussion by adding your comments below.

This article was co-written with our friend Bob London, president of London, Ink, a marketing and communications consulting firm headquartered in the Washington, DC metro area.

• Read more about After the iPhone Gold Rush

Apple claims, in their "answers to the FCC's questions," that there are currently about 8500 new apps and updates each week. That makes for a crowded marketplace that is pretty much unprecedented. How can you compete? Well, I think there are two good ways. The first one is ...

Being First

You probably know about Firemint's "Flight Control" by now. It's been a huge success. It dominated the App Store for weeks. How did Firemint achieve this? They obviously poured lots of talent and effort into this title, but so do loads of other games that don't see such stellar sales. My opinion: I think it's because Flight Control defined a genre. Being the first game to clearly demarcate this style of gameplay really paid off for Firemint, because their users got to experience something new, and that experience was worth spreading the word about.

Other games have come along to fill out this genre with gameplay mechanics like shipping (Harbor Master), and combat (Coast Guard). They are great games, and they're worth every penny, but they won't see the success of Flight Control without...

Being the Best

As time goes on, it's getting less and less likely that you'll be first person to come up with a particular type of app. For most types of application, pretty much anything you can think of has been done. You might have an idea, take a glance at the App Store, see a slew of existing apps, and abandon your app saying "I shouldn't waste my time." Well, you might be wrong.

The latest success story to come along is tap tap tap's "Convert." They are a shining example of why, even in a seemingly crowded niche, there's always room for one more. There are dozens of unit conversion apps in the App Store. They are all over the place in function, with some focusing on currency or temperature, and in quality, ranging from weekend projects with bland UIs to the fun and beautiful (and much heralded) "Convertbot" from Tapbots.

How did Convert come out on top? The developers certainly had a fearsome marketing machine at their disposal, but they also managed to build one of the most useful, usable, enjoyable and overall well-designed apps in the App Store. They heavily invested in beta testing, and polished it to a brilliant shine. What they ended up with was an app that appeals to nearly everybody (who doesn't need to convert something once in a while?) that stands out far above every other competitor in usability and user experience. It is good enough to convince people who already bought a unit converter to buy another one (it's just $0.99 after all).

Building a new take on apps that have already been done has some clear advantages. It gives you a chance to look at what works and what doesn't. You can be strategic about what sort of approaches meet with success, and which completely fail, and you can get a good feel for why by using the existing apps. It's a great opportunity because researching the 10 best apps in a certain area might only cost your $20. That kind of research is expensive for complex desktop applications or big enterprise software packages. You can also read the huge number of reviews for the apps you want to compete with to find out exactly where users' needs are before you start building a product. All of these factors mean you have a great head-start when building something that's already been done before, and you can strategically approach building your app in a way that you just can't do when you've got something new and untested.

So, it's great if you can be the first app to do something, but it can be just as worthwhile to build a really excellent version of something that's been done before.

• Read more about Good Idea, Bad Idea: Thingivore's Rails Rumble Post-Mortem

The time has come and gone: the 2009 Rails Rumble is over (from a code perspective, anyway). This year myself and the other members of my team (Brent Collier, Dave Naffis, and Ping Yu) put together Thingivore, a place to show off your collection of movies, games, and books online. As one might expect from a 48-hour marathon application development experience, it was a mixed bag of elation, frustration, fist-pumping and head-hanging as the hours drew to a close. I wanted to take some time to document some of my “lessons learned” so to speak for future Rumblers and app developers in general.

Good Idea: Have a Server Configuration Guru

While the Rumble is primarily a coding contest, it’s important to note that someone on your team needs to be able to get that Linode server up and running. By having someone who can configure centos servers in their sleep on your team, you don’t have to sweat bullets at the prospect of “just getting it running.” In fact, Dave Naffis (Intridea co-founder and Rails deployment genius) came in and 45 minutes later said “OK, just hit cap deploy deploy:migrate” whenever you want to update the server. This is including setting up DNS for thingivore.com, getting Ruby, Rails, Apache, Passenger, MySQL, and CouchDB all running and probably all other manner of dark magic I can’t comprehend.

Maybe it’s because I’m not a server configuration guy, but that’s exactly the point: I didn’t have to worry about it and could focus on the design and development instead of worrying about whether or not we were going to get it running on the competition machines.

Bad Idea: “Let’s Try Something New!”

For some crazy reason, I decided that I wanted to use the Rumble as a way to experiment with new technologies (primarily CouchDB). Do not do this. The Rumble is a time to take the skills you know like the back of your hand and apply them with laser-beam focus to build something awesome and complete in 48 hours. While I’m happy with our product, there are reams of features that were cut while I scrambled to understand some of the complexities of complex sorts and other issues with CouchRest and CouchDB.

Of course, it was also fun to learn a new technology and use it in a “trial by fire” circumstance, but ultimately if you want to build something that can win the competition it’s probably better to stick to your guns.

Good Idea: As Many Plugins As You Can Actually Use

Ruby and Rails provide some of the most powerful collections of reliable code that you could hope for. We were originally planning to go 100% with CouchDB for the project, but when it became apparent that we would have to roll our own OpenID authentication we decided to slap MySQL in as well (only for user models) so that we could make use of AuthLogic and its OpenID extension. This saved us who-knows-how-many hours of work.

We also used some powerful Javascript libraries to achieve some impressive visual effects quickly and without too much pain. When planning your app, think about what technologies you’re using and make sure that there is sufficient library support to get you where you need to be in 48 hours.

Bad Idea: Plans Are For Sissies

This one is somewhat obvious, but it’s a good idea to have a strong game plan heading into something as time-limited as the Rumble. It was unavoidable in our case as I was on my honeymoon in Paris until (literally) the day before the competition, but planning in advance would have meant that every team member was utilized every moment they were available instead of spending time figuring out who should be doing what.

That being said, I think there is also value in not planning too much. During the competition there will be times when you see things that work and you need to let the application grow organically instead of mechanistically sticking to your original gameplan.

Good Idea: Hang Out In IRC

The #railsrumble IRC channel was a good place to be throughout the competition. You get direct access to a couple hundred other competitors as well as the organizers of the competition. If GitHub goes down, if there’s confusion about the rules, you’ll get your answers in a couple minutes.

It’s also just fun to feel the energy of the competition and everything from “Got it deployed!” to “so much left to do and so little time zomg”. I wasn’t able to physically be in the same area as any Rumblers, but I still had a great time and lots of comraderie on the IRC channel.

Bad Idea: Last-Minute Anything

You will have things to do until the last minute. Do not do them. You will have features you want to implement in the last 2 hours. Do not implement them. You will want to tweak the style, tweak a view, tweak something that seems important (but isn’t app-crashing) in the last 20 minutes. Do not do it. Last-minute changes that aren’t to address specific, serious bugs are a terrible idea when you won’t have a chance to fix new problems you introduce.

Next year I am going to try to force myself to spend the last 2-3 hours of the competition doing nothing but finding showstoppers on the production site and fixing only those things. Our OpenID flow was damaged in the last hour of the competition (for registration, not login) and we didn’t catch it until after pencils down. Never again!

Best Idea: Compete in the Rumble!

All in all, you can’t go wrong joining in the Rails Rumble. While your family and non-developer friends probably won’t quite understand what’s wrong with you (“You work 40 hours, over a weekend, and don’t get paid?”) you will have a blast and will learn a lot about how to build things inside a pressure cooker. I know that I plan to be back for next year’s Rumble, and my thanks go out to my team and everyone who made it possible!

Update: I forgot one more bad idea because I didn’t realize it until later…Bad Idea: Forget to Add Google Analytics to Your Site. You know that you will be curious about your visitors as the judging spins up, but if you forget to add analytics (as I did) you won’t have much information at your disposal!

• Read more about iPhone Hack Day at Viget Labs

I recently spent a day hanging out with a few of the guys at Viget Labs hacking on the iPhone.  Ben Scofield, the Technology Director at Viget Labs, was leading an iPhone development primer for a few of Viget's finest, and they were nice enough to let a handful of "outsiders" join the fun.

My iPhone development experience at that point was very minimal.  I had done a few online tutorials and walk-throughs, but nowhere near enough to really understand what I was doing.  On top of that, my Objective-C knowledge was pretty much non-existant.  Fortunately, none of this was a problem.

We spent the first half of the day going over the basics.  Ben walked us through Xcode and Interface Builder, and we talked about basic project layout, the different types of iPhone apps (list, view, and navigation-based, etc).

We then broke off into small groups, pairs mostly, to do a little hacking.  David Eisinger and myself put our heads together on something amazing.  The Text-EmBIGiner, we called it (or something like that).  Picture this, a text field, a button, and a label.  You enter your text, hit the buttom, and BAM -- the label is updated with your text.  It was amazing.  We thought so at least.  Many high-fives were had.

Lunch was provided in the form of Amante Pizza.  Thanks Viget!

In the afternoon we moved on to talk about ways of making iPhone development less painful.  In other words, removing the Objective-C.  We briefly talked about Rhomobile, an open source framwork for building cross-platform mobile apps.

The remainder of the day was spent talking about and playing with two other frameworks, Appcelerator's Titanium and the open source PhoneGap.  Both frameworks allow you to build your app using primarily HTML and javascript, but they still give you access to the iPhone native controls and features.  They were very cool and I could definitely see myself playing with these more in the future.

Overall it was a really fun day, and I'm looking forward to putting my new knowledge to good use.

Thanks again Viget!

• Read more about Looking Back at iPhoneDevCamp 3 at Yahoo!

Our Director of Research & Development, Pradeep Elankumaran, and I attended iPhoneDevCamp 3 during the first week of this month. For those of you who haven't heard of iPhoneDevCamp, it is supposed to be setup as an "unconference", sort of a "Barcamp" type of an event, featuring content from the attendees and dedicated time for hacking on your own applications. Last year's iPhoneDevCamp was hosted by Adobe Systems in San Francisco. This year's iPhoneDevCamp was kindly hosted by the good guys at Yahoo! in Sunnyvale, California.

Yahoo! has an amazing campus that was more than capable of hosting the large amount of iPhone developers there for the event. There were also many "satellite" events going on in different cities around the world at the same time. One really interesting feature that they had at the event was a live stream of presenters of developers hacking away that could be viewed on any iPhone thanks to the new HTTP live streaming available in OS 3.0.

   The event kicked off on the first day with a mixer, which allowed everybody to walk around and introduce themselves to other developers and vendors that were at the event. Chi-Hua Chien gave the keynote and talked about the general growth of mobile and the Kleiner Perkins iFund. After his keynote was another chance to meet others, followed by a musical performance by BT. Pradeep and I "accidentally" had a chance to walk on stage and check out BT setting up his equipment.

   The rest of the event on the following two days consisted of teams hacking on different iPhone applications, which could be entered in to win a bunch of prizes for many different categories. Other keynotes from these days were by Andrew Stone of Twittelator fame and Steve Demeter, developer of Trism. There were also various talks held within different classrooms. Of those in attendance, the majority were experienced iPhone developers, but many others were not. People who didn't have any Objective-C experience helped out web interfaces, graphics, etc. I'm pretty comfortable with Objective-C but Pradeep hasn't had much experience with it at the time. For our project, which we weren't planning on submitting at the end of the event, Pradeep worked on the Rails back end and I worked on the iPhone interface.

   There were some really interesting applications that won awards at the event. Some of those that stood out to us were AR Kit (Best iPhone Open Source App), Nurse Brain (Highest Potential Startup Idea), and iSign (Best iPhone App for Accessibility). AR Kit is an open source augmented reality UI library for displaying location based data in spherical coordinate systems mirroring UI Kit on the phone. Nurse Brain allows nurses to hand-off important data about patients during shift change. iSign opens up people accessibility on the iPhone by introducing a gesture based sign language. There were many other great applications that received awards.

We had a great time at iPhoneDevCamp 3 and hope that we can have the chance to participate again next year. Thanks again to everyone who organized the great event, BT for performing (and not getting your security to throw us off stage), and Yahoo! for allowing the event to be hosted at a great campus. Hopefully, we'll soon be able to reveal what we were working on at the event!

• Read more about Intridea Helps Bring Traffic Alerts to Twitter

When you search the App Store for Traffic applications, you may see a few that simply aggregate traffic information from the same source. TrafficTweet, an iPhone application that we at Intridea helped to develop for Mobomo, aggregates traffic information from Yahoo and also pulls in traffic information posted to Twitter from other users of the application.

Since most people will be using this application while they are driving, TrafficTweet was designed to be easy to use and doesn't require much user interaction. When you load up the application you can see traffic information on a map relative to your current location (through GPS) with icons to represent severity and the type of incident. Information not provided from Twitter is sourced through Yahoo's traffic service.

If you want to report a traffic incident you can just select the severity and click on Tweet Incident. By using the GPS on the iPhone, we allowed TrafficTweet to pinpoint exactly where you are and attach an associated hashtag so that others can search for traffic in their specific area. If you do not have your Twitter credentials stored in the application, your traffic tweet will be posted to @traffictweetme.

TrafficTweet is only available for iPhones running software version 3.0 or higher, since it uses newly introduced native mapping features. TrafficTweet is available in the App Store for only $0.99.

• Read more about Rails Underground Recap

I finally had the time to write up a recap of Rails Underground in London, even though it’s a little overdue. I’ve really come to enjoy smaller regional conferences. Since it’s such a smaller crowd than larger conferences, you get to meet and spend more time with the same people — getting to know them better and pick each other’s brain. Rails Underground was great because of this reason, but not this reason alone.

I was attending Rails Underground to give my talk on Mobilizing Your Rails Application. The point of my talk was to get developers more focused on the mobile web and other mobile technologies and explain how to use certain plugins and gems to accomplish this. I believe my talk went well judging from the response afterwards — and since it was recorded, you’ll be able to judge it yourself as well. If you’re interested, feel free to view the slides here. I’ll be adding a link to the video of the talk as soon as it’s posted.

The conference was spread into two separate tracks for two full days. When I gave my talk, I was up against Pat Allen’s talk about the Community, which was another great talk also being presented at the same time in a different room. I enjoyed all of the talks that I attended but some of the talks that stood out to me were James Wilk’s talk on Cucumber, Pat Allan’s talk on Thinking Sphinx, Dr. Nic’s talk on Blue Ridge, and Jim Weirich’s talk on the Grand Unified Theory of Software. One talk that was extremely creative and entertaining was Paul Campbell’s talk, An Agile Workflow with Rails, which ended up being a hand-drawn story presentation. There were also keynotes on each day of the event. The opening keynote was delivered by Fred George and by Yehuda Katz on the last day.

There’s no doubt that the first Rails Underground was a success. Everybody that I talked to had a great time and learned a great deal of information. I met some new friends, learned some new things, had a great time and would love to attend again next year.

• Read more about Apple Improves Search in the iPhone App Store

When I created the App Store content for our TrafficTweet application, I created a nice list of tags. I was disappointed to see that the App Store didn't have an area to insert these tags in the submission forms. The iPhone analytics vendors like PinchMedia and Medialets already supported tags.

I was pleased that Apple finally added keywords field to the application submission form to improve the poor search feature. So I pasted my carefully crafted keywords (283 characters) into the field. It immediately rejected the entry for exceeding the 100 characters limit. So, I painstakingly prioritized and trimmed the keywords to 97 (an interesting exercise). Ok, this time, it took the values. I went back to change one of the keywords, but it wouldn't let me edit. Lesson learned: you have only one shot at adding keywords. Also, I noticed you can't change the app's title anymore. One step forward, one step back!

• Read more about John Cromartie Talks About Google Chrome OS on eWeek

We eat, live, and breath new technologies. Here is what John had to say about the recent Google Chrome OS announcement for eWeek:

John Cromartie, a developer at Mobomo, said, "Considering the shift in the market towards netbooks and the ubiquity of the web, it really makes sense to have a web-centric OS at the core of the experience. It will be a great thing for netbook consumers if they can get a stable, coherent, focused and well-designed OS for the kinds of computing people are doing with these devices."

However, "The web-app-only model for application development wasn't exactly a hit for the pre-App Store iPhone, but if Chrome OS offers a good API for building web apps that take advantage of OS and device features then it could be a nice platform to work with," Cromartie said. "I'm excited, but we'll just have to wait and see."