This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
Current Efforts:
Blue Parabola, LLC
HubAustin
web2Project
PHP'ers:
Cal Evans
Eli White
Elizabeth Naramore
Joe LeBlanc
Matthew Turland
Matthew Weier O'Phinney
Planet PHP
Tony Bibbs
Business/mISV:
Bob Walsh
Eric Sink
Joel Spolsky
Micah Baldwin
Paul Graham
Past Projects:
CodeSnipers
HOBY
Judicial Watch
mobile FoxNews.com
NRTW
Great Tools I use:
Drupal
GitHub
NetBeans for PHP
phpUnit
Subversion
Zend Framework
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
Getting closer...
I still can't announce our official web2project release date, but there are two major things that were just marked off the todo list based on the amazing effort of Pedro...
Table Prefixes - This seems like such a silly thing. In this day of cheap shared hosting, why in the world would you want/need table prefixes when you can just create another database? True, and good point... but the problem is that there are a number of hosting companies (and system admins) that don't give you an additional database. Or - more interestingly - you may have applications that need to report and aggregate information and having all of the data reside in a single database is simpler in terms of permissions, coding, etc.
So in the last week, Table Prefixes have been implemented throughout the system. We're in some final testing, but it appears to work about as expected without any oddities. The best part is that our new debugging interface gives us all kinds of useful bits as we go. This also gave us a second benefit... there is no raw sql anywhere within core web2project. There are some natural implications of that, but I'll let you ponder the ramifications... ;)
Coding Standards - One of the banes of my existance is stepping into a codebase and finding a mishmash of code, functional, classes, and a general mess of things. It makes things painful at best and horribly confusing at worst. Towards that goal, we're nearly complete with the cleanup of the entire codebase to a useful coding standard. Since PEAR wasn't quite a good fit, we followed in the footsteps of another great project - CakePHP - and are using their Coding Standards as a starting point. I also plan to follow in the footsteps of Jason & Garrison at North Carolina State University to tie CodeSniffer into the checkin [This is not the original link as it was taken offline. This new link is same concept, different author. -ed] process to keep the standard enforced.
For clarification, this does not mean that web2project is being converted over to use CakePHP as its framework. I happen to think that the underlying dotProject framework is pretty solid - especially with the latest permissions cleanup - and something like the Zend Framework makes quite a bit more sense. Of course, I'm biased as I've already implemented most of a Zend_PDf-based replacement for the existing Reports module... and technically I'm a ZF contributor though I haven't done anything with it yet.
Modules - We believe that one of the single biggest strengths within the dotProject community was the sheer number of functionality of the various Add On Modules. The Project Importer module is the single most popular dotProject Add On Module (based on downloads, page views, etc). In addition, the Project Exporter has sparked renewed interest and is scheduled to be completed for regular dotProject this week.
Therefore, there's a bit of a race among a few module developers that are working to convert their things at the same time... what will be the first Add On Module available for web2project? Will it be the Project Importer or will someone else take that honor?
Why we need table prefixes
People tend to forget the merits of allowing all the data to reside in a single database. It makes things that much easier to handle, and that is probably why we need table prefixes.
Single point of failure
But with everything in a single database, you've introduced a single point of failure for all of your applications.
If *one* of your applications has a vulnerability, you've just put *all* of your data at risk.
Post new comment