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.

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!