The camera change from Nikon D200 to Nikon D3 with its sensor size change from APS-C aka DX to full frame aka FX unfortunately made the purchase of a new all rounder lens imminent. And so I switched from 'AF-S DX VR Zoom-NIKKOR 18-200mm f/3.5-5.6G IF-ED' to 'AF-S VR Zoom-NIKKOR 24-120mm f/3.5-5.6G IF-ED'.



The picture was shot using the 'AF-S VR Micro-NIKKOR 105mm f/2.8G IF-ED' on the D3 and post-processed with Adobe Lightroom 2.0 beta and Corel Paint Shop Pro XI.

Both lenses have a UV filter mounted. The 18-200/VR has a B&W filter while the 24-120/VR has a Hoya filter. Both lenses come with VR and share the same aperture range, that is f/3.5 to f/5.6. Also the wide range is very compareable as the 18mm on the DX camera turns into 27mm on 36mm film, while the 24mm are already correct in terms of 36mm film equivalent, when mounted on the D3.

The unfortunate difference is the telephoto range. Here the 200mm DX format turns into 300mm on 36mm film. And that is way more than the 120mm of the FX lens.

Interestingly, the switch does not come with a handling difference - at least not in lens handling. Both lenses nearly look identical and share a more or less identical housing. But as to be expected, the 18-200 goes out much more than the 24-120 does. Sharpness-wise it appears both lenses deliver the same quality. Meaning they do a great everyday job but do not take very sharp pictures. Since even the flowers of both lenses are nearly identical, I had to check the internet to figure out which one belongs on which lens. The HB-35 has broader fins and belongs on the 18-200. The 24-120 is a tad bit wider, so it takes the HB-25 with its smaller fins.

I actually bought the camera and lens in Switzerland where prices are insanely high - though yet much lower than for instance in Germany. So I spent some time searching for shops with reasonable prices. I found digitec in Zürich and ars-imago in Zug, which was not too far away and unlike digitec, where I bought the camera, had the lens in stock.

I had to go twice to digitec because the first time they figured they could not get enough money from my ATM cards. It turned out that my two German ones only allow higher charges in Germany - or they just don't care so that you pay with Credit Card. For that however they happily charge 2.75% extra. That is absolutely ridiculous and of course unacceptable. So I came back the next day after visiting my bank in the morning. And believe me, it really feels strange running around with 6k in cash.

When I decided for the lens and found ars-imago I chose them for one reason. It was the cheapest place with the lens in stock that was reachable by car. There was one shop where I could have ordered the lens on-line. Including charges for shipping I would have paid the same, well there also is the credit card insanity. So I either would have had to wait longer or pay this unbelievable special Swiss insanity extra charge. So I happily drove to Zug after reading that there was the last lens of its kind waiting for me to be picked up. However when I arrived they told me with the typical Swiss smile, that my lens was sold half an hour ago. That means that those idiots sold my lens just after they sent me the confirmation that I can pick up the lens on the same day. They assured me the lens would come next business day which was two days later. So I lost one day for experimenting - dammit! The least thing one would expect now - of course - is that they would give a bit of a rebate for making me drive twice. But nothing - that's Switzerland. Lesson learned, never buy anything from ars-imago again.

That's it really. A cute search box that's "self contained" inside a PHP function so it's extremely convenient to display. What can I say? I got bored... [Link]

For now over three years we are working with unit tests. I’d like to share some of those experiences.

As we have two frameworks in place for our website, I can compare two different strategies for unit tests.

In our homemade legacy framework we were using SimpleTest. Mainly because I read PHP|Architect’s Guide to PHP Design Patterns and Simpletest was Jason’s framework of choice.

We have a cron job running which runs all tests every hour. The results of the tests are being shown on a page. The results are also displayed in Nagios.

(more…)

Truncated by Planet PHP, read more at the original (another 2564 bytes)

I just found out a very strange PHP feature by browsing the PHP-GTK2 API with the Reflection classes : spaces can be used in some alien places, like variable names.

But the doc says you can't !

Well, try this in PHP 5.2.5, for instance:

read more

I want Enums in PHP

I'm currently working about equally in PHP and Java. I can't say I've fallen in love with Java. But Java does have a feature or two that would be useful in PHP. One of them is the Enum (enumeration, that is), which is traditional in some languages and DBMSes (including MySQL) and was introduced in Java 1.5 (or is that 5.0? I'm sure they do that just to expose people like me as Java amateurs).

Enumerations are useful when a variable can have one of a given number of values. Actually useful examples I've encountered in web programming are states or stages in a process and user roles. Another kind of example is one I used in PHP In Action: an authorization system with three fixed roles or categories of user: regular, webmaster and administrator.

If we represent the roles as text strings, we risk getting our tests wrong:

 
  <a href="”edit.php”">Edit</a>
 
 

The only problem is that the word “administrator” is misspelled, so the test won't work.

This can be solve by representing the values with named constanst instead. Using class constants in PHP 5:

class Role
    const REGULAR = 1;
    const WEBMASTER = 2;
    const ADMINISTRATOR = 3;
    ...
 

Now we can do this instead:

We won't get away with any misspellings here; using an undefined class constant is a fatal error. Compared to global constants, this may be easier to figure out, not least because we know where the constant is defined (inside the Role class) just by looking at it.

This is called the int Enum pattern in the official description of Java Enums. The documentation also lists some problems with this, starting with type safety, which we're not that concerned with in PHP anyway. A more relevant problem is the fact that when you print the value, you just get the number.

But I don't see why you shouldn't use strings for the values:

class Role
    const REGULAR = 'REGULAR';
    const WEBMASTER = 'WEBMASTER';
    const ADMINISTRATOR = 'ADMINISTRATOR';
    ...
 

One PHP-specific problem I didn't mention in the book is the problem that happens with long class names. Since we still don't officially have namespaces in PHP, we will easily end up with nauseatingly long constant names, like this:

It's quite depressing to have to do that a lot. I've tried putting constants in their own class with a shorter name, but I didn't like it much. One thing I tried recently was creating instance methods to return the constant value:

class MyProject_Authorization_RBAC_Role...
    public function REGULAR { return self::REGULAR }
    public function WEBMASTER { return self::WEBMASTER }
    public function ADMINISTRATOR { return self::ADMINISTRATOR }
 

Now we can create an instance with a short name and get the values from that:

$roles = new MyProject_Authorization_RBAC_Role;
if ($role == $roles->ADMINISTRATOR())...
 

All of this just to get shorter names? I little desperate perhaps. So yes, I would like Enums in PHP.

The PHP team is once again proud to participate in the Google Summer of Code. Ten students will "flip bits instead of burgers" this summer: Zend LLVM Extension by JoonasGovenius, mentored by NunoLopesPHP Optimizer by SamuelGraham Kelly IV, mentored by DerickRethansPhD (PHP Docbook) Project by RudyNappée, mentored by HannesMagnussonReplace auto* with CMake by Alejandro LeivaRojas, mentored by Pierre A.Joyegsoc:2008 - XDebug by Chung-YangLee, mentored by DavidCoallierRewrite the run-tests.php script by CesarMontedonico, mentored by TravisSwicegoodPHP Bindings for Cairo by AkshatGupta, mentored by AnantNarayananAlgorithm Optimizations by MichalDziemianko, mentored by ScottMacVicarPECL, Website Improvements by BarryCarlyon, mentored by Helgi ÞormarÞorbjörnssonImplement Unicode into PHP 6 by Henrique do NascimentoAngelo, mentored by ScottMacVicarUpdate (May 11th): Ufortunately Nicholas Sloan had to drop out of the program, but he will be replaced by Rudy Nappée working on the same application.

I recently noticed, that most services needed to develop, manage, and deploy a website are free, except for hosting perhaps. Version control, project management, bug tracking — all that a developer or a small team might need is online for $0, thanks to some far-sighted providers. Most of the services have completely free accounts with some limitations, others provide free trial. And paying a few backs when you need more space or features does not feel too bad since you have been treated well. Here is a list I personally use and can recommend (this is not an advertisement on someone's request!): Springloops Code collaboration for Web developers: SVN hosting, code browser, change reviews, FTP deployment, Basecamp integration Basecamp Project management, collaboration, and task software: projects, to-dos, milestones, writeboards Google Analytics Website statistics, visitor tracking Feedburner RSS statistics and tracking Know more or better? Please let us know :)

Charles Nutter, a Sun engineer who has worked on the JRuby project, commented on PHP in a panel discussion at Sun's CommunityOne conference.

I will not join the "PHP vs. Ruby on Rails" "discussion" here, as the comparison of a programming language to a web application framework for another language does not make sense, IMHO. Instead, I would like to comment on two of Charles Nutter's points.

"With PHP, everyone has his or her own way of doing applications."

I think it is a good thing that the PHP community has a rich offering of framework solutions to choose from.

Although it looks like everyone and their mother is standardizing their PHP-based web application development using the Zend Framework, other component libraries such as the eZ Components and web application frameworks inspired by Ruby on Rails such as Symfony or CakePHP are thriving.

"Testing and tried-and-true design patterns are not part of PHP culture."

Yes, testing has become mainstream / popular thanks to JUnit and the Java community.

Yes, the fact that Ruby on Rails encourages test-driven development is a good thing.

Maybe it took the PHP community a little longer to realize the importance of testing. But now that we know how to build applications that "just work", are fast and scalable, as well as secure, a big topic in the PHP community right now is to implement processes and use techniques that help us assure that the software works correctly throughout the its lifecycle.

As for design patterns: Too many PHP developers are blindly using the GoF Design Patterns in PHP, even when they are not applicable. We have our own design patterns and idioms, though. Things that have no name help developers every day to write scalable code that just works.

You'd never think a guy could write so much about a blog application but to date after 6 parts we have covered a mass of detail from initial setup of our project's directory structure to Authentication of users. To date the feedback has been overwhelmingly positive to this series and I'm presently collecting comments regarding improvements for later inclusion.

Today's entry concerns authorisation. We previously covered how to authenticate an author to the blog, but we still have nothing ensuring only authenticated authors can access the new Administration Module. This is the domain of Zend_Acl, an implementation of an Access Control List system which limits access to resources by the roles assigned to a user.

In the final section of this entry, we take a small detour into the world of CSS (which rarely works out for me ) where I'll apply some small changes to our Layouts and add two new stylesheets. Once these are added, our infant blog application will look slightly more presentable than it's current nakedness.

Step 1: Understanding Access Control Lists (ACL)

It can be a bit confusing to face off against ACL if you're new to the subject. In essence all ACL does is keep track of resources and roles.

As to what a resource is, it is anything to which access can be allowed or denied. For our blog application, I could decide that the Administration Module is itself one resource. From there I can restrict all access to that entire Module, including all it's Controller classes and Action methods (which are part of that single Resource). Or perhaps I could determine that only one Action method in the whole Module is a specific Resource, bearing in mind that Resources are nestable (i.e. a basket is a Resource, and each egg it holds are also discrete Resources). Since each Resource can be given differing access rules, you can globally prevent non-author users from accessing the Administration Module, but maybe allow some registered users access to specific Actions in that Module as an exception to the global rule.

A lot of the time managing global rules, and then applying exception rules, is how ACL works in practice.

Explaining a Role is even simpler. Any visitor to the application can be assigned a Role which ACL rules may use to define that user's access to Resources. Typically the first Role everyone will receive is "guest". From there you can escalate Roles to offer a visitors a greater degree of access to Resources. Any user can be given multiple Roles even. For example, if an author visits the blog they start with the role of "guest" but after authentication we might grant them the additional role of "author". If Roles dictate specific but limited responsibilities (perhaps there's an "author" and "editor" Roles) you might decide to start tracking roles more elaborately, in a database possibly.

Going a bit further, if our Administration Module is a Resource called "admin" then we can decide that the only Role with access to it will be the "author" Role. Since our user has been authenticated and granted the "author" Role (either post-authentication or permanently recorded on the database), they can access the Administration Module.

Finally is the concept of Privileges. Just because you can access a Resource, does not instantly mean you should have total uncontrolled access to it. You can limit control over a Resource using Privileges. Perhaps an Author can access the Admin Module (represented by an Admin Resource) but we want to deny Authors the privilege of deleting entries from the database.

Step 2: A Little Planning Goes A Long Way

Before we leap into the fray like a demented action hero, let's set out exactly what we're aiming for.

Since our blog is a relatively simple application, we really only need two Roles to start with. We'll call these guest and author. This may change in the future, perhaps we could allow for multiple Authors but one Editor capable of editing all posts. In that case we'd need to pick apart how that's implemented. But for now, two Roles is just fine.

As for Resources, the first is the public facing facade of our application where entries are displayed, logins performed, and comments made. The second is the Administration Module. Again, we could be more elaborate but let's not overcomplicate the application until we're forced to . This suggests we only have two Resources: the Default Module and the Administration Module. Remember that the Default Module comprises everything not assigned

Truncated by Planet PHP, read more at the original (another 78418 bytes)