Mặt tối của ngành công nghệ phần mềm Việt Nam – Lập trình viên hay một thế hệ yếu đuối

Nếu tham gia vào một buổi tán gẫu hay nhậu nhẹt cùng các lập trình viên trẻ tuổi Việt Nam, cụm từ ‘OT – overtime’ có lẽ sẽ là cụm từ được nhắc đến thường xuyên nhất. Họ hay kể về nó như một nỗi sợ hãi xen lẫn tự hào vì khả năng làm việc ‘trâu bò’ của họ. Hiệu quả của OT như thế nào thì không nên bàn đến trong phạm vi bài viết này, nhưng nếu bạn thử thức khuya liên tục cả tháng trời, ăn uống không có giờ giấc và hầu như không vận động gì trừ 10 ngón tay thì bạn cũng có thể hình dung sức khoẻ của mình bị bào mòn như thế nào rồi …

Phần lớn những con người trẻ tuổi, đầy nhiệt huyết ấy hầu như không quan tâm đến những vấn đề về sức khoẻ của họ. Đơn giản là vì họ có sức trẻ, và ở độ tuổi từ 20 – 25, họ hầu như không thể cảm nhận được sự tác động của cường độ làm việc liên tục tới sức khoẻ của mình. Đó là lí do vì sao các công ty out sourcing rất thích tuyển các lập trình viên trẻ hoặc sinh viên mới ra trường, đơn giản đó là những cỗ máy làm việc không biết mệt. Bệnh tật mà họ phải trả giá cho những năm tháng vô độ của mình hầu như không bộc phát ngay tức thời, nó thường xuất hiện sau độ tuổi 30 … sau độ tuổi này, họ phải vừa fix bug, đồng thời vừa fix sức khoẻ của bản thân mình.

Với các công ty out sourcing Việt Nam, họ đang phải gồng mình đáp ứng các tiêu chuẩn cao cấp của Nhật và phương Tây khi gia công cho các thị trường này nhưng trong tay chỉ có nhân lực theo tiêu chuẩn Việt Nam vốn thấp từ năng suất, năng lực và luôn phải đương đầu với các nhân tố mất ổn định của xã hội, gia đình, sức khoẻ ở một quốc gia đang phát triển như Việt Nam. Nói một cách khác, họ – những lập trình viên phải hy sinh các yếu tố về sức khoẻ, tinh thần – nghĩa là làm việc nhiều hơn, nhận lương thấp hơn đề bù vào khoản thiếu hụt trên.

Chưa có thống kê nào đầy đủ về các bệnh nghề nghiệp hoặc bệnh liên quan mà các lập trình viên đang mắc phải. Tuy nhiên nếu nhìn vào điều kiện làm việc của họ thì có thể dễ thấy tim mạch, huyết áp, các bệnh đường tiêu hoá là phổ biến. Chế độ ăn không  điều độ, lạm dụng cà phê, thuốc lá là hình ảnh thường thấy của của ngành này. Sự căng thẳng trong công việc khiến họ dễ dàng chấp nhận các thú tiêu khiển nghèo nàn như nhậu nhẹt, chơi game quá độ … từ đó làm cho tình trạng sức khoẻ của họ ngày một tồi tệ hơn. Hơn 10 năm làm trong lĩnh vực này, tôi nhận thấy phần lớn họ đều thiếu hoặc lười vận động. Ngoài yếu tố khách quan là thời gian làm việc chiếm phần lớn thời gian của họ thì các công ty cũng không mặn mà lắm trong việc tài trợ cho các hoạt động thể chất vì nó khá tốn kém và phát sinh nhiều hệ luỵ. Chả có công ty nào thích nhân viên mình chưa đến giờ về đã chăm chăm vọt ra sân bóng đá và hôm sau xin nghỉ vì lý do … chấn thương. Việc ngồi quá nhiều khiến họ cảm thấy mình bị dán chặt vào cái máy tính, uể oải và mất dần ham muốn được vận động.

“Hãy làm OT nhiều lên, chúng ta sẽ dùng tiền đó để mua thuốc” – họ thường động viên nhau như vậy, tuy nhiên không phải công ty nào cũng sẵn sàng trả tiền OT cho họ mà thay vào đó là quy ra ngày phép. Nhưng họ có được sử dụng ngày phép đó để nghỉ ngơi hay không ? Câu trả lời có lẽ nằm ở các nhà quản lý, nhưng có vẻ một khi làm quản lý trong ngành out sourcing này, bạn nên lờ đi sức khoẻ của họ nếu không muốn dự án của mình thất bại. Hãy mặc kệ họ, dù sao công ty cũng mua bảo hiểm sức khoẻ cho họ mà. Tôi nghĩ nếu các công ty bảo hiểm và các bệnh viện làm một thống kê đơn giản về việc chi trả bảo hiểm khám chữa bệnh cho ngành IT, có lẽ họ sẽ thu thập được nhiều thông tin thú vị.

“Gục ngã trên bàn phím” xem ra là một hình ảnh thi vị, chết trong khi đang code hay “tử vì đạo” liệu có thật không ? Nếu bạn biết rằng đã có nhiều người chết hoặc phải đi cấp cứu khi đang làm việc thì có lẽ bạn sẽ nghiêm túc hơn với sức khỏe của mình.

Advertisements

Mặt tối của ngành công nghệ phần mềm Việt Nam – Lập trình viên, anh là kẻ xấu xa

Trong bài trước, tôi đã đề cập đến sự bế tắc của thế hệ lập trình viên đầu tiên của ngành gia công phần mềm Việt Nam. Một trong những nguyên nhân dẫn đến sự bế tắc đó chính là họ bị tụt hậu bởi thế hệ lập trình viên trẻ, manh động hơn … những người đang hưởng thành quả từ thế hệ trước nhưng sẵn sàng phủ định mọi đóng góp của thế hệ trước … Bạn có thể phản bác tôi vì những nhận xét nặng nề này … thật là lố bịch khi một thế hệ bị tụt hậu trong xu hướng phát triển tất yếu lại dành những lời lẽ hằn học cho giới trẻ. Xung quanh tôi vẫn có rất nhiều người dễ thương, làm việc có trách nhiêm … nhưng hãy tin tôi đi – Họ, những lập trình viên của ngành gia công phần mềm Việt Nam vốn là những kẻ xấu xa, ngạo mạn, vô ơn và ích kỷ.

Nhìn lại 20 năm trước, khi mà chỉ có một số ít các trường đại học đào tạo ngành công nghệ thông, số lượng lập trình viên tốt nghiệp khá ít ỏi khiến cho nguồn nhân lực trong ngành gia công phần mềm luôn trong tình trạng thiếu trước hụt sau. Nói như kiểu anh Quảng bPhone2 – ít nhưng chất. Các kênh tuyển dụng thời đó chủ yếu thông qua sự giới thiệu của các giảng viên, chương trình thực tập, sự quen biết từ gia đình hơn là các head hunter. Các lập trình viên thế hệ đầu tiên không phải show up quá nhiều trước nhà tuyển dụng ngoài việc chuẩn bị một bảng điểm tương đối đẹp và một thái độ ngoan ngoãn. Tuy nhiên, ngày nay mọi thứ đều hoàn toàn khác. Hàng loạt trường đại học mở chương trình đào tạo và cho ra lò hàng loạt các lập trình viên, những người chọn ngành học này như một ngành thời thượng, với mộng làm giàu, sớm nổi tiếng … khi mà hàng ngày họ đươc giới truyền thông cộng với truyền thống ‘phá đám’ của các công ty săn đầu người bơm vào não họ hình ảnh của Mark Zuckerberg, Elon Musk hay Nguyễn Hà Đông … mà thành công đơn giản là hãy trở thành JavaScript, fullstack developer …

Lập trình viên chạy đua với các công nghệ ‘hot’, họ điên cuồng học cách sử dụng các framework, thư viện mới mà đa phần bỏ qua các nền tảng căn bản của ngành công nghệ phần mềm. Mặt khác, các công ty head hunter, nhằm tối ưu hoá số lượng ứng viên đã tìm cách bơm đểu các chiêu trò để giúp lập trình viên có thể deal được mức lương cao. Bản thân các công ty phần mềm Việt Nam cũng không ngần ngại phá giá mặt bằng lương khiến cho mức lương của các lập trình viên cao chóng mặt … tất nhiên người hưởng lợi là các lập trình viên và họ dễ dàng say trong men chiến thắng, biến chất và mất kiểm soát với bản thân. Họ trở nên ảo tưởng tới mức hoang tưởng về trình độ của mình, khoác lác, rao rảng về cái gọi là … dân IT

Sự ngạo mạn đầu tiên mà họ thể hiện là dành cho chính đồng nghiệp của họ – các lập trình viên, các tester trong cùng dự án với câu nói cửa miệng “anh/chị code/test kiểu gì thế này ?” Đơn giản họ luôn cho mình đúng và thông minh hơn tất cả. Vì họ được công ty trả lương cao, vì họ giỏi mà ? Tất nhiên, họ cũng dành sự khi bỉ cho chính những công nghệ khác không nằm trong hot trend, hay như lập trình viên JavaScript sẽ không tiếc lời chê bai những người làm .NET, hay Visual Basic … Họ sẵn sàng bác bỏ giải pháp của những lập trình viên khác đơn giản chỉ vì nó không cùng công nghệ mà họ đang làm. Họ không biết rằng, họ đang tự giới hạn domain của mình bó hẹp trong một công nghệ, đồng thời tự trói mình vào sự ràng buộc đó mà không mảy may chuẩn bị cho tình huống nếu công nghệ đó trở nên lạc hậu hoặc bị xoá sổ.

Tự cho mình là trung tâm của vũ trụ, họ luôn đòi hỏi công ty phải đem lại cho mình nhiều benefit. Họ không thích bị ràng buộc, đòi hỏi môi trường làm việc tự do để bao biện cho sự lười biếng của mình. Khi cảm thấy bị thất sủng, họ đòi hỏi công ty phải cho họ cơ hội học hỏi những công nghệ mới, những thứ mà công ty không thực sự cần nhưng lại có ích cho họ để tìm một công việc mới ở công ty khác. Xuất phát từ một người chạy theo công nghệ, họ dễ dàng bị lung lay khi có một công nghệ khác ra đời, dễ dàng bỏ rơi công nghệ hiện tại trong khi bản thân họ chưa thực sự nắm vững nó. Dễ thấy các lập trình viên ngày nay là những ngưới biết nhiều thứ nhưng lại không hiểu sâu bất cứ một thứ gì.

Các lập trình viên trong ngành gia công phần mềm hầu hết đều có một mindset cố hữu ‘đó không phải là việc của tôi’, trước tiên đến từ chính bản chất của out sourcing – mỗi người chỉ làm một công đoạn của cả quá trình. Điều này khiến cho công việc đôi lúc bị dồn vào một số cá nhân trong đội mà không thể chia sẻ cùng ai. Tệ hại hơn, nếu những con người này chuyển sang các công ty product, nơi mà một cá nhân phải chịu trách nhiệm cho cả product – điều này sẽ trở thành thảm hoạ khi mà họ từ chối tham gia vào cả sự hình thành phát triển của sản phẩm.

 

 

Mặt tối của ngành công nghệ phần mềm Việt Nam – Lập trình viên, anh đã già

Gia công phần mềm – software our sourcing bắt đầu ở Việt Nam từ khi nào ? Từ cuối thập kỷ 90 của thế kỷ 20, ở Việt Nam bắt đầu xuất hiện những từ ngữ liên quan đến gia công phần mềm. Tại thời điểm đó, cho dù quy mô còn nhỏ lẻ và manh mún, Out sourcing Việt Nam cũng đã có những thành quả đầu tiên. Nếu như vào năm 1999, our sourcing Việt Nam chỉ mới xuất khẩu được 9 triệu USD các dịch vụ của mình thì đến năm 2005, con số này đã là 500 triệu USD. Một con số tăng trưởng ấn tượng, bên cạnh một đội ngũ lập trình viên trên 1500 người làm việc trong 95 công ty. Đây là những con số thống kê được dựa trên các thông tin mà doanh nghiệp trong lĩnh vực CNTT đăng ký với cơ quan quản lý nhà nước, thực tế có thể cao hơn nhiều.

Từ thời điểm đó cho đến nay đã gần 20 năm, và những thế hệ lập trình viên ban đầu đó cũng đã bước vào độ tuổi 40 – 50. Họ bước vào độ tuổi trung niên, không còn trẻ và cũng đã bắt đầu già. Các công ty our sourcing, vốn luôn cần những con người trẻ, năng động và khỏe mạnh sẽ hết sức cân nhắc khi tuyển những người ‘cao tuổi’, chỉ có kinh nghiệm mà những kinh nghiệm này chưa chắc đã đáp ứng được yêu cầu công việc hiện tại. Tâm lý mong muốn được trả mức lương tương xứng với kinh nghiệm càng làm cho thế hệ lập trình viên đầu tiên trở nên khó tìm công việc mới hơn khi mà các công ty có thể trả cho các lập trình viên ‘fresher’ với mức lương thấp nhưng năng suất cao hơn.

Nhìn lại 20 năm trước, khi mà công nghệ còn khá đơn giản với chỉ một vài ngôn ngữ lập trình như C, C++, Visual Basic … và sau 20 năm, chúng ta có cả tá công nghệ phức tạp hơn. Việc ‘chạy đua’ với công nghệ mới không hẳn là dễ dàng với những người lớn tuổi khi mà bộ não của họ đã bắt đầu mệt mỏi sau hơn 20 năm viết code – họ dễ dàng bị tụt lại phía sau trong cuộc chay đua công nghệ với những người trẻ. Tất nhiên, từ phía công ty họ cũng không có chỗ cho những lâp trình viên già cỗi này. Nếu may mắn, họ có thể tìm được công việc bảo trì các hệ thống xưa cũ – legacy system – mà kỹ năng của họ vẫn còn phù hợp.

Đối với các công ty phần mềm ở Việt Nam, vị trí quản lý là hữu hạn và thường dành cho những người ‘quen biết’. Thực sự để có thể ngoi lên vị trí quản lý, ngoài chuyện giỏi chuyên môn thì lập trình viên cũng cần phải có các ‘kỹ năng mềm’, thứ mà đối với những người ngày đêm cắm mặt vào bàn phím là một điều xa xỉ. Lên làm quản lý không dễ, chạy đua với thế hệ trẻ cũng không xong. Lập trình viên ‘già’ bỗng trở nên mắc kẹt giữa chính cái ngành mà mình đã gắn bó nhiều năm nay. Và sau nhiều năm cống hiến cho sự phát triển của ngành out sourcing Việt Nam, họ  trở thành những người dễ bị tổn thương vì có thể dễ dàng rơi vào cảnh thất nghiệp bất cứ lúc nào.

Vậy đâu là lối thoát cho những lập trình viên già cỗi ?

Thực tế, đã có rất nhiều lập trình viên chuyển sang một công việc khác hoàn toàn không liên quan đến CNTT. Phổ biến nhất là chuyển sang làm kế toán, ngân hàng, kinh doanh bất động sản … hoặc đi dạy học. Tác giả bài viết này – vốn cũng nằm trong thế hệ lập trình viên ‘già’ đang có ý định nghỉ sớm để chuyển sang làm … đầu bếp. Startup không phải là sự lựa chọn của họ vì lý do độ tuổi cũng như khả năng chịu đựng cường độ làm việc cao, khoảng cách về công nghệ … Các công ty product có thể là lựa chọn tốt hơn nhưng cũng không có nhiều cơ hội cho họ do các kỹ năng của họ có thể không đáp ứng với domain của các công ty Product. Điều may mắn cho ngành gia công phần mềm ở Việt Nam đó là chúng ta không phải đối mặt với ‘khủng hoảng tuổi già’ như các nước Trung Quốc, Ấn Độ … những quốc gia mà quy mô gia công phần mềm cũng như số lượng lập trình viên của họ lớn hơn chúng ta rất nhiều.

Chúng ta khoan bàn đến những lập trình viên đủ may mắn để có thể ngoi lên các vị trí quản lý, những người mà ngày đêm họ đang rao rảng về sự thành công của họ và vẽ ra những viễn cảnh tươi sáng của ngành gia công phần mềm nhằm phục vụ cho mục đích PR, tuyển dụng … Hãy nghĩ đến một thế hệ, những người đã đưa Việt Nam vào bản đồ gia công phầm mềm của thế giới đang ngày đêm chịu đựng sự đối xử bất công từ các công ty cũng như những lập trình viên trẻ. Họ bị lãng quên, co cụm và lặng lẽ bước ra khỏi ngành gia công phần mềm.

[JavaScript framework wars] May the force be with you

Before reading this post, just let you know that it could be very long post. If you don’t like to read, just scrolling down to the end of post because I put the stuff for evaluating JavaScript frameworks there. Using it to make the decision for your own with your own risk or read the post from beginning. It’s surely that evaluating or comparing the powerful of certain JavaScript framework with other ones needs a lot of effort. At least, you must answer yourself some questions for gathering the information.

1. Which frameworks that to be compared ?

The previous posts mentioned about AngularJS, EmberJS, BackboneJS and KnockoutJS. All they are well known, always appearing the top results for Google search. In this post, I will present one more candidate – CanJS, it just attracted me for couple days because of it’s very easy for understanding. Someone advise me that bring Meteor and ReactJS/Flux to the list, but it’s not fair as Meteor is complete platform which more widely than frameworks. ReactJS/Flux is just a library, along side with Flux as its architecture.

2. Which factor to be used for evaluating ?

A lot, but the popular factors are features, maturity, community, size, performance, testing, license, dependencies …

3. How do we evaluate the framework with other ones ?

“Use the force, read the source”, as analyzing on Part 2. How ever, we will dive into the features rather than statistic. Maturity should be considered by Github, Stack Overflow data, because of reflecting the powers of community supports. Size is not important much for web desktop development, but mobile web.

The challenges are now I am not expert with all candidates, except Angular, Backbone that I have experience before, but nor Ember and Knockout.

Dive into analyzing factors

Maturity

Angular

  • Google productions such as YouTube on PS3. Nike, Huffington Post and many more use Angular already.
  • Very good documentation, examples
  • API not stable, Angular team release several minor releases and hot fixes.
  • Growing fast with large community support.

Backbone

  • Used by Bitbucket, FourSquare, USAToday, DocumentCloud …
  • APIs is very stable
  • A lot of example along with notation source codes.
  • A lot of watcher on Github

Ember

  • API only turns into stable since 1.0
  • A lot of examples
  • Good documentation
  • Yahoo, Groupon, Zendesk, Square are using Ember for their products.

Knockout

  • Great documentation including jsfiddle like examples
  • Stable API
  • A lots of examples.
  • A lots of watchers on Github
  • A lot of application on production, including best well-known jsfiddle.net

Size and dependencies

  Web Mobile
    Size (Kb min + gzip)   Size (Kb min + gzip)
  Angular 33 Angular 33
  angular.js 33 angular.js 33
  Backbone 44.8 Backbone 22.4
  underscore.js 5.4 underscore.js 5.4
  backbone.js 6.8 zepto.js 10.2
  jquery.js 32.6 backbone.js 5.6
  Ember 111.4 Ember 78.8
  ember.js 64.6 ember.js 64.6
  handlebars.js 14.2 handlebars.js 14.2
  jquery.js 32.6    
  Knockout 58.7 Knockout 36.3
  sammy.js 6.6 sammy.js 6.6
  knockout.js 15.7 knockout.js 15.7
  knockout.mapping.js 3.8 knockout.mapping.js 3.8
  jquery.js 32.6 zepto.js 10.2

 

Ecosystem

Angular – http://ngmodules.org/ – 1488 modules

Backbone – http://backplug.io/ – 256 plugins

Ember – http://www.emberaddons.com/ – 1157 addons

Knockout – https://github.com/knockout/knockout/wiki/plugins – 65 plugins

Features

Framework features is the most important factor for making decision. It provides the necessary foundation to build useful applications. Framework features can come from development team, or project requirement.

Observables: The ability to track the changes on object (Model).

  • Backbone allows developers to extend their JavaScript model classes from a base model type and access all properties via .get() and .set() methods so change tracking can happen and events can be triggered when the model changes.
  • Knockout has the developer apply observable wrappers around plain old JavaScript objects and then has developer access properties via object.propertyName() syntax (notice the parentheses).
  • Angular does dirty checking on all bound DOM elements on the page since there are no standard get/set method. Dirty checking means developers must concern about performance that could be happen on large page.

Dynamic routing: When the url changes, framework should able to detect and act according this changing.

Knockout does not support routing as itself, but developer has several options to use routing via Sammy.js or history.js, pager.js

View bindings: The view automatically refreshes/re-renders when objects in the view change.

Two way bindings: The change automatically update in both UI/binding values when another changes its value.

Partial views: a sub-view that to be embedded in primary view, so we can reuse partial views across multiple views.

Filtered list views: the views can be filter according certain criteria.

View template: The client-side JavaScript model data binds with HTML to build the content. Most of JavaScript frameworks support 2 types of template String-base and DOM base

String-based templates take string or text templates and replace the dynamic parts with data from models

DOM-based templates embrace the declarative nature of mark-up and create an html on steroids experience where html is annotated with additional attributes to describe the binding and events needed.

Productivity

JavaScript framework that makes developers more productive is able to deals with cross-browser compatibility (see browsers compatible) and makes the application more productive, provides the potential for reusable components and reduces the amount of code that needs to be manually written.

Angular is difficult to learn and may require developer to structure source code in a particular way. It provides dependency injection, ajax, routing, cookies, promises and much more…

Backbone is flexibility as it is the one with the least conventions and opinions. However, it may require developer to write a lot of boilerplate code which reduces developer productivity.

Ember allows developer to wrap all of repeated pieces of code inside components. Ember believes in conventions over configuration, so it can get lot of things done if we follow its naming convention.

Knockout support both DOM and Text based templating, that more flexible for developer who get familiar with one before. Knockout is targeting to data-binding mainly, so if we want to use it as full-fledged framework, we should choice anther its implementation as DurandalJS

Testability

The framework that supports modularity and dependency injection is most suitable for writing Unit test.

Modularity is that code can have small pieces that can be tested in isolation

Dependency injection is able to change dependencies in tests

Angular is the best framework for testing, with the core supports both modularity and DI, also support mocking controller and directive dependencies. The latest version supports E2E test via Protractor which launches application in a browser and interacts with it via Selenium.

There are many test frameworks and tools available to the Angular developer, brings the great flexible options.

Backbone was not built with testing capability. Developer must spend effort to create tests via third party solutions such as Jasmine, SinonJS.

Ember is designed with testing as a core part of the framework and its development cycle. Ember supports well for both integration test and unit test.

Knockout was not built for testing in mind, in which developer could spend much effort to writing test or make their code to be testable. Like Backbone, testing should be done with third party solutions.

Performance

Runtime performance is the most considering factor for making choice framework. This section will use the result from testing TODO MVC projects which implements same application, but across a wide range of popular JavaScript MVC frameworks.

Backbone version: http://todomvc.com/examples/backbone/

Angular version: http://todomvc.com/examples/angularjs/

Ember version: http://todomvc.com/examples/emberjs/

Knockout version: http://todomvc.com/examples/knockoutjs/

Four applications above which implemented by certain framework will be tested and measured by WebpageTest http://www.webpagetest.org/

Which one is the best ?

Angular and Backbone are both considered as the best for initialing a new project. The fact that you can not just pick the best one by its features or large community. If your project needs to work for all various Browsers, even if very old browser like IE6, AngularJS is looser since it just support modern Browsers. So you should not look up for “the best”, but for “the most suitable” for your project.

If you can not make the decision, or get confusing … you can do the more challenging and interesting ways – build your own framework 🙂

 

[JavaScript framework wars] Use the force, read the source

As I mentioned in previous post, I would believe that Stack Overflow and Github could be the best resources for my concern that how is popular enough for the data to be representative. Stack Overflow could show me the number of questions with or without answers, because it indicate how the framework to be supported as well. The number of questions also indicate which framework is most used. Github – the coding social network that can show you the number of projects, and the number of stars on a project is indicative of popularity.

Github is the most popularity repository where you can find a huge number of OSS projects. Performing some basic stats about these projects could give us an overview that how Github users working for specific JavaScript framework, or track their issues  … We also know that most JavaScript frameworks are hosted on Github too, so we can look into the number of commits, repos,  it could give us some further insight into the stability of the projects.

Stack Overflow – where you can post various questions about programming. This site is more interactive, more social than any forum. The question, solution can be qualified by voting, de-voting. Looking into Stack Overflow statistic data that always tell you which JavaScript framework is most concern.

Finding statistic data on Github, Stack Overflow is simple than ever, because they are providing API, or querying capabilities right there on their site. But I prefer to use API rather than query data just by I am not an SQL expert, and I am going to made an application that does statistic on Github and Stack Overflow. But if you want to use queries as your favorite one, let’s try with some questions with querying capability on Stack DataExchange/Overflow

How many post that mentioning about AngularJS ?

SELECT COUNT(*) from Posts P
WHERE P.Id IN ( 
 SELECT DISTINCT(PostId) from PostTags 
  WHERE PostTags.TagId In ( 
    SELECT Id From Tags Where TagName LIKE '%angular%') 
)

At the moment, the query return 104292 posts. So I tried with various tags as ‘backbone’, ’ember’, ‘knockout’ , …

AngularJS: 104292 posts

Backbone: 18213 posts

Ember: 25169 posts

Knockout: 14113 posts

These numbers can tell you which framework is most concerning or most used.

Using the API that returns JSON and needs some extra steps to end up your statistic because the formatting of return values. You can make your own request as below which returns the number of questions about “angularjs” from 1, January 2012 until now.

https://api.stackexchange.com/2.2/questions#fromdate=2012-01-01&todate=2015-06-28&order=desc&sort=activity&tagged=angular&filter=default&site=stackoverflow

Considering a framework that it should have a large support from community. We might think the number of posts or questions that have answering would reflect the well support. So we make the question like “how many questions about angularjs, ember, knockout, backbonejs that have accepted answers”

AngularJS: 53150

BackboneJS: 10918

Ember: 14947

KnockoutJS: 94

The number for knockoutjs is unbelievable, but interesting. The result above tells us that AngularJS is owning a large community support, chasing by Ember and Backbone.

Now, let’s take a look on Github which targeting to 4 repositories AngularJS, BackboneJS, KnockoutJS and EmberJS. So lucky that these repositories has some statistic with charting, mean why we will not take serious with calling APIs.

Framework       Stars     Watch     Fork      Open    Closed

AngularJS             3872        619            993          298        1046

BackboneJS          22244     1621          4968        13           2061

EmberJS               14133       1132          3025        427        3311

KnockoutJS          6530        590           1130         164        1098

The statistic on Github gives a very limited numbers for AngularJS, it’s normally because Google just put AngularJS to Github since 2014, why BackboneJS had the first commits in 2010. You can get the general information about specific frameworks by calling these APIs.

BackboneJS – https://api.github.com/repos/jashkenas/backbone

EmberJS – https://api.github.com/repos/emberjs/ember.js

AngularJS – https://api.github.com/repos/angular/angular

KnockoutJS – https://api.github.com/repos/knockout/knockout

You can example your own data, just spending a hour with Github APIs. I am sure that you will find many interesting things here.

Statistic application, why not ?

By the time finishing this post, I just started implementing statistic application that tracks the github and stack exchange api about these specific JavaScript frameworks. So this post might be updated by some factors (charts, data tables …) lately.

The next post, I will talk about framework featuring that help us to consider which framework is suitable. May be the next post would be marked as “TL, DR” 🙂

[JavaScript framework wars] The phantom of MVC

Since I was a student, the term “MVC” would be the most of popular words that repeat over and over from my friends and my lectures. They could talk all day about “MVC”, but did nothing else as putting the codes into certain folders M, V, C. Starting working as Flash Developer at Pyramid Consulting and the term “MVC” was haunting me once again. All the ActionScript project should (or must) be implementing strictly as “MVC”. The beginning of MVC framework for me as when we met “PureMVC” that solving several questions and concerns that we never known before. It showed how M-V-C parts working together, communicating with notification … That was fantastic emotion !

“PureMVC” turned into our standardize framework until its alternative “cairngom” appears. This alternative stuff not only offered us “MVC” but also “DI”, “Unit Testing” – the stuffs that we only seen in Java world. For years lately, we had more choices since Flash was on the peak of trending, but Flash was mostly focused for online gamings and the frameworks borns as suppose for game development.

For now, we all know Single Page Architecture (SPA)  using AngularJS, BackboneJS … but don’t we know that Flash Web had played very well on SPA battle fields ? We enjoyed fullscreen websites, and experiment pages transition without refreshing, sounds, 3D, augmented reality … So my wondering was that something ables to replace ActionScript/Flash must offer us the same stuffs as ActionScript/Flash did.

As ActionScript, JavaScript  says “hello world” without “MVC” as its first library jQuery that offering DOM manipulation, animation … HTML web is to create with its own way, slicing psd to html/css, then embedding JavaScript As I mentioned above that “pureMVC” as first offering “MVC” to ActionScript, it’s also offering “MVC” to JavaScript and opened our mind for first SPA HTML/JavaScript stuffs. Flash/ActionScript has stopped their steps and gave its way to HTML5/JavaScript, this chance opens new opportunities for the born and develop of JavaScript frameworks (hold a sec, that makes me think about the death of dinosaur …). Have you ever answered yourself that how many JavaScript frameworks are there ? Find your own at “TODO mvc“. Seriously, then several questions come to you now.

– Which one is the best suitable for me ?

– Which one that I should pick up for starting ?

– Which one is suitable for mobile development ?

– MVC and MVVM, which one is right for me ?

While you’re sinking with those questions, don’t you realize that you’ve just joined the war – the war of making choice your suitable framework. The fact that you would not be alone, because not only you but several developers get confuse with a ton of frameworks. By this time, I am in charge to pick up the right framework for my organization. We have several kinds of projects and we must pickup the right one with ensuring less risk, but most suitable for maintenance. Once again, I must face my face with the phantom of “MVC” but now it’s not seriously because “MVC” has been became the most popular pattern, or set as standard of JavaScript frameworks.

The war was out there, but just happening to me. I must choose my side, or do compromise. The next post that I will perform some statistic, queries from Stack Exchange that how developers on the world choose their own framework. That may give us an overview for a big picture.

Sharing common libraries and own modules between multiple angularJS projects

I have multiple projects that I’ll develop using AngularJS, but targeting to web and phonegap at a time. The problem is that I have shared/common UI components (services, controllers, filters …) between these projects for reducing maintenance effort. All the projects will have their own modules with specific functionality. But technically we have to bring the common modules into each project (without copy-pasting them, obviously).

This scenario is to assume that your project could be large, and many small teams could work together at a time. Sharing common things that could prevent the code missing from updates, but it produces less DRY code and does not violate KISS principle. As I do mention about sharing common codes that this part should be far away from recent requirement changes … If the changes alway happen among the teams, sharing common things could be a nightmare.

My inspiration comes from developing application with Sencha ExtJS. This framework is awesome in separating the application into multiple targeting such as web, phone, tablet. It’s about the structure source code, and build process that collects appropriate codes that matching target devices.  With AngularJS projects, we can share the common libraries with bower, using module to split application into several profiles (phone, web …) or you know that you can have multiple ng-app in one prject. Grunt is the best tool for developing your own build process.

From beginning, I cloned the angular-seed project, start to modify it with multiple profile. It’s easy that you just create new folder ‘profiles/phone’ and ‘profile/web’ and copy the ‘view1’, ‘views2’ modules for both. Don’t forget app.js, app.css …  At this point, you have 2 application that share bower_components,  components as well. You can start the server and see them working separate parts of a single large web application. It should be worry that we could public all the things to user, but we don’t do that because the source should be minified and deployed for separated target.

To create the build for phonegap, I have the idea that is to collect the code from bower_components, commons, components folder, and profiles/phone . All the JavaScript code, css and html resource will be minified and copied into www folder in phonegapp package. So the most important here is grunt task, no more specific technical stuff. The same idea for web targeting, and grunt task would deploy this part to appropriate location.

I posted my solution to github, with detail instruction in readme file. All they’re kept to be update, since I am getting several feedback by my technical team. This simple solution have challenged many developers for a while, because of not deeply understanding on Front-end architecture. So, just a K.I.S.S 🙂