Objective C

Objective-C implements weak typing, blocks (aka anonymous functions or closures), key-value coding (aka accessing an object's methods and properties as if the object was a dictionary), monkeypatching, etc. It's a dynamic language with the power of C. It's Ruby and Python's uglier but more efficient sister. It has its own quirks that might put you off at the start, but the more I learn about it, the more I like it.

Jogging Without Gadgets

When I go out for my regular 10~12k jog, I don't bring any mp3 player with me. In fact, I don't carry any gadgets at all: the only items on me are my sleeveless shirt, jogging shorts, and running shoes. It wasn't always this way. When I started out, I would fill my iPod to the brim with supposedly energizing music. But after a while, the music started to get old, so I'd find more music to replace the old ones. Repeat ad nauseum.

After a while, I got tired of wasting so much time finding songs. So I got rid of the music (along with those pesky earphone wires that always cling to some annoying spot near my neck). Having been jogging old school like this for some time now, I realized something: Running is more enjoyable! Here are a few theories that I present:

• I can pay more attention to how I feel. Do I feel out of breath? Slow down a bit. Do I feel too relaxed? Speed it up a bit. Doing this multiple times during my run eventually helps me to hit a pace that is just right for my current level of fitness;

• I can let my mind wander aimlessly. I have to say, this is the best part. Usually, my thoughts revolve around some parts of work, philosophy, coding, and everything else that interests me or has piqued my curiosity at one point in time. This is certainly a lot better than the same old tunes blasting away inside my ear;

• I get to take in a lot more of my surroundings. I notice the greenery more, I hear different sights and sounds as the city around me wakes up, I hear dogs barking and chasing after me (which is fine since I also exercise my fast-twitch muscles in between my long runs so I'm able to outrun them easily!), and so much more. So even though I have limited options for my route, there's enough happening around these places to make it new each time;

• Before, when I used to bring a gadget that tells me my distance, lap pace, and time to finish, I felt constantly out of breath, impatient, and frustrated. Now that I stopped bringing that with me, I stopped thinking about those irrelevant things, and I started running according to what feels right. 

So when I take all of this into consideration, running without gadgets turns out to offer a lot more enjoyment and variety than anything else. That is how, I think, running should be.

Theory of Constraints: Drum-Buffer-Rope

This is an old report I wrote back in 2005 as a result of simulating different ways to streamline the process in the machine fabrication shop I worked for back then. 

Traditionally, the scheduling method used in a small manufacturing shop (let's call it MMS) has been more of guesswork wherein job orders are issued as they come. The main problem with this scenario is that as more job orders enter the shop floor, the larger the work-in-progress (WIP) inventory gets. As a result, idle times for job orders will severely fluctuate contributing to the variability of delivery times for job orders. The bottom line is that supervisors and sales representatives will not have enough data (and confidence) to come up with an accurate completion time estimate for every job order. Often times, they will resort to padding up the completion dates and/or compromising less critical jobs just to avoid late deliveries.

Job Shop Simulation
To demonstrate the phenomenon of fluctuating idle times contributing to the flow times of job orders, two sessions were held in MMS. In both sessions three scenarios were simulated. These simulations are based on the game developed by Dr. James R. Holt (Professor for the Engineering Management department of Washington State University) which was designed to closely resemble the work flow arrangement of job shops.

The arrangement of this simulation is such that four (4) of the participants will act as machine operators doing specialized jobs--that is Operator A cannot act as substitute for Operator B and so forth. One (1) of the participants acted as the scheduler releasing job orders to the shop floor. The remaining participant acted as the monitor responsible for computing each job order’s flow days and plotting the data appropriately in a graph.

Scenario #1
This scenario mimics the traditional method of releasing job orders into the job shop floor as they come. The scheduler was given thirty-six (36) pre-filled job orders and was instructed to shuffle them and pick only from the top of the stack during the simulation. Note that all job orders in the stack were designed to require only four (4) operations and should normally be completed within four simulation days. That is, each job order, if properly serviced, should have a flow time of only four (4) days. After the simulation, the data was plotted and was found to resemble the following:

The graph demonstrates that as more job orders are released into the shop floor, the more the workflow is congested contributing to the wild fluctuations of flow times. In the middle of the simulation, participants would have little confidence in answering the question “When will this latest job order be completed?”
After this scenario, the participants were then asked where the problem was. They all noticed that Operator B was the bottleneck. This is actually by design. Operator B represents the most constrained work center in a real-world shop floor environment. In the real world, the cause for this constraint may be anything from limited capability of the work center to high demand for its services. Operator B may be likened to the lathe department of MMS where nearly all of the job orders pass through.

Scenario #2
During the second scenario, the scheduler was given a fresh set of job orders which was exactly the same as the stack given in scenario #1. During this scenario, the participants were asked to work together in arranging the job orders such that they would not cause congestion in Operator B. As with the previous scenario, the scheduler was also instructed to pick from the top of the stack only. After the simulation, the data was plotted and was found to be no different than the graph from scenario 1.

Scenario #3
This scenario now incorporates the Drum-Buffer-Rope (DBR) method into the simulation. The participants were also oriented on the rationale behind DBR as well as given additional instructions to implement it during the game. The scheduler was then given a fresh set of job orders exactly the same as the stacks given in scenarios #1 and #2. The scheduler was then asked to arrange the sequence of cards exactly the same as scenario #1. The reason was to provide a direct comparison of results between DBR, and the method used in scenario #1. After the simulation, the graph plotted resembled the following:

The simulation clearly shows that DBR is a superior method to reduce job order idle time and narrow down the variability of completion times. Utilizing this method, MMS will be able to provide even better delivery-time reliability to its customers.

Elegant Solutions

I like elegant solutions because they are easier to administer. In fact, I believe that a solution is truly elegant if you do not even need to actively administer it. One thing to note about elegance though is that it's hard to achieve if you're harried, if you're out of time, trying to deal with too many things at time, etc. So it's important to be aware of you current state of mind and be sure that you are focused. Otherwise, you'll never achieve that elegant solution you have in mind.

Explaining Cloud Computing

Cloud computing is a hot topic these days and while nearly every IT professional knows what it is, the rest of the world is still unsure about it. In my current job, part of my responsibilities is to explain this concept in the simplest terms especially for non-technical people and I do this by saying that cloud computing simply changes how we acquire computers or software. The following two slides are usually part of my arsenal:

I start with the above slide by talking about how, in the past, it would take weeks or months to acquire computers or software and, at the end of that acquisition stage, you still had to deal with installation and configuration.

The first slide then dissolves into this next slide. Sometimes I add animation to the arrow by making it shorter and shorter until only the dot is left. As this happens I talk about how cloud computing removes all of that time and resource consuming process and makes the acquisition of computers or software nearly instantaneous.

Of course, I follow this up with other slides that give more depth to the topic, but I've observed that these  introductory slides are the ones that puts everything into context for the audience and make them go 'aha!' or even 'wow.' Notice how sparse the slides are. And yet, from my experience, they are very effective. That's because the slides don't compete with me for attention. Rather, they emphasize the message I'm trying to deliver from the stage.

Rails, Sinatra, or Express (for Node)? Decisions, decisions.

I've been evaluating these three frameworks yesterday and while I have to say that the speed of Express is really going to be critical in the long run, I think it's premature to use it at this point in time. What I need to do right now is get a prototype up and running quickly so as to keep myself motivated. Sinatra is really the same as Express (albeit a little slower and less of the asynchronous goodness) so I'll have to avoid using it at this time.

Since I'm already familiar with Rails, I'm going to use that as my prototype's springboard so that I can focus more on the client side where most of the action is going to happen. Later on, I'll just replace the backend with Express or Sinatra, whichever makes more sense.

No code samples for now. Gotta keep the suspense going! :-)

Things That Are Smaller Than Apple, Inc.

This may not be a slideshow, but it certainly is a good example of how to present numbers. Notice how this infographic does away with fancy graphics and yet gets the point across. I’d recommend using this for any comparison data. Chart purists might have a beef with the fact that it uses areas instead of the more technically accurate bar charts, but I  think that it’s really effective in getting the point across.

Original infographic here.