Things I learned about continuous integration that I did not know before
The Hudson is running on the CSDL telemetry wall since the semester began, and I kind of grab the idea of what it is doing by looking it so often since my project requires me to look on that wall every now and then. What I didn’t notice, however, is that it not only does compile and build the project, but also runs various QA tools, such as checkstyles, PMD, findbugs, JUnit, etc. Also I didn’t know that Hudson is so automated that once you set it up, you can almost forget about it. The features that Hudson offers are far more than I expected.
Problems I had to resolve in order to get the informative workspace system to build under Hudson
I have encountered various problems while I was trying to getting my informative workspace system to work under Hudson, but the real problem that took me quite a while to figure out was to make the system deploy in tomcat by Hudson. First of all, since the system is deployed in tomcat, it requires the tomcat to be running first. And since tomcat is using the default 8080 port, I have to somehow change the port for Hudson. (Well, actually now I think about it, maybe deploying Hudson in tomcat would also solve the problem.) Anyways, what I did was putting the "--httpPort=8081" parameter. However, changing the port didn't solve my problem. I still got the error of deploying the war file into tomcat, and it is a http response 505 error. After some googling, I guessed the problem was caused by the "C:\Documents and Settings" folder, which was the default home directory for Hudson to store a local copy of the SVN files. Since the way I deploy my war file is using ant script, and ant doesn't like the spaces, it simply refused to work. After I set up a variable HUDSON_HOME and points it to a folder without space, things went very smooth. (I still haven't set the emma up, but I was thinking to exclude it from my normal build routine anyways, so I will just leave it as it is for now.)
Update: Later I tried to create a new job with space in the name and the deployment also failed. This could be the original reason for the failure in the deployment. But since ant doesn't like space anyways, I would rather to keep things simple by eliminating both the spaces in HUDSON_HOME and in the job name.
Steps Philip has to carry out in order to get the informative workspace system running using the CSDL Hudson server
Other than setting HUDSON_HOME to a folder without space (which I assume is already been done), I don't see there are any extra steps needed for getting the informative workspace system running in the CSDL Hudson server.
Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts
Monday, March 17, 2008
Monday, February 25, 2008
The REST Architectural Principle
After reading some articles about the REST architectural principle, I really think it is a very reasonable architecture, and I am a little surprised in the real world we somehow just don't do things in the way that they supposed to be done, also known as, the RESTful way.
Last semester when I was doing the MyISERN project, the application was accessed through a serious of "action beans". Therefore, the URL is mostly something like /host/researchers.do, which is converted from the ResearchersActionBean. There are many problems with URL like this: one of the most common issues is that people cannot bookmark the page because the URL is always the same. Moreover, the URL does not represent the data on the page in a meaningful way.
Now since I know about REST, I would like to have my current Informative Workspace project being RESTful. The idea of informative workspace is to make the software development process more transparent, and thus there will be many relevant data involved. The REST principle can provide a good way to represent these data in a more reasonable way. For example, we can have some URL like these: (well, with the assumption that the system is a web application)
host/projects/ambient-device/code-complexity
host/projects/iHacky/milestones/2008-02-20
Technically, REST refers to giving a unique URI to every resource, and URL is only a subset of URI. However, I believe the concept is the same. Through the composition of the URL, the user can have a better understanding of what data is being represented in the page. I believe the real problem would be how to represent all these data in a way such that they can be helpful to the development process.
On the other hand, the SensorBase API pretty much obey the REST principle. For example, the resource is named using the URI specification: host/projects/owner/projectname. Also, it uses the standard HTTP methods such as GET, POST, and DELETE to control how the different data are represented, or, control how the different services are provided.
In terms of the Project Viewer, it doesn't seem like it obeys the REST principle to me. At the moment, the URI does not give information owner of the project, as well as the projects. Also, the user doesn't have access to the other data of the project from the Project Viewer itself. (well, it does give the URI for the SensorBase and DailyProjectData, but it requires the users to enter it from the browser.)
Last semester when I was doing the MyISERN project, the application was accessed through a serious of "action beans". Therefore, the URL is mostly something like /host/researchers.do, which is converted from the ResearchersActionBean. There are many problems with URL like this: one of the most common issues is that people cannot bookmark the page because the URL is always the same. Moreover, the URL does not represent the data on the page in a meaningful way.
Now since I know about REST, I would like to have my current Informative Workspace project being RESTful. The idea of informative workspace is to make the software development process more transparent, and thus there will be many relevant data involved. The REST principle can provide a good way to represent these data in a more reasonable way. For example, we can have some URL like these: (well, with the assumption that the system is a web application)
host/projects/ambient-device/code-complexity
host/projects/iHacky/milestones/2008-02-20
Technically, REST refers to giving a unique URI to every resource, and URL is only a subset of URI. However, I believe the concept is the same. Through the composition of the URL, the user can have a better understanding of what data is being represented in the page. I believe the real problem would be how to represent all these data in a way such that they can be helpful to the development process.
On the other hand, the SensorBase API pretty much obey the REST principle. For example, the resource is named using the URI specification: host/projects/owner/projectname. Also, it uses the standard HTTP methods such as GET, POST, and DELETE to control how the different data are represented, or, control how the different services are provided.
In terms of the Project Viewer, it doesn't seem like it obeys the REST principle to me. At the moment, the URI does not give information owner of the project, as well as the projects. Also, the user doesn't have access to the other data of the project from the Project Viewer itself. (well, it does give the URI for the SensorBase and DailyProjectData, but it requires the users to enter it from the browser.)
Monday, February 11, 2008
Changing Perspective
I read this article few days ago. The main theme of the article is about what the life of a software engineer is like. It is quite interesting to me that the author considers programming as producing art, just like the poets creating poems. For a very long time, I believe coding is some sort of elegant work, but I never really think of it in terms of art. To me, arts are something like the Mona Lisa, or the Ninth Symphony.
As an ICS senior, from time to time, I would imagine myself becoming a normal programmer after graduation. Then all I do is coding, coding, and coding. 8 hours a day, 5 days a week. It seems like an endless cycle to me, and honestly speaking, I feel that absolutely boring. What if one day, our technology is so advanced, such that we invented some programming machines that can produce quality code as human? If that ever comes true, what is the value left inside a programmer like me?
After reading the article, I think it might be about the time for me to change my perspective of programming. Computer language is like a brush: if it’s in the hand of some incompetent persons, it is no more than a brush; however, if it’s in the hand of an artist, it can become the key to unlock the artistic palace. It is the person that determines what the product can be, either junk or treasure. The creativity of human can never be replaced by the machine. Therefore, there are always some values left inside me, and there would be always something that only I can do.
Someday, if people ever ask what I do, hopefully I can proudly tell them: I write programs, like the poets write poems.
And no, I don’t fix computers.
As an ICS senior, from time to time, I would imagine myself becoming a normal programmer after graduation. Then all I do is coding, coding, and coding. 8 hours a day, 5 days a week. It seems like an endless cycle to me, and honestly speaking, I feel that absolutely boring. What if one day, our technology is so advanced, such that we invented some programming machines that can produce quality code as human? If that ever comes true, what is the value left inside a programmer like me?
After reading the article, I think it might be about the time for me to change my perspective of programming. Computer language is like a brush: if it’s in the hand of some incompetent persons, it is no more than a brush; however, if it’s in the hand of an artist, it can become the key to unlock the artistic palace. It is the person that determines what the product can be, either junk or treasure. The creativity of human can never be replaced by the machine. Therefore, there are always some values left inside me, and there would be always something that only I can do.
Someday, if people ever ask what I do, hopefully I can proudly tell them: I write programs, like the poets write poems.
And no, I don’t fix computers.
Monday, December 10, 2007
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.
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.
Monday, October 22, 2007
Use Cases
Use Case Wiki Pages
This is not a really difficult assignment, since we have gathered the necessary information we need to create the use cases.
We decided to use a use case template to keep our uses cases consistent. This is easily done. After several Google searches, we found some templates that might fit our needs. We modified the templates so it matches our use cases. At first we tried to fill out the use cases using tables, but then very soon we found out it is almost impossible to have a nicely formatted table in the Google project wiki pages. The only way to preserve the new lines is using the code block, which has some weird color when the content is not a real code. Also, some new lines are not preserved somehow. However, we figured this would be the best we can do in these Google project wiki pages.
In this assignment, I have a better understanding of use case. When writing a use case, consideration for both the user and the system are necessary. Also, a clear flow of how the process will be very helpful. Although use case is better when writing as scenarios, it is very easy to get wordy. A balance point between detained description and concise story is important. Lastly, use case driven design seems reasonable approach for developing software. After all, the users are the ones who determine whether the software satisfy their need. Knowing how they would use the software would save a lot of unnecessary mistakes.
This is not a really difficult assignment, since we have gathered the necessary information we need to create the use cases.
We decided to use a use case template to keep our uses cases consistent. This is easily done. After several Google searches, we found some templates that might fit our needs. We modified the templates so it matches our use cases. At first we tried to fill out the use cases using tables, but then very soon we found out it is almost impossible to have a nicely formatted table in the Google project wiki pages. The only way to preserve the new lines is using the code block, which has some weird color when the content is not a real code. Also, some new lines are not preserved somehow. However, we figured this would be the best we can do in these Google project wiki pages.
In this assignment, I have a better understanding of use case. When writing a use case, consideration for both the user and the system are necessary. Also, a clear flow of how the process will be very helpful. Although use case is better when writing as scenarios, it is very easy to get wordy. A balance point between detained description and concise story is important. Lastly, use case driven design seems reasonable approach for developing software. After all, the users are the ones who determine whether the software satisfy their need. Knowing how they would use the software would save a lot of unnecessary mistakes.
Thursday, October 4, 2007
CM Practice
Project Homepage
Discussion Group
SVN Group
Comparing to the WebSpider assignment, this is a relatively easy assignment. I was able to accomplish all three tasks. Although this task is simple, I still encountered some difficulties.
The first problem for me was the authentication of the tortoiseSVN. Thanks to the Prof. Johnson's help, I figured out that it was the HTTPS prefix of the URL screwed me over. When the HTTPS is used, that means an encrypted connection between the browser and website is established. In the HTTP case, the connection is unencrypted, and thus the write access is granted. Although I have heard about this concept before, this is actually the first time I encounter a problem caused by it.
The second problem is the mailing list setting for my project. The PDF file from the class website is unclear and different from what I see in the website, which made me a little confusing. Fortunately with the help from my classmates, I am able to solve the problem. I also commit twice to the SVN to make sure that there is a notification sends out to the mailing list whenever I do a commit. It would be much better that Google can integrate this functionality into its project hosting page.
From this assignment, I learned how to host a project use Google hosting, and I clarify the mechanism of how the SVN works. I had used SVN in a previous class, but there were a lot of troubles because the instructor did not teach us anything about it. Terms like trunk, commit, and configuration really confused me. This time I actually realize the advantages of using SVN, which I believe it will be a great help to my group project in the rest of the semester.
Discussion Group
SVN Group
Comparing to the WebSpider assignment, this is a relatively easy assignment. I was able to accomplish all three tasks. Although this task is simple, I still encountered some difficulties.
The first problem for me was the authentication of the tortoiseSVN. Thanks to the Prof. Johnson's help, I figured out that it was the HTTPS prefix of the URL screwed me over. When the HTTPS is used, that means an encrypted connection between the browser and website is established. In the HTTP case, the connection is unencrypted, and thus the write access is granted. Although I have heard about this concept before, this is actually the first time I encounter a problem caused by it.
The second problem is the mailing list setting for my project. The PDF file from the class website is unclear and different from what I see in the website, which made me a little confusing. Fortunately with the help from my classmates, I am able to solve the problem. I also commit twice to the SVN to make sure that there is a notification sends out to the mailing list whenever I do a commit. It would be much better that Google can integrate this functionality into its project hosting page.
From this assignment, I learned how to host a project use Google hosting, and I clarify the mechanism of how the SVN works. I had used SVN in a previous class, but there were a lot of troubles because the instructor did not teach us anything about it. Terms like trunk, commit, and configuration really confused me. This time I actually realize the advantages of using SVN, which I believe it will be a great help to my group project in the rest of the semester.
Subscribe to:
Posts (Atom)
Posts
