Closing thoughts

This semester has been a handful and this class in particular has been one of much growth. I have had to assume the role as lead of a group of very skill programmers. Arguably, more skilled and certainly more experienced than myself. Because of this I had to adapt and take on challenges that I didn't imagine I would be faced with going into the semester. It was difficult at times but everyone managed to work well together.

One of the things I've felt was an important quality in a leader was someone that would give people a general idea but would lead them work autonomously so as not to inhibit creativity. Looking back on this experience, I realize that this might not have been the way to go. About halfway through, I realized I needed to stop being everyone's friend and be their leader. I wish I had this same opinion going into the project but maybe that's a lack of experience on my part; this is likely the case.

On the brighter side, I think our team was able to make a legitimate software product and at the vary least, it is a stepping stone to much larger things. We came together when it mattered and although we didn't always see eye to eye, no conflicts ensued. As for being a leader, I've learned a lot about what that really means this semester and that's probably something I really needed. There are things I could have done better, but this is probably always going to be the case. I think in the end I worked with a very talented group of developers and they taught me a lot and I hope they got something out of working with me, although I can't really speak for them. I would say this semester has been one of ups and downs, mostly ups and in all, a success.

Cheers!

Final Presentations

The final presentation went over about how I was expecting, maybe even a little better. Aside from a minor hiccup in the beginning, everyone on the team nailed their part pretty solid. I was concerned that I would forget everything I was talking about at first but that pretty much went away entirely by the time I got on stage, and by Q and A, I felt pretty comfortable being up on stage. Having to present for such a seasoned group of people was pretty intimidating but the positive feed back they gave us at the end was a nice consolation prize.

Overall, I was impressed with every groups presentations. They were all fairly solid and everyone was professional the entire time. Everyone seemed to put a lot of time, effort and care into their projects and pitches which is always encouraging to see. This is especially nice considering I might have to work with some of them one day so it's nice knowing that pretty much everyone is professional and can work on a non-trivial project and have a product ready to ship at the end.

I was disappointed that we didn't win but I don't disagree at all with the judges' decisions at all. Mechanapp and VisualScheduler deserved to win so congratulations to them. In all, I would say that the projects were a success and everyone's pitch was well done.

Practice Pitch Reaction

The pitch has evolved quite a bit since the first practice pitch. At first it was mainly me talking and Justin going into detail about some of the features and while it wasn't terrible, it definitely needed work. The second pitch was similar in that I was doing a lot of talking, but it had more of a "hey, invest in us" feel to it. We got a lot of good feed back and one of the better things we changed about this last one was that everyone should be involved in pitching our app. After all, I wasn't the only one writing code. It also makes the pitch more personal in some ways since everyone has some input and that will hopefully help the audience to respond in a more positive way. We got the intro down to about four minutes I think and with some minor modification on my part, we should do well. I definitely noticed that I was speaking a little too fast at the beginning which will make our audience feel a little anxious so my main goal is to practice a bit more, focusing on keeping a calm and smooth pace throughout my part. That being said, our team has really come together to make this happen and I was fortunate to work with a very competent group of developers.

Leadership

Some people are born leaders, some people are bred leaders, and then there's the rest of us. This semester has forced me to consider leadership in a way that I don't think I was entirely appreciative of before now. In the past, it seems like all I remember are moments of me being the main character in some struggle to save the world, usually a zombie apocalypse, because the Resident Evil series is one of my favorites. I do remember moments of feeling completely incompetent, and in fact, it's probably a pretty equal number of moments of feeling like either the hero or the guy with the red shirt on; just another extra waiting to be cast aside. It's easy to consider yourself the leader because that's what is always spoon fed to us growing up. We will be the Robin Hood, we get the girl, we save the world, roll credits, but life doesn't play out like a Hollywood script. Dealing with people isn't romantic the way it's made out to be when we watch Harry Potter. The reality is, we are all the Ron Weasley. Every last one of us. We are all looking for that chosen one to guide us.

When I first started this project, I was completely in shock when it got picked. Now here I am, having to make the decisions about what color the side bar is and if we are using Times or Sans font, and oh yea what size font please. I've actually been multiple positions where I was the smartest, baddest motha' this side of the Mississippi (yes I sung the song to spell it), then I had to manage 3, three, THREE computer scientists, all of whom I hold in VERY high regard. Gulp. How is Ron Weasley going to deal with three Harry Potters?

This semester for me, has been about the metamorphosis from Ron Weasley to Harry Potter, going from zero to hero in no time flat. We were expected to hit the ground running and when this first project start I knew I was on the right track... then post Spring break hit, and it turns out, there isn't much a consumer would be willing to buy. Sure the framework was there and without me I don't think that would have happened. But now comes the time when we have to make a product people will buy and that was where we should have been all along. We should have been there yesterday. I should have been there 5 years ago. And that's when it hit, "you have 4 weeks to make something people want to buy and you have squat." Engage maximum overdrive, we are hacking machines. Slowly, I see that all along, everyone was just waiting for me to deliver that story that would turn everything around, grab this thing by the short hairs and make some moves, and we did.

This project has taught me about more than just working in groups. Group interaction is no doubt important, but understanding ones role in the hierarchy is as important in some respects. I am slowly realizing that people need direction. Especially in a setting like this where everyone has an idea but only one in the groups is picked. When the hand is played, the winner needs to do what is necessary. Before, I was just tricked into thinking I knew what a leader was. Now, I am the leader of a project that, without my teams help, wouldn't have been possible. And while there is always going to be things that shoulda/woulda/coulda/ been better, we managed to pull off a small victory. We worked together and we came up with a novel idea that DOES have potential to be much greater than it is. Without my team, this would not have been possible and without me this would not have been possible. 

Final Lecture Reaction

Reality that this semester is coming to an end has finally started to set in. Comparing my thoughts of what software engineering is at the beginning of the semester and now, I find that I have a greater appreciation for ability of such an abstract thing like software to change the world. When I first started doing computer science, and in many ways until this semester, software seemed like such an abstract thing. The program was always specified on paper or in a file or it was an idea I had. That was one of the huge appeals cs had for me. That I could make some abstract thing and have it do something even if it was something as simple as the first "Hello world!". Software was real for me because I could see something on the screen that told me that the program did (or more often didn't) do what I wanted it to. Most of the programs I had written up until this time, while interesting for me, were never something meant to be used by other people, it was always for a grade.

Then we get asked to design a piece of software that will change the world. Even at first I don't think I was fully appreciative of what this actually meant. Now, having learned a new programming language, development framework, written my own proposal, spec and presented my software to a real audience with the intention of having people invest time and potentially money into my vision, I feel like I have gotten a taste of what life will be like working in the software industry, even if it's only the appetizer in a three course meal.

Overcoming the adversities associated with the amount of things I have had to deal with; new framework issues, group interaction, and leadership in order to develop a piece of software for real world use has made me appreciate software's ability to change the world and understand what the phrase "Real programmers ship" means.

This week in development

This week was one of sealing up any major holes in our app that needed to be addressed based on the pitch and also on things we promised to have done by the end of the project. The thing that I addressed this week among other things was completing the scoring and ranking system for users of our application. Another thing I worked on was linked the missions to the wizards and also trying to build the story that we are trying to tell the user when the use our application. At this point, the main thing I am concerned with is story of G.E.R.A. and the struggle that the user is a part of when they play or app. I think this innovative approach to gathering user information is the biggest selling point of our application and creating a cool story is what will hopefully win over the crowd.

User Testing

One of the goals for this week, aside from getting the remaining features implemented and partially tested, was to have some people use the app. So far I have shown my app to a few friends and had them create accounts and log in to the live site. This was very enlightening for several reason and slightly change some of the development we did this week. During the testing, I encountered some bugs that we needed to address and I think we got all of the ones that were observed during that first user test. Some other things that were brought to light was how we were presenting the information to people. This topic was touched on a bit during the pitch as well. Specifically, that the missions lead directly to the wizard without any context for what the purpose of the mission is with respect the the story that the application is suppose to be delivering to people.

In all, I would say that we got a lot of valuable information with the first few user tests and I am hoping that between now and our next pitch day, that we will have some more user tests that will be able to help bring to light any short comings that we night need to address. Unfortunately, with only a few weeks left in the semester, any issues that we address must be almost exclusively aesthetic since nothing else should really be changed in terms of implemented features.

Pitch Reaction

Overall, I felt my pitch went quite well. Some of the good things I took away from peoples reaction were mainly that I need to smooth it over a bit. One thing that I also received suggestions on was having some kind of visual aid to go along with my presentation. I absolutely agree with the general consensus on my pitch.

Some things I have planned to do in preparation for the next pitch is to continue practicing it and memorizing it so that I will come out more fluidly and genuinely. It seems to me that the most compelling speakers I have seen appear so comfortable in the situation almost casual but in a very professional way.

One other thing I definitely need to do is make slides that I can practice with someone on my team. This way people have something to follow more easily. I might start off with just black and white slides and some large bullet points that will be important for prospective investors to follow. This way, I can tighten up my pitch while adding a visual element other than the live demo. This will hopefully get people more receptive to my suggestions about why our app is awesome.

I plan to have some themed slides for the final pitch that way to but a nice polish on everything. I also thing that David and Justin have some good ideas about the live demo so that will also be cool.

Preparing for the pitch

For the pitched, I decided to build it around the "goldilocks" method. In the intro I identify a problem that should be addressed in some way and can hopefully be solved in software. Then I describe similar software that are out there. I am careful to make a distinction that there are actually two different categories of software whose goal is to bring awareness to people about their impact on climate change. I note good and bad qualities about both, then point out how our software, while similar to both kinds of climate change related software, is very different in that it bring together the "best of both worlds". I plan to go into a bit of detail about what our software is and does and about the story that the software attempts the get the user involved in. After that, Justin will do a basic demo of the application, highlighting various features. We have rehearsed the pitch a few times so hopefully things will go relatively smooth on Monday.

I also hope that people will give us good constructive criticism so that we can make the application even better.

This week in GERA

This week was pretty busy in terms of getting things ready not only for the client meeting, but also for getting ready for our pitch on Monday. We addressed quite a bit of the user experience issues that were pointed out in previous meetings. This week consisted of implementing and polishing some of the ux stuff like the points system and also creating more of a story and point that will make the user want to continue using the application. This was done by making missions that the user is expected to complete. These missions simply correspond to doing things with in the application like filling in data for the first time or at all, for filling in data that are from previous months, and for improving there overall footprint which means decreasing the amount of carbon the emit in a given period of time. Certain missions are only available to users of a high enough rank. Once they reach this rank, a new mission is unlocked and they can then proceed to collect a point value for that particular mission.

This will not be demo-ed in any significant way during the pitch as it is still in a very early stage of development and demoing it a few days after its design would be a bad idea. However the majority of the sight will be demo-ed during the pitch.

Website Redesign

Introduction

The big thing I worked on in the week leading up to the client meeting with Nikan was website flow and user experience. I decided that since the website is based around gamifying carbon emissions tracking, the theme should be consistent with this vision. After talking with my group members about this, we all agreed that this would be a good idea for several reason. However, because of this redesign, there will be some other issues to overcome that I image Dave will address in this week client meeting. I part of this week has been, in addition to implementing the guiders and making the user experience more enjoyable, I have been trying to think of ways that we can justify or redesign to Ackley in the hopes that we wont be caught quite as unprepared as we were with our most recent meeting with him.
The following sections will describe some of the potential pros and cons to the redesign we have implemented in the hopes that we can find a good way to justify the redesign.

Redesign Pros

The user experience will be much better because, not only does the new theme work well with this, but also because we now have something that an audience will hopefully be able to better identify themselves with.

Redesign Cons

The theme is one in which you become part of an alliance to combat the evil "Big Petroleum" by tracking your carbon emissions. Because of this theme, and the artwork, it may be the case that we are now marketing to a niche group and will therefore not as accessible to some users.

Conclusion

Leading up to this client meeting, we have decided that it is important for us to meet up and present. It is likely that I will be presenting most of it since I am in a sense the letter and that seems to be the group consensus, however, we will all be participating in the practice presentation process, while simultaneously attempting to address these and other issues as we come across them. Hopefully this added preparation will be beneficial. I imagine it's better than doing nothing though.

Action Item

During the client meeting, one thing that Nikan pointed out that Dave had already addressed with the flow issue. One of the major issues we are having with our application is the user experience (UX). David Lochridge had mention something about using the guider.js API to enhance the users experience and I agreed that was something we should consider.

Since I have been in charge of the flow of the website I proposed being responsible for that and as such that was my task for this week. I did run into some issues about how to allow anonymous user to be guided through basic site navigation without having the guider popups continuously pop up every time a user went to a different page. Today I did manage to get things figured out and now it is a matter of styling the guides appropriately with the theme of the website, which we actually ended up redesigning quite considerable.

In my next blog, I will discuss exactly what that redesign consisted of and why we thought it appropriate to do so.

Client Meeting Reaction

Overview

The client meeting with Dave was a real eye opener. It put into perspective that we still have quite a ways to go in terms of our application. I was a little disappoint in myself for not being more prepared for it. Part of the issue I feel was that I was focusing a lot more on the back end stuff and getting the core functionality finished without paying enough attention to the user experience. I do understand that user experience is of central importance to this project, however, I suppose I was expecting the meeting to be focused more on action items that we had planned on presenting. Dave pointed out several issues concerning our application and while I wasn't thrilled with his overall reaction, he made several valid points. The one that hit home the hardest was the flow of the website. We essential have no flow as he pointed out which is a real issue. We can't expect to create a successful application if there is no rhyme or reason behind the navigation. If the application isn't easy for a user to understand and follow, there is little chance they will come back and use it again. Based on this, I have a plan that will hopefully help in creating a more natural flow of actions that will hopefully improve the usability of the application.

Improvements

The first thing I will be doing is going back to some of the websites that track carbon emissions to try and understand better how the user is prompted for information and also understand the general layout. I will take note of my personal preferences for certain behaviors and flows and see if these things can be applied in some way to our application. I am hoping that by going back to the research phase with an emphasis on user experience, that next meeting will be more successful in terms of presenting an application that a user will actually want to use.

Conclusion

The client meeting helped me understand some of the short comings that our application has and where it needs improvements. Dave did say that he felt that we had a lot of pieces which was a nice positive and he is correct in that aspect. We are lacking in the user experience area though which is no good and I feel partially responsible as the application proposer because I should have had a more concrete understanding of how I wanted the user to navigate the site. I focused more on the back end and it hurt this client meeting. I am confident though that I will be able to make some concrete deciscions that will turn our app around and make it a better experience for users.

Guest Speaker Reaction

Introduction 

On Monday, Dave had a guest speaker come in. Jeff VanDyke, founder of VanDyke software and UNM alumni spoke about various aspects of the software development industry as they are practice by his company. Topics like, development methodology and business model were address during his topic. He also answered questions posed by the class and by Dave. His company uses extreme programming for implementing features. He also mention after class when I was asking him questions that they do emphasis testing code however they do not spend too much time dedicated specifically to writing tests for trivial functionality. He also mentioned that ideas are fleshed out in advance although formal specifications are not used. I thought the use of extreme programming and the lack of formal specifications were important enough that I am going to do a "define, defend, attack" analysis of them in how they relate..

Extreme programming: 

Define

An agile development strategy that emphasis short burst of feature implementation known as sprints. The idea is that this development technique is more adaptive to changing client demands.

Defend

Being a CS undergrad seems to breed agile developers. It feels that we are always on the grind and always having to be highly adaptive to our situation based on the work load our professors put on us. This has been especially true of this class the client meetings can be good or bad depending on what kind of demo we have.

Attack

This method of development  has been serving our team well in some respects, and if it used in industry, I imagine it will serve us well in the future. The disadvantage is that I imagine most of us are use to at least a semi formal specification of what needs to be achieved which we don't really have for this project. I have tried my best to define the scope of the project and a specification of features to be implemented however this model has had to adapt based on client meetings so it has been hard finding a balance.

Accomplishments over Spring break

Over Spring break, the main focus of development was on getting as much of the back end built as possible, at least for me. My main focus was on allowing users to enter data into a form that  contains fields dependent on equations defined by an administrator. The focus was on this mainly because most of the overall functionality we are suppose to be delivering for the final demonstration hinges on us being able to receive and store user input persistently so that it can be user for things like gamification features and awards as well as the dynamic charting.

This was no easy task for me as I was and still am learning Ruby and Rails, so some of the conventions have only just started to set in after having fixed some of the bugs encountered in this process. The main challenge was getting formatted parameters to the server from a user. There are still some input validation issues that need to be address all of the calculation functionality is now working the way it should. Another issue Justine and I ran into while trying to integrate the dynamic charting in with the user statistics was attempting to do math on equations that no longer existed. Our database was polluted and so debugging that took a couple hours. Part of the problem was that it only occurred in the deployment environment and so we had to go sifting through the log file to figure out exactly what was going on.

Fortunately, we were able to get these issues resolved. Because of this, the more fun features we have proposed like awards and ranking will now be fairly easy to implement. We did take a bit of a hit in terms of the user experience as was ABUNDANTLY pointed out in the client meeting this week (which will be another blog post in its own right.)

On the plus side, we will now be free to focus almost exclusively on user experience so I am confident we will have something worth our efforts by the final demonstration.

Design Pattern: Active Record

Introduction

Active Record is a design pattern often used to as a means to access information stored in relational databases. Rails explicitly implements a class called ActiveRecord which models this design pattern. This ties back into the Rails idea of Convention over Configuration because Rails exposes its models as classes with methods that allow easy manipulation and access of data fields within a give database table.

Pro

This allows the model to implement behavior that the controller and view shouldn't be bothered with in a clean and scaleable way.

Con

This design pattern might not work well for non-relational databases like MongoDB. However, I do not have any experience with how MongoDB stores and interacts with its data types/ objects so this may not be a valid con to include.

Rails Challenges

Introduction

The past three weeks of development have presented many interesting obstacles that have require creative thinking in order to overcome the challenges. One of the obstacles I have faced is understanding the Rails convention on naming things and how this effects Rails behavior. Understanding the underlying Rails architecture has also been challenging to understand.

Rails naming convention and architecture

Rails aims at a framework that is geared towards development rather than the configuration of the underlying architecture required in order to successfully deploy a web application. Something referred to in Rails references often is "Convention over Configuration." This applies to many aspects of rails including the way things are name within programs. Specifically, when a user requests a web page, Rails uses it's routing infrastructure to determine where to send a user when a given URL is requested. These URL's generally, refer to specific actions in the Controller class of the rails framework. The controller does whatever it needs to which is generally creating instance variables of the various Models that will be used in the View of the web application. This view corresponds to one of the actions in the Controller and so their names correspond.

Conclussion

Rails is indeed a powerful framework for developing dynamic web content. In general, it does most of the heavy lifting in terms of generating a raw skeleton to work with. This, in theory, allows the developer to worry about higher level features and functionality rather than configuring Apache servers etc. The disadvantage to go the Rails way is that it can be potentially slow going in the early stages because of the learning curve associated with learning Rails convention and architecture.

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.

Security

In my last post, I touched on security a little bit from the perspective of the client, the company and more interestingly, the developer. I wanted to elaborate more on this idea in terms of what we as developers are responsible for when it comes to making design decisions, especially when it involves introducing potential vulnerabilities.


Hopefully most of us are at a minimum, mildly security conscious, at least to the point of not INTENTIONALLY introducing vulnerabilities into a system. However, as I discussed in my previous post about RSA, sometimes decisions are made to *supposedly* intentionally design insecurities into a system. What kinds of things do we as developers have to consider when designing such systems?
When we are responsible for the implementation of systems with the potential to effect billions of people what's important? Is it the money? Insuring people that are dependent on them are shielded
from failures? Does anything matter? Should we live in anarchy?


While money is definitely important, at the end of the day, I'd definitely prefer to go home to an average home and drive an average car if it meant I was able to sleep at night knowing that I wasn't contributing (HOPEFULLY!) to the unabashed mass surveillance of practically the entire planet! So for me, I
think designing something with the utmost skepticism for anyone that may potentially use it and also for the people that write my checks (HOPEFULLY! HA that's two) is the best way to ensure that as little collateral damage as possible is incurred. To me, it's more important* to know the things that I build weren't designed to harm them than it is to collect a few extra bucks that I'll probably blow on beer.


At the vary least, it wasn't intentionally. Not that that is not much of a reassurance to clients and employers, but at least I'll be able to sleep at night knowing I didn't sell out.


* I hope I'll be singing this tune 20 years from now but what am I, a fortune teller?

Preliminary Timeline

The following just a preliminary schedule for the Carbon Counter 5000 project. As such, it does not take into consideration any kind of development and maintenance that would normally occur in a real world development environment.

Having said that, one of the design goals from the beginning will be to develop a system that is highly maintainable there by allowing for a potentially higher return on investment for the investors. A real project would definitely take long term issues like maintainability into account when developing a large system and this projects aims to reflect this practice.

Client confidence

One thing that is obviously very important for any company to succeed is the customers' and stakeholders' confidence in the company they will be interacting with. Things that disrupt these relationships can have dramatic effects on the future success or failure of the company in question and software development is no different.


I personally, find security very interesting. When looked at security from a consumer point of view, if a product is insecure or perceived to be, obviously customer confidence becomes an issue. If it becomes such an issue as to be made public and/or widely discussed the confidence of investors and share holders in the company can become a real issue.


A division of EMC that recently came under fire was RSA. Edward Snowden disclosed information implicating RSA in creating software that used insure encryption functions by default on some of it's products. The NSA purportedly paid RSA 10 million dollars to build these insecurities into their products.


When this was made public it had several harmful implications for EMC. The first is obviously that consumer confidence in RSA was shaken. This was observed when several (8) security professionals boycotted the 2013 RSA Conference[Source].


The fact that this news has been made so public, at least in the security community, means EMC/RSA
now face a real problem with their stakeholders' confidence in the financial integrity of their investment since customer confidence has been effected by Snowden's disclosure.


So far we have looked at this issue from the stand point of the client side; the consumers of the software, and the people investing money in the company. One issue that is just as valid but maybe not considered as often is the point of view of the company and the developers that implemented the software. What kinds of things does one have to consider when actually implementing a system with respect to the consumer. What kinds of responsibilities do we  as developers owe a client when making a software system. What kinds of ethics does the developer need to consider when working on non-trivial systems in the real world? Is it more important to have listen to the boss and just add the "feature" (vulnerability) or does one go against this in the better interest of the end user?


This is an interesting topic that is common to many disciplines, not just software engineering but we as developers stand in a unique position as we are ultimately the ones responsible for these decisions. In my next post, I plan to delve a bit more into this topic to really discuss the kinds of issues that a developer is responsible. I might touch on the topics like the difference between the open source versus proprietary paradigm.

Carbon Counter 5000

In deciding on what would make an interesting software project, the first question you have to ask yourself is this, "what do people need?"

Clearly, people love games, but that's been done to hell and back so from a creativity stand point, not an original idea at all. This leads to the next question, "What is an original idea?"

The real problem with answering this question is that if you can think of it, chances are someone has done it. What you really have to do then, is come up with something that may not sound completely origin at a high level but, when viewed more closely, reveals a rich exposure of features that serve novel purposes.

Taking these things into consideration, I came up with something akin to a calorie counter. The difference here is that instead of counting calories, this application allows people to track their carbon emissions. Much like the calorie counter, this application could be used to help people track exactly

how big their carbon footprint is and offer advice on how to adjust it to levels that could help to prevent environmental damage.

In doing research on the originality of my idea, I decided to use summon the Oracle (Google) in order to see if there was anything similar. To my surprise NO ONE has thought of this!!! Just kidding, BP actually has an web-based application that will estimate your carbon footprint. However, they didn't

appear to offer any kind of long term tracking of carbon emissions for users.

After realizing that this kind of functionality wasn't offered I thought, "Wow! that really could be cool actually!" Not only does this application have the potential to be fun to implement, it also allows for a bit of originality in terms of the kinds of feature that could be offered as well as being well within the realm of possibility to implement under the given constraints (time mainly). It also, is designed with helping the environment in mind so not only is it original and interesting, it also has the potential to "change the world", which is very much in the spirit of software engineering as defined by Prof. Ackley.

So without further ado, I present to you, Carbon Counter 5000*. An interactive web based application that allows users to not only track their carbon emissions, but also gives them feed back on ways to improve / minimize their footprint. Users can sign up to have on going carbon tracking as well as anonymous emissions analysis, if a user doesn't want to share information.

* The 5000 in the title doesn't mean anything, I just added it because everything sounds more exciting if you put a big number at the end.

What is Software Engineering?

Having become a relatively new initiate to computer programming ( about 2 years ago was when I started), I have really only started on the journey of professional software development. Before it was function this and for loop that; now it's all "what library has the stuff I need?" and "does this fit into some kind of design pattern." This doesn't even begin to touch on all the aspects of software development and as a starter, a more fundamental question must be asked: What is software engineering?


In sticking with our initial assignment, I read the Wikipedia article on software engineering to get a feel for what it's all about and to get my brain ready for what should be a fun semester (hopefully not too much crying on my part!).


To paraphrase Dave on the first day of class, Software Engineering is the design of software to change the world. (not sure if actual paraphrase or actual quote -___-)


On the one hand, this definition carries quite a bit of weight. "Change the world" is a phrase that wont soon be forgotten and, looking back on when I first started college and even now, part of me wants very much to change the world and I think that if a poll were taken, most college students and more broadly, people in general would love to contribute something that would change the world. While this thought is nice, to me it seems a bit incomplete.


The incompleteness I feel stems from the fact that we as people are inherently selfish and so when someone says, "You can change the world" (or something to that effect), we automatically assume that it's going to be only us that does the changing. In reality, society is huge and complicated and much like a watch, takes more than just one gear to function correctly. Much like the gears of a watch, the people that make up the software development team must work together. Even Bill Gates and Steve Jobs, who most lay-men would accredit computers to, worked with other people.


Wikipedia defines software engineering several ways, one of which is as follows:

"The application of systematic, disciplined, quantifiable approach to the development, operation, and
maintenance of software".

This definition, while less inspirational than Dave's definition, does seem to have a bit more of the engineering flavor to it, but is still lacking an emphasis on the importance of cooperation between individuals to achieve a common goal that would be otherwise nearly impossible if attempted alone.

To this end, my working definition of software engineering is as follows:

The cooperative application of engineering principals towards software that can change the world.