This blog is more about reflection of realization of how I think I can keep up with the world technologies rather than Peppy itself.

When I first read about Peppy, yet another CSS selector, I was very reluctant to accept it. I’ve just become a fan of jQuery and now there is something new. Nowadays everyone is trying to impress others and nobody can tell immediately whose work will last for a long time. However with a bunch serious unit test the author provided and solid benchmark results, certainly some great work is done here. So I’d like to check out how to integrate this new selector with some of my other JS frameworks and will use it in my next project.

I am always easily fed up by having too many options, but this is the case more and more often in nowadays technologies world. And this trend will continue for sure because of the massive buzz and evolution of SOA. CTOs, Software Architects, and Software Engineers all need to wade through that software jungle to find out which meet the needs of the company, the product, and the component respectively. I have to give up my satisfaction with current technologies and software I am now comfortable with, and embrace whatever I find to be promising along the way. I may be wrong sometimes by passing on the best solution and choosing another, but at least I won’t be trying to stay in my comfort zone with the software I use from a decade ago.

So I’d like to write to myself, don’t hold any prejudice on new stuff.

One of the main sources of confusion and anxiety in our lives is having choices. If life could be just a linear path with no branches, we’d be follow our faith with less of the pain appears when we’re given too many options. Knowing that choosing one of the paths may lose the benefits of the others, we often hesitate, and always want a prediction of the results, either by logical analysis of the conditions or superstitious methods such as card readings, palm readings etc.

But sometimes, when the choices given are seemingly equivalent or the results wouldn’t really matter a lot, such as whether you should have fried chicken or sushi for lunch, here is something can help you get out of the “dilemma” if you feel you badly want them both.

The magic

Get a coin from your pocket, tell your self what each side of the coin would represent, say head for sushi and reverse for chicken. Toss it to the air and let it drop on the ground freely. And then go for the choice represented by the side facing up. There is nothing special, right? Read on. The key point is below.

“the coin help you identify what you really want, rather than let the odd determines what you should do”

So you’ve just toss the coin once. You’re probably know where you’re going. BUT, if, after the first toss, you still hesitate and feel want to toss it two more times to get a 2/3 ratio, go ahead with the OTHER option. Because this means you really like the other one better, even just slightly which makes you reluctant to accept the result. The key is tossing it ONLY once, if you feel even a little unsatisfied with the result, follow your heart from here.

The main theory behind this method is to let the coin help you identify what you really want, rather than let the odd determines what you should do. It could also be extended to situations such as considering where to go for holidays. But for more serious issues, rational thoughts should take precedence.

…Continued from Dealing with the world (0) - The problem,

“I will implement whatever you need me to implement precisely regardless whether you told me wrong”

What does “flawless” really mean?

It’s not necessarily wrong with an ambitious and strong statement like this, but a lot of considerations must have been taken into account to make such statements. If we can assume the local tests are correct, then his code can be in fact “flawless”. Unfortunately, the local tests is not a reliable source either. When an assumption is false, you cannot get any reliable information out of it, for any implication derived from it is true.

In this competition, there are four ways to get information on a problem: the specification document, the local test suites if provided, the test suites on server, and the support forum. Out of the four, only the latter two can be considered reliable and official. In this respect, the program is not really flawless since the “truth” here is the online test cases. Even though the they may contain errors themselves, they are the ultimate tests against which competitors programs will be checked. So being adaptive to them should be the goal. Moreover, competitors should not feel uncomfortable with these inconsistencies either because the point is more about meeting the requirements, not criticizing how the problems are loosely specified. The oath shall be “I will implement whatever you need me to implement precisely regardless whether you told me wrong”.

In fact, these kind of inconsistencies are more than just common in the real world production environment. When many people work as a group, lots of tiny flaws can occur, leading to misunderstandings among the members. Therefore people should be able to calibrate information received from others in order to damp the error accumulation, especially when supervision is not always available. It’s impossible to have a 100% accurate specification bearing none unclear/vague/ambiguous descriptions, and if a development team insists to wait for a 100% accurate specification to start, it’s going to take forever.

The world is never perfect, yet human race still evolves, because perfection is not a necessary factor. Now think in the other way, if we’ve reached perfection, there will be nothing else we can work on - and that’s probably the end of the universe.

…Continued from Dealing with the world (0) - The problem,

So why didn’t I raise all the issues I encountered?

Do what a competitor SHOULD do

So why I didn’t raise this specific issue on the forum at first place? From my standpoint, first I don’t have the responsibility to report any bugs I found; secondly, it became unfair to myself if I pointed out all the inconsistencies or gotchas that cost me hours to figure out through a series of analysis and debugging. Although I’ve raised two relatively more confusing problems that were confirmed and fixed. As a competitor, it’s fair I think.

Do what a competitor CAN do

Now from the judges’ perspective, if someone keeps pointing out every single problem, they may found it annoying because many of the problems can be sorted out through a more careful thought on the logic of the problem itself. Moreover, if the competitor posts too much bugs and suggestions regarding the problems, it’s quite likely that the judges will find that he is exposing too much of his own solution to other competitors which may or may not mislead others, but might cause the entire competition system fail to work. Just imagine what if I post all my DDLs somewhere on the web and allow everyone to download and submit them as their entries. It can be a catastrophe.

What’s my ethics?

Now let’s get back to the central point. What’s my ethics? Well, I need to say that there is no universal ethic that works for all circumstances. It’s a dynamic world and need dynamic solutions. But I am not saying you should become floating between the evil and the good. However, be evil or be good are perhaps the only options you have to choose only once and then never be the other. So supposed I chose to be good as my base ethic.

• In a competition: Although not absolutely true, in any competition the main goal is about beating others, if not, beating yourself. In a competition you lose the spirit if you decided to help your opponents out by providing help and guides to them. And of course misleading or trapping others purposefully is not the point either. Fair to say is that you concentrate on finishing your own task and do your best. You can seek supports from the judge and other competitors too, presumably, but the difference is you need discretion when hearing from another competitor.
• In a group working environment: When you work in a group and your goal is to help build the product as high quality as possible, you could express your ideas and concerns freely to colleagues, managers, and even sponsors. If you find an flaws in a product that other people didn’t raise, you should go ahead and report it as it may cause failures and severe consequences if not. This is where teamwork spirit should come to vision and where you can help colleagues by providing them background and extra informations.

(to be continued…)

As I am browsing on ImagineCup forum today, I came across with a post in which a user complained how he failed the Test Suites on the server while his “calendar program runs all of the NUnit tests (Local Version) provided flawlessly”, and that he believes that he “has no errors in my (his) code”. He is also “curious about … why the two people who have perfect scores on the leader board didn’t report the bug…”.

As being one of the “two people”, I would need to first assure people that I didn’t sneak into the current position because of the Test Suites back then was different than the current. I had the exact same problem but figured out the work around in less than 10 minutes. It’s not really a “work around” that people usually use to cheat. It’s more about guessing/analyzing what the judges really wanted when there are inconsistencies between the document and the judging test cases.

(to be continued…)