1.0.2 is both a maintenance and novelties version. All known bugs have been fixed and there are a few library additions.
Concurrent to this version, we now also have "LogiThink", a proto-CMS or framework over framework, a set of libraries along with a backend used to solve the earlier content, authentication and ACL things from the start and providing an excellent base to start a new project.
LogiThink has its own website: http://www.logithink.net
Sunday, March 14, 2010
Wednesday, December 2, 2009
What Can Logikit::Framework Do For You?
Note: I know it's a bit long. Anytime you feel bored and want to see the answer for yourself instead, please get Logikit::Framework from http://framework.logikit.net
During an online discussion at LinkedIn, one of the members, Didier Peereboom Voller, in his comment used an anology I like a lot:
"You don't sell a car by pointing out that its brakes work. You MIGHT sell a car if you point out that its brakes work better then anyone else's. "
Everybody drives a car but few of them try to design a brand new one. However, most of people have a "dream car" in mind, and in most cases some of people's dreams are also common. Some of us look for a much more confortable car, while some others give the first priority to the security and some people don't care anything else but the speed of the car. Of course, you can find a faster, a more secure, cheaper, less fuel-consuming or a more confortable car, but when you look for all of them in one place, that's where the dreams begin.
Then, can't anyone find out there, an affordable car that fits his/her needs, at least by 80-90%? Yes. Actually, that's the common situation. Most of people drive a car -a good or bad one, but a working one at least- and most of them again tend to "upgrade" his/her car from the very first opportunity. That's human nature. If it wasn't this way, we would still be riding horses. And given the opportunity, most of us would want to have "something better".
As far as I can tell, there are four items you have to possess to create something both new and usable:
1- Idea: You have to know exactly in advance, what you'll be doing.
2- Reason: You have to know why you are doing it. Without a reason acceptable for the public, the novelty you have made will remain in your hobby room.
3- Time: Everything takes time. Much or less. But you have to have it enough to put your plans in life.
4- Knowledge: Even if you already know what exactly you will produce, you also must know how to do it. Also, you have to know how to afford the development costs for your project.
If you are a team, a company, a faculty -name it- possessing those four items above in the mean time, you can do virtually anything.
But for a single person, it's hard to have all four in the mean time. If you are a student, probably you have time and ideas -and perhaps also the reason- but not the knowledge for sure (otherwise, you wouldn't remain a student, right?) If for you, school days are long gone, then probably you have an idea, a reason and the knowledge, but no time. In the latter case, you could put your time and create your dream car... and would you give it away?
Fortunately, in software business, combining the four items, you may have your dream software, can use it, improve it everyday, change the parts you don't like, add new things, and can also give it away so that other people can also benefit.
So, let's come back to Logikit::Framework (LF) and see how its breaks work better than anyone else's and answer the question "can it fly?".
"Economics is the science of satisfying unlimited demands with limited resources". - Peter Schiff
Dreaming is good, however when it will come to plan to put the dream into life, one of the first things to be figured out is the need to favor some features against some others. When designing a car, if you want a faster one, this will probably mean to weaken the security, or to consume more fuel or both. One needs to be very meticulous using his choices, from the "paper and pencil" phase to the test drives. Below is how I will "sell" my dream:
- Not a superiority over other frameworks, but this needs to be mentioned first: LF is published completely free of charge, under MIT license, the most libertarian one I came across. What I'm telling here is "I realized my dream. If your dream is different than mine and if you want, you can take and do whatever you want out of it. It can't fly yet, but if you ever come up with a 'wings' library, who knows?"
- In my opinion, to have a good project architecture is one of the key reasons to use a framework. LF is very well structured and offers everything a programmer may need to keep the project clean and maintainable, but still flexible and in most cases, does not force people to follow the way that is originally advised.
Thanks to LF structure, in a case you will need to add a field to a form, for example, in a project you deployed a year ago, it will be a matter of seconds to do it, cause you will know exactly where the form file is. Adding the field and setting the validation rules will be a real small job, to add another element to the form array.
Like most of modern frameworks, LF uses a MVC (Model-View-Controller) pattern, in most cases associated with a form and a validator. So the pattern might be called MVC+FV.
Every controller may have it's own model and it's own view, form and validator folders and every action (function in the controller class) may have it's own form and validator, and must have it's own view. The particular views are included in a higher structure called a "template" (a single html/php file in fact) during the software lifecycle.
The forms are defined as an array, however the array elements can be used free-style within a view and each of them can be placed anywhere needed in the layout design.
The validators can "talk" directly to the forms, uniforming and easing the validation handling.
- Although it's never obligatory to use it, LF comes with a code generator that can create the controller, the model, the views, the forms and the validators, starting from a database table. The resulting code will permit to do CRUD (create, read, update, delete) work along with pagination and sorting, and best of all, it's fully Ajaxified, and the design is still flexible, mainly CSS based, so the generated layout also can be altered to fit any design.
For me, this is also an important feature to let people choose for themselves and use the generator if they need it, when they need it. In some frameworks, to use a generator is almost obligatory to start a project, while some others totally reject to use it. Using LF, a programmer can use it anytime he/she will need it, not only at the beginning of a project, or can forget it for good.
- LF's model system is based on PDO, practically permitting the use of a lot of DMBS's (MySQL, PostgreSQL, Oracle, SQLite and so on) with the same code, providing a database abstraction layer. To use the model structure is encouraged and the only default way to interact with the database is the model. Of course, it's still not obligatory and one may create another object extending the model and use it within controller, but I think that will be against one of the major arguments of a MVC view. However to use such an object may be needed especially with the external libraries, and a solution for the purpose is also provided. The structure of the database class can be defined as a "lightweight version of active record pattern", leaving the decision to write raw queries or use predefined methods, to the programmer. Following existing LF standards, programmer will have very clean and usable models, and as always, the final choice is him or herselves.
- LF's library structure is exactly as it needs to be: Any external library could be just copied into the library folder, can be loaded and used within the controller in no time. If the library has dependencies, those dependencies also can be simply included or loaded within the library. An instance of the controller object is always available in hand so libraries have total access to controller capabilities.
- LF also offers built-in libraries. At this point, it's hard to say the libraries are enough to solve everything, however LF is not planned to be a simple MVC architecture, but it aims to be "self-sufficent" so that a programmer may be able to use only LF to solve 99% of the problems. With the first version (1.0.0), we had only a couple of libraries. As of version 1.0.1, image processing, ftp and email libraries have been introduced. Authentication, ACL (access control list), encryption, file compression, payment (paypal, 2CO and authorize.net), calendaring and PDF libraries are on the way. I can't promise for a date or a release order for them, as I also need to make my living. I'm also always open to any contributions also here, as I am for the other parts of the project. Until this time, I didn't use any 3rd party php code, but I'd appreciate it if some of you would like to participate and share his/her works, so we can speed up the things.
- Some helpers are "auto-auto-loaded" and are also used within the LF core. Say, if you need a "preformatted" print_r() function, it's already there. If you need a "flash message" on the actual page or the next page, it's also there. Thinking how those "small issues" let us lose some important time when it comes to the total time cost, the benefits of this could be better understood. As all independent functions are defined in a global scope, they are accessible from troughout your project.
- LF is packed with JQuery along with an ajax and messages helper using it, turning the ajax works and everyday's Javascript issues into a piece of cake.
- LF provides a URL-rewrite by default, based on Apache mod-rewrite, with an .htaccess file. It is also smart enough to understand if you are using a URI structure in a form "http://yoursite/yourLfInstallation/index.php/yourController/yourAction" or in a form "http://yoursite/yourLfInstallation/yourController/yourAction".
- Unlike most of other frameworks, LF can have an unlimited deepness with controllers.
While you may only have a maximum of two deepness with most of them (as in "http://yoursite/yourLfInstallation/index.php/yourSubfolder/yourController/yourAction"), LF can have something like "http://yoursite/yourLfInstallation/index.php/yourSubfolder1/yourSubfolder2/.../yourSubfolderN/yourController/yourAction/yourParams", and it will detect which part of the URI corresponds to your controller. I know, many projects won't need such a feature, but it's useful if you are a meticulous programmer who looks after a well-organized software structure, even with 20-30 controllers. And if you are dealing with a project with 1000 controllers, there it will become a required feature.
- This should not be considered a superiority, but: LF is well documented. Of course this is a must for every piece of software, however I must admit I have seen only two or three other framework docs comparable to LF docs.
- Besides all of the above, LF is designed to be remarkably, extremely fast. You may check the benchmark results mentioned in another post on this blog or better, can repeat them for yourself and compare with some other frameworks.
After having wrote that much, I can really understand how hard is car dealer's work, but if you were patient to read it to the bottom, I guess I managed to sell my car.
During an online discussion at LinkedIn, one of the members, Didier Peereboom Voller, in his comment used an anology I like a lot:
"You don't sell a car by pointing out that its brakes work. You MIGHT sell a car if you point out that its brakes work better then anyone else's. "
Everybody drives a car but few of them try to design a brand new one. However, most of people have a "dream car" in mind, and in most cases some of people's dreams are also common. Some of us look for a much more confortable car, while some others give the first priority to the security and some people don't care anything else but the speed of the car. Of course, you can find a faster, a more secure, cheaper, less fuel-consuming or a more confortable car, but when you look for all of them in one place, that's where the dreams begin.
Then, can't anyone find out there, an affordable car that fits his/her needs, at least by 80-90%? Yes. Actually, that's the common situation. Most of people drive a car -a good or bad one, but a working one at least- and most of them again tend to "upgrade" his/her car from the very first opportunity. That's human nature. If it wasn't this way, we would still be riding horses. And given the opportunity, most of us would want to have "something better".
As far as I can tell, there are four items you have to possess to create something both new and usable:
1- Idea: You have to know exactly in advance, what you'll be doing.
2- Reason: You have to know why you are doing it. Without a reason acceptable for the public, the novelty you have made will remain in your hobby room.
3- Time: Everything takes time. Much or less. But you have to have it enough to put your plans in life.
4- Knowledge: Even if you already know what exactly you will produce, you also must know how to do it. Also, you have to know how to afford the development costs for your project.
If you are a team, a company, a faculty -name it- possessing those four items above in the mean time, you can do virtually anything.
But for a single person, it's hard to have all four in the mean time. If you are a student, probably you have time and ideas -and perhaps also the reason- but not the knowledge for sure (otherwise, you wouldn't remain a student, right?) If for you, school days are long gone, then probably you have an idea, a reason and the knowledge, but no time. In the latter case, you could put your time and create your dream car... and would you give it away?
Fortunately, in software business, combining the four items, you may have your dream software, can use it, improve it everyday, change the parts you don't like, add new things, and can also give it away so that other people can also benefit.
So, let's come back to Logikit::Framework (LF) and see how its breaks work better than anyone else's and answer the question "can it fly?".
"Economics is the science of satisfying unlimited demands with limited resources". - Peter Schiff
Dreaming is good, however when it will come to plan to put the dream into life, one of the first things to be figured out is the need to favor some features against some others. When designing a car, if you want a faster one, this will probably mean to weaken the security, or to consume more fuel or both. One needs to be very meticulous using his choices, from the "paper and pencil" phase to the test drives. Below is how I will "sell" my dream:
- Not a superiority over other frameworks, but this needs to be mentioned first: LF is published completely free of charge, under MIT license, the most libertarian one I came across. What I'm telling here is "I realized my dream. If your dream is different than mine and if you want, you can take and do whatever you want out of it. It can't fly yet, but if you ever come up with a 'wings' library, who knows?"
- In my opinion, to have a good project architecture is one of the key reasons to use a framework. LF is very well structured and offers everything a programmer may need to keep the project clean and maintainable, but still flexible and in most cases, does not force people to follow the way that is originally advised.
Thanks to LF structure, in a case you will need to add a field to a form, for example, in a project you deployed a year ago, it will be a matter of seconds to do it, cause you will know exactly where the form file is. Adding the field and setting the validation rules will be a real small job, to add another element to the form array.
Like most of modern frameworks, LF uses a MVC (Model-View-Controller) pattern, in most cases associated with a form and a validator. So the pattern might be called MVC+FV.
Every controller may have it's own model and it's own view, form and validator folders and every action (function in the controller class) may have it's own form and validator, and must have it's own view. The particular views are included in a higher structure called a "template" (a single html/php file in fact) during the software lifecycle.
The forms are defined as an array, however the array elements can be used free-style within a view and each of them can be placed anywhere needed in the layout design.
The validators can "talk" directly to the forms, uniforming and easing the validation handling.
- Although it's never obligatory to use it, LF comes with a code generator that can create the controller, the model, the views, the forms and the validators, starting from a database table. The resulting code will permit to do CRUD (create, read, update, delete) work along with pagination and sorting, and best of all, it's fully Ajaxified, and the design is still flexible, mainly CSS based, so the generated layout also can be altered to fit any design.
For me, this is also an important feature to let people choose for themselves and use the generator if they need it, when they need it. In some frameworks, to use a generator is almost obligatory to start a project, while some others totally reject to use it. Using LF, a programmer can use it anytime he/she will need it, not only at the beginning of a project, or can forget it for good.
- LF's model system is based on PDO, practically permitting the use of a lot of DMBS's (MySQL, PostgreSQL, Oracle, SQLite and so on) with the same code, providing a database abstraction layer. To use the model structure is encouraged and the only default way to interact with the database is the model. Of course, it's still not obligatory and one may create another object extending the model and use it within controller, but I think that will be against one of the major arguments of a MVC view. However to use such an object may be needed especially with the external libraries, and a solution for the purpose is also provided. The structure of the database class can be defined as a "lightweight version of active record pattern", leaving the decision to write raw queries or use predefined methods, to the programmer. Following existing LF standards, programmer will have very clean and usable models, and as always, the final choice is him or herselves.
- LF's library structure is exactly as it needs to be: Any external library could be just copied into the library folder, can be loaded and used within the controller in no time. If the library has dependencies, those dependencies also can be simply included or loaded within the library. An instance of the controller object is always available in hand so libraries have total access to controller capabilities.
- LF also offers built-in libraries. At this point, it's hard to say the libraries are enough to solve everything, however LF is not planned to be a simple MVC architecture, but it aims to be "self-sufficent" so that a programmer may be able to use only LF to solve 99% of the problems. With the first version (1.0.0), we had only a couple of libraries. As of version 1.0.1, image processing, ftp and email libraries have been introduced. Authentication, ACL (access control list), encryption, file compression, payment (paypal, 2CO and authorize.net), calendaring and PDF libraries are on the way. I can't promise for a date or a release order for them, as I also need to make my living. I'm also always open to any contributions also here, as I am for the other parts of the project. Until this time, I didn't use any 3rd party php code, but I'd appreciate it if some of you would like to participate and share his/her works, so we can speed up the things.
- Some helpers are "auto-auto-loaded" and are also used within the LF core. Say, if you need a "preformatted" print_r() function, it's already there. If you need a "flash message" on the actual page or the next page, it's also there. Thinking how those "small issues" let us lose some important time when it comes to the total time cost, the benefits of this could be better understood. As all independent functions are defined in a global scope, they are accessible from troughout your project.
- LF is packed with JQuery along with an ajax and messages helper using it, turning the ajax works and everyday's Javascript issues into a piece of cake.
- LF provides a URL-rewrite by default, based on Apache mod-rewrite, with an .htaccess file. It is also smart enough to understand if you are using a URI structure in a form "http://yoursite/yourLfInstallation/index.php/yourController/yourAction" or in a form "http://yoursite/yourLfInstallation/yourController/yourAction".
- Unlike most of other frameworks, LF can have an unlimited deepness with controllers.
While you may only have a maximum of two deepness with most of them (as in "http://yoursite/yourLfInstallation/index.php/yourSubfolder/yourController/yourAction"), LF can have something like "http://yoursite/yourLfInstallation/index.php/yourSubfolder1/yourSubfolder2/.../yourSubfolderN/yourController/yourAction/yourParams", and it will detect which part of the URI corresponds to your controller. I know, many projects won't need such a feature, but it's useful if you are a meticulous programmer who looks after a well-organized software structure, even with 20-30 controllers. And if you are dealing with a project with 1000 controllers, there it will become a required feature.
- This should not be considered a superiority, but: LF is well documented. Of course this is a must for every piece of software, however I must admit I have seen only two or three other framework docs comparable to LF docs.
- Besides all of the above, LF is designed to be remarkably, extremely fast. You may check the benchmark results mentioned in another post on this blog or better, can repeat them for yourself and compare with some other frameworks.
After having wrote that much, I can really understand how hard is car dealer's work, but if you were patient to read it to the bottom, I guess I managed to sell my car.
Monday, November 30, 2009
Logikit Framework 1.0.1 released
This release was intended to be a "small changes package", and was scheduled for a bit later. Although the first version was released only about a month ago, the download stats were way beyond than I expected and there are already some people I know, using it in their own projects, so I decided to release an earlier version with a couple of additions to the existing features and some changes, along with three new libraries: Image manipulation, ftp and email classes.
Don't panic when you will see the size of the distribution file is lowered, as it is highly optimized now. You can get it at http://framework.logikit.net
This month (Dec 2009) I will start a relatively big project to be built 100% on Logikit::Framework, which will be an acid test, as I will need to implement almost every feature there, also will develop new libraries. All those will make part of version 1.0.2 which will eventually be released right after the project completion.
Well, enjoy it!
Don't panic when you will see the size of the distribution file is lowered, as it is highly optimized now. You can get it at http://framework.logikit.net
This month (Dec 2009) I will start a relatively big project to be built 100% on Logikit::Framework, which will be an acid test, as I will need to implement almost every feature there, also will develop new libraries. All those will make part of version 1.0.2 which will eventually be released right after the project completion.
Well, enjoy it!
Wednesday, November 4, 2009
Logikit Framework Benchmarks
Finally I had time to complete the "Hello World!" benchmarking for Logikit:.Framework.
You will find detailed results from Apache Bench. I also performed some good tests to compare it with a couple of frameworks, but I want to leave the comparison to others and will just publish the results.
Those tests are still so far from having a scientific value, but at least would give you an idea.
What I have to say as an "a-posteriori" opinion is that they are just close to a very native PHP "Hello World!"
SYSTEM:
CPU: 2 X Intel(R) Pentium(R) T3400 2.16 GHZ
Memory: 2 GB
OS: Ubuntu 9.10 (Karmic)
TEST 1
Concurrency Level: 1
Time taken for tests: 60.000 seconds
Complete requests: 9845
Failed requests: 0
Write errors: 0
Total transferred: 4164435 bytes
HTML transferred: 118140 bytes
Requests per second: 164.08 [#/sec] (mean)
Time per request: 6.094 [ms] (mean)
Time per request: 6.094 [ms] (mean, across all concurrent requests)
Transfer rate: 67.78 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 1.9 5 51
Waiting: 5 6 1.9 5 51
Total: 5 6 1.9 5 52
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 10
95% 10
98% 10
99% 11
100% 52 (longest request)
TEST 2
Concurrency Level: 1
Time taken for tests: 60.002 seconds
Complete requests: 9746
Failed requests: 0
Write errors: 0
Total transferred: 4122558 bytes
HTML transferred: 116952 bytes
Requests per second: 162.43 [#/sec] (mean)
Time per request: 6.157 [ms] (mean)
Time per request: 6.157 [ms] (mean, across all concurrent requests)
Transfer rate: 67.10 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 5.9 5 402
Waiting: 5 6 5.2 5 402
Total: 5 6 5.9 5 402
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 9
95% 10
98% 10
99% 10
100% 402 (longest request)
TEST 3
Concurrency Level: 1
Time taken for tests: 60.001 seconds
Complete requests: 9834
Failed requests: 0
Write errors: 0
Total transferred: 4159782 bytes
HTML transferred: 118008 bytes
Requests per second: 163.90 [#/sec] (mean)
Time per request: 6.101 [ms] (mean)
Time per request: 6.101 [ms] (mean, across all concurrent requests)
Transfer rate: 67.70 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 2.3 5 77
Waiting: 5 6 2.1 5 77
Total: 5 6 2.3 5 77
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 9
95% 10
98% 10
99% 11
100% 77 (longest request)
TEST 4
Concurrency Level: 1
Time taken for tests: 60.003 seconds
Complete requests: 9958
Failed requests: 0
Write errors: 0
Total transferred: 4212234 bytes
HTML transferred: 119496 bytes
Requests per second: 165.96 [#/sec] (mean)
Time per request: 6.026 [ms] (mean)
Time per request: 6.026 [ms] (mean, across all concurrent requests)
Transfer rate: 68.55 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 4.0 5 262
Waiting: 4 6 3.8 5 262
Total: 5 6 4.0 5 262
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 6
90% 8
95% 10
98% 10
99% 10
100% 262 (longest request)
TEST 5
Concurrency Level: 1
Time taken for tests: 60.003 seconds
Complete requests: 9769
Failed requests: 0
Write errors: 0
Total transferred: 4132287 bytes
HTML transferred: 117228 bytes
Requests per second: 162.81 [#/sec] (mean)
Time per request: 6.142 [ms] (mean)
Time per request: 6.142 [ms] (mean, across all concurrent requests)
Transfer rate: 67.25 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 3.0 5 140
Waiting: 5 6 2.7 5 140
Total: 5 6 3.0 5 141
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 9
95% 10
98% 10
99% 11
100% 141 (longest request)
163.83
You will find detailed results from Apache Bench. I also performed some good tests to compare it with a couple of frameworks, but I want to leave the comparison to others and will just publish the results.
Those tests are still so far from having a scientific value, but at least would give you an idea.
What I have to say as an "a-posteriori" opinion is that they are just close to a very native PHP "Hello World!"
SYSTEM:
CPU: 2 X Intel(R) Pentium(R) T3400 2.16 GHZ
Memory: 2 GB
OS: Ubuntu 9.10 (Karmic)
TEST 1
Concurrency Level: 1
Time taken for tests: 60.000 seconds
Complete requests: 9845
Failed requests: 0
Write errors: 0
Total transferred: 4164435 bytes
HTML transferred: 118140 bytes
Requests per second: 164.08 [#/sec] (mean)
Time per request: 6.094 [ms] (mean)
Time per request: 6.094 [ms] (mean, across all concurrent requests)
Transfer rate: 67.78 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 1.9 5 51
Waiting: 5 6 1.9 5 51
Total: 5 6 1.9 5 52
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 10
95% 10
98% 10
99% 11
100% 52 (longest request)
TEST 2
Concurrency Level: 1
Time taken for tests: 60.002 seconds
Complete requests: 9746
Failed requests: 0
Write errors: 0
Total transferred: 4122558 bytes
HTML transferred: 116952 bytes
Requests per second: 162.43 [#/sec] (mean)
Time per request: 6.157 [ms] (mean)
Time per request: 6.157 [ms] (mean, across all concurrent requests)
Transfer rate: 67.10 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 5.9 5 402
Waiting: 5 6 5.2 5 402
Total: 5 6 5.9 5 402
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 9
95% 10
98% 10
99% 10
100% 402 (longest request)
TEST 3
Concurrency Level: 1
Time taken for tests: 60.001 seconds
Complete requests: 9834
Failed requests: 0
Write errors: 0
Total transferred: 4159782 bytes
HTML transferred: 118008 bytes
Requests per second: 163.90 [#/sec] (mean)
Time per request: 6.101 [ms] (mean)
Time per request: 6.101 [ms] (mean, across all concurrent requests)
Transfer rate: 67.70 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 2.3 5 77
Waiting: 5 6 2.1 5 77
Total: 5 6 2.3 5 77
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 9
95% 10
98% 10
99% 11
100% 77 (longest request)
TEST 4
Concurrency Level: 1
Time taken for tests: 60.003 seconds
Complete requests: 9958
Failed requests: 0
Write errors: 0
Total transferred: 4212234 bytes
HTML transferred: 119496 bytes
Requests per second: 165.96 [#/sec] (mean)
Time per request: 6.026 [ms] (mean)
Time per request: 6.026 [ms] (mean, across all concurrent requests)
Transfer rate: 68.55 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 4.0 5 262
Waiting: 4 6 3.8 5 262
Total: 5 6 4.0 5 262
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 6
90% 8
95% 10
98% 10
99% 10
100% 262 (longest request)
TEST 5
Concurrency Level: 1
Time taken for tests: 60.003 seconds
Complete requests: 9769
Failed requests: 0
Write errors: 0
Total transferred: 4132287 bytes
HTML transferred: 117228 bytes
Requests per second: 162.81 [#/sec] (mean)
Time per request: 6.142 [ms] (mean)
Time per request: 6.142 [ms] (mean, across all concurrent requests)
Transfer rate: 67.25 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 5 6 3.0 5 140
Waiting: 5 6 2.7 5 140
Total: 5 6 3.0 5 141
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 6
80% 7
90% 9
95% 10
98% 10
99% 11
100% 141 (longest request)
163.83
Monday, November 2, 2009
Cons and Pros of a new PHP 5 framework - Why another one?
Though we are good old friends with PHP since PHP 3 days and I made my living on it, I always considered myself as a student rather than an expert, and always enjoyed to learn from other people's experiences. When I faced a problem, I found more logical to look for the footsteps of others before trying to re-invent the wheel. This helped me develop a point of view on where to use the existing ones, where to manipulate them and where to design the wheel from scratch; "how to think" for short.
Troughout my programming life, I've encountered several problems, worked on various projects both by myself or as a member of a team, and besides my own experiences, I had the chance to hear how other programmers approached to a spesific programming or logical problem, even most of them were daily and recurring ones, especially for themselves!
I strongly guess the first application framework started as a result of the same feeling: We do some common things in every new project, and most of us use some re-usable code and write wrappers around them if we are experienced enough, but to put them as a whole is always there as a new problem with each new project, as the scope of the new project is seldom the same as the previous one, and if your last project took -say- eight months, if you are a person who does not remember everything he has done in his whole life like me, this would also mean another learning curve, even if the teacher is yourself and the curve is relatively short... and needless...
Having past this point, some years ago, not very long after PHP 5 started, I started to look for a good basis which would be good for projects at any scope, and saw with great happiness I wasn't alone with most of my thoughts, and with great vision, people already started to code some frameworks for PHP 5 to take advantage of the object-oriented features to have a more re-usable code, but helas, it was still PHP 4 days for anyone else. If I'd use their frameworks without any objection, I still needed to look for the server capabilities first, and most of I coded, I needed to deploy, so I needed to go with my own solutions for some time more.
Then, some day I heard of Ruby On Rails and the MVC pattern. That sounded logical, but I couldn't take another fight to use Ruby and advocate it, and not so long after, I met CodeIgniter. I feel I have almost the same opinion on it since my first day: Man, it was something usable! It also worked with PHP 4 and let the programmer keep everything in shape. Most important: not too hard to dive in. This was definitely something new for me, and as CI is one of the most popular frameworks nowadays, I guess it's valid for so many other programmers.
I believe CI was a kicking-point for a couple of other frameworks as well, however by time I felt it lacked some many important features for me as the life continued on, while those points might be considered as "features" for some others. Just to name a few one, they had good form handling and validation features, but not quite separated from the rest of your programming logic, as they wanted to validate any data by principal, not only forms, whereas in the real life, most of the validation tasks are for the data coming from the forms. Another one was that they didn't want to use code generators, most probably as they wanted to leave the coder free with their decisions, or perhaps for another reason. But for me, it's an advangate rather than a disadvantage to use them, as long as it's left to your choice.
So to name them as well, I also met Symphony which was an answer to use a code generator and also Cake. Cake was strict, Symphony was better, and lastly Zend.
I just want to ask a simple and honest question and close the Zend case: If it wasn't named "Zend", really how many people would use it?
So within time, I came to a point where I was pretty sure about what I really needed from a framework as a programmer:
- Documentation (Without it, I can't understand it's really not rocket science.)
- Performance. (It is of the essence especially when you deal with sites with high traffic.)
- Usability. (We are humans. We will use it, not robots.)
- Separation of logics: A required MVC implementation to force me write good code. I'm a very lazy person and if I have the db connection within the controller, I'd tend to use it.
- In addition but not required: Separation of form and validation logics: My forms and my validators "need to know about each other". If I will "define" a form, my validator must also have capabilities to use those definitions, but this must be in a very libertarian way: To do that, I must not define also the layout of the form within my general wiew, but let people use my form components however they wish within their design, even they can be automatically generated.
- As a consequence of the previous: The programmer must not be forced to use any template engine, but still preserve the rights to take advantage of a good caching mechanism.
-Ajax Capabilities: A PHP programmer's almost dead without Ajax. He needs a hand.
- A code generator with all ajaxified good pagination, sorting and validation capabilities.
- A good library for any task (That I don't have with 1.0 release)
Those are mine standards that need to come out of the box, and I could hardly see them together within another framework . I believe I have achieved most of the points above with the earlier 1.0 release and all by myself and if you, the programmer reading those lines will contribute, we may have much much more.
By the way, the address for the framework is http://framework.logikit.net
Troughout my programming life, I've encountered several problems, worked on various projects both by myself or as a member of a team, and besides my own experiences, I had the chance to hear how other programmers approached to a spesific programming or logical problem, even most of them were daily and recurring ones, especially for themselves!
I strongly guess the first application framework started as a result of the same feeling: We do some common things in every new project, and most of us use some re-usable code and write wrappers around them if we are experienced enough, but to put them as a whole is always there as a new problem with each new project, as the scope of the new project is seldom the same as the previous one, and if your last project took -say- eight months, if you are a person who does not remember everything he has done in his whole life like me, this would also mean another learning curve, even if the teacher is yourself and the curve is relatively short... and needless...
Having past this point, some years ago, not very long after PHP 5 started, I started to look for a good basis which would be good for projects at any scope, and saw with great happiness I wasn't alone with most of my thoughts, and with great vision, people already started to code some frameworks for PHP 5 to take advantage of the object-oriented features to have a more re-usable code, but helas, it was still PHP 4 days for anyone else. If I'd use their frameworks without any objection, I still needed to look for the server capabilities first, and most of I coded, I needed to deploy, so I needed to go with my own solutions for some time more.
Then, some day I heard of Ruby On Rails and the MVC pattern. That sounded logical, but I couldn't take another fight to use Ruby and advocate it, and not so long after, I met CodeIgniter. I feel I have almost the same opinion on it since my first day: Man, it was something usable! It also worked with PHP 4 and let the programmer keep everything in shape. Most important: not too hard to dive in. This was definitely something new for me, and as CI is one of the most popular frameworks nowadays, I guess it's valid for so many other programmers.
I believe CI was a kicking-point for a couple of other frameworks as well, however by time I felt it lacked some many important features for me as the life continued on, while those points might be considered as "features" for some others. Just to name a few one, they had good form handling and validation features, but not quite separated from the rest of your programming logic, as they wanted to validate any data by principal, not only forms, whereas in the real life, most of the validation tasks are for the data coming from the forms. Another one was that they didn't want to use code generators, most probably as they wanted to leave the coder free with their decisions, or perhaps for another reason. But for me, it's an advangate rather than a disadvantage to use them, as long as it's left to your choice.
So to name them as well, I also met Symphony which was an answer to use a code generator and also Cake. Cake was strict, Symphony was better, and lastly Zend.
I just want to ask a simple and honest question and close the Zend case: If it wasn't named "Zend", really how many people would use it?
So within time, I came to a point where I was pretty sure about what I really needed from a framework as a programmer:
- Documentation (Without it, I can't understand it's really not rocket science.)
- Performance. (It is of the essence especially when you deal with sites with high traffic.)
- Usability. (We are humans. We will use it, not robots.)
- Separation of logics: A required MVC implementation to force me write good code. I'm a very lazy person and if I have the db connection within the controller, I'd tend to use it.
- In addition but not required: Separation of form and validation logics: My forms and my validators "need to know about each other". If I will "define" a form, my validator must also have capabilities to use those definitions, but this must be in a very libertarian way: To do that, I must not define also the layout of the form within my general wiew, but let people use my form components however they wish within their design, even they can be automatically generated.
- As a consequence of the previous: The programmer must not be forced to use any template engine, but still preserve the rights to take advantage of a good caching mechanism.
-Ajax Capabilities: A PHP programmer's almost dead without Ajax. He needs a hand.
- A code generator with all ajaxified good pagination, sorting and validation capabilities.
- A good library for any task (That I don't have with 1.0 release)
Those are mine standards that need to come out of the box, and I could hardly see them together within another framework . I believe I have achieved most of the points above with the earlier 1.0 release and all by myself and if you, the programmer reading those lines will contribute, we may have much much more.
By the way, the address for the framework is http://framework.logikit.net
Subscribe to:
Posts (Atom)
Posts
