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

RESTful Client-Side tools for GWT

I guess this is more of an announcement than a blog, but I just wanted to do a quick follow up to my last blog to mention some new developments pertaining to using a RESTful approach to GWT.

In my last blog, I spoke of RestLet, a server-side Java framework for REST. When I first learned of this technology, my cronies at Solertium Corporation and I fully embraced the concept, even doing some development on the open-source tool. Between then and now, I have been experimenting with client-side tools that provide reliable API through GWT to a RESTful server.

I first found GWT-REST, which if you saw my comments, I found to be pretty usable. Like the original developers of RestLet, though, I found it to have almost too much going on to make it work for me at the time. In addition, since, at the time, I have a strong code pattern that worked, it didn't make me want to go through the trouble of refactoring. After speaking with their development team, though, it looks to be strong in the future.
http://code.google.com/p/gwt-rest/

Since then, the RestLet guys have announced the release of a Restlet-GWT module, a port of RestLet to GWT, supported by the release of GWT 1.5. You can check out the official announcement here:
http://blog.noelios.com/2008/07/25/restlet-ported-to-gwt/

I am interested in seeing the differences between this and GWT-REST, but from my initial reading it seems that the RestLet version is an attempt at a direct port as opposed to something customized to have client-side conveniences implemented -- which I feel has strong and weak points, but the good should outweigh the bad here. I'm excited to see the implementation details, though! If you want a quick overview, the RestLet wiki provides pretty pictures and diagrams:
http://wiki.restlet.org/docs_1.1/g1/43-restlet/144-restlet.html

Again, I want to express that the RESTful method is more of an alternative to RPC than a replacement, both having benefits and drawbacks. The main drawback to RPC that has turned me to this approach is the tight client-server coupling issues and the limitations it enforces on your back-end server technologies.

My suggestion -- give Restlet's GWT module a shot. Like I said, it's an alternative, and it works right alongside RPC so it's not an either-or situation. We all have our own ways of getting the job done, but I'm always excited to hear of new developments and try them out, especially ones like these which make my job that much easier!

Thanks for your time in reading this. Feel free to comment with opinions for or against REST in GWT as I'd love to hear both sides. Also, if you'd recommend any technologies, again, feel free.

--
Carl Scott
Software Developer, Solertium Corporation



References:

• GWT-REST: http://code.google.com/p/gwt-rest/
• RestLet Wiki: http://wiki.restlet.org/docs_1.1/2-restlet.html
• RestLet with GWT: http://blog.noelios.com/2008/07/25/restlet-ported-to-gwt/
• Google Web Toolkit: http://code.google.com/webtoolkit/
• Roy Fielding explains REST: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
• RestLet: http://www.restlet.org/
• My previous blog: http://gogocarl.blogspot.com/2008/04/internet-alternative-to-gwts-rpc.html

The Internet: An Alternative to GWT's RPC

This blog is aimed at software developers currently or considering using Google Web Toolkit (GWT), and assumes you have some prior knowledge/background. I do not aim to be technical in this blog, but rather, simply expose the idea and provide insight to those loathing particular programming paradigms.

Google's Google Web Toolkit (GWT) has make remarkable breakthroughs in allowing Java developers to easily create websites and web-based applications with little concern about cross-browser issues. As a software developer fitting this niche, I must say I am more than happy with what GWT provides.

That said, one of the biggest complaints about GWT is it's Remote Procedure Calls (RPC). In a nutshell, your client calls a function through an interface which the server interprets, executes, and returns a Java representation of results. The actual process is somewhat annoying to implement, can be somewhat clunky, and can have the speed of the DMV lines at the end of the month. Ok, so I'm exaggerating a bit, but it's nuiances were enough to me to choose to never go back to RPC. In addition, I don't think my server should be returning me a Java Object. If I wanted to access this outside the context of my GWT application (hey, these "crazy" things may happen), I know Internet Explorer probably can't render it too well -- it has a hard enough time with HTML (zing!).

Allow me to re-introduce the concept of REST.

Representational State Transfer (REST) is an architecture style that, well, kinda does what it says. In the context of Web Apps, it defines how we define, locate, and access resources. If you want the whole scoop, I've got reference links at the bottom. For this exercise, you just need to understand resources and representations.

A resource is the conceptual target of a reference (the reference being, generally, a URL). A file, for example, could be considered a resource. The file's representation can be a number of things, but examples are HTML, XML, GIF image, basically what the user sees. In short, it represents a resource in some meaningful way. For this exercise, let's go with XML as our default representation (it will become painfully apparent why soon).

With RPC, using a method to retrieve some data (a Representation, perhaps) is the standard means. There is a RESTful way to do this a well, and here's the kicker: it's a basic building block of the Internet! The standard CRUD (Create, Read, Update, Delete) operations are already represented as HTTP PUT, GET, POST, and DELETE, respectively. I'd argue that just about anything you'll need to do with a web application can be covered by one or a combination of these functions. I'm not going to get technical today but take my word for it.

Enter RestLet. A lightweight, open-source Java API that acts as a catalyst in developing Web Services in Java to handle ANY general HTTP request. A request from, say, our Web-based GWT application! RestLet employs the principles of REST, transferring representations from the server to the client upon request. Assuming we use XML Represenations, we already have a means of parsing and interpreting these representations client-side ... AJAX, which is at it's core, GWT.

Now, we have a generalized API to program to and access data from. We can use GWT to make requests, but now JSNI, JSP, PHP, even standard HTTP requests are respected. We have a portable server to interpret our requests and the responses (XML representations) are immediately parsable, even by IE (zing!).

In short, employing the principles of REST to ANY web app is incredibly beneficial for a number of reasons that I'll leave to the avid reader to convince themselves of. Roy Fielding has spent plently of time stating things and I don't need to use more. RestLet, an open-source project provides a well-thought out means of utilizing this architecture. And with this, you can finally give that RPC code a REST.

I wanted to use this blog to simply introduce the concept of REST within the context of GWT, how it can be leveraged by AJAX, and how it can be used as an alternative to RPC. If there's any interest, I'll do a follow-up blog or blogs that will delve into the following topics:

• Current Open-Source Applications using REST/RestLet and GWT.
• Open-Source Solutions made to speed up XML processing and leverage REST.
• Creating a RESTful Web Server
• RESTful References and Why They're Essential

This is all information you can dig up yourself, but I'm happy to share. REST and RestLet, of course, aren't the only way to get outside the RPC box, but, from my experience, it works efficiently, encourages robust code, and, most importantly for me, let me say bye-bye to RPC.

To close, I want to say that I don't profess to be a definitive authority on this, and I'm still learning new things everyday. I look forward to any feedback on this you may have, and any other out-the-box ideas.

--
Carl Scott
Software Developer, Solertium Corporation

References:

• Google Web Toolkit: http://code.google.com/webtoolkit/
• Roy Fielding explains REST: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
• RestLet: http://www.restlet.org/