Rails Tools: Paperclip and Cloudinary, brought together

Need a low-cost viable solution for storing and serving image file attachments in your Rails application? Read on...

For a number of implementations, I have used thoughtbot's Paperclip gem to manage my Rails models' file attachments. It provides sizing and scaling via Imagemagick and is simple to get up and running quickly. For file storage, I found the paperclip-dropbox gem as an excellent way to hook up a free Dropbox account to store and manage a few files.

Unfortunately, not only is that gem no longer activity maintained (with ominous warnings across the homepage now), but this solution also doesn't work quite so well for images; particularly, serving images to display online. And the jump in price point from Dropbox to AWS or similar wasn't really something I wanted to take on. So, I needed something cost-effective that was good at serving images. For that purpose, I ran across Cloudinary.

Cloudinary is an image and video cloud-based management solution which is very fast, easy to manage, and has a usable free tier. It also has some awesome directives that can be used for on-the-fly image transformation in just about any way you can imagine, such as sizing, scaling, coloring, overlaying, and much more. Not only that, but Cloudinary is also Rails-friendly, coming with a Rails gem as well as a direct integration to CarrierWave, which is essentially an alternative to Paperclip.

Using Cloudinary and CarrierWave together is a great solution for many, and for those happy to do that, Cloudinary provides detailed instructions on getting integrated. However, for me, migrating from my Paperclip/Dropbox solution to CarrierWave/Cloudinary was a task I wasn't too keen on performing. So, I decided to build the missing link, bringing together Paperclip and Cloudinary.

The paperclip-cloudinary gem adds "cloudinary" as a new storage option for Paperclip, and dropping that in as the storage option along with the downloadable configuration file from a Cloudinary account will have your images stored in Cloudinary in minutes. From there, you can use Cloudinary's cool features to further manipulate your images in views. Or not, it's up to you from there.

Bottom line, if you're sticking with Paperclip, but want a better free-to-low-cost alternative to Dropbox for serving images, try paperclip-cloudinary.

--
Carl Scott
Software Developer, Solertium Corporation

How I Log My Time In My Sleep

Photograph by: apops, Fotolia.com

Every day last week, I woke up to see that my development time had been logged.

But I haven't logged in to FreshBooks since 2015.

Like many other development teams, our company uses FreshBooks to track our time and invoice clients.  It's a great tool with all the features we need for day-to-day operations. However, as a programmer, over the years I have failed to use this tool properly, and neglected my time logging duties until it was absolutely necessary. This neglect often required "time logging parties" with other members of my team who had been equally neglectful, which was a kind misnomer for stressful sessions of reading through e-mails, project management tools, git logs, hand-written notes, and anything else to help us remember just how much time we spent working on something.

And, like many other development teams, I work on multiple projects per day -- sometimes per hour!

For me, the most frustrating thing about logging time is essentially having to record my operations so many times. First, when I tell a client what I'm going to do. Again when I code the thing I was supposed to do. Then, I write fairly detailed commit messages describing what I did. Finally, I communicate with the client that the thing was done. And now I have to write all this again in an time tracking tool?! Ugh.

It doesn't often get done. And when it does, it isn't efficient. Time should be logged in-process.

I've tried stopwatch solutions, but they simply don't work when you forget to hit the button. And I'm too busy (forgetful) to hit the button. Or, I get distracted with something else going on, or a client calls, or I need to task switch immediately, etc. etc.

Why can't I just code and have my time tracked as I code?

Well, now I can, thanks to WakaTime.

WakaTime advertises itself as FitBit for programmers, and that's a pretty spot-on description. In the same way that FitBit tracks your statistics just by you doing your everyday tasks, WakaTime tracks your time spent in your IDE of choice (Vim, Eclipse, Android Studio, and many more) and automatically uploads that information to the web. At the end of the day, just by coding, you've got a picture of everything you've worked on for the day. For free.

"Yes!"

To complete the puzzle, though, I needed to get the time out of WakaTime and in to FreshBooks. There wasn't anything out there that did that for me, so I created it:

https://github.com/GoGoCarl/WakaTimeFreshBooks

WakaTimeFreshBooks is a Java command-line client that pulls the time logged for a given day in WakaTime and pushes that information as time entries into FreshBooks. After a couple minutes of setting up my API keys and matching up the WakaTime projects I wanted to log with FreshBooks projects I wanted to send the time to, I was up and running. Simple, yet effective.

On December 28, 2015, I set this to run as a daily cron job, and I haven't logged time since.

Now eventually, I'll have to edit my time sheets to include useful notes for invoices. And I still need to log out-of-band communications, as well as testing and video conferences (although, WakaTime is working on solutions for those things!). But, for now, I know that my coding time has been submitted, and that it's fairly accurate, which is much more than I could say merely a few weeks ago.

And I didn't have to do anything but code.

--
Carl Scott
Software Developer, Solertium Corporation

Code, Push, Deploy with JitPack

Recently, I released a Java connector for Appygram, available on GitHub in ready-to-use JAR format.  A useful library, for sure, but one glaring omission was the fact that it wasn't available via the popular means of Gradle or Maven.  That, for many, makes it not-so-useful.  Since, for now, I'm the only one working on this connector, having a publishing process that is fast and easy for me is important.

Enter JitPack.

JitPack (currently in Beta) is a package repository for GitHub that builds your GitHub projects on demand and publishes them, ready to download and use via the aforementioned popular means.

For me, this meant adding a pom.xml build file to my project, tagging my latest release, and pushing to GitHub.  Done.  Once I'm finished with my next round of coding and updates, I can do:

git commit
git push
git tag -a 1.0.3 -m "1.0.3"
git push origin 1.0.3

And now, my code is available to the JitPack package repository for everyone to use immediately.

If you're a developer looking for a fast and easy way to get your code available, try JitPack.  It's an interesting approach to skipping the build process and getting code assets available in a way that's easy for users, while being convenient to developers.  Tools like that are definitely gold!

--
Carl Scott
Software Developer, Solertium Corporation

Give Your App A Voice With Appygram4J

Communication is key in any relationship, and if you're a software developer, that includes the relationship between you, your customer, and your software.  What are your users saying about your app and their experience? What statistics can you collect from your app to provide a better experience?  And, most importantly, how can you ensure that the right people are getting the necessary information to help?

Enter Appygram.

Appygram, simply put, is a message routing service that directs all types of communication from your application or service to the right people and/or places.  Appygram allows you to manage this routing through a web interface, so you can make changes on the fly without requiring end-user updates.  The types of communication captured are entirely up to the developer, so anything from feedback messages, user polls, questionnaires, application exceptions, notifications, and all in between can be captured and routed using Appygram.

If you're a Java or Android developer and eager to integrate this service in your software, I have released a connector library, Appygram4J 1.0, available on Github.  To start, this library provides objects and simple calls you can use to send messages from your software to Appygram, and all you need to begin is an Appygram API key.

If you haven't already, you can start using Appygram today with prices starting from free at http://appygram.com, then you can grab Appygram4J here:

https://github.com/GoGoCarl/appygram4j/releases/tag/v1.0.1

If you're using other languages, such as Ruby or Node, you can also grab those connector libraries for Appygram as well.

Here's to better communication!  Have you tried Appygram or Appygram4J already?  What do you use it for?  Feel free to comment below with questions, comments, or suggestions.

--
Carl Scott
Software Developer, Solertium Corporation

Truly Rapid Development

Ran across an old, but interesting article on how to save time and costs on developing software. Found it pretty interesting:

http://blog.assembla.com/assemblablog/tabid/12618/bid/9148/Stick-your-con-call-up-your-estimate-6-things-you-can-skip-to-save-time-in-a-software-project.aspx

The interesting point here was the recommendation to skip estimates. I've never dealt with a customer who didn't want, or demand, time estimates on everything, but I agree with this article's assessment -- at the end of the day, the customer is either going to pay for the work, or not pay for it.

To-the-hour estimates, I agree, are painstaking and probably a waste of time, considering that more than likely, the estimate will be inaccurate anyway, or something may happen during the course of the project (change order?) that makes that original estimate wrong. However, in order to plan a project and create proper milestones and deliverables, there has to be some sort of estimate of time it will take to complete a task. Maybe weeks, not hours, would be better suited here.

Just thinking out-loud here, but wanted to share the article. Hope someone finds it as useful as I did.

--
Carl Scott
Software Developer, Solertium Corporation

Yay or Nay: URL Shortening

Coincidence or not, it seems in this new and brave Twitter-powered world (which deserves its own yay or nay blog but I'll save it for later), the prevalence of minimalist ... well, everything, have become popular. Half-size soda cans and water bottles, miniature laptops, and these tinyurl, bit.ly (and ju.mp) URLs. Of course, the question is...

Yay or nay?

You may have already sniffed out which way I'm leaning, but I'll start with an objective look at the positives. A number of services (including Google Groups) don't take too kindly to very long URLs. With websites becoming more powerful by the day with amazing technologies backing them, more and more information is being handled by web services, and ultimately passed via URL. Additionally, shorter URLs are "cute" and they can also be more easily read aloud. Finally, some of the more advanced shortening services offer cool tracking features, which are nice when you are into those sort of stats.

So, negatives. Aside from the fact that the last time I typed in a URL or read a URL to someone to type in was April 1997 (as an April Fool's joke), I find myself incredibly suspicious and uncomfortable with clicking a link with an obfuscated mystery destination. And unfortunately (or fortunately, depending how you look at it), I (like so many others) am not on a Mac, so viruses are a concern. To me, URL shortening is essentially a rod and bait for phishing techniques. Yahoo and Myspace apparently agree, as they have banned URL shortening from some of their services.

So, the verdict...

Despite the features and "cute" factor that URL shortening provide, they also open doors to spam, phishing, and other dimly lit alleys that I don't want to venture down. Outside of services like Twitter that just don't allow enough characters to have a full URL and descriptive text, I find URL shortening to be useless. 98% of websites I visit are via a search or a clicked hyperlink ... and if I'm clicking a link, who cares if it's 20 characters or 200 characters?

Mind you, I have a clear bias as I am working with professional services most of the time and am used to seeing complete URLs (and do not click otherwise); however, in general, I think it's undesirable to be magically transported from one URL domain to another, just for the sake of cuteness.

Now, if there was a means of shortening a URL from something like mydomain.com/anextremelylongurlthathasmanymanycharacters to mydomain.com/short, that is more acceptable. Having a shortened URL within a domain is fine and useful given the same positives that you find with URL shortening, but without the obvious negatives as listed.

All in all, though, I like to know where I'm going before I get there. So, URL shortening get the Nay.

Thoughts are welcome, as always.

--
Carl Scott
Software Developer, Solertium Corporation

The Google Takeover?

First came Chrome, Google's web browser built from the bottom-up based on some well-thought out and fresh ideas (which I happen to be using now as I type this!).

But that just wasn't enough. Now, they want the whole operating system:

http://www.digitalmediabuzz.com/2009/07/os-wars-google-vs-goliath/

Good luck. We at Solertium are excited.

--
Carl Scott
Software Developer, Solertium Corporation

Does Open Source Software Suck?

Hi All,

Just came across an interesting blog that I thought I'd share. It discusses the pitfalls of Open-Source Software.

http://blog.bitquabit.com/2009/06/30/one-which-i-say-open-source-software-sucks/

My thoughts? Well, first, I think the article makes a number of valid points. However, many of them do not only apply to open-source. There's a lot of "sucky" software out there! But the fact that any Tom, Dick, or Harry with a machine can create open-source software means you have to be wary about where you get software from.

The article was directed at the higher-level OSS, so to focus on that, again, I agree with a lot of what was said. The main mistake this article makes, in my eyes, is limiting the remarks to the world of open-source. That said, as a happy Windows user, the value of well-polished financially-backed software is undeniable.

However, the draw to open-source is the gain received from using the latest trends and tools available. Much "industrial" software fails to stay current and shys away from new ideas, clutching ever-so-tightly to that which worked. By and large, open-source projects tend to feel much fresher, breeding ideas that 5-10 years later could likely wind up in a big-ticket, closed-source product.

Again, I won't deny the facts presented in the article. But there's always two sides to a coin. :)

--
Carl Scott
Open-Source Software Developer, Solertium Corporation

Google Charts Via Charts4J 1.2!

Progress is a great thing...

After announcing my work on Google Charts for GWT, I was able to work with the Charts4J team, who'd also implemented a Google Charts Java API that worked server-side, and made a branch that was compatible with GWT.

charts4j 1.1 was released as an initial port of existing behavior of the original charts4j. Today, 1.2 was released containing loads of fun features as well as integration of some features I was using in Google Charts for GWT:

http://code.google.com/p/charts4j/wiki/Change_Log

If you're looking for a means of providing lightweight charts in your GWT application, give it a whirl. If you need lightweight charts in a non-GWT client application, you should try it out as well!

http://charts4j.googlecode.com/

Here's hoping you find this as useful as I have!

--
Carl Scott
Software Developer, Solertium Corporation

Google Charts for GWT

For anyone interested, I have begun developing a GWT implementation of the latest Google Charts API.

While there are a number of useful GWT-based chart implementations, many of them are based in Flash or are otherwise a bit heavyweight. Although there are some that work really well and are very nice (there's a really cool-looking one for Ext GWT), sometimes you just want a simple chart without any external dependencies.

The Google Charts API allows you to create charts on the fly via a URL-based API. It returns a static generated image of your chart. This makes for a powerful, yet extremely lightweight tool. While this API is clearly exposed on their site, there does not seem to exist, essentially, a standardized wrapper for this that caters to GWT.

My implementation of Google Charts for GWT simply provides that wrapper. Certainly, if you want something flashy and dynamic, this tool is not for you, you want the heavier tools I alluded to earlier.  But for a quick, lightweight tool with a number of customizable features, give this a whirl.

It is currently in the alpha stages, meaning that it is functional but is not completely documented and may contain some weird behavior. I would like to test the implementation more aggressively and finish off the full API feature set. Right now, though, you can create Bar, Line, Pie, and Scatter Charts, complete with features for Chart Legends, Shape Markers, custom colors and chart axes, multiple data sets, and more.

Check out my Google Charts for GWT samples here (with example source code):
http://www.solertium.com/samples/charts/index.html

Download the source code and samples from:
http://code.google.com/p/gogoego/source/checkout
https://github.com/GoGoCarl/google-charts-gwt

The project you're looking for is located in trunk/modules/com.solertium.util.gwt.charts

Hopefully this is useful. I'm very open to criticism and suggestions going into further development of this project.

--
Carl Scott
Software Developer, Solertium Corporation