• Read more about Present.ly Adds LDAP Authentication

We want to make Present.ly a seamless part of your organization’s workflow. To that end we are excited to announce a new feature that is finally ready to enter beta: LDAP Integration! With LDAP, you can allow your employees to use the same credentials to log in to Present.ly that they use to log in to your other business services, making it easier and more secure by utilizing your existing processes. This is especially useful for large organizations with hundreds of employees, as replicated logins create a great deal of stress and extra work.

To utilize the LDAP integration in Present.ly an administrator of your network needs to go to the Admin page and click on LDAP Settings. The administrator should then fill out the form that appears:

For more detailed information about LDAP usage, visit the LDAP Knowledge Base Article on the Present.ly support pages. This feature is available immediately for all claimed networks. It is still considered a beta feature at this point, so if you have any questions, concerns, or problems don’t hesitate to contact support and we’ll work with you to improve the system.

• Read more about LA Ruby Conference 2009 Recap

Pradeep Elankumaran and I just came back from the very first LA Ruby Conference (Twitter), which was held in Tustin, CA. We didn’t know what Tustin had to offer or what to expect, since it was the first time either of us has visited Tustin. When we arrived at the venue, we were in awe of the few million dollars worth of automobiles surrounding the stage. The conference was held in the Marconi Automotive Museum, which is filled with Ferrari’s, Lamborghini’s, F1 cars — you name it. The event ended up being a huge success due to the great venue and the amazing set of talks, with a final count of 115 attendees.

There were many great talks that ended up covering a wide variety of topics. One very unique talk was by Ron & Damen Evans with their unveiling of Flying Robot, a platform for Ruby Arduino Development. The Ruby powered blimp, flew around the museum, while being controlled by a Wii-mote.

Pradeep gave his talk on Fast and Scalable Front/Back-end Services using Ruby, Rails and XMPP and I gave my talk on Mobilizing Your Rails Application. The kind fellas from Confreaks were there recording each talk as well, so be sure to look out for those when they become available.

From flying robots to creating cross-platform native mobile applications, it’s quite clear that there are some very exciting things going on in the world of Ruby development. Our thanks and congratulations goes out to Coby Renquist, JR Fent, all of the great speakers and everybody else who helped to put on such a great conference. We are both looking forward to going back to Tustin in 2010.

• Read more about Presently is LDAP-ready

If you are an administrator of a large enterprise with thousands of users and hundreds of business units, one of the most challenging tasks you are facing is how to manage those users and groups across hundreds of applications. It would be a nightmare to create users and groups one-by-one in your presently account, not to mention associating all the users with the right groups.

If you are an administrator who worries about sensitive login credentials duplicated everywhere, or you are a user who hates to remember different user names and passwords for all the applications your company has, you might be hesitate to create yet another account for presently.

Now those worries are over, Presently proudly announce that it is LDAP ready. Since most large enterprises already has directory services in place that supports LDAP, while for smaller organizations, setting up an OpenLDAP server or Microsoft Active Directory is quite easy.

Just in case you are hearing about LDAP for the first time, the Lightweight Directory Access Protocol (LDAP) is an open standard that provides an extendable architecture for storage and management of directory information. Widely accepted and fast-growing, LDAP has become the de facto industry standard for accessing directory information over a TCP/IP network. For more details, please visit "LDAP Wiki":http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol .

Let us see what you can achieve by integrating your existing LDAP service with Presently:

* Account admin can easily batch import users and groups from LDAP
directory.
* Users are associated with groups automatically during the import
process according to your organization structure.
* Utilize LDAP to authenticate users directly instead of using local
accont credentials. So no sensitive login credentials are stored locally. And for users it means no more extra logins to remember.
* New user will be added on-the-fly during the authentication process, if his account information has not yet been imported.
These features help to eliminate all the administrator's headaches , and improve users' experience with Presently.

Here is how you can setup LDAP for your account:

1. Login as an admin user of your account.
2. Go to admin tab and click LDAP Settings on the right menu bar.
3. Enter your LDAP information in the following LDAP Settings Form.
4. Save the settings after you finish.

Definition of terms in the LDAP Settings Form:

* __Enable__: Enable LDAP on your account.
* __Server__: Type the IP address of the LDAP directory. Use either the host name or dotted decimal format.
* __Port__: Type the TCP/IP port on which the LDAP server will accept a connection from an LDAP client.
* __Encryption__: Select the communcation encryption method, can be "No Encryption", "SSL" or "StartTLS"
* __Authentication__: If your LDAP server allow anonymous access select "None", otherwise select "Simple" and provide Bind DN and password.
* __Bind DN__: Type the distinguished name (DN) of the directory administrator that allows presently to update information. You must use the LDAP string representation for distinguished names (for example, cn=Chris Smith,dc=intridea,dc=com ).
* __Password__: Type the directory administrator's password.
* __LDAP User Auth.__: Enable LDAP user authenticate for this account.
* __User search base__: Type the distinguished name (DN) of the entry in the directory information tree (DIT) under which user information is stored. You must use the LDAP string representation for distinguished names (for example, ou=people, dc=intridea,dc=com ).
* __Group search base__: Type the distinguished name (DN) of the entry in the directory information tree (DIT) under which group information is stored. You must use the LDAP string representation for distinguished names (for example, ou=groups, dc=intridea,dc=com ).
* __User unique ID name__: Type the user id name defined in LDAP user object schema. Usually it's 'uid', or 'sAMAccountName' for Microsoft Active Directory.
* __Group member ID name__: Type the group member name defined in LDAP group object schema. Usually it's 'member'.

Please email ping_at_intridea_dot_com for questions, suggestions or comments.

• Read more about Rails Template: Create a Twitter Application in Seconds

TwitterAuth has been out for a little while and has received some great feedback. Dr. Nic released a great template that lets you quickly build a TwitterAuth app for deployment to SliceHost and since I have some plans for a number of Twitter applications I wanted to try my own hand at writing one up.

If you have Rails 2.3, all you need to do is run this:

rails -m http://github.com/mbleigh/rails-templates/raw/master/twitterapp.rb yourappname

Changing yourappname to the directory in which you want to generate your application. The template will then prompt you for three things:

• What is your application called? Just give it a title for the pretty template generators.
• OAuth Consumer Key: The consumer key that you register at http://twitter.com/oauth_clients
• OAuth Consumer Secret

It will also ask you if you want to install missing gems and go ahead and generate your databases and run migrations. Once you’ve responded through the prompts though, you’re good to go! Just switch to your application’s directory and script/server. Your http://localhost:3000 should look like this:

When you click on Login via Twitter you will be taken to the Twitter OAuth approval page.

Twitter will then send you back to your application, and guess what? You’re logged in!

You can now build on top of this without having to worry about the basic authentication stack. If you aren’t familiar with TwitterAuth, it works a lot like RESTful Authentication, so it should be easy to pick up.

Enjoy, and I hope you find it useful!

• Read more about Present.ly is a WebWare 100 Finalist!

Intridea’s Present.ly has been nominated as a finalist in the WebWare 100 Communication Category. We’re honored to be chosen from a pool of more than 5,000 applicants to be one of the 300 finalists to compete for the title.

The WebWare 100 is a yearly contest held by CNET that allows the public to pick what the 100 best web applications of the year are. Past winners included such products as GMail and Amazon MP3, so we’re very excited to be included as a finalist for this year’s selection.

Voting is open right now, so please vote for us! We think that business micro-communication is an important next step in the future of communication, and your votes will help validate that and move it even further into the mainstream. Thanks for your support.

• Read more about Highlights from Philly ETE

Last week, I attended the Emerging Technologies for the Enterprise conference outside of Philadelphia.

I love the way these events provide an opportunity to learn. This time, the most interesting things I picked up weren’t new languages, techniques, plugins or gems — they were new perspectives on the work we’re doing.

Brian Marick

One particularly interesting insight came from software testing proponent Brian Marick, co-author of the Agile Manifesto.

His metaphor was that small changes in how we approach software can make a big difference in how we develop it, like “the difference between water at 33 degrees and 32 degrees [ice].”

I experienced that very effect this morning. Because I have been testing more, I want to write code that is easy to test. This required a minor refactoring (yes, I know some of you write your tests first), which made the code more loosely-coupled.

The result: same functionality and a better design — not because I made dramatic changes in my approach, but as a result of putting slightly more emphasis on testability.

Corey Haines

Literal “software journeyman” Corey Haines shared lessons from his extended pair-programming tour of the US.

At one stop, he interviewed OOP guru “Uncle” Bob Martin, who said:

In general, the more people you can work with, the more insights you gain that you simply can’t get on your own. Everyone thinks differently about problems and everyone has a different way to approach them.

In the Rails culture of “convention over configuration” and similar dogmas, it is easy to forget that there isn’t one right way. TDD may do wonders for you, but others might not excel with that approach. That does not mean they are “doing it wrong.” Some of us like TextMate; others vim or emacs; none is “best” for Rails development.

Another example is pair programming: traditionally, one person “drives.” Corey prefers an unusual setup with two keyboards and two mice — though only one person should type at a time :) — it may not be the way you would approach things, but it works for him and few people have pair-programmed with so many different folks.

• Read more about Present.ly and XMPP

Along with the launch of Presently.com, we quietly revamped the backend architecture of Present.ly to better use the eXtensible Messaging and Presence Protocol (XMPP) as the standard message delivery system. You may have noticed near-instant updates on the new web interface — this is primarily due to the super-fast messaging features of eJabberd, the XMPP server that Present.ly runs on.

We believe that XMPP will play a bigger role powering dynamic, real-time web applications in the coming years and have previously blogged as such. While most people in the industry know of XMPP only in its instant messaging role, the fact that there are fully fleshed out specifications for most common enterprise messaging problems as subsets of the XMPP specification is often sadly overlooked.

So what does this mean for Present.ly? In the short term, as you may have already noticed, you will see a major speed improvement posting and receiving updates. In the long term, we are planning on making our user interface a lot more dynamic — details are top-secret at the moment. We are also working on moving over our notification systems completely to XMPP, which will result in you receiving update notifications more rapidly over all your devices. As we grow, we’ll be leveraging eJabberd’s high scalability (due to it being written in Erlang) to provide a seamless, quick user experience.

We are also actively contributing back to the open-source XMPP community. Read about ruby_bosh, the first Ruby library to handle BOSH sessioning in your Ruby applications. We have also made various stability and speed fixes to the stropheruby library, which is based on the libstrophe C library (announcement soon). Both are available on Github for general use. Intridea’s proud to be a part of the XMPP community, and will be heavily using and promoting the technology with both our products and services.

• Read more about Using Git Submodules for Shared Rails Components

In some cases you may have the need to run multiple Rails applications with shared functionality. While Rails 3 promises to bring “mounting apps in apps” and the ability to make the whole process simple, for now we’re stuck in the real world. However, it is possible to share components. This post will walk you through how to set up shared components that live in multiple Rails applications at once and even run specs properly.

A few notes before we begin:

• This post focuses on models but the same could be applied to controllers, views, and more.
• I use RSpec so the testing solutions come from that perspective.
• My applications share a database, so I keep all of the migrations in one app and load from a duplicated schema.rb in the other.

Setting Up Your Application

First, you’ll need to create your shared directory. I’m mounting all shared components to my RAILS_ROOT/shared directory. So if I have app1 and app2 then I’ll do this in app1:

mkdir shared cd shared touch README git init git add . git commit -m "Initial import of shared repository." git remote add origin git@some.git:repository/online.git git push

At this point all we’ve actually done is create a git repository inside our app1 application in the shared directory and pushed it (with an empty README file) to a remote git repository.

What we need to do now is actually delete this git repository and re-add it as a submodule from the remote source (this is from the root of app1 again):

git submodule add git@some.git:repository/online.git shared git submodule init git add . git commit -m "Added shared directory as submodule"

What we did here is add the repository as a submodule using the git submodule command. We then ran git submodule init to update our .git/config to reflect the new submodule.
Finally we committed our changes.

So now we have a submodule living in our application directory, but right now it’s empty and Rails doesn’t know or care about it! Next we’ll set up Rails to make use of the components in the shared directory.

Setting Up Rails To Use Shared Components

Lets say that we’re going to create a shared model, SharedModel. We need to put it in the shared directory but still have it picked up by Rails’s lazy class loader. So in config/environment.rb you
will need to add the following:

config.load_paths += %W( #{RAILS_ROOT}/shared/models )

This tells Rails to look for classes in the shared models path. Now we create our model by creating shared/models/shared_model.rb:

class SharedModel < ActiveRecord::Base  end

When creating shared components I tend not to use Rails’s model generator, preferring instead to create the class by hand and generate a migration separately in my migration-having app.

This is actually all you need to do to get your shared components running in Rails. Next we’ll set up app2 to use the same code!

Setting Up The Second Application

To set up the second application, you basically need to simply repeat the same steps you did for the first application starting with git submodule add. So that would be:

• Add the submodule and initialize it.
• Add the shared directory to the load paths in config/environment.rb

As a note, if you are doing this to an existing application with multiple developers, other developers will simply need to pull from your main application once you’ve pushed it to a remote and run:

git submodule init git submodule update

To get the latest revision of the submodule locally for themselves.

Changing Shared Components

To modify shared components, just change them like you would normal files in your repository. The only difference is that when you want to commit changes you will need to do so from the shared directory, push and then make a new commit from the root directory. This way you are telling the root repository to track a new revision of the
submodule.

Testing Shared Components

So just because we’re sharing components doesn’t mean that we want to abandon TDD, does it? In fact, it brings up a somewhat interesting problem. I want to have specs that I can run for the shared components that can run in both applications, in fact I want these specs to run in both applications to make sure that the shared components aren’t
having any compatibility issues. While this isn’t extremely difficult to set up, it’s not easy, either.

The first step is to create a spec directory inside your shared submodule, and create a spec_helper.rb that simply points back out to the root application’s.

In shared/spec/spec_helper.rb:

require File.dirname(__FILE__) + '/../../spec/spec_helper'

We also need to create a pending spec for our SharedModel to make sure that these are running. In shared/spec/models/shared_model_spec.rb:

require File.dirname(__FILE__) + '/../spec_helper'  describe SharedModel do   it 'should have a pending spec' end

The good news is that if you run autospec from your shared directory, you should be able to see your pending spec run (you will need to create a second spec.opts file in the shared/spec directory for this to use your preferred options). You should push out the changes in your shared directory and get all of your applications up to date. The bad news is that this is the only place your specs will run at the moment. Let’s change that for the better.

Note: You will need to perform the following steps in each of your Rails apps that use the shared components.

First to get your specs running with rake spec we will need to modify the task found in lib/tasks/rspec.rake by performing the following substitution:

# When you see this... FileList['spec/**/*/*_spec.rb']  # Change it to this... FileList['spec/**/*/*_spec.rb', 'shared/spec/**/*/*_spec.rb']

That takes care of the spec rake tasks, but there’s still the matter of autotesting from your application root. This requires a custom .autotest file in your application root that looks like this:

Autotest.add_hook :initialize do |autotest|   autotest.add_mapping(%r%^shared/models/.*.rb$%) { |_, m|     autotest.files_matching %r%^shared/spec/.*_spec.rb$%   } end

This will automatically pick up changes to your shared models and re-run the specs for all of your shared models when they change. You could get more granular than this, but that’s a topic for another day.

Wrapping Up

Now that all of this is done you should be able to freely develop models in the shared directory and have them completely integerated into your normal development workflow. It’s quite a bit of work, but once you iron out the kinks it runs beautifully!

• Read more about Presently.com: Twitter Meets LinkedIn

On March 14 at SXSW, we launched Presently.com, designed to be the first professional microblogging environment. The idea behind Presently.com is that we wanted to bring the best of microblogging and career/professional social networking into one environment. Think of it as Twitter meets LinkedIn.

Twitter pioneered microblogging and its features, like 140-character status updates, followers/following lists, and direct messages have proven extremely popular with users, and the service is growing dramatically.

LinkedIn provides a more professional focus, but lacks social features, and therefore the true, dynamic Web 2.0 communications platform of a true social network.

Presently.com is based on Intridea's Presently microblogging platform, which is used daily by many large corporations and government organizations. Presently extends and maintains the basic Twitter metaphor with additional features, like group messaging; the ability to embed formatted documents like MS Word, PowerPoint, Excel, video and images; message capacity beyond 140 characters without compromising user experience; and extended user profiles to help people more easily identify others with common interests.

Why Professional Microblogging?

There is no doubt that Twitter is a revolutionary communications tool. But some users, even those who limit the number of people they follow on Twitter, are finding the noise ratio to be too high. Trivial and personal communications are inevitable in any public forum, and are in fact a big part of the appeal of Twitter. With Presently.com, we set out to flip the signal-to-noise ratio from 20-80 to 80-20, so serious users spend less time sifting through trivial information.

The Power of Group Updates

In addition to public updates, and private direct messages, features found in most microblogging environments, Presently.com users can create groups and send updates to just a few people, such as the employees of a company, or members of a workgroup or industry organization.

Anyone can create a group for a specific profession, hobby, project team, or any other community of interest. Groups on Presently.com can be public, private or secret. Public groups are useful for encouraging communications and collaboration within particular communities, such as the legal profession, graphic artists, web designers, and gamers. Private groups require an invitation from a current group member, and are useful for closed communications, within, for example, a committee, a sports team, a company, a project team or workgroup, or multiple parties negotiating an agreement or planning an event. Secret groups are private groups that are not listed in the publicly viewable group directory.

Once a group is created, users can send updates to the entire group, to individuals, or to one or more members of the group. Inviting new members is easy. Users can share documents, such as MS Word, YouTube video, Adobe PDF, PowerPoint, and Excel, and can also enter formatted text, including software code, directly into an update. Presently.com maintains threads so that users can see the origin, progression and completion of a conversation, project or discussion.

Who Can Join Presently.com?

Presently.com is currently free to all users. Presently.com allows users with any email address to join and form groups of common interest. Similar services, like Yammer are built around communities based only on common email domains, such that users from a single company can form a group, but can only include members with the same email domain. (For example, you could form a Yammer group with people who have email addresses ending in @yourcompany.com, but could not add people with email addresses ending in @anothercompany.com.)

Try It Out!

Presently.com had a great reception at SXSW. We were really pleased to be able to chat in person with new friends and old. I hope you'll check it out. I'd love it if you did your next group chat on Presently.com to see how much more seamless and enjoyable the experience is. On Presently.com, you don't need hashtags (though you can still use them) so participants, particularly those who are less technical, won't have to use an additional site or service to monitor the discussion. (And you won't lose track of people who forget the hashtag or format it incorrectly.)

Speaking of hashtags, Presently.com has a unique and powerful way of dealing with tags. Once a tag is used, it is automatically added to a tag list. Users can see which tags are the most popular, can click on a tag to see all of the updates related to that tag, and can click to be alerted any time someone uses a particular tag.

If you like the idea of professional microblogging, please create a few groups in Presently.com. There are already quite a few there (many of which we created to get the ball rolling), but the site really needs to belong to users to be effective.

• Read more about TwitterAuth: For Near-Instant Twitter Apps

The public beta of Twitter OAuth support has been released and I’m excited to introduce a new library that I’ve been working on called TwitterAuth. TwitterAuth is a Rails plugin that provides a full external authentication stack for Rails applications utilizing Twitter. Think of it as “Twitter Connect” for Rails, letting you create an application that may be logged into using only Twitter credentials.

TwitterAuth supports both OAuth and HTTP Basic (though OAuth is certainly the recommended strategy) giving you maximum flexibility for building the application. Without further ado, let’s get into the installation and usage of TwitterAuth!

Installation

TwitterAuth is available as a GemPlugin, so the preferred way to install it is simply to add it as a dependency in your config/environment.rb:

config.gem 'twitter-auth', :lib => 'twitter_auth'

You can also choose to install it as a traditional Rails plugin:

script/plugin install git://github.com/mbleigh/twitter-auth.git

Once you’ve installed it, you’re ready to create a new application using TwitterAuth!

The Low-Down

TwitterAuth uses Rails 2.3 Engine support to completely encapsulate the login process within itself. All you need to do is run a generator to make all of the support files necessary in your application. Run it with the --basic option if you want to use HTTP Basic, otherwise it will default to OAuth.

script/generate twitter_auth

This generates a User class, a migration, and twitter_auth.yml. You will need to edit twitter_auth.yml to match the settings of your application, such as providing the OAuth client token and secret.

Once you’ve migrated, that’s it! You are up and running with Twitter authentication; just point users at /login to start the process (login and registration are handled in a single step). For more detailed usage information including how to access the Twitter API through TwitterAuth, take a look at the README file.

The source for TwitterAuth is available on GitHub. I have also created a Lighthouse Project for the reporting of any bugs you may come across. There is also a basic homepage that will be listing who’s using TwitterAuth.

If you’re pretty familiar with Rails authentication systems (particularly Restful Authentication), this is probably all you need to know to get started. Go forth and make awesome apps! If not, I’ve written a quick run-through of the whole process to make it easy for anyone to get started with Twitter apps.

A Quick Run-Through

I think the best way to show what TwitterAuth is capable of is just to show how quickly you can build a simple Twitter application with it. To that end, let’s build a simple way to look at your friends’ timeline in an old-school text-based way (note, this is a totally useless application but works well for a quick demo). First we need to generate the app:

rails texty-twitter

Next we want to install TwitterAuth on the application, so we’ll add this to our config/environment.rb:

config.gem 'twitter-auth', :lib => 'twitter_auth'

Once we have hooked TwitterAuth into the application, we will want to run the generator to build the support files we need:

script/generate twitter_auth --oauth

Before I start on application logic I always lay out a basic HTML layout. Here it is for this application (in app/views/layouts/master.html.erb):

<html>   <head>     <style type='text/css'>       ul.tweets {         list-style: none;         margin: 0;         padding: 0;       }        ul.tweets li {         font-family: monospace;         font-size: 14px;         padding: 4px 8px;       }        ul.tweets li a {         color: #fa0;         font-weight: bold;         text-decoration: none;       }     </style>   </head>   <body>     <%= yield %>   </body> </html>

The next step is to edit config/twitter_auth.yml to reflect our OAuth client key and secret (to register your application log in to Twitter and visit http://twitter.com/oauth_clients). Other than the client key and secret, the defaults are fine for our purposes. We’ve now set up a basic TwitterAuth application; that’s really all there is to it. So now let’s make it a working Twitter application. First let’s generate a controller:

script/generate controller timeline

This will just be a one-action controller that will render out the main timeline for the logged in user in an text-based manner. Here’s the contents of the controller:

class TimelineController < ApplicationController   # this requires us to log in through Twitter before accessing any actions here   before_filter :login_required    def index       @tweets = current_user.twitter.get('/statuses/friends_timeline')   end end

In this action, current_user is the logged in user, and the twitter method provides a simple wrapper around the Twitter REST API that will automatically parse JSON API requests into Ruby hashes for you to use in your application. So current_user.twitter.get('/statuses/friends_timeline') will grab the latest statuses from your friends’ timeline (the main timeline you see when you’re logged in to Twitter) as an array of hashes. Now let’s display the tweets by creating app/views/timeline/index.html.erb:

<ul class='tweets'>   <% for tweet in @tweets %>     <li><%= link_to tweet['user']['screen_name'] + ':', 'http://twitter.com/' + tweet['user']['screen_name'], :target => '_blank' %> <%= tweet['text'] %></li>   <% end %> </ul>

This simply goes through each of the tweets we pulled down and adds a list item with a link to the author of the tweet and the content of the tweet. The structure of the hashes are identical to their description in the Return Elements section of the Twitter API wiki.

Finally, we need to add some routing to tie everything together. Make the config/routes.rb look like this:

ActionController::Routing::Routes.draw do |map|   map.root :controller => 'stream', :action => 'index' end

And we’re done! Fire up your server with script/server and go to http://localhost:3000/. If everything is working properly, it should redirect you to Twitter with a screen like this:

Once you click through and hit allow, it should then take you back and display your tweet stream in an old-school text interface, something like this:

It’s a simple and useless application, but in about 10-15 minutes you’ve created a fully-functioning Rails application that accesses the Twitter API and stores user information. Not bad!

See You At RailsConf!

TwitterAuth is a big part of what I will be talking about at RailsConf in my session ‘Twitter on Rails’. if you’re interested in the plugin and attending RailsConf in May I hope you’ll stop by; I’ll be building an entire Twitter application from scratch during the 45 minute presentation. Also, feel free to follow me on Twitter if you’re so inclined.