Sunday, October 23, 2011

A Cogini's internal TechTalk on Today HTML5

I made this slide and presented it to my colleagues a month ago. I even planned to publish the slide right after the presentation BUT, back then the layout of blogger made viewing deck.js presentation a pain in a**.

The problem hasn't vanished yet but with the current theme, it is less painful to view the slide, so...

The target of the speech is to identify HTML5 elements and features that you can use today, on any browsers. The selected elements are ones that nice to have but either don't break the website functionality if the browser doesn't support them (link relations) or comes hand in hand with a reliable fallback option (video/audio tag).

And here comes the slide. You might enjoy it better if activate your browser's full-screen mode. And here is the link to the original slide.

Sunday, September 11, 2011

My answer for the mobile application war

Just last week, our in-house project for the local market, PocketBank, kicked off. During the planning phase, a lot of time was spent on discussing the technologies we would be using in the project, which essentially a navigation app where we want an excellent offline mode and deploy on as many platforms as possible. The question was whether we should build a web app or a native app. The final decision was to go with native app as we failed to find a good map-kit with offline mode for web app. But thats not it, not yet. The discussion inspired further thoughts on the future of the ongoing application war.

I am not trying to make this blog another comparison between web app and native app as that kind of article/blog has been around for years and with a single Google search, you can find more than enough to read a whole night. What I am going to try is to predict the trend how people are and will be developing their applications for the current and future. The prediction at least will be carried out for my company for the coming time.

Here are some opinions of mine when making decision about the trend:

  • The fact that native app and nothing else can take full advantage of the specific features devices and platforms never changes.
  • Both leading mobile platforms iOS and Android are currently go for native app and build up a tight ecosystem around the platform (and devices), app stores and developers. A few factors of this ecosystem are awesome, like one-click payment, the powerful tools (IDE, instruments, etc.) available to native stacks. Web payment alternative such as Paypal, Google Checkout or other payment gateway is just not as convenient. I worked with XCode for a while and felt like dragged back to stone age when working on a number of HTML/CSS/JS tools). Some other factors aren't nice though, like entry cost, revenue split and that the static app stores' content oriented billing model can't fit all kind of shopping and services on the web.
  • Development cost is always a big concern. An app for iOS and Android usually calls for a developer for each and preferably more. That's double the resources a web app requires. And native app is expensive also because it requires skills and knowledge that aren't widely available. You can draw on a larger talent pool using web technology than you can with Objective-C.
  • Mobile platforms are taking steps towards a better support for web app. WebOS is a great supporter when exposing all of the API in JavaScript. And Windows 8 follows that movement, a foreseeable convergence of native and web app. But wait, do you remember the one-good-one-bad circle of Microsoft products? Windows 95 was a breaking news, Windows 98 wasn't much more than a wrapper of 95. Windows 2000 was kinda good, but WinMe wasn't. Windows XP was Microsoft's greatest OS ever and Win Vista couldn't do anything worse. Perhaps we will have to wait till Win9.
  • When a platform comes up with a new stunning feature that is not in HTML5 specifications (which takes forever to complete), it gonna take time for different browsers to implement the feature (some might never do). Despite a common belief among One Web supporter that "Regardless of who you are, what device you're using and what browser you're accessing content from, no user should be left behind.", there are a number of model browsers not as supportive as others (Android's browser, I am looking at you particularly) and eventually the next IE6 will emerge. Hopefully with the current platform/application update mechanism, thing will be less a catastrophe.
  • The native-app wrappers like PhoneGap or Titanium are getting well-known these days and they have their own use when providing HTML-based app with a (limited) set of native API. But IMHO, web app makes a better UX. Many users acknowledge traditional drawback of web app and when the experience turns out to be much better than what user expected, a little quirks won't even find its place it user's mind. But such a native app will fall right into "a piece of junk" category.
  • You hate Android's fragment? You will even hate mobile browsers' fragment  even more.
  • One Web is more a business and development decision rather than a decision to create an optimal experience for the users. The typical reason is to lower the cost and/or complexity. Compared to native apps, the web is a much wilder place. There is little or no standard about UI and UX and hence nothing to guarantee a consistent experience for users. However there are some positive points when it comes to web app UX like
    • Accessibility: generic experience for different platforms
    • No installation or update
    • Performance (don't get me wrong, I am not talking about the speed if that is the "performance" you are thinking about): no native app will ever deliver fresh content as quickly as the web 
  • Joe Hewitt's tweet: "I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in 2010, I won't wait"

My answer for the current...
  • The current generation of cell phones aren't quite powerful enough and HTML5 isn't quite developed enough so for coming time, web app won't be able to replace non-trivial native app. 
  • Native app is the number one choice for heavy tasks and new features. And by new features, I am not limiting to what platform vendors themselves have to offer but also the involvement and contribution of third-parties, a wish for a less-close future
  • Native-app wrapper wont be come mainstream, but remains relatively helpful for the access to (limited) platform API for the current time when WebOS is suspended and Win8 is in progress 
  • Business model like that of Bizness Apps will thrive as there is a growing demand for trivial apps from companies and no platform is proven to win the market
... and for the not-too-distant future
  • Eventually "web will win" is inevitable with direct support from platform level (e.g. WebOS and Win8)
  • Lot of effort and time are required to re-establish the ecosystem native apps is living in for web app, solve the feature puzzle and develop a new HIG that is neither iOS, Android nor any specific platform but a generic experience for all users
  • Native app remains the preferable choice for what it used to be the first ranked choice (above)
  • Native-app wrapper will become far less attractive, especially if there is a way to use native code to access platform API and then expose that to JavaScript. I wont be surprise if it will be eventually extinct

Friday, September 2, 2011

jQueryMobile - More in the FIXME list

A few week ago, I had a chance to work with jQueryMobile (JQM), a framework that I have known for long and looked forward to a chance to use for some practical development. (I was using Beta 2 when I wrote this post)

Well, after the first good impression (especially when compared to its ancestor, jQTouch), I started to find out a number of thorns here and there that prevented it from being use widely in the industry.

Most of the time when I write mobile web app, I use desktop browsers to test and develop the app and only move to the device to test major changes. I can tell that the page transition of JQM on my FF 5.01 and Chrome 13.0 is pretty flaky even when compared to the old jQTouch. The reason is because JQM is using keyframe animation and depends on how supportive the browser is, some frames might be dropped and causes the transition to be a bit rough. There is plan to switch to CSS3 transition, which guarantees better performance and support from major browsers, lets see how thing will go.

Currently, JQM provides developers with single-page (pages where only one div has data-role="page") and multi-page (single HTML document with multiple div with data-role="page"). And just like jQTouch, JQM uses hash-based URL for navigation.
So if I have a single-page document and want to "slide" to the next, my url is like
single_1 -> single_1#single_2
Similarly, urls of a multi-page document look like
multiple#foo and multiple#bar
I expected the two types as two great indigents for one-page apps. But no, different from my expectation, cooperation of the two types is half-baked. If I load a multiple-page document through AJAX, all navigation within the page are broken
single -> single#multiple -> single#foo (it should have been something like single#multiple#foo)
Also, the URL of an AJAX-loaded document is lengthy and ugly as it uses the format old_url#new_url, you can find this right on JQM's demo site
NOTICE: at the moment I was writing this post, jQM team has taken steps towards above problems with the launch of pushState, which clearly makes the url far neater and hopefully in the same manner handle single/multiple-page correctly.

And the last item in my list would be the bad "back" button. JQM provides default "back" button for pages loaded via AJAX. The problem with this default button is that it disappear when you refresh the page or load it from bookmark, which is a big FAIL for me. Developer can implement the "back" button manually too, but then the transition sucks. It wasnt possible for me to manipulate the transition effect and direction (in my case, it goes slide-right, where a normal "back" should go slide-left, but perhaps that's just me).

I would complain about the behavior of the button as well. JQM's "back" button functions as literal history of pages. This approach is similar to iOS' and Android's back button and works great for native apps. But web app is different. The user can interfere the URL, and when that comes, a history of pages leads to all kind of funny redirect as the "back" might structurally mess up the app workflow. I would love to see the button acts like a breadcrumb trail and therefore respect the app structure.

Just my two cents. I remain a big fan of jQueryMobile and its team, eagerly looking forward to the 1.0

Tuesday, August 30, 2011

Thoughts about MultiUni 2.0

Recently within Cogini, we have been planning to reviving MultiUni as many of us here were core members of the organization. In case you have not known what MultiUni am I blah blah about, it is a new model for education to improve the learning opportunities for Vietnam The goal is to offer low-cost high-quality courses that are not otherwise available in local universities or training centers. The organization was a blast as it addressed the exact need of both local students and companies: cutting-edge technologies. And back then, it was so fun for us to work together running the courses (iPhone and Android) as we both had chance (and reason) to approach latest and hottest technologies at that point and could really contribute practically for the community.
Unfortunately when the organization founder Huyzing left Vietnam, the activities started to decline and eventually was put on halt.

The re-establishment of MultiUni this time, not as a mere volunteer but as an organizer, exposes me to new opportunities and difficulties that I didn't acknowledge before.

My primary target of the reestablishing project is to revive the once-very-lively community that MultiUni 1.0 built up. I also want to attract local talents for my new company. But the discuss with Binh and Sieng at Mobile Thursday Meet-up (a very good one that I recommend everyone working in Vietnam mobile market to join) pushed the idea to another level: serve as the talent pool to make Vietnam one of the top rookies in the young and dynamic mobile industry. Although it requires a lot of efforts, not only from the community but also local companies and universities (that deserves its own post), it is very ambitious and worth keeping an eye on.

Also compared to two years ago, when the first MultiUni course was launched, the industry has changed in the way that make realization of MultiUni 2.0 much easier. After two years, the number of experts in fields that are still relatively hot and give developers stable positions such as mobile development, HTML5, functional languages, etc... has been increased dramatically and this new generation of experts, acknowledging the power of sharing, is really passionate when it comes to contribute to the community. The number of innovative projects that comes to Vietnam is also increasing in both quality and quantity.

Besides those advantages, there are a number of problems that need solving as well. Firstly, the commitment of local companies. As Binh pointed out, the reason MultiUni 1.0 failed to maintain a sustainable community was not only because the resign of its founder, but also because the number of students that could get a job based on the knowledge received in the class and/or be able to use the knowledge in their jobs was trivial and hence failed to maintain a healthy community with further activities, meet-up and training. How came fresh grads with latest technologies got unemployed and companies were in great thirst of talents happen at once? There might be many uncovered reasons, but the one on top of my head is the lack of involvement of companies in the courses in the past. Companies didn't know about the courses, the whole MultiUni community and the talent pool it could offer. Ones that knew weren't convinced by the courses quality. To address this issue, we are hoping to get more involvement of companies into the reestablishing project. Not only reveal hidden issues under employer's perspective, (a) company(ies) in organizational committees also can contribute solid commitment to the community, the trigger that needs to draw the participation of contributors, experts and learners.

Another thing blocked the way is the facility needed for the teaching and sharing process. Students and junior developers can't access to proper development environments and/or test devices that required for many platforms, namely iOS, Android, etc.... For companies, investing a TechLab for students is not something unaffordable. But the sharing culture simply has not been ready in this country yet, and the remain-unkown ROI of the labs makes the management skeptical about the benefit it can offer the company (and yes, there is nothing guarantee that students wont use the labs as their playground but serious development). Many company still prefer spending pile of money on head hunters to opening to the community and promoting their image, which IMHO, a far better long-term strategy.
Adventure ventures have been in Vietnam for years, but few express interest with community, NPO's projects. And it also impossible to work with ventures under the name "community", a real company needs to be established and that calls for heap of paperwork, too much that might scare away even the most enthusiastic contributor.

These thoughts and opinions are my own, and not that of my employer. And I am open to all constructive comments for a strong, lively community.

Sunday, August 21, 2011

Hidden threat in Storm's __storm_pre_flush()

Here at Cogini, we have an internal framework named Warp which uses Storm for ORM. Besides the fact that there is little document for the ORM (and only a fraction of that little is useful), there are also a number of tricks that make you simply want to tear your hair off. Below is one of those.

Preface: Storm's Store is the highest-level interface to a database. In Storm, every change to the database is put into transaction with commit and rollback. The story invovles Store's find() and Storm's base class' __storm_pre_flush__()
  • find(): perform high-level querying
  • __storm_pre_flush()__: executed before the object is flushed

I had two classes, everytime they were saved, they removed all the old entries before adding the new ones.

And I kept receiving this error: psycopg2.IntegrityError: duplicate key value violates unique constraint "student_intended_course_student_id_key" for line 14

StudentStudyPlan absolutely had nothing to do with StudentIntendedCourses, how come the error was fired here?
Whenever Store's find() is called, it triggers a flush so that newly added entries (not in the database yet as the transaction might have not been committed) wont be omitted. And right before Student object is flushed, it's __storm_pre_flushed__ is called.
Unfortunately inside _determineStatus(), implicit find() is used. This totally messed up the transactions and gave me the error mentioned earlier.

The solution is to move into __storm_flushed__ (called after the flush is done). Check if the status is changed, if so update it and commit.

A dirty trick, but still good to know if you want to both work with Storm and avoid being bald before your thirties!

Sunday, July 17, 2011

Basic OOP with Javascript

A while ago, a former classmate and current colleague of me phunehehe had a chance to work with a web app project that makes use of JS-OOP heavily. He was freaked out due to JS syntax and its way to do OOP. Yes, there are certain difficulties when moving from traditional OOP (Java, C#, etc...), but once you know the tips, it isnt something indigestible any longer :)

Basically, Javascript does not support a real class but it does allow you to create an object via a function. That special function is called constructor. With the keyword new, JavaScript makes the function become a constructor and instantiate a new object with the members defined by that function. Inside a constructor, the keyword this references the new object that's being created. It is also a convention that the name of the constructor is capitalized.

And nice enough, you can easily extend the function set of all objects created by a contructor using the prototype attribute.

How about a function that defined in both constructor function and constructor prototype? In that case the one that is defined constructor function will be used.

And from Douglas Crockford (Javascript: the good parts), we can easily implement inheritance with the combination of constructor function and prototype!

Finally, Singleton would be a good open to enclose this small talk about JS OOP. In short, Singleton is a class that has no public constructor but a special function that will return an instance of the class (and create one if the instance doesnt exist) Given Javascript nature, Singleton isnt a class, it also shouldnt be an object as any object in javascript can be created easily from a constructor. In fact, a Javascript's singleton is used as a namespace to provide a level of isolation from the global namespace and therefore served as a single point access to functions. A simple Singleton would look like this

With a bit of Javascript's famous closure, we can make the simpleSingleton to another level of complexity with private variables and functions.

My only question for this is that whether singleton in Javascript is really useful, I havent found any demonstrative sample yet. Comment below if you have any and want to share

Thursday, July 14, 2011

Timezone convertion in Python

I have been googling this issue for several times and each time it manages to get out of my mind within a few days. So I finally decided to just blog it, for share and for later references.

Sunday, June 19, 2011


A few weeks ago, I have some good (and at the same time bitter) experience with MySQL that I would like to share.

Requirement: given the auction and bid tables, select user's latest bid for each auction that she joined

Lets look into two auctions of my sample user whose id is 25

As the target is to get the latest bid for each auction, below is my desired result

And here is the result of my first attempt:

Oops, something is wrong here (of course, otherwise why on earth am I writing this). The second row should have been the bid made in second 47 not 44. The reason for this error is that GROUP BY is performed before ORDER BY, in other words the ORDER BY doesnt have any effect here.

After googling for a while, I am pretty sure that there is no way to tell MySQL order first, group later. You will have to do the grouping and sorting manually. Below is my query:

That's a long and quite complicated query, however the result set is correct

A few days later a colleague looked at my code, saying that it was bad (definitely) and offered some help with this

However, that... is wrong. Although the processing time is reduced dramatically, this solution provides a wrong result set. You might be deceived if only concentrate on the datetime column. The id column is actually wrong, due to aggregation effect. But the query was successfully trigger a debate among us and finally illuminate a right solution

SHAME ON ME! Realizing that how ugly and ineffective my query is, is really painful. Anyway that is a valuable experience with group by and order by, who knows if later on it turns useful.

Monday, March 7, 2011

jQuery's ready function and the "this" keyword

A few days ago, I got some hard time when my belief about the 'simple' this keyword of jQuery busted.

I had this simple html code
<div class="parent">
   <div class="child"></div>
   <div class="child"></div>
   <div class="child"></div>
I simply want to count the number of children inside the parent div. And instead of writing the counting code inside $(document).ready() as I have always been writing, I decided to narrow down the scope to the parent div only (because I had no reason to wait for the whole doc to be ready) and that was where the story begun.
$("#parent").ready() {
$(this).children().length; // return 1
$("#parent").children().length; // return 3
There is something wrong here, within $("#parent").ready(), $(this) and $("#parent") selectors are supposed to refer to the same object, the parent div. But the result turned out to be something different.

And thank for #stackoverflow, I got my answer. After all, the $.ready() function is ALWAYS run on the document element, no matter what selector are you using. To find an evidence for this, I tried:
$("#parent").ready() {
              console.log($(this).html()); // the whole html
              console.log($(this).html()); // the children divs' content
Apart from increasing code's clarity and understandability, you should stick with $(document).ready() because that is where everything get executed at the end of the day.