HTML Quickie: Long String Overflowing Your Div

May 25, 2009 § 6 Comments

Do you have that problem? I do.

EDIT(05/31/2009): Even better solutions:



General CSS solution:

overflow: scroll


The HTML solution:

use <wbr>. (But you have to figure out yourself where to put the tag)

The IE-specific CSS solution:

word-wrap: break-word

PHP solution:

wordwrap(‘your_very_long_string_here’, 15) // Break after 15 characters

Python solution:

import textwrap

textwrap.fill(‘your_very_long_string_here’, 15) # Break after 15 characters


Languages Numeric Types

May 23, 2008 § 1 Comment

C & C++ References:

C Trivia:

  • In C, long is both modifier and data type.
  • Long Long Int is not available in C++
  • <limits.h> header contains max & min information of numeric types.

C & C++ Numerical Types:

  • ShortInt — 2 bytes and 16 bits
  • Int — 2 bytes and 32 bits
  • Long Int — 2 bytes and 32 bits
  • Long Long Int (C only) — 4 bytes and 64 bits
  • Double — 64 bits

CPython Reference:

CPython Numerical Types:

  • Int ( use Long Int in C ) — 32 bits precision.
  • Float (use Double in C) — 64 bits precision.
  • Long — Unlimited precision.
  • Complex (use Double in C)

Java References:

Java Primitive Numerical Types:

  • Short — 2 bytes and 16 bits
  • Int — 2 bytes and 32 bits
  • Long — 8 bytes
  • Float — 4 bytes
  • Double — 8 bytes

Java Other Numerical Types:

  • BigInt
  • BigDecimal

PHP References:

PHP Trivia:

  • There’s no real concept of numeric data type in PHP (PHP 4.2 and newer supporters can argue me on this).
  • You don’t set date type on numeric variables, PHP determines data type for you.
  • 32 bit systems have a maximum signed integer range of -2147483648 to 2147483647.
  • The maximum signed integer value for 64 bit systems is 9223372036854775807.

PHP Numerical “Types”:

  • bool
  • integer
  • float

Perl References:

Perl Numerical Types:

  • Integer
  • Float
  • Decimal

Perl Trivia:

  • Decimal strings may have an exponential notation part, as in "12.34e-56".

PHP Date Time

May 11, 2008 § Leave a comment

is more or less annoying. Before fanbois comment me to oblivion, let me explain why.

DateTime and DateTimeZone are objects. They can be created using new DateTime() and new DateTimeZone() calls.

Why is it not documented anywhere? Instead, the documentation points to global function calls.

The global function for new DateTime is date_create(), while global function for new DateTimeZone is timezone_open(). How intuitive.

Talk about intuitiveness. date() does not return DateTime object. It returns string, but of course, that’s how it always be.

Now let’s talk about timezone_open(…). If you pass an invalid parameter, it WILL return false, but, it will also throw:

Warning: timezone_open() [function.timezone_open]: Unknown or bad timezone

Damn, that behavior is reported here.

More about timezone, did you know that you can call setTimezone() on DateTime object? I found it out by lucky guess. Where’s that documented on

Finally, when calling dateObject->format(‘U’), I was expecting to get “Seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)” –> pulled from But I didn’t get such results.

The seconds returned was not based on UTC timezone. It was based on the default php.ini, which was local timezone (PST).

So make sure before formatting to UTC, you call:

dateObject->setTimezone(new DateTimeZone(‘UTC’)) or

dateObject->setTimezone(timezone_open(‘UTC’)) or

don’t even bother creating object, just use: gmmktime()

Have fun with DateTime!


Fotolog Backend

February 2, 2008 § Leave a comment

Flickr Backend

January 30, 2008 § Leave a comment

Early Flickr:

Flickr Architecture:

PHP annoyance: MySQL now() vs PHP time()

January 23, 2008 § 3 Comments

When your DBA is thinking differently than you, you might get:


field: created_on

type: DATE

while, on PHP side:

$created_on = time();

Below is simple script that get rid of such annoyance.

From PHP to MySQL:

$created_on = date(‘Y-m-d H:i:s’, time());

From MySQL to PHP:

$query = “SELECT created_on FROM some_table WHERE id=1”;

$row = mysql_fetch_array(mysql_query($query));

$created_on = $row[‘created_on’]; //created_on from MySQL in DATE format

list($date, $time) = explode(‘ ‘, $created_on);

list($y, $m, $d) = explode(‘-‘, $date);

list($h, $i, $s) = explode(‘-‘, $time);

$created_on = mktime($h, $i, $s, $m, $d, $y); //created_on timestamp

So much loving and hating with PHP

January 7, 2008 § 1 Comment

As a developer that’s been coding PHP for so long and as a neophyte Pythonista, I have finally arrived at this crossroad.

Why PHP has to be this ├╝ber-sharp-double-edge sword? See what I mean below.

(+) Low Learning Curve

PHP is easy. Darn easy language. Many, like this one, said that PHP allows non-programmer doing programming. That argument, I think, is the strongest point of PHP. The easiness contributes to hobbyist productivity, open source growth, thriving dot com startups, and students.

(-) Low Learning Curve

The same ease of learning curve, also contributes to another PHP limitation. It is difficult to teach discipline programming in PHP. What is the need of modern design pattern if having everything in 1 php file works well? In my mind, that’s similar to: why bother folding my clean clothes if I can throw all of them on the floor. I could probably find my clothes faster if everything is on the floor (floor == hash map).

(+) Productivity

Because PHP is easy to pick up, it clearly delivers, “something”. Whether it is a non-enterprise spaghetti or well baked web framework with fabulous arrangement, PHP accounts for productivity to its developers. Increasing productivity is obviously one good solid point of PHP.

(-) Productivity

But the same productivity can also be undone by PHP itself. Either because of the syntax, security, or many other things. These caused the very same developers to go back, unravel the mess that’s either self-inflicted or, unfortunately, imposed by others (e.g. middleware “enterprise” companies). The easy way to dodge this bullet is to passed on the mess to the succeeding developers, but that’s… lame.

(+) The Speed of Prototyping

As the productivity increased, the speed of prototyping will naturally increased as well. This is most definitely a good thing. Until…

(-) The Speed of Prototyping

The prototype gives developers the illusion that it is “good enough” for live deployment. Is it? A lot of prototypes I’ve seen weren’t born with unit-test that actually represent real-life use case (Really… writing unit-tests is not that time consuming). On top of that many were born prematurely. Most of the time, the answer is not.

There will be more bullet points, as soon as I could think of.

What I’m Trying to Say

The more I use & read Python, the more I’m exposed to this perspective. To some readers, hold on your horses, I’m not trying to brew a flamebait here.

This is not PHP bashing and Python is kicking-PHP butt type of posting. I still love PHP, I still use it a lot, & I’m still CakePHP fanboi.

What I am trying to say is that, being Pythonic can apply to any languages. While writing PHP application, programmers can still apply good design.

Being Pythonic doesn’t mean using Python, it means not repeating yourself in coding, keeping everything simple, clear separation between logic and presentation, overall simply good design pattern.


1. Even before I know Python, the similarities between my coding principles and Zen of Python is striking. Although I’m not 100% agreeing with “There should be one– and preferably only one –obvious way to do it”.

Where Am I?

You are currently browsing the php category at RAPD.