You can now download Steam Framework 1.0.0 from the download page. Although there haven't been many recent changes in the repository, today I decided to bundle it all up and upload the archive. It's extremely easy to get it up and running and a simple example application is included.
Steps:
1. download and extract the files from the archive
2. configure apache to serve the content in the directory (subdomain+vhost)
3. download the latest minimal Zend Framework package
4. extract it to the Zend directory in the libraries directory
5. (optional) download and extract the Minify library
6. use your browser to access the web folder!
If you still don't see anything, you will need to edit the configuration/.htaccess file for to suit your needs.
If it's working you will see a very plain book catalog application. The next step is to play around with it and have some fun!
Tuesday, March 29, 2011
Friday, November 26, 2010
A bit of refactoring and a whole lot better
It has been a while since I have posted anything new here or committed anything to the Steam repository, but I have not been idle. I have consolidated code into fewer classes, I have removed dependence on a database and sessions, I have taken advantage of the fact that PHP is a templating language, renamed objects for clarity, and fixed a bunch of other problems. I am feeling confident that Steam has reached a point where no more major changes will be necessary. There may only be some changes made to how widgets are manipulated. The following are some of the highlights of the changes made to Steam.
Views, Widgets, & Templates
PHP was originally developed to be a templating language used to create web pages. It has since matured into a full fledged programming language, but it's ability to create web pages remains very powerful. Some have attempted to push PHP to the backend and provide new templating engines (Smarty), but I don't understand the rationale behind doing that. People are already familiar with PHP, and it already does almost everything we need it to do. I initially had problems using PHP "as is" with Views (pages) because I needed to manage headers and defer output until the very end. So instead, I had pages manipulate a page object, insert widgets (which return strings) into it, and display it using a method. In an attempt to find a better solution, I leveraged output buffering to capture the output of views and widgets, allowing one to code them in "natural" PHP, and then output them using a template also written in natural PHP. While views can now output directly to the browser with no problems, their intended use is to identify a template and map widgets to different blocks in the templates. But, I maintained the flexibility for people who only need to create simple pages.
Static Resources
I was using Google's Page Speed tool to analyze a site I created using Steam, and I noticed a few suggestions related to caching static resources. Prior to the current version of Steam, Apache was given the responsibility of serving static files, but in order to make the most of browser caching, I had to do it using PHP. The first thing I did was update the Apache rewrite rules to forward all requests to Steam. Then, I added a special resource type "static" to directly serve files residing in the static directory to the client based on portal rules. This allowed me to set the right Expires/Cache-Control headers to get browsers to cache files. I then moved on to provide fingerprinting so I could set expiration dates to a year in advance. Fingerprinting involves adding a "fingerprint" to the name of a static resource in order to uniquely identify it. When this resource is requested, the server responds with the file sans fingerprint. The fingerprint is generated using the md5 of the file contents. Whenever the file is modified, a new fingerprint is attached to the resource. This forces browsers to retrieve the new version even though they had been told to cache the previous file for a year. This functionality is handled automatically by steam. Simply use the following method:
\Steam\StaticResource::uri('/images/background.png');
This method will return a relative uri to the resource with the proper fingerprint attached.
Special CSS Handling
A common way of improving transfer speeds of pages is to decrease the size of static resources using minification. However, working with CSS which has been minified is not feasible. The easiest alternative is to minify your CSS each time you modify it, and have your pages link to the minified version. That option is also not ideal because it involves a cumbersome and repetitive task which is bound to go wrong once in a while. My solution was to have Steam automatically handle this process. When using \Steam\View, you can identify the need of specific CSS files using \Steam\View::css('layout'). This will add layout to a list of CSS needed by the current page. When it is time to output the html to the browser, Steam will combine the contents of the list of CSS, minify the resulting string, and cache it. This file is then served to the browser when it requests the CSS file.
Steam as a Wordpress Plugin
A friend of mine and I have been having problems with Wordpress: developing a javascript based user interface and working with Wordpress themes is ugly and difficult to achieve the desired results. The Steam way of accomplishing these things is much nicer, but rewriting wordpress using steam would be a lot of work, break compatibility with existing plugins, burden us with the task of keeping it up to date and bug free, and not be an acceptable solution for some people who insist on using Wordpress.
The alternative was to integrate Steam with Wordpress as a plugin, and that's what we did. Steam is now delivered with an interface to hook into Wordpress. This can allow you to take over certain URI's using Steam instead. For instance, you could write your theme completely with Steam. There is still work to be done to wrap all the Wordpress objects with Steam Models and provide a basic "theme" so it will be usable out of the box, but it has been tested and it works as intended.
Views, Widgets, & Templates
PHP was originally developed to be a templating language used to create web pages. It has since matured into a full fledged programming language, but it's ability to create web pages remains very powerful. Some have attempted to push PHP to the backend and provide new templating engines (Smarty), but I don't understand the rationale behind doing that. People are already familiar with PHP, and it already does almost everything we need it to do. I initially had problems using PHP "as is" with Views (pages) because I needed to manage headers and defer output until the very end. So instead, I had pages manipulate a page object, insert widgets (which return strings) into it, and display it using a method. In an attempt to find a better solution, I leveraged output buffering to capture the output of views and widgets, allowing one to code them in "natural" PHP, and then output them using a template also written in natural PHP. While views can now output directly to the browser with no problems, their intended use is to identify a template and map widgets to different blocks in the templates. But, I maintained the flexibility for people who only need to create simple pages.
Static Resources
I was using Google's Page Speed tool to analyze a site I created using Steam, and I noticed a few suggestions related to caching static resources. Prior to the current version of Steam, Apache was given the responsibility of serving static files, but in order to make the most of browser caching, I had to do it using PHP. The first thing I did was update the Apache rewrite rules to forward all requests to Steam. Then, I added a special resource type "static" to directly serve files residing in the static directory to the client based on portal rules. This allowed me to set the right Expires/Cache-Control headers to get browsers to cache files. I then moved on to provide fingerprinting so I could set expiration dates to a year in advance. Fingerprinting involves adding a "fingerprint" to the name of a static resource in order to uniquely identify it. When this resource is requested, the server responds with the file sans fingerprint. The fingerprint is generated using the md5 of the file contents. Whenever the file is modified, a new fingerprint is attached to the resource. This forces browsers to retrieve the new version even though they had been told to cache the previous file for a year. This functionality is handled automatically by steam. Simply use the following method:
\Steam\StaticResource::uri('/images/background.png');
This method will return a relative uri to the resource with the proper fingerprint attached.
Special CSS Handling
A common way of improving transfer speeds of pages is to decrease the size of static resources using minification. However, working with CSS which has been minified is not feasible. The easiest alternative is to minify your CSS each time you modify it, and have your pages link to the minified version. That option is also not ideal because it involves a cumbersome and repetitive task which is bound to go wrong once in a while. My solution was to have Steam automatically handle this process. When using \Steam\View, you can identify the need of specific CSS files using \Steam\View::css('layout'). This will add layout to a list of CSS needed by the current page. When it is time to output the html to the browser, Steam will combine the contents of the list of CSS, minify the resulting string, and cache it. This file is then served to the browser when it requests the CSS file.
Steam as a Wordpress Plugin
A friend of mine and I have been having problems with Wordpress: developing a javascript based user interface and working with Wordpress themes is ugly and difficult to achieve the desired results. The Steam way of accomplishing these things is much nicer, but rewriting wordpress using steam would be a lot of work, break compatibility with existing plugins, burden us with the task of keeping it up to date and bug free, and not be an acceptable solution for some people who insist on using Wordpress.
The alternative was to integrate Steam with Wordpress as a plugin, and that's what we did. Steam is now delivered with an interface to hook into Wordpress. This can allow you to take over certain URI's using Steam instead. For instance, you could write your theme completely with Steam. There is still work to be done to wrap all the Wordpress objects with Steam Models and provide a basic "theme" so it will be usable out of the box, but it has been tested and it works as intended.
Monday, September 28, 2009
Midnight Ridazz
The Midnight Ridazz are an informal group of Los Angeles cyclists who get together on a daily basis to ride with each other. As a member of this group, I stay connected with the other ridazz using the MidnightRidazz.com website. The classic (ancient) charm of the site certainly has its appeal, but there are many important tools we need in order to maximize our enjoyment (known as F.U.N.). I offered to take on the challenge using Steam, and Roadblock (our benevolent leader) accepted my offer.
Roadblock and I agreed that the original character of the site will be maintained by taking an essentials only approach; deviations from the user interface should be made only if they improve the site's usability. However, accurately judging whether or not something is an improvement requires many different opinions. So, after the initial version is completed, we will let people test drive it and get their feedback.
My greatest challenge in both difficulty and importance will be to bring the most happiness to the community. Therefore, the most important step will be to listen to those who hold the deepest regard for the Midnight Ridazz, and make sure I don't piss them off too much.
This project has been the most exciting project on which I have ever worked. Being a member of the community and supporting the cause of the Midnight Ridazz, this was the perfect opportunity for me to pour my heart and soul into something to bring about positive change in our home, Los Angeles.
I am excited in anticipation of its completion.
Roadblock and I agreed that the original character of the site will be maintained by taking an essentials only approach; deviations from the user interface should be made only if they improve the site's usability. However, accurately judging whether or not something is an improvement requires many different opinions. So, after the initial version is completed, we will let people test drive it and get their feedback.
My greatest challenge in both difficulty and importance will be to bring the most happiness to the community. Therefore, the most important step will be to listen to those who hold the deepest regard for the Midnight Ridazz, and make sure I don't piss them off too much.
This project has been the most exciting project on which I have ever worked. Being a member of the community and supporting the cause of the Midnight Ridazz, this was the perfect opportunity for me to pour my heart and soul into something to bring about positive change in our home, Los Angeles.
I am excited in anticipation of its completion.
Monday, July 13, 2009
High-Level Languages
Both computing hardware and programming languages have come a long way since their inception. The high level languages of today are made possible by the availability of hardware necessary to efficiently execute programs written with them. Successful languages are those which can best satisfy the needs of the involved parties. High-level languages have become successful because the time of a developer costs significantly more than the performance losses associated with high-level languages.
I believe one of the most problematic areas of development lies in the testing/debugging process. For this reason, I believe that language development will focus on changes which will reduce the amount of work required to test and debug.
I believe one of the most problematic areas of development lies in the testing/debugging process. For this reason, I believe that language development will focus on changes which will reduce the amount of work required to test and debug.
Tuesday, June 30, 2009
Seeking another developer
As I continue the development of steam, I'm becoming more and more interested in adding another developer to my team of one. One of the most important reasons why I want another developer is to get a second opinion on design decisions and speed up the overall development of the project.
My current method of development of steam is side-by-side design-implementation. I am developing a project which uses the framework, and when I run into problems or areas where the framework could simplify or speed up development, I modify the framework and continue. I develop features as I require them so that I can identify specific requirements rather than by trying to guess what I might need.
Let me know if you are interested in helping out. Thanks!
My current method of development of steam is side-by-side design-implementation. I am developing a project which uses the framework, and when I run into problems or areas where the framework could simplify or speed up development, I modify the framework and continue. I develop features as I require them so that I can identify specific requirements rather than by trying to guess what I might need.
Let me know if you are interested in helping out. Thanks!
Subscribe to:
Posts (Atom)