啟動 Mac OS X 的 OpenLDAP

三部曲
1. slappasswd 建立新的 rootpw
2. 編輯 /etc/openldap/slapd.conf 內的 suffix, rootdn, rootpw
3. slapd -d 255
Reference:
starting OpenLDAP on Mac OS X

LWP Chunked Way

在讀取 || 傳送大量資料的時候，可以利用 IO::* 這類模組去一次讀取其中一段資料 (Chunk) 就寫入暫存檔 || 送出，來避免對記憶體造成負擔的手法可說相當常用。也是 HTTP Server 用來做 Streaming 或是 Long Polling / Comet 的基礎。

Client 端的用法就沒有那麼絢麗的名字了（開發 Client 的人沒有必要用絢麗的名字震懾老闆？:p）。LWP 對 Chunk 手法也有支援，不過在 GET 和 POST 兩種 HTTP 動做的支援方式分別使用了接受 callback 和利用全域變數啟用的方式，有點不一致，特此紀錄一筆。

GET 使用 Chunk 的方式在 lwpcook 有詳盡記載。在 LWP::UserAgent 物件呼叫 request 方法時多傳入一個 callback 即可。

POST 動作其實也應該可以提供 callback。想像起來應該是這樣：

大概是反正多數時候只能寫 $socket->write($chunk)，所以乾脆就給個全域變數當作開關？

$HTTP::Request::Common::DYNAMIC_FILE_UPLOAD = 1;

雖然有 callback 的話應該還是有點用途的。

class variables in Moose

Moose attribute didn't allow the reference rather than a CODE reference as a default value. That prevents the objects shared a attribute when initializing. Actually this is a good design. But How should I do when needing a shared attribute between objects? I may refer this as the concept of class variable.

The state variable in CODE reference may be competent with this role.

A Counter as an example here. We define a Counter class here.



A counter has a attribute "value" and a method "inc" to increment it.

Then We define a Person class.



The Person class has a attribute "name" and a shared attribute "count". The Counter is a state variable return from a anonymous CODE reference. That's the trick.

The BUILD hook increment the counter everytime a new Person is constructed.

Then we examinate the shared variable.



A global variable in package name may still work. But this way uses 'has' syntax sugar. :p

If you use builder to replace the default option. the subroutine used by the builder is just the class variable accessor from Class name, returning value as $person->count().

Mysterious Timestamp

時間轉換大概是最惱人的「小」問題之一，每個語言的標準處理方式不盡相同。Perl 的 localtime() 是月份從 0 開始到 11 結束，Ruby 的 DateTime 是月份是從 1 開始的，不過 Perl 的 DateTime 月份也從 1 開始 (LOL)。背誦這些東西大概會發瘋。

不過 Epoch 沒有這個問題，任何語言上的 Epoch 應該都是一致的，有的只是時差問題，使用 Epoch 來初始時間物件大概是避開這問題的好方法之一，特別在不同語言間交換時間資料時，用 Epoch 交換後怎麼 format 都不會出問題。所以有些時間模組大概會像 Perl 的 DateTime 一樣實作 from_epoch() 這種 constructor。

就這點設計而言，Badger::Timestamp 大概是最好用的時間模組，其 constructor 支援 DateTime 模組的方式初始化外，還可以餵食 Epoch 和 ISO 格式的時間字串。一個簡單的 Epoch/ISO converter 只要八行。

什麼，你問說這八行程式有什麼用，有些跑了好幾年的 unix 系統上有著 crontab 執行著需要 timestamp 來分辨執行區段的分析器，有些要當天的零分零秒，有些要隔天的零分零秒。壞掉時有人會要你一定要「人工」處理，這八行就就是這樣來的。

附帶一提， Javascript 的 Date.UTC 和 Perl 的 localtime() 一樣，都是月份從 0 開始。

為什麼Javascript的月份是從0開始的 (-_-) w3schools.com/jsref/jsref_ut…

— Alec Chen (@alec929) February 28, 2012

和 Badger::Timestamp 很像的 moment.js這時候就很好用了，其 constructor 用陣列初始化時雖然還是沒有改用 1 作為月份起始著實也讓我驚訝了一下。好險，這 constructor 支援用 Epoch 初始化(不過承襲 javascript 的慣例，是 millisecond)，還可以用 Date.parse() 支援的字串初始化。這兩招可以避開月份的問題。

meet git-p4

For some reasons, in recent works I have to use Perforce, the revision control system used by Perl core team before 2008. Unfortunately, perforce lacks of distributed features and leads to heavy branching. In this developing, these two problems often interrupted programmers with conflicts hardly to solve. Bad workflow design also makes members forget to check out before editing randomly. A git subcommand git-p4 lets you use the great tool git locally with the smooth integration to perforce server.

The steps to configure on kernel.org are currently unavailable. The official site of Perforce saved a copy. Following normal steps to write .p4config to setup p4client and install p4 and git-p4 into $PATH, $ git p4 clone //depos/path /local/path would just work. After local commit of git, $ git p4 rebase && git p4 submit works just like $ git pull --rebase && git push to remote git repository.

By the way, if you use Mercurial there is also a perforce extension can enable hg to clone perforce repository directly with a few of setup.

However, I strongly recommend perforce users migrating to modern distributed revision control system. After all, all the best companies and organizations have given Git / Mercurial a big hug, such as Github, BitBucket, Apple, Google Code, Perl, Rails, Gnome, Debian, Android and Linux Kernel. The git-p4 is a good transformer.

2012-04-26 update:
The git-p4 is now part of the git distribution and the version on github is no longer updated and doesn't work.

Arrange bashrc

A simple recursive function can have aid on arranging bashrc files in a clear structure.



Add a line to source it in ~/.bashrc first, and then collect similar rc files into directories respectively.

If a bunch of bash completions were put inside ~/.bash_completion/, like

~/.bash_completion
|-- hg
|-- git
|   |-- git
|   |-- gitk
|   `-- git-common
`-- svk

just one more line

  load $HOME/.bash_completion

would load whole completions.

You may also have many aliases, environment variables, function definitions for different OS like this

~/.bashrc.d
|-- linux
|   |-- aliases
|   |-- env
|   `-- functions
|-- freebsd
|   |-- aliases
|   |-- env
|   `-- functions
`-- darwin
    |-- aliases
    |-- env
    `-- functions

Just one another line

  load "$HOME/.bashrc.d/$(lower $(uname))"

can load correct system-specified rc files.

MySQL 5.5.10 homebrew install issue

Coming after the mysql 5.1.52 homebrew install issue, the just released mysql 5.5.10, which solved the previous problem, has another issue.

When starting mysql daemon with mysql.server script, it showed error message like

ERROR! The server quit without updating PID file (/usr/local/var/mysql/data/*********.pid).

The new homebrew instruction to install mysql makes its default $datadir to be $basedir/data but the setting of $datadir in mysql.server line 70 didn't be fixed to corresponded to the change.

Adjust $datadir in script or just use boot parameter --data-dir=/usr/local/Cellar/mysql/5.5.10/data/ makes mysql.server work.

Tasting Perl6

At the moment that the first release of Rakudo Star has been announced over four months, binary packages or tested build in package managers have been provided in varieties of OS. If we want to taste Perl6 on Mac OS X, the best choice seems to be using Homebrew. Just type in $ brew install rakudo-star and run $ perl6. Rakudo Star in Homebrew has been updated to the newest version: 2010.10.

On Debian-like system, the best one should be using PPA of dexter on LaunchPad. The version falls behind Homebrew a little to be 2010.09. Because the Rakudo Star requires Parrot 2.8+, we also have to add PPA of Parrot to satisfy. Command $ sudo apt-add-repository ppa:dexter/rakudo-pkg ppa:dexter/parrot-pkg and run update, install. Then have fun!

Intro to App::CLI

My first meet with App::CLI is in the summer of 2008, trying to write JiftyX::Fixtures. Without abundant PODs coming with this module, it took me almost one day to understand this module through trial and error. Since, I write this intro to reveal more power from this module; even I have contribute some code and DOCs to the project.

Actually, App::CLI is a really powerful module having central idea similar to the dispatcher in many web application frameworks such as Rails. When we are trying to create yet another handy CLI tool for our daily working, here is a recommended architecture to use App::CLI:

MyApp                  
-> The kernel of our new tool

MyApp::*               
-> All other module forming the mechanism 
-> of our new tool, e.g. MyApp::Config
-> for loading configuration

MyApp::Command         
-> The dispatcher serving the invoking commands

MyApp::Command::*      
-> All subcommands invoked by MyApp::Command

MyApp::Command::*::*   
-> All subsubcommands invoked by specific subcommand

MyApp::Command::*::*::*
-> subsubsubcommands *god*

After deciding what command we need to implement, we only have two things should be done. The first is making MyApp::Command be able to dispatch. What we need to do is only add use base qw(App::CLI); into it.

Now, in MyApp.pm or our script, where we want to invoke command, we can just say

MyApp::Command->dispatch();

MyApp::Command would automatically use @ARGV to determine what (sub)command it should invoke and find its package to *require*. For example, if we type $ myapp list user --sort age in terminal, the @ARGV would be qw(list user --sort age), and MyApp::Command would require MyApp::Command::List::User, create its instance as $cmd, assign $cmd->{sort} as 'age', finally invoke $cmd->run_command().

So, The second thing, most of we need to effort, is to implement our (sub)commands. it's a bit like writing Controllers of Rails. If the URL matches /foo/bar/:id, the Action #list() of Controller Foo::Bar would handle the request, and @id would be assign value. If users type $ myapp list nickname --name /mark/ MyApp::Command::List::Nickname would handle the command and $instance->{name} would be assign string /mark/. For this case, we can write as below.

package MyApp::Command::List;
use base qw(App::CLI::Command);
use constant subcommands => qw(User Nickname);
use constant options => (
    "h|help" => "help",
);

sub run {
    my ($self, @args) = @_;
    if ($self->{help}){
        # output PODs when $ myapp list --help
    }
    # do something when user type like 
    # $ myapp list arg1 arg2 --opt1 --opt2 opt_arg2
    # and arg1 doesn't equal to User or Nickname
}



package MyApp::Command::List::Nickname;
use base qw(App::CLI::Command);
use constant options => (
    "name=s"  => "name",
);

sub run {
    my ($self, @args) = @_;
    $name = $self->{name} #=> /mark/
    # query the data base via condition /mark/
}

It completes. Note the we can specify all possible subcommands in constant subcommands of and give all possible options in constant options to all (sub)commands and just implement &run() the (sub)command would be done. And finally, note we can cascading subcommands infinitely. That is the core power of this module starting from v0.2.

Enjoy.

Keep favorite info pages in $HOME

Info is a handy document system most emacs fans love. We can learn Info, Emacs Basics, Emacs Lisp, Magit and blah blah blah through the system and look up any detail every time we need without leaving Emacs, so that I install many info pages into /usr/local/info, /usr/share/info and /usr/share/local/info. However, when I need to migrate all data to new computer, keeping my info pages is really a nightmare. So I add a few of lines shown below into ~/.emacs

(custom-set-variables
  '(Info-default-directory-list 
     (append Info-default-directory-list 
             '("~/.info"))))

and put all info pages I collected before into ~/.info

Now I just need to migrate all files in my $HOME to new computer.