I recently began working on a new venture, QR Card Us, to help support my education and fund another venture–it just launched tonight. This isn't so much a sales pitch about that though as it is an announcement of an open-sourced Haskell module I wrote in the process (though, you're certainly welcome to go check it out, tell your friends, and order some!).

As I was reading up on vCards, I found it most helpful to read RFC 2426. I wanted to easily play around with vCards in my favorite language, but didn't care for the existing vCard module, so I decided to write my own instead, thus letting me announce hs-vcard. I think it's fairly straight forward and well-documented, so I'll end with an example input and the output.

This is the vCard for Frank Dawson, one of the RFC 2426 authors, constructed in Haskell:

and printed out as:

Please let me know if you find any problems, and even better: fix them and submit patches to the GitHub repository. I also chose to not implement reading them in, primarily because I had absolutely no use for that, but people are again welcome to contribute and do so.

I hope you find it useful! Please feel free to comment with any questions or feedback you might have on how I could do things better.

I had started this project for two reasons: first, I had another project in mind that needed to access Google Voice; but knew of no way to do so; and second, I wanted to provide a way for developers to easily access Google Voice.

My idea was to access Google Voice's internal API, parse it with lxml and cjson, and keep the results stored in classes specific to the type of data to make utilizing Google Voice in any project a simple thing to do. However, as I was finishing up on a recent change of the conversation class to be Python properties, I decided that it would be fun to do a quick search for "Python Google Voice." I had never done this before and figured enough time had passed due to a number of things (work, school, an accident I was recently in) that it was possible that something did indeed exist.

How right I was. I found a very nicely coded project on Google Code (originally GitHub, it appears) called PyGoogleVoice. Authored by Justin Quick and Joe McCall, I have emailed them to let them know that I am stepping down on my own version. A lot of the features that they have meet (and even exceed, such as stemming the project to support Asterisk) what I envisioned smsGV (now py-smsGV) behold.

I am still going to work on the project that had inspired me to originally create. Though, instead of using my own library, I have decided it proper to use Justin Quick and Joe McCall's. It has been more finely tested, is better featured, and will continue to be updated while py-smsGV will not.

Also, for both the benefit of PyGoogleVoice, should they find inspiration, and other developers, I am going to still post my code to GitHub. It's not as fine-tuned as I would like, it is not representative of my actual skill because certain parts of it are still written in an early 'testing' fashion and had yet to be refactored or rewritten and finalized. However, I'm not a very big fan of just destroying code. Knowledge and inspiration can come from many places, possibly including my code, and so I have no problem hesitating to post it, even in its incomplete stage.

This post is just to let everyone know about the other Python Google Voice project in existence and to keep anyone who had been waiting on mine from anticipating or being anxious. I'll post more about any lessons learned from the coding I had done on this as well as more about the project I had in mind in the (hopefully near, depending on my accident recovery, schooling, and work) future.

Aside from a few new projects and developments for work, I have delayed the release of smsGV slightly (though its commits are always available publicly on GitHub—albeit not very recently updated, that's to be soon changed).

It's only fair that I let you all know the reason for the delay. It's not because I don't love smsGV or Google Voice anymore, I use it daily, but rather because I have traversed the Google Voice backend further and found a more optimized route to achieving my goals. Furthermore, I've found that using it will prepare the smsGV library for additional features that otherwise would not have been or would have been difficult and inefficient to implement.

That's all for now. I just wanted to keep everyone posted on the progress.

Preface

There are reasons for everything as I always recall in regular discussions with friends, family, and other acquaintances. Paste2Upload is not an exception, that’s for sure. An avid Lifehacker reader, I remind myself consistently that if there is a noted repetition in my daily life that it is necessary it be dealt with.

One thing that I do, without fail, throughout the day is open up a new tab in whichever browser I am feeling favourable to that day (mainly Firefox or Safari), navigate my way to Paste2, and paste a snippet of text; whether it be a funny conversation, an important selection of a website, or some code that I want to share quickly and efficiently. This works quite well, I must admit, but on the last note of the previous sentence there exists one issue with the current workflow: efficiency.

A Solution

Beginning

As we all know, especially the engineers of the crowd, there are many solutions to any given problem. Now, when I’m among a circle of my peers, I’ll make a point to insist that my solution is right. It’s all in good fun, just like they’d insist that theirs is right to me—it’s the engineer’s way.

And so, working diligently, I analyzed the situation at hand and came up with a solution (the right solution, I might add, to any of the aforementioned crowd). What I needed was clear:

A swift, efficient way to paste text—sans-browser. I don’t always work with a browser open, but I do often communicate with an instant messenger at hand, so I wanted to untie myself from that single necessity.

• A system-wide solution—I work in a variety of environments and share an equal variety of ways that I obtain information to share. Again, snippets from various mediums including both conversations and code. [ Note: Although room exists for various implementations to be system-wide, the actual execution of such is not addressed directly in the code, though I do handle it in a way specific to Apple’s OS X. See a soon-to-follow post for more information. ]
• Full Functionality—Paste2 supplies three fields, two of which are greatly important to me: language and “code.” Although the code field can be anything, as I’ve already stated twice above, the language field denotes options to format the text via syntax highlighting. Whether that be plain text, Python, MySQL, or other, I knew that it was necessary to implement this.

As you read through my implementation, please don’t hesitate to chime in with comments here and there. They’re never hushed away and are instead acted quite the opposite to, I welcome them. While around my peers for the effect of playful banter and competition I’ll insist that I’ve devised the end-all, be-all solutions, I welcome open-mindedness and request any suggestions. If they seem reasonable and well-placed and have a relevancy to the topic, I’ll implement them as necessary.

Implementation

My goals were outlined and the implementation of them became clear. My original vision with this was that I create a command-line based utility in Python that would allow me to execute something along the following lines:

./paste2 --verbose --language python --description “A little taste of some code that I wrote” [text]

An explanation is in line here:

• Verbose—We all know that this usually means the program being noisier in its execution. For me, it simply meant that the program would output to stdout “Pasted to http://paste2.org/p/..”
• Language—Working from the syntax highlighting options given on Paste2, this would do the obvious and allow me to specify a language to highlight for.
• Description—On the revision of Paste2 that exists at the time of this writing, you can supply some context to your pasted information in a description field. This data will appear below your paste.
• [text]—This one, although all options are optional, I did not specify because I wanted to note its impact on the end-product and how it existed in my original vision. The idea was that, if unspecified, the text would be supplied via a small clipboard module that I wrote (also in Python) to get the current clipboard data from the computer for Linux, Unix, Windows, and OS X-based operating systems.
• Return Value—The return was always similar, the program would exit cleanly and leave the user with a newly set clipboard containing the Paste2 posting URL.

A Mutable Plan

As a testament to my earlier promise, I am never afraid to welcome new ideas or proposed changes. Talking with a good friend of mine, Will Donnelly, I showed him my code at its then-completed state. It functioned according to the specifications above. Being the kind and praising friend that he is, he immediately pointed out everything that he saw wrong with it.

His main complaint was that my mindset did not seem to embrace the “UNIXy” side of things. I asked him to expand and he pointed out that my program forced the user to have their clipboard modified (which would hinder various implementations), had the unnecessary (and unwelcomed) [-v, --verbose] flags, and that it accepted only input from the clipboard or via directly input text.

To me, that last part was not an issue until he expanded further on his complaint. As he put it, I was failing to meet the standard by not accepting input-by-file or input through stdin. This is when everything clicked: a change had to be made.

The Mutation

I overlooked the proposed changes and implemented them with ease. It wasn’t many lines of change, but the payoff was well worth it. The program now accepted input through both stdin and file (which was simple enough, since Python treats the former just as it would the latter).

The verbose flags were removed as the program would now always output the URL to stdout so that, in the UNIXy fashion that was so demanded, it could be piped wherever necessary—whether xsel (Linux) or pbcopy (OS X).

Text input was removed in favour of file-name specification, which could be specified as a single dash (“-”) to let the program know that stdin input was requested.

The End Product

The end product, distributed freely under the MIT License, can be viewed at its GitHub repository page. The code itself can be viewed directly from the GitHub website as well.

The Message

Although I wanted to take an opportunity to share this bit of code with everyone, and I hope others will find it useful to their daily lives in reducing repetition and increasing efficiency, I had a greater meaning to this post.

First, as my preface suggested, I wanted to stress to all programmers (or - if not a programmer, to those who may want to suggest a small project for me to tackle) that if you notice repetition and inefficiency through your daily life, this is ample opportunity to write some productive code and simplify your life.

Second, I want to remind everyone that—no matter the field that you work in—I know that it is easy to get an idea stuck and committed in your head, but don’t let that block you from the bigger picture. Always take a step back, share your idea with friends and family, and don’t shun their input away. Although you may think that your original idea is the end-all solution and will work exactly how you want it, you may find from a little bit of open-mindedness that other possibilities can branch outwards from a little seed. As was with my code above, clipboards were my main concern at the beginning. Toward the end, various implementations are much less limited.

The Problem

 

I jumped up and down with excitement when I received my Google Voice upgrade, for many reasons that excite me. First is being able to place calls through the number, and receive calls as well. Though, the most important was by far SMS. I do not have a messaging plan on my mobile because it is just plain expensive, but I do have a data plan on it: for work, for play, and because the price is certainly right.

 

The problem that I have with Google Voice at the moment, however, is that there are two ways to receive messages on my phone through my GV number:

 

1. Receive the message via SMS 

1.  Check via www.google.com/voice/m/

 

Now, given what I have already said, the first option is out right away. So that leaves the option behind door number two – using my browser to check for new messages. Option two introduces an issue that, for me, defeats the whole purpose of SMS: notification.

 

My phone buzzes, dings, and changes the colours on my room’s walls whenever I receive a new email. (Okay, well, it does most of that). Sadly, it does not know when to set off its bells and whistles if the only way that it has to check for new messages is Pocket IE, Opera Mobile, or whichever other browser you prefer. This is an issue, since I don’t want to refresh the browser minutely, or even bi-minutely, to maintain a conversation with a friend.

 

Why not email their number?

 

Sure, you may point out that I can just email theirNumber@carrierSmsDomain.tld. I absolutely despise this method: it is tedious, prone to errors, and it means that I have to dig up all of these carrier emails, know if they change. Overall, it is simply a hassle, and hassles do not appeal to me.

 

Alright, alright. We get it - on with “The Solution”

 

The solution, in my humblest of opinions, is quite a simple one. Why not have Google Voice send new SMS messages to my email? It’s really quite an easy process, something that the “Big G” could implement with ease given they have direct access to the SMS receiving hooks. And yet, they have not. Not for a lack of request from their users, as numerous postings online show. Not from a lack of engineering and programming intelligence, as their Google Wave shows. Perhaps it is simply because the service is new and they do not want to overstuff it with potentially useless features. I truly do not know, I’d have to talk to Larry or Sergey to find out.

 

So, rather than waiting and speculating if the multicoloured giant will ever release this feature, I’ve decided to implement it myself.

 

How?

 

First I had to inspect the Google Voice system to see what potential methods were available for me to use.

 

The basic idea that I narrowed everything down with involves a lovely little friend of mine called Python, a module with the sweet name of “lxml,” and some inspection of the Google Voice system. At the time of this writing, I know what tactic I will be using because, well, I’ve already implemented it. The project is not released just yet because I’m still adding the gravy to my potatoes, but the core of my strategy has been prototyped, written, implemented, tested, and proven. The library uses a combination of Google’s mobile and “full” website, along with parsing the included JSON, in order to most efficiently and accurately retrieve new messages.

 

Password handling.

 

One obvious line of thinking is that I would have to store the passwords. This bothers me, since to make storing them useful I would either have to encrypt in such a way that decryption was swift (which would ultimately only be faux security at best), or I could store them plaintext.

 

“Which way, then?” you may be asking. My answer is quite simple: "Neither." I do not like storing such sensitive data plaintext, and upon further inspection it is not necessary. When the library processes a login request it will store a persistent cookie to ensure that the session lasts for as long as possible. Of course, exceptions where the cookie expires or shows as invalid are handled appropriately.