Baguhan Biyernes: Mga Idiom at Pattern

Madalas itanong ng mga may balak matuto ng programming kung ano ang kailangan nila para maging handa sila sa gagawin nila. Sa totoo lang, maraming magagandang sagot sa tanong na iyan:

Kailangan mayroon kang ‘passion for learning’.

Kailangan hindi ka natatakot magtanong o humingi ng tulong sa mas may nakakaalam.

Kailangan sanayin mo ang iyong ‘analytical skills’.

Para sa akin, mayroong isang magandang sagot na hindi ko gaanong naririnig kahit sa mga bihasa sa programming:

Kailangan matuto kang pumansin at makaalala ng mga pattern at idiom.

Kapag tinuturo ang programming sa mga baguhan, kadalasan ito ang paraan na ginagamit ng mga guro:

  1. Ituro kung paano gawin isang bagay
  2. Magbigay ng problema na kayang malutas gamit yung itinuro sa (1).

Ang problema dito ay tinatrato ng guro na pareho ang Math (kung saan nararapat ang paraang ito) at programming. Hindi sapat ang malaman kung ano ang mga bahagi ng mga program — kailangan mo ring malaman kung anu-ano ang mga posibilidad kung paano mo ibubuo ang mga program gamit ang mga natutunan mong bahagi ng program.

At ang mga kumbinasyon na iyon ay matatawag nating “pattern“.

Kunwari tuturuan mo ng iteration ang isang estudyante. Siyempre ibibigay mo sa kanyang pang-practice ay tung paggawa ng tatsulok na asterisk gaya nito:

*
**
***

Magtapatan tayo: sino sa inyo talagang nakakuha kung paano gawin ito ng walang tulong?

Mukhang simple siya — kasi simple nga siya basta alam mo yung pattern kung saan pwede mong gamitin yung counter sa nested loop:

for i <- 1 to 3:
    for j <- 1 to i:
        print "*"
    print "\n"

Dito natin makikita na hindi nga sapat ang pag-turo ng "basic concepts" lang sa programming. Kung tutuusin parang dinadaya nating mga guro ang mga estudyante pag hindi natin pinapakita at pinapaliwanag itong mga pattern na ito bago natin binibigay yung mga ganitong klaseng exercises o tests.

At sino naman yung mga nakakakuha ng tamang sagot?
Tama, yung mga may karanasan na sa programming i.e. yung mga estudyante na may kaalaman na tungkol sa mga pattern na ito.

Magbigay pa tayo ng isang halimbawa. Paano mo isusulat itong expression na ito?

kung ang pangalan niya ay Juan o Maria, gawin mo...

Pag tinuro mo lang ang konsepto ng boolean logic operators, malamang ang gagawin ng estudyante mo ay:

if name == Juan or Maria ...

Pero itanong mo sa kahit na sinong marunong mag-program, ang tamang code diyan ay:

if name == Juan or name == Maria ...

Isa nanamang pattern.

--

Kaugnay sa pattern ang mga idiom; pwede nating ituring na pattern lahat ng idiom.

Ang mga idiom ay mga pattern na madalas mong makita sa mga program na hindi ganoon ka-obvious para sa mga baguhan. Yung name == Juan or name == Maria natin sa taas ay isang halibawa ng idiom.

Kung tutuusin, pwede nating tawagin na idiom ang "=" operator sa mga programming language na gumagamit nito bilang assignment operator.

a = 100
b = 2
a = b

Para sa mga taong walang alam sa programming, walang saysay ang tatlong linyang iyan. Tinuro sa atin sa algebra na hindi pwede ang ganyan.

Subalit para sa mga developer, dahil iba ang ibig sabihin ng "=" sa ilang programming language, mayroon itong saysay at mayroon itong ginagawa.

Baka isipin ninyo "ang hina naman ng baguhan kung nalalabuan siya sa 'idiom' na iyan". Pero sige nga, subukan ninyo ngang intindihin itong Haskell code na ito:

a = do x <- [3..4]
       [1..2]
       return (x, 42)

Kung hindi kayo pamilyar sa Haskell, tiyak na malilito kayo sa ginagawa ng code na ito. Mukhang dapat madaling maintindihan yung do-notation o kahit man lang yung return, pero pag pinag-aralan ninyo kung ano ang ibig sabhihin ng mga idiom na yan, magugulat na lang kayo na malayo sila sa inaasahan ninyo.

Sa example na ito rin makikita na minsan binibigyan tayo programming languages ng mga paraan para isulat ang mga idiom. Halimbawa:

count++;  /* increment by 1 in C-based languages */
if 10 < x < 100:  # one way to range check in Python 

--

Hindi lang sa programming language nakikita at nagagamit ang mga pattern at idiom. Sa lahat ng level ng software development, mayroong mga patterns na sinusundan para mapadali ang

Halimbawa sa game development, lahat ng computer games gumagamit ng game loop:

while( user doesn't exit )
  check for user input
  run AI
  move enemies
  resolve collisions
  draw graphics
  play sounds
end while

Iba pang halimbawa ng patterns ay ang Model 2 at MVC ng web development, at Design Patterns ng Object Oriented Programming.

Sa madaling salita, mas mahalaga ang pag-aaral wastong paggamit ng patterns at idioms ng mga languages at platforms kaysa pag-aaral ng languages mismo.

Troubleshooting: Blender only renders one frame

Ran across this problem earlier. For some reason, Blender only renders one frame when rendering today’s Intro to CLI video.

The quick fix is to change the MPEG Preseek to 0.

set preseek to 0

I’m not sure why it happened, but my guess is that if your entire video is just made up of one source video (see below) and that source uses a weird codec, Blender messes up in pulling the correct frame for that time.

Blender as an NLE

(Yes, I’m using Blender as PD‘s main non-linear editor.)

Baguhan Biyernes: Bakit ang daming terminology na binabato sa iyo pag nag-aaral ka ng programming?

(Susubukan kong gumawa ng isang “weekly column” tungkol sa pag-aaral ng programming at software development. Bukod sa extra advertising para sa Pangkaraniwang Developer, mahahasa ko rin ang aking pagsusulat sa Tagalog.)

May isang magandang thread ngayong linggo sa r/learnprogramming kung saan nagrereklamo ang isang nag-aaral ng programming hinggil sa rami ng terminology na nakikita niya sa isang tutorial. To paraphrase/translate:

Isa akong baguhan na sinusubukang matuto ng jQuery, pero noong ini-introduce ako sa kanya ng kakilala ko, maraming lumabas na mga terminology na hindi ko alam sa 5 minutong usapan na iyon:

  • bind
  • delegation
  • node
  • handler
  • listener
  • event
  • bubbling

Ganito ba talaga kahirap matuto ng programming?!?

Pag binasa ninyo yung thread, madaling mahalata yung problema nung nagtatanong: hindi pang-baguhan ang jQuery, pero gusto parin niya itong matutunan kahit hindi pa siya bihasa sa JavaScript.

Gaya nga ng sabi ng ibang commenter, parang pumasok siya sa isang Calculus class kahit hindi pa siya dumaan sa Algebra at Trigonometry, at ngayon umaangal siya na hindi pinapaliwanag ng propesor ang sine at logarithm. Kaya nga may mga terminology tayo — hindi lang para hindi tayo magsayang ng oras sa pagpapaliwanag kung ano iyon, sa paggamit ng terminology, ipinapalagay na ng kung sinumang gumamit noon na maiintindihan na ng nakikinig/nagbabasa kung ano ang gusto niyang ipahiwatig kahit hindi siya simple.

Halimbawa, maraming pwedeng ibig-sabihin ang “node” kahit sa computer science, pero pag lumabas siya sa usapan tungkol sa jQuery, dapat naiintidihan ng lahat ng nasa usapan kung aling “node” iyon.

Sang-ayon ako sa huling payo ng mga commenter: dapat unti-untiin niya ang pag-aaral ng programming. Sa web development, medyo marami kang dapat matutunan bago ka mag-jQuery: HTML, CSS, at intermediate JavaScript. Hindi magandang sumabak sa isang tool o framework na ginawa para sa mga experienced developers kung ikaw mismo ay hindi experienced developer.

Pero kung tutuusin may punto rin naman siya. Hindi mo maiiwasan na dumiretso sa mga intermediate topics ang mga baguhan kaya mabuti kung mayroon kang mga paraan para mas mapadali yung buhay nila.

Kaya nga sa simula palang ginawa ko yung PD na may mga “Previous Lesson” links para malaman ng mga student kung ano yung mga kailangan nilang malaman bago nila pag-aralan yung current lesson. Balang araw, magkakaroon rin ng glossary of terms bawat lesson para hindi mahirapan ang mga student sa paghanap ng kanilang kahulugan. (Pero saka na iyon, tinatamad pa ako ;P)

Just Shut Up And Do It!

As with all prudent website owners, I regularly check my analytics for my sites to see trends and the occasional weird referrer (e.g. just tonight my Wooga post was linked by some Korean guy on Facebook).

In addition to Google Analytics, I also use Piwik so that I could see the IP addresses of visitors without having to go and open the nginx logs. Unfortunately, Piwik’s somewhat unreliable with the IP lookup:

Piwik

When that happens, I turn to any one of the many Whois and IP lookup sites and see where these visitors come from.

One thing I noticed about this approach is that I sometimes search IP addresses which are similar to past searches. If I had a way to list down my previous searches, I might be able to reduce the amount of these repeat lookups.

Now the obvious first choice would be to build a Rails application with Geokit and call it a day. But that wouldn’t be fun, wouldn’t it?

So instead of doing that, I decided to take this opportunity to finally learn Backbone.js.

A couple of hours later…

Trac(k)er

Introducing Trac(k)er, a quick and dirty IP tracer/tracker built with Backbone.js, Backbone.localStorage, Zurb Foundation, Flag Sprites, geoPlugin, and Google Maps.

You might be wondering what’s the connection between introducing a simple web application and the title above. The answer’s related to a previous post where I ranted about people who wait until they get a certain tool before trying to learn something.

This time around, I’ll be taking aim at a superset to that set of people: people who talk about wanting to do something but never get around to do it.

When I want to learn a new technology, I do the following:

  1. I read up on the technology, maybe watch a few presentations about it, all just to see what it’s about.
  2. I find a current problem that I have that can be solved by that technology.
  3. I try solving that problem with that technology.

My 3-4 hour romp through building a mashup with Backbone and GeoIP is a perfect example of this approach. I’m nowhere near the level of even a competent Backbone developer, but at least I have a passing knowledge of the basics behind the technology.

Pretty much everything I learned on my own was like this. I learned how to setup and manage a LAMP stack to let me try out various PHP apps like WordPress and MediaWiki. I learned Rails to help out in building my friends’ inventory management system web app. I learned nginx because Apache was eating too much memory when I had a memory-intensive web app. The list goes on…

On the other hand, when they want to learn a technology, they go:

  1. They hear about the technology and get hyped.
  2. They talk about how they’re going to learn that technology.
  3. They realize it’s a lot harder than they expected and they start making excuses.
  4. They make a big excuse so that they can abandon the technology and move on to the next shiny thing.
  5. Lather, rinse, repeat.

So my suggestion to people who want to learn something new but don’t want to become like the latter:

Just shut up and do it!

And my suggestion to those who have “legitimate” excuses for not being able to push through with what they planned to do:

Just shut up the next time!

You are not as good as you think you are

I know I’ve mentioned this before, but recent events have convinced me to mention the Dunning–Kruger effect again.

Kruger and Dunning proposed that, for a given skill, incompetent people will:

  1. tend to overestimate their own level of skill;
  2. fail to recognize genuine skill in others;
  3. fail to recognize the extremity of their inadequacy;
  4. recognize and acknowledge their own previous lack of skill, if they can be trained to substantially improve.

While the Dunning–Kruger effect is a common cognitive bias, the local culture of “Sirs” and “Masters” seems to have amplified it. In the past few weeks, I’ve been in online discussions related to business and application security where the people I’m talking to aren’t even aware of their lack of (basic) knowledge on the topic. The real problem here wasn’t that they could be debunked easily by any serious book on their respective topics; the problem here was that only a few (or no one in the latter case) stepped in to point out the flaws in their arguments – flaws that only newbies should make.

The “Sir/Master” mentality’s influence is twofold:

  • First, people who are called “masters” are content with their skill set and fail to look for gaps in them (classic Dunning–Kruger). Hence, they are not aware if someone is wrong or not.
  • Second, people are not willing to call out the “masters” when the former sees the latter say something wrong. It’s your post count automatically makes you a senior person who shouldn’t be questioned.

In other words, “Sir/Master” indirectly leads to “pwede na” (it’s good enough).

Note that this “pwede na” attitude isn’t limited to local communities. One recent article proposes that PHP’s problem doesn’t solely lie on the language itself, but that its ease of use produced a lot of incompetent developers who provide wrong advice to newbies which in turn become even worse developers. A few days later, a group of people made PHP: The Right Way as a means to promote good coding practices for the language.

Unfortunately, I feel that it will take a while for this movement catches on in the PHP community. The Dunning–Kruger effect has a pretty strong hold on PHP developer groups, and even locally it took 2 days before someone posted it to the forum.