After having our first client meeting one thing has become abundantly clear. It is time to hammer out the specifics. Up to this point, through the proposal process and in the very short time we had as a group prior to the meeting, the whole project has been discussed in the abstract. At the time of the meeting we had talked about action plans to take steps to solidify the ideas but had not actually done so. I think we would've been in a better position to have a successful client meeting if we had discussed actual implementation and design.
This is encouraging though, because the details are currently being addressed, and I believe that implies our next client meeting will be much more successful. Additionally, with an attempt having been made at some amount of division of labor, we will be able to more personally contribute to the next meeting--rather than staring at each other awkwardly until James spoke.
Friday, February 21, 2014
Friday, February 14, 2014
Ranking Conundrum
We are about to rank the proposals so that we can be placed into groups. This is really exciting because after listening to all of the proposals the last three days there are a number of projects that I find extremely interesting! It will be a difficult ranking process, especially where I will rank my own project which for whatever reason has lost some of its luster.
I am torn here. On one hand I think I will perform better this semester if I am working on a project that I find very interesting. I will find it more natural to remain engaged in the face of this, the most difficult and busy semester of my educational career. On the other hand, if I rank my project first--ahead of some projects that, embarrassingly, interest me more--and it is chosen, then I will be ahead of the curve on the "impact" portion of my grade, a concept which looms as an incorporeal boogie-man in the bedroom closet that is my uncountable fears regarding my last semester as an undergraduate.
I have tough decisions ahead.
Proposal Writing, the Aftermath
The proposal writing process was an educational experience. The task of creating a formal proposal document was new to me. I've had experiencing writing technical papers about research, as well as experience writing legal documents when I was a paramedic, but never before have I had to sell an idea in a formal document. Especially difficult was the balance between the "real" portion and the "pretend" portion. The real portion of course being the parts of the proposal written with the context of a 12 week project in an undergraduate CS class, and the pretend portions being things like the budget and support sections which due to the context of the semester long class had to be fabricated.
Regardless of this difficulty I found the writing process to be very educational as well as a tool for focusing my intents and taking a much more formal look at what it was exactly that I was proposing--an experience that will change the way I view future projects.
Regardless of this difficulty I found the writing process to be very educational as well as a tool for focusing my intents and taking a much more formal look at what it was exactly that I was proposing--an experience that will change the way I view future projects.
Wednesday, February 12, 2014
Proposal Final Draft
The final draft of my proposal can be found at:
http://cs.unm.edu/~adkuntz/AlanKuntzProposalFinal.pdf
As always comments are more than welcome!
http://cs.unm.edu/~adkuntz/AlanKuntzProposalFinal.pdf
As always comments are more than welcome!
Monday, February 10, 2014
State Pattern, a Behavioral Design Pattern
One of the more intriguing design patterns I read about while perusing the software design pattern wiki was the state pattern in the category behavioral design patterns.
This pattern hinges on a characteristic of a programs objects called state. The state of an object (can be an object itself) is used to allow the original object to have multiple behaviors. Part or all of the behavior of the object is actually dependent on the state variables or state object of the original.
This simplifies the way in which the program has to handle these objects. The program need only update the state of the objects (although I suppose they could update it themselves in some implementations), and then treat the object the same regardless of the state and the object will adjust its behavior accordingly.
I find this design pattern to be particularly powerful in one main way--it allows for a large conceptual and programatic abstraction of each object that aligns well with my understanding of an "actor" model of conceptualization. Particularly, a program can be conceived and developed as a stage for the interaction of various actors (sometimes objects), and define the rules for the interactions of the actors which algorithmically results in desired behavior.
One area I have used a concept like this in the past is in experimenting with multi-agent robotic algorithms.
The state design pattern is particularly powerful in this setting, as we can allow the actors to perform various roles or behaviors based on the state of the system which allows for more complex behavior and interaction definitions.
I will definitely be considering the use of this pattern in the future.
This pattern hinges on a characteristic of a programs objects called state. The state of an object (can be an object itself) is used to allow the original object to have multiple behaviors. Part or all of the behavior of the object is actually dependent on the state variables or state object of the original.
This simplifies the way in which the program has to handle these objects. The program need only update the state of the objects (although I suppose they could update it themselves in some implementations), and then treat the object the same regardless of the state and the object will adjust its behavior accordingly.
I find this design pattern to be particularly powerful in one main way--it allows for a large conceptual and programatic abstraction of each object that aligns well with my understanding of an "actor" model of conceptualization. Particularly, a program can be conceived and developed as a stage for the interaction of various actors (sometimes objects), and define the rules for the interactions of the actors which algorithmically results in desired behavior.
One area I have used a concept like this in the past is in experimenting with multi-agent robotic algorithms.
The state design pattern is particularly powerful in this setting, as we can allow the actors to perform various roles or behaviors based on the state of the system which allows for more complex behavior and interaction definitions.
I will definitely be considering the use of this pattern in the future.
Friday, February 7, 2014
Three Words
To describe my ideal project team in three words, I would say:
Excited, Dedicated, and Punctual
I chose these words because these are the characteristics I believe will facilitate the best experience for the group as well as the best final product.
Excited--I believe that a group that is excited about their work will inspire each other to be better group members and make the process less tedious and more enjoyable.
Dedicated--My ideal group is willing to work hard even when the project becomes difficult. A group dedicated to their work will be willing to add that extra effort to produce a high quality product.
Punctual--With such a narrow window of time to perform in, punctuality will be a high value commodity. Planning without punctuality of deliverables would be impossible, and as such punctuality deserves a place high on the list.
If I could include three more words I would include Personable, Proud, and Talented.
Person to person interaction skills are important in any kind of group setting as well as in a developer client situation. People who are proud of their work generally produce better work, as well as are better at selling it. Software Engineering seems like a difficult occupation, and as such I believe the best engineers will also possess some amount of talent.
Excited, Dedicated, and Punctual
I chose these words because these are the characteristics I believe will facilitate the best experience for the group as well as the best final product.
Excited--I believe that a group that is excited about their work will inspire each other to be better group members and make the process less tedious and more enjoyable.
Dedicated--My ideal group is willing to work hard even when the project becomes difficult. A group dedicated to their work will be willing to add that extra effort to produce a high quality product.
Punctual--With such a narrow window of time to perform in, punctuality will be a high value commodity. Planning without punctuality of deliverables would be impossible, and as such punctuality deserves a place high on the list.
If I could include three more words I would include Personable, Proud, and Talented.
Person to person interaction skills are important in any kind of group setting as well as in a developer client situation. People who are proud of their work generally produce better work, as well as are better at selling it. Software Engineering seems like a difficult occupation, and as such I believe the best engineers will also possess some amount of talent.
Sunday, February 2, 2014
Proposal
The proposal for my mobile application "Backpacker" is up and available at:
http://cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf
Comments are most desired and welcome!
Try this URL instead:
http://www.cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf
http://cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf
Comments are most desired and welcome!
Try this URL instead:
http://www.cs.unm.edu/~adkuntz/AlanKuntzCS460Proposal.pdf
Subscribe to:
Posts (Atom)