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.
Sunday, March 9, 2014
Thursday, March 6, 2014
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!
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.
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.
Saturday, March 1, 2014
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.
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.
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.
Subscribe to:
Posts (Atom)