Tag Archives: php

Quick note: iconv and Building PHP on OSX

When attempting to build PHP 5.3.6 on OSX (Snow Leopard) I got warnings about iconv, which I had installed via ports.

Undefined symbols:
  "_iconv_close", referenced from:
      __php_iconv_strlen in iconv.o
      _php_iconv_string in iconv.o
      _php_iconv_string in iconv.o
      __php_iconv_strpos in iconv.o
      __php_iconv_mime_decode in iconv.o
      __php_iconv_mime_decode in iconv.o
      __php_iconv_mime_decode in iconv.o
      _zif_iconv_substr in iconv.o
      _zif_iconv_substr in iconv.o
      _php_iconv_stream_filter_dtor in iconv.o
      _zif_iconv_mime_encode in iconv.o
      _zif_iconv_mime_encode in iconv.o
 ... etc

To get around this, I had to:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-iconv=shared,/opt/local

TekX

I attended TekX in Chicago last week.

I’ve been attending tek for (I think) four years now, and it’s consistently the best conference I do all year. It’s pretty much the only conference where I attend talks and feel like I’ve gotten something out of them more than merely academic interest. And this year, the Wednesday keynote (Josh Holmes) was the best keynote talk I’ve attended in years. He spoke about the value of simplicity. Specifically, the value of understanding what the customer needs (possibly as distinct from what they ask for?) and giving them that thing they’ve asked for, rather than a framework for generating frameworks for solving a larger class of problems that might some day solve the one they have.

I attended Derick’s talk about the DateTime stuff that he’s been working on. Although I was aware of some of this stuff from his talk two years ago, it was unfinished at that point, and so I haven’t actually played with any of it. I expect to have uses for it, starting today.

Having worked for a while on the DateTime stuff for Perl, I know how hard timezones are, how hard recurring events are, and various other things associated with calendars. Derick has done amazing work.

I attended a talk by @lornajane about Subversion and Git. This was the first non-religious comparison that I’ve seen. I’m so very turned off by the religious fervor that seems to always go along with discussion of revision control. Lorna’s discussion of comparative features, benefits, and so on, was very refreshing, and I finally feel that I have some idea what the real differences and similarities are. This talk was followed by a talk about Git which was more religion and less information, but still gave me some good solid information. I’ve been using Git now for 2 or 3 weeks, and so far I hate it. It appears to solve problems that I don’t have, and make simple things into 3 or 4 steps rather than 1. Offline commits are clearly a really cool thing. Nothing else that Git offers seems to be terribly useful. The rhetoric around Subversion being old and crufty, while Git is new and shiny, just doesn’t seem to match the reality.

I really should write a separate post about Git. I’m getting sidetracked.

Anyways, TekX was brilliant, and I highly recommend that you put it on your schedule for next year if you do anything in the PHP world.

… and back to Perl

For the last five years, roughly, I’ve been doing PHP programming, gradually forgetting the Perl that I knew, except when I wished PHP would do something that Perl makes easy.

One particular syntax I missed on an almost daily basis was:

foo( ) unless $bar;

It was therefore with some trepidation that I started on my new project, which uses Perl, mod_perl, and a heap of CPAN modules that I used to be very familiar with, but have, I thought, forgotten.

I’ve been very pleased to discover that I haven’t forgotten it, although some of it is pretty rusty. Perl’s use of different variable sigils ($, @ and % to denote different variable types) was welcomed back like group of old friends of whom you have fond memories, but sometimes confuse their names. If you know what I mean.

But it’s all coming back to me, and the various Perl colloquialisms are springing to my fingers.

I think that my years in PHP have benefited me, but I’m not very clear just yet in what way. The ability to jump back and forth between languages can make you perpetually confused, or it can make you stronger in both, depending on your approach. One hopes that you can learn something from the one to take back to the other, but that doesn’t always work out.

I am reminded on a regular basis, by support email, that I have a bunch of modules on CPAN which have largely languished while I’ve been in PHP-land. Of course, many of them have been superseded by better modules while I’ve been away. The Date ones, in particular, have almost all been superseded by the Perl Datetime project, which, although I helped start, Dave Rolsky has been heading for several years now. Maybe, if I’m lucky, I’ll have an opportunity to resurrect some of those modules and start playing with them again. Non-gregorian calendars, and traditions about different dates have long held a fascination for me, and I’d like to play with that again.

But, meanwhile, I’m learning the slang again, and since I’ve missed a half-dozen releases of Perl, I’m sure that it does even more weird and wonderful things than I did when I was a common face around the Perl circles.

Unit testing: A good habit, lost

When I was a Perl programmer, I was a strong believer in testing. I wrote tests before I wrote functions. I wrote tests before I fixed bugs. I ran the test suite every time before I committed changes to svn. I ran tests after I ran svn update.

When I became a PHP programmer, I quickly slipped out of the habit. There were two reasons for this.

First, my style of programming changed pretty drastically, with the move to being completely web-centric, and web front-end code is just harder to test.

Two, at that time, the available tools for unit testing were immature. Or, at least, so I believed, coming from the Perl world where testing is not considered optional, and is integrated into every aspect of the process, from design all the way up to ridiculing stuff that’s submitted to CPAN without adequate tests.

Now that I’ve been doing PHP programming for going on 5 years, I desperately want to get back into a testing mindset, but find that there’s an awful lot of inertia around not testing. If your code doesn’t have a test suite, it’s difficult to make that first leap to build one. And it’s also hard to convince management that it’s worthwhile spending time making a test suite when you’re behind deadlines.

And, since there’s not One True Way in PHP, like there is in Perl, you waste a lot of time and energy trying to find the right testing methodology. The PHP community could do themselves, and the rest of the world, a great service, by agreeing on one testing methodology, and then evangelizing it. Here’s another case where the quest for the best has woefully injured everyone, and led to a situation where people simply don’t test.

Now, I’m sure that the core PHP folks will disagree with me. Actually, I kind of hope that they will. Please disagree with me? Tell me that there is One True Way, and also that you do run the test suite every time you change a line of code. I greatly regret getting out of that habit.

Review: PHP Programming with PEAR (Packt)

Packt recently sent me a copy of the book “PHP Programming with PEAR” to review. I rather wish they hadn’t, because it faces me with the dilemma of having to post a really negative review of a book, and potentially hurt the sales. On the other hand, it’s my obligation to tell you, the PHP programmer, that this book should be avoided at all costs.

Unfortunately, it probably also means that Packt will stop sending me free books to review. But I gotta do what I gotta do.

1) The book is about PEAR. However, nowhere does it tell me what PEAR is, other than a short paragraph in the preface, which nobody will read. Much more importantly, there’s nothing whatever in the book that tells me how to locate, download, and INSTALL a Pear module. So when it jumps right into a chapter on one of the more obscure of the Pear modules, almost without telling me what it is, what it’s for, or why I would consider using it in preference to PDO, I’m completely at sea. Where do I obtain this module? How would I install it once I had obtained it?

If you type ‘pear help’ at the command line, you get more information than is contained in this entire book about the pear command line utility. It isn’t once mentioned, as far as I could tell.

Chapter 1 is missing, entirely. Chapter 1 should be “What is PEAR?” Chapter 2 should be “Using the pear command line utility” Those two chapters would be what most buyers of your book would actually be looking for. Without those chapters, the current book is an exercise in frustration. Yes, this stuff looks cool, but where the heck do I find Pear::DateTime? It’s not installed on my server.

I see that Packt has a separate book called The PEAR Installer. Presumably that book answers these questions. The problem is that if I go to the store to buy a book about PEAR, I’m going to buy one or the other, not both. A chapter on the pear command line utility is essential for this book.

2) The code examples are almost always there without showing the output. In the few cases where the output is shown, it’s almost always difficult to ascertain which code example led to it. The worst example of this I found was in the calendar chapter, where an example is shown of a HTML table rendering of a month calendar, complete with a description of what color the various dates were. I was unable to find the code that generated this output. Since this is one of the things that I’d actually like to do today at work, I find that very frustrating. This was the rule, rather than the exception.

I have found, in years of writing and presenting at conferences, that examples carry 100 times more weight than pages of exposition. Showing a line of code, and the output that it produces, communicates more than discussing the function and its uses. This book shows a lot of functions, and very seldom really shows what they do.

3) The book assumes that you already know what OO syntax looks like, and almost never shows it to you. One reason that PEAR developed was that with the transition of PHP from 4 to 5, nobody knew about OO syntax, or how to build objects, and PEAR was a way to provide these object models to people to get them started. Showing them how to use PHP objects is critical to success. CPAN did this really well with Perl, and PEAR has done it less well with PHP. I’m not real sure why so few PHP programmers know about or use the stuff on PEAR, while Perl programmers universally use CPAN. This book, and others like it, are an opportunity to tell people about the great stuff on PEAR. Reusable code is a really big deal, and PEAR is, and should be, the place for that code to live. Unfortunately, this book doesn’t communicate that.

4) The selection of modules to cover was, to be charitable, random. There are (as of today) 534 packages on PEAR. (See http://pear.php.net/packages.php for details.) This book chooses, at random, 5 of them, and covers them in a rather haphazard manner. Now, I don’t claim that I know which modules should have been covered. But I can assure you that if I wrote this book, I would do some research into which ones were most popular, and which ones seemed neglected, but amazingly useful, and which ones nobody uses because they’re not useful.

5) This book completely overlooks what I consider to be almost the most important topic, after “what is PEAR” and “How do I install a module”. Specifically, “How do I write a PEAR module?” And the related question of, once I’ve written a really useful module, and I’d like to share it with the world, how do I go about contributing this to PEAR. CPAN has done a wonderful job of answering that question, and, as a consequence, I have something like a dozen modules on CPAN that are used by thousands of people. I don’t know how to contribute my code to PEAR, and have some that I’d like to contribute. I was hoping that this book would answer this question.

6) I’m a huge calendar geek. I was looking forward to the calendaring chapter, because I figured it would give me the same charge that the calendaring stuff in Perl does. Calendars are a lot of fun, and PHP has put a LOT of effort into datetime code in the last few versions. A lot of brilliant people have devoted hundreds and hundreds of hours to making the datetime implementation respectable.

The calendar chapter was a huge disappointment. It focused largely around a code example to generate a HTML table rendering of a calendar, although early in the chapter it hinted at the fact that you can do this with a single function call in the Tabular class. But it didn’t tell me what that function is, which just pissed me off for the rest of the chapter. And since I was at the pool when I was reading it, I couldn’t look anything up, or try any code examples.

So ….

all of that to say, I think that this book is significantly below the standard that I have come to expect from Packt books. I was very, very disappointed. I think that this book is really important – that is, a book in this space – and it’s frustrating that it wasn’t done well. It felt like someone’s first writing experience. We’ve all been there. My first book was an embarrassment, and I’m glad that it’s out of print. I hope that these gentlemen progress in their career enough to feel the same way about this one. I felt a number of times that I could have written the book better.

50% of writing a book like this is research. Another 25% is experimentation – writing code with the stuff learned from the research, getting a feel of how it actually works, and coming up with interesting examples. A poorly written book on a topic like this is just a rehash of the documentation. However, I don’t think that this even goes that far.

CakePHP Application Development

CakePHP.jpg

As I’ve mentioned before, we’re using CakePHP for our development at work. Cake was the first formal MVC framework that I’d worked with, although at Asbury we had developed an MVC framework in house, almost unbeknownst to us. That is to say, we developed a sane web app framework, and weren’t aware that someone had already given a name to the pattern. Shame on us for not doing our research a little better.

Also, the other half of the web team had started working with RoR before I left, but I didn’t really look at it seriously.

CakePHP is one of many PHP MVC frameworks, and, naturally, there are a variety of opinions as to which one is the best. I can’t claim to have done a careful comparison. How did I choose Cake? I like to hire people smarter than myself, and trust their judgement. This was the recommendation that came up from that team of smarter people. And I certainly have to admit that Cake really works with the way I think, and is very much the effect that we were trying to achieve with our framework at Asbury. We didn’t quite get there, but we were headed very much in the right direction.

The CakePHP book from Packt Publishing was very helpful as an overview of what was possible. It has practical examples of what can be done, and has careful explanation of each step. In conjunction with the amazing online documentation, it provides a solid footing for jumping right in to writing Cake apps the first week.

One place the online docs are sorely lacking is the V part of MVC. The online docs are for programmers, not for designers – or perhaps “written by” is the better thing to say there. Either way, the section about views and layouts is still rather weak, although it’s being worked on. The Packt book is a good supplement to this, although it makes more sense on second reading, after a little hands-on experience with the Views stuff.

In short, recommended. 4-out-of-5-stars. Anupom and Ahsanul have done a good job of giving an introduction to Cake app dev in this book, and I’d recommend this as a desk-side reference as you start developing in Cake.

As to the other frameworks – yes, I’ve heard that there’s others that are better. One thing that is obvious, looking at the various frameworks, is that all of them are crazy active – they are all improving by leaps and bounds, and pretty much every feature comparison I’ve looked at is way out of date, and inundated by comments saying “yeah, that’s how it was 6 weeks ago, but you should take a look now!” So I’m pretty sure that the jury is still out on this, and that there will be still several years to watch these things before one emerges as a clear leader – if, indeed, that ever happens. It hasn’t in any other language (with the exception of Ruby) so I don’t know why we’d expect it with PHP.

Come work for me

I’m looking for a PHP programmer looking for an challenging position in the Lexington area. Our code uses the Cake PHP framework, and we’ve got several projects with a certain amount of shared code between them. Our biggest projects are ClearMyRecord.com and Hard2Hire.com, both of which are about helping people get their lives back together in one way or another.

I’ve got job postings on Monster.com, but I’ve found that finding people by word of mouth and personal contacts is way more effective than any of the job boards, both in finding the people with the skills and finding people who are likely to be a good fit for the team.

Ideally, we’re looking for someone with some OO PHP experience, and some knowledge of, or experience with, MVC methodologies. If you’ve used Cake, that’s great, but it’s certainly not required. And if you have MVC experience in some other language, like Ruby on Rails, or Catalyst, that actually translates pretty easily into what we’re doing, particularly if you’re interested in learning new things, and can convince me that you’re the right person for the job.

If you’re interested, or know someone who is, or want more information about the position, please contact me.

Tidy and PHP

I saw Yoav’s blog entry on Tidy and for a brief moment, in the first paragraph, thought that there was actually a phptidy utility. Alas, it was not to be.

Perl has had perltidy for some time, and, as I understand, it’s a pretty hard thing to do. But I keep hoping that someone will do the same thing for PHP.

Meanwhile, fortunately, php syntax is enough like perl that I can use perltidy to reformat php code about half the time (I have a vim macro that runs perltidy on the selected block of text) – the other half, it complains about syntax errors and screws things up pretty well.

Cake

After many years of saying “I really should take a look at CakePHP”, I’m finally doing something useful in it. And it’s marvelous.

What’s fascinating to me about shiny new technology like this (new to me, that is) is that I’m almost always reluctant to get started, and I’m almost always thrust into it by a co-worker who says that it’s the way to go, and starts doing stuff in it. This was the case with Apache, Perl, mod_perl, POE, PHP, AJAX, and now Cake.

Also, as usual, I am incapable of learning anything in it until I’m doing an actual useful project in it. I can’t just work through the tutorial, or make up a project. It has to be something that’s important to me, and is at least a little interesting.

And, as usual, my reaction here is, why the heck didn’t I jump into this years ago. Can you imagine the time and pain it would have saved me?

For those of you who don’t know, CakePHP is an MVC framework. Which is to say, it’s just like Ruby on Rails, or Catalyst, or any of a dozen other frameworks out there.

And for those of you who aren’t geeks, when we say “framework” it means “someone else did the boring work for me so that I can focus on the interesting part of the project.”

As it turns out, with most web applications, 90% of the work is doing the stuff that you’ve already done before on every other web application that you’ve ever written. Database connections, getting data, creating data, updating data, deleting data, asking the user if they’re sure they want to delete the data, etc, etc, etc. Very boring. Cake (and other frameworks) do that stuff for you, so that you can focus on the actual business logic of the application – that is, the things that make this web app different from the last 28 that you’ve already written.

Using the Plug n Pay API from PHP

We use Plug n Pay at $work to conduct our financial transactions. It’s a great service, but the example code that they provide for PHP and Perl developers leaves something to be desired.

I spoke with a tech support guy there, and, while he was helpful, and clearly very knowledgeable, I found that we differed significantly on a particular point of philosophy. He seemed to be somewhat perplexed as to why I would want a full OO interface to their API, because, as he said, any PHP programmer worth their salt can take the API documentation and write code that sends arguments via Curl, or PHP sockets, or whatever, and get useful results from it.

To this end, they offer one PHP file, containing a partial implementation of one of the API methods, as an example of how one might do this. The example manually builds a query string, rather than using http_build_query, and manually splits the return value, rather than using parse_str – not crimes in themselves, but it seems that ecommerce code should be held to higher standards than this.

While I don’t disagree that a good programmer could indeed do this, I disagree that any would *want* to. Good code is reusable code. Having thousands of programmers writing exactly the same code, and having many of them, no doubt, doing it really badly and insecurely, is not in the best interests of anyone – the programmers themselves, the companies they work for, or even Plug n Pay (or any other financial vendor). They are wasting thousands of hours, and they are very probably writing code that is insecure, confusing, poorly documented, and, in many cases, just plain wrong.

Having a complete API implementation, and providing that to customers, is a service to everyone. It saves my time as a programmer, it saves time and resources on tech support, and it results in more secure code that is guaranteed to do the right thing every time.

Now, the folks at PnP offered to audit my code and possibly offer it for download on their site, given certain licensing requirements, and I may take them up on that. I haven’t decided yet. But, to be honest, I find their attitude about the whole thing to be quite at odds with my view of how software development should work. Encouraging every individual programmer to find their own way is not the way to improve the overall security stance of ecommerce websites. In fact, I would say that the huge daily number of compromised ecommerce websites is a direct result of this stance.

So, anyways, to this end, I offer my starter implementation of a full PHP API for PnP. So far, it’s incomplete, but exposes the most frequently used methods, and does it in such a way that it’s pretty difficult to get it wrong. Of course, you need a PlugNPay account to use this, but one hopes that if you found this article by a Google search, this is the solution you’re looking for.

Now, it’s possible that I’m the only person that cares about this kind of thing, but if you’re interested in receiving updates of this code, or possibly in participating in the ongoing development of this code, please let me know, and we’ll work something out. Collaborative development of reusable code seems like the only sane way to implement a financial transaction codebase.