#packfire

[packfire-blog]

v2.1 update plans

Packfire Framework came a long way to be where we are today. The framework now empowers research projects as back end data servers and controllers, such as the Travel Assistant for the Visually Impaired (TAVI).

With the will for continuous progress, Packfire will be releasing a version 2.1 on 15 April 2013 sporting the following new upgrades, improvements and new features:

Better IoC dependency distribution using Packfire FuelBlade

Config and Flash message view filters

Security Analysis page

Backend Administration Webpages

Improved Composer package loading and integration

several minor bug fixes and greater code testing coverage

minor code speed up and improvements

[packfire-blog]

Upcoming Projects and Updates

First of all, Merry Christmas to all (: More code, less talking. That's what happened for the past few weeks. Nevertheless, we came up with great projects that we are sharing open source on Github. These projects were created to solve many challenges that web developers or software engineers face commonly. Here are some of the projects: `[CLI]` means that the project runs as a command-line interface application in the form of a PHAR binary. `[Composer]` represents that the project can be installed and used by others through Packagist and Composer installation. - [PDC for PHP](https://github.com/packfire/pdc): [CLI] a smart little worker that helps you to check for missing class dependencies by analyzing your source code and checking against PSR-0 namespace and autoloading. Makes you code faster as you spend less time trying to fix a misspelled namespace. - [Packfire Torch](https://github.com/packfire/torch): [CLI] a web asset management tool for you to keep images and JavaScript libraries out of your version control. Torch installs web assets from any source just like how Composer install components. - [Packfire Options](https://github.com/packfire/options): [Composer] A PHP-implementation of NDesk.Options (C#) using Closures and callbacks to help you effectively parse CLI arguments across platforms. - [Packfire Concrete](https://github.com/packfire/concrete): [Composer] A small library that provides toolset for PHAR compilation similar to how Composer does it. Used by PDC and Torch to compile themselves into PHAR binaries. CLI version coming soon.

[packfire-blog]

Environment Switching in Packfire

Different environments for your web application may require different configuration or certain parts of your code to run. For example, your database set up on your local development environment may be different from your actual production server in terms of authentication. As a result you update your configuration file whenever you deploy your application to the production server. Doing that sometimes makes you lose valuable configuration data which you may require later.  **Environment Switching** In Packfire Framework for PHP, all your configuration data is kept in the the `config` folder. Because we know that environments can require different configurations, Packfire allows you to switch between the configuration files based on the environment value. You can set the environment value by either setting the `PACKFIRE_ENV` environment value on your operating system or writing the environment value to `pack/env` file of your application. For example if you set `'local'` for your local development environment, configuration will be loaded from the `app.yml`, then loaded with data from the `app.local.yml` if it exists. This allows you to set the configuration for your computer when performing local development.  All the configuration files are kept with the version control and everyone is happy.

[packfire-blog]

Installing Packfire Globally

On our previous post, I shared that Packfire Framework 2.0 can be installed into your Packfire application locally by running the Composer command. If you need to install Packfire Framework 2.0 globally, you can follow the steps below: 1. Copy the Packfire Framework folder into the target folder on your server. 2. Open the `pack/constants.php` file in your application folder 3. Add the full pathname to the target folder where you installed the framework into the `__PACKFIRE_ROOT__` constant. With the `__PACKFIRE_ROOT__` constant filled, the framework will be searched for in that folder instead of the default Composer vendor folder.

[packfire-blog]

App and Framework Compatibility

From Packfire Framework 2.0 onwards, we've been spotting [Composer](http://getcomposer.org/) to allow developers to manage dependencies - particularly between an Packfire web application and Packfire Framework itself. Composer is a powerful tool for PHP developers to manage libraries and package dependencies in their software. Like how the other dependency managers work with channels and content repositories, Composer loads and install packages that are required by your application from [Packagist](http://packagist.org/) or a version control repository online. In Packfire 2.0, applications comes with a default `composer.json` file to allow you quickly install the framework with the application without any hassle. To install the framework for your application, simply run: $ curl -s https://getcomposer.org/installer | php $ php composer.phar install This will install the framework into your application only. **Version compatibility** Since Packfire is with Composer now, the versions are properly managed to ensure that you get the latest updates for your application while making sure that your application does not break. Version numbers are broken into three parts. The current version released as of right now is 2.0.1. It is in the format of a `Major.Minor.Update`. This is according to the standard posted by Composer. However to ensure that your application is compatible, we run compatible updates only by changing the update number in each release. Meaning to say that if you have an application meant for Packfire 2.0, you can safely install all newer versions of Packfire with versions like `2.0.*`, i.e. 2.0.1, 2.0.2, 2.0.5, without breaking your application. If we release an update for Packfire that requires application-side updates, we will release that build as `2.1.*` instead, and post details on how you can update your application manually to ensure compatibility with the newer version. With that, you can concentrate on your business and application logic development with ease.

[packfire-blog]

Github Gist and Travis-CI Integration

Over the past few days, Packfire Framework 2.0 has been continuously improved and fixed. As Packfire 2.0 conforms to the PSR-0 standards with namespaces, we've been detecting and fixing missing dependencies or problematic dependencies. The manual lookup and testing was very taxing and time consuming. Hence, a new tool called `pdc` (stands for Packfire Framework Dependency Checker) was written to help detect such problems. > `pdc` works great in helping to resolve and detect files with missing or broken class dependencies because such problems cannot be detected until runtime due to the nature of autoloading usage in PHP 5.3. It warns about PHP files with missing namespace statement at the top and dependencies in the file that are not resolved properly. The tool works great when we manually run in on our computer - but that's not enough. We need automation. **Automation** To automate the tool with our [regular unit testing with Travis-CI](http://travis-ci.org/packfire/packfire-framework), `pdc` was [uploaded to Github Gist](https://gist.github.com/3939260). [Packfire's `.travis.yml` file](https://github.com/packfire/packfire-framework/blob/c4b3069da949eee9c40fe6867a922e5aa7869a19/.travis.yml) was then modified to add in the lines: after_script: - git clone git://gist.github.com/3939260.git pdc - php pdc/pdc src The `.travis.yml` configuration now tells Travis-CI to pull the `pdc` tool from Github Gist and execute the tool right after unit testing is completed. Now the tool is automated with each push to Packfire Framework's repository, detecting and displaying result on the Travis-CI console:  **Updating the tool** The best part about Github Gist is that you can still edit your tool after you upload it. When changes for the tool is required, all we have to do is to click on the `Edit` button.  You get the same sweetness in version control of your tool on Gist as it is powered on Git as well.

[packfire-blog]

Test-Agent: Our little script that updates and tests Packfire Framework quickly and easily. The test script is run based on the .travis.yml configuration file.

[packfire-blog]

Friday Update #1

The past five days had probably been one of the best weeks so far: [Felix Baumgartner](http://www.redbullstratos.com/) jumping off 128,000 feet from the edge of space and back to Earth; Google shows you how their [Data Center in Lenoir](http://thenextweb.com/google/2012/10/17/where-the-internet-lives-google-invites-you-in-to-see-its-data-centers/) look like with Stormtroopers and employees rickrolling or caught on camera with food; Dropbox gives out free space to university students in a [Great Space Race](https://www.dropbox.com/spacerace?r=NTE3MDAwMjc5); announcement of Google, Microsoft and Apple events. Other than those out there, Packfire Framework 2.0.0 has been doing great for the past week. Some in-house applications (including the Packfire Framework official website) has been upgraded and tested against the 2.0.0 build to ensure compatibility and ease of development. It was announce earlier than MongoDB will be supported in the release after Packfire Framework 2.0.0. Packfire Framework 2.0.0 preview will be packaged and released this Sunday, 21 October 2012. Here's a brief summary of the changes made from 1.1-sofia to 2.0.0: - [PSR-0](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md) compliance - [Composer](http://getcomposer.org/) implementation - PHP >= 5.3 strictly for namespace and autoloading - Updated application structure - Better security handling - Many bug fixes and performance tuned So stay tuned for more updates