MyISERN 2.0 Review

The code I reviewed is from team yellow.

1. Installation
I can download the distribution file without any problem. I also unzipped it with ease because I used the WinRAR, but my other team member had problem unzipping it while using the default window unzipper.

Since there is no installation guide, I followed the developer guide and tried to build the system. Since team yellow is using a whole new system, there is no easy runnable war file. I downloaded XAMPP and Symfony as the guide told me to. When I tried to install the XAMPP, I had problem of getting the Apache server running. However, my other team member do not have that problem. After googling several pages, I discovered that this is quite a common problem, and there are many ways to "tweak" around it. I use the word "tweak" because none of them seem to guarantee to fix the problem. I finally got the XAMPP homepage show up on my localhost after I turned off my firewall and stopped some of my IIS services, which I have no clue what those services are used for.

However, my journey is pretty much ended here. I tried to install the Symfony framework, which is a lot harder than the XAMPP. The link provided in team yellow's guide does not give any useful information and it is more suited for unix users. The "pear" command-line thing seems come up from nowhere. I searched inside the folders from XAMPP and Symfony, and I did find some things called "PEAR", I tried every single execuatable, but they did not give me any luck. I tried to refer to the guide from team lime, which is using the same framework, but team lime is using WAMP, which is something different from XAMPP, and thus did not go too well either.

My other team members are pretty much stuck as I do. I finally had to give up after like two hours of searching the internet and reading relevent materials. Although Edward is managed to get the Symfony working at the end, he did not get the web app running still.

2. Code format and conventions
I have no experience for programming in PHP, therefore I do not know how well-formatted the code is. I remember team yellow mentioned a PHP eqivalence of checkstyle in their demo, but due to the reason I couldn't get the system running, and there is no guideline on how to run the tool, I have no clue to test it out.

3. Test case
Black box perspective: Since the system is not built, I cannot evaluate this.
White box perspective: Same reason as above.
Break da buggah: Same reason as above.

4. User interface
Although I am not able to build the system, I am able to see part of the website in my browser from those PHP files. The interface is very clear, and I like the coloring of the table cells which makes the whole page pretty neat. However, since these are partially of the interface, I cannot really evaluate it.

5. Three Prime Directives

Since the program cannot be built, it does not accomplish a useful task. As an external user, I am not able to install and use the system. As an external developer, I am not able to enhance the system easily, maybe I could get it working after putting considerable amount of effort into it.

6. Summary and lesson learned
From this review, I once again realized how important the documentation can be to a system. I had terrible experience working with software that has bad documentations. I do admire the courage of team yellow to take on a brand new system. Here is one suggestion I have: create a detailed installation guides with A LOT of pictures in it, you can safely assume the users have no knowledge of any tools you have used here, which is probably true for most of the class. Do not refer to any other online guides, they might not suit your system the best.

Prime Directives Redux

For each tool or technique, please provide one or more concrete examples of how it satisfies each of the three prime directives. If you feel the tool or technique does not apply to one or more of the three prime directives, please discuss why.

1. Interactive Development Environments (Eclipse, VisualStudio, etc.)
These IDE tools satisfy PD 1 because they obviously accomplish the task of developing software by providing an integrated environment with editor and compiler. The programmer can easily write programs and test the code all within the IDE.

These IDE tools also satisfy PD 2 because in this case, the developer, or programmer, is the main user. Since programmer’s tasks are to write programs and test programs, and these IDE tools can successfully accomplish these tasks, it indicates that the user can install and use these tools.

In terms of PD 3, these IDE tools score differently. If the IDE is open source, it is quite easy for an external developer to enhance the system since the developer can know about what is going on inside the system, assuming the system provided sufficient documentation. On the other hand, if the IDE is not open source, then it all depends on how much documentations the IDE provides, and how much restriction is applied. For example, Plug-in, which is a small portion of code that attaches to the system to enhance certain ability of the system, is usually allowed, and it is often easy to write with the provided API of the system. However, redesign of the system, such as major algorithm change, is commonly prohibited for closed source systems.

2. Coding Standards and Coding Standards Compliance Tools (Checkstyle, etc.)
This technique and the corresponding tools satisfy the PD 1 because they accomplish the task of ensuring a standard, consistent, and readable coding style through out the program by either enforcing a formal coding standard or automatically formatting the code with software tools.

This technique and the corresponding tools satisfy the PD 2 because they provide an easy way to format the code of a program, without the developer level requirement. For example, the users just have to follow the coding standard to write consistent and readable code, and they are not required to understand the rational behind the standard. Also, the users just have to run the coding standard compliance tools without knowing how the tools reformat the code to make it match the standard.

This technique and the corresponding tools also satisfy the PD 3 by giving control to the developer. The developers can adjust the coding standard easily according to their needs. For example, the developer can simply add additional rules to the compliance tools when they need it, and the new rules would be automatically applied to the whole program when the tool runs.

3. Build Systems (Ant, Make, etc.)
These tools satisfy the PD 1 because they successfully accomplish the task of building up a runnable file for the project by breaking down the project to separate components and create dependency among these components.

These tools satisfy the PD 2 because the developers and programmers, as the users, can use them relatively easy. These tools are usually well-adopted in its own domain, so the documentation and support are sufficient to allow the first time users to install the tools successfully.

These tools also satisfy the PD 3 because the developers can customize the build files to fit the desire of different projects. It is also independent to the IDE, so the developer can choose whatever IDE they feel comfortable with to develop the project.

4. Automated Quality Assurance Tools (PMD and FindBugs, etc.)
These tools satisfy the PD 1 because they accomplish the task of improving the quality of a program. Base on the tools, different aspects of the quality can be improved: optimization, subtle bugs, logical error, code convention, etc.

These tools may not satisfy PD 2 too well because most of these tools do not run alone, and they need to integrate with some other build tools in order to be used easily. Although this is not hard for a programmer, it could be troublesome sometimes.

These tools satisfy PD 3 because the developers can configure the tools in various ways so that they can check whether some certain aspects, or quality, of the program have been obtained. It allows the developers to develop different projects but have an overall guaranteed production quality.

5. Black and White Box Testing
This technique satisfies the PD 1 with the assumption that the testing are useful testing. With useful black and white box testing, the quality of the program is improved. However, if the testing is not good or useful, it means nothing to the program and thus does not accomplish a useful task.

This technique satisfies the PD 2 to a certain degree because with good black box testing, it implies the system is usable, and with good white box testing, it implies the system is stable. Together it gives the ability to use the system for the users. Again, this is under the assumption of the testing is good and useful testing.

This technique satisfies the PD 3 with the same assumption. For example, the developers writing black box testing do not need to know the internal structure of the system, yet with sufficient and high-quality testing which simulates the users’ tasks, the quality of the system will be enhanced. The more testing the system can pass, the higher quality of the system will have. Of course, granted those testing are useful ones.

6. Automated Testing Tools (JUnit, HttpUnit, etc.)
These tools satisfy the PD 1 because they provide an easy way to write tests and run test for a program. They provide predefined functions which are frequently used and often helpful for writing tests, and it simplified the programmer’s job of building a test case from scratch.

These tools satisfy the PD 2 when they have sufficient documentation and support. After all, it is not helpful to have these testing tools but the programmers do not know how to write them.

These tools satisfy the PD 3 because these tools enable the developers to create test cases in a more consistent way and thus easier to maintain. With these tools, the scalability of the testing can be increased in a more efficient way because they are well-organized and automated through small incremental build-ups.

7. Configuration Management (CVS, SVN, etc.)
These tools satisfy the PD 1 because they accomplish the task of providing a way for collaborative software development. Different developers can cooperate efficiently by using these tools to maintain a master copy of the code and still develop on their own copies.

These tools satisfy the PD 2 and PD 3 together because as the developers use these tools, they can keep track of what the other developers are doing and ensure that everyone is staying on the same stage, which can help to produce more high quality code.

8. Issue Driven Project Management
This technique satisfies the PD 1 by providing a way to manage the project process.

This technique is not really applicable to the PD 2 since it is only a technique for software development.

This technique satisfies the PD 3 because it keep tracks of every step of the development by a series of issues, which makes it easier to trace back and modify in the code according to the issues, hence gives higher quality of code.

9. Use Cases
This technique satisfies the PD 1 because it provides an easy understanding of what the system is able to do and how should it be done by describing them in use cases, which are essentially user stories and scenarios.

This technique is not really applicable to the PD 2 since it is only a technique for software development.

This technique satisfies the PD 3 by guiding the design and implementation of the system toward the users, who determine if a system is useful or not. By applying this technique, the developer would have a higher chance to develop system that satisfies the users’ needs, in other words, a higher quality system.

10. Software Review
This technique satisfies the PD 1 because a review can give useful feedback to the developer. It accomplishes the task of acquiring feedback about the system.

This technique is not really applicable to the PD 2 but it is related to the PD 2 since the usability of a system is closely tied to how much the reviewer can use the system.

This technique satisfies the PD 3 because the feedback from a review of the system can help to improve the design and implementation of a system, which in turns brings up the quality of the system.

11. Agile Methods (XP, Scrum, etc.)
These techniques satisfy the PD 1 because they accomplish the task of allowing software development in an agile way: change is usual, frequent, and good, and it should not be hard to make change.

These techniques are not really applicable to the PD 2 since they are only techniques for software development.

These techniques satisfy the PD 3 by adding “agility” to the software development process, which allows the system to be changed frequently without too much penalty, and adopt the new requirement.

12. Open Source Licenses (GPL, CPL, etc.)
These licenses are not really applicable to the PD 1 because they have nothing to do with the functionality of a software system.

These licenses satisfy the PD 2 by allowing more people to use software freely that are open source, and thus create more usability.

These licenses satisfy the PD 3 by allowing developer to enhance or change the open source software the way they want without restrictions or with minimal restrictions.

13. Online Hosting Services (Google Project Hosting, SourceForge, etc.)
These tools satisfy the PD 1 because they provide an easy way to host a software development project.

These tools satisfy the PD 2 because they are well-adopted to specific domain and have great community support, thus they are very easy to use.

These tools satisfy the PD 3 because the developer can easily host their project without the hassle of setting a server. This would greatly increase the ability of personal or small group software development.