Pages

Friday, May 27, 2005

Who's responsible for what?

It seemed like forever since my last post although I think it was just 4 days since I last bragged here :) Anyway, last week was a veeery busy week for me. I had to finish this java-based text game and then do thos other use case diagram for my other class. Alas! The benefits of being jobless proved itself beneficial to me once again!! I just hope that I got high marks for those.

My Naruto downloads are progressing err... somewhat slow.. so far, I've just downloaded the first 11 eposides and the last 5 episodes (using the school's internet :D) the site that hosts episodes 1 - 50 won't allow me to download 65 megs in an hour so I cannot use the school's bandwitdth to download those early episodes (which are sooo large by the way). Having to donwload an episode for 14 hour and then reaping the benefits by watching that 22-minute cartoon and then having to wait for 14 hours more is just crazy!! It's like whenever you finished downloading a single episode and then you watch it and then you get this tendency to become emotionally attached and then all of a sudden, the episode ends and then you launch your download manager and it tells you that you still have to wait for 13.40 hours before the download for the next episode.. damn!! all the excitement and all the emotion build-up just have to wait for 13 more hours!! A DSL surely would come in handy in this situation :D But hey, a 14 hour download is worth the wait if it lets me watch an episode of Naruto :D

So, where were we?! Oh yes.. I want to skip the math mumbo jumbos today that I've been bragging about over my last few posts and just talk about a very important thing that I've learned in programming - especially when you are dealing with objects. But I'll try my best not to include objects in this post. Today, I want to talk about coupling and cohesion. These two concepts are very important and yet are so much pain the ass that it takes them a lot of time to master but once you do, it will give you the skill to make your programs the ability to become incredibly extensible and maintainable in an almost effortless manner. It's like this phrase that my professor always says: "Once you know, you know."

As far as I can remember, maintaining a program is really and I mean REALLY is one of the most difficult part of the programmer's life. I remembered way back during my thesis days when I had this Super Trump program that we initially did during our software engineering class. It was constructed in a procedural approach using an object oriented programming language which as we all know would leave a lot of trace of inefficencies like numerous amount of code redundancies, very high dependencies between modules, and a method that knows how to do all!! It seemed like almost imposible for me to maintain that crap and to tell you frankly, if it weren't for that thesis, I could have pressed SHIFT + DELETE and it would have sent it directly to the recycle bin!! Just imagine the things that we had to go through just to add additional features to the game that our thesis advisor made us do. Just imagine this scenario: You have these five thousand lines of code in your program. You want to add a feature that lets you shuffle the decks of the players. So, you study the codes (.. no big deal..) and you try to implement the changes that you think are necessary.. and that's it.. but wait, there's more. You tried running the program.. what's this?! a runtime error?? what the.. Oh yes.. the perils of debugging a code. Now you have to spend some time looking at each of the modules and try to think what went wrong. You know have to think what were the components that were impacted during the change, the code snippets that you have to update in order to make the changes work, and probably search for those redundant codes and apply the updates to those as well and make sure that you did not forget anything, and oh, I need to remind you that you are working on a program that has 5000 lines of code and that you are running out of time because you have a scheduled program demo tomorrow!! God dammit!! I wanna die!! Harharharhar!!

"So, what is this coupling and cohesion that you are talking about?" you asked. Well, coupling is a concept that talks about the degree of dependence between each part of your program. Cohesion, on the other hand talks about the number of tasks that a unit of your program can perform. As a programmer and a designer, we aim to develop a program that is high in cohesion and low in coupling. This simply means that individual units of a program should have very low dependence with each other and that each units of the program should have a single and well-defined task that it should do. To put things in proper perspective, low coupling allows the programmers to make changes to one part of the program without having much effect on the other parts of the program. It means that whenever we want to add or remove something on a certain part of a program, we shouldn't have no worry (at least) about any possible side effects that it may cause to other parts of the program. High cohesion on the other hand just means limiting what a module or a class can do in such a way that it all its methods contributes to the overall identity the class or the module itself. It means that if you have a module that computes for taxes on a certain income bracket, then it should only compute for taxes, nothing more. Seems easy eh?! Well there's a lot more than meets the eye you know.

So how do we achieve a low-coupled and highly-cohesive program anyway? Well, to be able to achieve a low-coupled program, I now introduce the terms implementation and interface. An implementation, in simple terms, describes how a program works from the inside while an interface describes how the program works on the outside. Let me explain on this more using an analogy. Lets say you have a calculator. As a student, you know how to use the calculator by pressing the buttons and looking at the screen for the result. But whenever you press a button, something happens from the inside. All of those circuit boards and logical gates reacts to the button that was pressed and performs the expected operation. But then again, the student doesn't care how 5 + 4 is processed inside the calculator. All the student knows is that whenever the buttons 5, +, 4, and = are pressed, it will yeild 9 as the result and display it on the LCD. Hence, we can say that the student "trusts" the calculator to do its job and it doesn't care how it does it - as long as the what the student is expecting is projected by the calculator to the LCD. Going outside the analogy, we can say that the interface in the calculator are the buttons and display and the implementation are those series of gates and circuit boards which are all underneath the plastic cover. Now that we understand what these concepts mean, lets go back to coupling. To be able to achieve a low-coupled program, each units of the program (class, methods, modules, etc) should communicate not with its implementation but with its interface. This implicitly says that a certain unit of the program should not know how the other unit that it needs to interact with works internally. It only needs to know what are the interfaces that the unit offers (remember the calculator buttons!) and have the unit to interact with it - and that's it! Certainly, on the calculator analogy, we do not want the student to have it learned digital circuits just to use the calculator eh?! So how does it reduce the time to maintain a program then? Well basically, if you depend on a module or a class' interface, once the implementation of that unit of the program changes, you don't need to worry at all on whether the other methods or class that uses it will still work - because it will (that is of course if the interfaces are still intact!!). Certainly, on our calculator analogy, if later (for some reason), Casio decided to store numbers in octal form instead of binary inside the calculator, then we can implement that change inside the circuitry without having to change the buttons because after all, what we are changing is how it works - from the inside. Having all of these said, I hope that it is now clear that low-coupled programs reduces dependencies between programs and as a result, reduces the impacts that may require changes to other affected parts of the program. Phew! That takes care of coupling.

Now on to cohesion. If you have a module or a method in your class that seems to do almost everything, then this is an indication that your program is lowly cohesive (sounds like mighty bond!) This means that your neighbor shouldn't be living in your house and instead it should live in its own house! Every class or module that are defined in the program should do a single and well-defined task. This would allow for a proper division of responsibilities between modules / classes and other modules / classes. By having a highly-cohesive program, we ensure that a certain module or a class takes care of its own methods - otherwise, we will end up having other classes or modules of different animals taking care of methods which they are not supposed to be doing. And this adds more coupling to our program - and we all know what that means now don't we???!

Now all of these stuffs doesn't happen magically you know. There is no silver bullet towards a highly maintainable program. To be able to come up with a program that has these characteristics, you should not just jump right ahead to coding and just have these sporadic thoughts run while you program. Certainly, all of these are attained through good design and proper recognition of the problem. Take some time to learn how the program is supposed to run, what are the entities involved in the program, and how do they interact with each other. These very simple steps are often underestimated even by veteran programmers. As a rule of the thumb, the more you design, the less hours you spend on hours and hours of frustration on trying to do things right. "But hey, do I even need to design a program even if its just as simple as my stupid assignment in COMPR4?" you say? Well, find that out yourself. After all, the best way of learning is experiencing the learning in the first place ;)

Alright, I guess that's it with this long post! I still have to solve this stupid exercise number 37 in my math book (I have been stucked with this number for 6 days now you know!!). I'll try to post it here once I find the solution for it. Ciao!!

Monday, May 23, 2005

So when the hell did they meet anyway?

Okay, I have to admit it. I was supposed to post something this morning but unfortunately, I got hooked up into watching this Naruto Season 3 DVD (about 27 episodes, I think). So there I was, sitting in front of the TV for 7 hours, tirelessly enjoying every single episodes of Naruto (God I love the benefits of being jobless). And you know what this pattern leads to right? Yep, you guess that right.. anime fever. So as a consequence, my brain has now convinced me to download every single episode from seasons 1,2,4 and 5 and tell my subconcious that a 4GB download over a dial-up connection wouldn't take that long (yeah right! oh the things that I would do for cartoons). And yeah, I think that another consequence of me watching cartoons for 7 hours is not having any goodnight hugs and kisses from my girlfriend at all. I think she got irritated coz it took me long to reply to one of her messages (damn those cartoons!!). But I couldn't blame her for getting mad though coz it's my fault anyway. If you can hear me out there, I'm sorry honey.

Yesterday, while I was working on the math book, I encountered this problem that costed me a lot of pain in the neck and almost forever to solve. Its funny how simple math problems look so damn hard when you do not know how to solve them and how very elementary it is once you've gotten the hang of it. Anyway, the problem had something to do about motion. Here is the problem:

A commercial jet took off from Kansas City for San Francisco, travelling a distance of 2550 km at a speed of 800 km/h. At the same time a private jet left San Francisco, travelling at 900km/h and bound for Kansas City. How long after takeoff will the jets pass each other?

Okay, so the guy who wrote the problem is asking us at what hour from their initial departure will the two planes meet given their rate of movement. So when the hell did they meet anyway?! Lets find out.

Here are the facts in the given problem:

Kansas - San Francisco
Distance (d1): 2550 km
Rate (r1): 800 km/h
Time (t1): 2550 / 800 h or 3 hours and 3 /16 minutes

San Francisco - Kansas
Distance (d2): 2550 km
Rate (r2): 900 km/h
Time (t2): 2550 / 900 h or 2 hours and 15 /18 minutes

To compute for distance, we multiply its travelling rate by the time it spent travelling. Hence, we get the general formula:

Distance (d)= Rate (r) * Time (t)

and so to compute for the distance from Kansas to San Francisco and vice versa, we have:
d1 = 800 km/h * (51/16) ->2550 km
d2 = 900 km/h * (51/18) ->2550 km

But that's a given. The real problem is how the hell do we use the formula in order to figure out when the two freaking planes met. Take a look at this:

We say that the total distance from Kansas - San Francisco is equivalent to the total distance from San Francisco - Kansas. And so, we have the relationship:

Distance from Kansas - San Francisco (d1) = Distance from San Francisco - Kansas (d2)
d1 = d2
r1 * t1 = r2 * t2

And so, looking from the previous equation, we instinctively write:
800 km/h * (51 / 16) = 900 km/h * (51 / 18)

Now everything seems in order, right? No, that's wrong! We will only end up having 2550 = 2550 as an answer! What this equation suggests is the distance from San Francisco - Kansas and vice versa, not the distance from Kansas - Location of Plane B and San Francisco - Location of Plane A given given a certain time. So what do we do now? Take a look at the following crappy diagram:

Point of meeting:
+----------------2550 KM--------------------+
Plane A------------->o<----------------Plane B

Time to destination:
+----------------2550 KM--------------------+
-----------------------------------> 51/16 h (A)
51/18 h (B)<-----------------------------------

Time when the two planes will meet:
+----------------2550 KM-------------------+
---------x hrs-----+o+---(51 /16) - x hrs--- (A)
---------x hrs-----+o+---(51 /18) - x hrs----(B)

Okay, I know those diagrams are not very convincing but hey! don't blame me, Im trying my best to make all of these clear! Anyway, the diagram suggested that Plane A will take x hours to reach Plane B's "will-be" location and Plane B will take (51/18) - x hrs to reach Plane A's "will-be" location - all happening under constant motion. And so, we have:

t1 = x
t2 = (51 / 18) - x

and:
d1 = 800km/h * x
d2 = 900km/h * (51 / 18) - x

Now that we have those relationships in place, lets go back to our original equation:
r1 * t1 = r2 * t2
800km/h * x = 900km/h * ((51 / 18 h) - x)

So what does this equation tells us? It simply states that x hours after leaving the airport, Plane A would have travelled a distance of 800km/h * x and Plane B 900km/h * x in the opposite direction and most importantly, in that x hour, they will have meet!! Now that's a lot more convincing than our previous equation!! Now that we know we're on the right track, let's solve for x and get this over with:

800km/h * x = 900km/h * ((51 / 18 h) - x)
800km/h x = 2550km x - 900km/h x
1700km/h x = 2550km

x = 1.5 h

And so, 1.5 hours after the two planes left, they will meet. Hence, Plane A would have travelled 1200km in 1.5 hours and Plane B 1350km in the same duration as Plane A (Plane B is faster by 100km/h than Plane A) before they meet!!

Now that wasn't complex was it? So what's the moral lesson here? Well, I've learned that unless you have a very high IQ or unless you were born with a superhuman ability to process math problems, you should always and I mean ALWAYS try to understand the problem. Don't get upset when you didn't understand the problem the first time (not everybody does!) Try to read the problem over and over again until you have a good grasp of what it is really saying. Think of creative ways (e.g. drawing, asking a Chinese guy) that will help you understand the problem at hand (honestly, if I had 2 matchbox cars with me while I was trying to solve that problem, I would have probably used it to see if they really will meet - but of course, I could never simulate something moving around 900km/h using a matchbox). Always find possible relationships and facts that are stated in the problem as they are your clues in solving it (and they are all that you will have!). And well, perhaps the most important thing of all is that you should never give up! It's all about determination baby!! No matter how hard or complex the problem is, one way or another, it has a solution and it is up to you to find that out! Once you give up, it's all over! Remember, nobody does it perfect the first time, or the second time, or the third time, or even how many times you would have done it!! The important thing here is that no matter how many times you've failed, you should always get up and learn from your failures and try to solve the problem all over again. Everything is possible through hard work and perseverance. Nobody is born being great with something. We all must work hard in order to gain something. The reason why those Chinese guys are great in math is because of their dedication to learn!

Okay, enough about that. I'll end my post here and continue downloading Naruto :) I might as well continue on solving another ten numbers from the math book so that I can go on with the next chapter. Oh, and Detroit beat Miami just now. Good for them.

Sunday, May 22, 2005

Quadratic what?!

King of the Hill rocks!! Yep, I just finished watching the series. It's kinda funny but yet, it's amazing how the creators of Beavis and Butthead could come up with a story that's something funny and crazy (considering the fact that B&B always ends up doing more harm than good in the end) and then ice things up with a mellow tone that displays life's practicality - that is, regardless of the stupidities and craziness that they do, they always end up settling for what is really the right thing. It's like a skateboard punk guy that acts rugged and all but deep down inside, he still finds time to help his mom shop at the mall or feed his grandma with some cereal and milk. It's really a nice cartoon - in fact, one of the nicest yet funny cartoon out there - and I'd recommend that you'd watch it.

Anyway, I just finished working on the first 20 questions at the end of chapter 1.6 and I came across this problem that required me to solve using a quadratic equation. I was kinda excited to post this in here so, here it goes..

Basically, there are two common types of equation that you'll encounter out there; one is a linear equation and the other one is a quadratic equation. Linear equations are those equations that contains a constant and a first-order term. In other words, no variable can be raised to the power other than 1. An example would be 3x = y or y= ax + b (where a and b are constants). Solving for x would be easy as you only need to separate x from other variables and coefficients by following basic algebra theories. Ever wonder why they call it linear equation? That is beacuase of the fact that a linear equation is also the equation of a straight line. It means that if you continuously solve for both x and y, you end up with a pair of numbers that when plotted on a cartesian plane, results in points having the same slope as the previous plotted points - meaning a straight line. Anyway, the other equation is the quadratic equation. Unlike the linear, this equation has a second-order term and a constant. This means that it contains a variable that is raised to the power of 2. An example would be x2 - 6x + 8 = 0. Solving for x now involves a lot more than solving for x in a linear equation. A gentelman by the name of Gauss once proved that an equation having a degree of 2 or x has 2 or x number of solution depending on the number of the degree. Hence, in the equation x2 - 6x + 8 = 0, we both have numbers 4 and 2 that will satisfy an equality (try it!). Solving for x in a quadratic type of equation can either be: 1) Completing the square of the equation by adding b/2 on both sides of the equation. 2) Using the quadratic formula. 3) Factoring the equation (if it is factorable). I find methods 1 and 2 very convenient especially for complex quadratics. So why the hell did they name this type of equation a quadratic equation anyway? That, I do not konw :)

So, you might be asking "Where the hell am I gonna use a quadratic equation anyway?!" well, I did ask that myself but that was before I read chapter 1.6 :) Here's a simple example that demonstrates the use of the quadratic equation:

Find two numbers whose sum is 70 and product 1224.

Without the knowledge of Algebra, we are doomed to guess random numbers and hope that their sum is 70 and their product is 1224. Luckily, we know enough than just doing random guess. So:

Let:
First Number = x
Second Number = y


The sum of the First Number and the Second Number is 70.
x + y = 70

The product of the First Number and the Second Number is 1224.
x . y = 1224

We have two unknowns in the form of x and y so we have to eliminate one unknown in order for us to solve the equation and we can do that by expressing one unknown in terms of the other.

Hence:
x + y = 70
x = 70 - y

Expressing x in terms of y, we have:
x . y = 1224
(70 - y) . y = 1224
y2 -70y + 1224 = 0


Now, we have arrived at a quadratic equation by simplifying the equation. So, we can use either of the methods mentioned above in solving this equation. In this case, let's use the quadratic formula in solving the problem.

The quadratic formula has a general form of:

(-b +- sqrt(b2 - 4ac)) / 2a

(sorry but this blog editor doesn't support square root and superscripts)

Substituting the values to the formula, we have:
(-(-70) +- sqrt( (-70)2 - 4(1)(1224))) / 2(1)

Since we have two solutions for the equation, we then have:

Solution 1:
(70 + sqrt(4) )/2

Solution 2:
(70 - sqrt(4) )/2

Which will give us:

Solution 1:
36

Solution 2:
34

So does this satisfy the original problem? Let's see:

The sum of the First Number and the Second Number is 70.
x + y = 70
36 + 34 = 70
70 = 70

The product of the First Number and the Second Number is 1224.
x . y = 1224
36 . 34 = 1224
1024 = 1224

We have an equality!! And so without having to guess a lot of random numbers, we have arrived at the answers to the equation without even having to break a sweat! This is an easy one. There are a lot of problems out there in the world that requires much complex computation than this one. But of course, knowing the fundamentals really simplify matters a lot!! I'm planning to do a Java applet that does a simulation which incorporates solving equations (like those work rate problem that we had on my last blog) - but that is after I learn how to do applets. I'm planning to touch it next week though.

I'll be continuing to solve 10-20 more numbers on the book today before I sleep. So I guess this is it for now. I'm gonna hit the books again and hopefully, I don't get papercuts this time ;)

Saturday, May 21, 2005

After 10,000 years..

Hey all, it's been a long time since I last posted on this blog. A lot of things have happened since then. I'm now in Canada and yes, it is home to one of the biggest game development companies that I want to work on.. Vancouver, Canada is the home of Electronic Arts!! By moving in this country, I got a whole new shot at this whole journey. But nothing comes without a high price though. I got separated with my friends, my pets, my cousins, my hometown, and most of all, my ever dearest love. It was very hard at first but I was able to cope up after few weeks of doing nothing but watch cartoons :) I guess this is how life really is. You just have to know how to deal with those ups and downs and be happy with it.

Anyway, I actually had a shot at working at EA as a game tester but I turned down (that's right!!) the position since during that time, I was already enrolled at this certain course that I took at BCIT. What the hell were you thinking?! you might say. Well, it's hard for me to explain but I knew that with all of the free time that I will have for not working, I will have all the time in the world to further improve myself and target a more higher level position in the company. Right now, I just don't feel that my skills are enough to move me up the hierarchy so I decided to just wait (and be a bum) and gain as much knowledge as I can before I enter the industry.

Okay, enough about that. During the last few months, I've been working like hell on this pre-calculus book that I bought during a library sale. After I finished this other C++ book, I decided that its time to move on to more theories and less application (after all, how am I gonna program if I don't know what I'm gonna program). And so, its back to 4th year high school for me.. revisiting those topics that talk about radicals, polynomials, exponentiations, fractions, quadratics, etc. and I really try to answer all of the questions at the end of the chapter at the end of the book (that's like 140 questions per chapter!!) so that this time, it sticks to my brain for good!! And what's more interesting is that I try to find out how these polynomials are applied to the real world. It's really very interesting to learn how some of the real world problems that deal with numbers can be expressed as equations (I know we've been doing a lot of these during high school but I wasn't paying attention back then on how important these stuffs really are!!). It's truly impressive that by solving these equations, you get a concrete and valid answer out of the problem that seemed very impossible to solve just by looking at it!! Here's a very simple example:

Mowing on a garden lawn having an area of 5 feet requires Jim 2 hours to finish and 3 hours to finish for Jen. If Jim and Jen were to work together, how long will it take for the said lawn to be mowed?

We can express Jim and Jen's work in terms of a fraction of work that they can do per hour. Hence:

Jim can mow 5/2 feet of the garden in 1 hour (2.5 feet per hour)
and Jen can mow 5/3 feet of the garden in the same hour (1.67 square feet per hour)
Finally, we can express their combined work rate as 5/x

Remember, what we expressed here is how much work can be done in an hour. An x variable is needed since we do not know yet how many hours is needed for the both of them to mow the entire lawn. Also, we assume here that they both worked throughout the duration and that they worked on a consistent basis (that is, 2.5 feet per hour for Jim and 1.67 feet per hour for Jen).

Equating the problem, we have:

Jim's work rate + Jen's work rate = Combined work rate
5/3 + 5/4 = 5/x

Solving for x, we have:
x = (4)(3)(5) / (20 + 15)
x = 12 / 7

Hence, if Jim and Jen works together to mow the 5 feet lawn, it will take them 12 / 7 hours or 1 and 5/12 hours to finish - a lot more quicker than working alone.

So how do we check if our answer is correct? Simple. We just solve for equality. Hence:

We know that:
x = 12/7

And the working equation was :
5/3 + 5/4 = 5/x

By the virtue of substitution, we have:
5/3 + 5/4 = 5/(12/7)

Solving for both the left hand side (LHS) and right hand side (RHS) of the equation, we have:
35 / 12 = 35 / 12

Hence, this clearly shows that we have an equality and that our solution is correct!


You see, this is just one of the amazing things math can do. Without the knowledge on how to translate those into equations, we might have not arrived in the proper answer or even if we did, it would have took us a lot of time using ubiquitous methods.

There are a lot of things that I really have to learn in that area. Right now, I'm on section 1.6, page 67 of the book and there are a lot of problems whose complexity far exceeds the one that I just wrote down. Perhaps the real key to this one is really understanding what the problem is all about and knowing how you would express them algebraically. Well, I guess that's it for now. I need to get some sleep now as it is already 7 minutes past 5 in the morning :) (I really need to change my sleeping habits).