Test Driven Development

Introduction

In following an online tutorial about Rails development, I have come across an interesting idea that Dave seemed to be introducing us to in 351. This idea is development based on testing small junks of code and getting them to function. The term test driven development or TDD as chapter 3 of the tutorial refers to it is the idea that the developer writes tests that initially fail, then implementing the functionality, and getting the code to pass the tests. This cycle can be thought of as
 fail->implement->pass. Trent had also talked about developing in a similar fashion and David Lochridge talked about developing in this way on the final project in 351. I also image Justin Edwards thinks about development in a similar way based on the fact that he and David work together. Either way, considering that Dave and my entire team, all of whom I respect very much in terms of development abilities, have discussed this topic in some form or another, I am inclined to "drink the cool-aide" of TDD for this project.

Cons

I can't imagine this way of development having many flaws. The only one I can think of so far is that it leaves the programmer with a sense that not much is actually getting done since they are focused on writing tests instead of seeing any real behavior.

Pros

It forces the programmer to think about exactly what the behavior and output of the function should be and then commits them to implementing that behavior to achieve the desired output until the test goes from failing to passing.

Conclusion

I would be sold on TDD based on how many times I have heard the term used and the number of people I've worked with use it. From my perspective though, its even more valuable because it forces me to think about what I want the user of our application to see, then forces me to implement the behavior that would achieve the desired results. I image this being a useful tool in increasing my productivity as a developer and ultimately paying off by having a well designed and tested application by the end of the project. Pretty Sweet!

Cowboy Coding

Introduction

Today I learned about another interesting development technique called Cowboy Coding. This technique is a more free form way of going about developing software where-by the developer, not the manager controls many aspects of the design, things like language, algorithms, tools, framework and coding style are all decided by the developers and each developer, at least from what I gathered, may choose different combinations of these dimensions for a single project.

Pro

Developers have more control over many aspects of the project and don't have to look over their shoulder as much as a developer in a more traditional setting might have to.

Con

This technique is often used as a derogatory term for inexperienced developers that do not conform to the status quo of the software development methodologies community.

Reaction

My initial reaction when I first heard about this methodology (which was about two hours ago) was one of curiosity. It seemed interesting to me but sounded a lot like extreme programming or SCRUM. As I read the wiki, I began to find similarities to our projects at the beginning of the semester when we were all hashing out ideas for projects and choosing the technologies. However, I started realizing that, as time progressed, we started to solidify certain aspects of our projects which seems counter to what cowboy coding is all about. Because of this and because it doesn't seem to me like any substantial project could possibly get done with out some kind of organization, I have to agree that cowboy coding would definitely not be my choice for writing a large piece of software.

Conclusion

Don't be a cowboy coder. People will call you a n00b and make you cry :,(

Pinning done scope

The first meeting with Nikan went well and I am also looking forward to hearing what Dave has to say about our project and what needs improvement as I am sure he and Nikan will be doing. In the mean time I have set of a share gdrive with my team so that we can create the schedule that Nikan wanted us to make as part of our action items for this coming week. In addition to starting the spread sheet, I have added a document that will hopefully be helpful to the team in terms of helping us to understand exactly what kinds of emissions we will be considering. (e.g., Natural gas, electricity, gasoline etc. ) In addition, I am working on the action item I am responsible for this week which is to define exactly what is being gamified in terms of user statistics / rankings and how we plan on doing this. I will also be sharing this with my group in the Google drive so that everyone else knows exactly what my vision is although I hope they will give me constructive criticism and feed back on anything I may be missing.

Project Selection Reaction

I was very surprised and a little nervous that my project was selected. I was surprised in the sense that there were so many good projects to choose from and because of this, I was quite flattered that mine got considered as much as it did. I am nervous because now I feel even more responsible for helping my team succeed in accomplishing our goals. Considering it is my proposal, I am also on some level the team leader since I have the most knowledge in this subject. (Which isn't saying a whole lot at this point.)

The nice thing is that I have a strong team to help me in this project. I have worked with David Lochridge in 351 and so I already have an idea of what to expect from him. He is very hard working and I am excited to get to work with him again.

I haven't worked with Justin before nor Trent but both of them have reputations for being good programmers and smart people so I am also very humbled and feel like in some ways I might be the weakest link. I hope that this since of humility will allow me to do an even better job of helping the team and will motivate me to try even hard so that we may succeed this semester.

While I may not have as much experience as Justin, David or Trent, I am confident that my work ethic and dedication will make up for any deficiencies I may have in terms of coding ability. I also feel that I have certain characteristics that will help me to be a good leader. Not to say that I AM the leader but it feels somewhat implied seeing as this was the project I suggested. I am excited to have the opportunity to be working with people that I respect and feel that I stand to learn a lot this semester.

In all, I would say that so far the team I am a part of will meet all of the attributes I describe in my post about ideal team attributes, although this remains to be seen.

Choosing Projects:

One of the hardest things that I have encountered while trying to pick my top 5 projects for the semester long project is finding a balance among many of the following themes: plausibility, interest, societal impact, and potential team members

Plausibility:

In the context of this class, plausibility is the likelihood that the project is something that can actually be done given the time constraints. Taking my work load in other classes into consideration, I have found, has greatly impacted which projects I find myself wanting to choose. On the one hand, there are really interesting and potentially fun proposals, however, these proposals appear to be quite involved and may run the risk of being so hard that 11 weeks just isn't enough time to actually have a polished application at the end of the semester. This is unfortunate as many of the project that are interesting also appear to be out of scope. It is something that is really hard to judge because it isn't completely clear how much of the technology is already out there and may just need to be retrofitted in order to create a useful and interesting application.

Interest:

This category seems to pretty much be going hand-in-hand with the Plausibility aspect of many of the projects. I have found that many of the interesting projects that I can see myself wanting to spend hours hacking away at, are also the projects that have potentially much lower chances for success. This is kind of a bummer because honestly, who wants to do something boring? Hopefully NO ONE!!!

Societal Impact:

This aspect is also important simply because it doesn't make sense to work on something that is just going to get thrown away right after the semester ends; what a waste of time! Fortunately, many of the projects that had a fair balance between my interest in them and my perceived plausibility of them also seemed like they had the potential of actually being useful beyond their creation in this class. Of course some of the easier or less original projects didn't seem to have as much potential but that goes without saying I suppose.

Potential Team Members:

This is probably one of the most important dimensions that I find myself taking into consideration when deciding what my top 5 will be. This is simply because, although I am a fairly patient person, I do have my limits like anyone else. Image having to work on even the simplest of projects with a dysfunctional team; not my idea of fun! I wouldn't even mind doing one of the harder projects as long as everyone on the team, at least some some degree, was able to compromise and could get along. This is also probably the hardest to judge for at least two reasons: the first is that I don't really know what projects the people I want on my team will pick or in what order (not to say that we haven't been trying to game the system,) , and second, even if we all chose the same projects, there is no guarantee that other people I DON'T want on my team will somehow have overlapping preferences and I may get stuck with them. This has definitely been one of the hardest things to take into account when choosing my preferences.

This project, like any project worth doing, requires a fine balance between many things and I have only touched on some of the things that I have been taking into account while choosing my preference list for the projects.

Scaling the Internet:

One thing that I thought was interesting when Dave mention indefinite scalability had something to do with IP address space. This got me to thinking about what kinds of issue might be encounter when attempting to scale IP beyond even the 128 bits used for IPv6 addresses. One of the problems that I came to realize in thinking about this was the fact that you can't simply tack on some extra bits in the most significant bits of the address or something like that. The  problem is that the NIC  has finite space to buffer data onto it. Just imagine growing IP addresses to the point where the number of bits required to represent an address exceeded the number of bits in the NIC's ingress buffer. How would this problem be fixed?

To be completely honest, this may be a completely crazy question considering the fact that you could assign every particle on planet Earth an address in IPv6 address space. It's definitely a fun idea to think about none the less.

Proposal v2

The link to my final proposal can me found here. One change I decided to do was to restrict the focus of the application towards individuals, instead of trying to cater to both individuals and businesses.

Proposal Review: Dan Green

The following is for my review of Dan Green's project proposal.

Proposal Review: David Lochridge

The following link is for David Lochridge's Cloud Conference Board project proposal. Overall, this project seems like it would be very interesting to work on, however, it also seems that there is a lot that needs to be done so the idea might need a bit of refinement.

Design Pattern Response

One thing I found interesting while reading the Wikipedia article is that very abstract concepts like concurrency also have design pattern principals applied to them to describe recurring things. The one I found very interesting was the idea of a Scheduler.

So what exactly is a scheduler? 

Scheduler:

The scheduler pattern is an object that explicitly sequences waiting threads.

What is good about this pattern?

It allows for many different programs sharing limited CPU time and space, to be scheduled, and have their code executed. It is also designed without a specific scheduling policy, which allows the implementer of this pattern to design the policy based on the situation.

What is bad  about a scheduler?

According to Wikipedia, this design pattern comes with significant overhead, which may be undesirable depending on situation.


I am having a difficult time trying to think of ways to attack the scheduler pattern since it doesn't seem like multitasking operating systems would exist without the concept of a scheduler. Then again, I'm sure there is some crazy alternative that I am unaware of that would totally blow the scheduler away?

The 3 MOST Important Teammate Qualities

The following list describes 3 qualities that are most important for a teammate to have when going into a long term development project.

Compromising:

In any kind of relationship, both personally and professional, the ability to compromise or come to some kind of agreement is of the utmost importance. Without compromise, people begin fighting about whose idea is better and since no one is willing to back down, nothing gets done. It is absolutely necessary that a teammate be willing and able to compromise. In any situation, especially software development where there are potentially uncountably many ways to solve a given problem, one of the first steps is deciding on a means by which the problem will be solved. From the kind of language, to the specific implementation of a function or object, if team members cannot come to some kind of a compromise on the implementation, nothing will get done.

Reliable:

Reliability is another trait that everyone must have in order to accomplish a given task. If team members are unreliable, code doesn't get written, people start fighting and blaming each other and nothing gets done. A reliable team member is, at least to me, more important than a skilled one. If a skilled team member writes some code, then doesn't show up for the rest of the development cycle, if any problems in the code appear or if it is too complicated for other developers to understand, then the project will see a slow down as the other programmers attempt to understand or fixed the problem code. At least with a less skilled but more reliable team member, if something goes wrong, they are there to fix it or at least assist in fixing the problem.

Congenial:

Having a team that is made up of nice people that can get along goes a long way in being able to get a project done. If the team can get along well, then they will be able to spend longer periods of time together coding, or designing new features or models for a system. A team that doesn't get along will have a harder time because they will be at each others throats at every turn. Being able to get along with people is a valuable skill in any context, especially team oriented ones.

The following is a description of the three other team member qualities that would be nice to have in a team, but aren't as important as the ones described above.

Skilled:

Having a team member or two that are very skilled in at least one aspect of a project can go a long way in terms of ease of implementing a project. Instead of having to constantly Google, information or read through countless forums with little results, having someone skilled in a particular area can help prevent simple mistakes from being made that end up costing lots of time to find the answer to.

Eager:

If team members are not eager to begin working on a project, then it is likely that they will not try very hard to come up with a solution to the problem. Eager team members are excited about the project and want it to succeed. They will devote more time into the project because they enjoy it and because of this will make a better end product. And if they don't, at least it was a good experience instead of being stuck with @$$holes. I would also assert that having an eager programmer is, at least in some ways, better than having a skilled one who is not as excited about the project. The programmer that is excited is also more likely excited to learn new things and will be a bigger asset to the team because they are willing to put in the extra time to learn new things instead of assuming they are some all known hacker.

Drinks:

How else are we suppose to celebrate a hard fought battle of programming endless hours, banging our heads into a desk and throwing our notes and papers everywhere if we can't sit down together at the end of it all, through back some drinks and enjoy a job *well* done?

Proposal Review: Justin Edwards

The review for the ViciniChat proposal is up here. This seems like an interesting and challenging project and I feel there is a lot of room for growth as a programmer for the team picked to work on it.

Final Proposal

The following is the link my final proposal.