Block Comment

Alright, installment two of our clipboard cache project.

This whole project centers around the clipboard. So what a great place to start!
We are at a disadvantage. Arggg, already negative! I should explain. Microsoft has some built in features that would make this project easier. For windows, we could add our application into a chain of other applications that are all notified when any action happens regarding the clipboard. This would include copying text into the clipboard, which is exactly what we are going to need to watch out for. However, since we are trying to develop a platform independent application (and we’re not developing in .NET), we don’t have access to this functionality. Cripes. What is the answer? Busy waiting. <Game show Fail sound here…> Wa..wa..wa….
Ah, a chance for an aside: “busy waiting”, or “polling” is a concept in computer science that is a nice way of saying bug the thing that you want to get something from until you get it.
An illustration would fit great here. Let’s say that you are on a long car ride, and you have a five year old child in the back seat. The child, of course, does not want to interrupt the operation of the vehicle, or distract you the driver in any way, however, they also want to know when they have arrived where they are going. Naturally, the answer to this dilemma is an event based architecture. The child says, before the car even starts moving no less: “Father, please inform me when we have reached our final destination. I will play quietly with my GI Joes until you have instructed me to do otherwise.” The event of arriving at where you are going causes the child to be informed of something that is meaningful to them. What a perfect world of family vacation bliss! Any of you out there with children know that this is seldom (uh, try never) true to real life. How about this scenario instead:

Car in driveway.
Child- “Yeah! Vacation!”
You - “Yeah!”
Car pulls onto street in front of house.
Child- “I’m bored!”
You - “Play with the new GI Joe I just bought you.”
Car pulls out onto main road.
Child - “How long is this going to take?”
You - “How about I just let you know when we are close…”
Car merges onto freeway.
Child - “Are we there yet?!?!”
You - “no”
Every other step of the way - “Are we there yet?!?!”
You - “no”
…
Child - “Are we there yet?!?!”
You - “I will pull this car right around and take us home if you don’t stop asking me that!!!”

That my friends, is busy waiting. Thankfully, computers are much more patient that we are, so they don’t mind when we ask them the same question repeatedly. One very important thing to consider though, is that a computer is not like an annoyed, although loving parent. They are more like a taxi cab driver. You can ask as many questions as you want, and they will still happily take you to where you are going - if we can pay there fare. The fare in this case is that we have to use resources (namely performance-expensive CPU cycles) to perform the busy waiting.
So with that, it brings us to our application model- we are going to have to ask the clipboard constantly if it has changed or not. Annoying, but necessary for what we want to do. Well, lets pay the piper, and get started a-coding!

Some time ago, a good friend of mine introduced me to a little program, which was tastefully named “Clipomatic“. It was a simple idea, basically a program to keep track of the history of text you’ve cut or pasted since the program was started running. There are more features to Clipomatic, but that is the so called meat ‘n’ potatoes of it.
This software was produced by Mike Lin, whom I am in no way affiliated with, and can claim no credit for, or contribution to Clipomatic. That being said, there is no way that Mike Lin could have produced Clipomatic without gross amounts of help from me. Just lol-ing ya, the first statement is true- I had nothing to do with materialization of Mr. Lin’s excellent idea. I will, however, copy it to the T, for my own personal gain, at least until I am bored with the idea. Let’s see if I can get some blogging miles out of the deal while I’m at it!

Maybe I’ll actually get a comment or two on the article that isn’t trying to sell prescription medication or promote a web site of ill repute. Probably not.
That being said, I will be walking the reader through the creation of my own clipboard history tacking thingy…er Automated clipboard caching mechanism- ya that sounds better. The main challenge here is that I would like to develop the program in Java, so that it can be…uh…”effortlessly” (right) ported over to Linux, which is the operating system that I use when given the choice, and not wanting to watch streaming movies from Netflix…or synch my iPod…or, actually do anything that involves sound or video, but that is all for another article (maybe “Linux, the best practical operating system that is built perfectly to work for everyone, that is in a small subset of computer users” - did I tell you I can market things I love very badly when given the chance? If not, now you know…).
Anywho, on to writing a useful piece of cross platform compatible software!
Hang on for a wild ride- talk nerdy to me, baby!

OK, so it has been approximately eight months since the last iBack post- have you enjoyed all of the amazing content I have posted since then? Ya, I know- a big let down. I could rail on and on about having allot to do, blah, blah, blah…but I would rather focus on the brighter side, now you can enjoy the second generation of iBack!

Welcome to iBack, G2- Look back soon for some new posts. I’m not sure if I’m going to continue the design series right away, we shall see. Feel free to add any input to the direction you would like to see (either one of you). Thanks! Check back soon!

OK, so it has been awhile since my last post- thanks for bearing with me!

Life gets busy, and the design series is taking more time to put together than I originally thought it would. So in lieu of finishing that series, I am going to change topics for a bit- but don’t worry, the series will not go unfinished.

With modern software development, an application is rarely created completely from scratch. There is a plethora of libraries, plugins, and components that can be leveraged to ease the workload. This has become such a part of our way of thinking, we often don’t notice it anymore. I know that I have found myself grumbling about challenges associated with configuring an application server- without taking the slightest consideration of how difficult and involved it would be to create an application server from the ground up. Although this is an extreme example, it illustrates the point.
With all of these components available for us to use, it changes the way that we engineer software. We have to take into account the advantage of using code that someone else wrote, while also not forgetting the learning curve of the API that comes along with each one.

This changes the idea of modeling our software in clay, or rather from an unformed lump of clay at least. It is almost like we are putting together pieces of the system that fit together nicely, like just like a child (uh…a child…right) might play with a bucket of legos. But we are still need to configure and shape these pieces to work seamlessly together. It is more like we are developing with preformed pieces of clay that can be used to construct a larger system. This concept could be thought of as using “Claygos” to model and develop our system.

For example, lets say that we are going to create ourselves a bright, shinny, and profitable AJAX driven web based application. When designing the system, we already have many, many components to consider using- and consequently learning the APIs for.

So lets start with the what the users will be interacting with. We should think about our user interface design. We could develop all of our nifty AJAXy interactions with the user in JavaScript by ourselves, but why do that, when we can find an easy, out-of-the-box solution that can offload allot of that work for us. There is an ever growing community of user interface AJAX frameworks to choose from. There is the Dojo toolkit, and old time favorite. Then there is the Yahoo UI library- backed by a large corporation that can afford to develop quality products. There is also JQuery, a solid AJAX framework, with many advanced user interface features. But then, there was that time that a friend showed me a site that used Mootools, which had some great visual effects. Oh, and there is the Prototype framework, a favorite in the Ruby on Rails community…and I hear that if your going to use Prototype, then you can add allot of really cool visual effects in your UI if you take advantage of the Script.aculo.us library as an add on. And oh yeah, there is also ExtJs, a library that extends the Yahoo UI library, Jquery, and Prototype. Hmmmmm. This is alot to take in. All of a sudden we have allot of research to do in order to find the right “easy, out of the box” solution to our user interface issues.

BTW- click the comic to view it in at a larger, more readable size.

OK, so lets take a break for a minute from our user interface design and take a look at some of the fundamentals of how we are going to process our data on the server-side. Ah, good ol’ fashioned server side programming. For sake of argument, lets say that we have already decided to develop our application with Java. Lets get started! Well, we should look at any components that will make it easier to process our data, and transfer that data back to the client AJAX style. We don’t want to go reinventing any wheels here do we?
Oh look, there are some choices here too. Should we use DWR, which allows us seamless communications between the server and the client, which hides allot of the AJAX magic? Also, the Google Web Toolkit looks interesting- it takes Java code and compiles it into compatible JavaScript code for use on the client side, which would assuredly alleviate some of the headaches associated with traditional AJAX development. I also remember running accost a project called ThinWire, which seems to be able to produce some impressive results. Yup, that’s right…more reading and possible API learnin’.
So with all of these rich choices out there, and a gang of fanboys (and girls) following each one of them around singing their praises, which ones do we choose to make our application the best that it can possibly be? Also, how can we create mock ups that represent how these external components will make our application look and feel.

These is the question that we will attack in the next section of this series.

Beginning in the 1920s, the majority of automobiles that have ever seen production have been modeled using clay during the early stages of their development. This is a process that was pioneered by Haley Earl during his career at General Motors, where it was met with great success.
The whole purpose of this process was to show what a tangible product would look and feel like before steeping the production team into the expensive and intense development of that product.

In any project, the earlier that new design changes are introduced, the cheaper they are to successfully implement in the final product.

General Motor’s Designers and Engineers adopted the clay modeling technique many years ago to help them ensure the final product was a success, and more importantly, that the end product ended up being what they set out to create.

So, what do cars and clay have to do with software, you may ask? Well, the same principles described above can be seen in software engineering. The “clay” that we use to represent our software products often consists of data flow diagrams and user interface sketches, among other things.

In the next few posts, I hope to be able to outline an effective process for creating a “clay” model of our software before we direct a team of talented (and expensive) developers down a path that we may find later was paved with incorrect choices.

Modern day Designers and Engineers still take advantage of the clay modeling technique for automotive development.

Well then.

As modern day software engineers, should we (and how can we) model something that is so inherently intangible as software? I am going to do my very best to convince any readers that this is not only a helpful, but crucial step in the development process.

Any commentary is invited from those that have experience in this area, or anyone else that would like to add to what I have here- the more the merrier!

Welcome to the blog!

My name is Chris Arnold, and I am a software developer for a company in the Portland, Oregon area. This blog will be a platform for all of my personal thoughts and opinions to springboard off of into the rest of the world. Feel free to leave any comments you may have, I value and feedback- be it positive or very positive.

The topics presented here will be general in nature, but will all be related to my interests somehow. This means that most posts will be related to technology in some form or another. Feel free to let me know if there are any topics of interest that you think deserve commentary.

Welcome, and check back often!