Wednesday, May 14, 2014

Another one bites the dust...

I am super stoked on what groups were able to put together by the end of it all.  Typically in classes like this there is one group that stands on stage and shows off their unit tests because they have nothing.  I was pleasantly surprised that this did not happen.

One group that I believe did not get the credit that they were entitled was PowderAde.........Oh uh Carve Companion.  This app is dope!  I am going to bug Brandon until he lets me put it on my phone.  Just making an app is a super impressive feat.  I have tried my hand at it and when my Hello World app crashed for a week, I said screw it.  Their application is solid and I am really going to use it this coming snow season.  Hell even at the skate park.  They really put in a ton of work for the Google Play and Google Map integration and for that I give them props.

Well another semester is gone and I can't say I am not glad to see it go.  Last semester I told myself "next semester is going to be cake compared to 351".  Now this semester I am saying "next semester will be cake compared to 460".  **Commence infinite loop**.  This was way harder than I thought.  This was actually probably my hardest CS class.

 I am not a business man at all, I am the troll banging on the keyboard.  At least I want to be.  This class really opened my eyes that funding comes from somewhere and this is what you need to do to get it out of investors/customers pockets and into yours.  I learned that no matter what, you must sell yourself and your product.  People will not see that you wrote a project in Erlang and just throw money at you.  Ok maybe they will, but still.  Now I know what needs to be done to sell a product to someone who has never seen it.  I have also made huge progress in writing.  By doing so much writing with the pitches and the reviews and the evaluations, I am now much better at doing things that I will be doing at a company for the rest of my days.  Now I really see that changing the world through software is not just changing the world through software.  It's coming up with an idea, developing it, convincing people this is a good idea, trying again to convince people this is a good idea, coming up with a business model, theeeeeen changing the world through software.  This is quite a daunting task for most of us, but we all pulled it off.

Congrats to Mechanapp for their second place victory.  Those guys are solid talent and they earned it.  I am excited to see if they keep going with the application, or if they drop everything and enter into the job market.  Either way, they should be very proud.

Thanks to my team Dan, Zach, Kellen, and honorary member Katie.  This app would be nothing without you all.

A huge thanks goes out to Professor Ackley for kicking my ass in 251, 351, and 460.  I have gained more knowledge and lost more sleep than I knew was possible.  By being such a tough teacher, he weeds out the "tourists" as he would say, and pushes everyone else to give 150%.  After every class period, I felt like I gave 3 pints of blood, but I am a much stronger developer for it.  


Tuesday, May 13, 2014

We Did it

I cannot believe that our project was picked as the top software engineering project of 2014.  I feel that the whole thing came together very solidly.  I was nervous at first since our project was not evaluated on the content, but on the quality of the speech.  One thing is for sure though, I am so glad that we had two practice pitches before this one.  The biggest benefit in my mind is that it gave us a chance to really nail down our timing.  If we had gone on stage today and been four minutes short on our talk as we had previously done, we would have had no chance.  The practice talks got us very comfortable with our speeches and I was not nearly as nervous for today as I thought I would be.  We have a long way to go though.

I do believe that we can use this application to change the world through software.  In fact, with our winnings, I believe that we are going to upgrade our Amazon server and try to get this thing out by October.  I feel that by winning today, we have made a great impact on the class and now we must make an impact on the rest of campus.

A big thanks to Professor Ackley, the guest judges, and my fellow students for this class.  It has helped me grow as a Software Engineer.

Tuesday, May 6, 2014

Bug Whisperer

One of the biggest things that I have contributed to my team through this whole project is being able to break things.  I have been able to find many issues with our project (and I am continuing to).  This is I have managed to find bugs and unexpected behavior that my other ream members have not noticed, which we have fixed soon after.  This is helping our project be more solid and ensure that we do not have something terrible happen during our presentation.

I did have an interesting scare the other day.  Brandon Lites asked me if we are sanitizing our SQL queries and I looked at him like a deer in the headlights.  After convincing him not to do some horrible SQL injection on our project,  I brought the issue up with my team.  We did some research thinking that we would have to write some kludge in back end to make the site less vulnerable to attack.  Not so.  We are using Hibernate as our Java Persistence framework and it actually sanitizes queries for you!  Looks like Bobby Tables won't have a problem attending UNM (ha).

 On a serious note though, we learned an important lesson from this.  This class is about designing software for the real world and getting us ready to go from school to shipping code to a customer.  Now, in school we have never really had to worry about security issues like this, the goal has just been to get the project finished.  In the real world, if we had shipped a product that was vulnerable SQL injection, I am sure that it would be exploited in less than a day.  Even though Hibernate took care of the vulnerability, it was a reminder to keep security in mind and always stay sharp on how something is implemented.      

Thursday, May 1, 2014

Thoughts On Continued Development

So, it has been a topic that had been brought up a lot so I figured it was worth mentioning.  A lot of people that I have talked to have expressed interest in using the VisualScheduler application and have been asking for the URL.  Most of them have also said that they would definitely pay five dollars a semester for our schedule generator.  Zach has showed the application to a UNM recruiter and they were very impressed with the application.  She gave us the name of someone named Cinnamon Blair to talk to about money and if we will be allowed to make profit off of the application.  I firmly believe that if we talk to UNM about making profit off of the application, people will use it and it will be successful.  Soon in the future, we plan to get more server space than the micro instance we have right now so we can support many more users.  One of the starting places to kick off the application will be the UNM subreddit to get the word out to other people at this University.  We will also be setting up social media pages soon to get people involved with the application.  I do not see a reason why UNM would provide something like OpenData if they did not want an application like this to be made, so I feel as though me and my team have filled a giant hole in the registration process.

Monday, April 28, 2014

Misc. Ranting

Presentations

The last day of presentations are over and everyone really improved. Here are a few of my reactions to the pitches and the projects in general.

Automaton:
I really liked that this team made a project that they basically built from the ground up.  Talking to the team, it seems like the only technology they used was node.js everything else they made.  Seeing the final product, I was impressed with how much work they did in so little time.  Another thing I noticed is that the majority of the speech is a demo.  That really isn't that big of a deal I mean they have a lot to show and the point is to really show everything the application is capable of, right?  It would be nice to hear some a business plan or something that tells me how they will maintain the application because I am kind of curious.  The game itself is a little confusing, but its a cool idea and I really like it.

VisualScheduler:
Basically, I wanted to do a small review of our pitch just to write out some changes we should make.  I thought our pitch went well.  Way better than I thought it would.  Some things that I would change though is that we really need to talk about our technology.  We are using so many different libraries and languages, I think it would be neat to mention.  I have programmed in Java for years and we are using things that I had never heard of as of a few months ago so I feel our audience would like to know what was happening under the hood.  Ackley also made a good point today about having a time with us during our presentation.  If we had had one, then we would have been able to tell that we were short on our time and blab for another 40 seconds.  Another good point was to really push the schedule generator.  This feature is a main part of our business model and is really cool.  Talking about if for ~30 seconds was not nearly enough and selling that will be a big move for us.  I really want to win the best project and with our final talk, I think we can really drive that bad boy home.

G.E.R.A
This is a project that I think people would be into because "going green" has been the latest fad (for lack of a better word).  For me, I can't really see myself using it just because it is not really a topic I care about.  Ben is a good public speaker and, though there were a few bumps, he is animated and engaging.  I don't mean to sound overly pessimistic, but there are a few things about this application that rub me the wrong way.  I am not the biggest fan of the website layout.  It is not bad by any means, I just think it could be done a little cleaner and less clunky.  I really want to see what the missions look like to.  One of the big selling points of their pitch is that many applications are simply data entry.  For me, I can't really see how it wouldn't be merely data entry so I would love to see a small example.  Overall, their pitch was very solid.

Thoughts on the Team:
I am very happy with the team that I worked with.  Everyone worked super hard and gave it everything they had to make an outstanding application.  We worked very well as a team and, even though there were some disputes, we were able to back the final choice and make it work.  This project was a ton of work, but it was a great team experience and a great learning experience.  Dan and Zach know so much about programming and I was able to use the past few months to pick their brains and learn a ton.  In a few short months, Zach went from never looking at a line of Javascript to being a master of Javascript and AngularJS.  It is obvious that he put a lot of time and research into doing what he was assigned and doing it well.  Dan was the duct tape for the whole team.  No matter what part of the project I was working on, I was able to ask him what my next move should be and he always came up with insightful information.  Kellen came through with the static web pages and made them look exactly like the mock ups.  The biggest benefit of this project is that it is Dan's baby.  He is so close to the project and wants it to succeed so bad that he killed himself and made us to the same to make it perfect.  No matter what, there was something that Dan wanted us to do better which really helped to make the application what it is.



Wednesday, April 23, 2014

Final Push

It's almost time to call it a semester, but there is still a lot to do before we are done.  We have run into a couple little bugs that we need to fix to make our project sturdy and reliable.  One thing that I was surprised by is that screen resolution can really mess things up.  When using existing applications on my phone, laptop, and desktop the application always magically scales.  Sometimes not super well, but pretty good.  When trying our application on different devices, a lot of the styling gets really messed up.  It has been harder than I thought to fix this problem.  In fact, before trying the application on different devices, I didn't even know that this would be a problem.

Another very unfortunate bug that we have is that whenever we try to access our site from a phone's browser, we get an error saying that this type of address is unsupported.  I again did not think that this would be a problem.  I just figured that a browser was a browser and it should work.  Even though I carry my laptop with me everywhere, I really hate having to pull it out and I always search the web on my phone.  If this is going to be a practical application for college students, this issue needs to be resolved since students practically live on their phones.

The schedule generator is going rather well.  I have always struggled with JUnit testing, but I wrote some tests for the generator that make us pretty certain that it is functioning correctly.  These tests are not as robust as Ackley's tests (whose are?), but I am trying to get to that point.  One weird issue I ran into with making tests is that for the meeting time, start date, and end date, we are using the java.util.Date class.  When my test was receiving the JSON object from the backend, Jackson was unable to parse the fields of the JSON into these Date objects since we did it in an odd way.  After some internet research, I figured out that I needed to make time and date deserializers so that Jackson knows how these fields should be parsed into Dates.  This made the test suite work and I was then able to use assert statements to make sure the object was correct.

I am excited for the demo on Monday and I think everyone is going to be really impressed.  We really need to meet our time limit this go-round and talk about our business model.  If we have a killer presentation, I have the utmost confidence that our project will be selected as the winner of this semester.

Monday, April 21, 2014

2nd Round Of Presentations

Overall, everyone really stepped up with their second presentations.

Mechanapp:

This group delivered a solid first presentation, but showed a lot of improvement in their second one.  I really liked how James and Alan switched between talking and shedding light on different parts of the project.  Also, the demo was much improved and really gave a great flavor as to the usefulness of their application.

Demigod:

This group still has a long way to go,  but they were again much better than their first performance.  It is obvious that Matt does not like presenting, but the always acts lively to get the audience involved in the presentation.  Having a demo this time really helped me stay engaged rather than just watching a video of how it worked.  The only thing I noticed was that the other Matt (running the computer) was biting his nails the entire presentation and was really distracting.  Hopefully there is a challenge on their application to help people quit nail biting.

Powderade:

The presentation was much more engaging since the group was presenting and not on a video the entire time.  Contrary to what Ackley said, I did not find it to be that big of a deal that the snowboarder and the application demo did not match up.  I thought it was cool just to see the numbers change while someone was snowboarding.  If the video worked smoother next time around, I really liked the direction that there presentation went.

Friday, April 18, 2014

Progress Report

So we had our meeting on Wednesday with Ackley and he seemed pretty distraught that our schedule generator was not started.  He did have a valid point that it should have been completed earlier, but it will not be too difficult to implement.  All this feature is going to do is take the classes a user inputs and show them how they fit together.  That's it.  It will not be looking for all art classes that fit into a specific time and that are for seniors or something, we are just showing conbinations of exact classes.  While writing the backend for this feature though, I did realize that we made a huge mistake early on.

I think all of us were really excited about our project and were ready to get to hacking.  It turns out that that was a bad idea.  Obviously, teachers are always saying "develop requirements" and "develop a program structure" which is where we failed.  We did establish requirements and talk about structure somewhat, but not nearly enough.  We neglected to think about our future features and now implementing them is a pill.  If we had planned out our design more, the features would just fall into place, but it does not really feel as though that is the case.  I am hoping to do a large refactor to make the code more abstract, modular, and maintainable.   

Friday, April 11, 2014

Calendar Joy

Well I have been looking into the calendars that we can use for our web application.  I think I have decided that the Angular UI calendar is the best bet.  With the Google API, from what I gathered, even if we don't want to access a user's personal information we still have to authenticate them with Google.

Writing a calendar for the application has been really difficult.  I have been working on back end development for the majority of the project and I have been having to learn Javascript and Angular JS in a matter of days.  Javascript is similar to Java, but the scope is really messing with me.  I have been confused on what can be accessed, who can see variables, and so on.  I have been writing a calendar, but I am unfamiliar with this language so I am getting errors that I have had no idea how to solve.  The majority of my time has been spent on Google trying to debug something I don't fully understand.

As we approach the end of the semester, the thought that this project may not get done is scary.  We have so much to do, and no time to do it.  It has been really difficult having a team mate who lives out of town (and similar issues) to have team meetings because we do not meet nearly as much as other teams.  I feel like this is the cause of our lack of progress.  We have had a lot of hardships on the team and it has been tough to accomplish anything effective.  Hopefully, we can work hard to get the project done, but I wish we had more time to make it great.

Wednesday, April 9, 2014

Progress Report

Well, its the Thursday before our demonstration in class and we have a lot of work to do to get where we need to be.  We have four days to get a calendar up and going to add classes to, as well as allowing a user to accept a schedule and obtain the class CRNs.  The calendar is not as clear cut as we thought it would be and we are considering different technologies.  I know, it's way too late to be doing this.  We have been looking at Google Calendar API as well as the Angular UI.  The Google API is rather complex and would require our users to have a Google account to use the application.  The Angular UI is simple, but is hideous.  If we want to have a great UX, then the Angular calendar needs a visual overhaul.  The cool thing about the Google Calendar is that is can send push notifications to the user.  This would be so sweet!!! Also, we can communicate with the API using a REST interface, which is already all set up.  It would be trivial simply sending the API a POST request with the JSON that a user would like to add.  The Google API is what I am leaning towards, but we will see how it goes.

Sunday, April 6, 2014

Backend Finished

Well, it happened way way later than we would have liked but the backend is done.  Anything that the user wants to search like courses, instructors, etc is supported. This should have been finished way earlier and we are now down to the wire on finishing the application that we promised.  Our meeting with Ackley the other day made me realize how much we have left to do.  I am now being moved to the front end and have been doing hours of internet research to catch up with the rest of my team on AngularJS and Javascript.  I feel I have a good understanding of the framework and, luckily, I have usede MVC for many projects in the past.  Since AngularJS basically forces an MVC architecture, I should have no trouble catching up.  I am excited to make things look great for our user and to contribute to an outstanding user experience.  

Monday, March 31, 2014

The big UX

User Experience

Well after devoting the majority of my blogging time to the actual code and development, I think it is time to talk about the user experience that we are trying to achieve.  So we have some mock ups of what the site design will look like and, from my client hat point of view, I really like the design.  It has a very professional feel to it as well as being very clear and concise.  The help section is very clearly marked and easy to find in case the user is unsure of how to use the product.  Below is a link to see what we have so far as far as mock ups go, and implementing the site to look this way is currently in progress.

UNM Visual Design Mock Ups

The user experience of this product is significantly better than what UNM is currently using for purposes of scheduling.  Personally, every time I have made up a schedule on the UNM website, I search my classes beforehand and jot down the CRN numbers and times of classes I need to take in a spreadsheet.  If I am registering and a class I put in my schedule is full, then I basically must rush through this whole process again to rearrange my schedule.  The UNM Visual Scheduler improves user experience by having all the necessary tools for a user in one place.  With a built in calendar and schedule generator, this whole terrible registering process becomes automated and all the user has to to is choose their preference of schedule.  In my mind, the design is clean, elegant, easy to use, and will provide people the information they need in a readable format.  Once this design is implemented, I know that our users will keep coming back semester after semester.


Saturday, March 29, 2014

Progress Report

Progress

Well after only about 4 hours in Starbucks and being pushed into buying a hobo lunch, I have made a significant amount of progress.  I got the backend returning any kind of entity that a user specifies and performing accurate database queries.  I had accomplished this before, but it had a very brute force feel to it that looked terrible and was hard to follow so I am slightly happier with this new implementation.  There are some repeated parts of code that look very copy-paste and I have been trying to think of a way to further abstract this.  For now though, there is a 95% working implementation.  I must still implement this to work with specified meeting times and instructors, but for now it seems to work well for everything else.

The progress is looking good for the demo on Wednesday and I am hoping to really impress Ackley.  After hearing about some of the meetings that other teams have had, I am nervous about the cosmetic appearance of our application.  I do feel that our mock ups will help us implement a site with a friendly user experience and nice flow.  I am super stoked about how programming went today and am excited for the rest of the team to check it out and provide feedback.

Tuesday, March 25, 2014

Progress Report

Progress

I have made a backend that can construct queries to the database based on how much or how little information is provided to the backend.  As of right now, it returns only section entities, but will soon return any type of entity that is specified.  Integrating the backend with the angularJS frontend, however, has proven to be more difficult than expected.  It has been hard to get the front end to actually make a post request to the backend and it doesnt appear that they even talk at all.  I have written a small test class for the backend as a proof of concept, but I am hoping to have the front and back end communicating for the demo tomorrow.

Saturday, March 22, 2014

Progress Report

I've been trying to get back into the programming groove after spring break and it has honestly been hard to get motivated.  I have been thinking of how to implement the backend in an abstract way rather than having to brute force all the possible queries a user can make.  I have found it hard to find a pattern in all of the data and have been doing a brute force approach right now to hopefully figure out how to abstract all of the code.  I am also trying to figure out how to construct queries with meeting time and instructor as this data is not directly correlated with classes in the database. Hopefully this will be finished in time for a killer demo on Wednesday.

Sunday, March 9, 2014

Progress

Progress

I have been working on making the Model and Controller for the unmvisual project.  I was hoping to get this done by the weekend, but it turns out that I went down a rabbit hole all day yesterday and was not able to get anything concrete accomplished.

In doing this though, I learned a lot about how JSON objects really work and I have a great idea to get this part of the project done.  Using JPA 2.0, if an argument that is accepted into a function is defined as JSON in the annotations of the method, it will be automagically parsed and made an instance of said object.  I did not realize this and worked on making a JSON string parser which took hours and was a waste.

I really want to up the pace of our project as it feels like we have been stuck where we currently are forever.  If we can get the front end and back end communicating properly, then we can all dog pile on the javascript front end and focus on making it look as pretty and be as user friendly as possible.  The fact that most of our project is in javascript is mildly unnerving because none of us have ever written any javascript, so it will take some time to learn.  




Saturday, March 8, 2014

Midsemester Evaluations

Evaluation of Myself

 I am nervous about writing my midsemester evaluation and trying to convince somebody that I have been working hard.  To me, I know I have been working hard and making progress to benefit my group, but convincing someone of that is not as easy as it sounds.

When it comes to the project, I have been working on it at least a little bit everyday.  Progress is slow but that is because the technology I am working with requires a huge learning curve.  I have never worked with the Java Persistence API, Jersey, Maven, JSQL and many other technologies that are key in my role of making the backend.  I have put a ton of research time into learning these technologies and have made many little proof of concept programs to really figure out how they work.
Yesterday, I did some test programs with constructing JPQL queries using JPA 2.0 and I am going to implement what I learned in the backend today.  


Friday, March 7, 2014

Progress Report

Progress Report

Well today we had our team meeting with Ackley and, unfortunately, I missed it.  I was working late on the project and slept through my alarm.  This is the worst thing that could happen because I had a demo ready to show about what me and the team have been doing so I feel as though I let them all down.  This is very unprofessional and I should have come up with a plan to ensure that this didn't happen.

On the bright side, I have successfully made a JerseyTest that calls the backend and can send JSON objects back and forth.  Also, the backend is able to successfully query the database and return a JSON. Right now, the backend will spit out everything in one table and only accepts path arguments.  As the front end will be making very specific queries, the team and I were thinking of sending the request as a JSON to the server using the POST method in REST so that the URI does not get too long or complicated.  From what I have read, it is common practice to send large queries as POST requests so this should not be considered bad practice.

To query the database, I am making a JSON parser using Jackson to parse these large JSON queries from the front end.  The trick is going to be constructing a JPQL query from the relevant information provided.  This part of the project should, hopefully, be done by the weekend.    

Wednesday, March 5, 2014

The Frustration Ensues...

Progress and Problems

At the last meeting, my task was to make very simple queries to a database based on a request from the front end.  This has not been going well  My problem right now is a never ending circle of dependency issues.  It seems like every time I start up the project, something new is broken and I am wasting hours fixing it.  Hopefully, these will get resolved soon and productivity will exponentially increase.

On a bright side, I have made all of the entity class objects for Dan to throw into the database using JPA and it seems to be working very well.  Also, half of our group has started using Intellij full version rather than Eclipse as it has many tools to help with Javascript editing.  Seeing as how the entire group will be working with Javascript soon, we figured this would be a wise choice.

Today, I am trying to fix a 404 error that is being thrown because, for some reason, I cannot access the URI that I specified using REST.  Hopefully this will get sorted out soon.

Thursday, February 27, 2014

Project March:

Progress:

As the project really starts to heat up, I am super excited about what I have been able to accomplish and learn.  This week, I have been doing research on the REST interface and have made an REST server that takes JSON objects and returns JSON objects back.  I have also been doing a lot with the parser.  I have been researching XPath in a DOM parser and have made some really neat spikes.  I have been able to successfully parse the large UNM opendata file that we have to turn into a database.  Right now, I am focused on being able to retrieve a JSON object from the front end of our program and turn it into a mySQL database query.  So far, everything has been going great and I feel as though the work I have been doing has contributed to the team.  

Saturday, February 22, 2014

Current Work: 1

Current Work 1

So as of late, I have been working on implementing a simple backend to really kick off this project.  I am trying to figure out how REST commands like GET and PUT interact with the code and how they actually call the code.  I have also been learning how to parse and create JSON objects that are going to be passed back and forth between the frontend and backend.  It is a little odd how REST works and a big part of what I am doing right now is experimenting with it to figure out the ins-and-outs.  To make a successful project, we must make the front end and the backend have flawless communication so knowing everything that I possibly can about REST and getting comfortable using it is, I feel, a good use of time.

I am slowly making progress towards figuring out how to implement all of this as well as getting a better understanding of web applications in general.  So far, I have had a lot of library and dependency issues which have made me dive into the numerous help forums out there and have a better understanding of what things like web.xml and pom.xml do.  The biggest struggle so far is just getting familiar with new things.  Basically, aside from JAVA everything in this project, even something as simple as GIT, is new to me so it has been difficult.

Thursday, February 20, 2014

Start of Group Projects

Group Project Begins

Well, it's finally that time.  I am super happy that I was able to get on the UNM visual schedule project as it was my first choice.  After our first two group meetings, I think we have a really good team and can make something to really change the world.

Dan has a really great vision for the project and is going to be a great leader.  So far, he has been very prepared and knows what everyone needs to do.  I am excited that I get to work with the SAX parser and focus a lot of energy on parsing the open data that UNM provides.  I did not get to work with the SAX parser a whole lot in 351, so it will be nice to gain some experience with it.

Already, I have been reading up on Javascript and AngularJS as I have never really had to make a web application.  I am really stoked, but really nervous to tackle this project.  I have never worked with MySQL, Javascript, TomCat, or REST so it will be a huge learning curve.  I think we will be able to manage though and make something very special..

Sunday, February 16, 2014

Proposals Day 2

Second Day of Pitches

Well the second day of presentations is complete as well as my final selections.  I think the pitches really influenced my overall decision even though I read many of the proposals.  I was impressed again at how well the pitches were delivered, but there were a few exceptions.  Some of the proposals seemed too casual.  I mean the target audience is young adults, but I feel as though some of the proposals could have been more professional.  I am excited to see where I end up and what project I am on.  I feel as though the projects I listed really could change the world and I would be excited to be on any of them.

Thursday, February 13, 2014

Initial Pitch Reviews

Pitches: Day 1

After listening to half of the classes project pitches today, I was very impressed at the creativity and presentation of everyone in the class.  I really liked Trent's project of making a program that synchronizes visual effects with music played on a MIDI board.  Also, Alan had a very elegant proposal and was very fluent with his speech.  You could tell that he has a great vision for the backpacking project and knows the ins and outs of what needs to be done.  I also liked Kishore's project about the social snowboarding app.  As a snowboarder myself, I see this as a really rad idea that I would be excited to use when on the mountain.  Ronald's project was neat as well, but I was more impressed with his verbal skills and his selling skills.  One thing that I noticed is that in my proposal I attempted to use the Goldilocks's method to pitch my idea.  From other speeches I heard, I did not see anyone else try to use it.  If they did, maybe it was hidden and I didn't catch it.  

From the projects proposed so far, I think my top picks are
Kishore - Snowboarding App
Alan - Backpacking App
David B - Converting web pages for PC to web pages on smartphones

Seeing other people present and how well they did, I know what I can work on in the future and, hopefully, have more impact on my audience.  

Tuesday, February 11, 2014

Final Revised Project Proposal

Final Revised Project Proposal

The following is a link to the final project proposal for SmartPaper complete with revisions:
SmartPaper

Monday, February 10, 2014

Design Patterns

Software Design Patterns

A software design pattern is basically an abstract, general solution to a continuously recurring problem.
I will focus on describing the Factory Method design pattern.

Factory Method

 - Essentially the Factory Method defines an interface for creating objects, but lets the classes that implement this interface decide which class they are going to instantiate.

 - Basically, object creation is delegated to subclasses to:
       1)  Avoid code duplication
       2)  When creating an object requires access to information that should not be in the composing
class
     
- A problem with the Factory Method is that if it is not implemented right away, then refactoring existing code to use this pattern can be very time consuming and can break the code for a while.  As we all know, breaking the code should be minimal and basically non-existent in refactoring.

- The Factory Method is an excellent way to abstract the creation of objects to help the code be more modular.  It makes the code easy to change or to add new objects without changing the existing base of the code.

Thursday, February 6, 2014

Three Words For Ideal Team

Three Words to Describe my Perfect Team

Prompt, Knowledgeable, Teachable

Reasoning

- A perfect team member would always be on time.  It shows dedication to the project and it shows that they care about the success of the team.  With big group projects, if one person is consistently late, the whole team loses productivity.  By having a team member show up on time, it shows they are interested in the project, interested in the welfare of the team, and interested in showing up to actually work and push the project forward.

 - A team member should be knowledgeable about programming.  In the past, I have worked with a team member who was not very knowledgeable and not only did it slow the whole team down by making us have to stop and explain everything, but it lowered team morale.  By constantly having to explain what is going on, the team gets frustrated and feels like that member is not pulling their weight.  To be successful, the team must be happy and having team members that are knowledgeable is a great start.

 - A person can know every in and out of every binary in the world, but if they cannot listen to ideas, they are worthless.  A team member should be able to listen to their co-workers, see their point of view, and be open to new suggestions.  As many computer scientists tend to have a big ego, it is important that all team members be teachable so that there are no fights in the group or lack of productivity.  Having a team that can listen, admit when they are wrong, and be happy working with other people's ideas makes the team happier and the project more successful.

The Three Omitted

Three words that I would have loved to include, but had to omit:

 Friendly - Tam members who will be happy taking breaks as a team and all go to eat with each other or just being courteous and funny in team meetings are an important thing to me.  I love it when people are super friendly and nice when you see them.  It makes working with them a much more pleasant experience than it could be.

Focused - Taking breaks and goofing off are a big part of team projects, but when it comes down to it, I want team members that are given a task and they have tunnel vision until its done.  This gives the team a bigger sense of urgency to get the project done and, in my experience, when one person focuses and tries to achieve a lot, so does everyone else.

Free - if a person has no time to ever meet with the entire group, they may as well not be in the group.  I would like a teammate who is always open to meeting after work or before school and, no matter how busy they may be, always find time to make it to meetings.  If a person is never free to meet, the team begins to resent them and internal tension begins.

Tuesday, February 4, 2014

Software Craftsmanship

Software Craftsmanship

An approach to software development that emphasizes the coding skills the the software developers themselves.

 - interesting that the Software Craftmanship Manifesto took assumptions of the Agile Manifesto even further and basically stated that software engineers should acquire a certain set of basic competencies   in programming rather than having a very strict engineering approach.

 - the metaphor of software developers and medieval guild traditions in Europe is an interesting idea and not at all far from the truth.  Throughout the course of college, I have seen a lot of change and progression in my code and software ability.  People with much more programming experience have more tools and it is clear that, with time, they have grown in their software developing skill.

 - I really liked how the article states that there will always be room for people to write software with their own unique knowledge.  I have always found it interesting to look at code of much more experienced programmers and see how different two programs with the same functionality can be so different.  Each programmer comes from a different background and it is neat to see what people have learned over the years that influence the way they write software.  

 - In the Software Craftsmanship Manifesto, I love the value "Not only responding to change, but steadily adding value" - This is something anyone who writes software should focus on.  Merely sticking a band-aid on code so it works again should not be consider acceptable.  The code should not only handle new technology and change well, it should become more polished and work even better than before

After reading this article, I was so inspired that I even went and signed the Manifesto for Software Craftsmanship and if you believe in Craftsmanship over Crap then YOU SHOULD TOO!

Proposal Reviews

Proposal Reviews

The following links are PDFs of the proposal reviews that I have completed.  Overall, I saw some great ideas and some projects I would be more than happy to work on.  A reoccurring theme I noticed is that some of the projects are massive.  It seems that they would be very difficult to accomplish in eleven weeks.  However, I had a good experience reading these and by judging other people's proposals, got some ideas on how to improve mine. 

Ezra Stallings:  Ezra Review

Brandon Lites: Brandon Review

Zachary Harding:  Zachary Review

Sunday, February 2, 2014

Final Project Proposal - David Daily

Here is a link to the final project proposal for David Daily.  Note: This project is different than the project initially submitted.  As I was doing research, the original idea was incredibly complicated and required technology that I would not be able to use.

https://docs.google.com/viewer?a=v&pid=forums&srcid=MDY2MzAyNTU5MzAyNTAwOTQ3OTYBMDM2NjEyMjQ1MDE1Nzc1MDI2NjUBc3I3UW9rU0kydTBKATQBAXYy

Thursday, January 30, 2014

Agile Development......

Wikipedia on Agile Software Development 

Agile software development is basically a set of software development methods that promote adaptive planning, development and delivery.

What I thought was most interesting about agile software development methods is that they were developed to completely contrast waterfall methods because many people thought these methods were too "micromanaging".

 The Agile Manifesto, which basically started the movement of agile software development, is based on 12 principles:
  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily cooperation between business people and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

I prefer waterfall-oriented approaches to agile development because I see many issues with the above.

   1. "Customer satisfaction by rapid delivery of useful software" - this shouldn't even  be stated because I believe this to be a founding principle in all software development

   2.   "Welcome changing requirements, even late in development" - not very reasonable.  There has to be a "feature freeze" date so that the customer does not tell you that they want a feature that tosses people they don't like into a black hole 2 days before the program is supposed to ship.


   3. "Face-to-face conversation is the best form of communication (co-location)" - I agree with this and it's a lovely thought, but with growing technology and things like repositories for code, many people can work on a project or talk about requirements without ever meeting face-to-face.

I personally like the idea of trying to squeeze every last drop of information from the client at the first meeting to establish a set of requirements and use waterfall-oriented approaches.  The agile development approaches just seem too laid back and unproductive.

Tuesday, January 28, 2014

Reaction to Wikipedia on Use Case

Use Case

According to Wikipedia, a use case "is a list of steps,typically defining interactions between a role and a system, to achieve a goal." 

It seems to me that a use case is basically a step in the process of developing functional requirements that models how components of a program will interact with each other.  Many of these use case examples could be pictures such as UML or even memory and pointer diagrams.  

From Alistair Cockburn's "fully dressed" model, the Design Scopes and Goal Levels steps seem a big confusing and unnecessary.  I personally believe that if I was looking at a use case, I should be more concerned with the top level ideas of how a system interacts than trying to remember what a solid box and hollow box mean.  Knowing the design scope and the goal levels of a use case is useful information, but should be conveyed in words.  

One of the biggest benefits that I see to use cases is that they make it clearer exactly what role each part plays in a system and everyone working on a project with access to the use case can typically agree on the requirements.  This also depends on the quality of the use case writer though.  

All in all, even though use cases provide much more information, I would prefer a user story to a use case.  Some of the examples of use cases are a little convoluted and may be a little too much for the task at hand.  

Tentative Timeline For CS460

Timeline

Here is a link to the tentative timeline for David Daily CS460.

https://docs.google.com/viewer?a=v&pid=forums&srcid=MDY2MzAyNTU5MzAyNTAwOTQ3OTYBMDE2NDU1NDI1MTE1NzMwMjIxNjkBcGltZllKaTJURE1KATQBAXYy&authuser=0

Saturday, January 25, 2014

Concept Paragraph For CS460 Project

Concept Paragraph

The Idea

In the world today, there are many applications and devices that tell you exactly where you are in the world and very accurately.  However, none of these are able to tell you your location without a satellite.

The Proposal

Our team will create a positioning system that can tell a user their exact latitude and longitude, or can tell them where an object of interest is that is equipped with one of these devices.  It will do this by calculating solid earth tides and readings from accelerometer stations around the world, and use the results to calculate longitudes and latitudes.

The Audience

The current audience for this device is anybody that needs to find their way around, but will be especially military and international cooperation organizations since it will work in places that GPS cannot.  For example, say the United States sells a super computer to China and China has promised that it will be kept at a university and used for educational purposes.  If the computer is equipped with one of these devices, the U.S. would be able to intermittently query the device to find its position and make sure the computer is always at the university.

Support 

For this product, my team will offer updates and new technology that will make it possible to query devices in real time with no satellites.  Also, there will be updates being released to the public to expand our market and make this technology a feasible solution for that "GPS signal lost" message that is so fun to hear on a road trip.


Call to Action

Not only could this device change the way that the military locates machines and people, but it could change the way that people find their way around.  After all,  I wouldn't trust a satellite that is 1,000-22,000 miles above the earth to tell me where the nearest McDonald's is, would you?

Thursday, January 23, 2014

Software Engineering - That Wikipedia Thinks 

Some Interesting Things Wikipedia States That I May Not Agree With

 - "Software engineering is the practice of computer programming, while computer science is the theory of computer programming.".... meh not in my opinion

 - "some students in the developed world avoid education related to software engineering because of the fear of offshore outsourcing" - though this may be the case, there is a lot of software being written for government purposes and places where security clearances are required, so there will always be domestic need for software engineers

What Was Kinda Neat About The Article

 - The Waterfall model is very straight forward, yet has a good structure of the way good programs are created

 - I thought it was interesting, just for personal knowledge, that companies like Apple and Microsoft sponsor their own certification exams....which is probably a good thing

 - "Software Engineering sees programmers as practitioners of a well-defined engineering approach with the connotations of predictability, precision, mitigated risk and professionalism" - I think this is the coolest sentence because these are things programmers need to really focus on for their software to make an impact. If these things are forgotten about.......well.......you get iOS

Personally,

I feel as though software engineering embodies the more business and standards aspects of computer science such as:

 - Developing standards as to what is "good" programming and what is "bad, ugly, sinful" programming

 - Getting projects completed in time and sacrificing features to meet budget, but maintaining the functionality that was initially promised

 - Being able to interpret a customers wants and needs and give them back a program that is capable of what they need to do with it

and Computer Science

- Is making neat stuff and hacking for the fun of it

I wish the article

- Had talked more about the soft skills aspect of software engineering

- Talked about how it's a profession where the majority of time spend is modelling things that would be impractical to research in real life

-