styli

was playing around with some iPad’s styli lately and here they’re: the Wacom Bamboo stylus, TruGlide, Adonit Jot, Adonit Jot Touch, Jaja, Cregle’s iPen and ByZero. I’ve been loving the smoothness of Bamboo, but TruGlide is really an excellent one! The new Adonit Jot Touch seems to be promissing, and on the second position is Jaja (for pressure sensitive styli).

wwdc 2012

t would start within a week from now, the well – expected event of Apple’s world – wide developers conference of 2012 – WWDC 2012. To welcome the tech fair 😛😛, on the left is a screen capture of what I’ve been working hard on for the whole last month (the video is not really clear since it’s shot with my phone), a photo browser UI like iPad’s Photos app. It takes time to learn insights into Core Graphics, Core Animation, and I’m still learning. For all those years of graphics I’ve been through, Apple UI and its graphics sysem are still sooo… brilliant and amazing to me! (and “our love has just begun”!) Keep heading North!

apps

hẳng bao giờ muốn nói về software engineering, vì với tôi, đó là việc làm hàng ngày, đã làm hàng ngày thì có gì nhiều để mà nói!? Để ý thấy thường ai đó nói thật nhiều về điều gì (tiền bạc, tình yêu, trí thức, đạo đức…) thì tức là người ta thiếu cái đó! Tôi thì chỉ muốn nói nhiều về nhạc, vì âm nhạc với tôi là chưa bao giờ đủ! Tuy vậy hôm nay ngứa miệng nói về software engineering chút, gần đây đọc được một bài viết khá hay, trình bày lại ý chính ở đây: phát triển ứng dụng giống như là một nhà làm phim độc lập.

Phát triển app giống như làm phim: cả hai loại người này, coder và film – maker, đều có cá tính độc lập và xu hướng muốn sáng tạo, tạo nên một sản phẩm gì đó và “quăng ra” cho công chúng, mà đôi khi họ cũng không để ý đến việc quảng cáo, promotion cho sản phẩm của mình. Tuy nhiên khác với phim: kịch bản đã được viết sẵn từ đầu, việc làm app đòi hỏi coder đóng cùng một lúc hai vai: diễn viên và đạo diễn, với phần lớn khả năng là không thể biết trước được kịch bản sẽ như thế nào, sản phẩm của mình sẽ đi về đâu.

Đội một chiếc mũ khác lên đầu, ta sẽ nhận thấy apps ngày càng giống các sản phẩm bán lẻ. Nhiều coder có xu hướng “tự kỷ” cho rằng công việc mình làm là một cái gì đó “công nghệ cao” hay “to lớn”, đó là cái ảo tưởng hình thành không biết từ đâu: giáo dục, truyền thông, môi trường làm việc? Thực ra apps đã trở nên rất giống các sản phẩm bán lẻ (sữa tắm, dầu gội, kem đánh răng…), có hằng hà sa số các sản phẩm tương tự cạnh tranh với bạn, thị trường nhiều khi đến mức bão hoà, thế nên các chiến thuật marketing là một yếu tố quan trọng.

Điều này đồng nghĩa với việc coder phải chuẩn bị tinh thần để customize sản phẩm của mình theo nhu cầu của khách hàng, bỏ nhiều công sức, thời gian để cải tiến, đánh bóng các chức năng của phần mềm, đừng vội vàng tung ra một sản phẩm chưa tốt, dù vẫn biết rằng time – to – market là một sức ép hết sức lớn. Có một “thành ngữ” nói rằng: khách hàng không thông minh như ta nghĩ, và họ cũng không ngu như ta nghĩ. Điều này hoàn toàn đúng để nhận xét về chất lượng, tính cạnh tranh của các phần mềm.

Gần chỗ tôi ở có một công viên xinh xinh, cuối tuần nào ra đi dạo cũng thấy người ta mượn không gian để làm phim (đa phần là các loại phim truyền hình rẻ tiền dạng 20 triệu đồng / tập). Dừng lại và chú ý xem diễn xuất, kịch bản thì nhận ra đó toàn là những loại: con chó của tôi bỏ tôi ra đi, còn vợ tôi thì bị xe tải cán chết!, hay tệ hơn nữa là những loại: chống chỉ định với trẻ em mang thai và đàn bà dưới 16 tuổi! (đảo ngược 2 vế lại một chút 😬). Các bạn tôi ơi, khả năng kiên trì và sáng tạo của các bạn còn tốt hơn của các loại lau nhau kia nhiều… hãy vững bước trên con đường của riêng mình!

chuyện tình tự kể

gày nào, cho tôi biết, biết yêu em rồi, tôi biết tương tư, sau đây là câu chuyện tình tôi tự kể, ngày nào, biết mong chờ, biết rộn rã buồn vui đợi em dưới mưa… Chúng tôi quen nhau tính về thời gian chưa phải là quá lâu, chỉ một vài năm gì đó. Nhưng nguồn cơn, nguyên do câu chuyện có lẽ đã được vun vén, manh nha từ lâu rất lâu về trước, tôi thương em dễ có từ thủa mẹ về với cha.

Bao giờ biết tương tư - Tuấn Ngọc 

Những lý do, ngọn nguồn chẳng thể nào mà giải thích và truy nguyên cho được đã dần đưa chúng tôi lại với nhau tự lúc nào. Tình yêu nào rồi cũng sẽ đi qua nhiều thăng trầm, đã có lúc tôi cảm giác chẳng hiểu gì về em, nhiều khi sự khó khăn của em làm tôi nản chí, cũng có khi tôi đã hoang mang, nghi ngờ em và chính mình.

Nhưng với tình cảm chân thành, bằng trực giác tự nhiên mách bảo, chúng tôi đã vượt qua nhiều sóng gió, để đến một ngày: ngày nào, cảnh thiên đường, đã mở hé tình yêu là trái táo thơm, tôi ghé răng cắn vào… Đến đây thì hẳn các bạn đã đoán ra nàng thơ của tôi tên là… Apple –  hiện diện trên các MacBook, iPhone, iPod, iPad xinh xắn! 😬

con bò tím

hi còn nhỏ, tôi có một “biệt tài” là… mài dao rất sắc 😀. Một công việc tưởng chẳng khó khăn gì nhưng thực ra cũng không đơn giản lắm, muốn mài dao cho sắc và độ sắc ấy giữ được lâu cũng có khá nhiều kỹ thuật mà tôi chỉ tìm ra được sau nhiều tuần thử nghiệm. Chẳng là trong nhà họ hàng tôi lúc ấy làm cau khô: mua cau tươi về gọt vỏ, cắt miếng và sấy khô đem bán. Người ta chẳng bảo sắc như dao cau là gì, và ai đã làm công việc đó sẽ hiểu một con dao sắc là như thế nào.

Đơn giản chỉ vậy nhưng cái “niềm đam mê dao sắc” ấy, nếu có thể gọi như thế, nó đi theo tôi đến tận bây giờ. Gần đây tôi mua con dao gốm (ceramic knife) Nhật này, với giá bạn có thể mua được 10 con dao thép tốt khác. Cực kỳ sắc bén và chắc chắn, đủ bền và bén để cắt những thứ mà dao thép vẫn thường được dùng. Đặc biệt là chất liệu gốm sứ trắng muốt, trông rất mảnh mai và xinh xắn, nên chỉ dám dùng vào việc cắt, gọt trái cây hàng ngày. Đó có thể chỉ là một “impulse purchase”, thực ra tôi muốn thử một chất liệu khác biệt.

Làm một con dao, hay mài nó cũng không phải là việc quá đơn giản. Đỉnh cao như katana, kiếm Nhật, phải mất hơn 30 năm để học cách làm kiếm, và hơn 6 năm để học cách… mài kiếm sao cho sắc 😀. Nhưng túm lại thì nó có liên quan gì đến nhan đề của post này: con bò tím – the purple cow!? Một tựa sách của Seth Godin: Purple Cow – Transform your business by being remarkable mà gần đây tôi được đọc! Một cuốn sách về marketing, 160 trang khổ nhỏ, dể đọc với một số ý tưởng và khá nhiều ví dụ thú vị.

Từ những trang đầu tiên, tác giả đã khẳng định ý tưởng xuyên suốt cuốn sách là: mô hình các chữ P truyền thống: product, pricing, promotion, publicity… đã không còn nhiều hiệu quả, chữ P mới ở đây là purple cow. Nói cách khác, mô hình dựa vào những sản phẩm trung bình, và rất nhiều quảng cáo dần lùi bước, thay vào đó là những sản phẩm thực sự tốt và người dùng tự tìm đến cái họ cần. Vai trò của luật số lớn không còn như trước, ý tưởng tốt, sản phẩm tốt sẽ lấn át quảng cáo và truyền thông đại chúng.

Tôi hơi ngạc nhiên khi đọc những dòng về quảng cáo: bạn không thể làm cho tất cả mọi người phải lắng nghe mình, hãy tìm ra những người quan tâm, và hướng các chữ P vào đó. Điều này có thể bắt đầu đúng ở đâu đó, nhưng ở một xứ như VN, khi người tiêu dùng như những con bò được chăn dắt, thì tìm đâu ra một con bò tím? Ý tưởng của cuốn sách dần lộ rõ, một trong những ý tưởng đầu tiên trong thời economic recession này, khi hướng business tới chiều giảm phát, nghiêng về chất lượng để bù lại quá trình lạm phát.

Quá trình lạm phát đó đã có lịch sử nhiều thập niên với kết quả là những sản phẩm được đánh giá very good cũng không phải điều gì đặc biệt lắm. Nên trái nghĩa với remarkable là… very good. Tác giả lấy ví dụ những loài chim di cư thường bay theo đội hình chữ V. Những doanh nghiệp ăn theo xu thế cũng giống như những chú chim bay theo con đầu đàn. Nhưng điều mọi người không thấy là trong bầy chim, định kỳ vẫn có sự hoán đổi vị trí để con đầu đàn được nghỉ sức, những con chim khác đảm nhận vị trí bay đầu tạm thời.

Tác giả dành rất nhiều trang để đưa các case study minh hoạ thế nào là một remmarkable product. Một remmarkable product cũng giống như một con bò màu tím, bạn đã thấy một con như vậy ở đâu chưa, bò tím thật sự là rất khác biệt. Là một cuốn sách về marketing, tác giả dành nhiều thời gian phân tích sự nổi trội của con bò tím, hơn là cách thức tạo ra nó. Với thị trường như VN, tôi sẽ nói bạn có thể tạo ra con bò tím bằng cách phết sơn tím lên một con bò bình thường, nhưng tốt hơn hãy bắt đầu đi nghiên cứu cách biến đổi gene loài bò!

Là một người làm kỹ thuật, Purple Cow không thực sự cuốn hút tôi lắm. Nhưng nó đánh dấu những xu hướng gần đây của nền kinh tế, bạn phải tạo ra được những sản phẩm thật sự có chất lượng và thật sự khác biệt, những sản phẩm không thể chỉ được đánh giá là very good mà tự thân nó thôi đã cuốn hút người dùng, không cần nhiều đến quảng cáo. Như khi Steve Jobs giới thiệu iPhone 4, ông ta đã cố tình liên hệ: it’s like a beautiful old Leica camera, dòng máy ảnh ít tính năng, kém hiện đại mà vẫn có khoảng giá trên $6000.

Trở lại với ý ban đầu, con dao gốm thực sự là một purple cow (hay ít nhất với tôi là như vậy). Đã đến lúc phải học cách suy nghĩ để tạo ra những sản phẩm như thế. Khi sự lạm phát đảo lộn nhiều thang giá trị, khi ngay cả chữ very good cũng không gợi lên điều gì đặc biệt, thì đó là lúc học cách làm những điều bình thường nhất, không nhất thiết phải là cái gì đao to búa lớn, một con bò thì cũng chỉ là một con bò, một con dao cũng chỉ là một con dao, nhưng hãy là những con bò, con dao khác biệt mà người ta phải lưu ý và cần đến chúng.

writing on the margins

his is just a post of my truly nonsense and random thought. Some notions are just interesting in their own forms, like writing on the margins or sub luna saltamus – dance beneath the moon… I just particularly like the phrase writing on the margins, the action and its meaning, that’s why this website layout is designed with that notion in mind, the left column is reserved for additional and complementary information, as side notes along main content.

Take a look at the two iPad’s screenshots on the left and you would see how nice it is, writing on the margins in a modern and digital form, especially when you could still use your own handwriting with it. You may have noticed the two classical masterpieces (one in mathematics and the other in literature) referenced in those notes! 😀

ios-widgets

aving written myself numerous UI widgets, from simple to complex, from Windows to Linux, from 2D to 3D… but I’ve just started writing iOS widgets not too long ago. Making iOS widgets is really fun, for we have supports from the most powerful 2D graphics system ever built, that is CoreGraphics (Quartz 2D). The code, hosted on github, is released under MIT license, check it out for a demo project, I hope that these widgets would be useful somewhere, but yes, I know, don’t complain about the code quality, most is written in a rush and still have flaws in it, use at your own discretion!

1.   XFilePathHeader

This tabular header let you quickly browse a hierachy structure (like file system directories). The levels are shown as tabs, tap on a tab to jump to a parent folder, tap on the “Home” icon to jump to root folder.

2.   XSegmentedControl

The Apple’s standard UISegmentedControl only displays text, not image. This class lets you use image along with text (or image or text alone) in any orders (image then text, or text then image).

3.   XProgressTextField

This is a copy of Safari’s address textfield which shows a progress bar while the webpage is loading. Would continue to add more of these miscellaneous tiny widgets just for fun when I have time.

byzero stylus

uch an interesting device I’ve used recently, a stylus for iPad. While stylus like Wacom’s Bamboo is fine for general sketching, it’s not really suitable for fine – grained drawing. This Byzero takes a different approach as it does not use iPad’s touches, but provides its own mechanism. Image on the left: you can see that the pen is actually an ultra sound source, two microphones (and an infrared receiver) in a single piece plugged into the iPad connector port. Pen position detection is done by triangulation on the acoustic signals. This kind of setup can be found on many other things like this 3D laser scanner.

If you use the iPad seriously for taking notes and drawing, a stylus like this is a must, sometimes your thoughts, ideas can only be expressed with a pen: text, drawing and all kinds of presentations on a page. The stylus is sensitive, it can captures any glyphs you draw. However, it’s very irritating that the calibration process is not really exact: pen position is offset – ed by a small varying distance, and with a noticeable delay… This reduces the usability of the stylus much since it’s important to have immediate and correct responses on the screen for user to make micro – adjustments in his hand to produce good writing, drawing.

chẵn và lẻ – chẳng lẽ

Chuyện nó cũng tương tự như với Bám theo lề trái, lề phải là việc của con cừu của giáo sư Ngô Bảo Châu. Người ta cố tình muốn ghép ông vào một bên nào đó, nhưng ông không chọn bên nào cả, cả hai bên đều giống nhau, cùng một kiểu tư duy logic nhị phân cũ rích: không “địch” tức là “ta”, không phải “nhân dân” tức “phản cách mạng”, không tốt tức là xấu, không ngay tức là cong, blahblah… một kiểu trá hình cho cái thật sự là: không giống như tôi (nghĩ) tức là tầm bậy…

Cách suy nghĩ nông dân thiển cận và bần tiện như vậy và những hậu quả trực tiếp của nó tưởng như dễ dàng nhìn thấy, song có rất nhiều người “ngây ngô không hiểu” hoặc không muốn hiểu.

A metaphor for VN software engineering’s status quo, IMHO 😬

Below: Liliputian egg and the metaphor for endianness.

ột ví dụ kinh điển trong làng Tân nhạc để minh họa cho cái tư duy hình thức sơ đẳng và thô thiển phổ biến với người Việt. Cách đây đã lâu, một nhạc sĩ rất có tiếng và có tài sau một thời gian du học ở Liên Xô về đã nói: Văn Cao viết nhạc lẻ nhiều quá!. Thế là bắt đầu một trào lưu âm ỉ và kéo dài nhiều thập kỷ với tư tưởng chủ đạo: phê phán các nhạc sĩ “tiền chiến” sáng tác thiếu chuyên nghiệp, thiếu bài bản, tác phẩm viết ra sao toàn lẻ nhịp. Một thực tế đúng là đến 90% các sáng tác âm nhạc “tiền chiến” là lẻ nhịp.

Và có lẽ cũng đến 90% các tác giả “tiền chiến” là sáng tác ngẫu hứng, tài tử mà nên, chứ ít người thật sự có được huấn luyện trường lớp bài bản (nếu nói về bằng cấp, trường lớp thì e rằng không nước nào bằng Việt nam như hiện tại). Và cũng đúng theo nhạc lý cổ điển (Tây phương) thì nhạc viết ra nên theo luật cân phương, không nên lẻ: để hát nghêu ngao một mình thì không sao, chứ đưa vào ban nhạc, hòa âm, trình diễn lớn sẽ rất khó khăn. “Cái sự lẻ” ở các tác phẩm “tiền chiến” thể hiện những điểm sau:

  • Tác giả đa số là sáng tác ngẫu hứng, ít người có cơ hội tiếp xúc đầy đủ với trường lớp theo kiểu Tây phương.

  • Tuy không bài bản theo kiểu Tây phương nhưng đa số đều mang ảnh hưởng không ít thì nhiều của nền cổ nhạc VN.

  • Sự lẻ nhịp thể hiện tính chất bất ổn của thời đại, một giai đoạn có thể nói là biến động nhất trong lịch sử VN.

Bẵng đi một thời gian, tiếp xúc với âm nhạc thế giới bổng phát hiện ra rằng: âm nhạc Tây phương đương đại cũng lẻ nhịp rất nhiều, rồi quay lại nghiên cứu cổ nhạc VN thì phát hiện ra nó cũng lẻ không kém. Thế là chính những kẻ ngày xưa phê phán người khác “lẻ nhịp” giờ quay sang hô hào: Ah, tui cũng lẻ nhịp, tui đi kịp với thời đại. Đến đây thì mọi người sẽ hiểu ra cái thói tranh luận, cái cách suy nghĩ hình thức VN là như thế nào. Nói chuyện nhạc có vẻ trừu tượng xa vời, quay sang những chuyện cuộc sống hàng ngày, đâu đâu cũng thấy nhan nhản những kiểu tư duy “hình thức” như thế.

Ngay như trong ngành IT mà tôi làm việc, cả ở những dự án lớn nhất, những công ty to nhất, mọi người cũng dành đến 90% thời gian để tranh luận những thứ vô bổ: C hay C++, C++ hay Java, Java hay .Net, nào là Design Pattern hay không, nào là Waterfall model hay Iteration model, nào là Design trước hay Code trước, v.v. Những tranh luận chỉ có thể gặp trong Gulliver du ký: một quốc gia chia thành hai phe uýnh nhau vì một phe ăn trứng từ phía đầu to, phe kia ăn trứng từ phía đầu nhỏ!

Những ai hiểu vấn đề ngay từ đầu chỉ có thể cười mỉm mà thôi, và họ đã đi tới những đâu rồi, code thì vẫn tràn lan những lỗi sơ đẳng kiểu như: mảng (array) bắt đầu từ 0 hay 1 (cũng lại chẵn hay lẻ, có thể các bạn không tin nhưng những lỗi như vậy không ít). Đó là chưa kể một số người không muốn làm việc, ngồi một chỗ bàn chuyện chẵn lẻ, dậm chân cho bụi bay mù rồi tưởng tượng là mình đang chạy! Nói chuyện kỹ thuật sợ mọi người bảo là nó chuyên biệt quá, vấn đề tự lặp lại chính nó trong tất cả những chuyện khác: nhân sự, quản lý, sale… đâu cũng thấy kiểu tư duy như thế.

Có lẻ là do sức lực chỉ vừa đủ dành cho việc nắm bắt một số kỹ năng ngôn ngữ, nên sau khi có được một số danh từ, khái niệm cơ bản… thì họ mắc luôn vào trong đó, không tự vượt lên được. Nó cũng phản ánh một điều, người Việt chúng ta rất háo suy nghĩ hình thức, rất háo những chuyện: tôi là như thế này, người khác là như thế kia, ít người có suy nghĩ độc lập (“độc lập” chứ chưa nói “sáng tạo”), hoàn toàn cảm tính và “bầy đàn”, ít người muốn làm việc, ít người thật sự muốn theo đuổi kiến thức!

vectorial

The classical SVG example rendered using a thin OpenVG layer on top of OpenGL (or Quartz) on a Mac. This is also to say goodbye to the old Lunar year (year of the tiger) that is ending!

inished with my survey on vectorial graphics, in details, about rendering SVG using Quartz, OpenGL (ES) on Mac, iOS and some Android flatforms. I’d had the chances to systematize more my knowledge on vectorial: path, stroke, anti – aliasing, solid, gradient and pattern fill, etc… Todays, people’s all talking about 3D, OpenGL, DirectX, etc… While few mentions much about 2D stuffs, I’ve traced back some historical evolution paths, since I believe that it’s through history would we understand technologies.

In the beginning, there was… PostScript

It was John Warnock who kindled the idea, he joined Xerox in 1978 and an early version of PostScript (named InterPress) became the language to drive a laser printer. Laser printer was then a revolutionary device, which offers extraordinary graphics compared to the capability of dot or matrix printers. Warnock left and founded Adobe in 1982, the company that produced well – known graphics softwares including Illustrator, king of the vectorial editors.

Then there was DPS, PDF and Quartz

But it was Steve Job who realized the superiority of PostScript and urged John Warnock to popularize it. When Steve Jobs left Apple and started NeXT, he co – developed with Adobe DPS – Display PostScript, a derivative of PostScript – the language that drives the NeXT computer’s graphics system. When Steve has got back to Apple, DPS then evolved into what is now known as PDF, and Quartz is the C binding that bridges traditional Unix programmers to the Mac graphics world.

The X window system

The X’s designers also started with a PostScript RedBook in hand. But due to various reasons including the lack of in – depth consensus about vectorial, X maintains until now low level of PostScript support. The X server can only handle basic PostScript commands (it can’t even draw splines). X took a hybrid approach using both vectorial and raster – based solutions to the problem. Also the Unix root has an impact: X is the only true client/server windowing system to the current day.

Until now, the NeXT computer remains an idealistic symbol, pure vectorial remains a pursuit, perhaps for higher – standard devices, such as with this Backbone:

Backbone is an attempt (our attempt) at creating a Really Good Desktop. The metric we use for “Really Good” is our own. In short, to us, to carry on the NeXTSTEP® and OPENSTEP® spirit!

The Windows’ GDI

Born to be the youngest of all graphics systems, GDI learns nothing from it predecessors. Neither it is device and resolution independent (like Macs) nor a true client/server system (like X). GDI sticks to screen and the pixel unit with quite a lot implementation flaws. These flaws won’t become obvious until we come to serious editing, publishing and printing: text documents and graphics designs would never has the on – screen – display and printing qualities we would expect, though various 3rd party softwares would come to rescue somewhat the situations.

Then, things change with time

The 2D graphics systems on Mac, Windows, Unix… all has different origins, and all targets different real – world problem domains. All has hardware acceleration to various levels and qualities, and it’s hard to compare them in some cases. To the present day, no system is known to keep the original idealistic model that uses pure PostScript: X has been mixed from the beginning, Mac & iOS have switched to raster to some extent, GDI is essentially pixel – based. Then come the wind of change! It would be another story, another evolution path, but today, 3D hardwares has become quite popular with reasonable prices. It’s counter – intuitive to treat 2D as a separate part from 3D, and the trend is merging 2D to become a subset of 3D rendering. However, the process hasn’t been very easy, it would take some more time to reach maturity:

  • WPF (Windows Presentation Foundation): first came with Windows Vista, GDI now runs as part of DirectX 3D rendering environment. Vista was not a success indeed!

  • QuartzGL: Quartz2D runs on top of OpenGL since OS X 10.2 (Jaguar). However, QuartzGL is not enabled by default even in the current version (10.6 – Snow Leopard) since it’s still quite buggy.

  • GLX & AIGLX: both has some implementation problems and is competing to each other to become the official 3D extension for X.

Taken an arbitrary GDI’s API (such as MoveTo, LineTo…) we can see the parameters’ type is integer, which is in reality the pixel unit. The Quartz’s counterparts are always in float, a virtual unit so that the APIs can be device and resolution independent.

The so called “GDI printer” is actually a bitmap device, it lacks a PostScript interpreter and hence need to be attached to a computer to do the actual computing. Reason is obvious: cheapness, adding a PostScript interpreter would significantly raise the cost!

jingle hell

First, it’s Jabber, then the open standard XMPP, then libjingle (the thing behind GTalk and several other VoIP applications). An essential part of VoIP, VPN, P2P technologies is ICE (Interactive Connectivity Establishment), techniques that help computers behind routers connect to each other…

ow it’s Christmas time, but this has nothing to do with Xmas except the name: LIBJINGLE. For a long time, I’ve been trying to expose one of my home servers to the Internet. Normally, you’d just need to setup dynamic DNS to update the router IP address and NAT (Network Address Translation) to forward one port onto the server. Unfortunately, my ADSL router is a special (hardware / firmware) version OEM-ed by Comtrend to FPT (the local ISP), and no matter how I configure, NAT is simply forbidden. I’ve tried various techniques to punch holes (TCP, UDP) through NAT, such as this pwnat, a trick to fool the router using ICMP echo packet. However, due to different router implementation & configuration, no technique is known to work in 100% of the cases, as pointed out in this paper.

The NAT traversal problem repeats itself in various applications: VoIP, P2P network, VPN (Virtual Private Network), networking for games… Current technologies take a dual approach in solving this: a certain kind of ICE (Interactive Connectivity Establishment) when two peers can directly connect to each other, or a central server in between in case the routers forbid it all. Such as with libjingle, Google Talk servers are used in case a direct connection can not be made. Remember the Skype’s global disconnect problem lately? It’s the same sort of problem with ‘central servers’. With these knowledge in hands, it’s turned out that setting up a VPN to access my home servers from anywhere is quite easy as follow.

Build libjingle and fwd (a simple wrapper around libjingle). Building libjingle on Debian is a nightmare (yes, it’s a real nightmare, libjingle 0.4 has a nasty code base). It took me a whole day, and after changing several dozens of places in libjingle’s code, I got it compiled and run correctly (please refer to this post for some initial building instructions). Once the transportation channel has been established with libjingle, a SSH tunnel is setup to forward a port on your roaming laptop to the SSHD port (22) on the home server:

# on a server inside your home network, this will forward
# port 2222 to port 22 of another machine (‘buffalo’)
./fwd -u account@gmail.com -p password 2222:buffalo:22

# on your laptop from anywhere on the Internet, almost
# the same command, but the -L option for client mode
./fwd -u account@gmail.com -p password -L 2222:buffalo:22

# then connecting to the ‘buffalo’ box is just setting up
# a SSH session, thus a SSH tunnel inside another SSH tunnel
ssh root@localhost -p 2222

The technique works flawlessly, I can now access my home VPN from anywhere. Basically you’re inside a VPN now, so various setups at home would transparently work (strictly speaking, this is still not real VPN as TCP, UDP broadcasting may not work, but most regular connections would). Next, I proceed to exposing some of my home services onto the outside world. Again SSH proves to be such a very very powerful tool as you can build SSH tunnel inside another tunnel, which can be nested for several layers (ssh is actually means ssshhh! – sign used to signal lowering one’s voice I think):

File sharing

SFTP (Secured File Transfer Protocol) is built on top of SSH, and SFTP is native to any Linux (for Windows, we could use WinSCP, and for Mac is Cyberduck). Just connect to one end of the tunnel like with SSH (localhost:2222) and on the other end of the (nested) tunnels, we get access to the whole file system.

Subversion

SSH is built-in into SVN (I often use SVN by command line rather than WebDAV). Something like: svn co svn+ssh2222://user@localhost/svn/project would do the job, where ssh2222 is defined in your subversion’s configuration file (under the [tunnels] section) as: ssh -p 2222, this instructs the secured shell to connect to the host, then call the ad-hoc svnserve instead of a real web server.

Web Proxy

This is very useful since if helps surfing the Internet securely while you’re in public. After setting up Squid web proxy on the same server, the command: ssh -N -L 8080:localhost:8888 root@localhost -p 2222 tells SSH to forward the local port 8080 to the proxy port 8888, then pointing Firefox at localhost:8080 would secure our traffic more than enough (2 levels of nested tunnels and 2 levels of port-forwarding).

Music streaming

I use this to casually enjoy my music collections while not at home. Install FireFly (formerly mt-daapd) music streaming server and forward the default port 3689, then I can listen my favorites songs anywhere using Rhythmbox (Linux). And since the protocol (daap) is originated from Apple, listening is also natively available on any Mac machines using iTunes.

whatever happened to programming?

There’s the change that I’m really worried about: that the way a lot of programming goes today isn’t any fun because it’s just plugging in magic incantations – combine somebody else’s software and start it up. It doesn’t have much creativity. I’m worried that it’s becoming too boring because you don’t have a chance to do anything much new… The problem is that coding isn’t fun if all you can do is call things out of a library, if you can’t write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who’d want to go into that as a career? (Coders at Work – Peter Siebel, quoting Donald Knuth)

Ví dụ về chức năng đơn giản nhất: resize ảnh trên các browsers, ảnh trên: Firefox, ảnh dưới: Chrome, (ảnh được chụp lại và hiển thị nguyên kích cỡ từ 2 browser, cả 2 dùng cùng một ảnh gốc kích thước lớn). Có thể thấy chức năng resize ảnh của Firefox, IE kém rất xa so với các browser khác.

hatever happened to programming? Điều gì đã xảy ra với lập trình? Khi ở năm 1 đại học (1998), tôi có viết một 3D engine đơn giản bằng Borland C, lúc đó sách vở thiếu, internet thì chưa có. Mục tiêu đặt ra rất đơn giản: hiển thị (xoay) một đối tượng 3D đọc từ file mô tả tọa độ các đỉnh. Bằng những hình dung hình học đơn giản, tôi xây dựng một phép chiếu: giao điểm của đường thẳng từ mắt tới các đỉnh của vật thể với mặt phẳng chiếu chính là pixel được hiển thị trên màn hình. Sau đó ít lâu đọc thêm tài liệu, tôi mới biết đó gọi là: phép chiếu phối cảnh – perspective projection. Một số đoạn code released từ game Doom giúp tôi hiểu rõ hơn kỹ thuật chiếu dùng trong game thực: ray casting.

Sau đó 1 thời gian bắt đầu có internet, chúng tôi lại “say mê” tìm hiểu các kỹ thuật graphics “tối tân” hơn. Còn nhớ lúc đó có trang web winasm.net, nơi chỉ vẻ rất nhiều về Gouroud, Phong shading, light, bump mapping, sprites… Chúng tôi đọc các code viết chủ yếu bằng Assembly, rồi viết lại bằng C/C++ trong cái “engine” của mình. Chuyện là như thế, chúng tôi “nghĩ gì viết nấy”, đa số các trường hợp là “phát minh lại cái bánh xe”, bắt đầu bằng việc tự xây dựng những mô hình, thuật toán “ngây thơ” trong đầu. Cái “engine” của tôi so với các engine chuyên nghiệp bây giờ thì thật đáng xấu hổ, nhưng ít nhất chúng tôi hiểu những ý tưởng, nguyên tắc vận hành cơ bản.

Những điều kể ra trên đây chỉ mới là a, b, c… trong computer graphics, lĩnh vực có rất rất nhiều thuật toán, kỹ xảo, mánh khóe… hấp dẫn và độc đáo. Còn nhớ vì ham thích viết các chương trình đồ họa và xử lý ảnh nên một số môn khác tôi không chú ý tới. Như các môn AI, có lần tôi copy code của một người bạn về nộp làm bài tập (đã được cho phép). Đó chỉ là một chương trình chơi caro (croix-zero) dùng thuật toán A*, nhưng vì cúp cua nên tôi không biết về A*, ngồi cả đêm đọc xem cái chương trình đơn giản đó làm cái gì nhưng vẫn không tài nào hiểu được. Sau đó “bổ túc kiến thức” thì biết là A* cũng chẳng phải là điều gì phức tạp, nhưng nếu không có ý tưởng về thuật toán trong đầu… thì code cũng như một đám rừng chẳng cho anh biết được gì về nó.

Sau đó tôi viết nhiều về xử lý ảnh, tới đây thì nền tảng toán trở nên quan trọng, đa số các khái niệm là đủ phức tạp để không tự hình dung bằng trực quan trực giác được. Nhưng nghiên cứu kỹ lưỡng chút thì rồi chúng tôi cũng hiểu được ý tưởng đằng sau các khái niệm convolution, high – pass, low – pass filters… Nhờ những kiến thức đó mà bây giờ tôi có thể có được những nhận định đúng hơn, ví dụ như một chức năng tưởng chừng hết sức đơn giản như resize ảnh, nhưng cho đến tận bây giờ vẫn chưa được implement đúng trên hầu hết các trình xử lý ảnh phổ biến: GIMP, Photoshop… Có thể các bạn không tin điều này, nhưng GIMP, Photoshop, Firefox… resize ảnh bằng giải thuật tuyến tính nên có thể bỏ đi những thông tin quan trọng, và giữ lại những pixel không quan trọng.

Một số kỹ sư phần mềm nói với tôi: suốt nhiều năm đi làm chưa bao giờ anh ta phải cài đặt một thuật toán nào đã học ở trường, việc lập trình hiện tại chỉ là lắp ghép các module, library ở high – level, rất ít khi đụng đến bản chất thật low – level bên dưới. Tôi cũng đồng ý như thế, một số dự án đơn giản là làm việc ở high – level, không phải sản phẩm nào cũng đòi hỏi kỹ năng sáng tạo, đòi hỏi kỹ sư có hiểu biết sâu về các thuật toán chuyên biệt. Nhưng nói như vậy không có nghĩa là những kỹ năng đó không cần thiết và không quan trọng. Nếu không có những kỹ năng đó thì mãi mãi chúng ta chỉ làm được những công việc “làng nhàng”, thậm chí những công việc “làng nhàng” cũng đòi hỏi những khả năng know – how, tổ chức code nhất định. Trong nghề lập trình tôi vẫn ưa thích kiểu người hay “đi phát minh lại cái bánh xe”.

Thế nên mới biết là những điều nói ra càng đơn giản thì lại càng không đơn giản! Nhiều engineer trẻ tôi gặp sau này thường không có sự quan tâm tới những yếu tố đơn giản và cơ bản như thế. Dĩ nhiên những điều trên đây chẳng có gì to tát, cũng như đa số các vấn đề lập trình cũng không phải là điều gì lớn lao. Nhưng trước hết hãy cho tôi thấy bạn có hiểu biết cơ bản về vấn đề mình đang làm, đừng gọi hai vòng lặp for lồng nhau là: “thuật toán”, hãy có khả năng đọc hiểu mô tả của thuật toán và biến nó thành code chạy tốt… trước khi phán đó là những điều cơ bản không cần để ý tới. Tất cả bắt đầu với suy nghĩ của chính mình, với cái mô hình và trình tự trong đầu mình, chứ không phải bắt đầu với danh sách các khái niệm, chữ nghĩa, API… mà anh thậm chí không hiểu nội dung đằng sau nó! Sau đó thì mới có thể nói đến ý tưởng, điểm mạnh điểm yếu, chỗ dùng được (không dùng được) và sự khác biệt của các công nghệ!

Một cách rất quan trọng để hiểu công nghệ không phải là từ thuật toán, ý tưởng, mà là từ… lịch sử. Nếu quan tâm đọc lịch sử computer graphics, bạn sẽ biết đằng sau “Phong shading” là Bùi Tường Phong, một người Việt. Hay bạn sẽ hiểu tại sao SGI (Silicon Graphics Inc.) có nhiều ảnh hưởng đến thế, tại sao những phong cách, sản phẩm của công ty đó lại thiết đặt nên những tiêu chuẩn vàng trong cộng đồng computer graphics (ví dụ như OpenGL), tại sao máy Mac dùng UEFI chứ không dùng BIOS, tại sao NextStep và OpenStep dùng “vector display” chứ không phải là “bitmap display” như đa số các windowing system khác… Sự phát triển của công nghệ là một quá trình tiến hóa liên quan tới những yếu tố xã hội và con người, chứ không đơn giản là sự phức tạp hóa các ý tưởng kỹ thuật!

technical debt

Các yếu tố nội tại ảnh hưởng đến sự thành bại của một dự án phần mềm, chưa nói đến các yếu tố ngoại cảnh…

Những gì nhắc đến trong bài này không phải là “rocket science”, cũng chưa đáng gọi là công nghệ tối tân. Đó mới chỉ là các kiến thức cơ bản mà đa số có thể học được ở nhà trường, cộng với kinh nghiệm sau một vài năm làm việc! Tại sao thực trạng đa số coder Việt Nam như tôi thấy lại ảm đạm đến vậy? Những gì họ học được đều hình thức, hời hợt, nằm trên bề mặt con chữ và khái niệm suông, ít người có được kiến thức thực dụng khả dĩ tự làm được những product mới!

Một phần là do đa số coder làm việc trong những dự án out-source, code họ viết thường là những đoạn nhỏ không quá 1000 dòng, thêm vào trên khung sườn do người khác viết sẵn! Phần khác là khả năng tự tìm tòi, tự giải quyết vấn đề bằng chính suy nghĩ của mình. Nếu họ biết tự thử nghiệm những project cá nhân nhỏ cỡ 30 000 ~ 50 000 LOC chứ không copy & paste code thì kinh nghiệm, độ nhạy bén trong cách tiếp cận & giải quyết vấn đề, khả năng sử dụng ngôn ngữ & công nghệ của họ đã khác!

Một lý do nữa là do cách dạy, cách học từ chương chỉ giúp cho sinh viên có được một mớ ngôn từ, khái niệm trống rỗng mà không thực sự hiểu nội dung sâu bên trong của chúng, và càng không biết các cách ứng dụng, kỹ xảo dùng trong thực tế. Đa số né tránh các bài toán cấp thấp và cụ thể, thích sử dụng các thư viện có sẵn với lý do don’t reinvent the wheel – đừng phát minh lại cái bánh xe. Cách ngụy biện đó vẫn đứng vững cho đến khi chúng ta đi chế tạo cái xe thì phát hiện ra đến cái bánh chúng ta cũng chưa làm được!

echnical debt là một ẩn dụ đôi khi được dùng trong ngành công nghệ phần mềm (CNPM), và là ẩn dụ đúng nhất cho thực trạng CNPM Việt Nam hiện tại. Phát triển phần mềm cũng như mọi công việc kinh doanh khác, về bản chất giống việc vay nợ, tức hiệu suất sinh lời phải đủ để trả lãi và quay vòng vốn trong một khoảng thời gian nhất định. Dĩ nhiên các yếu tố kỹ thuật khó lòng có thể được định lượng như tiền bạc, nhưng theo một nghĩa nào đó, nếu tỉ lệ các vấn đề được giải quyết thấp hơn so với tỉ lệ các vấn đề phát sinh, thì điều đó có nghĩa là dự án đang “tăng trưởng âm”. Tuy mượn một thuật ngữ từ lĩnh vực kinh tế, song “nợ kỹ thuật” thuần túy đề cập các vấn đề kỹ thuật như được trình bày sau đây:

NỢ LOẠI I

Đây đơn thuần là sự yếu kém về khả năng kỹ thuật và khả năng hiểu biết làm chủ công nghệ. Sự yếu kém này gồm nhiều dạng:

Kỹ năng cơ bản: có lần một senior engineer có 6 năm kinh nghiệm hỏi tôi về một khai báo C++ như sau (nằm trong file .cpp):

int CSomeClass::m_someVariable = 1;

Sau 1 phút xem xét vấn đề, tôi hiểu ngay là người này không biết cách khai báo “static member variable” trong một “C++ class”, anh ta nghĩ nó cũng giống Java, chỉ cần khai báo trong định nghĩa class (file .h) là đủ.

Khả năng am hiểu công nghệ: một lần khác, một technical manager trình bày với tôi về 3D, OpenGL… anh ta nói rất nhiều về các khái niệm, thuật ngữ, danh sách dài các API. Nhưng chỉ sau một vài câu hỏi, tôi biết ngay người này không hiểu cách thức hoạt động cơ bản của một 3D engine, chưa nói đến các chi tiết phức tạp của một 3D driver. Mãi 4 tháng sau đó, sau một quá trình mày mò, anh ta mới bắt đầu hiểu ra những yếu tố đơn giản như: các hàm vẽ 3D không làm việc cùng một cách như các hàm vẽ 2D.

Sự yếu kém của các coder Việt nam tập trung nhiều vào nhóm Nợ loại 1. Những kỹ năng cơ bản cần phải được đào tạo thật kỹ, không phải chỉ là lý thuyết mà còn là các kỹ thuật, kỹ xảo ứng dụng thực tế. Nó giống như một người nói về kiếm, dĩ nhiên anh ta có thể nói về các “kiếm chiêu”, “kiếm pháp” anh ta học (đọc) được ở đâu đó. Nhưng điều này hoàn toàn khác với chuyện anh ta có thể dùng kiếm để chiến thắng những đối thủ (dự án) khó khăn, sừng sỏ!

Yếu kém về kỹ năng cơ bản kéo dài thời gian thực hiện những feature nhỏ, làm không đúng cách khiến phải làm đi làm lại nhiều lần. Tôi đã thấy một người implement một UI’s button: đơn giản chỉ là vẽ một cái nút với 1 dòng text & image. Anh ta không thực sự hiểu nó làm việc như thế nào, anh ta copy code từ đâu đó. Có thể các bạn không tin nhưng đó là sự thật, cái button được sửa đi sửa lại suốt 6 tháng mà vẫn chưa hoạt động đúng!

Sự yếu kém trong hiểu biết công nghệ cơ bản dẫn đến nhiều hệ quả nghiêm trọng hơn: định hướng sai, không hiểu các yêu cầu hợp lý và không nhận ra những yêu cầu phi lý của khách hàng, phí phạm tài nguyên cho những bước đi sai lầm. Hậu quả nhẹ nhàng nhất là: chỉ giải quyết được vấn đề trong một số tình huống phiến diện, thiếu bài bản. Nhưng thường thì hậu quả không tốt đến thế: làm sai lệch các hiểu biết chung của dự án, sử dụng công cụ, công nghệ không đúng chỗ, đặt ra những mục tiêu không tưởng, không có thật.

NỢ LOẠI II

Là những quyết định sai lầm (về kỹ thuật hay quản lý) dưới các áp lực từ phía kinh doanh hoặc từ những độ đo, cách đánh giá không phản ánh sự thật, duy ý chí.

Một ví dụ nhỏ: sau khi định hướng, khung ứng dụng được dựng lên trên nền một “3D test driver”. Bản thân driver là một “school project” có cải tiến chút ít, bản thân ứng dụng được viết trên một số giả định về các khả năng mà driver và hardware có thể cung cấp. Sau khi test, ứng dụng không đạt yêu cầu, và do đó quyết định optimization được đưa ra: chúng ta biết việc này ảnh hưởng đến kiến trúc cơ bản và lâu dài của software nhưng trước hết nó phải pass được 1 số measures nhất định!

Dĩ nhiên người có kinh nghiệm sẽ hiểu ngay là các độ đo đặt không đúng chỗ: driver và application mới chỉ là những code đơn giản, khó lòng có thể optimize nhiều, hardware 2D cũ hoàn toàn không đáp ứng, thậm chí là không tương thích dù là trong concept với các yêu cầu 3D mới. Và cũng không khó khăn để nhận ra: dường như với tác giả cái “3D driver” này, đây mới là lần đầu tiên ông ta thử nghiệm các kỹ thuật 3D, dĩ nhiên các concepts “bài bản” vừa học được đều rất đẹp cho đến khi người ta biết rằng 1 “real world project” hoàn toàn khác 1 “school project”.

KẾT LUẬN

Những món nợ kỹ thuật dù lớn, dù nhỏ đều góp phần ảnh hưởng tới hiệu suất và sự thành bại của dự án. Tất cả đều có chung nguyên nhân: chất lượng nguồn nhân lực! Các thành viên cần phải được chuẩn bị (kiến thức & kinh nghiệm) cho vấn đề mình đang giải quyết, từ khâu design đến coding, cho đến các scopes & milestones của dự án. Trong một dự án nhiều người, nhiều giai đoạn, tất cả những món nợ này được tích lũy theo cấp số nhân: sửa sai trên những code sai của những định hướng sai… và kết quả là lãi mẹ đẻ lãi con và nợ trở thành không trả nổi.

career’s funs – 8

he computer industry is the only industry that is more fashion – driven than women’s fashion. (Larry Ellison) => right, so much dogmas, lies and myths.

Well, it has been said over and over again that the tremendous cost of programming is caused by the fact that it is done by cheap labor. (Edsger W. Dijkstra) => needless to say, another so true dilemma!

I do believe I have post-traumatic Java syndrome. (Renae Blair) => me too, though not very serious!

One of my most productive days was throwing away 1000 lines of code. (Ken Thompson) => with me even more

Deleted code is debugged code. [Jeff Sickel] => 😬

Before code can be reusable it first has to be usable. (Ralph Johnson) => certainly!

The goal of Software Engineering is to build something that will last at least until we’ve finished building it. (unknown) => applied to many projects!

Better train people and risk they leave – than do nothing and risk they stay. (unknown) => it’s worse when they stay and untrained!

Benchmarks don’t lie, but liars do benchmarks. (unknown) => countless cases!

Why do we never have time to do it right, but always have time to do it over? (unknown) => the question answers itself!

Evolution always seems to win out over revolution when it comes to technology. (Rick Hightower) => don’t believe in one who screams for revolution!

If you have too many special cases, you are doing it wrong. (Craig Zerouni) => solving is not creating more problems (special cases = problems)!

C++ is popular because it is like C. Java is popular because it is like C++ and C. C# is popular because it is like Java. See a pattern! (Rick Hightower) => many techies fanboys forgets this!

What it comes down to is that Rails developers are just that: they’re not software developers, at least not most of them… Their framework dictates how their systems are designed instead of the problems the systems are designed to solve. (Samuel Tesla) => said this several years ago

Suppose you went back to Ada Lovelace and asked her the difference between a script and a program. She’d probably look at you funny, then say something like: Well, a script is what you give the actors, but a program is what you give the audience. (Larry Wall) => 😀

The structure of software systems tend to reflect the structure of the organization that produce them. (Douglas Crockford) => 😀 absolutely!

engineering dogmas

ver the years in our software community, I’ve seen a lot of dogmas, myths and lies that spread like ‘cholera’. That only reflects the fact that many programmers just repeat like parrots what they ‘learned’ from school, news, books… without their own justification, and to some extent, reflect their lacking of experiences. A good engineer should, at least, have some abilities to judge the pros and cons, weak points and strong points, when to use, and when not to use a method, a language or a technology.

Design first, then code!

The principle is, in general, not wrong. However, pragmatically, a software’s final structure, architecture… is not achievable as product of an immediate thought or a single design cycle. In most cases, the “first design” is certainly not the correct one. It’s not in a deterministic process that we can build software, complex product would always requires a lot of trial and fail. And from my experiences, good designs are sustainable solutions after a tedious process of experiments to eliminate wrong directions. We need coders of strong analysis and experimental skills rather than the “evangelic designers”!

Where are the documents?

We are going to make clear distinction: do we need coders who really understand what they are doing, or we just need some paper to present to customers? In countless cases did I see that coders do not understanding what they are doing: they don’t understand a feature, they don’t know how to archive that, they are unable to judge the pros and cons, they just mechanically copy and paste code from somewhere. Documents only provide rough, general views on the matters. If you’re going to mention about a static-web-page project, I would agree that document is something. But if you’re mentioning system programming, it’s the code that is the document!

Poor skills and wrong knowledges

This is simply put: countless! Just to name a few:

Poor skills: once, a coder being asked to fix a “null pointer exception”. What he did is adding a “if (pointer != NULL)” line into the code. It’s not fixing, it’s just hiding, fixing is find out why the pointer is NULL, not prevent it from being executed! Another time, another coder, getting frustrated under a crash situation, place a “try… catch” around the buggy code segment. This is again, not fixing, with this way of hiding, we’re just going to accumulate faultinesses until the software crashes silently for no reasons!

Object oriented programming rules: OOP is more beautiful in theory than in practice. OOP provides a nice way for modeling, but it come at costs: bloating code. It is not until the project grows above 1M LOC that OOP become a burden, that we would need to do the “functional decomposition” optimization tasks. It’s the execution (functional) tree that decides performance, not the inheritance tree that obscures runtime characteristics!

Design pattern rules: this is again, not true! I agree that patterns reflect some good coding practices, but software could never be built from the so call “patterns” (there hasn’t been any such proven process). I really don’t understand what is a “singleton” if it’s essentially (in C/C++ syntax) a static variable, I also don’t understand what we need from a “factory” if it’s essentially a “switch… case” structure!?

Management myths

Managers tend to forget what they’d learned when they were coders. There’re lots of myths in software management, just some examples:

  • Software people is of a same type and the same background.

  • We already have a book that’s full of standards and procedures for building software. That provide out people with everything they need to know!

  • If we get behind schedule, we can add more programmers and catch up.

  • Project requirements continually change, but change can be easily accommodated because software is flexible.

There have been extensive criticisms on various OOP models and OOP implementations (Java, C#, C++, MFC, Objective C, glib…) The AntiPatterns wiki and many other authors provide good anti-examples on the uses of patterns!

Linus Torvalds, being criticised: “the kernel has no obvious design”, had replied: “Linux is evolution, not intelligent designs”! The same applied for similarly complex projects!

Document is for understanding, but is not the understanding itself.

Software project management is the domain of vast diversity! No simple rules applied to a software process!

career’s funs – 7

If programming languages are cutleries, still some high respect for Ruby… My experience is that if some languages or technologies come with much bells and whistles, noone would mention about them in the next few years. I just need to keep with me a katana!

here are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. (Charles Antony Richard Hoare)

A good programmer is someone who looks both ways before crossing a one-way street. (Doug Linder)

Being abstract is something profoundly different from being vague… The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. (Edsger Dijkstra)

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. (Nathaniel S. Borenstein)

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates)

There are only two kinds of programming languages: those people always bitch about and those nobody uses. (Bjarne Stroustrup)

The C programming language, a language which combines the flexibility of assembly language with the power of assembly language. (unknown)

The last good thing written in C# was Beethoven’s Moonlight Sonata. (unknown)

The problem with using C++ … is that there’s already a strong tendency in the language to require you to know everything before you can do anything. (Larry Wall)

A system composed of 100,000 lines of C++ is not be sneezed at… The real test of OOP will come when systems of 1 to 10 million lines of code are developed. (Ed Yourdon)

Computer language design is just like a stroll in the park. Jurassic Park, that is. (Larry Wall)

3d particles

ome funs with 3D effects. Just some years ago, rendering 3D particles like water, smoke, fire, fog… was an extremely hard task. I remember how struggling it was for me to build 3D models for a waterfall (with moving water) or a shouting-crowd stadium. It’s enjoyable to see how graphics has advanced in the past few years, these effects are now easily achievable.

Video above: the classical Utah teapot with steam coming out from its spout, rendered with Panda3D, the well-known open-source game engine originally released by Disney, which has a feature-rich C++ core with Python scripting for application development.

basic algorithms

The book is my primary source of interest while being a freshman, which presents a wide range of algorithms in a very coherent and systematic way. I remember “rescuing” this hard-copy from a Fahasa‘s junk pile for about 4 USD, which from that time on became a student’s most precious thing! You can read the soft-copy here.

his is among the subjects I was very fascinated the early years at university: algorithms, graph theory, geometry, image processing… I was not quite good at “symbolic” math (like algebra), but “visual” math offered me much inspiration. The thing I would remember most is Robert Sedgewick‘s Algorithms, a book that I’ve read through over and over again many many times. It is indeed the most important Computer Science textbook that beginners MUST read until today.

The Java applet below is “refurbished” from the code I wrote the first year at college, which visualizes the nature of different sorting algorithms (original code was written in Borland C++ 3.1 with BGI – Borland Graphics Interface). This is among my various attempts to visualize the knowledge collected from the book, which had taught me that even a simple thing like “bubble sort” is not that “very simple”! Let select an algorithm in the dropdown list and click ‘Start’ and see the differences!

My visualizations above are very early (1997), much prior to those demonstrations on wiki. Later on, I’d learned that the author R.Sedgewick put a great emphasis on algorithms’ visualizing himself, his work used PostScript. Many new ways of visualization are really impressive and easy to understand, such as this (using JavaScript).

I started with with C/C++ at school, then continue with C/C++, Java, Design Patterns… on various projects. Later I abandoned Design Patterns (and Java), then I abandoned C++. To me there’s no Design Patterns, there’s only data structures and algorithms! Would write another post on the bloating and non-sense usages of Design Patterns later on!

It seems that most software engineers today lack fundamental knowledges and skills. It’s quite apparent that you could not rely on a guy talking about architecture, GoF’s design patterns… all the time but can not state the algorithmic differences between a DFS (depth first search) and a BFS (breadth first search).

parallax

“3D clip” made by myself just for fun, strictly speaking, this is not 3D video but rather a pseudo – 3D effect, parallax, (tiếng Việt: thị sai) created totally from still images (see on the left). My video is partially inspired by this excellent CSS – only parallax. It’s quite easy to figure out how to acquire this, but let read about the definition from wiki.

This is also a popular technique in game programming, some early (and current) games choose to reduce a full 3D scene to several layers, some use parallax – mapping to acquire a pseudo – spatial effect, all helps eliminating excessive 3D computations. Clip made from random still images captured at Khe Gà, Phan Thiết.

3d graphical user interface

The code is written in C++ base on Clutter 1.2.4 library. It shows basic widgets: tabbed container, scrolling container, list box, combo box, check box, edit box, button, label, radio button…

1. If you just want to add some eye-candy effects with the cost of a much more complicated GUI with “unorthodox” ways of representing information, that would be a very bad idea! The best way to understand graphics is not digging into math books, but rather computer graphics history, the ideas behing the NeXT computer, PostScript, PDF, NeWS & X windows system, Quartz & Cocoa…

2.1 Hardware with only a framebuffer and some blitting, blending devices.

2.2 Hardware with some 2D vector calculating abilities.

2.3 Hardware with different 3D calculating abilities supported in their GPU. Take a look into the Mesa3D code to understand how the graphics pipeline hardware & software stack works.

3. I suggest that a graphics developer should try coding a complete module by himself from scratch, for example: orthographic or perspective projection module, bump mapping implementation, light ray tracing model… to gain working experiences himself.

his is my personal project in which I tried to evaluate some new ideas and concepts in using 3D techniques for GUI (Graphical User Interface). It’s quite tiny indeed (about 6000 LOC – line of code), all written by myself in about a month (mostly in my free times at weekends). So please don’t blame me on some un-completed or un-polished features, they are just for testing the ideas only. I would try to examine the trend of applying 3D graphics to GUI, but first, let have a look at the video below.

1.   The first thing to consider is not 3D engines or hardwares, it is about usability. Many traditional (2D) GUI out there are already complex and obstructive. GUI is about information presentation and presentation should be really simple and clear so that even my grand mother can understand and use. I’ve been seeking, trying to explore many new ways invented to represent information in 3D (or 2.5D) space, and I could say only a very very small percent of them could make a usable value. Users have long been familiar with 2D, and yet 3D hasn’t been very much persuasive.

2.   3D hardwares can be categorized into 3 groups (as listed on the left), and the 3D engine can be configured to off-load calculations to hardware. With the 1st type of device, only bitmap operations could be off-loaded. With the 2nd type of device, many drawing operations (the path_xxx functions) can be off-loaded. The 3rd type of hardware is most valuable since we can have its finish for ourselves a lot of work.

It’s important to understand the target device our software stack would be running on. If it is an out-date machine with just some blitters, we should use paint-like (aka: bitmaps) operations, while on most modern PC, draw-like (aka: 2D vector) operations are more encouraging. While bitmaps may offer nicer and more customizable GUI, the cons is it lacks the scalable ability that vector has.

3.   The last is about software implementation. Many of the graphics concepts are first introduced in software, which then embedded to hardware, which then standardized by software (like OpenGL or DirectX) again. Thus, many elements of a graphics pipeline is the production of a long history of interactive evolution. A graphics pipleline is not a general framework, it depends on very detailed, in-depth techniques to be operational in real-world application.

Game & graphics are the domains where most formal software methods would easily failed. 3D graphics developers should have good knowledge on graphics in general (bitmap and vector drawing), geometry, linear algebra & discrete maths, deep understanding on data-structures and algorithms… are strong pluses, advanced tips & tricks in coding and optimization is a must (game & graphics programming has always been a hell of tricks from the age of dawn) and finally good understanding on 3D techniques (model, scenegraph, projecting, shading, clipping, lighting, effects…)