• Read more about Upgrades for Presently Desktop

2011 has brought about a series of changes and updates for Presently, including an updated Chrome Extension, a slick new iPhone app, SharePoint 2010 integration and an impressive round of UI changes for the native web app. April has been our busiest month, and today we're excited to make yet another update announcement, this time concerning our new Presently Desktop app!

If you haven't already tried the desktop app, be sure to download it right now and check it out. And if you've used the desktop app in the past, grab the update today and you'll see an immediate difference in the UI, stability and power. In addition we've implemented a long list of new features to make sure that your favorite communication and collaboration tool is pushing the envelope and meets your growing demands.

All of our recent updates aim to homogenize and streamline the Presently experience across the line of our connection options. Now you'll find the same functionality, similar UI, and usability in our Desktop app, iPhone app, and (very soon) our Android app that you've always enjoyed in our native web app. Here's a quick rundown of what you can expect from the update to Presently Desktop:

New Features

• Now you can upload assets including media, text, and other files.
• Added syntax highlighting for pasted text attachments
• URL shortener
• Implemented Direct Messaging functionality
• Can navigate through updates with your keyboard. Get the full shortcut list by pressing "shift+?"
• We created this version around a new Titanium web kit, so it's more stable and will be easier to upgrade in the future. This allows us to keep up with technology and ensures that users will have fewer problems with starting up or closing down the application.

Interface Enhancements

• Keep your updates stream clean by marking your unread messages as "read" with the mouse or hotkeys.
• The update box auto-resizes. When you're not active in the update field, the box gets smaller to give you more screen real-estate. When you're ready to type in the field it auto-resizes to give you space to type.
• No more clicking to load updates; we've implemented endless scrolling to view more updates.
• Now displays Group Avatar on Group messages.
• Previous versions did not support image preview, but we thought that was just silly. So we made sure that your attached image assets are auto-fitted and previewed in your update stream.

Bug Fixes

• Now you can resize the main window! This was a bug in the older version of the application, but we made sure to take care of it with this update.
• Are you a Windows OS user? You will be happy to know that we are taking care of your needs. This update makes Presently Desktop an equally great experience for Windows users as it does for Mac users.
• We've tackled a long list of performance issues and bug fixes. That translates to a faster, more intuitive and stable application for our users.

Visuals

It's fun to talk about all the technical changes we've made to the desktop app, but it's even more fun to show you! Below is a screenshot of the Windows and Mac versions of the Presently Desktop app in action at Intridea:

More to come!

We've been busy making your microblogging experience more pleasurable and intuitive so that you can be more productive; and we're not finished! Our new Android app is waiting to be released in the Marketplace, and we'll be sure to update you as soon as it's available for download. Work continues at Intridea to improve Presently across all platforms. We'd love to hear your feedback about the changes we've been making. Connect with us on Twitter or send us an email and let us know your thoughts!

If you're not using Presently already it's time to try it out! At Intridea, we developed Presently because we needed a wide-scale collaboration and communication solution for our team of developers, sales people, marketers and business developers. We use Presently every day as our main tool for communication across our company. We're excited about this product and the problems that it solves, and we think you'll love it too. Try it out today, or give us a call; we'd love to talk to you about how Presently can serve you and your business.

• Read more about Announcing SparkBin - Private Beta

Today we're announcing SparkBin, a new Intridea product entering private beta for Google Apps customers that offers you a better way to gather ideas from within your company.

Your employees have great ideas. Unfortunately, it's too easy to overlook that spark of genius when it's trapped in an e-mail or a conversation. SparkBin is a tool for aggregating all those ideas, ensuring they don't get lost in the shuffle. It's also a way for your team to receive immediate feedback on their ideas.

SparkBin is entering private beta today. We'll be letting companies in over the coming weeks until we're ready for the public launch. Register for access and keep track of all of those ideas that have been kicked around in the company communication channels.

Gather Ideas Quickly and Effectively

Submitting ideas is seamless. It only takes a few seconds to submit an idea to SparkBin, and that frictionless experience will drive your employees to submit more ideas more frequently.

Works with Google Apps

SparkBin is integrated directly into Google Apps, so your employees don't have to set up new accounts or worry about remembering yet another password. They can simply log in and see the ideas from everyone else in your Google Apps domain.

Increase Engagement

SparkBin offers a leaderboard that displays the top ideas submitters for the week, month, and all time. Ideas are only counted when someone other than the submitter likes it, so this encourages broad engagement and friendly competition inside the company to become a "King of Ideas".

Easy Organization

Ideas in the SparkBin are organized by tags, so you can organize them any way you like. Want to group ideas by product, business unit, or department? No problem!

We've been using SparkBin internally to gather ideas and have found it to really helps to get people talking. We're excited to begin sharing this with others, and look forward to feedback from a much wider audience!

• Read more about OmniAuth: Flexible, Unassuming Multi-Provider Authentication for Rack

The web application landscape has changed drastically in the past year or two. Where once every site was a silo unto itself and could reasonably expect users to create a unique login and password for each site, it is now a different story. I sigh every time I have to fill out yet another registration form, wishing instead for a simple "Connect with Facebook", "Sign in with Twitter", or "Log in with OpenID". At the same time, services are more interconnected than ever. One of the best ways to increase the popularity and viability of a new service is by piggybacking it onto the existing user bases of apps such as Twitter, Facebook, and Foursquare.

There are lots of authentication solutions out there for Rails. Many of them even have ways to connect to services such as Facebook or Twitter. But as I used these in project after project I noticed an emerging pattern: they all make too many assumptions about how I want to handle authentication in my application. Sure that makes it a quick start for the vanilla use case, but I honestly can't think of a time when I've dropped in an authentication solution and I was good to go. It's time for a change in perspective.

OmniAuth: The Unassuming Authentication Library

Today is the public release of OmniAuth. OmniAuth is a Rack-based authentication system that abstracts away the gritty, difficult parts of external authentication without assuming anything about what you actually want to do with that authentication information.

What does this mean for you? This means that you can make your app authenticate through Twitter, Facebook, LinkedIn, Google Apps, GitHub, Foursquare, and more and then have complete control from there.

Installation

OmniAuth is available as a gem:

gem install omniauth 

Diving In

Using OmniAuth is as simple as using any other Rack middleware. Of course, that's because OmniAuth is simply a Rack middleware. No complicated framework-specific configuration, just a collection of middleware to take the pain out of external authentication. Let's say I have a Sinatra app that I want to be able to authenticate via Twitter or Facebook. Here's what's required:

require 'omniauth' use Rack::Session::Cookie # OmniAuth requires sessions. use OmniAuth::Builder do   provider :twitter, "CONSUMER_KEY", "CONSUMER_SECRET"   provider :facebook, "APP_ID", "APP_SECRET" end

That's it! Now if I want to send my user to authenticate via Twitter, I send them to the URL /auth/twitter. For Facebook, /auth/facebook. The user will automatically be redirected to the appropriate site where they will be able to authenticate. Once authentication is complete, they will be redirected back to /auth/providername/callback and OmniAuth will automatically fill the omniauth.auth environment key with information about the user, so for my Sinatra client I just need to add:

get '/auth/:provider/callback' do   auth = request.env['omniauth.auth']   "Hello, #{auth['user_info']['name']}, you logged in via #{params['provider']}." end

Of course, I could do a lot more than just print out the user's name. I could also:

• Check for an existing user via the uid key of the auth hash and log them in if one exists.
• Create a user based on the uid and information from the user_info hash.
• If a user is already logged in, associate this new account with the user so that they can log in using either service or post to both services using respective APIs.

The point here is that OmniAuth doesn't assume that you simply want to log a user in. It lets you make that judgment call and gives you all the information you need to do just about anything you need to do.

OmniAuth works right now for a wide variety of providers, and this list will continue to grow. OmniAuth today supports:

• Facebook
• Twitter
• 37signals ID
• Foursquare
• LinkedIn
• GitHub
• OpenID (meaning Yahoo, Aol, Google, and many more)
• Google Apps (via OpenID)
• CAS (Central Authentication Service)
• LDAP

A Breath of Fresh Auth

OmniAuth has been my worst-kept secret library for some time now. I've been using it as the go-to authentication strategy for new projects big and small for the last few months, and it feels really refreshing to have so much control over authentication without losing the drop-in ease of use. If you need external authentication but have found existing solutions to lack flexibility, please take a look!

OmniAuth is on GitHub with a growing set of documentation on the GitHub wiki and I have also set up a Google Group to handle any questions that might arise.

• Read more about FlockFeeds Launches From Node Knockout

This past weekend was the first Node Knockout, a 48-hour development competition utilizing Node.js. Always up for exploring new technologies, Intridea was represented at the competition by Michael Bleigh, Sean Soper, and Jerry Cheung. 48 hours later, FlockFeeds has launched!

FlockFeeds is a simple tool that will turn your Twitter stream into a news feed. That means that you can simply add the FlockFeed to your RSS reader (such as Google Reader) and FlockFeeds will automatically fetch all of the links that your Twitter network posts, do its best to understand the content and parse out the important stuff, and put it into an easy-to-consume feed for you.

The application is powered by Node.js, Express.js, MongoDB, and Readability.js. Look for a more in-depth technical post in the near future detailing the participants' experiences developing in Node.

Not only did FlockFeeds launch, but we've decided to open up the source code to the public. Feel free to check out the code on GitHub. So give FlockFeeds a try, and don't forget to vote for it in the competition! Voting closes Friday, September 3.

• Read more about MultiJSON: The swappable JSON handler

JSON has become ubiquitous. From Facebook and Twitter both declaring it to be the preferred (and in some cases only) option for API access to the new OAuth 2.0 draft spec declaring that JSON is the only acceptable response format for OAuth token responses, JSON is here to stay. What isn’t ubiquitous, however, are people’s preferred implementations.

As library authors it is our duty to try to support as large a part of the community as possible and do so in a friendly manner. To that end, today we’re releasing MultiJSON, a simple library that allows you to seamlessly provide multiple JSON backends for your library with intelligent defaulting. Install with a simple gem install multi_json and then get started like so:

require 'multi_json'  # Decode using default engine. MultiJson.decode('{"abc":"def"}) # => {"abc" => "def"}  # Set an engine using a symbol. MultiJson.engine = :active_support  # Encode using ActiveSupport MultiJson.encode({:abc => "def"}) # => '{"abc":"def"}'

This gem is primarily for library authors, allowing you to use the best JSON available on the users’ systems without explicitly requiring one library over another. This way you can be sure that your JSON handling will work across implementations (e.g. JRuby) as well as requiring as little extra code as possible (the gem detects existing libraries before requiring more by default).

Engines supported by default are:

• yajl-ruby
• json (gem)
• active_support
• json_pure

We hope that this will make development of JSON-relying libraries a little bit less of a headache for library authors and users alike. The code is, as always, available on GitHub.

• Read more about OAuth2 Gem: Just in Time For Facebook's Graph

While I’d been tracking with great interest the progress of OAuth 2.0, Facebook lit off the powderkeg yesterday by announcing that their entire API was moving to the protocol (as well as to RESTful JSON). As a developer who had been constantly confounded by the relentlessly hostile environment that Facebook seemed to present to developers, yesterday was a sudden and welcome about-face. The acquisition of FriendFeed, it seems, gave Facebook the talent they needed to do it right this time.

But anyway, on to the news! We have just released a gem for OAuth 2.0 to work with the new Facebook API. You can get it right now:

gem install oauth2

We wanted to get this into the hands of developers ASAP so for now the functionality is pretty much limited to the “web server” type of authentication (the protocol includes many different strategies, all of which will be implemented on the gem over time) and has been tested to work with Facebook’s new API.

So how do you use it? Here is an example Sinatra application containing all of the code necessary to authenticate and then perform requests against the Facebook API.

require 'rubygems' require 'sinatra' require 'oauth2' require 'json'  def client   OAuth2::Client.new('api_key', 'api_secret', :site => 'https://graph.facebook.com') end  get '/auth/facebook' do   redirect client.web_server.authorize_url(     :redirect_uri => redirect_uri,      :scope => 'email,offline_access'   ) end  get '/auth/facebook/callback' do   access_token = client.web_server.get_access_token(params[:code], :redirect_uri => redirect_uri)   user = JSON.parse(access_token.get('/me'))    user.inspect end  def redirect_uri   uri = URI.parse(request.url)   uri.path = '/auth/facebook/callback'   uri.query = nil   uri.to_s end

So now you’re ready to get started with the new Facebook API! This is still an early release, but I’ll be working on it a lot in the coming months, partially as preparation for my talk at RailsConf in which I’ll be delving into the OAuth 2.0 specification and what it means for Rails developers in-depth. The code is, of course, available on GitHub where you can report any problems you run into. Enjoy!

Update: Those who aren’t terribly familiar with the protocol may wonder why OAuth 2.0 isn’t just rolled into support of the OAuth gem (or why I didn’t fork it and do it that way). Honestly, I would have liked to, but OAuth 2.0 is an almost entirely different beast than 1.0a and they share so little functionality that it would basically be two projects living under the same gem name. So that’s why!

• Read more about Redfinger: A Ruby WebFinger Gem

Just yesterday, Google turned on webfinger for all GMail accounts. Today, we’re releasing a RubyGem to help you use the new protocol!

What’s a WebFinger?

WebFinger is a new protocol for extracting public information about a person via their e-mail address. It is meant to complement systems such as OpenID as well as give a simple way to get basic information about a user without having to ask them for it.

E-Mail providers can implement WebFinger by creating a special URL (specifically at /.well-known/host-meta) that is an XRD XML document telling the requester a URL at which they can find out more about e-mail addresses on their domain. Google’s, for example, is http://www.google.com/s2/webfinger/?q={uri}. When the WebFinger endpoint is requested with an e-mail address in place of {uri}, Google looks up information about that e-mail’s public profile and provides it in a standardized XRD XML format.

So why WebFinger when OpenID already exists? Users are used to associating their e-mail address with their identity. It’s natural since an e-mail address is (usually) for a specific person. By putting a protocol in place to find out more about an e-mail address without requiring additional input from the user, a host of options become available.

For instance, if I’m an application looking to authenticate using OpenID, I can ask a user for their e-mail address instead of their OpenID URL (something that will confuse mainstream users to no end). Or, if I want to automatcially fill in basic profile information, I can check to see if a parseable profile page is available in a format such as hCard.

Enter Redfinger

Redfinger is a library built to easily consume the WebFinger protocol. Installing it is simple:

gem install redfinger

Using it is just as simple:

require 'rubygems' require 'redfinger'  finger = Redfinger.finger('youraccount@gmail.com') finger.open_id.first.to_s # => "http://www.google.com/profiles/youraccount"

Redfinger will query the host of the e-mail domain specified, and, if the Webfinger protocol is supported, retrieve information about that e-mail address including such links as OpenID Provider, hCard URL, and more.

How can you use this today? Well, if you’re an OpenID consumer you can use the above code to try to “intelligently find” an OpenID endpoint from an e-mail address. Of course, it will just about only work with Google at the moment (this is an alpha protocol, after all). Or, you could install the mofo gem (a gem for parsing microformats for web pages) and do some neat things with microformats:

require 'rubygems' require 'mofo' require 'redfinger'  finger = Redfinger.finger('account@gmai.com') card = hCard.find(finger.hcard.first.to_s) card.fn # => "That GMail user's full name" card.title # => "The title he/she entered on Google Profile"

Here Redfinger determines a URL that will have hCard information about the e-mail address specified, and the Mofo gem goes out and fetches that address, parsing out the information.

WebFinger is still brand new (Google calls it “alpha”) but it shows some promise for being a great way to make the open web more seamless for users. As always, the Redfinger source code is available on GitHub and RDoc Documentation is available. Check it out!

• Read more about Simple Mustache JSON Serialization

If you’ve taken a look at Mustache, the “stupid in a good way” templating engine, you might know that there are also Javascript Mustache renderers such as Mustache.js. Today we’ve released a small library called mustache_json that allows you to compile your Mustache view objects into JSON, allowing them to be interpreted by Javascript Mustache rendering engines.

What this means for your project is that you will finally have a identical client-side and server-side rendering interface, opening wide the opportunities for pushing more of the rendering work onto the client-side, a boon for many real-time and heavy-interaction applications.

To install mustache_json, just get the gem from Gemcutter:

gem install mustache_json

To use it, simply require 'mustache_json' and all of your Mustache objects will automatically be given a #to_json method. For instance:

require 'mustache_json'  class Person < Mustache   def initialize(first_name, last_name)     context[:first_name], context[:last_name] = first_name, last_name   end      def initials     "#{context[:first_name][0..0]}.#{context[:last_name][0..0]}."   end      def listing     "#{context[:last_name]}, #{context[:first_name]}"   end end  bob = Person.new('Bob', 'Bobson') bob.to_json

This will render into a JSON object that looks like this:

{"last_name":"Bobson","initials":"B.B.","listing":"Bobson, Bob","first_name":"Bob"}

Mustache JSON gives you access to all of the public instance methods you declare in your Mustache as well as any context you have set. It is essentially a fully compiled version of the Mustache view, providing everything another renderer needs to create the actual markup. The JSON back-end for this library is swappable, meaning you can use the JSON gem, JSON pure, ActiveSupport, or Yajl by default (and any other class with an encode method if you’ve got a different library).

Documentation is available on RDoc.info and the source is available on GitHub. Stay tuned for posts in the future about utilizing this library to actually perform identical rendering in Ruby and Javascript.

• Read more about Hashie: The Hash Toolkit

One of my earliest gems was Mash, a useful tool for creating mocking objects as a Hash. One of the most common problems people had with Mash was a simple one: it conflicted with another class of the same name in extlib! To address this problem as well as give the project some room to grow, Mash is now part of a new toolkit called Hashie. Hashie is available now via Gemcutter and the source, as always, is available on GitHub. To install:

gem install hashie

Hello, Hashie

Hashie is, right now, simply the former Mash code along with a new extended Hash called a Dash. A Dash is a “discrete hash” that has pre-defined properties. It can be used as a dead-simple data object when even something like DataMapper is too heavy, but a Struct is too light (Dash gives you the ability to set per-property defaults as well as initialize from an attributes Hash). For example:

class Person < Hashie::Dash   property :name   property :email   property :occupation, :default => 'Rubyist' end  p = Person.new p.name # => nil p.occupation # => 'Rubyist' p.email = 'abc@def.com' p.email # => 'abc@def.com' p['awesome'] # => NoMethodError  p = Person.new(:name => "Awesome Guy") p.name # => "Awesome Guy" p.occupation # => "Rubyist"

The other advantage Hashie has over Mash is that it’s built from the ground up to avoid conflicts. Instead of adding stringify_keys methods to the Hash class, it’s instead added to a Hashie::Hash subclass. You can, however, get Hashie’s few Hash extensions in the Hash class by including the HashExtensions:

Hash.send :include, Hashie::HashExtensions

Hopefully the move will make it easier for everyone to use it in their projects without fear of running into conflicts, and hopefully you’ll also find the Dash useful. Over time the functionality of Hashie may grow to encompass additional simple and useful extensions of Hash. So install Hashie, your friendly neighborhood Hash toolkit, today!

• Read more about Presently Adds SharePoint Integration

We’re always looking for ways to make it easier to integrate Presently into your day-to-day workflow. Today, we’re happy to announce something that will make it much easier for businesses using Microsoft’s SharePoint to integrate Presently. Starting today businesses can use the Presently SharePoint Web Part.

The Presently Web Part will allow you to view and post updates to your company’s Presently account from directly inside your Microsoft SharePoint portal. For more information on the installation and usage of the Web Part, you can visit the SharePoint application page.

We have also released the source code to the web part, it’s available on GitHub. Please feel free to contact support with any additional questions.