Skip navigation

Slowly, the red-filled rows in our schedule table crept down, indicating more and more (critically) delayed deadlines for builds. We haven’t stopped coding ever since code started rolling and deadlines have been moved a few times already to boot. But, sadly, we just kept missing build deadlines.

However, before I continue with my story-telling, I really just need to relate some news to you…

It seems that The Social Network has finally been beaten for the title of “Best Geek Flick”. Received with much geek acclaim, the competing movie was screened the night of 25 May, 2011, a tonight-not-again type of screening. The movie is entitled Sir Zhen* vs. The Server. Shame I missed it.

Some reviews,

…Unexpectedly, there are no logic errors found. We asked help from our mentor kuya P of what is happening. Sir Zhen approached us and asked if there are any problems and we told him of what is happening. Sir Zhen debugged the server… In a way that I cannot comprehend. We commonly debug our puny logic for hours but Sir Zhen only took about 30 min or so and the level of the logic is too high for us to handle. I cannot put into words of how I see it, the nearest I can think of is Pure Awesomeness…

~Luigi Mari Tenerife. Co-intern from UPLB. Emphasis added.

 

Lahat ng narinig mo sa isang sem ng Operating Systems class maririnig mo sa loob ng thirty minutes!

~John Patrick Albacea. Co-intern from UPLB. Words are not verbatim.

 

Hindi tumitingin si Sir Zhen sa code. Dun lang siya sa dump log! At nahanap niya!

~Luigi Mari Tenerife (again). Co-intern from UPLB. Words are not verbatim.

Certified must watch! (If only it wasn’t a one-time big-time show)

And now, to proceed…

So, we had four build deadlines last Monday. Three of them went dead-up to “Critically delayed” but we eventually managed to build two. Builds 3 and 4 were eventually reslated for the next day.

I really find it hard working with untested base code. My responsibilities build mostly upon them and so for the past few days I found myself a self-styled discoverer of bugs. Some bugs are subtle, others not so. Some are just effects of snippets unupdated to reflect recent changes in the architecture while some are due more to carelessness than other factors.

And of course, after I’ve hunted the bugs in the base code, I would have to hunt down those that would appear in mine—my code built on the debugged base code. My life, in short, has recently been an endless cycle of test and debug. I feel as if my wish of becoming part of the API Team was fulfilled, albeit being in a debugging role; I work on the base classes but I never really author one. You won’t find a base class signed with “@author The Chad Estioco“.

Working with the base classes means that, for the past few days, I’ve been trying to do acrobatics with Java keywords such as implements, extends, protected, abstract, and synchronized like never before. For some reason I can’t explain, our module always seem to be a special case when dealing with the base code. Just like today, when I had to send tokens in response to a tap action from the user—ours seem to be the only module that needs to do that so I had to put in some extra effort and ask for some extra help to make our code fit the base architecture.

Fan as I am of System.out.println in debugging, I admit that I wouldn’t have been able to get past all those bugs without a tool like the Eclipse debugger. Woot. I guess I have a new friend.

That’s all for now. Stay bug-free and see you soon. ~ The Chad Estioco

*In case you missed it from my first post, Sir Zhen is the person in charge with Azeus’ summer internship program. A bit of trivia: Azeus is using an internal tool for browsing the databases involved in their projects. I poked around this tool a bit and it turns out that this internal tool was created by year 2003 interns**. Sir Zhen was already the person in charge with the internship that time.

**Funnily, one of the 2003 interns’ had a surname of Estioko.

“Six weeks? We don’t do projects in six weeks. We usually do them in six months.”

~Mr. Lee, CEO of Azeus, during his meeting with us interns. Words are not verbatim.

Aaaaaannndddd we’re on the final week. We coded last week away and I expect we’ll do the same for our final week. My fingers are now packed with awesome strength, honed from hours of coding. My body, on the other hand, is starting to display symptoms of coffee dependence, as coffee is my mental stimulant during those sleepy hours after lunch break.

Our project is nowhere near finished yet, sadly. And we already scrapped some features at that. Among the casualties in the clean-up was my statistical ranking system. I’m not really disappointed that it got scrapped as I still have two challenging features to implement. And besides, I don’t think I’ve managed to perfect that system to behave exactly as we expect it to; after realizing that Python’s randint returns a uniform distribution I stopped thinking about it but I bet I have a few test cases in which it will break.

To manage all the project’s files, we are using SVN. This is the first time I ever coded with such a large team and I admit that it can be quite overwhelming. The most number of co-developers I ever had before this was 4, making-up a team of five, including me, and we didn’t use SVN that time. The first (and, prior to my internship, only) time I ever used SVN was, ironically, in a pair-programming project.

This is also the first time I ever used a framework that’s being coded as we work, and being coded by co developers at that. The pros:

  1. If there is a function you need but is currently not in the framework, all you have to do is talk to the person responsible for that type of function and you’ll have it at your next SVN checkout. No more awkward workarounds or (worse) waiting for months for the release of the next version.
  2. If there is a bug, or something you don’t understand, do the same as above. No more waiting for forum answers that may never come at all.
  3. It is a learning experience. I don’t really work with frameworks a lot but for those few times I did, I always wondered how they did things* (my current fascination, by the way, is CodeIgniter’s URLs, which are actually class/function names). Since my co developers (with our mentors) made the framework, I can see the code and learn how they did it. While I don’t understand everything about the framework (the jwebsocket-based framework still stumps me), I sure have picked-up some nifty programming tricks.

And the cons:

  1. Since we’re running on a tight deadline, and since framework development runs parallel with project development, some parts of the framework tend to be buggy, especially those made by request (see #1 above). It changes rapidly too: the jwebsocket-based framework has been through a number of deprecations already.
  2. Again, maybe due to the tight deadline, the framework isn’t well-documented, if at all. Though I can ask the person responsible directly, it gets a little embarrassing after a few rounds especially when that person is also working on something for his module—something that is always the case, without fail.

So there. I hope I can finish everything under my responsibility this coming (final) week. I’ll really work hard and smart to beat that!

*Maybe, my hesitation to work with frameworks is because I don’t understand how they do what they do. They’re like magic.

Biggest. Hurdle. Yet.

The base code I was waiting for came finally this week. They seem to have resolved it last Friday, after I went home. However, I spent the better part of Monday improving on a more stable feature trying to beat an afternoon deadline for a demo build. I only started looking at the base code around noon.

The instructions were pretty simple. Extend and override the methods of class Foo and then call method bar() of class FooBar. Sounds easy right?

Well it is supposed to be easy. Unfortunately, things went a bit more complicated for me in this episode of my adventure.

At this point, I am unwilling to continue my story using the optimistic-man voice I am hoping I have sounded like so far. It wouldn’t do the frustration involved any justice. Instead, I’ll be taking a leaf out of the books of those genii-going-madman from the movies and tell my story…

…event-log style (cf. Darren Aronofsky’s Pi)

Monday, 9/16/2011, sometime after lunch. Carefully read through resources and emails for instructions on how to work with the framework we are using. I coded what I’ve understood so far. Right. This should work. Hit “run”.

Monday, 9/16/2011, around 4PM. How many times have I hit run and I still don’t see a single map tile on my AVD? I already encountered this problem when I first worked with Google Maps but I don’t remember how to resolve it. They say it boils down to my API key, which is already there, copy-pasted from the layout xmls of my previous Google Maps work.

And it doesn’t help that AVD3 takes a lifetime to load or that, every now and then, connection to it times out and you can’t test your code on it anymore and the only solution is to close the AVD and wait for another lifetime.

Tuesday, 9/17/2011, morning. A beginner’s mind is a fresh place to come from, Zen says. So, this morning, I tried to address the issue of Google Maps not showing on my AVD. I perused StackOverflow, Android Dev Notes, Ubuntu Programming Talk forums, hell and high water but nothing seems to work for me. I even tried to regenerate my API key! After a few failed attempts at getting Google Maps to show, my beginner’s mind isn’t so fresh anymore.

Tuesday, 9/17/2011, after about an hour. I decided to test my previous guaranteed-working Google Maps code. They didn’t work. Tried to run them on an AVD in another computer. They worked. What?!

Tuesday, 9/17/2011, after a few minutes. Explained the developments in the issue to my mentor. Turns out that I hadn’t set the proper port and proxy. That’s funny since I don’t remember tinkering with the AVD’s settings since the last time I worked with Google Maps. While I appreciate the art in classic cartography, I never thought the sight of a map can make me this ecstatic.

Right. Whatever. Must. Code. Now.

Tuesday, 9/17/2011, around lunch. I can’t figure out what I’m doing wrong. I followed every instruction—extended every class they told me to extend, overrode every method they told me to override—and it still won’t work. I’m caught up in a cycle of read-code-run-ask. I’m starting to feel embarrassed as I repeatedly go to the same person for help. He seems to be the only one who understands what’s happening in the code and I seem to be the only person in need of his assistance. Perfect combination.

(If it’s any consolation, I’m the only one working with his code.)

It won’t work even after I showed him my codes and he nodded telling me it should work. Should.

Tuesday, 9/17/2011, an hour or so after lunch. I decided to run the sample code instead of just studying it and trying to get the pattern. It works flawlessly. What I can’t understand is why it doesn’t work for me. My bad. This code hates me.

Tuesday, 9/17/2011, after about 30 min from last log. Breakthrough. He pointed out that he didn’t really extend and override the methods of class Foo himself. There were already pre-made classes in the framework which did that for us. All I have to do is add my own code, should I need some more functionality/processing.

Wow. I didn’t know that.

Wednesday, 9/18/2011. (At this point, logs will have precise time stamps as it is this day that I thought up of this whole scheme.)

Wednesday, 9/18/2011, 9:18 AM. Succeeded in disabling the sample code. That’s intentional, the rationale being, if I can break it I understand it…

Non sequitur. Turns out rationale isn’t really very rational as I still can’t do what I want to do with the code.

Wednesday, 9/18/2011, 9:42:56 AM. (Time stamp from Android’s console at Eclipse. That’s accurate!) Modified the code some more and then hit run. Console greeted me with the following message: “Installation error: INSTALL_FAILED_INSUFFICIENT_STORAGE”. My bad. How big has our project become!

Wednesday, 9/18/2011, 10:06 AM. I thought I got it but still no. Hmppfff.

Wednesday, 9/18/2011, 10:32 AM. SUCCESS AT LAST!!! Must document how I did it so I can modify further! YEAAAAHHHHHHH!!!! I’m happy again!

<(‘-‘<) ^(‘-‘)^ (>’-‘)>

So. There you go. A story of my descent to madness then rise to happiness for the past few days.

Stay happy. Till next time ~ The Andrei Estioco

This coming week, I’m ready to code the AI (or should I say A*? ~wink~~wink~) of my n-puzzle project. I know that it’s been two weeks since I told the world about it but it’s been a busy two weeks and, aside from it, I’m also doing a lot of other things in my after-internship hours; it’s actually been ready since last week.

I decided to represent the puzzle as a one-dimensional list (the Python array). While it may seem counter-intuitive to do that since the n-puzzle is a two-dimensional grid, I decided to do so since, from that representation, it’d be straightforward to count the number of inversions. Inversions, as I’ve mentioned in my previous post, are important in determining if a given configuration is solvable or not.

Aside from inversions, there are two more computations that I had to address, which, unfortunately, isn’t very straightforward with a flat list. The first is determining the polarity of a row (polarity means whether a number is odd or even); the other one is computing the Manhattan distance* between two tiles. To solve both, I had to resort to some index arithmetic.

Although a 2D array representation will save me the trouble of two computations, those two computations are still way lighter (just arithmetic and some loops) than flattening out a list and then computing inversions (two nested loops, unless I’m mistaken).

(Though it is possible to compute inversions on a 2D array, I find that tedious to code.)

The biggest problem I encountered so far is in randomly generating a solvable instance of the puzzle. A naive approach would be:

  1. Generate a random instance of the puzzle.
  2. If the instance generated is unsolvable, go back to step 1. Otherwise, you’re done.

Since there are n! possible configurations for the puzzle, and n!/2[1] of these configurations is unsolvable, the approach described above runs in O(n!) time.

Another naive approach will be:

  1. Generate the solved instance of the problem.
  2. Randomly make movements on the puzzle—this will make the puzzle unsolved (duh!).

But how many movements must I do to make an unsolved state that is difficult enough? Since the movements made are random, I am not sure that more movements == more entropy == more difficult puzzle. Worse, I may even end up on the solved state again. Sure I can add a 3rd step to check (whether the puzzle is unsolved or whether the puzzle is difficult enough** or both) but at this point I already find things too complicated that I am no longer willing to analyze the time complexity of the method discussed.

And the best method I came up with is to use the properties of a solvable instance which I discussed in my previous post regrading the n-puzzle. I only had to address two simple problems with regards to this approach: 1) inserting the blank on a row of given polarity, and 2) adding an inversion to a sequence. The first one just needed some index arithmetic. The second one is slightly more complicated (see http://www.cs.bham.ac.uk/~mdr/teaching/modules04/java2/TilesSolvability.html***).

To test the stuff I’ve been coding, I defined the __str__ method for my n-puzzle. And, of course, things look ugly and bothersome to check with straight-out printing. With straight-out printing, my grid will look like

2 9 14 3
11 0 8 5
13 10   7
1 12 6 4

This is where I decided to use string formatting. Formatting, I can get

2  9  14 3
11 0  8  5
13 10    7
1  12 6  4

From what I remember from Java, string formatting is hellishly ugly to code, kind of like regex only, I understand regex but not string formatting.

Java String Formatting: Code

formatter.format("%4$2s %3$2s %2$2s %1$2s", "a", "b", "c", "d")

To say: return the 4th argument padded to 2 characters the 3rd argument padded to 2 characters the second argument padded to 2 characters the first argument padded to 2 characters. See the API for the Formatter class.

Python 3 String Formatting: Code

"{3:2} {2:2} {1:2} {0:2}".format("a", "b", "c", "d")

To say the same thing. See PEP 3101.

(This only works in Python 3. And 2.6, if I’m not mistaken.)

The output isn’t character-per-character exact but isn’t Python’s syntax better?

That’d be all for now. Must start on my A* ~wink~ – The Chad Estioco

*Along with the Manhattan distance issue comes the problem of moving tiles, as though they’re in a 2D grid—they involve more or less the same index arithmetic.

**And I must take pains to define what is difficult enough.

***I already gave this link last time.

[1] Russel and Norvig. Artificial Intelligence: A Modern Approach. 3rd ed.

The good part of the day:

  • I’ve started coding the third out of my three responsibilities for Module GundamX.
  • I’ve managed to make my app connect to the server. Prior to Friday it kept throwing an exception. As I expected, I just overlooked some steps.
  • I have integrated my SQLite database (read: the local DB system of Android) to Project GuitarHero’s SQLite framework.

The not-so-good part of the day:

  • The base class I need for item #1 above doesn’t look too finished yet. Either that or I, again, have overlooked a few things. But the code didn’t have much useful comments and was still littered with TODOs. Hence I’ve only started with item #1 but I haven’t really made a lot of progress.

The best part of the day, told in pictures:

So, we went up to the 29th floor (Azeus is at the 28th, but they own a unit in the 29th)…

Amazing view from the 29th floor...

Is that a helicopter pad at San Miguel's rooftop?! (Reflected is the flashy shirt I wore for the occassion)

 

Image0165

 

My co-interns: Wow we're at the 29th floor! WOW IS THAT A HELICOPTER PAD AT SAN MIGUEL'S ROOFTOP?!

To meet the man behind the company, Mr. Lee

 

 

"Is that intern taking my picture?"

He looks grumpy in my picture above but he is very far from that. Mr Lee has a gentle voice with an accented English (but hey, we probably sounded accented to him too) laughing a hearty laugh. We asked him one question each, and he answered sportly to questions such as,

Why Philippines? (Verbatim words; in context, the question meant “Why did you choose to have an Azeus branch at the Philippines?”)

How many of your employees do you know?

If Azeus grows further, do you plan to buy the whole (PSE) building?

(You won’t find my question among those three. Those questions came from my module mates. Don’t they ask the most amazing/funny of questions?)

 

 

...and here he looks zoning out but he is actually answering a question from one of us.

I didn’t manage to catch all his words maybe because I’m unused to his accent but it was an inspiring two hours nonetheless. He kind of reminds me of my impression of Professor Quiwa and Professor Muriel (links to my personal blog).

Best lesson I’ve learned from our meeting with Mr Lee: don’t be afraid to think about the long term; you may be making an investment.

Hope you’ve had a Friday the 13th as inspiring as mine ~ The Chad Estioco