Agile Toolkit Tutorial #1 – A better web development

Web development does not need to be complex. You have reinvented the wheel way too many times. It’s time to reinvent web development altogether. The source of inspiration for Agile Toolkit – the new web development framework – comes from Desktop and Mobile application development and object oriented toolkits. Our first tutorial episode will give you a very brief, 25-minute introduction to this new framework and will highlight some of main benefits.

Agile Toolkit Tutorial #2 – How to become a web developer

You might have installed WordPress or Joomla for your friends, but have you thought about earning your living with Web Development? To became a successful web app developer you will need to be efficient. You must know how to build software quickly and how to improve it over time without compromises. This tutorial episode will guide you through a prototyping phase of the application. Putting together a basic screens and UI elements just to show to your client or investors is easy and fast in Agile Toolkit. The best part is that you will be able to continue and enhance your prototype until it becomes a fully-featured scalable web application / service.

Take part in the next hangout

We are recording Agile Toolkit Tutorials now on a weekly basis, every wednesday. If you have a microphone you can participate too. We use Google Hangout and ScreenFlow to record and edit episodes. Come along for the next one, register on our Google Event page.

The next episode will focus on the awesome back-end features of Agile Toolkit – Active Record, Object Relational Manager, Multi-table Models and how to use full potential of your SQL database to build scalable web software.

If you can’t make it to the next one, come next wednesday 1:30 UK time (http://www.agiletech.ie/time/1:30). This is a weekly event.

http://youtu.be/DimVEvuOm_g

Your questions are answered and the guide gives a great taste of what can be done with Agile Toolkit just in a few moments. This is the first podcast in the series with a new episode scheduled every week.

We are recording episodes live and if you are willing to participate and ask questions, here is the link for the second episode event:

https://plus.google.com/u/1/events/cr7rqaq57dp3aler6idsjrrrf6o/105976746491820250883

Jeff said it, PHP language sucks. But we use it. Why?

• It’s easy to install for new users. It’s a single PHP extension. And in most cases that’s all you need.
• It’s easy to read. Surely some new scary features have been creeping into, but why the hell do I want my integer to be an object?
• It’s fast. Initially PHP was a collection of C routines. It naturally evolved to be a thin layer on top of C with it’s own language parser.
• It’s safe. Problem with one application can’t impact others. No memory leaks. No runaway threads.
• It’s flexible. Diversity and low standards is what makes Agile Toolkit possible to innovate new and exciting ways.
• It’s transparent. You can actually pick the code and be able to follow what’s going on. Try to follow Ruby framework with all the overloading.
• It’s scalable. It encourages developer to think in terms closer to low level languages.
• It is usable on it’s own. You can actually develop web app in PHP without any 3rd party PHP code.
• It gets job done. When a web app needs to be develop quickly for someone, nothing beats PHP.

Different languages serve different purposes. Inconsistency in function naming? Oh, Cmon.

If you combine object-oriented principles with Model-View-Controller paradigm properly, this will result in a much more efficient web development environment. In this article I explain object-oriented principles can be combined with MVC paradigm.

NOTE: I am the author and maintainer of Agile Toolkit. Me and my colleagues have built Agile Toolkit according to the principles I describe here. This article, however, is for promoting the fundamental ideas. If you would like to see a fully-practical implementation of Object-Oriented MVC, read introduction to Agile Toolkit. You are also welcome to implement ideas described here in your favourite programming language / framework / development environment or simply extend your out-look and expand your vision of Software Development.

Understanding Objects

If you are unfamiliar with object-oriented programming, method overloading and abstraction, let me start with an example.

Suppose that you must develop an application which draws shapes on the screen. The shape you need to implement would be Circle, Square and Line. Each shape have a set of different properties such as dimensions, lengths etc. The way how each shape is drawn would also be different. Therefore we would define a base-class first:

[php]
abstract class Shape {
public $x, $y;
abstract function draw();
}
[/php]

Afterwards you would extend this class to create Circle, Square and Line class. Each class would add some additional properties and implement draw() method differently. What is important is that you can abstract interactions with shape in the main body of your program. For example:

[php]
foreach($shapes as $shape){
$shape->draw();
}
[/php]

Regardless of how many different shape classes we have defined, how complex they are and how many properties they hold, the code above will remain as it is. This principle is called Abstraction and is often used in Object-Oriented application design.

Composition

The second important principle of Object-Oriented programming is Composition. That is ability of one object to rely on implementation of other objects to achieve it’s goal. Consider the following implementation of the “Square” class:

[php]
class Square extends Shape {
private $lines;
function draw(){
$lines[0]->draw();
$lines[1]->draw();
$lines[2]->draw();
$lines[4]->draw();
}
}
[/php]

In this implementation, Square relies on four other line objects to do the job. Of course Square can also be implemented differently, but the important thing is that it re-uses other objects to achieve minimum code and simplify implementation of a Square.

Both principles work extremely well in Web development, but many developers neglect to use them on a regular basis.

Planning Web Software with Object-Oriented approach

When any new application or a system is designed, software architect tries to anticipate what kind of flexibility will be required from the software and will attempt to use some of the development paradigms (including those two I have described above) to improve flexibility and efficiency of the software.

Let’s walk through the typical web application and see what areas of the application we anticipate to be extended and will require flexibility.

1. Data Model

M in MVC stand for Model. Model is an object which represents piece of physical data in your application. This can represent User, Order, Record, Message and many other things. There are many great frameworks which will help you convert your SQL data-base into Model structure at the expense of losing ability to use some powerful tools of Object Oriented Programming:

• Generated Models typically will not use inheritance
• Generated Models will not use abstraction
• Generated Models will not use composition

There are many cases when use of the methods will save you some grief and all you need to do is to learn and recognize them. Here are few examples:

Inheritance: Publisher and Advertisers

Suppose you build web application where some users can publish articles and other users can advertise on the sidebar. Both type of users pursue different goals and are permitted to do different functions. They do have, however, some things in common such as ability to change their password.

A skilled software architect would create a class for a “User” which then would be inherited by Publisher and Advertiser. Method for changing password would be described in the “User” class and will be inherited by both Publisher and Advertiser.

You can also create a User class which incorporated features of both Advertiser and Publisher, but then any change to Publisher logic might impact Advertisers making your project less stable. The project will also become less flexible and it wouldn’t be as easy to introduce a new class of users without affecting existing functionality.

Through proper use of object-oriented inheritance principle you can achieve a much better structure source code.

Composition: Model Features

Models can have certain features such as soft-delete or ability to produce audit records. This functionality can be implemented through a separate objects instead of making model support it all. This is where composition principle is used. Some ORM systems will allow you to “enhance” your model by incorporating additional features through 3rd party classes. With composition you can also define your own patterns and make use of other classes inside your model.

With composition you can implement field encryption, validation and behavior extensions – all of these are very useful for a flexible application.

Abstraction: Generic Views

Suppose you have two models: “User” and “Order”. They do have a different set of columns, operate with different data-sources and behave differently and would also contain different set of methods. However they might be based on a generic model class. This way some User-Interface code can assume certain things about your models.

The most basic things to assume is how to create, delete update and list records. However views could also extract information about model fields from the model in which case they can build tables and forms for you without the need to re-define them all again.

Your model can be used by a restful API implementation which will transparently support manipulation with any model your system has. More importantly, you can also produce up-to-date SOAP specifications on the fly without any intermediate code.

That is the power of Object-Oriented abstraction.

2. User Interface

Let’s now switch to the User Interface of your web application and try to find where the similar principles can be used and applied. It is more challenging to design Object-Oriented User Interface for web software, simply because everyone wants to have a unique design, but it is still doable.

Any user interface design will be based around some concepts. You would operate with things like frames, buttons, layouts, headers, boxes, pop-ups and so on. Each element could be described with a piece of HTML code and some logic code. Frame, for example, would have two dynamic areas – title and the content.

Commonly the MVC principle uses no Object-Oriented principles in building Views instead it relies on template engine to do all the work. Templates do allow you to perform includes but are not object-oriented in any way. You can’t inherit a template and pretty often virtualization principle is not working either. If you are using regular MVC approach, you end up losing the flexibility of object-oriented programming.

This can be solved by working with objects. Suppose our objects are: Frame, Button, Paragraph. Because we enjoy customization we would also need a object with a custom HTML template which we can call “View”. With Smarty templates often include one another. With objects we already have a great principle called composition.

Composition: Form

Probably the best UI component which relies on composition is Form. The form class on it’s own can do very little, however it relies on “Field” and “Button” classes.

Composition principle in software with Object-Oriented user interface would go beyond forms and will allow any view to be composed of other views.  A frame could contain a form. A form field could contain a button. Finally the page could also be an object.

We are not eliminating templates, but templates are now used by each object individually. You no longer include templates but you now incapsulate objects.

Abstraction: Generation of HTML

Ultimately any Web Software must produce a HTML output for browsers to work with. If our User Interface consists of objects, then we will have to rely on abstraction when generating HTML. This way we can ask Frame object to render() itself into HTML and Frame would rely on other object ability to produce HTML and so forth.

[php]
echo $page->render();
[/php]

Inheritance: Widget customization

Now that we are incapsulating objects and not templates, it’s much easier to produce general-purpose widgets which can be part of the page. Such widgets can communicate with other components or the system or even with JavaScript on the browser-side. But in addition to the selection of the base widgets it’s now extremely easy to add new widgets by inheriting existing ones. If you need to build a signup form, you extend a regular form then tweak some behavior and properties.

This approach to the project will promote creation of new components and their re-use. By extending widgets (views) and not adding more functionality into them you can keep basic performance fast and avoid creating un-stable code.

3. Application Class

After models are defined and the UI components are defined too, there are the binding element to it. That’s the application class. Application is typically a class which is responsible for doing EVERYTHING. Of course application class uses composition to divert implementation towards other classes. The Data-Model and User Interface is something I have mentioned already. However there might be some other classes, which are typically called Libraries.

Inheritance: Multiple API classes.

Application must be a valid objects. It should be possible to create several instance of application object and also have ability to inherit applications. One application may be focused around serving one user segment and other application could be used for website administration purposes. Some API classes may be focused to be called from command-line or from scheduler. Other API may produce HTML, XML or JSON output.

Composition: Implementing Routing

A web application must respond to different URL formats and connect them to different classes. How the mapping is done is defined through “Routing”. For example http://example.com/testpage/ might be routed to a class called “page_testpage”. Ability to divert page-specific functionality into page classes is implementation of composition in Web Application front-controller.

The principle, however, is depending on the nature of API used. Command-line API typically do not require routing. Implementation of RESTfull API can be implemented by connecting to models directly.

Abstraction: Application Roles

There are many general web application categories such as Content Management Systems, eCommerce solutions, Ticket systems. Certainly you can implement a ticket-system. However – can you deliver such a system as an abstract class which could then be further extended?

Majority of MVC frameworks would not allow to do that. This is an incredibly powerful concept which can create a more flexible closed-source web software distribution, implement a stable multi-interface web system and even build one open-source project on top of another with a very tight integration and minimum overheads.

The Object-Oriented MVC

Here I have described my view of Object-Oriented MVC. Models fully capable of all object-oriented features. Views implemented as objects, not templates relying on object-oriented features. Finally the application which controls all of the process yet will not take away any of the advanced object-oriented techniques.

Object Oriented development offers a powerful concepts used by majority of developers word-wide. Web Frameworks usually restrict developers and take away power of Object-Oriented development. Only by combining and designing a web framework from the ground-up to permit and use full power of object-oriented programming maximum web development efficiency can be achieved. But not without some learning.

In his last blog post Janis is explaining his experience in migrating from 4.1 to 4.2 and all the necessary changes he had to make for one of his internal applications. Read the full blog on his blog: Migrating from Agile Toolkit 4.1.3 to 4.2 master branch. Notes.

Update: Today there is a new post looking into details how to best use list-type fields: dropdown, checkbox lists and radio buttons along with some screenshots.

Please help me encourage Janis in writing more blog posts. I would certainly be interested in hearing about the Content Management System he have built.

• MVC Frameworks help you organize flexible page structure
• Database frameworks (also called ORM) help you to organize flexible database access interface
• User Interface frameworks will help you make your user interface consistent
• Security frameworks will help you introduce security practices in your software.

Frameworks do that by introducing some assumptions, generalizing and also restricting developer to certain practices which framework authors approve of.

It’s fairly obvious to anyone than adding thousands of lines of code to your  ”Hello World” application wouldn’t make it execute faster. The regular argument of a framework authors is that they help development process to be faster and smoother on a larger projects. This often nothing to do with the speed of the code execution: “Developer time is more expensive than CPU time”.

What’s worse is that some frameworks impose standards which slow your code down. An example is a basic Acitve Record implementation, which brings your powerful SQL engine to the level of Simple DB to match the lowest common feature denominator across multiple database vendors. This along with a general overheads of the framework greatly contributes to the “slowness” of your project.

So how can framework contribute to performance of your project?

1. Make Fewer SQL Queries

When your frameworks sends request to a database and waits for result, it introduces latency. The PHP code waits for data to be parsed and executed by SQL and results to be returned. Because today SQL is still the most popular way then your job is to make as little queries as possible. If you could build your page with 10 SQL queries instead of 50, that would speed things up a lot.

Having less number of queries means each query would be more complex and would retrieve more data. Yet we don’t want to write the queries. Your database framework will have to have concept of expressions, joins and sub-selects to be able to off-load as much logic as possible into SQL engine. If number of queries on your page increases along with number of records displayed on the page, then you have produced non-scalable code. If your framework endorses this practice, then your framework is not scalable.

2. Selective render

When you look at the page such as this one you see many different areas with many different types of dynamic data. As it happens with dynamic web pages, some areas of your screen will refresh themselves. There are two approaches to do so

1. Build a separate JSON service for sending updates
2. Let framework handle the refresh

The (2) is very tempting, but average frameworks can’t perform web page refreshes graciously, that’s why many developers will have to duplicate some code and build a separate mechanism for JSON polling. This introduces inconsistence and bugs in the user interface. Many developers resort ONLY to JSON polling after the page is loaded increasing number of dynamic requests, making page unusable for search engines, building reliance on javascript and severely reducing total page load time.

For a scalable framework it’s an absolute necessity that the fragment of the page could be inexpensively re-rendered and reloaded with as little database traffic as possible and without additional coding from developer.

3. Parallelization

Suppose you have two different API services behind your web frontend. One service is built to return JSON with list of on-line users. The other service returns the JSON with recent post feed. Your frontend is written in your favorite PHP framework which makes use of templates or some page logic to determine if any of those page areas (or both) needs displaying.

JSON backend introduce some serious latency in your request, so it’s imperative that you your frontend PHP framework would execute both requests in parallel. Unfortunately most of the PHP frameworks want the data pretty much right away, when the page is rendered.

A scalable framework would be capable of identifying which widgets you need to display on your page and allow to execute both JSON requests first before collecting their output.

4. Overheads

Minimization of overheads is often the ONLY practice frameworks concern themselves with. This is where modularity is important. Let’s say the developer X have built a plug-in for WordPress. He decided to use super-fast framework and throughly benchmarked his add-on. Next comes the developer Y who have also built a plug-in for WordPress with a different framework but equally as fast. WordPress now requires to initialize two frameworks introducing huge overheads.

You might have been seen this in practice with a different set of frameworks, such as Zend and CodeIgniter. And then you integrate Facebook API which does not rely on any framework and makes you chew through thousands of line of PHP code which you don’t need anyway. And you also use ORM of your choice which has no dependencies yet re-implements tons of code.

A scalable framework should provide a unified set of modules and practices which are used by all of the plug-ins and add-ons to avoid any code duplication. In practice, decoupled frameworks are very bad for scalability. How many frameworks would provide add-on developer with a consistent API for building user interface?

5. Caching

After making all the possible mistakes in the book, frameworks do implement a caching strategy and brand themselves as a “High Performance”. The caching is not a cure and will introduce complications and limitations. Framework must be fast and scalable without any caching. Yet caching is important too. There are two types of caches: data cache and output cache.

The data cache helps developer to skip some database queries. If your implementation requires you to traverse models on each row (such as to determine URL for user thumbnails), then adding a memcache seems like a good-enough solution to the problem. This does help scalability a little, but essentially displays outdated data and can lead into many nasty problems.

Output caching helps you to cache either parts of the page or all the page completely. Many MVC frameworks wouldn’t have sufficient support for implementing output caching, because they are used to “echo” things out. As developer it becomes your burden to collect output into buffer and build logic for substitution and keeping cache up-to-date.

A scalable framework should handle both tasks flexibly and consistently. It should allow you to exchange your expensive data source (SQL, JSON) with a faster data source such as Memcache gracefully and transparently.

The framework should be equally good at letting you substitute whole areas of the page with a static alternatives without loosing functionality and requiring you to go under the hood of page routing or loosing any dynamic functionality on your page.

Conclusion

Many PHP frameworks sucks at properly understanding scalability principles. Look into a Silex framework and imagine that your project has 200 pages. On every page request, it will execute 200 matching pattern checks which are NOT based on regular expression. How is that scalable? Possibly another caching would help?

I am saddened by the state in which PHP frameworks are today and I believe there are many things which can be improved. I also believe that developers can be educated to have a good judgement and understanding of scalability.

There is huge potential for the next generation of PHP frameworks and I strongly encourage you to write and talk about it.

So should someone ask you, “what PHP framework is the fastest” — tell them that they are all slow, but some of them are “scalable”.

I have implemented all of the scalability principles described above in my framework: http://agiletoolkit.org/ but if you have a worthy alternative be sure to leave a comment with some clarifications.

What is Active Record?

Active Record pattern have been hugely popular due to adoption in Ruby on Rails and in other frameworks. (Active Record explained on wikipedia). Typically a class is generated based on the database table schema. All the fields of the database are reflected as properties of the model. Class has several constructors allowing to load model directly by ID or search for records. Only one record can be loaded at a time.

Why Classic Active Record is Broken?

No Testability

When the object is created, constructors does not accept reference to the database engine. Instead, they manage to pull it from some global namespace. That makes it very difficult to use Active Record with multiple database configuration or for testing.

Static methods / Constructors

A static method of a class which creates new instance of that class is called “constructor”. With Active Record there are multiple constructors present which can load record in a different ways. Number of constructors depend on the table structure in some implementation such as loadByCode() would only be applicable if “code” field exists.

Abusive properties

Potentially table can contain any field therefore model may have no “reserved” properties. That makes it virtually impossible to build any decent logic in the abstract model class.

Code generation = duplication

I am always amazed how same people preach about code re-use and how awful it is to copy-paste your code and then use code generators which effectively build thousands of lines of code for them. It might look good in your versioning system, but it is a very bad development practice.

One table = one class

While frameworks typically allow you to specify “parent class” in the YAML definition, in practice it is rarely used. We know that sometimes one table may contain different entity types, but Active Record implementations does not help in separating them into different classes.

Operations with multiple records

By definition Active Record object can hold one record only. If you need to iterate through multiple records you will end up creating and destroying objects, which introduces performance overheads.

Lack of conditioning

Active Record typically allow to load ANY record present in the table. It’s virtually impossible in many implementation of Active Record to restrict loading to certain types of data. That is, for example, implementation of soft-deletion. Implementing it often is a major effort.

Recipe for an Improved Active Record

Dependency Injection

There might be many variables model may require. Database driver object is one thing, but it might also require some other information. Specifying multiple objects for constructor is troublesome and inconsistent. My suggestion is to specify just one object which contains links to other necessary resources.

This object can be passed through the factory class. I have solved this problem having each object carry reference to such an object and whenever new object is created, it also receives that reference. That is a “api” class which can be used to reference database connection: $this->api->db. In practice, there may be multiple API classes, which makes it possible to inject dependency into any object.

Avoiding Constructors

If a model object could have a state where it is not associated with the database record, then the same object could be reused multiple times. If object is created first and then load() method is used to load new record from database then it can be subsequently called to add more records without the need to create model instance every time.

That means other methods can be used for loading data. As developer you may define new methods for data loading in your model classes which would override default methods.

Avoiding using properties for fields

In a database one field usually is a primary key. In most cases it’s called “id” but not always. If we want to introduce a property in our model, which will always refer to this primary key it may clash with non-primary key in a classic implementation of Active Record.

Fortunately PHP objects can also act as arrays. By using $model['name']=’John’ the requests can be easily routed and saved inside internal array without polluting all of model property namespace. The $model->id then can always contain value of record’s primary key. Other operations are possible through methods set() and get(). $model->set($array);

In this implementation other model properties can be used internally by model business logic without affecting any fields.

Avoid Code Generation

Now that we have freed up properties of the Model class, we no longer need code generation. In fact we can configure model fields through PHP and store more meta-information for each field.

Not only that, but adding fields dynamically is now possible by using addField method. Native PHP calls are faster then using PHP to parse other file format. Native PHP is also more powerful and can allow you to define fields much more flexibly.

One table = Many Classes

Now we can inherit our models and add additional models and change behavior for the newly created classes. No longer there is one-to-one relation. You can also remove some field definition in your sub-classes if the field is not used for that business case.

Now you can create models for “User”, “Admin” and “Moderator” based on the same code-base and the same database table. Moderator, however, would have more methods/actions and might as well be able to address more fields in a table.

Ability to extend Models is a powerful strategy. It allows you to leave your existing code intact, but add a new model for your new use-cases. This greatly helps you to reduce amount of testing you need to perform after structural change of your database.

Operation with multiple rows

Now that the active record object have a state with no data, it can also be used as iterator through multiple records. What is great about our implementation is that for each iteration we simply need to load data from PDO into our internal array.

But let’s also add ability for a model to have conditions, which are automatically applied when loading data. By using conditions you can narrow down the selection of a model. Some models can even have default conditions, such as “Admin” model would only iterate through records with is_admin=”Y”.

Full Conditioning

With the availability of transactions, we can now insert record into the database and then attempt to load it. If existing model conditions will let record to be loaded, then it was saved properly. Otherwise the newly saved model does not conform to the conditions and transaction must be canceled.

With this the model of “Admin” can no longer save non-admin users into the database. Full conditioning now gives us a great assurance that any widget, piece of code or any developer working with Admin model would have no way to bypass some of the restrictions.

What’s even more valuable in SaaS applications is the ability to introduce condition based on a currently-logged-in user. Removing the need to always check for record author and having it done automatically is a great piece of mind for the security focused people.

Agile Toolkit delivers Improved Active Record Approach and more

Model implementation in Agile Toolkit offers all of the solutions described above and much more including Joins, Expressions, Traversing and Behaviors. Found out more: http://agiletoolkit.org/doc/modeltable

Read More…

Or

Watch Presentation Slides…

This release is the result of a half year effort and is based on the feedback we have received on 4.1 version. It brings a lot of improvements and enhancements but the primary goal is to create a fully transparent and fully-documented underlying architecture and promote extensibility through add-ons. The syntax of a new version is compatible with 4.1 with some exceptions outlined in our upgrade notes.

If you are new to Agile Toolkit — follow to our interactive introduction.

New Data Model

Agile Toolkit have always had a powerful ORM manager, but the Active Record support was lacking. With 4.2 the base classes for Models and Relational Models are completely rewritten. The new structure is much more extensible and efficient. The syntax has been simplified considerably.

The Agile Toolkit have been well received in the small companies and with new release it now targets medium companies. Support for variety of relational databases now includes SQLite, PostgreSQL and can be extended very easily for any database supported by underlying PDO architecture. Agile Toolkit now also have a set of models which can be used with no-SQL databases, caches and transparent APIs.

Support for additional databases, techniques and protocols will be coming through add-ons.

New CSS Framework

Although the interface retains the similar look, the underlying CSS framework is now much more powerful. It’s been re-writen using lessCSS and is based on 12-column grid system. CSS classes are much easier to use and build your interface with. The alteration of the look can also be easily achieved, things like line radius, spacings, number of columns, footer behavior can be very easily changed through a very simple CSS configuration file.

New Add-on architecture

With the version of 4.2 minimum requirement for PHP is now 5.3. That enables the use of namespaces. With namespaces developing add-ons for Agile Toolkit is pure enjoyment. You will find a add-on developer guide on our documentation site, but what’s really important is that your add-on can rely on core user interface, other addons and contain both the library and UI elements. This makes it possible for addons to be quite awesome. Developer of payment gateway can now provide developers with the actual payment form instead of set of functions written in the low-level PHP.

Fully Documented

Agile Toolkit is coming from a closed-source environment. It was initially designed to be used within our web development company: Agile Technologies. We have open-sourced our Agile Toolkit in early 2011 but it is only now that the documentation have matured enough for wide adoption.

Become Agile!!

For all web developers either freelancers or working for the companies there are many reasons for using Agile Toolkit in your next project or in your company. If you need to look at some project examples, here are some example sites launched recently and built completely in Agile Toolkit. If your project has already started why not:

• develop Administrative Back-end using Agile Toolkit to save time.
• re-build your model structure on Agile Toolkit ORM and improve security.
• use Agile Toolkit for serving static pages and improve speed.

If you are in the need of custom web development using Agile Toolkit, consultancy, training or add-on development — our experienced team can offer you great solution (we are now based in London, UK)

We are hiring!

Are you looking to join a great team to join which values great software design and your artistic programming skills? Would you want to collaborate as a part-time freelancer or a full-time employee? We have some great employment offers and real projects you can join. Contact jobs at agiletoolkit.org.

https://groups.google.com/forum/#!forum/agile-toolkit-devel

You can learn a lot buy learning fundamentals of Agile Toolkit.  I’m starting from the very bottom layers of the framework, so join in quick!