This week Obsidian continued to make progress towards becoming prepared for POSSCON. When we met tonight, we had a conversation about what we would need for the convention. A table and chairs were to be provided to us, but we planned out what our table would look like. We planned on a monitor mirroring one of our computers, so that we could run demos on popular open source projects for people who come by the booth. We also thought that it might be a good idea to have another computer open to people, so that they can sign up for our mailing list if they are interested in the project. We also decided that we would have our poster prepared, so that we have something else to show at the convention. We also discussed the possibility of creating a little script for the convention. Just something that would echo the command line arguments to run Obsidian on projects. This would create an easy and fast way to run it, without having to type out the lines yourself. We didn't reach a conclusion on this front, as some members thought that such a script would not impress visitors to our booth, because it might seem like we didn't know how to run our own project. I personally think that the idea of a script has merit, just for simplicities sake, but it remains to be seen whether we will pursue this idea.
Next we split up the responsibilities for documentation for the next milestone that is due on 2/27. My personal responsibilities are adding JUnit documentation, and writing about modifying test cases. You can check out the rest of the group's assignments on their personal blogs, or on the wiki for our class. The goal is to have a first pass over the documentation completed by Wednesday.
We also finished solving our second bugs since last week. On Sunday, I submitted a diff file to Hunter so that he can add it to the full project. We decided that we are going to use diff files to continue to patch Obsidian, so we were using this week to standardize the procedure. We ended up closing Issues 7 and 4 over the weekend.
I am sort of struck by a sense of being slightly burned out from investing so much time in the project, and it feels like a lot of the team is getting to be right there with me. It was to be expected as the school year went on and the course load started getting heavier, but it is still disheartening that we seem to be slowing down our progress. I spoke with Hunter about the growing sense of ennui, and he agreed that school was catching up with him as well. I have a feeling that this week is going to be hard to get through, and that we might fall behind schedule here. Since our deadline is so much earlier than the rest of the classes' due to POSSCON, it is imperative that this does not happen. I am going to try extra hard this week to try to push through the rest of my work, so that our project continues to stay on the schedule that we set for it.
Monday, February 25, 2013
Wednesday, February 20, 2013
Line 11: Refactoring Mindset
So, I believe I will start this off by actually talking about some of my experiences at the Alumni Symposium. On Monday, I wrote about what I felt the Symposium would be like, and for the most part I was correct. The speakers had good insight on how to get a job, how to sell yourself, and most importantly how to be yourself in the years after college. There was a Q&A period after the presentations, and they used this time to address many of the concerns that students had about finding and keeping jobs in the industry. The most important takeaway from the whole thing seems to be to just keep learning. Technology is a fast field, and you have to be willing to keep up with the times and learn new techniques in order to be a useful member in a company.
One of the really refreshing things about the symposium was how a few of the recent graduates still seemed to not really be fully sure in their jobs. They say that people treat them like experts, but they have to try just as hard as everyone else to keep up and be relevant. It provided a very humanizing viewpoint on the working world.
There was also a slight discussion about events that we could go to in Charleston to further network with people in the industry. Many were mentioned, but far and above the most important was the Job Fair that we will be having in March. I will definitely be attending this, and will hopefully meet some contacts that will be useful to me in the future.
In Obsidian news, we had a meeting tonight to discuss further bug fixes. We worked as a team to help Joanna figure out her exception handling bug, and I solved my Test Class naming issue. For now, we just gave it a more distinct string to append to the end of class names. We may improve upon this further in the future to make sure duplicate names cannot exist. For now though, the team decided this fix was good enough. We also talked more about the Web App and the website itself, and made a plan to meet on Friday to commit the bug fixes to the project.
Hunter also told us today that we had been granted a table at POSSCON for the 2 days it is running. We will be able to show off Obsidian to local developers, and hopefully gain some more members for our project.
One thing that I am currently worried about is the prospect of having a dead project in the future. A lot of the members of our class have been having issues getting into contact with the developers for their projects, and this is discouraging to them. While I don't want Obsidian to become like one of those projects, I do think that there is a very real danger that it might. We are 5 students, 4 of whom will be graduating this semester. That amounts to a lot of change in the future, so hopefully as we tackle that change, we will also be able to continue to grow and nurture this project.
One of the really refreshing things about the symposium was how a few of the recent graduates still seemed to not really be fully sure in their jobs. They say that people treat them like experts, but they have to try just as hard as everyone else to keep up and be relevant. It provided a very humanizing viewpoint on the working world.
There was also a slight discussion about events that we could go to in Charleston to further network with people in the industry. Many were mentioned, but far and above the most important was the Job Fair that we will be having in March. I will definitely be attending this, and will hopefully meet some contacts that will be useful to me in the future.
In Obsidian news, we had a meeting tonight to discuss further bug fixes. We worked as a team to help Joanna figure out her exception handling bug, and I solved my Test Class naming issue. For now, we just gave it a more distinct string to append to the end of class names. We may improve upon this further in the future to make sure duplicate names cannot exist. For now though, the team decided this fix was good enough. We also talked more about the Web App and the website itself, and made a plan to meet on Friday to commit the bug fixes to the project.
Hunter also told us today that we had been granted a table at POSSCON for the 2 days it is running. We will be able to show off Obsidian to local developers, and hopefully gain some more members for our project.
One thing that I am currently worried about is the prospect of having a dead project in the future. A lot of the members of our class have been having issues getting into contact with the developers for their projects, and this is discouraging to them. While I don't want Obsidian to become like one of those projects, I do think that there is a very real danger that it might. We are 5 students, 4 of whom will be graduating this semester. That amounts to a lot of change in the future, so hopefully as we tackle that change, we will also be able to continue to grow and nurture this project.
Monday, February 18, 2013
Line 10: That could be me in x years
Tomorrow, in lieu of class, we will all be attending the Alumni Symposium for the computer science department. The point of this event is to allow graduates to come back to school and recollect on their first year of work. They cover topics like how they got their jobs, how they are fitting in, and what the school taught them that they found helpful in the real world. The whole thing is to get those who are close to graduating, like myself, some helpful advice for finding our own job in the future.
When I went to Sparc a few weeks ago, we met one of the speakers, Joshua Walton, who spoke to us for a moment as we took our tour. Since I already made contact with him, and Sparc seems like a cool place to work, his will probably be the talk I am most interested in. The other speakers seem interesting as well though. One of the interesting things about this symposium is that it focuses mostly on new graduates, but we have a few veteran speakers as well. I think that the input that they can give would really help me in my future job search.
In Obsidian news, we recently solved a slew of bugs. Last Wednesday we had a meeting to report on our solved bugs, and we each submitted our fixes to the repository. It was heartening to solve a bug, and even more so that each of us managed to solve ours with little to no problems. So, because of me and my group, the Obsidian project is now a little bit better. That feels pretty good. For a complete list of what we solved and how we solved it, you can always check our Google Code Issue Tracker. You will have to search through all of them for the completed ones though.
For next Wednesday we will each have hopefully solved another bug. The one I am currently casing out is Issue 3. We need a better naming algorithm for Test Classes because of discrepancies when programmers have already created a Test Class. The current algorithm just adds -Test to the end of the class name, since this is a pretty standard naming convention, whenever Obsidian has to name a Test Class, there is a high likelihood of it being named something like ClassTestTest, which would correspond to ClassTest.java. This confuses Obsidian, because it will look at ClassTest.java, and assume that it is the Obsidian Test Class, when it is in fact another programmer's Test Class. This causes many inconsistencies, and is a problem that needs to be addressed.
To solve it, I am probably just going to make more obscure naming convention, and refactor some code to make the search for obsidian test classes a bit more accurate. I think that this should guarantee that Obsidian always finds the test case that it wrote, and will solve the problem. I trust that the rest of the team will have theirs done by Wednesday as well.
When I went to Sparc a few weeks ago, we met one of the speakers, Joshua Walton, who spoke to us for a moment as we took our tour. Since I already made contact with him, and Sparc seems like a cool place to work, his will probably be the talk I am most interested in. The other speakers seem interesting as well though. One of the interesting things about this symposium is that it focuses mostly on new graduates, but we have a few veteran speakers as well. I think that the input that they can give would really help me in my future job search.
In Obsidian news, we recently solved a slew of bugs. Last Wednesday we had a meeting to report on our solved bugs, and we each submitted our fixes to the repository. It was heartening to solve a bug, and even more so that each of us managed to solve ours with little to no problems. So, because of me and my group, the Obsidian project is now a little bit better. That feels pretty good. For a complete list of what we solved and how we solved it, you can always check our Google Code Issue Tracker. You will have to search through all of them for the completed ones though.
For next Wednesday we will each have hopefully solved another bug. The one I am currently casing out is Issue 3. We need a better naming algorithm for Test Classes because of discrepancies when programmers have already created a Test Class. The current algorithm just adds -Test to the end of the class name, since this is a pretty standard naming convention, whenever Obsidian has to name a Test Class, there is a high likelihood of it being named something like ClassTestTest, which would correspond to ClassTest.java. This confuses Obsidian, because it will look at ClassTest.java, and assume that it is the Obsidian Test Class, when it is in fact another programmer's Test Class. This causes many inconsistencies, and is a problem that needs to be addressed.
To solve it, I am probably just going to make more obscure naming convention, and refactor some code to make the search for obsidian test classes a bit more accurate. I think that this should guarantee that Obsidian always finds the test case that it wrote, and will solve the problem. I trust that the rest of the team will have theirs done by Wednesday as well.
Monday, February 11, 2013
Line 9: Squashed?
Since last week we have all made progress on our assigned bugs. We should each have at least one ready to commit to the repository on Wednesday at 6:30. Working in Obsidian has made me much more comfortable with the program, and I am beginning to gain insight into how to work with it. My terminology could still use a little work, and I am hesitant to write any official documentation for the project without first running it by Hunter, but I am getting there. That is the important bit.
My bug was to come up with a more comprehensive method for naming method tests, and classes that Obsidian has to create. Formerly, the code was just appending Test to the end of these things; however, this was dangerous because of the frequency with which programmers write test classes with exactly that naming scheme. This would cause Obsidian to confuse itself when it was searching for something like ClassTest.java for instance. The actual test class for this would be called ClassTestTest.java which would not be what Obsidian was looking for. This is a pretty simple fix, but it is an important one none the less.
We came up with a few different ways of naming method tests, but as of yet we have no clever implementation for the Class tests. At first, we were going to name a method following a method that reflected its arguments. For instance, add(int i, int x, String s) would become addTwoIntOneString() when Obsidian had created the tests for it. This has the benefit of creating distinct method signatures for overloaded classes, but we ultimately shied away from this approach. Some members of our team felt that the method names might become too long this way, and opted for a simpler approach.
The new method that we finally agreed on was much simpler. It takes any method name, and basically creates a test method that looks like this Test_<methodName>_#. The number will only appear if the method is overloaded, and from there it increments upwards. In order to make a more distinct link between these generic method names and the methods they originated from, Laryea has agreed to write some code to put a comment before each test method that will name its "parent" method.
This weekend also saw a large expansion in our Google Code Wiki's functionality. We planned out the basic structure last week, and over the weekend I created most of the pages and added information where I could. It also has a navigation bar now, which makes navigating the pages much more convenient. It is really coming along, and it will only get better from here forward.
One slight problem that I had during the creation of the wiki was the state of JUnit. The project seems to be migrating, and their home page is looking quite unimpressive at the moment. They also seem to have removed their source code from where it was being hosted. This was bothersome because it would have been nice to link them on the wiki. We decided to wait a week or so and see if they get it back up before we link to it though.
My bug was to come up with a more comprehensive method for naming method tests, and classes that Obsidian has to create. Formerly, the code was just appending Test to the end of these things; however, this was dangerous because of the frequency with which programmers write test classes with exactly that naming scheme. This would cause Obsidian to confuse itself when it was searching for something like ClassTest.java for instance. The actual test class for this would be called ClassTestTest.java which would not be what Obsidian was looking for. This is a pretty simple fix, but it is an important one none the less.
We came up with a few different ways of naming method tests, but as of yet we have no clever implementation for the Class tests. At first, we were going to name a method following a method that reflected its arguments. For instance, add(int i, int x, String s) would become addTwoIntOneString() when Obsidian had created the tests for it. This has the benefit of creating distinct method signatures for overloaded classes, but we ultimately shied away from this approach. Some members of our team felt that the method names might become too long this way, and opted for a simpler approach.
The new method that we finally agreed on was much simpler. It takes any method name, and basically creates a test method that looks like this Test_<methodName>_#. The number will only appear if the method is overloaded, and from there it increments upwards. In order to make a more distinct link between these generic method names and the methods they originated from, Laryea has agreed to write some code to put a comment before each test method that will name its "parent" method.
This weekend also saw a large expansion in our Google Code Wiki's functionality. We planned out the basic structure last week, and over the weekend I created most of the pages and added information where I could. It also has a navigation bar now, which makes navigating the pages much more convenient. It is really coming along, and it will only get better from here forward.
One slight problem that I had during the creation of the wiki was the state of JUnit. The project seems to be migrating, and their home page is looking quite unimpressive at the moment. They also seem to have removed their source code from where it was being hosted. This was bothersome because it would have been nice to link them on the wiki. We decided to wait a week or so and see if they get it back up before we link to it though.
Wednesday, February 6, 2013
Line 8: This bugs me
Today, Team Obsidian met again to further discuss our POSSCON plans. We finished writing up our proposal for the table, and Hunter is going to get criticisms from Dr. Bowring tomorrow morning. This meeting was very short, and the only thing we worked on was the proposal. I hope that this proposal will get us a table so that we can really open up our project to the community at large.
We have also been given some exercises to complete for class tomorrow. Most of these focus on getting further involved with bug fixes for our OSS projects.
6.4
The oldest active bug on the Obsidian project is the request for a better naming algorithm for naming test classes. The current method for creating them can create a bug when test classes have already been created. This bug will be fixed by creating a new method for naming the test classes that will follow the same flow as naming method tests. The way that it is now, there is just a very static procedure for naming test cases. This bug doesn't seem like a very hard fix, so I have chosen to solve it for my first bug fix.
6.5
This exercise was to create an account on the bug tracker for our project, so that we can solve and create bugs in the future. This exercise doesn't really have any impact on our project because we are in charge of making the bug tracker, so we have all already created accounts for our issue tracker.
6.6
The next exercise was to try to reproduce a bug from our project. I accomplished this pretty easily, because the project that we are running Obsidian on, Common Lisp for Java, reproduces the bug I mentioned before very easily. As part of our meetings this week every member of our team met with Hunter to discuss and reproduce our bugs. During my meeting we discussed strategies for solving these bugs, and we also reproduced the ones that I had taken responsibility for.
6.7
Our final exercise had us perform triage on 5 bugs. This is basically laying the groundwork for solving them, and making them easier to solve as a result. Since we are such a tight knit team, most of these are also redundant activities for us. We classified these bugs according to severity and priority when we uploaded them to our issue tracker, and we are all aware of their effects and scope.
I did find it rather helpful information though, because it let me know that the team was on the right track with our meetings and bug discussions. It will also be useful information in the future.
The other thing that I did today was taking a tour of Sparc. Sparc is a local company that predominantly does software design for the government. They have been branching out into more open software recently, and they seem like a pretty fun company to work for.
Our tour basically took us around their office, and we briefly met a few key members of the organization. The whole office is a large open area with lots of pathways between the teams. They follow the agile approach to programming, and seem to focus on their employees a lot. Overall it was a pretty good tour.
We have also been given some exercises to complete for class tomorrow. Most of these focus on getting further involved with bug fixes for our OSS projects.
6.4
The oldest active bug on the Obsidian project is the request for a better naming algorithm for naming test classes. The current method for creating them can create a bug when test classes have already been created. This bug will be fixed by creating a new method for naming the test classes that will follow the same flow as naming method tests. The way that it is now, there is just a very static procedure for naming test cases. This bug doesn't seem like a very hard fix, so I have chosen to solve it for my first bug fix.
6.5
This exercise was to create an account on the bug tracker for our project, so that we can solve and create bugs in the future. This exercise doesn't really have any impact on our project because we are in charge of making the bug tracker, so we have all already created accounts for our issue tracker.
6.6
The next exercise was to try to reproduce a bug from our project. I accomplished this pretty easily, because the project that we are running Obsidian on, Common Lisp for Java, reproduces the bug I mentioned before very easily. As part of our meetings this week every member of our team met with Hunter to discuss and reproduce our bugs. During my meeting we discussed strategies for solving these bugs, and we also reproduced the ones that I had taken responsibility for.
6.7
Our final exercise had us perform triage on 5 bugs. This is basically laying the groundwork for solving them, and making them easier to solve as a result. Since we are such a tight knit team, most of these are also redundant activities for us. We classified these bugs according to severity and priority when we uploaded them to our issue tracker, and we are all aware of their effects and scope.
I did find it rather helpful information though, because it let me know that the team was on the right track with our meetings and bug discussions. It will also be useful information in the future.
The other thing that I did today was taking a tour of Sparc. Sparc is a local company that predominantly does software design for the government. They have been branching out into more open software recently, and they seem like a pretty fun company to work for.
Our tour basically took us around their office, and we briefly met a few key members of the organization. The whole office is a large open area with lots of pathways between the teams. They follow the agile approach to programming, and seem to focus on their employees a lot. Overall it was a pretty good tour.
Monday, February 4, 2013
Line 7: Bug Juice
When we last left off the team had divvied up duties on enhancing the Obsidian project, and had started to populate our Issue Tracker on Google Code in honest. As we worked and issues popped up, we would log them and move on with our lives. As of writing this, our Issues tracker has 18 total issues, a few of which are our entries for enhancements to the projects, and 4 of which are bugs that we have already fixed.
It was kind of heartening to see progress being visibly made on the project, but the enhancements themselves were very slow going. Most of us are still rather unfamiliar with Obsidian, so coming up with ways to implement the changes without breaking the whole thing was rather difficult. Although last time I said that creating class diagrams of the code had vastly improved my understanding of it, it was apparently not improved enough. Hunter however had no problems with talking out these problems and helping us along with our parts. He also made somewhat stunning progress on his own code, and refactored an integral class to be a bit more generic and better structured.
The delivery date we set for ourselves for this first pass of enhancements was this Wednesday, but when we had our meeting today it was apparent that we were probably not going to make that. Apparently, despite Hunter's valiant efforts, we were still to unfamiliar with this project to be of this much use to it. So, we reexamined our strategy and changed our plans. We decided that Hunter would be in charge of added the enhancements we had discussed to Obsidian, while the rest of us would take more of a supporting role on the project and fix up the bugs that we had found, and that were sure to pop up in the future. We distributed bugs to the group members and made a plan to meet with Hunter to discuss them in depth in the next two days.
The reason we decided to change the duties around this way was mainly to speed up the project. This is because we hope to speak to some of the organizers of POSSCON about possibly getting a table or booth to show off our project. We feel that we can reach a large audience this way, and that would really help our project take off. With this in mind, we have to have all of our documentation, code, and cursory information online by March 27. We are of course shooting about a week ahead of that so that we have a buffer period to finish any unfinished items.
One other small victory that we won was obtaining the Google Code URL for just obsidian. We had previously been at obsidian-unit-test-generator, which was much more of a mouthful. Hunter contacted the owner of the Obsidian Game engine project and he agreed to give us his URL, as his project had not taken off the way that he wanted it. This makes us much easier to find and will hopefully prove useful in the future.
It was kind of heartening to see progress being visibly made on the project, but the enhancements themselves were very slow going. Most of us are still rather unfamiliar with Obsidian, so coming up with ways to implement the changes without breaking the whole thing was rather difficult. Although last time I said that creating class diagrams of the code had vastly improved my understanding of it, it was apparently not improved enough. Hunter however had no problems with talking out these problems and helping us along with our parts. He also made somewhat stunning progress on his own code, and refactored an integral class to be a bit more generic and better structured.
The delivery date we set for ourselves for this first pass of enhancements was this Wednesday, but when we had our meeting today it was apparent that we were probably not going to make that. Apparently, despite Hunter's valiant efforts, we were still to unfamiliar with this project to be of this much use to it. So, we reexamined our strategy and changed our plans. We decided that Hunter would be in charge of added the enhancements we had discussed to Obsidian, while the rest of us would take more of a supporting role on the project and fix up the bugs that we had found, and that were sure to pop up in the future. We distributed bugs to the group members and made a plan to meet with Hunter to discuss them in depth in the next two days.
The reason we decided to change the duties around this way was mainly to speed up the project. This is because we hope to speak to some of the organizers of POSSCON about possibly getting a table or booth to show off our project. We feel that we can reach a large audience this way, and that would really help our project take off. With this in mind, we have to have all of our documentation, code, and cursory information online by March 27. We are of course shooting about a week ahead of that so that we have a buffer period to finish any unfinished items.
One other small victory that we won was obtaining the Google Code URL for just obsidian. We had previously been at obsidian-unit-test-generator, which was much more of a mouthful. Hunter contacted the owner of the Obsidian Game engine project and he agreed to give us his URL, as his project had not taken off the way that he wanted it. This makes us much easier to find and will hopefully prove useful in the future.
Subscribe to:
Posts (Atom)