Entry tags:
My DW development plans
Since I started to play with the DW codebase I have been mostly making changes on the test suit and did some code cleanup. Let me write down my plans for the coming weeks:
Many tests in t/ fail was the first bug I opened. Since then we checked all the test scripts. Most of them now pass correctly and the others were set to be skipped. Once that was done I noticed that there are tons of warnings when running a test with -w. More specifically there were 3047 warnings. With the latest patch submitted we are down at 30 warnings.
In testing DW I described a bit how the tests should be used and how to understand them and how to write more.
Lots of thanks to
afuna for reviewing and committing my patches.
My further plans are as follows:
Though I am not sure I am up to the last task as that would require deep knowledge of the codebase, the history and all the features of DW.
In code refactoring I outlined some of the low hanging fruits.
1760 remove $LJ::HOME is a more specific version of this. After some discussion with
mark we agreed
that the best would be for now to eliminate both $LJ::HOME and $ENV{LJHOME} where possible and use the new DW->home instead. That method call currently returns either of the above variables but later can return some totally different - configuration based - value.
I'll also want to get rid of "use lib" calls in most of the places - they only need to be present in entry points of the application which should be few.
Today the accepted standard in the perl world is to have every "package" in a single file that corresponds to its name so package LJ::Something should be in LJ/Something.pm. So I'll split up or unite and rename the files as necessary to get to that point. That will also make it much easier for us to locate the implementation of a class. (Later we can rename everything to DW::* or move there only cleaned up code.)
There are many files with "package LJ;" in them. Apparently they are all part of a huge LJ
package but after some staring at the code gave the feeling that many of them are actually independent so we might want to move them to LJ::Some::Other::Name. That will require deeper understanding of the code and the application.
Eliminate Class::Autouse is the last one
of the currently assigned bug. Class::Autouse might save memory and improve speed in a command line environment or for a CGI script but in a persistent environment such as mod_perl (or FastCGI) it does not have added value. So I'm going to get rid of all the 90 or so occurrences.
Many tests in t/ fail was the first bug I opened. Since then we checked all the test scripts. Most of them now pass correctly and the others were set to be skipped. Once that was done I noticed that there are tons of warnings when running a test with -w. More specifically there were 3047 warnings. With the latest patch submitted we are down at 30 warnings.
In testing DW I described a bit how the tests should be used and how to understand them and how to write more.
Lots of thanks to
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
My further plans are as follows:
- eliminate all the remaining warnings
- enable -w in all the test scripts
- enable Test::NoWarnings in all the test scripts (probably via a new common testing module)
so any new warning will generate a test failure keeping us a lot more aware of them - make sure every test has a "plan"
- Fix tests that are currently skipped
Though I am not sure I am up to the last task as that would require deep knowledge of the codebase, the history and all the features of DW.
In code refactoring I outlined some of the low hanging fruits.
1760 remove $LJ::HOME is a more specific version of this. After some discussion with
![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png)
that the best would be for now to eliminate both $LJ::HOME and $ENV{LJHOME} where possible and use the new DW->home instead. That method call currently returns either of the above variables but later can return some totally different - configuration based - value.
I'll also want to get rid of "use lib" calls in most of the places - they only need to be present in entry points of the application which should be few.
Today the accepted standard in the perl world is to have every "package" in a single file that corresponds to its name so package LJ::Something should be in LJ/Something.pm. So I'll split up or unite and rename the files as necessary to get to that point. That will also make it much easier for us to locate the implementation of a class. (Later we can rename everything to DW::* or move there only cleaned up code.)
There are many files with "package LJ;" in them. Apparently they are all part of a huge LJ
package but after some staring at the code gave the feeling that many of them are actually independent so we might want to move them to LJ::Some::Other::Name. That will require deeper understanding of the code and the application.
Eliminate Class::Autouse is the last one
of the currently assigned bug. Class::Autouse might save memory and improve speed in a command line environment or for a CGI script but in a persistent environment such as mod_perl (or FastCGI) it does not have added value. So I'm going to get rid of all the 90 or so occurrences.
no subject
no subject
no subject