E… ko Blog
Saya adalah Saya

In more detail
In the extended entry I’ll look a bit closer at some of these deviations from the ideal..
Print rather than Echo
This one’s more for consistancy, (we’ve used echo everywhere before, it’s it’s one character shorter
Grepping for echo in a project, is also quite a handy test for any kind of data injection, since most output is our projects is done via template engines. Grepping for :h and echo will find most potential holes. (althoug grepping for print_r / var_dump is also a good idea..)
Exiting on XMLHttpRequest calls.
Most of the XUL based code, and alot of the new HTML/XUL hybrid code I specifiy uses XMLHttpRequest calls to send update/delete/add requests, read more »

Coding Standards

Thankfully, I have managed to cobble together a quite large project coding standard to try and keep projects on track. Without them, Stages III and IV would become unmanagable, as tracing exactly how code was implemented so that both changes and refactoring would become completly impossible.

Unfortunatly, however clear the standards are (or you thought they are), developers have a nack of not following them, either out of habit or just the pressure to deliver so they can get paid.. – So a certian part of the halfway Phase II code review ends up just reiterating where they have missed those elements.

Common mistakes include

• Not following the ‘no if without braces rule’
• not cloning DataObjects, as we develop in both PHP4 and test in PHP5
• creating javascript libraries with functions in them.
• creating PHP includes with functions in them
• Not making the most of the automated url rewriting that FlexyFramework and HTML_Template_Flexy do for CSS, javascript and images.
• Using mysql_real_escape, rather than the more portable DataObjects’ escape() method. (which really wraps PEAR DB/MDB2)
• Incorrect Indentation in javascript files.
• passing strings around as error messages notices, rather than using error and notice flags, so the text of the message is on the templates, rather than in the PHP code.
• Implementing magic constructors on the base controller…
• using $do->whereAdd(‘somevar=1′) when $do->somevar = 1 will do..
• adding ?> at the end of the file – It’s not needed, and will come back to bite you one day.
• Hard coding email subjects etc. in the PHP code, rather than using email templates.
• Adding too many config options – especially file locations.

Reviewing the code also is a great opportunity to update and rewrite some of the standards so that things like this should not happen any more. (Although I wonder if making it bigger means there is even less chance they will follow it)

• using ‘print’ rather than ‘echo’
• for xmlHttpRequest called code, using ‘exit’ in the get()/post() methods, rather than trying to get clever with content-type, and modifying the output method.
• don’t do the page processing in the output method()
• stopping the use of javascript shortcuts – ie:
• function ID(n) { return document.getElementById(n); }
• using libraries that where not specified.. or using non-PEAR libraries when PEAR ones are available… – or creating libraries and plonking them in the Application Tree, with the wrong file/class mapping.
• using commandset/command in XUL rathar than simply oncommand and the Javascript call.
• using cwd(), rather than using dirname(__FILE__), for determinig the path for reading data files.
• creating new object/array’s when cloning dataobjects will work.
• working with session variables from classes outside the one you are in (in The Framework, classes own a session variable $_SESSION[__CLASS__]…, and other classes should not access it directly).
• not implementing a 404 return for unknown get’s on the main page.
• passing get/post requests back up to the main page using parent::get()…
• Hard coding options (eg. enums) into controller classes (eg. currencies or statuses etc.) – put them in the DataObjects, so other pages can get the same list.
• Overlaying config var’s into the controller as raw properties..
• Doing PHP calls in the template that involve alot of Database calls (that are critical and could fail) – Which is why we design code to do the processing before any output occurs, so we can redirect and handle issues gracefully.
• Trying to get clever with sessions to pass errors about, when internal redirectors are intended to send notices back to the next page. (eg. HTML_FlexyFramework::run(”,array(‘notice’=>array(‘user_updated_ok’=>true)));
• excessive nesting of if/while/if/…else etc. – kill that nesting, return, continue or exit from conditions early, eg. negative test, and return, rather than positive test, and if/else.. nested many levels.
• Consistantancy withdataobject methods, in general, dont do updates to a dataobject on a call, unless the method hints’ that it might do it… -> eg. $do->approve() or $do->approveAndUpdate(); …
• Avoid silly code… $obj->is_verified = Project::isAuth() ? 0 : 1 .. either just cast it (int) , or let DataObjects worry about it…
• Making lines so long you can’t read them… Creating an instance of an object to call a method that ‘could’ be static, is not a bad thing, MyProject_DataObjects_Sometable::callaMethod() or $x= DB_DataObject::factory(‘Sometable’); $x->callaMethod();
• Expecting me to chmod directories hidden away in the application. If you need to create temporary or semi temporary files, use the Template engines’s temp directory, rather than trying to create them in the Code source somewhere (so that changing file permissions on svn up/checkout is not needed) – We can always change our default temp directory with set ini_set(session.save_path) in the bootstrapper..
• ConfigData/default.ini are generally depreciated in favour of using the bootstrap to define the default options – and we have a slightly different bootstrap defined for our servers.
• Assuming it’s ok to delete stuff! instead, it should be a basic assumtion, that nothing get’s deleted from databases (eg. it always get’s flagged), so dont write code that actually deletes it, and always check the deleting flag when searching…
• Forgetting to extend the Project base class – Everything extends the base class, even code run via cron jobs.

And sometimes, you realize that the rules you set down may not be totally the best idea…
In one case I advocated using $do->setFrom() rather than seeing a big list of map’s between $POST[] / or something else and a dataobject. However, in some cases either building the object slowly and clearly or listing what you send to setFrom() makes the code considerably clearer. Continue…>>

/* sumber milis phpXperts */

[** not proof read yet - so send corrections not complaints **]
As my freelancing work has scaled up into a full on company (of one still). I have had to evolve from being a one-man coding band into a team leader/manager. This introduced, over the last few years, a slightly different way of working.

Phase I

Specification writing, normally involving doing Inkscape interface designs, along with a huge gnumeric code specification, detailing the database design, along with explaining all classes and templates need for a project.

Phase II

Outsourcing, either to third parties, or to team members within the office I work with. Including a roughly 50% complete code review.

Phase III

The oh sh*t, it’s getting urgent, we better fix the delivered code and make it work well enough for the client to start testing.

Phase IV

The what seems like never ending bug finding and fixing stage.

Where I am at present.

Two of the larger projects I have at present are in Phase II & III. One is being forced to go live, the other is halfway through development. Both being coded by different teams, however, what is interesting is that the issues that come up in the code reviews both, have been pretty similar.

The specification stage, perhaps the most labourious, and sometimes mind numbing if it gets large, is always interesting to look back at. The more I do it, in hindsight, It tends to make you realize, there is no such thing as a perfect specification. It always ends up as a best guess, based on what you think is needed and what you think the end user probably wants.

Dealing with end users is always fun, thankfully, this process tends to deal with the end user in two seperate phases – The Specification and the Bug fixing. (Although what normally happens is that after the bug fixing there is another process called changes – which gets dealt with almost as a new project)

What has interested me alot in the last few weeks, has been, to see how far some parts of the specification I wrote and designed, had to be dramatically changed During Phase III. It seems that however much thought and consideration went into the concepts, there is no way to totally predict how the look and feel translates to trying to actually get things done using the application. I’ve spent alot of time doing mass culling of parts that I spend considerable time trying to specify down to some detail, as when I sat down to test it, It was completely confusting.

Anyway, what I really want to go into, is some of the interesting code that comes out of the code review. Both half way through the project, and the complete overhall that has to be done as you push a project live. So you can demand payment (or at least beg for it..)

Continue… >>
/* sumber milis phpXperts */

Introduction

Without dispute, “enterprise” is a much-disputed term in the software
market. Many companies label their software as an enterprise application
due to marketing reasons in the hope to grab a piece of the cake. PHP
companies are not free from entering the “enterprise barkers”,
especially now that PHP 5 is out[1] – mostly because it offers
better objectoriented and XML programming features compared to PHP4. But
does that qualify to meet the demands of the enterprise market? The past
years have seen a convergence in the enterprise application sector,
favouring a component-based and multi-tier application architecture.
Hence, the question is also whether such architecture can be built for
mission-critical projects with available PHP software. The evolution of
enterprise software development has mainly been driven by the Java 2
Enterprise Edition (J2EE)[2]. Today, J2EE could be named the de facto
industry standard for the development of distributed multi-tier
architecture applications. It is backed up by industry leaders like Sun,
Oracle, BEA, and IBM. This article will compare PHP’s software stack
with what’s available in (and for) J2EE, to overcome the typical
Java versus PHP discussions that usually focus on language features, but
do not take into account the overall picture. Basically, this article
assembles a PHP5EnterpriseEdition(PHP5EE). read more »

Sudah tentu semua pernah melihat situs yang menampilkan kurs mata uang. Sedikit trik kita bisa mengambil kurs mata uang secara realtime menggunakan PHP. Code ini sebenarnya banyak di internet, karena ini memang saya ambil dari sana, hanya saja sudah lupa dimana dulunya .
Dengan berpedoman pada contek, modif dan kembangkan sendiri jadilah seperti yang dibawah ini: read more »

ternyata…
PHP sudah mendukung penggunaan standard MARC record internasional ya… baru tau daku , modul nya bernama yaz (php_yaz.dll di windows ato yaz.so di Linux). cuman sepertinya konfigurasi pada PHP 4 dan PHP 5 ada perbedaan. di PHP 5 belom pernah berhasil dan selalu muncul pesan error di Log Apache seperti berikut:

PHP Warning:  PHP Startup: Unable to load dynamic library ‘C:/php5/ext\\php_yaz.dll’ – The specified procedure could not be found.\r\n in Unknown on line 0
[Sat Aug 12 08:19:03 2006] [notice] Apache/2.0.54 (Win32) PHP/5.1.4 configured — resuming normal operations
[Sat Aug 12 08:19:03 2006] [notice] Server built: Apr 16 2005 14:25:31
[Sat Aug 12 08:19:03 2006] [notice] Parent: Created child process 2120
PHP Warning:  PHP Startup: Unable to load dynamic library ‘C:/php5/ext\\php_yaz.dll’ – The specified procedure could not be found.\r\n in Unknown on line 0
[Sat Aug 12 08:19:03 2006] [notice] Child 2120: Child process is running
[Sat Aug 12 08:19:03 2006] [notice] Child 2120: Acquired the start mutex.
[Sat Aug 12 08:19:03 2006] [notice] Child 2120: Starting 250 worker threads.

So… belom ngerti cara install modul YAZ di PHP 5.1.4

Tapi untuk PHP 4 (terutama PHP-4.4.2) adalah sebagai berikut.
Konfigurasi YAZ di PHP-4.4.2 (windows)
1. load module yaz di php.ini
    extension=php_yaz.dll
2. copy file yaz.dll (berada pada direktori c:\php4) ke direktori C:\windows\system32
3. pastikan file php_yaz.dll telah ada pada direktori c:\php4\extensions
4. restart apache

Paket program yang saya pake Apache 2.0.55, PHP-4.4.2 semuanya for windows.