Archive | November, 2004

Text pumping

Posted on 22 November 2004 by Demian Turner

If you haven’t picked up on this article yet from John Lim then head on over and read it – some interesting things in store for PHP.

Comments (0)

Yellow Duck Framework

Posted on 19 November 2004 by Demian Turner

The Yellow Duck Framework is an object oriented framework that will help you with creating web applications.

The Yellow Duck Framework supports the following items:

  • Clean separation of code and output
  • Templates for outputting HTML easily
  • Automatic action dispatching using URL parameters
  • Object oriented form construction and validation
  • Object oriented handling of authentication
  • Classes for creating “XML/RPC” clients and servers.
  • Classes for creating syndicated XML feeds such as RSS and Atom feeds.
  • Easy handling of files, directories and images. For images, there are some very straightforward functions that can create thumbnails of those images.
  • An object oriented interface for creating and sending email messages.

The Yellow Duck Framework tries to be as flexible as possible so that you can
tailor it in such a way that it works according to the way you want it to work.
It’s definitely not the framework that will solve all your needs, but for most
web application related functions, you will find the Yellow Duck Framework a
very handig tool to get your work done faster and more reliably.

More information:

Comments (1)

PHP 5, Oracle, SQL Relay and the Future

Posted on 16 November 2004 by Demian Turner

Andi Gutmans, one of the original PHP creators, has an interesting article on the Oracle site talking about PHP5 and the future of the language.

Mentioned towards the end of the article is the SQL Relay project, which implements a proxy broker for SQL connections
(including Oracle), allowing for connection pooling of database
connections using PHP.

Comments (0)

Seagull 0.3.11 Released

Posted on 10 November 2004 by Demian Turner

This release of Seagull is the last in the 0.3 series, with a generous round of bug-fixing and a last-minute patch, you should find it quite stable to use.

The majority of work done focused on stabilising and improving existing functionality, however a few new features were added, these include:

  • master templates: much easier to design your screens choosing from one of the multiple or no-column layouts
  • publisher went through a cleanup, the main improvement being the removal of the dependency on frames
  • substantial steps forward taken with XHTML cleanup and CSS improvements
  • first unit tests added

Quite a bit of work was done behind the scenes for changes that will be more obvious in the 0.4. series, these include

  • full implementation of a front controller, so ‘start files’ are no longer needed, and URLs can dynamically be reformatted, improving search engine/REST integration
  • enhancements in the User module including perm/role synching, and a user search feature

The full list of changes can be viewed in the changelog. As with the last release, the recommended method of install is to use the PEAR web installer, however a tarball of all the files needed is also available.

Thanks as always go to all the Seagull developers – we’ve dipped into the SF top 50 this month. You can checkout the Seagull presentation given at a recent PhpLondon meeting and come and see us in Poland for the upcoming PHP conference happening there.

Comments (0)

Batch Analysis of Html in a Unix Environment with SAPID

Posted on 09 November 2004 by Demian Turner

Thanks to Riccardo for this article, I’ve reproduced it below but there are some formatting probs which can be avoided by visiting this link.

Riccardo Magliocchetti, riccardo –at– datahost –dot– it
v. 1.0.1

Getting into a software project code that has been developed by various people over years isn’t an easy task since it tends to dishomogeneity. Some factors need to be taken into consideration: people’s programming habits and level of knowledge, and the passage of time, which improves and refines technology.

This is true in international and long term projects which, thanks to free /
open source software, are now quite common. The process fortunately can be controlled by adhering to strict coding style guidelines and W3 [1] standards.

But with projects that are often done in contributors’ free time and that consist of hundreds of thousands of lines of code, can often be difficult to apply these rules.

Comments (0)

TinyButStrong 2.0 : serious template engine in pocket-size

Posted on 08 November 2004 by Demian Turner

TinyButStrong is a Template Engine that aims to be simple, useful, light and easy to install. It’s a single file with a class having 8 methods and 3 properties.

The peculiarities of TinyButStrong with regard to the other template engines are:
– not programming in the Html template,
– visible tag in any visual (wysiwyg) Html editor,
– supports MySQL, PostgreSQL and SQLite in native.

Version 2.0 bring many new features. There are also some changes from versions 1.x, but it stays simple and light to use.
New features are described at the web site on the Support page.

-> Web site
-> Examples
-> Forum

Comments (0)

How to Use JMS with PHP

Posted on 04 November 2004 by Demian Turner

Haven’t heard anyone mention this recent article from O’Reilly, quite a good read:

JMS (Java Messaging Service) is an interface implemented by most
J2EE containers in order to provide point-to-point queuing and
topic-based (publish/subscribe) functionality. JMS is frequently used
by enterprise and back-end applications for distributed communication
and collaboration. PHP is a powerful scripting language popular for use
with Apache’s CGI facility. Although efforts are being made to develop
PHP as a back-end scripting language, its use is still very much
confined to front-end applications. Combining the strengths of
PHP–easy and fast web development, and compatibility with many types
of databases–with those of JMS, which is the standard for
communication with back-end enterprise applications, creates a powerful
and easy-to-use tool for both Java and PHP developers.

PHPMQ gives the PHP developer JMS-like abilities through the MantaRay messaging bus. This document gives an overview of PHPMQ and its use by the PHP developer.

Comments (0)


PGP Encrypting data

Posted on 03 November 2004 by Demian Turner

It’s been a tough morning. I’ve had numerous cups of coffee and hit my head against numerous walls trying to find out why I couldn’t get PHP to run PGP and encrypt some data. I’ve been developing in Apache and PHP for years, but recently my new job has required me to work under IIS Windows systems more and more. This is where I ran into problems, especially with PGP telling me that it couldn’t find key files even though they were blatantly in the right place. I hope this helps someone!

How to use PGP with PHP

Comments (0)

Beard-Certified Gurus

Posted on 01 November 2004 by Demian Turner

Thanks to the Braidy Tester via John Lim for this great list of what makes a great programmer.

Plans before coding

A great developer takes the time to plan an approach before
designing or coding. A great developer knows that the time required to
do so will be more than paid back by the time saved by getting it more
right the first time. A great developer plans all scales of work, from
envisioning multiple versions of a product to writing or modifying a
small method.

Always knows why

A great developer always knows exactly why they wrote a particular
line of code, and why they wrote it the way they did. A great
developer writes code because that code is the best choice for a
particular situation, not just because it is the canonical
implementation. A great developer codes consciously.

Writes situation-appropriate code

Any developer can write code. A good developer writes solid code.
A very good developer writes elegant code. A great developer writes
code that is both solid (compact, well constructed) and elegant
(precise, simple, graceful, polished). More importantly, a great
developer can tell when elegance is not worth the effort.

Deviates where and when necessary

A great developer not only knows the canonical implementation but
understands it is the canonical implementation. A great developer can
tell when the canonical implementation is not the best answer for a
particular problem.

Knows when not to change code

A great developer knows that changing code is sometimes worse than
fixing it. Fixing a bug may cause too much instability elsewhere in
the product, for example. Messy code whose function is not well
understood shouldn’t be rewritten until there is sufficient time to
ensure its function is well understood. A great developer understands
the tradeoffs involved between changing code versus leaving it as is.

Approaches debugging scientifically

A great developer knows that debugging is a science not an art and
approaches it as such. A great developer formulates a theory as to the
cause of the problem, determines a method for proving the theory wrong,
performs the experiment, and observes the result. A great developer
records this information and uses this data to guide further work.

Walks through their code

A great developer knows that they don’t really know their code until
they’ve stepped through it. A great developer sets breakpoints on
every line of code as it’s written so they know which lines haven’t
been hit.

Knows the language and platform intimately

A great developer knows the programming language (and platform) in
use inside and out. A great developer knows why each construct (API)
was included in the language (platform) and why other constructs (APIs)
were left out. A great developer disagrees with certain aspects of the
language (platform) but understands why those aspects work the way they
do. A great developer knows what the language (platform) can do, what
it can’t, and how to achieve the same effect through other means.

Groks the tools

A great developer knows what the available tools are and how to use
each of them. A great developer knows that not every tool is
appropriate for any particular task. A great developer knows how to
abuse the tools to produce results hard or impossible to accomplish via
“approved” uses.

Improves the tools

A great developer knows that their tools can always be improved. A
great developer prefers to get these improvements from elsewhere so
they can concentrate on solving the customer’s problem. A great
developer recognizes when it is simply faster or more efficient to
write a tool themselves. A great developer constantly looks for
opportunities for increasing their productivity.

Knows when to ask for help

A great developer takes pleasure in a challenge. A great developer,
then, enjoys banging up against a brick wall and slowly breaking
through it. Some walls are thicker than others, however, and sometimes
the wall has a developer-size hole that the developer continually
manages to miss. A great developer realizes when it’s time to ask for
help and does so. A great developer knows who to ask for help. A
great developer knows there isn’t any shame in asking for help.

Always has a side project going

A great developer is never completely satisfied by the current
project. A great developer is always also working on a (probably many)
side project meant to investigate an idea, understand a language or
library feature, automate a process, or otherwise itch a scratch the
primary project isn’t satisfying.

Doesn’t make assumptions

A great developer actually does make assumptions, but a great
developer doesn’t stop there. A great developer inspects the
assumption, then researches that assumption into knowledge. A great
developer does this not just for their own assumptions but for
assumptions other people make as well.


A great developer documents everything. A great developer strives
for self-documenting code but knows that some amount of documentation
is always required. A great developer knows that documentation need
satisfy only two goals: educate the current audience, and preserve
enough knowledge about the topic that the current audience can expand
the documentation as necessary for any future audience.

Follows coding standards

A great developer has internalized and continuously uses a set of
coding standards. A great developer may not be able to recite the
standards word for word, but when asked about any particular point the
correct answer is immediately forthcoming. A great developer writes
conformant code without the aid of verification tools, but always runs
those tools as a backstop.

Uses version control

A great developer knows that version control is as important for
personal projects as for enterprise projects. A great developer
version controls everything.

Makes lots of small checkins

A great developer knows that version control is most useful when
code is modified via small checkins that each contain a single logical
change. A great developer strives to check each change in
independently from each other change.

Tests their own code

A great developer is embarrassed when someone else finds a bug in
their code. A great developer thoroughly tests their code before
checking it in. A great developer doesn’t pretend to be a great tester
but does strive to be considered a good tester.

Has passion for their customer

A great developer understands what the customer needs to do and how
the customer wants to use the product. A great developer looks beyond
the customer’s needs to see how the product can revolutionize the
customer’s tasks. A great developer promotes the customer’s point of
view throughout the product cycle, from the first nascent product
vision through specifying and implementing features to cutting features
and triaging bugs to product release and ongoing maintenance. A great
developer helps the rest of the product team understand the customer as
well as they do.

Has great judgement

A great developer understands the business case for the code he is
writing. A great developer uses this as a basis for judging what code
to write and what code should not be written. A great developer uses
this as a basis for deciding when to write code and when writing code
is not the right thing to do. A great developer uses this to balance
designing for the future against the need to get something done in a
timely manner.

Has no ego

A great developer values the praise of their customer over the
praise of their peers. A great developer wants to do the right thing
but doesn’t much care about being right. A great developer brings
their reasoned opinion to design and coding discussions but listens
carefully when alternatives are offered, searching out and examining
the details of these other options. A great developer appreciates
suggestions for improving their code or design. A great developer
knows they will write bugs and appreciates it when bugs are brought to
their attention. A great developer follows a process because the
process protects them from themselves.

Makes time for training

A great developer knows that the only way to continue to be a great
developer is to never stop learning. A great developer doesn’t limit
this education to programming-related topics, either, but also
researches testing, program management, marketing, and anything else
that is remotely related to the process of creating software.

Comments (0)



Demian Turner's currently-reading book recommendations, reviews, favorite quotes, book clubs, book trivia, book lists