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.
Well another week, another set of changes. There are 4 primary changes that I’ve made to the site since last week. They are, in no particular order
The addition of comments.
A Twitter-based rating widget
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.
Writing music is hard. I love doing it but I have yet to write a piece where I did not have significant writer’s block. What I often do is wakeup early and spend an hour or so working on a piece before starting work. I have been writing and playing music for a few years and it is still hard each time. It really is 10% inspiration, 90% perspiration. Enough so that I stopped and wrote a blog entry about it.
There has been a lot of talk over the past several years about the difference between performance and scalability. Never mind that the difference between the two will probably not really affect most developers. Never mind that the “difference between performance and scalability” argument is often used when someone’s code performs poorly and their best argument is “Yeah, but my code scales”. Yeah, sure it does.
I deployed this blog about a week ago. Since then there has been little traffic, mostly because I have not promoted it and I have also been working on a bunch of other content and such. Since I also just needed to just get it out the door and running I have not spent a lot of time testing for performance. This blogging app is based off of Zend_Application and as such there is a bit of overhead. Since I was not expecting traffic to be that heavy I was not (and am not) overly concerned about snappy performance at this point. As long as the page loads and displays in the browser I’m fine with it.
If you are reading that title and thinking “what is that guy smoking?” then you are probably in good company. Developers often make development decisions based off of philosophy. Some developers go the route of “we will decide on the best tool (language) for this individual job” and end up having hundreds of individual tools that they need to end up supporting. Others desire to take a more puritanical approach in saying that “we will only use this one tool (language) for this individual job.” The problem is that the decision is often not as cut and dry as many development philosophies allow.
So there’s been a little bit of interest in the music I wrote for Zendcon in ’09. Some people liked it, some didn’t. I remember reading some of the Twitter posts on the wall and feeling a little nervous. The sound guys played it more up-front than I was expecting. I had no idea that they were going to turn it up the way they did. It wasn’t that loud (according to Kevin’s reckoning ) but I was expecting it to be background music. So the fact that I wasn’t chased out of there with pitchforks made me glad.