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.

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! 😀

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

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.

verlet integration

little fun with gaming physic, written using Three.js, the 3D library built ontop of HTML5 and WebGL. Physics engines like ODE or PhysX support a wide range of simulation: rigid body, soft body objects… While those engines are powerful, they are somewhat weak in scalability, e.g: to simulate the flag below, we need to create an array of hundreds of objects, which may not really feasible on small devices.

This demo tries its own physical calculation called Verlet integration: numerical method to apply Newton’s second law of motion to a system of point masses. Verlet integration, despite its complicated formal description, is simple enough to be calculated and executed in real time on the low end mobile devices.

The demo works best on Chrome but it should work on any browser that supports <canvas> (try dragging the flag to add some motion).

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!

the world is not flat

The book title reminds me of the same stupid question: how to put an elephant into a refrigerator. I still insist that you can not put a normal elephant into a normal refrigerator, no matter how people is arguing about that! The question: how to eat an elephant (answer: one bite at a time) actually makes more sense to me!

would tell you how I usually encounter a dialogue taken place in Vietnamese, a pattern that repeats over and over again, and people never learns a thing, neither do they actually have a little sense about real things behind it. Here’s how the dialogue would go on, taken an example to describe the pattern: A (a certain person): I’ve recently read the book “The world is flat”, and really love it! Ah ha, the world is truly flat!   Me: No, the world is not flat!   A: I would suppose you don’t mean it geographically, think about it like a metaphor to get the philosophy of the book, man!   Me: No, the world is not flat!   A: You never get a thing, you crazy!

By now, anyone with a second thought should recognise my meaning either geographically or metaphorically. After that I asked him something into the content of the book. It turned out he knows almost nothing of the book except its name, and parrots the name as if he had found a “holy truth”! Yes I would certainly understand, while everyone was reading and everyone was saying the world is flat, he wouldn’t dare saying (or even thinking) the opposite. My opinion about the book could be right, or it could be wrong, but actually I won’t argue on the surface of phrases, flat or not flat is just a matter of words, what important is the book’s content.

I’d read through the more than 300 pages of the book which takes its examples, facts… exclusively in the Information Technology contexts, either in India, China or other Asian, Latin countries. It is full of details of only the IT industries, details about out – sourcing, internet, software work flow, email, network phone… the things usually seen in outsourcing service. Obviously the author meant a similarity for other fields, other industries, which seems to be a too restrictive point of view, we all know that IT in fact is only a very small fraction of the economy (taken the VN textile industry alone for an example, its estimated yearly revenue is roughly 12 ~ 15 times bigger than the IT counterpart).

The book concentrates on globalisation: the trends of out – sourcing, the way people communicates, the way firms process information… The author propagates it as “a way to be”, a trend, a life style that is absolutely irreversible. Also Friedman considers open source software the most disruptive force of all of the trends since it allows knowledge to be freely distributed and decentralised efforts could be cooperated. Friedman also encourages young American to become scientists, engineers, mathematicians… leaving low – level labour jobs to other countries. The author also tried to relate those vast details with other profound social and political problems.

I have never read anything so “colonial” like that book. It takes a lot of facts, truths… in a small sector of the economy and tries to provide a biased and exaggerated point of view. To exactly quote the author: When the walls came down, and the windows came up, windows can not come from thin air, there’re always “invisible” walls somewhere, and most of the times, those invisibles are much more overwhelming than the visible ones. In fact the book only receives “warm appreciations” in the field it’s related with, and aiming to, that is IT, it does tremendously receive negative reviews right in the country of its author (you can easily check out the web for that).

The world has never been flat, anywhere, anytime. It’s not flat in the sense of people about their living conditions and standards. It’s not flat in everyone’s mental and psychological status. It’s not flat in different life styles, in people’s hugely diverse definitions and pursuits for happiness. It’s not flat even in the American (or any Western) societies, whose tradition has always been the supporting for personal values, think and do differently. It’s not flat as human as a physical and mental objects are bounded to geological and social constraints, and human is more a complex creature rather than, over copper wires, a piece of (possibly cleverly falsified) transmitted information.

Friedman is right that there have been dramatic changes in the global economy, in the global landscape; in some directions, the world is much flatter than it has ever been, with those in various parts of the world being more connected than they have ever been, but the world is not flat… Not only is the world not flat: in many ways it has been getting less flat. (Nobel Prize – winning economist Joseph Stiglitz)
The popular expression that a capitalist will even sell you the rope you need to hang him with seems to be becoming increasingly true. Aronica and Ramdoo’s book is an important addition to the literature of globalization and a necessary therapy for all those whose minds have been in touch with Friedman’s glib phrases. (blogcritics.org)
After reading the book, I got the feeling that Friedman would even sell you the rope to hang yourself (not him) and I’ve thought there’s quite a lot of people who would willingly buy the rope!

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!

kindle development without kdk

DK, the Kindle’s Software Development Kit has been released for quite some times but Amazon still strictly restrict accessing to it, many many software developers (like me) have registered and received no reply. It is understandable that Amazon could be skeptical on what to put on Kindle’s app store, but it should not be that conservative toward the developing community. KDK is basically just a PBP (Personal Basic Profile) J2ME (Java Micro Edition) with Amazon’s extension, a Kindle emulator, and some tools…

Having no KDK doesn’t mean that we can not develop software for Kindle! Below are my notes on building, deploying an example application for Kindle. This would make cleared the steps needed to write applications for Kindle without the KDK. Please notes: the information is collected from many different sources, jailbreaking could be considered “illegal” according to some Term Of Use. Use the information at your own risk!

1.   Jailbreaking and usbnetwork

Download kindle-jailbreak and kindle-usbnetwork from here. Choose the files that is suitable for your device, e.g: for my Kindle 3 (wifi + 3G), it would be the jailbreak_0.4.N_k3g and usbnetwork_0.27.N_k3g. Copy the jailbreak_0.4.N_k3g file to your Kindle, then proceed to updating the system. The jailbreak exploits a hole in Busybox implementation to gain root access. Next, do the same thing with usbnetwork_0.27.N_k3g, which provides a secure shell via USB connection.

Launch the Search box on our Kindle, type ;debugOn, press enter to execute the command, then do the same thing with ~usbNetwork to start the sshd daemon. The default configuration would set Kindle to 192.168.2.2 and expect the connected PC to be 192.168.2.1. Now we’ve got root access and the entire FS (file system) in the palms of our hands. Spend some times exploring it, when done, put the Kindle back to normal use by issuing ~usbNetwork again, then ;debugOff.

2.   Key and file signing

This is the most important part! Kindle’s “kindlets” are exactly Java’s jar file with .azw2 extension, however, we can’t just simply copy and run it. The applet is linked against several system libraries located at: /opt/amazon/ebook/lib/Kindlet-1.1.jar and /opt/amazon/ebook/sdk/lib/*.jar (copy these files to your PC for local jar building in place of those provided by the KDK).

The .azw2 file must also be signed with 3 different keys located at: /var/local/java/keystore/developer.keystore and the security policy is defined at: /opt/amazon/ebook/security/. For more information on signing, please refer to this post. If you’re tweaking your Kindle and writing apps for it, I suggest that we would just use the signing key of Andrew de Quincey, the first one to figure out about this, so that free softwares can be easily shared among Kindle’s users.

Configure the usbnetwork interface and access Kindle via sshd. Image below: the command htop running on Kindle’s ssh console.

When finished with hacking, we can un – install these two exploits to restore Kindle back to original state (and receive official updates from Amazon), but that would be after the next section, when we’d been able to deploy our own software on it!

3.   KindleGoban – an example app

I’m going to deploy KindleGoban, a Go (weiqi) game viewer, as an example app. Adrian Petrescu, the man behind this open source game, is perhaps, an insider of Amazon’s KDK project. But technically he’s under a NDA (non disclosure agreement) and won’t be able to say anything except the publicly available information. However, he did indirectly provide valuable resources.

First, copy the developer_keystore (mentioned in #2) to your PC & Kindle (at /var/local/java/keystore/developer.keystore). Then download KindleGoban (and its dependency library KWT. Make some changes to the build.xml to include KWT (adding several widgets) and get rid of the KDK’s stuffs (which we don’t have). Then build, sign and deploy the .azw2 file to your Kindle. And there you are, a nice Go game viewer!

# first, build and sign the jar file
$ ant build.xml
$ jar cvfm KindleGoban.azw2 KindleGoban.mf bin/*
$ ./signkindlet developer_keystore KindleGoban.azw2
# copy the file over to your Kindle, also need
# to copy an example .sgf file for testing
$ scp KindleGoban.azw2 root@192.168.2.2:/mnt/us/documents

4.   Resources

This section gonna be regularly updated on the availability of documents, tools.. for development on Kindle. Please note most of these are from third – parties rather than Amazon, which are the results of hacking, reverse – engineering… and some other information indirectly available from the KDK. At the moment, we only have this official javadoc from Amazon which describes the KDK’s APIs.

  • Savory: a native ebook converting daemon for Kindle.

  • Kindle emulator: need to double check this.

  • KWT: Kindle Widget Toolkit.

  • Mangle: a manga viewer for Kindle.

  • Qindle: a Qt port for Kindle.

  • To be updated…

KindleGoban screenshots, this is, like most Kindle projects at the moment, is just starting, would expect more features in the time coming.

whatever happened to programming?

Dạo này có thói quen viết blog IT tiếng Việt (viết tiếng Anh sợ ít người có đủ kiên nhẫn đọc và hiểu)

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.

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!

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ệ!