, , , , and

Ed Finkler recently published a "manifesto" concerning the need for lightweight PHP development libraries for small projects not needing the full weight of MVC frameworks that are so prevalent these days. These ideas and suggested libraries for use are now listed at MicroPHP.org. I agree with these sentiments for the most part, but I do have one concern that I've been unable to allay: There are no routers I can find that ascribe to the PSR-0 autoloader standard.

Basically, PSR-0 explains how PHP libraries can use namespaces and directory structures to ensure some means of compatibility. For example, if a library is in the namespace \fry\core\database then the SPL autoloader can expect to find it in a specific directory within the project structure. (More detailed explanation.) The problem is that most of the recommended libraries don't even use namespaces, much less adhere to the PSR-0 recommendations.

This is a problem because each of the router libraries has its own way of defining where things should be, or worse, none at all. Some of the smaller routers, like klien.php, contain the whole of their workings in a single file, rather than spreading the classes out into individual files like PSR-0 suggests. This itself isn't a problem at first, because you can include a separate autoloader yourself, but it does present some issues when you try to use those other libraries.

I suppose the recommendation of MicroPHP advocates is to simply include what you need when you need it. I guess that's fair. But I expect that any project that results from the binding together of small libraries will be an interesting puzzle to sort out, and adding endless includes to the top of the index.php that starts the project doesn't necessarily seem like the best way to handle dependencies.

As a result, I'm looking for a good router that includes an SPL Autoloader. I'd started re-writing microsite for this purpose, although I had done this prior to the MicroPHP manifesto, and there are some changes I'd like to make to improve my tiny framework's micro-ness. But microsite does include an autoloader and assumes a PSR-0 directory structure, which I feel is simpler than explicitly including all of the libraries.

If the intent is to make it easier to code small things faster, then I believe that a router implementation that supports autoloading of classes is the fastest means to implementation. Hopefully, more of these smaller libraries begin to include namespaces and support the PSR-0 directory structure.

, , , and

You know that permission page, with all the checkboxes? Wouldn't it be nice if you could drag a bounding box around a bunch of those checkboxes to toggle all of the selected checkboxes? Well, since you asked so nicely...
I created a script, dps.js, and a bookmarklet that will do just that!
Step 1: Drag this link to your bookmarks toolbar to create a bookmarklet:
Drupal Permissions Script
Step 2: Visit your Drupal permissions page.
Step 3: Click the bookmarklet that you created. Nothing will seem to happen.
Step 4: Then do this:

Unable to display content. Adobe Flash is required.

Another side-effect of this bookmarklet is that the column areas that surround the checkboxes become hit-targets for the checkboxes they're near. So you can miss the stupid tiny things slightly and still toggle the box.
Here's the official repo, to which you are welcome to submit patches: https://github.com/ringmaster/serverscripts
Enjoy!

, , , and

I have a few resources on this site that are ripe for abuse. Particularly the Pingback and Trackback testing tool, Pingomation, which allows blog admins to test whether their blogs are correctly sending and receiving pingbacks and trackbacks without having to set up a separate blog themselves. (Actually, as of this writing, there is a glitch that is preventing this tool from working properly. Hopefully I'll be able to resolve that soon.)

My server became overloaded with requests this morning, so I needed a way to determine who the offenders were and quickly shut them down. The first thing I did was look through the Apache log for any suspicious activity:

tail -n50 /var/log/apache2/access.log

This command revealed a surprising number of attempts to use my Pingomation tool from various servers, as if they thought my site was some kind of announcement system. This needed to be curtailed. So I looked for the IP addresses of the most active offenders:

awk '/Pingomation/ {print $2}' /var/log/apache2/access.log | sort | uniq -c | sort -n

This command line does a bunch of stuff. The awk command grabs any log line with the word "Pingomation" in it (which would be any hit to that page on the site) and outputs the second (as indicated by the $2) column of the data, which is the IP address. These addresses are then sorted and passed to uniq -c which reduces multiple duplicate lines (this is why it must be sorted first) into a sing line with a count in the front. I then sort the results again numerically to see who has abused the site most.

At the end of the list were a few IP addresses that have hit that URL more than 200 times, one even hit it in excess of 700 times. This is just from today's log! This must be stopped. I fed each of these IP addresses into an iptables command to block access from that IP entirely, so that the request is stopped before it even bothers Apache:

iptables -I INPUT -s 80.243.189.146 -j DROP

This simply tells iptables to drop any traffic originating from the IP address 80.243.189.146, which is the most offensive host.

I was careful to filter the IP addresses for those used by Google and other search engines for spidering (there weren't any), since denying access to those addresses would ultimately remove my site from their search indexes.

, , , and

I've been intrigued by the LESS and SASS CSS libraries, which provide some additional features to the way CSS can work that feel more intuitive. After reading through the documentation, I've been particularly pleased with the LESS library, because of its ability to be parsed and processed in real time by a javascript libarary. Obviously, you wouldn't use this javascript in production, but it makes development easier, since you don't need to compile the CSS after each change, and the tools that do compilation generally tend to be in languages that are a pain to install on my platform.

Today I embarked on a project, intent on incorporating LESS as the CSS pre-compile library into the output of a Habari-based blog template. What I wanted to do was use Twitter's bootstrap.less to give me a jumpstart on basic layout and design, then add my own styles to the mix to give the output some flavor. This seems pretty straight-forward, but I ran into a problem that might require a little more explanation to even understand where I'm coming from.

My blog template is written entirely in HTML5. And when I say "HTML5", I'm not talking about a few tags here or there. This template was constructed with the express purpose of pushing HTML5 to its limit in terms of blog output, and setting a gold standard for how to use HTML5 to produce blog output. In other words, it's not just about throwing a few extra

tags around, but actually thinking about their placement and making sure the use of the HTML5 semantic tags jives with the spirit of the HTML5 spec. I've been referring to a few sites as reference, but one of the major ones that has been useful is this page by Edward O'Connor, which has outlined many of the hard bits already.

The trick is that my output document in HTML5 is now ridiculously well-formed. There are named tags in places that make sense, and there are very, very few <div> tags in the output. You might expect this to be great for HTML, but not so good for CSS. In actuality, it was necessary to add only one additional div to the output to conform to the layout that the grid in bootstrap requires. That's pretty neat.

But then I started to think about what I would need to do to apply bootstrap to my template. Basically, it would require me to add all sorts of classes to my semantic tags, and this bothered me. For example, I have a section with an id of "posts" that contains the main blog content, and an aside with an id of "sidebar" that contains the sidebar. If these things already have tags and id's that represent them well, why would I want to add classes to them to define how they should look presentationally? Should I not be able to address those elements directly?

This leads to what I think is an interesting - and for me and Habari, age-old - discussion about the efficacy of CSS frameworks. Frameworks are great if you want to quickly apply a framework's layout to your existing design. They provide a great foundation in which you can see your site become pretty quickly. But ideally, custom CSS is a better way to go. If I never use the "span8" class, why would I include it in my CSS? And the class names are certainly of no use to my markup. Moreover, if I want to re-style a template by swapping out CSS, embedding the widths of the columns into the markup (with the "spanX" classes") would prevent me from easily making layout changes.

What I wanted to do with LESS, or what seemed possible, was to use mixins. After all, if I can say that an element with the id of "posts" includes all of the properties of the class "span11", then I've basically succeeded at using the framework effectively for rapid layout, and keeping my markup semantic. Right?

Well, that doesn't work. Why? There are a couple of reasons but primarily, the mixins add the referenced rules into the new selector, but they do not alter other uses of the referenced rule to be influenced by the new selector. This is probably best explained with an example.

If I have this LESS code:

.foo { color: red; } .foo .bar { text-align: left; } #posts { .foo; }

You might expect there to be a new rule in the processed CSS output like this:

#posts { color: red; }

There is! Which is great. But what I was also hoping for was this:

#posts .bar { text-align: left; }

And of course, it doesn't make any sense to expect this, because I didn't write a rule that explicitly defined this on the child class. But this is what I wanted it to do. Bootstrap is riddled with little tricks like these, especially in the complicated grid rules, that includes selectors like .row > [class*="span"], which selects an immediate child element of an element with the class "row" that has a class starting with the word "span". Obviously, unless I redefine this rule it's not going to do anything for me.

I thought a bit about what I would really want instead of this. What I think I would like is a CSS framework that allows me to use it for output like LESS and SASS, but also expects that I'm not going to use it forever; that I would really like to graduate to full-on compiled and minified CSS that doesn't include all of the cruft that the framework comes with that I don't use.

I can't see any way to get what I want using LESS and Bootstrap. Both tools make it easy and fast to get a layout up and running, but even combined, neither is very good at producing the CSS I would most want for my semantic HTML. What I would like most as a new feature would be to see a command that allows me to specify two selectors and have the compiler replace one with the other entirely in the output. In this way, I could keep the bootstrap source and add my own styles and keep my HTML5 markup nice and clean.

, , and

I've been thinking lately about the project process, and how software that manages the process tends to focus more on certain aspects than others, sometimes leaving important elements completely uncovered. To look at an example, Trac is a well-known ticket tracking system. It has built-in case tracking, revision history review, and documentation via the wiki. There are many plugins available that enable different minor features, but these are the basics of what Trac provides: Timelline, Tickets, and Wiki.

These features are important, but they do not encompass the whole project. A small development shop needs more than just these items as tools that are essential to their work. A very simple example is a design/document review and distribution system. Maybe this is not explicitly essential, but I've found over my time doing web development that there is too often a need for this than to let it go unchecked.

In such a feature, stakeholders would upload documents - whether designs, contracts, specifications, or whatever - to the tracking system. This would make them available to other project members as needed. This basic type of dropbox functionality is useful for accepting content from clients, making it available to the project team centrally rather than through unreliable email forwarding (especially for attachments of any useful size for designs), and having some accounting of when and by whom the files were provided.

In essence, this feature seems like a "nice to have", but rather than figuring out which 3rd party tool provides each individual feature of a full project process, shouldn't there be a single tool that does everything? From that perspective, there are a few significant feature that need to be added.

If you look at the project process from the point of view of a small web development shop, the project starts at the pitch. There should be a way to track bids and proposals in the system, so that those documents can ultimately be moved to active project status. This type of feature would also be useful to schedule and maintain contact with those potential clients.

An idea that has been growing more as I consider the full project lifecycle is that of a CRM, which ties nicely in with the bid process. Small web firms need to be able to efficiently manage time. Everything runs on a schedule, otherwise the next project will be delayed, or a bid will be lost due to time constraints. If part of your bid/proposal process included scheduling follow-ups wouldn't that be useful?

Consider also how CRM features could improve the ticketing and revision process. Rather than subscribe people individually to tickets, the system would leverage the CRM to obtain contact information and potential demand/desire for specific kinds of contact. Automatically send messages when milestones are reached or delayed. Notify the proper stakeholders of changes in planning and design. When documents arrive into the dropbox-like review system, make sure that the right person not only sees them, but has signed off on them, and keeps getting notifications that this must be done to complete the process.

One of the most frequent places in the project process where things get held up is during content creation. Too often, clients think that after they get to a certain point, the developers will simply make the site go. Without content, there really isn't a site, and the client is responsible at least for providing the content, if not entering it themselves. A CRM would be able to manage that process automatically, where developer who are busy creating features and making the working of the site perfect will often forget to remind the client - and the correct contact - of that obligation.

Another component of the problem is overall project scheduling. Unless you're able to work on only one project at a time, and only for a specific length of time, and meat your deadlines exactly without fail, you're going to need a way to schedule personnel resources against the projects that exist. You're going to need to know who is available, what skills they can apply, and how long it would take them to complete components of the project that have been assigned so that their work can be scheduled with the work of others on the same project, and with their other work on other projects.

This is a complicated problem, because there are so many aspects driving the needs of the scheduler. On one hand, assuming you had a definitive number for how long it would take each specific person to accomplish each specific task, you would be able to schedule all tasks with a simple calendar. Allow enough time for task-switching and thought organization, and that could work pretty simply. But we know that teams and workers don't work this way, so the scheduler needs some way to account for this, otherwise the schedule will be seen as useless very quickly into the project.

The schedule needs to account for risk in a way that makes sense. Some systems will calculate a worker's prior estimates against their prior actual time taken, and use that as a factor for multiplying out future estimates. There are so many things that could affect this computation, the simplest one being the worker himself altering his estimate based on prior performance! There is also the possibility that the work is completely different, such that the estimate has a different level of expected accuracy.

The challenge in building a system will need to include that there are many methods and processes for producing more accurate estimates, and that the more complicated these methods are, the more time they'll take as part of the project planning task. Some tools like Agile look at acceleration and story points as potential ways to estimate time for a task. Some processes include full-blown estimation and risk assessment. The ultimate project planning tool will make it as easy as possible to produce as reasonably accurate estimate, rather than dispense of accuracy for ease, or dispense with easy for accuracy.

It should be easy to determine what methods will work best simply by applying a one-page approach. That is, what information can be computed and conveyed with enough accuracy on a single sheet of paper that it is useful? This is likely to include many manual processes that might be tedious on paper, but more easily done with the computer. In most cases, things that work well in the real world that are made better with a computer end up being great solutions (see also: word processors). If the software can reduce the complexity to that level, then I would expect it to be successful.

It seems like my next step should be to outline a basic project workflow and identify the components that a computer could help with by demonstrating how they could be done on paper (or via mail or phone or in person, eschewing the computer completely). Using this process, I will have produced a list of useful components to project management success, rather than producing a set of features with no target. I do run the risk of targeting the end software at too specific of a process, which is something that I want to avoid. But if I'm careful to be very generic about the kinds of projects that this software will address, that shouldn't be a problem.

« Newer Posts  1 … 3 4 5 6 7 … 11 Older Posts »