To get pecl working properly, make sure you have Xcode installed on you machine. Next, you will need to get a copy of MAMP’s source and prepare it using 32-bit compile flags. You can download the MAMP source from the MAMP download page. Running the .dmg should extract the source. After extracting the source run the following:


mkdir /Applications/MAMP/Library/Include/
mv /path/to/extracted/mamp/source/ /Applications/MAMP/Library/Include/


Next you will want to extract the PHP package and do the following to prepare the package:


mv /Applications/MAMP/Library/Include/extracted_php_source/ /Applications/MAMP/bin/php5/include/php/
cd /Applications/MAMP/bin/php5/include/php/
MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64' LDFLAGS='-O3 -arch i386 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64' ./configure --with-php-config=/Applications/MAMP/bin/php5/bin/php-config


Finally, you now can install pecl extensions with the following command:

MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64' LDFLAGS='-O3 -arch i386 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64' /Applications/MAMP/bin/php5/bin/pecl install


And that’s it! Enjoy!

Installing a 32-bit JDK is very easy. First, download the right package from the sun download site: http://java.sun.com/javase/downloads/index.jsp and extract it. To extract the .bin file, you need need to make sure to make the .bin file executable. After that, you can run the file and it should extract itself to the current directory. You can now use the JDK by referencing it directly or by setting it as an alternative using the appropriate instructions. For the purpose of this article however, we don’t need to get into that. Next, you will need to update your start/stop scripts to take advantage of the new JDK.

Unfortunately, you still have more to do because the start/stop scripts use JSVC to control the Tomcat daemon. If you try to startup tomcat after referencing the new JDK, you will notice that you get an error stating that it cannot locate a valid JVM. This is because the JSVC that has been installed, is a 64-bit binary and is looking for a 64-bit JVM. You will now need to recompile JSVC as a 32-bit binary so that you can use it with your 32-bit JDK. This is where things get a little tricky. After some googling, I found the following instructions. Unfortunately, these instructions didn’t work for me as is.

To compile JSVC, you will first you need to download and extract the JSVC source. Next, make sure you have lib32gcc1 and libc6-dev-i386 installed. On a Debian system you can do this with the following command:

sudo aptitude install lib32gcc1 libc6-dev-i386

If you do not have the packages installed, aptitude will prompt you to install the packages. Next, run the following configure commands to configure and build JSVC:

cd /path/to/jsvc/src/native/unix/
CFLAGS=-m32 CPPFLAGS=-m32 CCASFLAGS=-m32 LDFLAGS="-L/path/to/32/bit/shared/libraries/" ./configure --with-java=/path/to/32/bit/jdk/ --build=i686-pc-linux-gnu
make
cd native/
gcc -m32 -L/path/to/32/bit/shared/libraries/ -ldl -lpthread jsvc-unix.o libservice.a -o ../jsvc

On a Debian machine the path to your shared libraries might be:

/emul/ia32-linux/usr/lib

By this point, you should have a jsvc binary in your /path/to/jsvc/src/native/unix/ directory. You can move this where ever you like and reference it from your tomcat start/stop scripts. Now, your done!

is an open source platform that brings the power of Lua to web development

While this was my goal, I wanted to start from scratch since I haven’t had any experience with the language and didn’t want to learn it on a specific platform just yet. So, I went on to figure out how to install and configure Lua with MAMP. To accomplish this yourself, you will need: Xcode, MAMP, Lua, LuaRocks, MAMP source, and mod_fcgid.

Step 1: Install Xcode

This one is pretty straight forward. You can easily install Xcode if you have an OS X install DVD. Otherwise you can download it from the Apple Developer Center.

Step 2: Install Lua

Installing Lua is also straight forward. Download the source from Lua’s FTP site. I chose the current version (5.1.4). After extracting the source run the following commands:

cd /path/to/source/
make macosx
sudo make install

This should install the Lua interpreter into your /usr/local/bin/

Step 3: Install LuaRocks

To install LuaRocks, you first need to download the source. The current release is 2.0.1. After downloading the source run the following commands:

cd /path/to/source/
make
sudo make install

This should install luarocks in /usr/local/bin/ . You can test your installation with:
luarocks help
You should be presented with a list of commands to use luarocks.

Step 4: Install Lua MySQL support

This part is a little tricky as you need to make sure you have the source for your MAMP installation. You can download the MAMP source from the MAMP website. Running the .dmg should extract the source. After extracting the source run the following:

mkdir /Applications/MAMP/Library/Include/
mv /path/to/extracted/mamp/source/ /Applications/MAMP/Library/Include/

Once you have moved your source over, extract the MySQL package then run the following commands:

cd /Applications/MAMP/Library/include/mysql-5.1.37/
./configure
make

Once you have finished building MySQL, you will want to move the mysqlclient into the current MySQL location:

cp /Applications/MAMP/Library/include/mysql-5.1.37/libmysql/.libs/*.dylib /Applications/MAMP/Library/lib/mysql/

You will now be able to install the luasql-mysql package from luarocks with the following command:

sudo luarocks install luasql-mysql 2.2.0-1 MYSQL_INCDIR=/Applications/MAMP/Library/include/mysql-5.1.37/include MYSQL_LIBDIR=/Applications/MAMP/Library/lib/mysql


Step 5: Install Lua fcgid wrapper

This is an easy one:

luarocks install lua wsapi-fcgi 1.1


Step 6: Install Apache mod_fcgid

This part was a bit tricky for me since I don’t have much experience compiling Apache modules. First, you will need to extract the httpd source, for me this was httpd-2.0.63.tar.gz. Next, you will want to build Apache into a separate directory. Use the following to build Apache:

./configure --prefix=/path/to/target/Apache
make
make install

While running the make command, you may get the following error:


sendrecv.c:965:2: error: #error APR has detected sendfile on your system, but nobody has written a
sendrecv.c:966:2: error: #error version of it for APR yet. To get past this, either write apr_sendfile
sendrecv.c:967:2: error: #error or change APR_HAS_SENDFILE in apr.h to 0.


Fixing this is simple, all you need to do is edit /Applications/MAMP/Library/include/httpd-2.0.63/srclib/apr/include/apr.h and make the following modifications:

-#define APR_HAS_SENDFILE 1
+#define APR_HAS_SENDFILE 0


I know its taken quite some time now, but you are almost done! All that’s left is to build mod_fcgid and configure Apache. To build mod_fcgid run the following commands:

APXS=/path/to/target/Apache/bin/apxs ./configure.apxs
make
make install
cp /path/to/target/Apache/modules/mod_fcgid.so /Applications/MAMP/Library/modules


Step 7: Configure Apache for mod_fcgid and Lua

Now that you have everything built and in place, you just need to configure Apache and then you will be ready to start building Lua web apps!

Open /Applications/MAMP/conf/apache2/httpd.conf with your favorite text editor and add the following to the load modules section:

LoadModule fcgid_module modules/mod_fcgid.so

While you are at it, you can comment out the following lines if you like (I am not sure if it is possonlble to run mod_cgid with mod_fcgid, so I just took them out).

#LoadModule cgi_module modules/mod_cgi.so
#LoadModule cgid_module modules/mod_cgid.so

Next, find the IfModule mod_fcgid directive, and add the following under it:


AddHandler fcgid-script .lua
FcgidWrapper /Users/avayanis/.luarocks/bin/wsapi.fcgi .lua
Options +ExecCGI


Finally, restart Apache through the MAMP application and test it out! Here is a sample lua script to test out your Lua environment:

module(..., package.seeall)
 
function run(wsapi_env)
    local headers = { ["Content-type"] = "text/html" }
 
    local function hello_text()
        coroutine.yield("Hello World!")
    end
    return 200, headers, coroutine.wrap(hello_text)
end

Edit #2: I don’t mean for this article to be followed verbatim, but rather, used as a guide to understanding Zend Framework’s routing process.

Now that I am using ZF for current projects at work, I have taken the opportunity to promote ZF with my colleagues. One colleague in particular, who has been using Code Igniter(CI), was somewhat perplexed by ZF’s seeming complexity, even after reading through the first few sections of the Reference Guide. In particular, he didn’t understand how ZF handled URIs as it is quite different from CI. So, I have put together the following, hopefully simple overview, explaining a bit about ZF’s routing and using it in conjunction with Zend_Config.

Out of the box, ZF routes URIs by turning the first segment into the controller and the second segment into the action, unless you have specified a module directory, in which case, the first segment becomes the module, the second segment the controller and the third segment the action. Any segments beyond that are converted into key-value pairs that are accessible through the front controller’s request object.

Therefore, something like http://www.vayanis.com/post/view/id/101/title/new-post is translated into a request for the ‘post’ controller, and ‘view’ action with two request parameters: ‘id’ with value ‘101′ and ‘title with value ‘new-post’. Accessing these parameters is simple:

$id = $this->_request->getParam('id');
$title = $this->_request->getParam('title');

Unfortunately, this default behavior is bad for SEO because it adds unnecessary and useless information to the URI, but like many things in ZF, there is a solution and so I turn to the Zend_Controller_Router_Rewrite.
As the documentation states:

Zend_Controller_Router_Rewrite is designed to allow for mod_rewrite-like functionality using pure php structures. It is very loosely based on Ruby on Rails routing and does not require any prior knowledge of webserver URL rewriting.

So, to simplify this URI, I can create the following route:

// Get Front Controller Instance
$front = Zend_Controller_Front::getInstance();
 
// Get Router
$router = $front->getRouter();
 
$route = new Zend_Controller_Router_Route(
    'post/:id/:title',
    array(
        'controller' => 'blog',
        'action'     => 'post'
    )
);
 
$router->addRoute('post', $route);

This will shorten the previous, lengthy URI from http://www.vayanis.com/post/view/id/101/title/new-post to http://www.vayanis.com/view/101/new-post

Finally, like most components, if you are not comfortable maintaining your configuration in pure php, you can instead use a INI config file. The equivalent of the previous example could be defined in an INI config file with the following code:

[production]
routes.post.route = "post/:id/:title"
routes.post.defaults.controller = blog
routes.post.defaults.action = post

To use the INI with a router, use the following:

// Get Front Controller Instance
$front = Zend_Controller_Front::getInstance();
 
// Get Router
$router = $front->getRouter();
 
$router->addConfig(new Zend_Config_Ini('path/to/route/config/file', 'production'), 'routes');

MacFUSE implements a mechanism that makes it possible to implement a fully functional file system in a user-space program on Mac OS X (10.4 and above).

In a nutshell, MacFUSE lets you turn any number of connection interfaces into a fully functional file system. With the files provided in the link above, you can mount an FTP or SSH login as a network drive, thus solving my issue of using subversion over a network drive. The best part is, I can now easily access my Mac Pro remotely as well. Although, now that I think about it, I have never tried to mount a remote drive over AFP so that could have always been possible.

I have to admit this is my new favorite development tool since it makes working remotely much more pleasant. Instead of opening files one at a time through Cyberduck, my FTP client, and Textmate, I can now mount my FTP account as a network drive and create projects with Textmate to edit all my files. This also happens to be a great solution for all the people wishing for FTP support within Textmate.

Anyhow, I hope this can be of help to someone else.

The only way I found to correct this problem is to add decorators to each element individually. This is highly redundant and hardly ideal, but it gives the control necessary to fix this problem. It also bloats the config file significantly; previously, the config was 31 lines long, but now it is 47 lines long:

[login]
; General Form Information
login.action = "login/submit"
login.method = "post"
login.id = "login"
 
; Form Decorators
login.decorators.elements.decorator = "FormElements"
login.decorators.table.decorator = "HtmlTag"
login.decorators.table.options.tag = "table"
login.decorators.form.decorator = "Form"
 
; Username Element
login.elements.username.type = "text"
login.elements.username.options.label = "Username:"
login.elements.username.options.required = true
login.elements.username.options.validators.alnum.validator = "alnum"
login.elements.username.options.validators.regex.validator = "regex"
login.elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
login.elements.username.options.validators.strlen.validator = "StringLength"
login.elements.username.options.validators.strlen.options.min = "5"
 
; Username Decorators
login.elements.username.options.decorators.helper = "ViewHelper"
login.elements.username.options.decorators.tableData.decorator.td = "HtmlTag"
login.elements.username.options.decorators.tableData.options.tag = "td"
login.elements.username.options.decorators.label.decorator = "Label"
login.elements.username.options.decorators.label.options.tag = "td"
login.elements.username.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.username.options.decorators.tableRow.options.tag = "tr"
 
; Password Element
login.elements.password.type = "password"
login.elements.password.options.label = "Password:"
login.elements.password.options.required = true
login.elements.password.options.validators.strlen.validator = "StringLength"
login.elements.password.options.validators.strlen.options.min = "6"
 
; Password Decorators
login.elements.password.options.decorators.helper = "ViewHelper"
login.elements.password.options.decorators.tableData.decorator.td = "HtmlTag"
login.elements.password.options.decorators.tableData.options.tag = "td"
login.elements.password.options.decorators.label.decorator = "Label"
login.elements.password.options.decorators.label.options.tag = "td"
login.elements.password.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.password.options.decorators.tableRow.options.tag = "tr"
 
; Submit Form Element
login.elements.submit.type = "submit"
login.elements.submit.options.label = "Submit"
 
; Submit Decorators
login.elements.submit.options.decorators.helper = "ViewHelper"
login.elements.submit.options.decorators.tableData.decorator = "HtmlTag"
login.elements.submit.options.decorators.tableData.options.tag = "td"
login.elements.submit.options.decorators.label.decorator = "Label"
login.elements.submit.options.decorators.label.options.tag = "td"
login.elements.submit.options.decorators.label.options.class = "submit"
login.elements.submit.options.decorators.tableRow.decorator.tr = "HtmlTag"
login.elements.submit.options.decorators.tableRow.options.tag = "tr"

Personally, I think this is poor design and feel it may even be a bug, but I will attempt to submit it to ZF’s issue tracker and see what they say. Otherwise though, I still feel as though Zend_Form is a great component, and will continue to publish any discoveries I come across.

login.elements.username.type = "text"

And turns it into:

Array
(
    [login] => Array
        (
            [elements] => Array
                (
                    [username] => Array
                        (
                            [type] => text
                        )
                )
        )
)

Now, back to Zend_Form. I think my biggest gripe with the documentation provided for Zend_Form is that it does not explain how anything is working behind the scenes. For instance, it does not explain that Zend_Form normalizes config statements by prepending ’set’ when making calls to member methods. This is invaluable as it explains why

    $form->setElementDecorators(array('ViewHelper'));

in PHP becomes

    elementDecorators.helper = "ViewHelper"

in a Zend_Config_Ini. Internally, elementDecorators tells Zend_Form to call setElementDecorators(); This small example also shows why it is important to know how Zend_Config_Ini actually translates an INI to PHP…

Array
(
    [elementDecorators] => Array
        (
            [helper] => ViewHelper
        )
)

As we can see this declares an array of decorators to be passed into setElementDecorators(); The keys, in this case “helper”, do not necessarily matter as it is only needed to index the array, the values are what matter, as that is what is passed and used within Zend_Form. Similarly, it is important to know that almost all aspects of form and form elements, excluding form element type, are implemented internally as options. The following is an example INI file with comments explaining particular sections.

    ; A basic Form config
 
    ; First level attributes are automatically treated as options.
    action = "login/submit"
    method = "post"
    id = "login"
 
    ; Form Decorators
 
    ; Again these decorators are treated as options of the main form.
    decorators.elements.decorator = "FormElements"
    decorators.table.decorator = "HtmlTag"
    decorators.table.options.tag = "table"
    decorators.form.decorator = "Form"
 
    ; Username Element
 
    ; Form Element Type is specified explicityly, not as an option.
    elements.username.type = "text"
 
    ; Username attributes (Label, Required, and validators are all
    ; declared as options).
    elements.username.options.label = "Username:"
    elements.username.options.required = true
    elements.username.options.validators.alnum.validator = "alnum"
    elements.username.options.validators.regex.validator = "regex"
 
    ; Validator parameters such as pattern to regex are also
    ; declared as options. I have not looked into it, but I
    ; assume this is due to the way Zend_Validate handles its
    ; own constructors.
    elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
    elements.username.options.validators.strlen.validator = "StringLength"
    elements.username.options.validators.strlen.options.min = "5"

Bringing it all together, the following is the first version of my login form.

    [login]
    ; General Form Information
    login.action = "login/submit"
    login.method = "post"
    login.id = "login"
 
    ; Form Decorators
    login.decorators.elements.decorator = "FormElements"
    login.decorators.table.decorator = "HtmlTag"
    login.decorators.table.options.tag = "table"
    login.decorators.form.decorator = "Form"
 
    ; Username Element
    login.elements.username.type = "text"
    login.elements.username.options.label = "Username:"
    login.elements.username.options.required = true
    login.elements.username.options.validators.alnum.validator = "alnum"
    login.elements.username.options.validators.regex.validator = "regex"
    login.elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
    login.elements.username.options.validators.strlen.validator = "StringLength"
    login.elements.username.options.validators.strlen.options.min = "5"
 
    ; Password Element
    login.elements.password.type = "password"
    login.elements.password.options.label = "Password:"
    login.elements.password.options.required = true
    login.elements.password.options.validators.strlen.validator = "StringLength"
    login.elements.password.options.validators.strlen.options.min = "6"
 
    ; Submit Form Element
    login.elements.submit.type = "submit"
    login.elements.submit.options.label = "Submit"
 
    login.elementDecorators.viewHelper = "ViewHelper"
    login.elementDecorators.errors = "Errors"
 
    login.elementDecorators.tableData.decorator.td = "HtmlTag"
    login.elementDecorators.tableData.options.tag = "td"
    login.elementDecorators.tableData.options.class = "test2"
 
    login.elementDecorators.label.decorator = "Label"
    login.elementDecorators.label.options.tag = "td"
 
    login.elementDecorators.tableRow.decorator.tr = "HtmlTag"
    login.elementDecorators.tableRow.options.tag = "tr"

This creates a login form with a username and password field along with a submit button. However, instead of being wrapped in a definition list using definition titles for labels and definition data for input fields, I have wrapped the labels and input fields within a table similar to the google login form. Notice though, that I have sectioned this form using [login]. Tthis is so that I can define all my necessary forms in one forms.ini file and load each form by section. I have also prepended each declaration with login. as a way to keep my form definitions organized and easy to read (to me at least).

Concluding this guide, I would like to reiterate, how useful I think Zend_Form is as it solves one of the most tedious process for any PHP project; form creation and validation. I hope it continues to evolve and mature, and I hope others find it as handy as I have. Although, if anyone has an easier solution, please let me know.

$loginForm = new Zend_Form(new Zend_Config_Ini('/path/to/form/config', 'login'));

This will create a Zend_Form object by passing it a Zend_Config_Ini object.

Unfortunately, when you decide to build a custom form using Zend_Config, the documentation on how this actually works, is extremely sparse. There are three examples of using the Zend_Config, however, they are not commented and there is no explanation as to how it works, there is only a weak reference to PHP object oriented code from which to draw conclusions from. Maybe, I am too used to the Java API documentation.

Anyways, after a few days with ZF, it has become apparent to me, that ZF is a very well written, powerful, extensible, and versatile PHP framework. However, due to its incomplete documentation, I would argue that its’ learning curve is fairly high, much higher than Code Igniter’s. In time though, I am sure the ZF developers will realize this, and make the effort to provide better documentation. In the meantime though, I am going to continue to use ZF and hopefully, take it upon myself to provide some insight; a Zend_Form tutorial using Zend_Config is already in the works.

Since I don’t play the game as much as I did when it first game out, I have no business trying to analyze the flaws of the original compared to what Blizzard has done and is doing with the sequel. Therefore, I will stick to enumerating the new additions found in this latest gameplay trailer.

Highlights

1. The Terran Command Center now doubles as an scv transport. This gives Terrans unprecedented mobility when trying to rebuild.
2. Terran buildings now have modular addons. Each addon, provides special functionality. In particular, the Reactor allows buildings such as barracks to double their output capacity.
3. The new detector, the Sensor Tower, upgrades into a radar tower which has a much larger range and allows players to detect enemies in the fog of war.
4. Battlecruisers (and possibly all major units) are upgraded individually. This means you must spend resources per Battlecruiser to give them your choice between the old Yammator Canon and the new Plasma array.
5. The Viking is the new Valkyrie. It deals area of effect (AOE) damage to capital airships, but thats not all. It can also transform into a ground assault unit.
6. The Banshee is the new Wraith. It is an air unit with the ability to cloak, but unlike the Wraith, it is armed with AOE missiles (This seems a bit too much considering the new Viking, so I wonder if it is only an Air to Ground attack unit).
7. As was seen in the original gameplay trailer, the Reaper is a new light ground unit with the ability to traverse terrain obstacles. However, this new trailer highlights the Reaper’s new armament: demolition charges. These demolition charges are basically land mines with timers.
8. The Terran Command Center now has the ability to transform into a planetary fortress, giving it a heavy artillery canon for defending against enemies.
9. The Thor is the new Terran heavy siege unit. It looks like a cross between a Battlecruiser and a Siege Tank as it has both, powerful laser canons and a siege mode.
10. Replacing the Vulture is the Cobra, a fast ground attack vehicle armed with a rail gun.
11. Last, but not least, are the Ghosts. However, Ghosts are no longer weak attack units. They come with a new “sniper” attack that is a slow and high damage (one shot against marines). In addition to the traditional nukes, Ghosts can call down drop pods which are basically paratroopers. This should make base raids and sieges particularly interesting.

Since this is the third time I have seen the gameplay trailer, I must admit, I am impressed with the direction of Starcraft 2. Although it stays true to the original in terms of gameplay, this sequel adds many new dynamics to the game. Each race we have seen so far looks like they will have many more options for building effective armies. Micromanagement will again most likely separate good players from great players, and as I said in my last post, terrain will probably be a big part of the game. All we need now, is the Zerg’s gameplay trailer so that we can marvel in what will be Starcraft 2.

Trailer Download

Blizzard’s Starcraft 2 movie page

The following is a code snippet from the HTTP and HTTPS documentation that shows how to easily send data using HTTP POST:

$postdata = http_build_query(
    array(
        'var1' => 'some content',
        'var2' => 'doh'
    )
);
 
$opts = array('http' =>
    array(
        'method'  => 'POST',
        'header'  => 'Content-type: application/x-www-form-urlencoded',
        'content' => $postdata
    )
);
 
$context  = stream_context_create($opts);
 
$result = file_get_contents('http://example.com/submit.php', false, $context);

Quick Explanation

1. http_build_query: Generates an URL-encoded string from an associative array. Example: array(‘key1′ => ‘value1′, ‘key2′ => ‘value2′) becomes “key1=value1&key2=value2″

   This properly encodes the data for the post transaction.

2. stream_context_create: Creates and returns a resource to a stream context from an associative array of arrays in the format $arr['wrapper']['option'] = $value

   This creates a linear output stream to be sent during the request transmission.

3. file_get_contents: Acts exactly like file(); except that it reads an entire file into a string.

   This requests a file resource and puts the result into a string.