This week I have finished writing tests for the error reporting server. I have done tests for controllers and models. I am not going to test views or helpers because it would make the tests very fragile if we change a few html tags or classes. I have 100% coverage on almost all the covered files.
As for the phpmyadmin component. I refactored the functions I wrote into a library that I include. I also renamed functions to follow conventions and wrote the doc blocks for those functions.
For next week I should be documenting the error reporting server codebase. I will probably also add the copyright notice to the required files. There are some refactoring I wanted to do in the access control module. Also I am planning to do something useful to the state like add other states and provide a way to change state.
This week is the second week for the graphs and stats task. This week was the final week of writing new functionality. Next week is docs and tests. This week I added global stats about the different summarizable facts about incidents as well as an incident chart to track incidents. I also corrected some bugs from last week and added some of the recommended functionality by some of the phpmyadmin developers
I started researching unit testing in cakephp. I have written tests before but that was for ruby on rails. Its the same concept but the available facilities are different. I shall start with writing the tests and I hope to finish all the model functions this week but I am not sure yet.
There is no major changes to the database so the old seed file should still work and no major changes to reports.phpmyadmin.net. I refactored a few parts of the codebase since I didn’t feel them elegant enough. There is probably going to be more refactoring in the coming weeks as well.
I will do some refactoring in the phpmyadmin code I wrote. Since the project is nearly over we shall be merging this code soon so it would be good to be prepared for it.
We are nearing the end of the project. This week was graphs. I created pie charts that showed summaries of the incidents in a report. I also added two more summaries so that almost anything that could be summarizable is summarized.
I had used previously a graphing library but it turned out not to be free for commercial use. Since I am not sure what type of use is this I looked for an opensource library that was more flexible and found one that was released under the MIT license.
I also added syntax highlighting in the stack traces to make it easier to see the code snippets. Furthermore I fixed a bug where if the error occurs in error_report.js file then I wouldn’t accept it. I also added another characteristic for grouping error reports which is pma_version. two incidents belong to the same report only if they have the same pma_version.
I created a pull request for the changes here. I still have not prepared the new seed file. This has a new look for the website and I need a new update from the community on the look of the project. I will be crafting an email once I create the seed file.
As for next week I have planned for adding graphs for the entire website like reports per day as well as frequency of reports per pma_version, as well as other summaries that I may find interesting.
This week completes the two week task of adding functionality of grouping exceptions together manually and automatically. I have changed the way of storing the reports in the database from storing all the data in the reports table to storing exceptions in the incidents table and similar incidents are grouped in the reports table.
I have added functionality to group related reports together such that they show the combined information of their incidents in the reports description page. I have also offloaded the code that creates new incidents and reports to the incidents model. I have refactored it to split it into separate functions.
I have also modified code in phpmadmin to anonymize the host name from the error report as well as remove unneeded params such as database and table names. I have also isolated the actual files and php scripts where the exception occurs to be used in grouping the reports together.
I also added some sanitization in html entities that are stored in the database. there needs to be more sanitization done in the coming weeks to cover all the user submitted data.
I created a pull request here for all the changes including some other checkstyle changes. I will also create a new seed file soon for the new changes since the old one would not work anymore.
As for next week it is the first week in another two week task to add graphs to visualize the statistics both for a single report as well as all the reports as a whole. Additionally I would add another field to the report summary which is which page the exception happens in, as well as sanitize the rest of the user submitted fields to prevent XSS.
This week my task was to create a view for an error report. I finished it successfully. I have created 2 views one that shows the summary of all the submitted reports showing the most important info and the other shows the details of a specific incident
The detailed view is a pure json view that has all the information collected. The reason I kept the view as json is that there was too much information for it to easily fit in a usable interface. When I was doing an html display I was cramming a lot of information and trying to make it look good with the layout. The json saved me from that and allowed me to only include the info that I think would be most suitable and leave the others out to the detailed view. it is also pretty printed so its still easy to manage.
I have tried to make my code as modular as possible so that any change in one part should not impact the other parts. I have left all but the simplest queries out of the controller and implemented them as methods in the model. This is a good approach since it allows me to change the schema of the database and leave the controller and views untouched.
Speaking of changing the schema, the current schema is implemented such that all submitted reports are given first class treatment in the sense that they are listed separately in the index and each has its own view. however this is increasingly not the case, since most likely most of these reports would just be repetitions of an older issue or bug and should not get the same treatment as a new bug or issue.
This is currently implemented by an extra column in the reports table pointing to the id of the report of some similar report. Thus reports without an entry in this column should be given preferential treatment than reports that do.
So I am thinking of changing the schema into two different tables. one for reports and the other for incidents. the incident is a submission that matches a report such that all incidents for a specific reports are for the same bug. and a report has many incidents.
Due to the separation of responsibilities I am able to do the change with minimum changes in the controller and view. I will probably do this in the weeks allotted for grouping reports together since this is the most relevant week and will already include a host of changes to allow for the grouping of reports anyway.
Next week I am going to implement sourceforge api submission. It would allow developers to just automatically submit reports to the sourceforge issue tracker for the developers to work on. The only issue left is access control, in the sense that who can submit these reports?
This week was github api and authentication. I refactored the code I wrote for last week and moved it into a separate component to handle all the requests and try to keep the controller slim. I currently also created some access control on the website where only logged in developers can see the error reports otherwise they are redirected to the home page and asked to login.
After some working I was able to get an access token for the source forge api for my account. I also created a controller to enable me to get an access token for any account since I will be creating an account for sourceforge bug tracker submission. That however is for another week.
This week I have finished the client side component and once the api between the client and the server is complete I will request merging into master. This should be the last week of me working on the client side component.
My system now currently catches any errors that occur and offer to submit the error report to our servers. It uses file_get_contents or curl depending on availability and respects the proxy settings set by the user.
I wrap all global functions starting with PMA_ I also wrap the callback for AJAX.registerOnload as well as the handler for $.fn.on since it is used excessively throughout the code.
I have tested the code in the latest versions of browsers available on linux (so no IE or safari yet) and it works ok.
I have started on the server side component and created a repo. I have setup the server on my computer. Once I make things more portable I will probably push the initial version of the server early this week. A lot of things are currently dependant on my current setup so it is of no use to push them to a public repo for now.
I will be using cakephp as my development framework. I would have rather used Ruby on Rails but I figure it would be easier on the developers who already know the language to use a php framework.
This week my task is to basically create the server. I have gotten a head start already. I will be using the extra time to take on some of the tasks of the next week so that I would be ahead of schedule.