A few weeks ago, I invested in my very first Chromebook with the intent of writing a Chrome OS application for it. I purchased an ASUS Chromebook Flip. It’s a great little machine for using web based applications. In fact, I am writing this blog entry from it right now. One question I had though was, can I use this as a development machine? Well, it’s been kind of a mixed experience, so I’ll be writing about this here.
There are a few code editors available on the Chrome Web Store. I’ve highlighted what I think are the best choices below.
This editor is made by Google, so it seems like the most obvious choice to me. It supports developing applications using Dart and JavaScript. It’s actually quite nice. It has Git integration, it supports project work spaces, and you can deploy and run Chrome or web applications directly from the IDE.
The downside of this IDE is uncovered upon visiting its GitHub page.
Note: Chrome Dev Editor is no longer being actively developed. We’ll do our best to merge your pull requests.
This editor is more akin to a text editor, but with syntax highlighting for various programming languages. It also has limited Git integration, and supports editing code files in local or remote folders.
This editor is also basically a text editor with syntax highlighting. From what I’ve read, it’s goal is to be just that, nothing more, nothing less. This means it does not have support for things like Git integration which isn’t necessarily a bad thing. I’d personally rather have a great editor instead of an okay editor w/mediocre Git support.
Unfortunately, at the time of this writing, I find writing code with all three of these editors to be a very awkward experience. With all three of these editors, if you actually want to execute the code you write, you are pretty much limited to using JavaScript, and HTML, or Dart. If you are okay with this, then fine, you are all set! If you are using something like TypeScript, it’s a bit more involved to make this work. This is where Linux comes in.
Crouton is a tool that essentially allows you to install Linux on your Chromebook. Once installed, it lives side by side with Chrome OS. This means you can install whatever tools you enjoy using on Linux there, but still have access to the files or projects you create in the Chrome OS environment.
In my case, I wanted to be able to use the latest versions of Git, Node.js, npm, and TypeScript. By default, Crouton installs Ubuntu 12.04 (Precise Pangolin). This is problematic when it comes to installing the latest version of Node.js, because it comes with a C++ compiler that isn’t capable of building the latest V8 JavaScript engine. They attempted to fix this by building node packages with Clang. Unfortunately there are no ARM builds for these distributions which means I cannot run them on an ASUS Chromebook Flip. More information about this is available here.
Fortunately, there is a simple workaround for this problem. Install Ubuntu Trusty Tahr instead.
sudo sh ~/Downloads/crouton -t xfce -r trusty
After doing so, you can install Git, Node.js, npm, and TypeScript on the Linux environment like normal.
Once you have Linux installed, you can now edit your TypeScript code using one of the editors I’ve already mentioned. When you want to build your application, you can either use the TypeScript CLI from a Linux command line in a Chrome browser window, or run it from a command line in the Linux GUI.
Optionally, you can also install a coding IDE to the Linux environment if you’d like. However, in my case since I’m using an ARM Chromebook, I’ve found that it is more difficult to find ARM builds of my favorite editors.
Know of a better way to develop applications on a Chromebook? Comment below!
Various people have given me positive comments on the non-traditional recipe I use to make pork ribs. Credit for this recipe goes to my friend John who originally told me how it was made. That being said, I’ve decided to post the recipe here since many people have asked me how to make it.
The Supplies and Ingredients
Supplies
BBQ Grill
Mesquite charcoal
Knife
2 Big bowls
Spoon
Measuring cup (1 cup)
Plastic cutting board
2 big plastic bags
Ingredients
2 racks of St. Louis style pork ribs
1 piece of ginger root
3 small yellow onions
6 limes
Minced garlic
White vinegar
Soy sauce
The Marinade
Start by setting out all of your ingredients so that you may bask in their glory. Pictured below is everything you need to make this recipe.
Chop up the onions into big chunks.
Chop up the ginger.
Slice up the limes.
Open the jar of pre-minced garlic.
Add 2 cups of soy sauce to your bowl.
Add 1 cup of white vinegar to the same bowl.
Dump all the stuff you previously chopped up into the bowl.
Add a spoon full of minced garlic to the bowl (you remembered to open the jar right?).
Your bowl should look similar to this one now.
Mix that stuff up.
Taste it. It should taste like all the stuff mixed together.
You did it! Congratulations, your marinade is now complete. Set the bowl aside, and let’s get the ribs ready. Repeat the following steps for each package of ribs.
Open the package of ribs, and place them on a plastic cutting board.
Take your knife and lodge it under that sinewy nastiness on the underside of the ribs.
Pull that nastiness off, and toss it.
Split each rib, then cut the whole rack in two.
Put a few cups of marinade into a plastic bag.
Add the ribs to the plastic bag.
Put the sealed plastic bag into a big bowl. Then, repeat all previous steps for the second rack of ribs.
Put them in the fridge, and leave them there overnight!
The next day…
I prefer to cook the ribs hot and fast at first, charring them. Then I place them offset from the fire for a while to finish. You can optionally baste the ribs with the marinade while they are cooking, or give them a full dunk a few times while cooking. Doing so will result in tastier ribs.
It’s easy to get lost in the hustle and bustle of every day life. Occasionally, I like to take time out of my evenings away from my career, my personal obligations, etc, and look up at the sky. It’s extremely humbling to reflect on how small we are in the universe. We are literally just a small speck of blue in the sky. A speck of blue that can probably barely be seen by just the other planets in our solar system.
Unfortunately, light pollution, and extreme distances of thousands to millions of light years obfuscate what you can actually see in the sky with the naked eye. That’s why it’s great to have a decent telescope and a digital SLR camera. The following are images I put together using photos taken via my Celestron C8-NGT Telescope, and my Nikon D60. Most of them consist of 20-30 second exposures stacked together using lynkeos.
This is a photo of a friend of mine w/our Telescopes. We’ve got our scopes pointed at the sun, and are using Mylar filters to take pictures of the transit of Venus.This is a photo I took with my iPhone 4S of the Transit of Venus. I didn’t yet have my SLR.Jupiter is the largest planet in the solar system.Saturn is the second largest planet in the solar system.The Orion Nebula.Andromeda Galaxy. This is the nearest Galaxy to our own, The Milky Way.Sirius is the brightest star in our sky.
As I can best recall, 1995-1997 was around the time I was introduced to the internet, the web, internet relay chat, etc, etc, etc. Prior to this, my brother and I had been avid Bulletin Board System (BBS) users. I had always wanted to run my own BBS, but being a kid, I just couldn’t afford myself the opportunity. So, when we first got dial up internet access via flash.net in Houston, TX, I quickly discovered the web, and began wondering how I could make my own website. Doing some of my own research via early search engines like AltaVista, and WebCrawler, I discovered a nice little tool called HotMetaL. It was with this tool that I put together my very first website, “SoftShoe Programmer’s World.”
Now, this was in the age of free website services such as Geocities, Xoom, etc. I quickly setup shop at http://www.geocities.com/TimeSquare/Arcade/6361 and proceeded to make the best use out of the one free megabyte I’d been allocated. Since generic QBasic programs are incredibly small, it was pretty easy to have a small bit of content up at all times. In between playing Doom and salivating over the upcoming release of Duke Nukem 3d, I’d be working on my website. In fact, my friend Pete and I decided to be super nerds and compete about who had the best website.
Unfortunately, my original website has been forever lost. I do have a fairly vivid memory of it though. It featured black square buttons I’d drawn in paintbrush with red text for their labels. You could navigate between a few pages of information by clicking these buttons. Fortunately, I do happen to have backup copies of pretty much every website I made after that. This includes various updates to “SoftShoe Programmer’s World” among other creations. Most of these websites are in a pretty decrepit state, as their image tags relied on absolute addresses of things actually stored on Geocities. Other tags rely on images provided by services that disappeared well over ten years ago. Nevertheless, I’ve fixed one up and have taken a few screenshots of it for your amusement. 🙂
The Landing Page
Qbasic Game Downloads
Links to other Qbasic Websites
This site also features a nice little biography written by the 15 year old version of me. I’ll be turning 29 next week, so that means I wrote this about 14 years ago. I’ll be wrapping up this post by leaving you with those words… 🙂
“Well first of all my name is Robert Shoemate, and I am 15 years old in the 9th grade. I have been programming for about two years. The first programming language I ever used was the simple Basic language on the Commodore 64. My Brother taught me some of the simple commands, and I thought it was pretty cool! The first program I ever made was a simple multiplication program. The second programming language I used was one called Amos. It was made for the Commodore Amiga and it was one of the coolest programming languages I have seen. I wasn’t that good at programming in this language because I was a little kid and I didn’t want to read the manual or anything. When I got my Packard Bell Pentium 75 in 7th grade I started expirementing with Qbasic. I started out making small simple programs with just text and no graphics. Then one day me and my best friend Jamy Ryals started to make a game called Lamb Hunt. This was my very first game that I ever used graphics with. I dont remember what grade I was in when I made this game, but I think I was in the beginning of the 8th grade. One day in 8th grade when one of my classes went to the computer lab I went into Qbasic and programmed a simple chat program for the networked computers. The teacher did’t like this program very much, but everyone I knew thought it was a cool program! After using Qbasic a while I was introduced to the language Visual Basic. This language was a lot like Qbasic except it was written to run in windows and it was a more flexible programming language. I havn’t really written anything good in this language, besides an extremely crappy version of Lamb Hunt 1 for Windows. Finally I was introduced to Visual C++. I am currently learning C++ it is one of the hardest to use languages I have seen, but its the best language out there, and ill be able to make awesome programs with it after I learn it. The SoftShoe name you see on this page a lot was made up by my Dad. He used our last name “Shoemate” and turned it into a cool sounding software company name…”
Sometime around 2003, a small startup called HPT-Interactive was formed. The founding members included my brother Matt, and two friends of his, Eric and Dave. As far as I can remember, the group released two game titles to the Windows Mobile Pocket PC market that was around at the time. The first was the HPT Game Pack that included renditions of Break Out, Space Invaders, and Asteroids. The more notable second title was a little gem known as Blade of Betrayal. As my brother Matt has put it, the team originally wanted to make a “run, jump, and gather coins” game. However, as time passed, the project ballooned into a full-on platform game featuring a comic book style story line, various zones, enemy types, etc. In order to make a game like this possible, another friend of mine was brought in to help out, Billy. Billy is a fantastic artist with a natural born talent for game design, so he worked with the team to flesh out story lines, provide artwork, etc.
Blade of Betrayal was released later that year and was very well received by the Pocket PC community. You can still find some of the original reviews online. I’ve provided some original screenshots of the Pocket PC edition of Blade of Betrayal below.
Unfortunately, though Blade of Betrayal was well received, it did not perform financially very well. Due to this, the team eventually broke apart as its members began to focus more on their professional careers. Eric and Billy stuck with it though, and began working on a version of Blade of Betrayal for the ill-fated Tapwave Zodiac. Yet again, another unfortunate event occurred, Tapwave went under during the development of the port. If you are unfamiliar with the Tapwave Zodiac, it’s quite understandable since it wasn’t around very long at all. You can, of course, read more about it on Wikipedia. I’ve actually got Eric’s old Tapwave Zodiac, and occasionally power it up for amusement.
For several more years, the source code to Blade of Betrayal sat lifeless on a hard-drive in Eric’s apartment. In fact, at one point, he’d even believed he’d lost the original source code. During this time period, being the brother of one of the original developers at HPT-Interactive, I actually sparked up a friendship with Eric and we’d been toying with the idea of developing a new game. Eric, always an engine programmer, would provide me with source code to whatever his latest game engine was he was working on and I’d devise some sort of simple concept for a game. We never really worked on anything big. In late 2008, that all changed for us though.
It was Winter 2008, in Houston, Texas and various friends of mine were in from out of town. We’d all decided to meet up at the Flying Saucer in downtown. After spending some time hanging out with friends and having a few drinks, an old friend of mine arrived, Billy Garretsen. Billy and I go way back. As far back as Middle School I can remember tossing around game ideas and concepts with him, but never really creating anything. Well, Billy and I got to talking, and of course, yet again, we were throwing around more game concepts. I’d mentioned that I was spinning up various projects with Eric, and this really perked Billy’s interest since they hadn’t seen each other in a while. Eventually, we came to the topic of the iPhone, and how a brand new SDK had just been released allowing developers to write native applications for the device. We thought, “What could be the quickest turn around on a game for the iPhone that we could put out?” Of course – the consensus was, Blade of Betrayal.
As soon as I got home I contacted Eric and asked him how plausible he thought the idea was, and told him to find the source code. It didn’t take much for us to reach the same mindset – after all, developers were releasing apps like crazy for the iPhone and were all getting rich, so we thought we’d give it a shot.
Now, the ironic part about all of this is that I’d been a Mac hater for years. It didn’t take much for me to start spouting off non-sense about how this or that sucked on the Mac. Yet – I found myself in an Apple Store with Eric purchasing a Macbook and was eating my own words. After working with the computer for the past 3+ years, I’ve come to terms that it is actually a darn good machine with a darn good OS. This experience has taught me to look at both the good and the bad of all devices and operating systems. Now this doesn’t mean I accept the culture that comes along with owning a Mac and frequenting the Apple Store. I found it quite ridiculous after I purchased my Macbook and was waiting for Eric when one of the Apple Store employees did the double finger point at my Macbook and said, “You know what’s awesome? That’s awesome!” *sigh*
In fact, I find the so-called culture created by Microsoft, Apple, the Linux community, etc, etc all friggin ridiculous. Microsoft is a nerd trying much too hard to be cool, this resulted in one of the creepiest parties I’ve ever been too. Linux claims they have great community support, and when you ask for it they treat you like the scum of the earth. That being said, this is a rant for another day… 😉
Moving on, what was I talking about? Oh! Blade of Betrayal. So once Eric and I purchased our Macs, we began learning the tools and the language, XCode and Objective-C. Coming from Visual Studio, we honestly found them to be a bit weak, but we eventually developed a love-hate relationship that has worked out for the best (These days, I actually quite enjoy the flexibility of Objective-C).
Now, the outstanding thing about writing games and software for the iPhone is that you can actually write the majority of your code in C or C++. This was great news for us, because Blade of Betrayal was written entirely in C and C++ code. Our first major hurdle was to move all of the code into an XCode project containing a simple Objective-C layer, and fix all the compiler and linker errors. This surprisingly took less time than I expected as I think we had something displaying on the screen in about a week or two.
One of the more amusing aspects of porting Blade of Betrayal to the iPhone was our tooling. The original Pocket PC tools had been written in Borland Builder around 2003. We encountered a problem with our images where they needed to be sized in powers of two to work with OpenGL ES on the iPhone. Now I didn’t really know anything about Borland Builder, but I did know C#. So I began porting a lot of the Borland Builder code over to C# so I could write additional code to make our images powers of two. This eventually resulted in a hybrid mess of half-assed poorly written and maintained tools. Trust me, you don’t know what unintuitive is until you’ve encountered these tools. Amazingly though, we continued using them through games like Bumble Tales, and Headstone Harry. The tools may be aweful, but they do work.
So anyways, as the weeks went by, our code began coming more and more together. We eventually pulled a few all-nighter weekends at Billy’s place. Then, some how, after three months of work, the game was done. We proudly submitted it to the app store, and waited for the millions of dollars to start rolling in.
Unfortunately though, things just don’t work that way. 😉
Blade of Betrayal was only moderately successful, if you could consider it as that. It was nice to be able to afford iPads when they originally came out, and a few other things, all on money our game had earned. Unfortunately, the millions of dollars are only reserved for the lucky few who make a hit out of an extremely original idea. I am proud to have worked on it though, it was a three month project I put my heart and soul into with two very good friends.
If you are interesting in checking it out, Blade of Betrayal is available for iOS and Android devices.
I’ve been using computers since the late 80’s starting with the Commodore 64, then transitioning to an Amiga 600, then on to Windows PCs. The thing I’ve always enjoyed most about computers is that what you can create on them is only limited by the bounds of your imagination. Be it artwork, music, or games, so long as you have the determination and the drive to accomplish something, you can create it.
I’m a pretty avid programming hobbyist myself, and ever since making the transition to the DOS/Windows PC back in 1994 I’ve made a habit of hoarding all of my creations. The majority of them have spent their lives in a CD folder whose primary purpose is gathering dust. In looking for a purpose to this blog, I thought it might be fun to dust off this old CD folder and talk about several of my old projects along with those that I am currently working on today. Since this is my official first post, what better to talk about than my first graphics based game? Prepare to be underwhelmed. 🙂
When I got my very first DOS/Windows PC, one of the first things I was introduced to was Microsoft QBasic. This was my first real experience writing code that actually made things happen on a PC. In between playing Doom and Space Quest, I frequently opened up QBasic and wrote simple text based games. I have tons of these text based games still, they aren’t anything pretty, however, I’m sure I’ll be talking about them at some point.
Space Quest IV: Roger Wilco and the Time Rippers
Anyways, I think it was around 1996. I was hanging out with my friend Jamy when my brother, Matt, challenged me to write an actual game that made use of graphics. Graphics!? This indeed sounded like a daunting task. I was aware of the DRAW command at the time, however, I hadn’t really done all that much with it. Essentially, the DRAW command works as follows.
You set a screen mode, my screen mode of preference was Screen 12. Then to actually draw something, you specify something like:
PSET (1, 20), 15
DRAW “U15R5D15”
PSET sets the color, and position at which to begin the drawing. From there, it’s a lot like an Etch a Sketch. The DRAW command as seen draws UP 15 pixels, RIGHT 5 pixels, then DOWN 15 pixels. If you replace the hard values of PSET with variables, you can essentially control and/or animate the position of the drawing.
The problem with the way this works though, is if you update the position of the drawing in real time, it leaves a trail of junk behind on the screen. This is a problem that is easily solved today through the use of a technique called double buffering, however, I was a kid, and I pretty much had to invent a technique for preventing this artifacting from happening.
The most obvious solution to this problem would be to clear the screen between drawings. Bad idea. This leads to some pretty psychedelic flickering since the screen you are clearing is the screen the player is looking at. Since I had no idea what double buffering was, the brilliant concept I came up with was to just draw over the previous position of the object in the background color before redrawing it in the correct color at the new position. Gotta start somewhere right? 🙂
After overcoming this supposed technological boundary, Jamy and I came up with a concept for a simple game that could utilize this technique. This game eventually became known as “Lamb Hunt.”
Lamb Hunt
The primary goal in Lamb Hunt is to rack up points by shooting Lambs, represented as squares, using the laser gun at the bottom of the screen. When you shoot a Lamb, if the collision check works (seriously), it explodes giving you points. Lamb Hunt makes use of the drawing technique described above, along with some incredibly rudimentary “collision detection.” Don’t worry, no actual Lambs were harmed in the making of this game.
If you are interested in checking out the source code to Lamb Hunt, you can get it here. As for running it, you’ll need to get your hands on a copy of QBasic and DOSBox. Google knows where those are. 🙂
Robert's Programming Blog 