Mobomo webinars-now on demand! | learn more.

It's been close to a year since Rails 3 came out and I've had the pleasure of working on several Rails 3 projects since its release. Some existing gems became irrelevant with the release of Rails 3, while others lived. Additionally, we've seen many new gems come to life. I'd like to share a stack of gems that I've been using this year. Hopefully they will give people a bit of help while developing a new Rails 3 app.

Most of these gems have good documentation on their project wiki (every great gem should be well documented, right?), so I won't go into great detail about the mechanics. Instead, my aim is to introduce you to some of the gems I find most useful and separate them into meaningful categories, as a sort of reference guide.

Here we go:

» Authentication

The above two are really amazing gems for speeding up your authentication. Yes, I love both of them in different cases: ideally, OmniAuth is better for applications which want to support multi-provider external authentication, which is why I've just added OmniAuth into the RefactorMyCode Rails 3 branch to take advantage of its auth benefits. Devise is totally powerful enough for the classic authentication case. However, if you have too much business logic inside your login/registration/auth flow, you definitely need to make your own authentication.

» Access Control

Ryan is a star in the Rails world, so naturally his CanCan gem is really popular, but with good reason: it does really powerful authorization. However, declarative_authorization is also a good option. In fact, Ryan mentioned CanCan was inspired by declarative_authorization.

» Views/Page and Admin Scaffold

From a front-end perspective, I suggest you might want to try the above gems to speed up and simplify your UI design process. For example, rails_admin gives you a nice interface to manage your application's data.

» Quick SNS

These gems will allow you to prototype the basic functionality of your application quickly without having to worry about creating everything from scratch - so you can focus more attention on the meat of your application instead of the nuts and bolts.

» Form and Related Tools

Most of the above gems are famous through RailsCasts. There are two pairs of options here: simple_form and formtastic or paperclip and carrierwave. I like all these solutions, and you should pick the one that fits your project. If you want to know the differences between each pair, get more details on their wiki :) tiny_mce is an HUGE gem for rich editing; I list it here to remind you that it exists, but I recommend you get the WYSWYG via a JS lib like CLEditor - it works gracefully.

» Search Solutions

In regards to search in Rails, I bet there are some strong opinions out there. I want to split these gems into two types: Object-based searching and Full-Text searching. I highly recommend you use meta_search and/or meta_where for object-based searching because it can convert your form params directly to a search solution which is super convenient. Full-Test searching depends on your use-case, but all these three gems (thinking-sphinx, acts_as_indexed, sunspot) are great.

» Pagination

Yeah, you can use will_paginate in Rails 3, but I will suggest you should give kaminari a try, that's really cool.

» Background Work

These are two projects that accomplish basically the same thing. There is a post that introduces resque clearly here. In the post, the Github staff mentions their brief history of doing background jobs and they do a good job at highlighting the differences between the two.

» Status Machine

I like to use workflow a bit more than state_machine, since it's more natural to me. You definitely need one status machine to control your stable flow stuff, such as a registration flow status or a wizard-like features.

» Rack API framework

This gem is for adding REST-like APIs to your Rails/Sinatra application. Michael gave an awesome presentation at RubyConf2010 on Grape; I recommend watching it to see the greatness of Grape for yourself. I believe you will fall in love with it.

» Memcached Client

These two gems are actually mainly written by one same author Mike Perham. He mentioned that Dalli is a high performance pure Ruby client for accessing memcached servers. It works with memcached 1.4+ only as it uses the newer binary protocol. It should be considered a replacement for the memcache-client gem. The API tries to be mostly compatible with memcache-client with the goal being to make it a drop-in replacement for Rails.

» Deployment and Monitoring

I am not a system administrator, so I can't speak with any authority on this. That said, I do find these three gems come in handy with deployments and monitoring.

» Cron job and Backup as a Pro

These two gems are my favorites! Before I knew about these, I had to write complex and stupid scripts to do backups that I was not familiar with. Cron job is also a pain if you are not a system administrator. Now time changes and you, as a Ruby programmer, can do the cron job and backup in the Ruby way, surely as a PRO. :)

» Testing Gracefully

Testing is always important, and with the popularity of testing practices like TDD and BDD you have to own your super gun to play. These gems can help you out, although I didn't cover all the different levels of testing with these gems. But I will say, rspec is my favorite framework for testing, and factory_girl and faker are good supports. Anyway, test by your own way.

» Toolkit

There are many handy gems which will give you convenience and power. Take the above four as examples: "Ruby-Debug" lets you easily check your running application's context at specific program points; "Hirb" displays your AR items conveniently in a table view in console; "Cheat" brings tons of other gems' manuals into your terminal window for easy reference and; "Rails-Settings-Cached" is for global configurations in Rails 3 applications. Yeah, throwing the brick out is to meet your GEMS.

How to find great gems?

First, you need to follow Ryan's railscasts; he is good at introducing new stuff via video. Second, you can go through the GemFile of a great open source project that you love - this is definitely the best way to come across valuable gems. Third, just subscribe to github ruby trends to know what's going on in Ruby/Rails community. There are also some other good sites, like rubygems and railsplugins, where you can find useful gems with some poking around.

I originally shared this topic with all of the Intridea East Team members during our weekly Friday Tea-hour. You can find the PPT here. I wanted to share the list with more people, so I turned to our blog for that purpose. I'm sure I missed many valuable gems, so please share your thoughts in the comments!

Categories
Author

It's been in beta since the beginning of this year, but today it's official - we're releasing the Presently Chrome Extension as a full-fledged Presently client. We released the first version in January, and since then our developers have been adding functionality and making tweaks to bring full functionality to the extension - so Presently users can enjoy a seamless integration of their corporate collaboration app within their Chrome browser. Now you can do almost everything you do on the native web app! In this version 0.1 you can:

  • Receive and post status updates instantly
  • Like/Unlike updates
  • Attach text
  • URL Shortening
  • Desktop Notifications
  • View older updates with continuous scrolling
  • Keyboard Shortcuts for added usability (Press shift+'?' to get the whole list)

Download the extension now and see how easy it is to collaborate, communicate and stay connected in real-time with Presently Chrome, our newest addition to the family of Presently apps.

If you ever need to recover the Chrome extension (if it freezes upon coming back from a lost network connection, for example), follow these instructions:

  • Right click the Presently icon in Chrome
  • Click "Manage Extensions"
  • Find Presently
  • Click Disable and then Enable

presently-logo

What is Presently?

New to Presently? That's ok - there's a first time for everything. The Chrome Extension is just one of the many clients we have available for Presently. Presently is an award-winning "Twitter for the Enterprise" tool, designed to make internal collaboration, file-sharing, and communication easier for businesses. Fortune 500 companies, small dev shops and companies every size in between have been using Presently since 2008 for internal communication and collaboration!

We've got a free SaaS version to get you up and running painlessly and a super-secure and robust Behind-the-Firewall version for companies that need that added level of security. Signup for Presently today and you'll find an array of tools available to you that help you stay connected with your company and co-workers, including clients for the iPhone, Blackberry, Android, the web, Microsoft desktop, Mac OS and more. Use the links below to get started, or to contact us for a demo!

Categories
Author

It’s been nearly a year since the release of the iPhone 4, and much to the dismay of the tech community, it’s still the only product in the Apple lineup with a high pixel density ‘Retina’ display. While the much-hyped feature drew universal praise when the device was unveiled, some were wondering the following:

  • Would consumers see this as a compelling feature?
  • Would competitors follow suit, establishing critical mass for high PPI displays?
  • Would Apple eventually launch a Retina display for iPad or Macbook Air? Or would another manufacturer release an ultra-high resolution tablet or laptop?

In a little over 10 months time, high PPI displays are currently everywhere in mobile. Walk into any carrier retail store, and chances are that the featured smartphones already feature high-resolution displays. Those that don’t have them likely will within an iteration or two.

Retina display for Mac will be here sooner rather than later. Apple’s yet-to-be-launched OS X Lion includes built-in support for the Retina display, along with ultra high-res desktop wallpapers and icons. It’s a decent bet that we’ll eventually see some variation of the Retina display across the entire product line. And of course, as happened in mobile, the rest of the industry will follow Apple’s lead, effectively eliminating the concept of a default dpi standard.

How can designers and developers prep for this change?

Embrace resolution-independent design practices for the web, not just mobile. Up until this point, designers and developers who haven’t worked in mobile have been able to avoid the extra hassle of prepping content for high PPI displays. But with the classic notion of the ‘pixel’ fading away, it’s a good time to reiterate the importance of resolution-independent design practices across the board. Specifically:

  • Minimal use of bitmaps (reserved for photography, video, and illustrations)
  • CSS3 for buttons, gradients, shadows, and lines
  • HTML5 canvas and SVG libraries for complex and interactive graphics
  • @font-face for custom type
  • Vector graphics for interface elements

Start to use Scalable Vector Graphics (SVG) on the web. With Internet Explorer 9 finally getting onboard with the basic SVG feature set, it’s time to adopt vector graphics on the web (for real this time). Unless you are designing for a specific audience using certain browsers (in which case you may need fallbacks), now is a great time to consider using SVG for:

  • Icons
  • Background images
  • Custom type treatments
  • Logos and mastheads

Get comfortable with Adobe Illustrator. This advice was doled out around the web when the Retina display was first introduced, and one year later it rings more true than ever. Photoshop is still the industry standard for producing web graphics, but as the web steers towards resolution independence, so should the toolkit.

Photoshop users: keep all of your source files in vector format for as long as you possibly can. If you must use Photoshop (full disclosure, we love it and use it daily at Intridea), it’s a good idea to create your interface elements as vector Smart Objects, or import them directly from Illustrator. This way, your elements can scale when you resize the source files without effectively losing resolution.

For time being

The current process of designing for high PPI displays is a bit of a hassle, but it’s hopefully transitional. Designing for the Retina display with targeted CSS and high-res bitmaps is already intensive. Throw in the eventual release of high PPI displays on tablets and laptops and it’ll be painstaking.

There are a number of established design practices for supporting high PPI displays. Many of the tutorial articles written soon after the iPhone 4’s launch are still relevant (here’s a great list of some key takeways).

Categories
Author

Emacs vs Vim. iPhone vs Android. Of all of the nerd arguments, none hits closer to home for Ruby developers than HAML vs ERB. Proponents of HAML look at writing HTML as a dirty practice to be avoided at all costs and look down upon "mere" ERB authors. Meanwhile there's SASS, a language syntactically close kin to HAML and, until last week, one that even rode along inside the HAML gem. HAML abstracts HTML, SASS abstracts CSS. I'm not here to stop you from using HAML if you like it. Go for it. However, I'm tired of having an aesthetic choice that some developers make bandied about as if it were "the only way" to do things.

The Difference Between HAML and SASS

HAML is an abstraction of HTML that allows for terse description of HTML elements in a meaningful-whitespace format. Rather than writing:

<div id="profile">   <div class="left column">     <div id="date"><%= print_date %></div>     <div id="address"><%= current_user.address %></div>   </div>   <div class="right column">     <div id="email"><%= current_user.email %></div>     <div id="bio"><%= current_user.bio %></div>   </div> </div>

You can instead write:

#profile   .left.column     #date= print_date     #address= current_user.address   .right.column     #email= current_user.email     #bio= current_user.bio

SASS, similarly, is an abstraction of CSS that allows for terse description by allowing for nesting and other conveniences. SASS also includes an SCSS format that looks nearly identical to CSS. For SASS, you go from this:

table.hl {   margin: 2em 0; } table.hl td.ln {   text-align: right; }  li {   font-family: serif;   font-weight: bold;   font-size: 1.2em; }

To this:

table.hl   margin: 2em 0   td.ln     text-align: right  li   font:     family: serif     weight: bold     size: 1.2em

OK, so that's HAML and SASS. They both accomplish roughly the same thing, right? Not so much. Here are some of the differences between HAML and SASS:

SASS looks a LOT like CSS. CSS is a series of rule declarations that already follows a relatively terse format. SASS simply adds on the notion of meaningful whitespace and nesting of rules to prevent repetition.

HAML is an abstraction, SASS is an improvement. While HAML and CoffeeScript could be (in my opinion) successfully compared (each provides a syntax that some find more pleasant for writing a certain type of textual content), SASS does something that neither HAML nor CoffeeScript can: it provides functionality that is impossible to achieve in the target compiled language. There's no such thing as a variable, mixin, or function in CSS. SASS provides a thin layer on top of CSS that adds immense power that wasn't there before. Personally, I like CoffeeScript, but I also don't mind writing plain Javascript. I doubt I'll ever again work on a web project where I don't use SASS, because it is simply too useful to ever be without.

Learnability. If I sat down with a designer who was familiar with CSS, I could teach them SASS in less than an hour. Despite trying a couple times at various points, I still have to constantly defer to the reference when I'm writing HAML. I'm not saying that HAML doesn't help some people write HTML templates more efficiently, I'm saying that writing your project in HAML simply guarantees a relatively long and obnoxious learning process for every person who needs to work in the views. Maybe you have a small, fixed team that makes that a possibility, but in many (if not most) real-world scenarios wasting time to teach a templating language that is simply a convenient abstraction is not going to be worth it.

Breadth and Scope. HAML works essentially as a subset of the things you can do in ERB. There are some things that HAML simply won't do (some of these encourage good programming practices, but the statement is true nonetheless). SASS is a superset of CSS; you can do everything you can do in CSS and significantly more. This difference means that SASS will never tie your hands for styling a site but HAML may tie your hands to a specific means of execution in some scenarios. Again, not to say this is always a bad thing, but it's a true thing.

Freedom of Choice

I don't really care if you want to use HAML. I actually can understand how, for developers who don't like writing HTML and CSS (I work on both sides of the development/design fence) it may feel more productive to be able to write things that way. So go for it, use HAML. Just don't tell me that my choice is inferior. We're talking aesthetics here, there is no right and wrong.

There are other ways to accomplish the same terseness that HAML provides while generating pure HTML templates, things like Zen Coding or even just judicious use of some more advanced features of your editor of choice.

TL;DR. SASS and HAML solve two completely different problems. Liking SASS doesn't imply wrongness in disliking HAML. Using HAML is fine if that's your bag, but don't act like it's the only way. It's just an aesthetic choice.

Categories
Author

No matter what level of developer you are, at some point you will have the underrated joy of inheriting a legacy software project. And since we're fortunate enough to work in such a fast-paced community and ecosystem, "legacy" really encapsulates any piece of software more than a month or two old. Often though, we don't have time to appreciate how our ancestors used to write Ruby back in the days of Rails 2.3, or even (gasp) 2.1 — we need to get right to work. It's at this point that the nefarious Jabberwocky method can rear its ugly head.

The Jabberwock in the Room

When we first adopt a project, some of the language may seem like gibberish. Let's say we encounter this snippet of code in some controller:

@sword = VorpalSword.new @sword.snicker_snack!

Looking at this code, we might expect to open up the VorpalSword model and find:

def snicker_snack!    Jabberwock.destroy_all end

Unfortunately, in this all-too-contrived example, the VorpalSword class simply doesn't have that method!

The Jaws That Bite, the Claws That Catch!

Stuff and nonsense! Now we'll have to dig through and see if we can find a way to uncover this method. Let's start doing some sleuthing...

  • Maybe there's a method_missing in the VorpalSword class

  • Does VorpalSword inherit from anything?

  • Hmm...does it include or extend any modules?

  • It's probably just a plugin. Let's check the vendor/ folder...

  • Okay, maybe not. How about something under the lib/ folder...

  • Is "snicker_snack!" a gem?? Who would name a gem "snicker_snack!"

  • Did someone overwrite method_missing in ActiveRecord::Base?!

  • That's it, I'm switching to Scala!

Final Uffish Thoughts

Abstraction is a fantastic technique - we love to keep our software DRY and happy, but occasionally it can lead to code obfuscation. So before you go galumphing back to your project, take a few minutes and follow these suggestions to keep your code readable, and avoid those Jabberwocky methods:

  • Using modules is a self-documenting way to extend the functionality of your classes. If you do decide to use a shared library to cover some functionality, try to use modules rather than re-opening classes.

  • Be very careful when you use metaprogramming techniques like method_missing, or dynamic code creation. Writing a lot of crafty methods using a few lines of Ruby can be lots of fun, but sometimes a little bit of duplication can improve the readability of your code tenfold.

  • Lastly, documentation and tidy code is important. Try to organize your methods, and definitely drop a comment into the class if you know a shared library will be mutating it down the road.

Be sure to keep these tips in mind, and you'll find whoever inherits the code after you will chortle in his joy.

Categories
Author

This post is part of a series called Open Source Citizenry in which I discuss ways to eliminate the barriers that developers and companies face to participating in the open source community.

Last week at Red Dirt Ruby Conf, a tweet came through my stream that seemed to fit quite well with what I was already thinking about for my Open Source Citizenry post this week:

.bbpBox61459124273168384 {background:url(http://a2.twimg.com/a/1303316982/images/themes/theme3/bg.gif) #EDECE9;padding:20px;} p.bbpTweet{background:#fff;padding:10px 12px 10px 12px;margin:0;min-height:48px;color:#000;font-size:18px !important;line-height:22px;-moz-border-radius:5px;-webkit-border-radius:5px} p.bbpTweet span.metadata{display:block;width:100%;clear:both;margin-top:8px;padding-top:12px;height:40px;border-top:1px solid #fff;border-top:1px solid #e6e6e6} p.bbpTweet span.metadata span.author{line-height:19px} p.bbpTweet span.metadata span.author img{float:left;margin:0 7px 0 0px;width:38px;height:38px} p.bbpTweet a:hover{text-decoration:underline}p.bbpTweet span.timestamp{font-size:12px;display:block}

There are still too many developers who work with Open Source and not enough Open Source developers.less than a minute ago via Echofon Favorite Retweet Reply Mike Perham
mperham

In last week's post I tried to give some insight as to why open source is important for companies. This week, I'll be looking at the other end of the spectrum: why should you, as a developer, actively contribute to open source? For some, the answer to this question feels natural; however, for many developers the idea of contributing to open source can be daunting, confusing, and somewhat frightening.

It Will Help You Land Your Next Job

Are you unsatisfied with your current job? If you are, it's a great reason to start contributing to open source. If you're stuck using a language or framework that you don't enjoy, or a development practice that you don't believe in, it's practically imperative that you begin contributing to open source. Why, you ask?

Because the person that is in charge of hiring at the kind of company you really want to work at is going to be looking at an applicant's open source contributions as a way to gauge talent. The more (good) open source you release, the closer you will be to getting your dream job before you've even had an interview.

Open source contributions are a fantastic way to evaluate incoming employees. The very first thing I do when I'm evaluating a potential hire at Intridea is look them up on GitHub. That's not to say that we don't hire people who haven't done much in the way of open source contribution (there's more to the hiring process than a single factor). However, I can say that I am going to be much more adamant in my arguments to hire a person if I can see the way their mind works from the open source projects they've released.

You Will Write Better Code

Open source is open to the entire world. Everyone can see what you're writing. If you think this doesn't have an effect on your willingness to take hacky shortcuts, you're very wrong. Not only does the mere fact that it's open source make you write your best code, but open source also helps you to think about your problem domain from a wider perspective.

As I released more and more open source projects, I began to have a kind of Spidey Sense for when something would make a good abstraction. When I'm architecting a project I'm already thinking about how certain pieces could be built in a modular way to maximize reusability. Even if these pieces don't end up getting released as open source they are still useful extractions that get used in other projects down the road. The concept of building code for a community instead of just for an application makes the work more enjoyable.

Reputation is Real

For a software developer there are essentially two paths to extremely enviable positions of respect in the community: either you can be the tech genius behind a multi-billion dollar startup or you can release open source projects that thousands (not millions) of developers find useful. Guess which one is easier to accomplish?

Reputation isn't just about vanity, either. Sure, it can feel good to have someone say "Oh cool, I've used X!" when they meet you, but building a reputation brings real benefits for you:

  1. If you love your company, your company is automatically more respected because you're a part of it if you have a good reputation.
  2. You'll get the chance to meet, talk to, and learn from the people that you respect. Not that these people are otherwise inaccessible, but having your own "known" libraries gives you some common ground to strike up conversations, get input, and become a better developer.
  3. It will get you hired at awesome places. See above.
  4. You will get help when you want it. If you have a good reputation and embark on a new project you'll be able to round up volunteers more quickly if you're a known entity.

It can occasionally feel shallow or awkward (at least to me) to be thinking about and concentrating on my reputation in the community. However, look at it another way: open source reputation is built on real, honest-to-goodness work that is making people's lives easier. And if you start releasing bad code, guess how long that reputation will stick around? Reputation is simply a measure of the respect that others have for you based on the merits of your code. And that's not a bad thing.

That Warm Fuzzy Feeling

It just plain feels good to contribute to open source. The rush you get the first time (as an example) your patch is accepted into a major open source project is exciting. Seeing people using and talking about a library that you wrote is awesome. Hearing that some company that you really admire is using one of your libraries internally is amazing.

Open source feels good because it is good. You are offering value to a community of people free of charge, and in return you get to feel good about yourself and enjoy what you're doing. Don't be afraid to pat yourself on the back (maybe not too hard) for getting code out there. It's more than most people do, and even if only ten developers ever find it useful, that's ten people that saved hours or days of work because of something you did. And that's a warm fuzzy feeling.

Standing on the Shoulders of 1,000,000 Dwarves

Open source is amazing because it doesn't rely on the herculean efforts of a single person or even a few people. Open source is about thousands of people contributing tiny useful things that thousands of other people can build upon. It's not about building the biggest boat, it's about making the entire ocean rise. Each and every person who contributes to open source is making a difference to the ecosystem as a whole, and the more people that get involved the better the whole system works together. There can never be too many open source developers.

Barriers to Contribution

I think it's relatively clear to most developers why open source contribution is a good thing. Additionally, I think there is something intrinsic to the developer's mindset that drives us to crave the scrutiny and the ups and downs of publicly available code. So why doesn't everyone write lots of open source? Here are a few reasons with my responses:

  1. I'm not good enough to release open source. Poppycock! My first open source release was literally forking another project and hacking at it until it did something I wanted it to do that it didn't do before. I had no idea what I was doing. I still don't, most of the time, and I've released dozens of open source projects.
  2. People will think I suck because my code sucks. Nope, people will ignore your project if your code sucks. That's the worst case scenario. And, to be honest, if you're solving a problem that other people haven't solved, they'll probably use your code even if it sucks. And then they'll patch it so it doesn't suck anymore. Wins all around.
  3. How do I even do it? It seems complicated. It's not, especially in the GitHub era. If you want to know how to do something, find a project that does something similar and steal their execution. Just steal and steal from everyone until you understand it well enough to forge your own path.
  4. I don't have enough time! Find a way to make time! Identify a piece of your existing app code that other people would find useful and extract it out. This cuts your open source time down to abstraction instead of creation. Work on open source for half an hour a day. Convince your company to sponsor some open source time for employees. Contribute small patches to the libraries that you use on a regular basis. Where there's a will, there's a way.

I could go into detail and examples on each of these points (please feel free to ask me sometime), but the point is that whatever you think is holding you back from contributing to open source, the reality is much less frightening. Your first project will be the hardest to get out the door, but it gets exponentially easier each time after that.

In coming articles in the series, I'll talk specifically about how to be a good open source user, how to be a good contributor, and how to be a good project owner. But if you only needed a tiny push to start getting involved, hopefully I was able to supply it. Please feel free to discuss anything related to open source contribution in the comments, I'd be happy to lend what knowledge I have to the service of getting everyone more involved!

Open Source Citizenry Series

  1. Why Open Source Company Culture is Important
  2. Why You Should Be An Open Source Developer
Categories
Author

Today I'm introducing GemNotifier.org, a web app I built to deliver timely notifications about your favorite gem updates. It's a SparkTime project at Intridea and it's something I've been working on for the last month.

Why Build GemNotifier?

Simple, really; because there is a demand for it. Both for myself, and for other devs:

What Does it Do?

It's a very simple and useful concept. Rubyists can subscribe to their favorite gems and they will get email notifications when those gems are updated.

Get Started

Start using GemNotifier today. The setup process is straightforward:

  • Sign in with Github Oauth
  • Search for your favorite gems and click subscribe. You'll be notified when things change!

SparkTime

You'll be hearing a lot more about SparkTime on our blog in the coming months, so I'll give you the rundown now! SparkTime is a new initiative at Intridea designed to get us working passionately on side projects that we might not get the chance to do otherwise. Although many of us already make time to contribute to open source, work on side projects, or improve existing code bases, we realized that our talent could be better utilized if we got organized. From this, SparkTime was born. Every Intridean signs up for a project they feel passionate about, using SparkBin to keep track of our ideas. We use Presently to talk about our projects and as a means of collaboration among SparkTime teammates. There are a lot of interesting projects going on and we look forward to sharing more of them with you soon! Follow us on Twitter to get updates about our progress.

We're Doing Fun Stuff

We work hard at Intridea - but we love what we do and we have a lot of fun doing it. If you're interested in being a part of our great team check out our openings; we're a growing company of diverse, talented and energetic engineers, designers and entrepreneurs. We offer compelling benefits and a unique culture that values the individual contributions that make Intridea such a great place to work.

Categories
Author

Here at Presently we understand that the key to staying connected is mobility so we've been working hard to improve our applications for all of our mobile platforms! In last week's announcement on the new Presently Desktop app, we promised you an update for Presently Android, and we're here to make good on that promise! Starting today you can uninstall the old version and visit the Android App Marketplace to download the new version of Presently.

Improvements

We've made several critical improvements from the previous version, including:

account-settings.png

Preferences.png

Preview

Work Continues

We hope that the new Presently Android app helps you stay connected to your network no matter where you are, and we're confident you'll be happy with the update! Our developers have been busy this year and we're not slowing down. An update to our Blackberry application is on the way, and our iPhone app was updated last week, so be sure to tell your coworkers to grab whichever application suits them! As always, if you have any feedback about the app, or need any help please don't hesitate to shoot an email to support@presently.com or visit and search our knowledgebase for more answers.

What is Presently?

Presently is the perfect microblogging solution for businesses. Communicate and collaborate in real-time, in a secure Twitter-like environment built for the enterprise. If you're not using Presently yet, let me give you a few reasons to check it out:

  • Empower your employees - increase productivity and creativity through collaboration via Presently.
  • Enable your employees to easily share files and media.
  • Easy solution for groups or departments to collaborate on projects.
  • Track ongoing conversations with threaded view and inline reply options.
  • Past information is available in an instant through Presently's search tool.
  • Our Desktop, Mobile, and Web applications give you the flexibility you need to access Presently anytime, anywhere.

So try it out today and see what the power of real-time collaboration and communication can do for your company. You'll wonder how you ever lived without it!

Categories
Author

This post is part of a series called Open Source Citizenry discussing ways to eliminate barriers developers and companies face to participating in the open source community.

Earlier this month I had the opportunity to speak at KCRuby about a topic of my choosing. Rather than use the opportunity to put together a trial run of my upcoming Red Dirt Ruby talk, I decided at the last minute to talk about something that's been on my mind for a long time. While open source participation is higher than it's likely ever been, I still see so many people too hesitant, confused, or intimidated to enter the open source community and start releasing. So I wanted to give a cheerleader talk about how everyone can and should be contributing to open source. You can see the showoff slides here, but I think the issue is important enough to merit a larger discourse. This is the first post in a series in which I will be writing about how and why every developer should participate in the open source community. First up, I aim to supply developers everywhere with some ammunition to bring open source culture to their company.

Why Open Source Company Culture is Important

Companies have many ways to benefit from an open source culture. While many arguments can be made about the philosophical implications of choosing to contribute to the open source community, at the end of the day philosophy isn't going to persuade any CEO to adopt open source. The real reason that open source culture is important to a business is because it's a business decision that can bring many real-world advantages over the proprietary-focused alternatives.

Defining Open Source Culture

There are many degrees of "openness" in a company's culture, just as there is a whole spectrum of licensing that is considered "open source" but can have vastly different ramifications for downstream users. Personally, I believe that many companies would benefit from embracing open source as a core aspect of their corporate identity. To me, fully embracing open source means changing the default. Rather than building things and thinking "Should we open source it?" the assumption should be that yes, we will open source it unless there are compelling reasons to avoid doing so.

This is a big leap for a company to take, and I don't think many are there. We recently acquired RefactorMyCode, and rather than simply taking it over and continuing with it as a product we decided to additionally open source it. There aren't a ton of reasons why open sourcing would necessarily be a huge win for Intridea, but there are even fewer reasons why it wouldn't be a good idea. It's a community-oriented project, it doesn't contain any kind of magic voodoo patentable algorithm, and we can give the public the chance to refactor RefactorMyCode.

It Leads to Better Code

You may run a tight ship when it comes to code quality and you may even have excellent processes in place to ensure that the code that you deliver is well-tested and sanity-checked before it ever reaches production. However, there is simply no review process that can compare to the power of opening up source code to the world at large and letting them take a look. The code quality bump is due to two primary reasons:

  1. Developers building things for open source know that anyone in the world can look at the code they're writing. It will make them less likely to take easy shortcuts at the expense of good code.
  2. Other people will start using your code way off the golden path you imagined when you designed it. This will cause your architecture to evolve to be more flexible, useful, and hardened.

I know that in many cases I've had to rewrite large sections of a project because the community use cases have revealed a superior architecture that will encompass a broad range of functionality. I then benefit from this architecture when I need a similar solution in the next project I'm working on for my company.

You Get Work For Free

This is probably the most commonly cited advantage of open source: once you build a community, the community gives you free bug fixes and feature updates without you having to code a single line! This is a real advantage, especially when there is a wide-open field for community addition (such as adding new strategies to my OmniAuth library).

Of course, you need to have a workable community involvement process before you can really reap the benefits of contribution. Thanks largely to GitHub, this process has never been easier, but there are still some things to keep in mind that I'll cover in a later post.

Your Developers Will Be Happier

There's a real sense of accomplishment that comes from releasing and contributing to open source. It makes your developers feel like they're giving back, becoming a real member of the development community, and investing themselves more in the craft of software development. The same can be said of encouraging developers to attend local meetups relevant to the field and conferences.

Why do you care about happier developers? Well, every company should care about happy employees, but software development is a black magic mix of science, artistry, and craftsmanship. While some work can be done by "forcing it", a good deal of that work requires inspiration and passion, something you won't be getting out of developers that feel stifled and isolated from the development community at large.

You Will Attract Better Talent

If your company becomes known as one that embraces open source and community involvement, you will begin to attract better talent when it comes time to hire. Sure, having a killer product, good benefits, competitive pay, and many more things affect this strongly as well. But the chance to be involved in open source without having to do so by moonlighting is a chance that is very attractive to the kinds of developers you want to have working at your company.

Open source is synonymous with credibility for many developers. The more well known your company is for having great open source, the higher you rank amongst the development community. It really is that simple.

You Will Gain General Technical Credibility

This may be more applicable to service-oriented companies that do consulting, but in some cases your portfolio of open source projects can be the validation your company needs to win a bid for a client. Intridea has won clients before when they check with their technical expert and he or she confirms "hey, I've heard of that company, they released X".

All of these reasons come about because contributing to and participating in the open source community changes the perception of your company for developers, customers, and other businesses alike. While a company that rabidly protects every scrap of its software might be seen as greedy or, well, basically "jerks", companies that embrace open source foster a general sense of well-being about them that is difficult to define but something that I've definitely experienced personally.

The Flip Side: Addressing Arguments for Proprietary Software

So if, as a developer, you've just made your pitch to the higher-ups to embrace open source, you might receive any of these as (valid, by the way) concerns about being more "open" as a company.

  1. But we're a software company, aren't we giving away our most valuable assets? Nope. Well, maybe if you have a completely novel complex algorithm that solves a problem in a game-changing way, but the truth is that most software isn't some "secret sauce" that can't be duplicated by competitors. On the contrary, even with high-level tools and environments at the end of the day a good deal of software development is re-inventing the wheel. The more everyone is involved in open source, the fewer wheels have to be re-invented.
  2. We're on a deadline, we don't have time for open source. This can be one of the biggest challenges to overcome. I'm not going to lie, supporting open source projects does take time and effort. However, think of it as a tradeoff: by putting in some time and some effort to maintain an open source project, you are gaining all of the free hours of community contribution.
  3. What if people look at the code and think it's awful? Well, then you're learning a valuable lesson about the code quality you're producing and you'll probably be able to identify ways to improve it. Open source projects without tests, with brittle "golden-path" architectures, and even well-intentioned projects that are simply tackling a tough domain are probably going to get some flak. But being wrong isn't nearly as damaging to your company as being ignorant of the practices that you should be using every day.

This post (and this blog series) is more about starting a discussion than providing definitive answers. I'm not saying I know exactly what your company's needs are, but I do believe that embracing open source will do more good than harm. If you have any questions, comments, or rotten produce to throw, feel free to start some discussion below. Stay tuned for the next post in the series where I'll be talking about the benefits to individuals in contributing to open source. And if you're interested in checking out some of the open source work that Intridea has done, hit our Github page.

  1. Why Open Source Company Culture is Important
  2. Why You Should Be An Open Source Developer
Categories
Author

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.

Categories
Author
« First ‹ Previous 65 66 67 68 69 70 71 72 73 Next › Last »
Subscribe to