Category: Flex

XNA is quite possibly one of the most robust game programming frameworks out there. You can do nearly anything with it, and one of the reasons it is so flexible is its “Content Pipeline”. But sometimes it can be a bit tricky to use this feature, requiring us to do bit more work. But in the end, it helps to use the Content Pipeline. Luckily today we are going over how to use it to load in some XML.

A quick google search will reveal that loading in XML with C# and XNA can be a bit more complicated that it seems. There are several ways to accomplish XML integration, all dependent on your needs. Today we are going to go over the simplest way to load XML in XNA using the fancy Content Pipeline.

For the best viewing, use full screen mode.

A while ago Google gave us a brand new language, Go. In the last couple of years I really haven’t heard much about it, but I decided to finally install it and give it a try. This tutorial will guide you step-by-step on how to install Google Go and start writing your own applications.

Go’s website has very good instructions on how to install it, and this tutorial will take many steps directly from there. Their website has instructions for all the major platforms, however this article will be specific to Mac OS X running on a 64 bit Intel processor.

Google does not distribute the binaries, which means you’ll have to build it for your own platform.

Setup Environment Variables

When you build Go, the compiler is going to need to know a few things.

$GOROOT is the path to where you’ll download the Google Go source code. I left mine where Google suggested, which is $HOME/go (/Users/[username]/go).

$GOARCH is the architecture you’re building for. The options are amd64, 386, or arm. The name is slightly misleading, but amd64 works for all 64bit x86 processors, and is what you’ll want to choose for Inlet 64 bit processors.

$GOOS is the operating system. The options here are darwin (for Mac), freebsd, linux, and nacl.

$GOBIN is where the output from the build will be placed. You’ll have to create this folder before building Go.

Grabbing The Go Source

Go uses Mercurial for version control. I didn’t have Mercurial installed, so I had to install it with this command.

After you have Mercurial installed, fetch the repository to your Go root.

Building Go

This step assumes you have gcc and a bunch of other crap installed. The simplest way to get these is to just install Xcode. If you’re a developer on a Mac, however, chances are you’ve already got it installed.

When the build is complete, you’ll see something that looks like this:

The known bugs are expected and the number may vary based on the current release of Go and your architecture.

Once this is done, a compiler and a linker has been placed in the bin folder. Time to add that folder to the $PATH environment variable.

Writing Some Go Code

With your favorite text editor, create a helloworld.go file and add some Go code to it.

The compiler and linker will be called 8g and 8l. We need to now compile and link our application.

After it builds and links without errors, it’s time to run our program.

Which outputs:

And there you have it. If you own a Mac and are interested in messing with Google Go, this tutorial should get you started. Go has a pretty good sized framework that should let you do a lot of interesting things. Google uses Go internally for production systems, which I guess gives it some credibility as a mature language. Hopefully Go can gain some mainstream momentum in the future, and I’ll definitely be watching it grow.

A while ago Google gave us a brand new language, Go. In the last couple of years I really haven’t heard much about it, but I decided to finally install it and give it a try. This tutorial will guide you step-by-step on how to install Google Go and start writing your own applications.

Go’s website has very good instructions on how to install it, and this tutorial will take many steps directly from there. Their website has instructions for all the major platforms, however this article will be specific to Mac OS X running on a 64 bit Intel processor.

Google does not distribute the binaries, which means you’ll have to build it for your own platform.

Setup Environment Variables

When you build Go, the compiler is going to need to know a few things.

$GOROOT is the path to where you’ll download the Google Go source code. I left mine where Google suggested, which is $HOME/go (/Users/[username]/go).

$GOARCH is the architecture you’re building for. The options are amd64, 386, or arm. The name is slightly misleading, but amd64 works for all 64bit x86 processors, and is what you’ll want to choose for Inlet 64 bit processors.

$GOOS is the operating system. The options here are darwin (for Mac), freebsd, linux, and nacl.

$GOBIN is where the output from the build will be placed. You’ll have to create this folder before building Go.

Grabbing The Go Source

Go uses Mercurial for version control. I didn’t have Mercurial installed, so I had to install it with this command.

After you have Mercurial installed, fetch the repository to your Go root.

Building Go

This step assumes you have gcc and a bunch of other crap installed. The simplest way to get these is to just install Xcode. If you’re a developer on a Mac, however, chances are you’ve already got it installed.

When the build is complete, you’ll see something that looks like this:

The known bugs are expected and the number may vary based on the current release of Go and your architecture.

Once this is done, a compiler and a linker has been placed in the bin folder. Time to add that folder to the $PATH environment variable.

Writing Some Go Code

With your favorite text editor, create a helloworld.go file and add some Go code to it.

The compiler and linker will be called 8g and 8l. We need to now compile and link our application.

After it builds and links without errors, it’s time to run our program.

Which outputs:

And there you have it. If you own a Mac and are interested in messing with Google Go, this tutorial should get you started. Go has a pretty good sized framework that should let you do a lot of interesting things. Google uses Go internally for production systems, which I guess gives it some credibility as a mature language. Hopefully Go can gain some mainstream momentum in the future, and I’ll definitely be watching it grow.

Remember back many moons ago when we posted a previous tutorial about Excel document creation? Specifically, this one. It worked, but if you take a look at it again, that code was painful. And ugly. And required hooking up ruby with a Java library called JExcelAPI using RJB – which, really, is not something anyone actually wants to do. So today we are going to take a look at something else (that I think) is a lot nicer/cleaner for Excel document generation: a new web service specifically for document creation called Doc Raptor.

As a disclaimer, I am one of the people who wrote Doc Raptor – so I apologize if I come across as too excited about it. In all honesty, I think I’d be just as excited if someone else had created the service – because I really hated integrating and using that Java library in every app that needed to produce Excel documents.

Enough talk about that, let us dive in and see how Doc Raptor works. The example here today is going to be in Ruby (because that is what I write most of the time now), but since Doc Raptor is just a RESTful webservice, you can easily make it work with the language of your choice. The high level overview is that you create html tables, send them as a POST request to Doc Raptor, and get back an Excel document. Below, you can see the Ruby code necessary for such a request:

First off, you need to get a Doc Raptor API Key – which is easy to do, you can just go sign up for the free plan, and it will be right there on the dashboard:

Below that you see that we are including the module HTTParty. HTTParty is a ruby gem that makes dealing with http connections absurdly easy. Including the module makes it so that this Doc class can act as a nice encapsulation of communication with Doc Raptor – giving us handy methods like post. Right below the include line, you can see the call to base_uri. That is a method that we get by including HTTParty, and allows us to set what the base url we will be hitting against will be – in this case, it is “https://docraptor.com”.

Then we get to the meat of this class (although there really isn’t much to it) – the create method. This method takes the document information passed in (we will go over what is passed in in a moment), and does a POST request of that data plus the api key against “/docs” (which is really “https://docraptor.com/docs” – because of the setting of the base uri earlier). What is returned is just the response from Doc Raptor, which, if all went well, is the created document.

So what is passed into create? A hash of a couple parameters to send to Doc Raptor – :document_content, :document_type, :name, and :test. You can read about these parameters in detail in the Doc Raptor documentation, but I will go over them briefly here. :document_content is the most important – this is the string of html that Doc Raptor will use to create the document, and is what we will spend most of the rest of the tutorial creating. :document_type is used to tell Doc Raptor what type of document to create – it supports creating both Excel and PDF files – “xls” and “pdf”, respectively. In this tutorial, we are just creating Excel files, so this will be set to “xls”. :name is just a name for the document for your reference (shown on the Doc Raptor account dashboard with the date/time the document was created). And finally, :test sets if Doc Raptor creates this document in test mode – test mode allows you to create documents that don’t count against your monthly limit, but are watermarked, so it is great when figuring out how you want a document to look.

Ok, so that is a bunch of text covering how to use that create method, but who reads text? You want to see some code! So let us get to generating some content to create an Excel file from.

Since Doc Raptor takes html, we might as well use all the tools at our disposal in ruby that make creating html easy. I’m talking about haml. If you haven’t heard of haml, you should go take a look – it is a very clean and easy to use markup language that can be used to produce html. We are going to take some data and render it with a haml template, producing html that we can give to Doc Raptor. Below you can see the ruby code that does the rendering:

We have an array of, literally, some data that we will be passing into the template. First, we open and read in the haml template (from a file called my_excel_template.haml (we will look at the contents of that file in a moment). Then we create a new haml renderer around that template. Finally, we render the template, and make the some_data variable available to be used inside the template as the variable supplied_data. The generated html is stored in the variable rendered_template.

Ok, so now we can take a look at this haml template. Haml is pretty easy to read even if you have never seen it before, but the folks at the haml website do a much better job explaining it than I ever could, so you should read through their tutorial if the markup below makes no sense.

Essentially, the code above is just describing an html table with some headers and then some rows of data generated by the data we passed in when rendering the template. So when this is rendered with that data, we get the html shown below:

So this is some pretty standard html, and will in fact render as a table if you throw it in a browser. There are a couple things to point out, though. The name property on the table is used by Doc Raptor to set the name of the sheet inside Excel – so in this case we will get a sheet named “My First Sheet”. Doc Raptor will also pay attention to the any style attributes to the best of its abilities – you can read the full set of supported styles in their documentation.

Ok, time to take this html and send it off:

We just set those parameters like we talked about earlier, call create, and write the response to a file. Nice and simple! The resulting spreadsheet for this example looks like the following:

Pretty sweet for just making html – and a lot nicer than trying to deal with awkward java libraries. Below is the ruby code all together:

And that wraps up this introduction to Doc Raptor! If ruby isn’t your thing, you can find other language examples on the examples page. If you have any questions or comments, feel free to leave them below, and I will do my best to answer them.

Remember back many moons ago when we posted a previous tutorial about Excel document creation? Specifically, this one. It worked, but if you take a look at it again, that code was painful. And ugly. And required hooking up ruby with a Java library called JExcelAPI using RJB – which, really, is not something anyone actually wants to do. So today we are going to take a look at something else (that I think) is a lot nicer/cleaner for Excel document generation: a new web service specifically for document creation called Doc Raptor.

As a disclaimer, I am one of the people who wrote Doc Raptor – so I apologize if I come across as too excited about it. In all honesty, I think I’d be just as excited if someone else had created the service – because I really hated integrating and using that Java library in every app that needed to produce Excel documents.

Enough talk about that, let us dive in and see how Doc Raptor works. The example here today is going to be in Ruby (because that is what I write most of the time now), but since Doc Raptor is just a RESTful webservice, you can easily make it work with the language of your choice. The high level overview is that you create html tables, send them as a POST request to Doc Raptor, and get back an Excel document. Below, you can see the Ruby code necessary for such a request:

First off, you need to get a Doc Raptor API Key – which is easy to do, you can just go sign up for the free plan, and it will be right there on the dashboard:

Below that you see that we are including the module HTTParty. HTTParty is a ruby gem that makes dealing with http connections absurdly easy. Including the module makes it so that this Doc class can act as a nice encapsulation of communication with Doc Raptor – giving us handy methods like post. Right below the include line, you can see the call to base_uri. That is a method that we get by including HTTParty, and allows us to set what the base url we will be hitting against will be – in this case, it is “https://docraptor.com”.

Then we get to the meat of this class (although there really isn’t much to it) – the create method. This method takes the document information passed in (we will go over what is passed in in a moment), and does a POST request of that data plus the api key against “/docs” (which is really “https://docraptor.com/docs” – because of the setting of the base uri earlier). What is returned is just the response from Doc Raptor, which, if all went well, is the created document.

So what is passed into create? A hash of a couple parameters to send to Doc Raptor – :document_content, :document_type, :name, and :test. You can read about these parameters in detail in the Doc Raptor documentation, but I will go over them briefly here. :document_content is the most important – this is the string of html that Doc Raptor will use to create the document, and is what we will spend most of the rest of the tutorial creating. :document_type is used to tell Doc Raptor what type of document to create – it supports creating both Excel and PDF files – “xls” and “pdf”, respectively. In this tutorial, we are just creating Excel files, so this will be set to “xls”. :name is just a name for the document for your reference (shown on the Doc Raptor account dashboard with the date/time the document was created). And finally, :test sets if Doc Raptor creates this document in test mode – test mode allows you to create documents that don’t count against your monthly limit, but are watermarked, so it is great when figuring out how you want a document to look.

Ok, so that is a bunch of text covering how to use that create method, but who reads text? You want to see some code! So let us get to generating some content to create an Excel file from.

Since Doc Raptor takes html, we might as well use all the tools at our disposal in ruby that make creating html easy. I’m talking about haml. If you haven’t heard of haml, you should go take a look – it is a very clean and easy to use markup language that can be used to produce html. We are going to take some data and render it with a haml template, producing html that we can give to Doc Raptor. Below you can see the ruby code that does the rendering:

We have an array of, literally, some data that we will be passing into the template. First, we open and read in the haml template (from a file called my_excel_template.haml (we will look at the contents of that file in a moment). Then we create a new haml renderer around that template. Finally, we render the template, and make the some_data variable available to be used inside the template as the variable supplied_data. The generated html is stored in the variable rendered_template.

Ok, so now we can take a look at this haml template. Haml is pretty easy to read even if you have never seen it before, but the folks at the haml website do a much better job explaining it than I ever could, so you should read through their tutorial if the markup below makes no sense.

Essentially, the code above is just describing an html table with some headers and then some rows of data generated by the data we passed in when rendering the template. So when this is rendered with that data, we get the html shown below:

So this is some pretty standard html, and will in fact render as a table if you throw it in a browser. There are a couple things to point out, though. The name property on the table is used by Doc Raptor to set the name of the sheet inside Excel – so in this case we will get a sheet named “My First Sheet”. Doc Raptor will also pay attention to the any style attributes to the best of its abilities – you can read the full set of supported styles in their documentation.

Ok, time to take this html and send it off:

We just set those parameters like we talked about earlier, call create, and write the response to a file. Nice and simple! The resulting spreadsheet for this example looks like the following:

Pretty sweet for just making html – and a lot nicer than trying to deal with awkward java libraries. Below is the ruby code all together:

And that wraps up this introduction to Doc Raptor! If ruby isn’t your thing, you can find other language examples on the examples page. If you have any questions or comments, feel free to leave them below, and I will do my best to answer them.

HTML5 is getting a lot of attention these days – especially when it comes to video. This tutorial is going to cover a feature added to HTML5 that I don’t think is getting enough attention – web storage.

Prior to web storage, most websites used cookies to store information on the client’s computer. Cookies, for the most part, work great for simple storage. They do, however, have one major drawback. If the user is visiting your site on two separate windows or tabs, information stored in cookies will be shared between them. To handle this case, the web storage in HTML5 has been split into two pieces: localStorage and sessionStorage. The first one works like cookies, saving information for an entire site (origin). The second one, sessionStorage, will store information for each origin but keep it isolated between windows or tabs.

Before we get started, I should note that not every browser supports web storage. Wikipedia is maintaining a pretty good list of HTML5 browser compatibility that should probably be consulted before using storage in a production environment.

Reading and Writing Values

Both mechanism use the same object as defined in the web storage spec, Storage. Let’s take a look at this interface.

Hats off the creators of this, as I don’t think there could have been a simpler interface for storing values. At its core, this is basically a dictionary mapping string keys to object values. For the most part, pretty much anything can be stored in here – as long as it can be cloned using the structured clone algorithm

Let’s take a look at how do use this, first using localStorage.

In this example, if the value hasn’t been stored yet, you’ll receive this alert:

The next time the page is loaded, you’ll now receive this alert:

As you can see, using localStorage is incredibly easy. This value will now be stored indefinitely on the client’s computer ready for me to retrieve whenever they visit my website again.

Using sessionStorage is just as easy. All we have to do is replace the object we’re using and we’re done.

The code is nearly identical to the previous code, however this time, if you open the site in two different tabs, you’ll receive the “No item found” message for each tab. In the previous example, the value existed for every new tab or window created.

One thing to remember when dealing with HTML5 web storage is that it does not cross browsers. The spec does not outline where or how a browser must store the data. Therefore if the user visits your site in one browser one day, then in a different browser the next, you will not be able to see values that were stored by the other browser.

Listening for Changes

The HTML5 spec outlines an event that client’s can attach to in order to receive updates whenever a storage (local or session) changes. At this point in time, however, I wasn’t able to get it working in Chrome (6.0.401.1 dev). I was, however, able to get the following code working in Opera.

In Opera, the storageChanged event will fire twice – once for when the localStorage is cleared, and again when the value is set.

Although we’re moving in the right direction, HTML5 still has a ways to go before it’s fully adopted. Web Storage has a great amount of potential in the future of web apps and I can wait to see what developers are able to do with it.