“Turuan ang sinumang Pilipino na gustong matuto ng Programming o Computer Science.”

If there’s a tagline for my current project, Pangkaraniwang Developer, that would be it.

No need for a lengthy blog post, just head over to the About page and learn why I’m doing this.

Donations are always welcome. LOL

Can you help me with this? I’m going to take a technical written exam for a job i’m applying. Here is the list of what are expected on the exam:
-Basic Programming
-OOP
-recursive programming and variables in programming
-? statement
-conditional statements
-loop statements
-flowcharting
-pseudocodes (strings,odd/even)
Can you guys give me tips and heads up on where to focus and what to expect on the exam? The exam will be next week and I want to be prepared for it. Thanks in advance.

PS: Hindi ko alam kung anong programming language ung eexam. (I don’t know what programming language will be used in the test)

Whenever I see these type of questions, the first thing I do is give a ಠ_ಠ to my monitor. The listed coverage above is so basic that every 2^nd year college student should have no problem with it.

It’s like a carpenter asking what tool to focus on when applying for a carpenter position: screwdrivers, hammers, saws, or measuring tape? Yes, it’s that basic.

Unhelpful snarkiness aside, what advice would I give to these fresh grads?

There only need to do two things:

1. Relearn the basics

If you’re not confident about the things listed above once you’ve graduated college, it may mean that you don’t have a good foundation with the fundamentals yet. So the best advice I could give for that problem would be to forget everything you know and start over using the following books:

• Learn to Program by Chris Pine
• Learn Python the Hard Way by Zed Shaw
• Think Python or Think Java by Allen Downey
• Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Sussman (optional, if you want to double your starting salary. LOL)

When reading these books, you may find out how outdated or incomplete your college courses were back when you were taught programming. This is normal, and is an important part of the (re)learning process.

While you are reading these books, you may do the second advice at the same time:

2. Practice. Practice. PRACTICE!!!!

Apart from lack of fundamentals, the other reason you might not be that confident in going into a technical interview is the lack of coding practice — you should’ve encountered all of the things above had you coded thousands of lines of code before graduating.

So practice! Go to Project Euler and try to solve the problems! Go to Top Coder and do the same with the High School competitions!

Find algorithms and try to implement them! Start with simple ones like the Sieve of Erasthosenes and Conway’s Game of Life, then move on to progressively harder ones like Quicksort and Dijkstra’s Algorithm.

Also, don’t be content with just writing code; make an effort to read code. Good programmers are like good novelists; they read a lot more code than they write so they know what looks right and what looks wrong.

In other words, if you can’t figure out how to code something, just search for sample code on the internet and study them.

—

Just to wrap things up, I’ll be commenting on the items in the “technical interview coverage” listed at the start of this post.

-Basic Programming
…
-…variables in programming
-conditional statements
-loop statements

If you’re not familiar with these after a CS/IT course in college, I really question the quality of your education.

-? statement

It’s the conditional operator, used for writing if-then-else statements in shorthand.

Technically speaking, you really don’t need to use this (and in turn, don’t really need to know this) but there are a lot of cases where the shorter form makes code much easier to read. (And there are a lot of cases where it makes code really hard to read, but that’s another story.)

-recursive programming …

This is recursion. There are two types of interviews that use recursion:

• The bullshit type that makes you use recursion for tasks that can be done with simple loops like factorial and fibonacci sequence. If you know what loops are (and you should) and what recursion is, this shouldn’t be hard for you.

  Why do I find it bullshit? Because any programmer worth his/her salt knows how bad tail recursion can be in certain languages.

  If a decent technical interviewer would ask me this question, I’d expect a follow up question on how to eliminate the tail call.

• The good type of interview that really requires recursion i.e. the ones that require stacks and backtracking. For example:
  

  Given a string of characters, find the longest palindrome within the string.

  These problems may be harder, but they’re very much doable if you practiced the way suggested above.

-flowcharting

As I’ve mentioned in last night’s tweet, flowcharts are cute but useless. Anything less than Data Flow Diagrams or UML Diagrams can be better written as pseudocode.

-pseudocodes (strings,odd/even)

Which brings us to this one. Pseudocode has nothing to do with “strings,odd/even”. My guess is that this just wants the applicant to be comfortable with writing pseudocode that deals with strings. (and numbers?)

-OOP

Now here’s the hard part. Even I didn’t have good OOP knowledge even after graduating from college.

Fortunately, the books listed above have decent chapters on OOP so just read up on the topic and practice.

And finally:

PS: Hindi ko alam kung anong programming language ung eexam. (I don’t know what programming language will be used in the test)

This means the test is language agnostic and you will be coding in pseudocode. Just use the language you’re most familiar with.

If the interviewer berates you for syntax errors on code written on a whiteboard or a piece of paper, you probably won’t want to work in such a company. Trust me.

–

In closing, most technical interviews are just there to weed out applicants who pose as developers but can’t really write a line of code. So if you really know how to code, you shouldn’t have a problem with them.

And if you do fail, just take it as a sign that you need to practice harder. Unlike in other fields, a few months of practice in programming will actually help you get better jobs.

Anyway, the point of this post is to answer a question posed to me by a student in the Q&A portion of the talk:

Anong programming language ang dapat naming pag-aralan?
(What programming language should we learn?)

Here’s a question I wouldn’t want to hear answered by someone else (i.e. someone who’s also invited to talk to students). The question itself may seem simple, but unless you’ve seen how the industry works as a whole, you’ll probably give a wrong answer.

The traditional answer I don’t want to hear is to give a suggested list of languages based on market demand.

Simply put, this is bullshit. This is the same sort of bullshit that pressures our youth to take nursing courses even though they’re just in it for the money, money that they probably won’t get due to the eventual over-supply of nurses.

So for the student’s question, I gave two answers:

Programming language and platform choice doesn’t matter, because for the most part it’s a business decision.

Yes, I’m talking about steaks and strippers. In a large company, you may be initially hired to work on a single language, but eventually there will be a time where the company will make a business decision to shift technologies, whether due to market pressure or due to a new client. If you focus too much on a language, you will not be prepared for the change and you may end up getting fired or demoted.

In smaller companies or in a freelance setting, language still doesn’t matter, though for another reason: the client will not care about the language as long as you deliver the product.

This leads to the other answer:

Focus on the fundamentals, not on the language/platform.

A common mistake among fresh grads is that they’re confident they know language A or platform B because they were able to make their school projects or theses while at the same time not having their fundamentals down pat. Not only does this make them inflexible in terms of learning new languages, it also makes their work brittle and sloppy.

In other words, a student who has 4 years of school “experience” in Java is nothing compared to a developer who just had learned Java a month ago but has solid fundamentals in OOP.

You might say “Screw learning, I’m just in this for the money!”. But the fact is, there’s this thing called the Python Paradox: developers who are passionate enough to learn more than their peers often end up in higher-earning and less-stressful jobs.

Bottom line: There is no “best” language that you need to learn in order to earn a lot of money. However, if you have good fundamentals, learning the language and platform that the market needs will be much easier for you.

ffnpdf, a tool that converts FanFiction.net stories into PDF files.

(Great for putting your favorite Harry Potter slash fics on your mobile phone or tablet for portable use! LOL)

The code and documentation are found at the Github page. Theoretically, this gem can work anywhere Ruby, pandoc, and XeTeX can be installed (e.g. Windows, OS X, *nix) but I’ve only been able to make the whole thing work in Ubuntu/Mint.

Demo and how-tos are posted in this playlist:

I haven’t gotten around to make a license for this, but I assume that anyone into fanfiction knows that publishing and selling fanfics without consent from the rights owner is a big no-no. Thus, I don’t need remind them that this tool is just for personal use and not for commercial purposes.

These screencasts were recorded in 720p so it’s a good idea to select a higher resolution then view the videos in full screen or the large player in order for you to read the code properly.

Here I code a hexagonal “game of life”-like cellular automata. Used Ruby, Gosu, and RSpec.

Walking through coding a simple Rails app. Bunch of technologies discussed like Twitter Bootstrap, Heroku, and git.

Going through Project Euler problems via brute force using Java.

Here’s a quick update to this mini-tutorial. Previous parts can be found here and here.

Installing MySQL

Installing MySQL is so simple that I don’t need to hide it behind the cut. The one in the Ubuntu repositories work just fine:

$ sudo apt-get install mysql-server-5.1

Note that you will be asked to enter a root password somewhere in the installation.

To wrap up the installation run

$ sudo mysql_install_db

to initialize the installed server and

$ sudo mysql_secure_installation

to secure it.

In mysql_secure_installation, you’ll be asked for your root password and then you’ll asked if you want to change it. Just enter “n” since there’s no reason to change it this early. Then you’ll be asked if you want to do some things to secure the database which is, of course, what we want to do so just hit Enter for each question to choose the default answer (“Y”).

Installing WordPress

Now we go to making our Ubuntu + nginx + PHP + MySQL setup more useful by installing a web app. I choose WordPress for this tutorial because it’s both popular and easy to install.

Note that most PHP web apps out there have similar installation steps i.e. install prerequisites, setup database, download and extract files, and configure the app.

Installing prerequisites

We only need to install a few extra components for WordPress to work on our box:

$ sudo apt-get install php5-mysql php5-gd

php5-mysql is obviously required to allow PHP to connect to MySQL. php5-gd may be needed if you’re uploading images inside WordPress instead of using an external hosting.

At this point we are ready to follow the Installing WordPress guide.

Creating the database

I’ve switched around steps 1 and 2 because I prefer to do file-related tasks together instead of jumping from files to database to files again.

In setting up the database, we go with the client guide. Creating a new user isn’t part of that guide, though, so we’ll have to do that too.

Connect to the database using the root user:

$ mysql -u root -p

You will be prompted for the password before you can proceed. Once in, you can now proceed with doing what you need to do. The following lines will create a database named wp and a user named wp_user whose password is password_here.

mysql> CREATE DATABASE wp;

mysql> CREATE USER wp_user;

mysql> SET PASSWORD FOR wp_user = PASSWORD("password_here");

mysql> GRANT ALL PRIVILEGES ON wp.* TO "wp_user"@"localhost" IDENTIFIED BY "password_here";

mysql> FLUSH PRIVILEGES;

mysql> EXIT

Downloading WordPress and moving it around

Now it’s time to proceed with steps 1 and 3. Use wget to download and extract the latest version of WordPress:

$ wget http://wordpress.org/latest.tar.gz

$ tar -zxvf latest.tar.gz

We’ll then move the extracted folder wordpress/ to /var/www/ to centralize our web-app stuff.

$ sudo mv wordpress /var/www/

We also need to change the ownership for the folder:

$ sudo chown -R www-data:www-data /var/www/wordpress

Configuring it to work

First we need to add our database settings to wp-config.php:

$ cd /var/www/wordpress

/var/www/wordpress$ sudo mv wp-config-sample.php wp-config.php

/var/www/wordpress$ sudo vim wp-config.php

Change the settings as follows:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wp');

/** MySQL database username */
define('DB_USER', 'wp_user');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

Now to edit our nginx settings.

$ sudo vim /etc/nginx/nginx.conf

We’ll be using a combination of suggested settings from both nginx and WordPress documents:

...
    server {
        listen       80;
        server_name *.mysite.dev;
        root /var/www/wordpress;

        if ($http_host != "mysite.dev") {
                rewrite ^ http://mysite.dev$request_uri permanent;
        }

        # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
        location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
        }

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                # This is cool because no php is touched for static content
                try_files $uri $uri/ /index.php;
        }

        location ~ \.php$ {
                include fastcgi_params;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_pass php;
        }

        location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
    }
}

The main changes here are the update to the root (pointing it now to /var/www/wordpress) and the try_files approach of URL rewriting (which allows nginx to act like mod_rewrite without the use of .htaccess).

Wrapping up

Restart both PHP-FPM and nginx to apply the changes we made to both.

$ sudo /etc/init.d/php5-fpm restart

$ sudo /etc/init.d/nginx restart

Then go to http://mysite.dev to proceed with the “famous 5-minute install”.

You have now successfully installed WordPress.

Here’s the next part of my basic web server administration tutorial.

At the first part, we set up the virtual machine. Now we’ll be setting up the web server itself.

Set Static IP Address and fake Domain Name

Before we could proceed with installing our web server, let’s do a couple of things to make our server behave more like a “normal” server.

First is to set our server’s IP address to a static IP address. There are a bunch of ways to do this (e.g. change the router settings), but we’ll just go with changing our server’s settings

Running ifconfig and route will give us the current IP address and gateway.

In this case, the new IP address is 192.168.1.125 and the gateway is 192.168.1.5. We can now apply these settings to /etc/network/interfaces. Open the said file via:

$ sudo vim /etc/network/interfaces

(For this tutorial, I’ll be using vim as the default text editor. If you find vim too daunting, you can replace all instances of vim with nano)

It will look something like:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

Now replace the last line with the following:

iface eth0 inet static
address [address here]
netmask 255.255.255.0
gateway [gateway here]

for example:

iface eth0 inet static
address 192.168.1.125
netmask 255.255.255.0
gateway 192.168.1.5

To make sure you got the static IP settings correctly, you can restart the server via

$ sudo shutdown -r now

or you could just simply restart the network interface:

$ sudo /etc/init.d/networking restart

Here we see the /etc/init.d folder where the init scripts (like networking) are placed. Aside from being executed automatically upon boot to start services, they can also be used to stop or restart the said services just like what we just did with networking. We will see more of /etc/init.d/ later in this tutorial.

Now that we’ve set the IP address as static, it’s time to set a fake domain name.

Normally, when you’ve got a server with a static IP address, you’d have to go and buy a domain name from a registrar like Namecheap and you’d go through the steps in linking that name with the IP address and waiting for the DNS propagation.

For this tutorial, we’re going to skip all that by faking it with the hosts file.

First let’s update the server’s /etc/hosts file to add our fake domain name “mysite.dev”:

sudo vim /etc/hosts

Add the line at the end:

192.168.1.125   mysite.dev

You can verify the new setting by using the ping command.

user@ubuntu:~$ ping -c 4 mysite.dev
PING mysite.dev (192.168.1.125) 56(84) bytes of data.
64 bytes from mysite.dev (192.168.1.125): icmp_seq=1 ttl=64 time=0.172 ms
64 bytes from mysite.dev (192.168.1.125): icmp_seq=2 ttl=64 time=2.38 ms
64 bytes from mysite.dev (192.168.1.125): icmp_seq=3 ttl=64 time=3.34 ms
64 bytes from mysite.dev (192.168.1.125): icmp_seq=4 ttl=64 time=1.59 ms

--- mysite.dev ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 0.172/1.874/3.342/1.161 ms
user@ubuntu:~$

Now let’s apply the fake domain name mapping to the host Windows computer. Like in Linux, the hosts file in Windows requires admin privileges so we first need to run the text editor as Administrator in order to allow us to modify it.

Right-click Notepad and select “Run as administrator”. Once open, you can now add the “192.168.1.125 mysite.dev” to the end of the C:\Windows\System32\drivers\etc\hosts file.

Now you could change the PuTTy settings to use “mysite.dev” instead of the actual IP address.

The actual installation of the web server below the cut.

Installing Nginx

It’s finally time to install the web server.

We won’t be using Apache, though. Instead, we’re going to go with its leaner and faster Russian counterpart nginx. We’re also going to build it from scratch (as opposed to getting it from a repository) to show you how its done in Linux machines.

Installing dependencies

We’ll need to install a few things before we could proceed with building nginx.

$ sudo apt-get install build-essential libssl-dev libpcre3-dev

build-essential contains the essential tools for compiling programs from source while the other two are libraries that nginx needs during compilation.

Building from source

~$ wget http://nginx.org/download/nginx-1.0.11.tar.gz

Using wget we download the latest stable source as of this writing. Yes, it’s a whopping 700 KB.

~$ tar zxvf nginx-1.0.11.tar.gz

We then unpack it using tar.

~$ cd nginx-1.0.11

~/nginx-1.0.11$ ./configure --sbin-path=/usr/local/sbin --with-http_ssl_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module

~/nginx-1.0.11$ make

~/nginx-1.0.11$ sudo make install

Now we finally perform the build/installation. This three-step configure-build-install scheme is pretty much how one builds any program in Linux from scratch.

This nginx build doesn’t come with an init script so we’ll have to download one off the net.

~/nginx-1.0.11$ cd ~

~$ wget https://raw.github.com/JasonGiedymin/nginx-init-ubuntu/master/nginx

~$ sudo mv nginx /etc/init.d/nginx

We still need to set a couple of things with the script:

$ sudo chmod +x /etc/init.d/nginx

$ sudo chown root:root /etc/init.d/nginx

The first command sets the script to executable and the other command gives the ownership of the script to root. Now we can run nginx:

$ sudo /etc/init.d/nginx start

You can now open http://mysite.dev to check if it’s installed properly.

Using Firebug or Chrome Developer tools will confirm the server’s really nginx 1.0.11.

Tweaking nginx

Before we proceed with installing PHP, let’s apply some tweaks to nginx to make it more Apache-ish (lol) and then some.

$ sudo ln -s /usr/local/nginx/conf /etc/nginx

This creates a symbolic link in the /etc folder to match with the convention for configuration files.

$ sudo vim /etc/nginx/nginx.conf

Now we edit the configuration file like so:

user  www-data;
worker_processes  1;

pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    gzip on;
    gzip_buffers 16 8k;
    gzip_disable "MSIE [1-6]\.";
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    error_log  /var/log/nginx/error.log  debug;

    sendfile        on;
    keepalive_timeout  3;
    index              index.html index.htm;

    server {
        listen       80;
        server_name *.mysite.dev;
        root /var/www;

        if ($http_host != "mysite.dev") {
                rewrite ^ http://mysite.dev$request_uri permanent;
        }

        # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
        location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
        }

    }

}

A quick summary of the changes:

• We changed the server’s user from “nobody” to the system user “www-data”, the default user for web servers.
• We set the file where the PID for the server would be located. This will allow our init script to stop or restart the server.
• We enabled gzip for supported browsers to dramatically reduce the bandwidth usage.
• We set the log to match Apache’s format.
• We defined a handler for the *.mysite.dev domain, defining its root to be the same as Apache’s (/var/www)

Now to wrap things up:

$ sudo cp -r /usr/local/nginx/html /var/www

$ sudo chown -R www-data:www-data /var/www

We copy the html folder to /var/www and give it to www-data.

$ sudo mkdir /var/log/nginx

Just creating the log folder.

$ sudo /etc/init.d/nginx destroy

$ sudo /etc/init.d/nginx start

We force stop the server (as we haven’t defined the PID file when we started it) then start it normally.

Opening http://mysite.dev now shows us that the site is served as gzipped.

Installing PHP-FPM

Unlike nginx, we won’t be building PHP from scratch. We will, however, not go with Apache’s mod_php/extension route and instead go the PHP-FPM route which, like nginx, is much leaner than the former.

Since PHP-FPM isn’t available in the official apt repositories of Ubuntu 10.04, we will have to use another repository. Nginx’s repositories may be a bit out of date (PHP v5.3.5 vs the current v5.3.8) but it should be enough for this tutorial.

$ sudo apt-get install python-software-properties

$ sudo add-apt-repository ppa:nginx/php5

$ sudo apt-get update

$ sudo apt-get install php5-fpm

The steps above will install PHP-FPM with fairly decent defaults. If you want to change some settings, you can modify the files at /etc/php5/fpm/ and restart the server via “sudo /etc/init.d/php-fpm restart“.

Now all we need to do is to tell nginx how to use PHP-FPM. Here’s our modified /etc/nginx/nginx.conf:

user  www-data;
worker_processes  1;

pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    gzip on;
    gzip_buffers 16 8k;
    gzip_disable "MSIE [1-6]\.";
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    error_log  /var/log/nginx/error.log  debug;

    sendfile        on;
    keepalive_timeout  3;
    index              index.php index.html index.htm;

    upstream php {
        server 127.0.0.1:9000;
    }

    server {
        listen       80;
        server_name *.mysite.dev;
        root /var/www;

        if ($http_host != "mysite.dev") {
                rewrite ^ http://mysite.dev$request_uri permanent;
        }

        # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
        location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
        }

        location ~ \.php$ {
                include fastcgi_params;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_pass php;
        }
    }
}

The main changes between the original are:

• Adding “index.php” before “index.html index.htm” to let the server prioritize the former over the latter.
• The addition of the upstream php block that points to PHP-FPM.
• The addition of the location handler for PHP files.

We also need to modify /etc/nginx/fastcgi_params, adding the following lines at the end of the file:

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

Once done we can now restart the server via sudo /etc/init.d/nginx restart.

To test PHP, create the phpinfo() index.php file:

$ sudo sh -c 'echo "<? phpinfo();" > /var/www/index.php'

Then open http://mysite.dev again:

You have now installed nginx and PHP on your web server.

Benchmarking

You can use ApacheBench to see how well your site performs under load.

$ sudo apt-get install apache2-utils

Here’s 1000 requests with 100 concurrent users (10 requests each user) to our static HTML file:

user@ubuntu:~$ ab -n 1000 -c 100 http://mysite.dev/index.html
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking mysite.dev (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        nginx/1.0.11
Server Hostname:        mysite.dev
Server Port:            80

Document Path:          /index.html
Document Length:        151 bytes

Concurrency Level:      100
Time taken for tests:   1.720 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      378290 bytes
HTML transferred:       157795 bytes
Requests per second:    581.31 [#/sec] (mean)
Time per request:       172.025 [ms] (mean)
Time per request:       1.720 [ms] (mean, across all concurrent requests)
Transfer rate:          214.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       27   79  15.7     84     102
Processing:    39   83  16.5     86     131
Waiting:       10   61  17.5     65      98
Total:        129  161  16.5    172     184

Percentage of the requests served within a certain time (ms)
  50%    172
  66%    173
  75%    173
  80%    173
  90%    178
  95%    182
  98%    183
  99%    183
 100%    184 (longest request)

Here’s the same test against our phpinfo() page:

user@ubuntu:~$ ab -n 1000 -c 100 http://mysite.dev/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking mysite.dev (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        nginx/1.0.11
Server Hostname:        mysite.dev
Server Port:            80

Document Path:          /
Document Length:        42481 bytes

Concurrency Level:      100
Time taken for tests:   8.582 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      42649000 bytes
HTML transferred:       42481000 bytes
Requests per second:    116.52 [#/sec] (mean)
Time per request:       858.186 [ms] (mean)
Time per request:       8.582 [ms] (mean, across all concurrent requests)
Transfer rate:          4853.19 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    6  16.6      0      63
Processing:    66  810 126.3    861     875
Waiting:       59  808 127.0    858     873
Total:        125  816 113.2    861     875

Percentage of the requests served within a certain time (ms)
  50%    861
  66%    862
  75%    863
  80%    864
  90%    869
  95%    874
  98%    874
  99%    875
 100%    875 (longest request)

581 and 116 requests per second? Not bad for a “low end” server.

Proceed to part 3: Installing MySQL and WordPress

This isn’t a full write-up of the event so I’ll keep this short and simple. The event was at Drei‘s place with just a bunch of Ruby, Python, and PHP guys from both Manila and Baguio hacking up random stuff instead of doing the whole Code Retreat thing.

at the after event, aka “Yo dawg, I heard you like taking pictures so here’s a picture of people taking your picture so you can have a picture of you taking pictures of people taking pictures”

Being the slacker that I am, I didn’t have anything planned out beforehand. I thought I’d just go the same route as with Startup Weekend Manila and just be a rubber duck floating around groups. Fortunately, Buddy brought along his significant other Rizza with the intention of having her learn programming from the participants of the event.

I couldn’t resist this teaching challenge. So for the entire event, I went on to give an impromptu crash course on the fundamentals of software development.

I started off with basic imperative/procedural programming via pseudocode (to drill in the idea that software development is not about computers but about solving problems). As we progressed I moved on to Ruby for the more technical side of things (basic data types) up to Object Oriented basics.

first programs – potato salad and quadratic formula

By mid-day, I had this little flash of insanity and began downloading >250MB of development stuff from a certain site.

That flash of insanity was to go back to the original Code Retreat exercise, Conway’s Game of Life, and build it in Java to teach software development: coding conventions, revision control, test automation, refactoring, etc.

Of course, I had to teach the most crucial concept in software development: how to wing it. And that was where Android came in.

So we had a base GoL class and a freshly installed Android SDK. A couple of Google searches later and a lot of guesswork, we were able to make the whole thing work as a Live Wallpaper in around 1.5 hours.

Lack of sleep and preparation can turn a Ruby guy into a Java developer. LOL

So I’m gonna be recording rants for the next few weeks to figure out and fix my vocal problems. I’m ok with topic suggestions but I’m not really expecting any.

Will be posting the recordings on this site until I get to setup another page for the recordings (probably a wiki).

Episode 0 – Intro

Episode 1 – Pizza (pt1 of 2)

Episode 2 – Pizza (pt2 of 2)

–

UPDATE

Podcasts now posted daily at http://bry-rants.tumblr.com/

So yeah, we had 2 missing speakers, leaving Alvin and I to handle everything.

But surprisingly, this DevCon event was far better than the one in DLSU (read: a more prestigious university) mainly because the students were really interested in what the two of us have to say. Sure, our talks may have been boring for most of the audience, but by the time we left the campus, we’ve fielded over a dozen questions, mostly from students who approached us after the event ended.

In comparison, AFAIK, only one student asked a question in DLSU.

Pride? Apathy? I really don’t know.

Anyway, here’s my talk and the slides.