I've been in the USAF for almost 10 years (since October 2002). I've heard some pretty crazy things about us. Here's the deal.
Everyone in the Air Force isn't a pilot. Surprised? Well, we're not. It's a good thing we all aren't, otherwise: there wouldn't be any working jets, no bombs ready to fall or missiles ready to fly, no fuel in the not working jets, no one would get payed, there would be no buildings or even a runway, there would be no one to provide security, no nuclear stockpile waiting for someone really dumb to force us to use them...there'd just be a bunch of "pilots" sitting around with nothing to do. We do a lot more than fly and it takes hundreds of people to fly a plane, even if most of us never leave the ground.
It's a job. It's a really cool job and a lot of times really dangerous, but it's still a job. For some of us it's not just a job though, it's something bigger than any other profession can understand. It's a family, it's a machine, it's living breathing monster waiting for the wrong person to piss it off. What other people in other professions can probably understand is eventually, maybe, it isn't a job anymore. At one point or another something clicks, either on or off, and your view changes. You either click on and suddenly it's not a job anymore, it's what you are or you click off and realize you aren't in the right place anymore. It's the best (or worst--depending on your outlook) job in the world, because few other jobs are also a service to millions of people.
Most of us hate war. We didn't join the military to fight, we joined to keep someone else from winning (or to go to college, or to grow up, or to get away from someone/something/some place, or...whatever). I joined to see the world and, well, that hasn't worked out so well for me. I also joined to grow up and get away from what I thought was going to be a bunch of really poor decisions. We all join for different, but similar reasons. Everyone has battles in their lives, we just chose to be ready for our battles.
We aren't here because we couldn't make it somewhere else. We aren't dumb (well, most of us aren't). A lot of us are here because we didn't make it somewhere else, but that just means we didn't try as hard as we should have. We failed at something easy so we decided to right it by doing something way harder. My mom doesn't even know exactly what I do and she would probably tie me down and not let me come back if she did.
Well, that's a few, I'm sure I'll think of a few more for another day.
I've decided to start blogging more and not just about my projects. We'll see how long it lasts and yes I realize I need to hurry up with the comments app...
Just read this informative blog about PHP memory usage in some frameworks and CMS'. As of writing this blog, I have an HTML comment at the bottom of the page's HTML source that tells me the execution time and peak PHP memory usage to generate any page on this web site using ClayCMS. Just right-click and click View Source (or equivalent) to check it out (last thing on the page).
I just checked the peak PHP memory usage for the home page of this site and it says Peak PHP Memory Usage 605660 bytes. We'll round that up to 606 KB. According to the blog post I linked to, PHP uses 256 KB just to render "Hello World" on a page. I'm sure that is dependent on the machine and how it is configured, but that sounds pretty accurate. I'm not trying to brag, I just want to point out that taking the time to optimize and focusing on performance does make a difference. Granted, there are a lot of features missing right now, like blocks and things like that. Check out the blog if you haven't yet. Those memory numbers were for a basic page, nothing extra. If I go to a page like that, maybe this page, it says Peak PHP Memory Usage 502292 bytes. So if we assume a decent sized application (this is a blog page with a pager, HTML filtering, and quite a bit of SQL data) load added 100 KB, adding blocks may add 200 to 300 KB to the memory usage, maybe more maybe less. We'll say it will add 400 KB. That puts ClayCMS' peak memory usage around 1 MB, with a full featured page being generated.
I just hope I can keep this performance scale, because so far I'm cutting the best memory usage in half. Drupal with a limited number of modules was pulling down about 30 MB of memory at peak. Once again, I'm not bragging. I know how fast and easily something can get bloated. Let's just hope ClayCMS scales from here and keep trying to make it even better.
I've been working on a PostgreSQL adapter for ClayDB. I've only used PostgreSQL once before now and that was just to run a Xaraya installation for a client years ago. I never thought there was really a difference between MySQL and PostgreSQL. Wow was I wrong. PostgreSQL has some really interesting data types, including UUID, ARRAY, and lots of geometric data types. I don't know how I could possibly utilize all of the features in PostgreSQL and maintain any sanity within the ClayDB Adapter interface. It is a really interesting database and I'd like to experiment with it a lot more.
Working on the adapters for SQLite and PostgreSQL have made me realize the down side to having a simple Database Abstraction Layer and the features we have to sacrifice for the sake of being flexible. In the future I may take that into consideration when developing a next generation ClayDB library. Fortunately, if someone doesn't care to maintain compatibility with more than one database, they can still use ClayDB as a connection manager and PDO wrapper. ClayDB doesn't require adapters to implement the Adapter interface class, so one could create an adapter specifically taylored to any database engine and disregard any needs of any other adapters.
Anyway, I'm working on the PostgreSQL adapter. Once it's finished I plan to work on a MSSQL adapter, which will be tested with the SQL Express server. I hadn't planned on supporting any closed source databases, but I'm trying to open Clay up to as large of a user base as possible. MSSQL is very low on my priority list, as I will likely never use it. It's still on my list though, so yeah.
There is an interesting article on the PHP Classes blog about an optimization that was introduced in PHP 5.4. I remember reading about a change to the way PHP 5.4 handles object properties, but I don't remember it explaining what the optimization did.
"That was when Portuguese core developer Gustavo Lopes explained that starting PHP 5.4 the dynamic properties hash table is created only if variables are added dynamically to objects at runtime."
This is quite interesting and kind of surprises me that it wasn't in PHP 5 already. What the quote means is if you only use object properties that you declare in the class declaration (before using the properties in a method), PHP 5.4 uses a single hash table for any object created from the class. In the past PHP 5 created a new hash table for every object, which meant if no dynamic properties were introduced after the class declaration it was wasting memory on excess hash tables it never really needed.
This explains the phantom memory differences between my web server (PHP 5.4.x) and my test server before I upgraded it to PHP 5.4. Lesson learned: Declaring class properties isn't only to make the code easier to read, it's also an optimization!
I updated the SQLite adapter and datadict for ClayDB in the Clay repo on GitHub. I haven't pushed it to the Clay Framework repo yet. It's kind of a dirty fix for now; they are based on the MySQL adapter and datadict in ClayDB. I haven't tested it on Linux yet, but plan to this weekend if I have time. It works on Windows and uses the PDO SQLite extension in PHP. Databases are created in the /data folder. No changes were required to ClayDB query syntax; the adapter and datadict translate ClayDB's methods, so everything that works under MySQL works with SQLite.
The Shift indicator light began blinking on my 2005 Honda Pilot, so I had a transmission diagnostic ran. The dealer told me it was getting a 4th Pressure Switch fault. They wanted to charge a couple of hundred dollars to fix it. I got the part number from them and decided to fix it myself. I found this web site that has some pretty awesome diagrams, along with all of the parts in the picture. They charge below list prices and ended up replacing the 4th (#11 in the diagram) and the 3rd (#12 in the diagram). I also bought new fender clips and new washers for the switches, all for under $100. It took less than an hour to replace the switches and would have taken less if my old fender clips didn't all break in the process of removing the fender guard.
Things are finally slowing down at work again, so it's time to get back into the grind on Clay. I have to finish the permission system in ClayCMS, so that is my priority for now. While I'm working on the permission system, which is mainly working on the database schema and optimization, I plan to finish the ClayDB adapter for SQLite. It's a good time to work on it, since I am working on schema anyway and spending a lot of time in the database tables.
Once SQLite support has been added to ClayDB, I plan to implement adapters for PostgreSQL and Firebird. I would like to have more database adapters, but I will likely not write any adapters for closed source databases. I have considered DB2 and MSSQL (mainly for Azure support), but those will not be a priority for me. Anyone that wants to contribute an adapter is more than welcome though.
One of my goals for the new BeSquishy.com is to make it a content and data services provider. There are several sites that offer hooked like content services, such as Disqus' comment system, and I believe it is the future of content management. A lot of people do not have the time, resources, or experience to set up their own web site and deal with upgrades, backups, and troubleshooting. They often get a hosted solution, settle for a service that doesn't meet all of their needs, or jump from solution to solution trying to find one that will allow their sites to adapt with their changing needs. I, personally, appreciate how many open source solutions there are, but for someone that just wants something they can mold to their needs, it can be a tedious process to narrow down the choices.
For content services I want to provide interfaces to go with the data, also hosted and available to be used in any way. Much like Disqus offers a hosted comment system, BeSquishy will allow you to hook in content and data that is managed and stored remotely. That's the idea anyway.
BeSquishy isn't online yet, but the true value to the experience I hope to offer through it is it will be open source and open for anyone to contribute to it. I don't plan to charge for it, but if there is enough demand there is a potential for premium services or dedicated support. I think it's the future of content management and so far I've been pretty lucky when it comes to predicting things like that. There are also other things I want to offer through BeSquishy, but they are related to the idea above, in one way or another, and it is way too early to get into those :)
Almost 4 years ago BeSquishy.com was my project of focus, a hosted content management system built on a hybrid of Xaraya and the codebase that would become Clay. I stopped development of BeSquishy.com to further develop Clay into a standalone framework, with the hope of one day building the BeSquishy.com content management system on just Clay. Well, we're not there yet, but BeSquishy.com is coming back in a different way. Clay isn't feature rich enough yet to support a hosted content management system on its own, but it is getting closer. This time around BeSquishy.com will serve as the flagship web site for promoting Clay and will offer services built on Clay, along with other initiatives. It could one day move back in the direction it was once going, but times have changed and so has the way people use the Internet. There are many web sites out there that offer the older BeSquishy-like functionality, although I have yet to find anything close to a full realization of BeSquishy's ambitions; Facebook is probably the closest at this point. This time around BeSquishy will cater more to web developers and open source intiatives it sponsors.
Starting off I plan for BeSquishy to offer some web services that I feel will make web developers' lives a little easier, some of which are available else where, some are not. BeSquishy will be completely open and anything it offers will be open sourced for collaboration. Everything won't be tied to Clay, although I imagine a lot of the code/initiatives developed through BeSquishy will be included in Clay in one form or another. It will be a separate entity, but will have close ties to the Clay Project as a sponsor.
Between illnesses in my family and a never ending busy work schedule, I am not sure exactly when BeSquishy will makes it appearance. I have a vague idea for a timeline. I have long planned to have clay-project.com online by the end of July, so I imagine BeSquishy.com could show up sometime around that timeframe as well. I plan to create a GitHub organization and begin throwing some ideas in there for the first few web services to offer. I'll keep you updated.
I've been a little sick lately, so i haven't focused on as much development as I'd hoped. I have done some work on Clay, but not a lot to ClayCMS. You can see the latest changes on the project's GitHub page.
I expanded the applications' ability to specifiy which templates to use within their class methods (Component Actions). Before it was done by setting the object property $template to a string of the template name:
$this->template = 'toolbar';
would use the template toolbar.tpl in the application's /templates folder.
You can also use subfolders in the template name:
$this->template = 'includes/toolbar';
would use the template toolbar.tpl in the application's /templates/includes folder.
The new addition (you can still use the string for an in-application template), allows you to set the template using an array. This array allows you to specify a template from another application or from a theme:
$this->template = array('application' => 'blog', 'template' => 'toolbar');
$this->template = array('theme' => 'simplestyle_4', 'template' => 'toolbar');
In both cases above it would use the toolbar.tpl template in the /templates folder of whatever the first key is set to.
I also expanded the application object's template method, allowing a 2nd parameter to override the template origin, template name, and override/supplement data provided in template variables.
$this->template($dashboard, array('application' => 'system', 'template' => 'toolbar', 'data' => array('message' => 'This is overridden from the page template'));
The way this works is $dashboard is an array created from using $this->action() on an application object. The 2nd part, another array, adds to or overrides parts of the array provided by $dashboard. The 'data' array defines a variable $message that can be used in the system/templates/toolbar.tpl template. In the example I made it come from a page template, but any template has access to $this->template() and can include other templates.
I also created a new API to replace the Pager I made a few weeks ago (the one at the bottom of this page). The old Pager used an application object, while new the Pager uses a static application library (class) that is called as an API. It doesn't create any new objects, like the old one did, and seems to be a little more efficient. Application objects aren't resource hogs anyway, but every little optimization helps.
I updated TinyMCE in the Clay repo to the latest version.
Finally, I worked a little on a code highlighter, so I can show highlighted code in blog posts. I may make it into a TinyMCE plugin, but I haven't decided exactly which route to take yet. I am leaning toward a lighter solution than TinyMCE, perhaps something using HTML5. If I move to a different WYSIWYG editor, I will create an option so you can choose which editor to use. I have managed to get a little work done while being sick, but I'm hoping I'll feel better soon so I can focus on something a little more complex...like the ClayCMS privilege system, blocks, hooks, etc.
I pushed the MT theme today to GitHub. You can browse the theme on GitHub here:
Keep in mind that is the current tree, so if I push a change you wont see it with that URL.