Final blog

The presentations were yesterday! We got to present in front of judges not related to the class, and our group came up... short! We didn't get one of the two awards handed out, but overall I still think we presented a good project. Ours was the only mobile app, while everything else was a website. We also had a video in our presentation which nobody else did. Finally, I think our one-sheet was the most unique, since we made a brochure instead of a normal one-sheet. So, while we may not have won, I think we presented the most unique project.

We slipped up a couple of times while answering the judges' questions, but this was expected since it was a high stress environment. Though we said a couple of things we shouldn't have, overall our we answered our questions knowledgeably and effectively.

The two winners were Visual Scheduler and Mechanapp, and they were both excellent. Visual Scheduler, I believe, was the best idea. It had a clear and direct function with little to no competition, and as a student I know the customer base is very interested. Mechanapp had the best presentation, with a well rehearsed speaker (James Vickers) leading the show. Both of these projects were great, and my hat is off to them.

The semester has been a good one. Even though we didn't win our project was my favorite of all of them. I learned a ton about Android and developing in general, and I wouldn't do it any differently. To all my readers, this is my last blog, but thanks for checking in!

I will update if I start a new CS blog on this account.

Thoughts on Other Projects: Demigod

Demigod is a stat tracking app online that allows you to track personal stats about yourself. Basically, you can track stats about your fitness, nutrition, or brain (or mental exercises). There are certainly a lot of other stat tracking apps out there, but this one tries to combine all self improvement stats into one convenient website where you can go to track everything. Their presentation did a good job of convincing me that the United States (myself included) should do a better job of tracking their nutrition and fitness, and how this site can assist in that.

The site looks very slick and it does look easy to pick out exercises for you to do for a week. It also seems that it does encourage you to do these exercises by "leveling up" your character the more stuff you do. This gives you a sense of accomplishment when you finish one of the challenges and puts it permanently into your profile, making you want to do another challenge for the next week. I think it's really cool how they split the challenges into three categories (nutrition, fitness, brain). This makes it easy for someone who's really only interested in one of these things to still use the website. The site even has challenges for quitting smoking, or other unhealthy vices, which seems really nifty.

My main problem with the site is that it requires manual data entry on your computer, i.e. you have to log on to the site on your computer and enter that you actually followed up on the challenges. The problem with this is it makes people not want to use it if they did do a challenge but forgot to input that they did. Or if they don't use the computer much, it can be tough. I really do think this should be a mobile app. It's easier for people to pull out their phone right after working out or something and entering that they did than it is to log in at home. However, this is a very minor complaint. Most people who wouldn't want to enter their stats on the computer probably wouldn't sign up for it in the first place so it is unlikely a target demographic.

Overall, this is a very nifty app. I could see myself using this if I was trying to get a bit healthier, which I may need to do. The team worked super hard on the site, and it definitely shows, it looks very polished and professional. Watch out for these guys at the final presentation.

Thoughts on Other Projects: G.E.R.A

G.E.R.A., or the Global Emissions Reduction Alliance, is a gamified carbon tracking website that allows users to input real data from their actual carbon emissions, and also encourages them through mini-games to reduce these emissions in real life. What's really great about this site is that it is trying to make a difference in the real world. Some of the apps are for convenience or entertainment, whereas this app is actually trying to address a real world problem, and that's admirable.

The stat visualization on the website looks really good. Since users can enter their data, the team has created tools to help visualize their carbon emission history, and I think this will help users to see how much they've improved, or if they have. Most of the users on the site will want to improve their carbon emissions, it's unlikely that people will be playing the game without any motivation. This tool just helps them keep track of everything, and gives them little directed incentives, which is really all people need to get going in the right direction.

The site is a little too dark sometimes, which makes the text a little hard to read. The team slightly fixed this by making a translucent background, but the site (at certain points) doesn't look super visually appealing, mostly because of color rather than art style. As well, I wish I knew what the games looked like. From what I can tell, the "games" are just something like "reduce your carbon by 2% this week" with data entry from the user, which isn't super exciting. Though, I don't really know how you could make it more exciting, so I can't really blame them.

Overall, I think this app is very good. I think it is the most beneficial app to mankind out of all of the projects in the class, since it is actually trying to do good for the world.

Thoughts on Other Projects: Automaton

Automaton has succeeded in making a game that looks professional, and better yet, like something people would want to play. The idea for Automaton was to make a game that's fun but also teaches about computer science, not necessarily in a way that's strictly educational, but more in a way where you don't even realize you're learning. It looks like a puzzle game mixed with fundamentals of CS. You have to manipulate the pieces to create a for loop, or take the mod of a number, stuff like that.

I think what I really like is even if it's not teaching people how to program, it's teaching them how to think like a computer scientist. In computer science, you really have to think of things in a step by step fashion, and that's what the game is all about. Manipulating a system in a step by step way to get your desired result. No, it won't teach you the correct Java syntax, but it will teach you how to think about problems when you're writing Java.

The only thing I don't like about it, is that it looks very similar to Spacechem, another game like it that I've played. The gameplay is extremely similar. However, they've recognized this, and after all it's in the same genre, since the genre is a specific type of puzzle game. Automaton certainly has its own look and feel to it, it is nothing like a complete copy, so this is not a big issue.

Overall, I think Automaton looks amazingly polished for what it is. Nobody else made a game (at least a video game) for their project, likely due to the inherent obstacles that come with building a game from scratch. These guys have not only pulled it off, but they've made something excellent, despite the difficulties. This project will definitely be one to look out for in the final presentations.

Thoughts on Other Projects: Mechanapp

This application looks really good. The visuals are really nice, their seem to be pleasurable animations on everything which I really like. The idea is a good one, basically it helps you diagnose problems in your car based on a series of yes or no questions. It also uses weighted likelihoods to try to diagnose your problem more accurately and more quickly.

I really like this product, and think it has real market potential. Their idea is to make money by putting in targeted advertising into the product, which makes a lot of sense since their product is already targeting a specific demographic. The problem there is you have to gain momentum to get the attention of anyone who wants to advertise with you before you can make any money, however this is a problem for a lot of startups.

The presentation for these guys was great! They felt very relaxed and comfortable with their product, which is good. It makes me feel more confident in the product when I see them so comfortable with it. Also, it seemed that they had rehearsed the demo a few times so it went very smoothly and demonstrated all of the features quite clearly.

One question that I have, (and a reservation I have about the product) is how are all of the trees going to be implemented? Are all of them going to have to be manually entered? Are there separate trees for every car or are they all pretty much working with the same tree?

Despite all this, I think the product is great, and think it's a real contender for the best project award. Good luck to Mechanapp and its team!

Thoughts on Other Projects: Visual Scheduler

These guys certainly made a product that people want. To be honest, I knew the scheduling tool for UNM was a pain but I didn't really know I wanted a new way to do it until I saw the visual scheduler. It just seems like it makes it so easy, compared to the current method. The schedule generator is genius and is definitely a feature I would use in the future.

The first presentation for this group was a bit weak. The demo was fine, the site (mostly) worked, and it certainly looked like a strong product, but I felt like the presentation wasn't super rehearsed and they demo'd a bit too long just to fill in time that they didn't use.

All that being said, the second presentation from them was way better. The demonstration didn't feel forced, the time felt natural, and they demo'd the schedule generator which was super cool. Overall, I think it was super improved and I'm confident it will be even better going into the final investor pitch.

I really like this group, and wish them the best with their final presentation!

Project wrapping up

It's interesting to view the project now that it all is wrapping up. It's no longer a looming fear in the distance, it's quite nearly an obstacle overcome. I'd be lying if I said there weren't nights when I thought we wouldn't finish it. I've had to pull quite a few all nighters working on this project, but it's unbelievable how much we've been able to accomplish in such a short time span. Sure, we only got one "simple" Android application done in 3 months time, but none of us even had Android experience going into this project. We jumped in head first, and I for one came out with a much better understanding of Android and how to use it.

Android wasn't what I was expecting. I will say that. It uses Java, but it definitely isn't Java. If you've used Java, it doesn't give you enough knowledge to just know Android, and may be quite confused going into it. However, I have started using a little bit of Java FX and it seems to use some of the Android paradigms. Since it Android is a very visual language (or perhaps I'm just taking advantage of a lot of the visual aspects) this relationship makes a lot of sense.

Being so close to the end makes me excited, and sad. Sad for the end of all the memories, excited for the prospect of moving on to new projects! Good luck to everyone working on their projects.

Developing for Mobile

Hi there, I'm back today talking about developing for mobile, and what its advantages and disadvantages are.

First off, they're mostly disadvantages, to be honest. The biggest frustration is testing code. The easiest way that we've found is to run the application on your phone through a USB, since the emulator is horrible and slow. Once running on the phone, you can set up a console to give you error output and standard output on the computer. In this way, you can see what went wrong if anything, since the phone does not give verbose output. The problem here is that we need to test outside sometimes. Since our application is motion and GPS based, a lot of the time we need to go outside and run around with it to test if features we implemented even worked. Needless to say, this makes it difficult to bring the computer with you to debug.

Another issue is artificial data. With computers, it is much easier to set up a system to feed your program false data so that you may test your code. With mobile, we are often pulling from sources on the phone itself and does not make sense to fake the data from it. Overall there are many difficulties developing for mobile since you are developing on a different platform than what you are developing for.

One positive aspect is that your program is as mobile as your phone. This means if you want to test data on a mountain, you don't need the computer just your phone, which is highly portable.

I like developing for mobile, because I think it's an important skill to know and it's so popular right now. There are so many apps being developed, but there are a lot of low quality apps developers have a chance to stand out from the crowd.

Intellij... You weren't the way

Hey there, today I'm going to be talking about JetBrains IntelliJ. You can find their website here.

We picked IntelliJ because we thought it would be the robust path. Though it's new, we read much high praise for it and that it was the future of android development. We knew going in that there would be more support for Eclipse, but really how many problems can an IDE cause?

More than I thought, certainly.

Adding libraries is a key part of the IDE, and it is not at all clear much of the time how we are supposed to do this correctly in IntelliJ. Because all of the tutorials were written for Eclipse, I assumed they would pretty much be the same in IntelliJ, because why would they reinvent the wheel? However, the project structure files are different, so much of the process is different enough to invalidate tutorials. Basically, it's just different enough to cause problems.

I would not recommend using IntelliJ for someone thinking about doing Android development. Use Eclipse. The features are all there. It has better support. And mostly, it's what everyone else uses.

Setting up IntelliJ

We chose intelliJ because it seemed like the IDE to use. It's the IDE of the future! This means that learning how to use it will be a valuable skill. The developers of IntelliJ IDEA definitely had Android in mind when making the IDE, which made it seem to us that it would streamline out development process.

The problem is that IntelliJ is relatively new, so there aren't nearly as many tutorials out there for setting it up. This means that anything that we want to use, plugin-wise, has to be figured out without much help. A lot of tutorials out there skip steps, assuming you know what they mean. This is troublesome because it adds a lot of time to setting up basic things, like repositories in the IDE itself.

As frustrating as it is, it helps me learn things better when I have to figure it out myself. I would like to make things faster, but I'm actually learning better so it is probably worth it in the long run. If I ever need to set up things again, I will know exactly what to do.

My Thoughts on Android

We've begun programming our project, Powderade, which is an app for Android OS. This is my first time working with Android, which I am very excited for since the app market is huge. All I had heard from everyone was that Android was just Java, and if I knew Java it would be no problem.

Well, those people were wrong. Android is not "just Java." Certainly, Java is incorporated into the language, and it's important to know. The complex parts of the program are going to be written in Java, but it uses Java more like a script. The program is put together in .xml files, which is something I had never encountered before. It makes assembling the program really strange, since there are a bunch of different files that point to each other for layout purposes. Putting together a GUI in android is certainly not like putting together one in Java.

I'm not saying that it's necessarily more complicated than Java is when it comes to GUIs. The IDE I'm using (IntelliJ IDEA) even comes with a GUI builder that allows you to visually put the GUI together, making the process a little simpler. But what I am saying is, just because you know Java does not mean you know Android. They are very different environments to program in.

I am glad to be working on this, though. I wanted the experience and now I'm getting it. I'm excited to know once we finish this project I will be an Android veteran!

Unit Tests, Why Use Them?

I'm here talking about Unit Tests, and why companies use them. Specifically, I want to talk about this paper.

Unit tests are basically tests that plug something into a program and expect a certain output. If they do not receive that specific output, then the test is "failed." These can be useful because people who didn't necessarily write the program can test the program by knowing what outputs should be. This can give useful information to the programmer if something has broken, or is not working correctly. A suite of unit tests should provide information to the programmer whether the program is running correctly or not.

What James Coplien is arguing in this article is that, in his words, "The cure is worse than the disease," meaning of course that the time spent writing unit tests is greater than time spent debugging code. He goes into a multitude of reasons why, including unit tests being over-required, and too many tests provides less information than the correct tests. I think he makes valid points, and what I like about this article is that he talks about the problems, but tries not to generalize unit tests being "bad" or "useless." He instead talks about how the original vision for them has become outdated as programming goes to new places, and requirements for unit tests are ridiculous in the workplace to the point where sometimes the tests are more complicated than the original program.

I have always thought that unit tests were not all that useful, but I assumed that this was because I was working on projects alone, and when you have a plethora of coders working on the same program, things could get complicated to test without a unit test. I still think that is the case. The problem with the solutions boasted in this article is that they rely too heavily on the competence and similar thought of everyone on the team. Not everyone will be able to write their programs to be testable, and generally, that will just be how it is. It is simpler to have unit tests, which are dedicated to testing the program, than have everyone be able to test their own code, and test within the program itself. This solution is certainly better if it is only a team of 4 to 5, but how could you expect a team of 80 programmers to be able to test together like that? I think it's unrealistic.

Overall, I think the writer is correct, unit tests are used incorrectly and inefficiently a lot of the time. But that is simply the way it is with software engineering, there is inefficiency when business and computer science interact. Hopefully, we will get to a point some day where enough people understand computer science in similar fashions where these problems won't crop up, but it seems unlikely.

Working with a Team

Getting thrown into a group of people that you don't necessarily know is quite the  experience. Add that to immediately getting assigned tasks and expected to work together, you have an interesting challenge.

Getting in my group, I was lucky, because I knew both Brandon and Kishore pretty well. Brandon and I are good friends, and Kishore and I have worked together in previous classes. John I didn't know, but he is quite the pleasant fellow and was easy to get along with. All of us were quite willing to work together, which made the initial experience enjoyable and painless.

I could imagine working with strangers or just peers that you don't like could be pretty tough. Not only do you have to work with your partners, you have to trust them to do their part of the workload. If you have a team member you can't trust, you have an entire team you can't trust and then you have a team that can't produce anything.

Like I said, this is not the case for me. Hopefully it's not the case for any group. But this experience has taught me how important the group is. Therefore, in the future, I think when selecting a group, you should be able to choose based on who else is going to be in a group. For example, if someone I don't want to work with is going to be on a project I want to work on, it might change my mind.

Now, I realize, in the real world, you won't always get to choose who you work with. You're going to have to deal with the partners you're assigned to in a lot of cases. But, if you're offered a job with a peer or group of peers that you don't want to work with, you have the choice of not accepting that job. However, in this class, if you're put in a group with people you don't like, you have no choice in the matter.

Thoughts on Project Proposals

Hey guys, it's been a while. I'm here today talking about my thoughts on proposing and project and the whole process thereof.

So my project, WorldBand, was not chosen. I'd like to say I was relieved, but that was not quite my feelings on the matter. To be honest, I felt ambivalent. On one hand, I was relieved. My proposal, which felt like I made up information (like the timeline) that was not necessarily going to be accurate, was not going to be held accountable to me.

On the other hand, this project which I had put so much effort into was just going to be discarded, probably not to be picked up again. As much as I like the idea, I doubt I will have the opportunity or resources to work on a project like this again. As much as I am excited to work on my assigned project, I will always have personal feelings toward the project I came up with. And, in fact, I still feel like it was a good idea. I feel like a website done right in the vain that I came up with could be a top 50 website in the world.

C'est la vie. You will always be attached to your own projects, but that doesn't mean you shouldn't realize when there are better ideas. My project proposal was good, I think people understood my vision, and I got a decent amount of votes. In the end, I am not upset, because I think the project I'm working on is better for the scope of this class.

WorldBand Proposal: Round 2!

Hi guys, I have taken the feedback that I received from my proposal for WorldBand, and updated my proposal, which can be found here.

Please, feel free to comment or review! Thanks for your input! Special thanks to Kishore and James for reviewing my proposal version 1.

Software Design Patterns: How useful are they?

Hi there, I'm here tonight discussing the article on wikipedia for Software Design Patterns, that article can be located here.

A software design pattern is basically something you can design or draw out as a template for a piece of software that you are currently developing. This template cannot be followed instruction by instruction to achieve the desired result, rather it is more of a general direction to begin in, with milestones along the way. This is important because it gives some structure to the overall design of what you are doing, aiding you to not be lost when looking for the next step in the program.

I have user software design patterns before, mostly for outlining object oriented related objects. Diagrams I have done detailed how classes interacted, helper classes, and their basic designs. This is cool because when you start programming a class, you have it outlined before it's even done. This means if you have two classes interact with each other, you can program one before the other since you already know what functions the other will have that need to be interacted with. This was very important in a project where a group of us were working on a program together, and we didn't necessarily all work at the same time. Since we knew all of the basic class outlines, our programs could interact with each other quite easily, even if we weren't in constant communication.

Some criticism has come from the fact that these diagrams oversimplify things and this becomes a problem when you're actually implementing according to simplified diagrams. These problems can arise from thinking you needed extra functionality that wasn't necessary, or not foreseeing a certain problem. Though both of these things can happen, I don't think it is valid criticism. Problems will always arise when programming something complicated, and I think it's very useful to have an overarching structure to the program before you delve into the nitty gritty.

So, overall, I think software design patterns are awesome. I think they are useful and you will almost always be very happen you decided to make them before you get into the full body of code.

My ideal project team

Here I am today, once again talking about the project proposal I have put fort, WorldBand. You can read that proposal here.

If I were to describe the perfect team for this project in three words, those words would be:

Knowledgeable, communicative, and inspired.

Knowledgeable because the work that I'm looking to do is going to be quite complicated. They don't necessarily need to know everything before the project starts, but they need to be able to learn fast and teach others.

Communicative because the whole team needs to work together to make a project work. Everyone needs to be communicating for the site to be made correctly. This does not mean that they need to be talking more than coding. Part of being communicative means knowing how to be concise and direct, making the process easier and less time consuming.

Inspired because you have to want to work on a project to work on it. Some inspiration will come from it being a requirement for the class, and therefore to graduate, but I'm hoping a lot more inspiration will come from actually wanting to complete the project to the best possible degree. With this kind of inspiration I know the team will work hard without anyone having to enforce it, they'll all enforce themselves.

Some other contenders were thorough and hard-working.

Thorough because the team should care about all aspects of the site and should not just be throwing the site together as quickly as possible. I did not choose this because if you're communicative and inspired they will definitely be thorough.

Hard-working is obvious, of course I want team members who are actually going to work on the project and not slack off. However, I didn't choose this word because if they are inspired, hopefully that will force them to be hard-working.

What it Means to Review a Proposal

How is it that someone can read a 15 page proposal, and summarily score it in less than a page? A few concise sentences is all that it deserves? Well, maybe not, but it is pointless to restate the entire proposal in a proposal review. In fact, though it may seem harsh when there is less content in the review, this often is a good thing (for your proposal, at least) because it means there wasn't as much to talk about. If you have a solid project, then there just isn't as much to talk about. This cuts the other way too, though. If you have a truly horrible project, then there won't be much to talk about either, even if there is plenty to rant about. You usually know when a project is truly horrible though, so if you don't think this about your project chances are nobody else does either. This also doesn't mean, though, if there is a lot to talk about, your project isn't good. Sometimes, there are great projects that could almost be perfect with a few changes, and then the reviewer might just be enthusiastic to talk about these changes and why they need to happen. Sometimes, this will mean extra criticism or extended thoughts, but that does not necessarily show a decreased amount of interest in the product, sometimes it shows more.
So, in summary, the length of a review doesn't necessarily mean much. You have to look at the content of it. If the reviewer is saying this isn't going to work, then maybe you need to rethink it.. Or maybe the reviewer is just bad. But it's something you need to consider at least.

Proposal Review: Mechanapp

I'm here reviewing a proposal put forth by James Vickers, a fantastic fellow student in the cs department. You can find the proposal here.

Review of Proposal: “Mechanapp”

Proposal author: James Vickers
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create an application that can assist in the diagnosis of a car problem using probabilistic diagnosis based on other entries into the system. This will help for both professional and amateur car owners and enthusiasts to fix any problems on their own, while paying as little as possible.

Part 2: Reviewer reaction

The idea is a good one. Car repair is a mystery to a large majority of the populace and even the good ones are shooting in the dark a lot of the time. I kind of like to think of it as a “WebMD” for cars, a simple diagnosis tool so that you can get quick and easy advice.

Part 3: Quantitative scores

Format: 4

The format was good, though some information seemed to be repeated. Nothing too drastic though, and easy to look through and know the scope of each section.

Writing: 5

Very easy to read, and explains the project very well. Solid writing.

Goals and tasks: 4

The target audience was well defined, and the product was well laid out from a front end perspective. I think more analysis needs to go on on what needs to be done behind the scenes though, on the technical side.

Scope: 3

I think more thought needs to go into the platform and the technical side of the project (even if you're not sure on the platform, pick one and if your team decides to change it once you form, that's fine), but the scope of the marketing and attracting customers is good.

Plausibility: 5

Everything talked about could easily be done and is being done for different applications already.

Novelty: 4

Similar to other diagnostic tools out there, but none that I know of for cars. Seems like a very solid and novel idea.

Stakeholder identification: 2

The stakeholders are not identified, though the target audience is outlined very well.

Support and impact: 4

This could easily make an impact on anyone who works on cars, so good job there. But how will the application be supported once the product is done, and the twelve weeks are up?

Evidence: 4

You did a good job of talking about other tools out there for mechanics, but you also could have talked about other diagnostic tools out there.

Challenges and risks: 3

Technical challenges weren't addressed. A lot of marketing and viability challenges were though, such as having customers enter previous solutions into the database, which was good, since that will be a major problem upon starting up.

Proposal Review: Backpacker

Hi there, today I will be reviewing the proposal put forth by Alan Kuntz, a very talented and intelligent individual, that can be found here.

Review of Proposal: “Backpacker”

Proposal author: Alan Kuntz
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create a mobile app that will specifically gear to a backpacker's needs. These include tracking consumables, keeping battery life low, and the possibility of sending out an emergency broadcast. This application would be a lightweight accessory for a relatively new market.

Part 2: Reviewer reaction

This idea is simple and lightweight, and exactly the kind of mobile app that will hit a niche market. Because the proposer has experience in backpacking, he clearly knows the needs that should be met when developing a mobile application geared to backpackers. The emergency broadcast alone, though not new, could be extremely helpful when applied to backpackers. I really do think that this idea has potential to change the world.

Part 3: Quantitative scores

Format: 4

The format is easy to read, though sometimes sections seemed to be repeated and it was not clear upon referencing which section I read something in. However, there were still clear sections that the writer did not write outside the bounds of.

Writing: 4

The writing is clear, and very conversational. I really like how the proposer didn't get caught up in the technical aspects of the proposal (that being said, there were some issues with this I will address later), and the whole thing gelled very well. Sometimes I felt the proposer was repeating himself, however.

Goals and tasks: 5

This section was excellent. The proposer clearly thought through his target audience, and exactly what he wanted to achieve. The different features of the application are well defined and fleshed out.

Scope: 4

The features are fleshed out very well, as mentioned previously, but one thing that bothered me was there was not a mention of what platform would be used, or how the thing would be programmed. Given, though, in the timeline there was time dedicated to discussing with the team, but I would say you should pick a platform and it can be changed later.

Plausibility: 5

Everything proposed is very doable on a mobile platform, and there are other services out there that perform similar functions.

Novelty: 3.5

On one hand, it seems like the application of this to backpacking is actually very new and I would like to applaud that. On the other, I feel like many other applications out there can do very similar things. Still, though, I think that it is different enough it can find a niche market.

Stakeholder identification: 1

The stakeholders are not identified, and this needs to be addressed.

Support and impact: 4

Great job talking about how this could impact, with the emergency broadcast system having the possibility of saving a life, there will always be impact. Not much about supporting the application was covered though.

Evidence: 5

You gave evidence of other applications, all of the functionality is clearly capable with mobile technology, and just well justified in general.

Challenges and risks: 3

Technical challenges weren't really addressed, though this could be because you did not really see them as a challenge. Still, they should at least be mentioned.