I have a thing for charts. Charts have the ability to convey very complex scenarios in a single line, or a few lines, if there are multiple considerations to be made. But the reason I have an interest in charts is not because of the information they convey, but the information that they don’t convey. I find that the information that is left out of a chart is often the most important piece. This is because statistics can be made to say pretty much anything. You’ve probably heard the line “Lines, Damn Lies and Statistics”. When I start hearing things like “60% of people think X” or “20% of people think Y” I tend to switch off. Interestingly enough, I do the same thing, though. Probably because that’s the easiest way to make a point. It sounds scientific. It sounds like you’ve done your research, even if you really haven’t.
I was doing some talking with some gentlemen last night over several adult beverages and fine tobacco products. They worked for a partner of ours and had brought up an interesting point concerning Zend Framework. It seems as though people who ask them about their product set and how it fits in with PHP were asking about Zend Framework and whether or not you had to use the whole framework to be able to integrate with their software.
Code Assist is one of those “must have” features in any IDE. Some developers are so brilliant and have such good memories that they are able to know what parts of their application do what and those silly drop down boxes just get in their way. I am not one of those developers. I love Code Assist. In fact, I learned Java via code completion in JBuilder 8. It was horrible Java code, but it worked. And eventually I learned how to write good Java… using code completion as well.
In our previous installment we looked at setting our backend up so it could automatically retrieve the bit.ly URL for a given URL and store it as part of the data for a given instance of a Content model. What we’re going to do this time is take a look at the front end components.
Sometimes I find that doing things backwards can actually make things a little more clear. That way you can see the end result and then, as you work backwards, see how all the pieces work together.
Matthew wrote up an article on modules in Zend_Application and that got me thinking a little bit. When I have done training for Zend Framework, one of the things that mystifies students to some extent is the whole plugin architecture and where things can go. There has been several articles written about it, but they tend to use code to describe it. I was only able to find a small handfull of articles that used some kind of chart to describe what goes on. Not that that’s a problem, but I had found that when I drew out the request lifecycle that it helped the students understand it better.
In a perfect world software works all the time…
So, you can stop laughing now. But if something gets really messed up there are a couple of options that you have to make it work again.
Often, one of the reasons for a hung instance of Zend Studio is a broken workspace. Zend Studio, and Eclipse, cache a LOT of information and the IDE is highly dependent on that information. Sometimes that information gets royally mangled. If the workspace is salvagable, and it usually is, the easiest way to fix the problem is to have Studio clean its cache.
Over here there is a good article on sharing page feedback on Twitter. I’ll end up doing something similar but in a different manner. A little while I posted an article (Do you queue?) on how you could use the Zend Server Job Queue to run individual tasks. Well you can do the same thing here. I’ve made a few changes since that article, namely that Zend_Application is passed in both to execute() and to run() so I could easily retrieve application settings. Don’t know why I didn’t think of that earlier. Oh well.
So you’re now in charge of some kind of event and people are going to need tickets to get in. You could do it the old fashion way and actually have people at the door checking the tickets, but that is so 1980’s and also so easy to forge (for the nefarious). Event organizers are adament that tickets are only used once and so they want to use some kind of barcode reader to ensure that tickets are valid and you are responsible for the web side of this.