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.
Thursday, February 27, 2014
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.
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..
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.
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.
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
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.
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!
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
https://docs.google.com/viewer?a=v&pid=forums&srcid=MDY2MzAyNTU5MzAyNTAwOTQ3OTYBMDM2NjEyMjQ1MDE1Nzc1MDI2NjUBc3I3UW9rU0kydTBKATQBAXYy
Subscribe to:
Posts (Atom)