就在這個月初，根據w3techs的資料，WordPress在整個web的CMS佔有率堂堂邁入37%，今天更邁入37.3%，可喜可樂，可喜可樂

但個人覺得上面這張圖真正值得注意的不是WordPress，而是打倒Joomla成為第二名的Shopify。

它既不是開源軟體，也不是general purpose CMS，作為一個單純電商的平台，它從去年7月的1.6%，竟然以急起直追之勢成長足足1.5倍打倒Joomla；而且按照這個速度，除非Shopify突然捲入什麼致命的政治醜聞，差距在幾年內恐怕只會愈拉愈大。

這一方面反映了個人化的電子商務市場之大，一方面反映了老掉牙的「do one thing and do one thing well」可以是很強大的：Shopify提供的功能恐怕還不到WordPress.com所有功能的1%，但他們的事業體是我們的好幾倍大。這也是為什麼我一有機會就在公司內喊著要砍東西而非一直加東西，但短時間內看來我們還是會往繼續加的路線走就是了。

本系列專為從PHP之外的語言開啟碼農人生、卻因命運安排整天與PHP為伍的人撰寫，收集一些從其他語言的角度看來不可思議的設計。如果能讓在讀這篇文章的你在實務上踩到而懷疑人生前就釋懷，就是我莫大的榮幸。

前言

繼前篇gethostbyname()，本篇討論少見於PHP之外的設計：varying case sensitivity，也就是某些情況下大小寫相關，某些情況下大小寫無關。總之，就是任性。

可能因為我個人有經年累月的大小寫相關的程式編寫習慣，再加上linter層層把關，我大概兩年多才發現有這個特性，當下簡直是晴天霹靂、茅廁頓開，在這非黑即白的大小寫相關性世界，PHP竟仍能為我們開一扇窗；彷彿在提醒我們，看待世間萬物切勿抱持成見，才能看見真實。

常有人說PHP是如詩般的語言，這，何嘗不正是其獨有的詩意呢？

嘴夠了，進入正題

更精確來講，PHP的大小寫相關性是：

• 函式名、命名空間名與類別名大小寫無關
• 變數名、常數名大小寫相關

…

大部分的時候這都只會造成一些小驚喜，像這樣：

class Foo {
    const ABC = 'I am a constant';
    static function bar() { ... }
}
$poetry = 'I am a variable';

Foo::bar();  // 可以
foo::Bar();  // 嗯，有何不可
print_r( $poEtry ); // 不行喔
print_r( Foo::aBC ); // 討厭，就說不行了，都欺負人家 ...

但一個沒站穩，玻璃心還是會摔碎的。

Continue reading ➞ 我們與PHP的距離(二)： 任性的大小寫

前言

自從加入a8c，PHP作為常備語言之一，時至今日仍然像顆出奇蛋一樣止不盡的驚喜。天底下沒有完美的語言，但至今確實沒有任何一個我寫過的程式語言比PHP讓我感到更『魔幻』。本系列專為從PHP之外的語言開啟碼農人生、卻因命運安排整天與PHP為伍的人撰寫，收集一些從其他語言的角度看來不可思議的設計。如果能讓在讀這篇文章的你在實務上踩到而懷疑人生前就釋懷，莫大的榮幸。

祝各位天天PHP，天天開心。

進入正題

首先來看看今天的主角：gethostbyname() 在文件中是怎麼描述的吧：

gethostbyname ( string $hostname ) : string

Returns the IPv4 address of the Internet host specified by hostname.

舉例來說：

php> print_r( gethostbyname( 'softman.blog' ) );
192.0.78.25
php> print_r( gethostbyname( 'localhost' ) );
127.0.0.1

很簡單吧。這基本上就是一個gethostbyname()系統函式的包裝，

但問題出在它的回傳值設計。根據官方文件：

Returns the IPv4 address or a string containing the unmodified hostname on failure.

『當錯誤發生時，會回傳無修改的hostname引數』

……………..

這神設計有兩個問題。第一，和許多PHP函式的錯誤行為相悖；第二，複雜的錯誤處理讓這個函式很難正確使用。如果你認為：

$hostname === gethostbyname( $hostname )

這樣就結了，那就太小看PHP惹 …

Continue reading ➞ 我們與PHP的距離(一): gethostbyname()

話說PHP因為不像JavaScript內建的log函式庫就挺不錯，不同的源碼中總是可以看到自己的log函式。最常見的不外乎是可以印出任意個引數值到error log / stdout / stderr，或是印出第一個引數後回傳之。

誒～但可能是大家都想盡量少打些字吧，我發現這類函式經常被命名為 l()。對，就一個一柱定海的l。

是很精簡啦，而且l這字看久也蠻美的 … 但個人認為這並不是一個好名字。為什麼？因為不夠明顯啊。這就有點像C++為什麼要引入static_cast reinterpret_cast啥的來取代C-style cast，要特別留意的東西應該要盡量設計成引人注目會比較好。

基於這項理由，我自己在用的是mango()、guava()和litchi()

……………….

……………….

真的啦，有code為證：

function mango( $val ) {
    if ( is_null( $val ) ) {
        return 'NULL';
    } elseif ( false === $val ) {
        return 'FALSE';
    } elseif ( true === $val ) {
        return 'TRUE';
    }

    return print_r( $val, true );
}

function guava() {
    $arg_strs = array_map( 'mango', func_get_args() );
    $log = join( ' ', $arg_strs );

    error_log( $log );
}

function litchi( $arg, $label = 'log value:' ) {
    guava( $label, $arg );
    return $arg;
}

說真的，自從我把這些log函式從WTF系列改成這台灣味的水果系列，整個人debug起來心平氣和，修為都提升了呢 🤪

而且另外的好處是很好搜尋啊。大家在提交源碼前相信公司都會要求把不必要的debugging log都拿掉吧？(啥？你們公司不用？塊陶啊～) 這樣只要ag guava就一定能找出所有的debugging log了呢。雖然也可以用ag '\bl\('找到所有的l()呼叫，但這打起來手就癢癢的，沒這麼順暢呢 … (個人因素

我在某次working tips分享中分享了這個小撇步，會後有人漲紅著臉拿了這個給我看：

function 👻( $val ) {
     if ( is_null( $val ) ) {
         return 'NULL';
     } elseif ( false === $val ) {
         return 'FALSE';
     } elseif ( true === $val ) {
         return 'TRUE';
     }
     return print_r( $val, true );
 }
 function 💩() {
     $arg_strs = array_map( '👻', func_get_args() );
     $log = join( ' ', $arg_strs );
     error_log( $log );
 }

嗯 … 真是超級明顯又好搜尋呢