Faith & Prosperity

What a week. First, I attended my job's care group last Thursday (10729) and the topic was about prosperity. Then. my boss gave me and one of my coworkers a ticket to a financial seminar about debt, investment and setting up a business. The seminar was today, and it went well- all three of the speakers were both emotionally moving and very knowledgeable in their topics. After the seminar, I attended the Saturday mass with another coworker, and the homily was about, take a guess: wealth. See the pattern yet?
"Owe no one anything, except to love one another..." ~ Romans 13:8
Dr. Dan Lachica's talk about debt was very inspiring, and although I'm not in debt (except maybe from my parents) I still learned a lot from it. However, what really striked me was his short segue into how cheating somehow affects what happens to you in the future. Dr. Lachica's example was that, if he holds a scalding hot bottle of water, his hand will blister right away- therefore, he immidiately knows that the cause of the blisters is the hot bottle of water. However, if he holds the hot bottle now, and gets blisters after a few days, it would be harder to connect those two events.

Now, let me tell you what happened to me just last week. Yes, a week before my whole week of faith and prosperity-talk with practically everyone.

A week ago, Saturday, I was at the office working as usual with very little care about cash except saving enough for a copy of Final Fantasy 14 come late September. One of my friends asked me if I have time after work, since a new movie that looked interesting was in the theaters (No, not Eclipse, but Sorcerer's Apprentice w/ Nicolas Cage). Since I didn't have anything planned except my weekly Saturday mass at the nearby mall, I agreed. Turns out that the same mall had a screening of the movie we want, 30 mins. right after the mass (coincidence? I didn't think so then, but...)

I met with my friend after work, and we went to the mass together. Before the mass ended, the collection basket was passed for those who'd like to share their blessings with the church- I usually pass it on because... well, I don't really have an excuse. But until then, I don't remember ever putting any of my own money into the collection basket. However, my friend took out his wallet and drew some coins when the basket neared. Feeling a bit guilty, I also looked at my wallet and got some coins out- about six or seven pesos, I'm not sure. We dropped the coins into the basket and the mass continued.

We ate at a fast food, watched the movie (it was good, btw) then went home- a bus then a jeep. Here's when I first noticed something: I had the exact amount of coins left for my ride home, and since I don't like breaking my bills to coins, I decided not to stop at a convenience store for a quick bite.

The next work day, the same thing happened at my workplace's canteen- exact change. Nothing extra to spend on luxuries that I want, but don't need. The week trudged on, and the same things kept happening, up until the weekend came- which I normally spend some extra cash (I had quite a lot, to my surprise). I had quite a fun and I enjoyed hanging out with my friends, until I noticed that I left my jacket at a coffee shop (Town Center's Coffee Bean). It was a favorite of mine, and quite new too- I immediately sms'd my mom about it just in case I never get it back, since me and my friends are already a bit far from where I left it. An hour passed by, almost two hours, before we got back. Lo and behold, I got my jacket back. The shopkeeper's staff kept it for me, and I was really grateful that they did so.

It was an amazing string of "coincidences": starting with a guilty offering of only a few pesos, into saving some cash, into finding my lost jacket, and finally capped with a series of seminars that explained everything. It took me a while before I saw which caused what effect, but I'm sure- 100% sure, that my whole week was planned by Him. I really am blessed, and I'm writing this as way to spread these blessings, to inspire, or at least convince you, that the Lord, our God, is really a generous God.

I don't really like quoting from the bible (it almost always feels like its out of context somehow), but since I started with one, I'll end with another. Until next time, Sayonara!
"As long as the earth endures, seedtime and harvest, cold and heat, summer and winter, day and night will never cease." ~ Genesis 8:22

“Are we really going to use these theories/principles at work?”

While teaching in Letran, or even while studying there a few years back, one question almost always pops up when a professor wraps up a difficult topic: “How do we apply this in the real world?” I have asked this question myself a few times, and now that I'm working in the industry again, I have this rare chance of showing you exactly how the theories are actually used in real applications. I will tag these series here as 'Theory + Reality', and the posts would be about how we can apply the theories we have learned to the software that we would create.

Reality:10716 ~ Blog 1 
Click the Pic to Enlarge!

One of the most common task that we're going to do at the industry is to maintain and improve upon existing software. Look at the code above. This is a small piece of code from the Business Logic (BL) Layer that basically shows some collection of information about the customer. According to my previous blog post about the N-Tier Architecture, the Second Tier is basically a bridge/police between the User Interface and the Data Store, transferring while verifying the data through a set of business rules/policies. Now, let' analyze the code line-by-line.

Line 174: The Business Logic code asked for a ComboBox as a parameter. The alarms in your head should already start ringing- there's something not quite right here. A Combo Box is something the user interacts with, and the bridge/police shouldn't have anything to do with it. Theoretically, what we need is the data- what's inside the ComboBox.
Line 175: It's normally unnecessary to put an entire function in a Try-Catch block. We should only catch errors that we can fix- errors that the business logic layer, or the layers below it, actually creates. Everything else should just bubble up to whoever can resolve the error. Of course, sometimes you need to do this when debugging the code, just to be sure.
Line 176 to 184: This is simply an initialization phase for the parameters that would be used by the next process. Trivia: It's almost impossible to have a runtime error here that the Business Logic layer can resolve.
Line 185: This is the connection to the Data Store. We should hold on to the data that this returns until the User Interface needs it.
Line 186: Here, we use an external object (service as clsService) to bind another external object (the ComboBox), passing the data that we got from the Data Store, which is readily available since the scope of the Set_Get_Lookup property is Public. Obviously, this doesn't belong here. It has nothing to do with any Business Logic, and has everything to do with the User Interface. Take note that one of the features of the BL layer is that we should be able to interchange different UIs easily (this design pattern is known as loose coupling) and by binding the combobox here, we are tightly coupling this part of the code to the current interface.
Line 187: Catch ex as Exception means you would catch ALL exceptions. I will say this again: It's good programming practice to just specify which errors you catch, then let everything else bubble up. The user interface usually has this kind of Try-Catch block, to notify the user that you've done everything you could've done, but the error is still there.
Line 188: This is an impossible line of code. Business Logic layers are normally compiled in a library (a DLL) and libraries, by their very nature, are “headless”. They should never have a User Interface, so calling a MessageBox here is a logical error.

Theory + Reality
10716 ~ Blog 2 
Click the Pic to Enlarge!

You can see in the sanitized and Diff'd code above the design patterns and theories which I applied. Specifically:

Single Responsibility Principle. The business logic layer should have one, definite responsibility only: to act as a bridge/police for the data traveling between the UI and the Data Store. Don't let responsibilities bleed into other layers, or even other objects (also: avoid tight coupling).
Load Once, Use Many Principle. You can find my blog post about the Lazy Initialization design pattern here.
• Better Exception Handling.

That's it! The first of the hopefully many posts in this series is complete, and I hope we've both learned a lot from these. Until the next post, sayonara :D

Post@Posterous? Or Not?



I have been reading Michael Scott's novel, The Alchemyst this last few weeks, and it inspired me to write a short story in the same vein- about teens using magic in the modern world. Aside from posting it in my DeviantArt account, I have also decided to post it in a new blog which has far more editing capabilities. Posterous.com has been making waves in the internet world this past few weeks due to their new features, and I decided to give the service a try.

First things first: The signup was mixed bag. On one hand, all you have to do is email your first post to post@posterous.com and you're automagically signed up. On the other, geeks and experienced bloggers usually set the site up before posting- and it took me a couple of seconds to figure out that the sign up form was on the login page, and not the front page. After that's done though, Posterous accepts OpenId which makes logging in a breeze.

After playing with it for a while, I realized that the site is a far, far cry from Wordpress, or even Blogger. While most Blogging platforms have focused on ever-expanding features, Posterous have focused on Simplicity (a bit like google). They sticked with a simple WYSIWYG interface for posting & editing- there's nothing new in post-by-email, and their autopost to social networks is subpar with what Wordpress offers- for example, you can't choose which link shortener you can use. Also, the initial Themes, while very customizable, are limited to about a dozen.

If the only service you need is a place to put your notes, thoughts or stories into, then you can't get any more simpler than what Posterous offers. Signup, then everything's ready to go- post away!

Note: Sorry I can't post more often and more concise. I don't have Internet Access at work (yet) so I don't have the same amount of resources as before~ I'll still try my best though, gambatte! w00t~

Two-Tier Or Three-Tier?


N by !Raimyu on deviantART

The N-Tier pattern, when used in software development, is one step above my usual topic of design patterns. They are commonly called architectural patterns which are concerned with the software at a macro level (eg. ‘the big picture’).

Some time ago, I was tasked before of maintaining a line-of-business sales system from a fairly large company.Their technical design spec was quite clear that the “…architecture is divided into three (3) main layers…” which, in theory, should make my job easier. As I browsed through the code though, one thing became apparent: It was not a 3-Tier Arch like the docs said, but a more traditional server-client setup~ Now, what is the difference exactly?

A Server-Client architecture (which is, technically, a 2-Tier Arch) is concerned primarily with the centralization of data and sometimes the balancing of process load to either the server or the client. The data and the business rules (stored procs) are stored at the server, with a thin client app to present the results (forms, grids & reports)- which is exactly how the LoB app above works.

S+C’s Advantages over 3-Tier Arch

  • Faster Development (less design, less code)
  • Can offload processes to the server to accommodate for weaker client workstations, or vice versa if the server is the performance bottleneck
  • Can change business logic without re-deploying new software to the user

Three-tier applications on the other hand, is focused on the separation of responsibility to facilitate control and change. The Data Access Layer is usually separated physically such as a Database Server, but is mostly kept “dumb” except for very few performance functions. The Business Logic Layer on the other hand is a more robust collection of libraries and maybe a few dynamic scripts that enforces the rules of the application. This ranges from who can access which data, data validation, up to caching, etc. Lastly, the topmost Presentation Layer is the combination of UI Rendering (Windows Forms, ASP.Net, WPF, etc.) and UI Logic (Parallel processes, Sessions, States, anything that is not business-related logic).

3-Tier’s Advantages over S+C Arch:

  • Modular, and thus easier to maintain. You can replace one layer with another completely with very minimal code changes (switch from Windows Forms to WPF or ASP.Net with zero impact on business logic or database schema)
  • can perform Unit Testing very easily. Since all of the business logic is contained on libraries, you can hook the DLLs easily on a controlled testing environment.

We have to consider both sets of factors above in order to decide which architecture to use when designing our software~

Job @ Honda/Isuzu

At exactly 8:00am GMT+8 tomorrow (10619), I’ll officially be an employee of Ayala Motors under their Honda/Isuzu team :D It’s nice to have a permanent job instead of just jumping around with freelance and open-source development stuff~

Fun Facts: I was without a permanent job for approximately…

  • 2 Months and 6 Days or
  • 9 Weeks (rounded down) or
  • 67 Days or
  • 1,608 Hours or
  • 96,480 Minutes or
  • 5,788,800 Seconds o.0;

Of course I will still try to contribute to the Open Community, but in the meantime (at least while I’m still on probationary status) I will probably limit my posts here. I still have a lot to talk about, in fact: I have a post about the Difference between CS and the IT courses and another post about Careers and How to Make/Break one. I will post both of them ASAP, but I guess its sayonara for now~ See ya :P

Hadou 91: Senjyu Kouten Taihou

Hadou91

Limit of the thousand hands
Respectful hand, unable to touch the darkness
Shooting hand, unable to reflect the blue sky

The road that basks in light
The wind that ignites the embers
Time that gathers when both are together
There is no need to be hesitant, Obey my order

Light bullet -
Eight bodies -
Nine items -
Book of heavens -
Diseased treasure -
Great wheel -
Grey fortress tower

Aim far away,
Scatter brightly and cleanly when fired

Thousand Hands Bright Sky Cannon

~Urahara Kisuke, Bleach 402

Motivation

Motivation is the fuel for your creative engine, so that you can reach your goals. Intelligence and creativity matters little if you are not motivated enough to use these gifts. Actually, some people argue that motivation is the root of being smart or creative.

However, not all motivation are the same. Being a Computer Science or Information Technology student, the rewards matter a lot. In fact, as the video below demonstrates, carrots and sticks (the traditional “more work == more reward” paradigm) have the opposite effect on tasks that require the algorithmic approach.

According to studies performed by world-class economists from M.I.T. & Carnegie Mellon: For simple, straight-forward tasks, the traditional “do this == get this” paradigm offers enough motivation. But for more complicated tasks that requires conceptual or creative thinking (eg. programming or information analysis), the traditional motivators does NOT work.

If this is true, then what drives us? Autonomy & Mastery

Autonomy is the desire to be self-directed. This is why programmers tend to clash with the management the most- because we are innovators, risk-takers, explorers, and most importantly: Scientists. We boldly go where no man has gone before.

Mastery is the urge to get better at stuff. The best musicians in the world play music for fun. Not for cash, not for fame. Just because its fun. Programming is the same- we want to be better programmers because we enjoy programming, and being better at it is immensely satisfying.hubble10-hp[1]

Look at Google’s Innovation Time Off: Engineers are encouraged to spend one day of their week to work on projects that interest them. The engineers decide (autonomy) to work on interesting projects (mastery). And from this model, a lot world class services emerged: GMail, Google News, Orkut, even Google’s primary revenue source: AdSense. Now THAT is how you motivate programmers.