Introduction:
iHacky is supposed to be a sort of social network within a social network. This have some inherent advantages such as using the original social network to spread your own base. But it also seems repetitive. The idea kind of makes you ask yourself, "why?" After actually installing the application and being an avid Facebook user, I'm starting to see the light.
Installation:
As for installation, installing the iHacky application was the easiest out of all the projects so far. All I really had to do was click on the installation link on their installation guide, click okay a few times and there it was. It was a bit spare but I could really see some potential in it. I wasn't able to install the iHacky server side application because PHP is actually really hard and actually convoluted to install. As far as the code goes though, I really don't know PHP as well so it wasn't really worth installing anyway.
Code Review:
Although I don't know too much about PHP, one look at the code and I can tell that it is clearly documented. There really isn't too much code which goes to show just how powerful PHP is with web development but it is not so complex that you can't follow what is going on with each page. To be honest, it looks a lot like the MyIsern project we were working on last week.
Overview:
As for any bugs that I've found, the home page has a link that links back to my own Facebook homepage. Clearly, this is really not necessary. I have a link to that at the top of my page already. I really don't need another one. On top of that, there really is nothing on the homepage at all. Although the base code seems to all be there, there really is nothing functionality-wise. I can find anything that really attracts me to the homepage and gives me something to do while I browse away on Facebook.
On the profile page I find more of the same. There is again a link to my own profile. I don't really see a need for this. Instead, how about a few boxes where I can start editing my own profile already. Somewhere where I can add what languages I'm good at or at least know something about. If not, maybe a little area where I can insert my coding "motto" or a blog section. If this is really going to be a social network, within a social network, you might as well take the best from each social network. There are websites like xanga, myspace, facebook, and orkut. Each one has people attracted to it for a special reason. I think this application needs to find that special something and put a iHacky twist on it.
Tools look like somewhere I could put in something about the languages that I work with but right now it has nothing. There is a cool autofill search toolbar but with so little people on the application, it's not very helpful. Another idea that could be used here would be a section to add/edit/delete my own tools. Hey maybe even a section where I can elaborate on the tool, such as how long I've work with this tool or maybe even where I've used it before. Why not a link to the project itself. The idea is to link people that have common interests, but you can't find people with common interest if you don't list the project you work on. It's easy enough to on sourceforge and look for projects, but what if you wanted to know more about the developer? This would be an awesome niche for that some of interaction.
The more I go through the site, the more it seems like the site should be more compact. There shouldn't be a separate tab for tools, teams, and projects. They should flow into each other and if need be, a search that you can use to find any of the three. This should be easy since we did this through MyIsern.
There is an invite tab but nothing there. I would rather not be enticed with this if there is nothing to do here. Really.
Also, like any good web developer, you don't want all your contact information all over different pages where they might not be relative. If it is then, of course it should be there, but you should also have a page where they could get in contact with you if they need to. Maybe a contact page?
As for any other tasks, tab, or other options, a profile picture would be nice too. Bulletin posts? Maybe you want to send out an announcement to everyone you know about a new project you're starting? This social network was originally based on college student trying to connect to each other, so you should take advantage of this and try to tap into that network. Listing what college you went to will also help you find people in your ICS class that you haven't seen in a while and catch up to them. So why not a message feature as well?
Wednesday, March 19, 2008
Monday, March 17, 2008
09.Hudson
To really talk about what I learned about Continuous integration before this assignment, I really need to go over what I knew about it before. I knew that Hudson was a continuous integration application but I originally thought it was just a server program that would keep a copy of your project and build it for you. I had have the idea right. I didn't know what it actually grabbed a copy of your project from a SVN repository and then built it for you. I also didn't know that it used ant and a bunch of other QA test software that we were already implementing to basically build and run tests on our project for us. I also didn't know what Hudson will also send out an RSS feed or some other notification to let us know of some error. I thought we would have to check in on Hudson ourselves.
I really didn't encounter any problems getting Hudson to work with our project since we use a SVN repository, Java, and all the other QA tools for java like ant, PMD, CheckStyle, and such. For the most part it was just setting up the project that took a while. The things that gave me problems were finding my SVN http link, the password for the SVN account and things like that. It really wasn't much of a problem at all.
The steps needed to actually set up Hudson with our project are pretty standard. First off we needed to install Hudson. This is easy enough because we just needed to "java -jar hudson.war" or deploy the Hudson war file into any running server application like tomcat. Then we need to set up the ant installation which just meant going into Hudson homepage and clicking on the "manage hudson" and "system configuration" links then add the local directory for ant.
Then we need to set up the SVN repository with just amounted to clicking this link, "
Then we need to set up the project. We needed to click on the new job link on the homepage and select "Build a free-style software option." On the next page, we need to setup Hudson to use SVN, how often we are going to poll the SVN, and what to run (ant) when we build the project.
Now Hudson should already start to download and build the project. The only other thing to do is to set up all the other QA tools and we should be done. This is just as simple as downloading the plug in's from the Husdon webpage and installing them under the "Manage Hudson" link that can found under the main page. After installing the plug in's and restarting Hudson, there should be a "manage plugin" link under "Manage Hudson" link. From here you can manage all the different tools such as PMD, FindBugs and such.
I really didn't encounter any problems getting Hudson to work with our project since we use a SVN repository, Java, and all the other QA tools for java like ant, PMD, CheckStyle, and such. For the most part it was just setting up the project that took a while. The things that gave me problems were finding my SVN http link, the password for the SVN account and things like that. It really wasn't much of a problem at all.
The steps needed to actually set up Hudson with our project are pretty standard. First off we needed to install Hudson. This is easy enough because we just needed to "java -jar hudson.war" or deploy the Hudson war file into any running server application like tomcat. Then we need to set up the ant installation which just meant going into Hudson homepage and clicking on the "manage hudson" and "system configuration" links then add the local directory for ant.
Then we need to set up the SVN repository with just amounted to clicking this link, "
http://localhost:8080/scm/SubversionSCM/enterCredential" and typing in the link for your SVN repository and the respective account username/password combination that you've set up just for Hudson.Then we need to set up the project. We needed to click on the new job link on the homepage and select "Build a free-style software option." On the next page, we need to setup Hudson to use SVN, how often we are going to poll the SVN, and what to run (ant) when we build the project.
Now Hudson should already start to download and build the project. The only other thing to do is to set up all the other QA tools and we should be done. This is just as simple as downloading the plug in's from the Husdon webpage and installing them under the "Manage Hudson" link that can found under the main page. After installing the plug in's and restarting Hudson, there should be a "manage plugin" link under "Manage Hudson" link. From here you can manage all the different tools such as PMD, FindBugs and such.
Wednesday, March 12, 2008
hackystat-sensor-visualstudio -- Code Review
Introduction:
I was actually pretty interested in testing this project because I was curious to see just how data could be taken as you are coding. It wasn't what I thought it would be but it was interesting nonetheless. They expected to retrieve data on the programmer by monitoring how changes in opening, saving, closing files and such would indicate some kind of change of state. I don't really see how much data could be taken from these actions but they added other actions such as compiling the code, state changes, changes in the buffer and program itself. I could see some data come from this but it's really quite vague on just what kind of data could be had here. It seems like all the data being collected are things that I should know as I'm coding, it would be nice to see a sensor that could take the code I've written and give me data that reflects whether this file has an associated test that goes with it, or if there was a sensor that told me that I was writing code that would not be executed (i.e. white box testing).
Installation:
Other than the fact that getting Visual Studio 2008 was extraordinarily difficult for me (I did not have a MSDN account and wasn't aware of that till the last minute), the rest of the install was a breeze. I was able to download the files with no problem. I was able to follow the instructions online and installed the sensor with no problems. This is to say that I already had hacky stat installed and for a regular user there should be a bit more information on how to install just the "essentials" of hackystat.
A few problems that I did run across was that I didn't have .NET 3.5 and I had to download and install that along with Visual Studios 2008. I think this team should make a note of that for future releases. On the plus side, although I was blocked from using the sensor without this piece of software, the installer did direct me straight to where I could download with ease.
I could also possible see someone getting lost when trying to install hackystat. They should be specific to which part of hackystat they need to install. Also the very first line of the installation guide reads, "This sensor is compatible with Visual Studio 2008 or a Visual Studio version that supports up to .NET Framework 3.5." I had Visual Studio 2005 install with the .NET 3.5 framework and it did not work. They should change this to reflect that.
Code Review:
I'm not to familiar with C# but it was surprising to see that it was very similar to Java. I have no idea what the coding conventions are so I can't really say much about that but I was able to follow along with the code without much difficulty. There was a slight error with "VisualStudioSensor - For Testing.Addin." Apparently it was looking for a file that was not there. I checked the installation guide and could not find anything on this file. I really have no idea what this file is for but I was able to run through the rest of the program without any errors.
Bugs:
The few bugs that I found were running more than one instance of the program caused the sensor to crash. I don't know if this is something they never planned for or if it is a deliberate function.
The status bar text reminding you that the sensor was initiated only works when Visual Studios is started manually. If I opened a .sln file there was nothing to tell me that the sensor started.
There was also another bug with NUnit gave some kind of error but this was fixed with the latest release of the sensor.
There is also that Testing.Addin mentioned above ealier.
Overview:
This project installed very easily and ran almost without a hitch. The only problems that I really ran across was a few errors that had to do with multiple instances and basically things that I would do only to "break da bugguh." Other than that, each of the DevEvents worked fine. I was able to open, save, and close files and see it reflected on the project viewer. I was also able to use the other feature and find corresponding DevEvents on the project viewer as well.
I was actually pretty interested in testing this project because I was curious to see just how data could be taken as you are coding. It wasn't what I thought it would be but it was interesting nonetheless. They expected to retrieve data on the programmer by monitoring how changes in opening, saving, closing files and such would indicate some kind of change of state. I don't really see how much data could be taken from these actions but they added other actions such as compiling the code, state changes, changes in the buffer and program itself. I could see some data come from this but it's really quite vague on just what kind of data could be had here. It seems like all the data being collected are things that I should know as I'm coding, it would be nice to see a sensor that could take the code I've written and give me data that reflects whether this file has an associated test that goes with it, or if there was a sensor that told me that I was writing code that would not be executed (i.e. white box testing).
Installation:
Other than the fact that getting Visual Studio 2008 was extraordinarily difficult for me (I did not have a MSDN account and wasn't aware of that till the last minute), the rest of the install was a breeze. I was able to download the files with no problem. I was able to follow the instructions online and installed the sensor with no problems. This is to say that I already had hacky stat installed and for a regular user there should be a bit more information on how to install just the "essentials" of hackystat.
A few problems that I did run across was that I didn't have .NET 3.5 and I had to download and install that along with Visual Studios 2008. I think this team should make a note of that for future releases. On the plus side, although I was blocked from using the sensor without this piece of software, the installer did direct me straight to where I could download with ease.
I could also possible see someone getting lost when trying to install hackystat. They should be specific to which part of hackystat they need to install. Also the very first line of the installation guide reads, "This sensor is compatible with Visual Studio 2008 or a Visual Studio version that supports up to .NET Framework 3.5." I had Visual Studio 2005 install with the .NET 3.5 framework and it did not work. They should change this to reflect that.
Code Review:
I'm not to familiar with C# but it was surprising to see that it was very similar to Java. I have no idea what the coding conventions are so I can't really say much about that but I was able to follow along with the code without much difficulty. There was a slight error with "VisualStudioSensor - For Testing.Addin." Apparently it was looking for a file that was not there. I checked the installation guide and could not find anything on this file. I really have no idea what this file is for but I was able to run through the rest of the program without any errors.
Bugs:
The few bugs that I found were running more than one instance of the program caused the sensor to crash. I don't know if this is something they never planned for or if it is a deliberate function.
The status bar text reminding you that the sensor was initiated only works when Visual Studios is started manually. If I opened a .sln file there was nothing to tell me that the sensor started.
There was also another bug with NUnit gave some kind of error but this was fixed with the latest release of the sensor.
There is also that Testing.Addin mentioned above ealier.
Overview:
This project installed very easily and ran almost without a hitch. The only problems that I really ran across was a few errors that had to do with multiple instances and basically things that I would do only to "break da bugguh." Other than that, each of the DevEvents worked fine. I was able to open, save, and close files and see it reflected on the project viewer. I was also able to use the other feature and find corresponding DevEvents on the project viewer as well.
Wednesday, March 5, 2008
Ambient code review
Passing the verify:
It seems like a lot of people were having a lot of problems with this and this is mainly our fault. The Junit test rely on the fact that you go in and manually change the test to reflect your information. We didn't annouce that well enough so many people had problem with running the verify.
changing the Color of the orb:
It seems like everyone knew how to change the color of the orb but the main complaint was that it wasn't intuitive nor was it "simple." Only someone that knew the system well or had the system explained to them could probably manage to get this done.
Improvment and suggestion:
I think that the biggest problem that we face in this code is the shear lack of documentation. It seems that a lot of people got lost along the way with just what each piece of code does. We almost assumed that the name of the files would be enough to explain the code itself but it seems that the javadocs were not enough. We need to document the code better so that other can understand what is going on.
Top 5:
1. Latency
2. Documentation
3. too many libraries
4. Verify fails
5. No listing of options with orb
Summary:
A good start but there is definately a lot of work ahead as well as some back tracking with documentation. It seems right now that the code works well with the options that we have but at the same time, no one but us really knows how to use or how the system works at all. We need to fix this by adding more documentation and a fresh interface.
It seems like a lot of people were having a lot of problems with this and this is mainly our fault. The Junit test rely on the fact that you go in and manually change the test to reflect your information. We didn't annouce that well enough so many people had problem with running the verify.
changing the Color of the orb:
It seems like everyone knew how to change the color of the orb but the main complaint was that it wasn't intuitive nor was it "simple." Only someone that knew the system well or had the system explained to them could probably manage to get this done.
Improvment and suggestion:
I think that the biggest problem that we face in this code is the shear lack of documentation. It seems that a lot of people got lost along the way with just what each piece of code does. We almost assumed that the name of the files would be enough to explain the code itself but it seems that the javadocs were not enough. We need to document the code better so that other can understand what is going on.
Top 5:
1. Latency
2. Documentation
3. too many libraries
4. Verify fails
5. No listing of options with orb
Summary:
A good start but there is definately a lot of work ahead as well as some back tracking with documentation. It seems right now that the code works well with the options that we have but at the same time, no one but us really knows how to use or how the system works at all. We need to fix this by adding more documentation and a fresh interface.
Subscribe to:
Posts (Atom)