For the last several months, I've been following the progress of Wolfire Games - an independent game developer who is taking a different approach to game design. They maintain an active blog, detailing their progress with their newest game as well as articles on game design and theory. Yesterday they released their first game Lugaru as an open source project. For those reading this that don't comprehend what that means, (I'm looking at my sister - my only subscriber) it means that the foundational code that was used to create the game has been posted on the web with the intention that it be read, changed, improved, and used!! Normally, that is a closely guarded company secret, but some will release it for various reasons. The motivation for Wolfire releasing the source of Lugaru is a commitment to continue being awesome!!
I spent some time today reviewing their code. It was the first time I had looked at the source for a decently sized application. Opening a few files, I began to pick up on their coding style and design. Over the last year, I've privately studied the concept of refactoring, the process for improving the design of existing code. My hope is that I can use those concepts to improve the design of Lugaru and use this blog to document my thoughts and progress. Here we go...
Wednesday, May 12, 2010
Saturday, June 13, 2009
SOAP vs. REST
A quick apology to all the family members that are signed up to this blog. I promise to resume personal musings soon!
My class on Service Oriented Computing is discussing two paradigms of web architecture - SOAP (Simple Object Access Protocol) and REST (Representational state transfer).
REST is an architecture is a style that is used heavily throughout the web. Once we spent a lecture learning further about this and looking at examples, I was blown away at how often it's used. It would be like listening to a lecture on bricks and the types of bricks and the intricacy of brick laying and then stepping outside and look at a building. You're blown away at the new perspective you have for something that you took for granted your whole life.
REST is very simple. It's principles, (blatantly lifted from wikipedia) are:
At the time I read about SOAP in Chapter 4 of "XML, Web Services, and the Data Revolution," I thought to myself, "this seems very straight forward." SOAP uses the http transfer protocol with an XML payload. The payload, in turn, has a similar structure of an optional header plus a body - Easy (at least in theory.)
SOAP services require this structure for requests which isn't as easy to do as REST.
My class on Service Oriented Computing is discussing two paradigms of web architecture - SOAP (Simple Object Access Protocol) and REST (Representational state transfer).
REST is an architecture is a style that is used heavily throughout the web. Once we spent a lecture learning further about this and looking at examples, I was blown away at how often it's used. It would be like listening to a lecture on bricks and the types of bricks and the intricacy of brick laying and then stepping outside and look at a building. You're blown away at the new perspective you have for something that you took for granted your whole life.
REST is very simple. It's principles, (blatantly lifted from wikipedia) are:
- Application state and functionality are abstracted into resources
- Every resource is uniquely addressable using Uniform Resource Identifiers
- All resources share a uniform interface for the transfer of state between client and resource, consisting of
- A constrained set of well-defined operations (HTTP GET, POST etc)
- A constrained set of content types, optionally supporting code on demand
- A protocol which is:
- Client-server
- Stateless
- Cacheable
- Layered
At the time I read about SOAP in Chapter 4 of "XML, Web Services, and the Data Revolution," I thought to myself, "this seems very straight forward." SOAP uses the http transfer protocol with an XML payload. The payload, in turn, has a similar structure of an optional header plus a body - Easy (at least in theory.)
SOAP services require this structure for requests which isn't as easy to do as REST.
Big Design Lecture #6
I had intended to attend Ryan Plesko's lecture on "Designing for People and Machines" which might have led to some Web 2.0 discussion. Unfortunately, there was a mix-up in communicating the time or date to the lecturer and he wasn't there. Instead I went to Thor Muller's lecture on "Work Like the Network."
Everything about this lecture has already been said on my post about lunch.
Everything about this lecture has already been said on my post about lunch.
Big Design Lecture #5
Lecture #5 was "Presenting Your Ideas in Highly Charged Political Situations" by Adam Polansky. He made it evident that the title of lecture was chosen by a third-party AFTER he put his presentation together. Whereas the title might lead you to think he'd be teaching you methods for making your boss think he came up with your ideas, this was nothing more than how to organize your presentations.
Although this was a flagrant abuse of false advertising, it was one of the most applicable tracks I attended. The most important thing I took from the lecture was minimizing the amount of information you put on a slide. I think all too often, people pack a slide with so much text that they just read the slide to the audience or could sit down and let the slide do all the talking for them. Either way, they miss the important detail that a slide show assists you the presenter. People came to hear YOU, not your slide show!
Although this was a flagrant abuse of false advertising, it was one of the most applicable tracks I attended. The most important thing I took from the lecture was minimizing the amount of information you put on a slide. I think all too often, people pack a slide with so much text that they just read the slide to the audience or could sit down and let the slide do all the talking for them. Either way, they miss the important detail that a slide show assists you the presenter. People came to hear YOU, not your slide show!
Big Design Lecture #4
I took a break during the fourth lecture to collect my thoughts and recover from the UX excitement. I used the time to create my Twitter account and then read the wikipedia entry on "Twitter" to try and understand what I got myself into. I still don't understand the hype (which coincidentally is my 6 word summary of Big D).
I caught the last few minutes of "Future Prood Designs + Presentations for THIS Generation" with Robert Wiseman. The only points I took from there was the idea of allowing your customers to decide your design. He used the image of employees walking across a grass field to work (what kind of business are we talking about?!) and then paving the rabbit trails that emerge. He didn't have an example of an application doing this, though.
I caught the last few minutes of "Future Prood Designs + Presentations for THIS Generation" with Robert Wiseman. The only points I took from there was the idea of allowing your customers to decide your design. He used the image of employees walking across a grass field to work (what kind of business are we talking about?!) and then paving the rabbit trails that emerge. He didn't have an example of an application doing this, though.
Big Design Lecture #3
It's interesting how otherwise innocent words can have profound meaning in professions. "Code Pink" for example comes across as almost a playful alternative to it's more serious big brother "Code Red." You don't see many medical dramas declaring Code Pink - imagining it is kind of silly. Yet if you walked into a hospital and ran up and down the halls yelling "CODE PINK!" you'd scramble the entire building. Code Pink in medical jargon means an infant has been stolen. Pretty serious...
Likewise in embedded programming "Design Patterns" holds a very reverent meaning due to the book of the same name written by the Gang of Four. Noone casually sits down to read it - they meditate on it!
Therefore when I saw the third lecture at Big Design would be on "Latest Design Patterns That You Should Know" by Bill Scott I penciled it in as a must-see. It wasn't as profound as those words would have it seem. These patterns were not as hard to understand and visualize as say the Visitor Pattern. Bill had lots of them that you would think would be common sense, yet he had lots of real-life examples of websites implementing just the opposite resulting in 'anti-patterns.' This form of presentation ("Here's what NOT to do") really connected with me. I enjoyed the talk, though I don't know if it's directly applicable to work.
Some examples of his design patterns:
1. Make it Direct
2. Keep it Lightweight
3. Stay on the page
4. Offer an Invitation
5. Show transitions
I would have taken more detailed notes, but the lady sitting in front of me turned around and scolded me for, "Doing work during the presentation." When I explained I was taking notes, she said the typing was very distracted and that I was a VERY rude person, despite my repeated apologies.
Likewise in embedded programming "Design Patterns" holds a very reverent meaning due to the book of the same name written by the Gang of Four. Noone casually sits down to read it - they meditate on it!
Therefore when I saw the third lecture at Big Design would be on "Latest Design Patterns That You Should Know" by Bill Scott I penciled it in as a must-see. It wasn't as profound as those words would have it seem. These patterns were not as hard to understand and visualize as say the Visitor Pattern. Bill had lots of them that you would think would be common sense, yet he had lots of real-life examples of websites implementing just the opposite resulting in 'anti-patterns.' This form of presentation ("Here's what NOT to do") really connected with me. I enjoyed the talk, though I don't know if it's directly applicable to work.
Some examples of his design patterns:
1. Make it Direct
2. Keep it Lightweight
3. Stay on the page
4. Offer an Invitation
5. Show transitions
I would have taken more detailed notes, but the lady sitting in front of me turned around and scolded me for, "Doing work during the presentation." When I explained I was taking notes, she said the typing was very distracted and that I was a VERY rude person, despite my repeated apologies.
Big Design Lunch
By this time I was ready for a break. As an embedded engineer I'm in the business of writing black boxes where numbers go in and numbers go out. There's no "user experience" and no customer I'm trying to pull in. I got to be honest, the first two lectures left me physically shaking after hearing how bad people are trying to suck me in to their product.
Needless to say, I needed a break. The Big Design conference catered boxed lunches. I grabbed one and set off to find a conversation to be a part of while I ate. The topic among my classmates was either how we finished up the last class or how Frailey's death-march of a project was wrapping up - neither one of which I had the stomach to sit and listen to. Feeling particularly brave I walked up to a table with two guys my age and asked if I could join them. They eagerly agreed and I sat down. Turns out these two guys were Garrett Dimon and Thor Muller - two speakers at Big D. If I was hoping for a light conversation that helped bring all this into perspective and let me digest the last three hours of lecture, it wasn't going to happen. At one point it occurred to me that these two (particularly Thor) talked really fast and non-stop. The conversation was all over the place. At one point I gathered Thor was a carear business starter - building a small company and selling it... starting another. He must be terribly important and very rich, but not much of a listener.
At one point he asked me what I thought of 'all this', (I assume he meant the last hour of hyper-babble) and I got the impression he was only using this as a launch pad to change the subject. I said I was an imbedded engineer who was on assignment at the convention. The look on his face made it look like something foul had briefly crossed his nose. Then realizing his face was showing his thoughts, he made a pleasant comment about me being the smartest person at the table and then resumed hyper-babble.
With the next track starting, I excused myself...
Needless to say, I needed a break. The Big Design conference catered boxed lunches. I grabbed one and set off to find a conversation to be a part of while I ate. The topic among my classmates was either how we finished up the last class or how Frailey's death-march of a project was wrapping up - neither one of which I had the stomach to sit and listen to. Feeling particularly brave I walked up to a table with two guys my age and asked if I could join them. They eagerly agreed and I sat down. Turns out these two guys were Garrett Dimon and Thor Muller - two speakers at Big D. If I was hoping for a light conversation that helped bring all this into perspective and let me digest the last three hours of lecture, it wasn't going to happen. At one point it occurred to me that these two (particularly Thor) talked really fast and non-stop. The conversation was all over the place. At one point I gathered Thor was a carear business starter - building a small company and selling it... starting another. He must be terribly important and very rich, but not much of a listener.
At one point he asked me what I thought of 'all this', (I assume he meant the last hour of hyper-babble) and I got the impression he was only using this as a launch pad to change the subject. I said I was an imbedded engineer who was on assignment at the convention. The look on his face made it look like something foul had briefly crossed his nose. Then realizing his face was showing his thoughts, he made a pleasant comment about me being the smartest person at the table and then resumed hyper-babble.
With the next track starting, I excused myself...
Subscribe to:
Posts (Atom)