Delivering the Art of Lunch

By on

Leave a comment

Here at InterKnowlogy we have this great program called RECESS where we get to take a few hours each week to try our hand at new technologies. One of our leads, Dan Hanan, posted a great little read on what RECESS actually is so I won’t go into any more detail about it.

Background
One of the best ways, we’ve found, to learn a new technology is to utilize it in an application in order to find its strengths, weaknesses, etc. Being a bunch of Software Engineers we have a tendency to be obsessive and compulsive in almost everything we do, and when that is paired with pickiness over certain types of food, deciding upon where to go to lunch as a group becomes very time consuming (almost longer than actually eating the food). So back in the spring of this year a couple of other devs and myself decided we wanted to learn more about ASP.Net MVC, Silverlight 4 (with RIA), and Entity Framework 4, and decided on creating a lunch decision service using these technologies (kill 2 birds with 1 stone and have fun doing it). We also decided that we needed a good name for this application before we could start, and since InterKnowlogy’s slogan had recently changed to Delivering the Art of Software, we decided to play with it and call our application the DAL (Delivering the Art of Lunch).

Scenario
The most important thing we’ve learned from other RECESS projects is to keep the finished project as simple as possible otherwise it won’t ever be finished. So we decided to create a service that would send out an email to all the registered users, at a specified time in the morning, to see if they will be joining the group for lunch. In the email is a link to an MVC page where they say yes or no. A little later on everyone who says that they are in for lunch then receive another email with a link to another MVC page where they can choose their top 3 restaurant choices(the restaurants are an intersection of all the preferred restaurants of the users joining in for lunch), and a little later an email stating the restaurant choice is sent out to everyone participating in lunch. It is then up to the people involved on whether they are going to abide by the choice or not.

We decided to use the Silverlight client to be where we register users, create/update/delete restaurants, and choose which restaurants the user is ok with going to for lunch, and the ASP.Net MVC site is where the users specify if they are available for lunch and their top 3 restaurant choices. It also shows who has said they are joining in and what the final restaurant choice is.

After a few weeks of work we had an Alpha version that we wanted to try out with our coworkers. So we deployed it to a server, and sent out an email letting everyone know about it. With it being Alpha we expected to run into a few issues, but within the 1st day we hit one issue that brought the whole thing down. Our owner, Tim Huckaby, loves to hear about new things we’re working on and try them out. So he joined in, added 5 top restaurants in the world (that none of us can afford let alone get to over lunch time), and made only those 5 his preferred restaurants. The next day when the process started and he said he was in for lunch (even though he doesn’t eat lunch with us), the resulting intersection of preferred restaurants was empty, and we weren’t able to use the application when it never provided restaurants to choose from.

Fixing the bug
While we have given Tim some much deserved crap over the restaurants he chose, he did find a very damaging bug that needed to be fixed. Our end result was if the restaurant intersection didn’t return any results then choose up to 5 of the most popular preferred restaurants, and if there still weren’t any the service randomly chooses 5 restaurants for everyone to vote on.

After a long hiatus, I finally got the bug fix along with a number of other refactorings up again and we’ll see how long it can stand. 🙂

Finally
The overall learning experience was pretty positive. Entity Framework makes development against a simple database extremely easy, and in the Silverlight world, pairing that with RIA services gives you the same functionality on the client side. One issue with RIA that I ran into is the fact that any extra methods you create to extend the DomainService is very limited to the parameter types that can be used. It is extremely powerful for basic CRUD functionality, but it takes work to get more complex things functioning. ASP.Net MVC is really powerful and something that I will need to delve into more in the future.

More RECESS rambles to come.

Google ClientLogin URL Changed

By on

Leave a comment

Since Feb. 2010 I have been working on a pet project called Informant. The project interfaces with Google Voice and allows the user to send SMS messages to a group of contacts from their Google Contacts. The application has been working great since its first release in Mar. 2010. However, in the last month I’ve received reports that it was not working. Users have been unable to authenticate with Google which was most concerning. I started to look into a solution and found nothing online that could help me. With out time to fix the issue, the problem has persisted until today. I decided to take a different approach and try to find another .NET implementation of the Google Voice API. After looking for a while I found one on Source Forge called GVoiceDotNet. Their implementation is authenticating exactly the same way as I’m doing in Informant. Both projects use the ClientLogin API for Google Accounts. I didn’t notice any differences until I starting doing a side by side comparison of the URLs we are using to authenticate. The change, while small, made a big difference.

My Original URL: https://www.google.com/accounts/ServiceLoginAuth?service=grandcentral

GVoiceDotNet URL: https://accounts.google.com/ServiceLoginAuth

There is only one breaking change between these two URLs. No, it’s not the service=grandcentral. That part is apparently not required and is ignored. The URL www.google.com/accounts is no longer valid, it is now accounts.google.com.

I am totally surprised that Google changed this URL and even more surprised that I can’t find any documentation about this change. Perhaps I’m just looking in the wrong place? It doesn’t really matter, I’m just stoked to have Informant back up and running!

If you don’t use Google Voice, you should definitely check it out! And check out Informant on Codeplex!

Fonts and the Web

By on

Leave a comment

Here at InterKnowlogy, we get time each week to tinker and dive into technologies that interest and inspire us. We call it RECESS, which stands for Research and Experimental Coding to Enhance Software Skills. This week I’ve been noticing sites ‘sprucing it up’ by using custom font embedding with services such as TypeKit (Or similarly related projects such as Google Web Fonts) that allow you to license and use custom fonts in a site.

There’s a problem though. 90% of the time it annoys me.

Let me explain. First impressions are everything, and right after first impressions is readability. If I come to your site looking for information, to read something, I don’t want to get a headache doing so. The problem isn’t the design or the font itself usually, it’s the way the browser deals with and renders the font. Using a custom or weird font for the body text of the page WILL bother people. Its why standard fonts exist and are as popular as they are: readability. Now, that being said, there are really good design reasons to want to use custom fonts in a dynamic content driven site to augment the design. Especially in the title and headers since it will catch someones eye and because people spend a minimal amount of time reading them anyways. Whatever the reason, if your going to go down the custom font path its going to be important to refine and choose a solution that is going to be consistent and usable for the people that visit your site.

Coming back to RECESS, I spent some time examining the different offerings and essentially broke them into two categories: Browser/OS rendered text, and Image rendered text. Let me explain: For the Browser/OS rendered text (which TypeKit and Google Web Fonts use) the text is set using normal CSS rules, and then an actual font file is loaded by the browser and used to display the text. Almost exactly how text is displayed for application on your computer except that the font is never ‘installed’. The advantage is that it behaves exactly like normal fonts, you can type, select, copy, and do all the normal things you do with text. The second way is imaged rendered text, taking some chunk of text and turning it into an image that gets displayed in place of the text. Designers sometimes do this for logos and main headers that almost never change because it doesn’t require the use of a more modern browser and they KNOW that it will display the same way. Also in this category is a tool called Cufón. It’s a bit of JavaScript and a bit of a generator. It basically takes a font file, turns it into a bunch of shapes, and then on the users computer it uses JavaScript to load, render, and replace text in the page with those images. The disadvantage being you can’t select and copy the text in the same way, but the advantage is that it looks consistent and renders well.

I decided to tinker with these and see what I came up with (All screenshots are on Windows 7, the IE9 ‘font’ example is invalid as I would have had to convert it to a different format for it to display, but I was lazy. There is another example later that illustrates IE9 correctly showing a font this way.)

So here are some screenshots of the results on different browsers on Windows 7:

Chrome 12:

Firefox 6:

Safari 5.1 on Windows

Internet Explorer 9

I was surprised at the results. Same font, same file, but completely different results between Chrome / Firefox / Safari (IE9 excluded obviously) for the regular font rendering. Cufón came out the most consistent of all of these.

Next I went to TypeKit and found excellent illustrations of why embedding fonts is still so difficult and why I’m seriously considering using Cufón for the time being:

From top to bottom, Safari 5.1, Chrome 12, Firefox 6, IE9

The big thing to note is how jagged the letters look until you get to IE9. Readability wise, I would NOT consider using an alternate font for a large amount of text unless I had to, and for right now, Cufón seems a very viable choice for consistency.

There’s no final conclusion in this, since you will have reasons that will drive you to one option or another (Or simply throw your hands in the air and announce to the world that you are done with the web forever) So:

Nerd out.

Tinker.

Be careful with your font choices and how far you take this on a site that will be used on a regular basis. Cheers!

GitHub 101 on Windows

By on

Leave a comment

This post is a continuation off of this post on Up and Running with Git and Visual Studio, if you have no idea what Git is, or how to setup git and git-extensions on windows I recommend you start there.

So you’ve installed git and git extensions, written a sweet hello world application, made some commits, split some branches and merged features in and out here and there, and now your looking to share that code with the world or you’ve decided that just having a local copy of your code isn’t good enough for a backup and don’t want or can’t go out and purchase another machine or setup remote hard drive. For whatever reason, you’ve decided to use GitHub to push a copy of your source code up to, either to share with the world, keep a local backup, or to share with a team.

First, you’ll need to create a GitHub account, which is free for public/shared repositories (example: Open Source Projects), and from $7-22 a month for private repositories, and $25+ for organizations and companies. Assuming you decide to go with a free account to try things out, you’ll land at a page that will look like this:

Pick a username, an e-mail address, and a password, click the signup button, and bam! You’re now a member of the GitHub community. You can now go explore, setup your profile, write a bio (Your picture is based on your e-mail address from the Gravatar service, the homepage explains it well enough)

Now, on GitHub your going to create a new repository, it’ll ask you for a project name, optional description and homepage. Enter all the details and click Create Repository (Note that Project Name doesn’t have to be unique in all of GitHub, just unique to the repositories and forks that you have on your user account)

Now obviously, if you have a paid account you’d have the option to create a private repositories that only you (and people you invite to see) can see, fork and access. Once you’ve created your repository, you’ll be greeted with instructions on how to set it up. If you’ve followed my previous post you should have already setup your e-mail address (assuming that it’s the e-mail address you used to sign up to GitHub) and name, and so any commits will automatically be associated to this account based on the e-mail address. Now, once you’ve created your account your going to have to add your public key. What the heck?

Ok, without getting into too much detail (You can read way more about transport layer security and public – private key encryption if you find it as interesting as I do…) GitHub is providing two way authentication by using an SSL key. Normally when you connect to a secure server over SSL the server identifies itself with the server name, certificate authority, and a public key, however, your computer remains anonymous and it wouldn’t matter what computer your using. By providing an SSL certificate, your telling the GitHub server “Not only do I trust that you are who you say you are, I’m also providing a strong encryption grade authentication method that proves who I am when I’m connecting to you.”

Details aside, the long and short of it is that you have to generate an SSL certificate and give the public key token to GitHub (obviously keeping the private key secret). Browse to your repository in GitExtensions and open “Generate or import key”.

Which will allow you to generate a key (You will need to save both the public and private key somewhere), by default I believe it generates an SSH-2 RSA 1024bit key which is what you need for GitHub as of this writing.

If you’ve already done this you can just use an existing key. Once you’ve saved it (optionally supplying a pass-phrase for the private key file), it’s time to tell GitHub what your public key is.

Log into GitHub, go to account settings, and go down into the SSH Public Keys section, in there, give your public key a title, and paste in the public key from putty. The text should look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAkn1Hp72xRMjYtfmaHRbtwTrNBEt2oPVKyGh8uU1b8BPw
CjrtCzOGHF66YzBAitpHqaGOkLPyLXHHk1BrAKaWE06W2aVooNdqAEUYBwe0gJGR/bmf73Qhey2xW9
PBE5ocsEpVnW5HtEoMTpiKaPDqSTY6ogH/dt4FSclubb/5DKE=

And after saving it, you should have a new key:

These SSH keys uniquely identify you as a user.

Now that you’ve added your public key into Git, you need to add the remote repository to your local repository and setup PuTTY with your SSH key. Open up Git Extensions, browse to your repository, open up the Remotes folder, and you should see the following:

From here, enter a name for the remote repository, and pull the URL from the repository startup page, it should look like this: git@github.com:yourusername/Test-Project.git

Brows to wherever you’ve saved your private SSH key file for PuTTY, and click the Load SSH Key. If you saved it with a password, you’ll be prompted to enter the passphrase you protected the public key file with:

Enter your passphrase and click ok.

Once done, click the Test connection. If this is the first time you’ve connected to GitHub, you’ll be notified that this server’s RSA fingerprint isn’t in the registry:

Check to make sure it’s the same as the one shown on the GitHub website, and hit yest to cache the GitHub server host key.

And you should then see that you can authenticate:

Save your configuration, close out of the dialog and select the up arrow icon (or go into the menu and select push) and push all or some of your branches to GitHub:

And there you go! Remote repository pushing and pulling. Just like that.

And now that you’ve pushed your repository up to GitHub, you can also pull other changes:

And that’s all for now, if you’ve got questions or comments, leave them in the comments for this post and I’ll respond to them as soon as I can.