I'd like to conclude this semester with a reflection on software engineering--the discipline, and how my viewpoints have changed over the course of the semester.
Initially I was a little skeptical about software engineering in general. I have exposure and experience in research in computer science, and I viewed the differences as stark. I was unsure how I would take to it or how enjoyable I would find it.
One thing that surprised me was how much the two disciplines went hand in hand in our project. I found the science infused in every day choices throughout the semester, regarding things like algorithms and data structure choices. It was also interesting to me how much above and beyond the science the engineering was. There is so much more to creating a good product than understanding how it should work and the science behind the implementation.
My views towards software engineering are definitely different and I think the perspective I gained this semester is wonderful. I now know much more about what being an engineer actually means and am confident that I would both enjoy and be successful in an engineering role.
I am going to take some of the lessons I learned in this course and apply them to my own research as I go to graduate school. I will continue to allow the science and the engineering to work together in my work, as I make this a priority. I believe this approach will benefit the quality of my work in the future.
Wednesday, May 14, 2014
Group Postulations for the Last Time
I wanted to reflect with some finality on how the group interactions went from my perspective in Mechanapp.
It was an interesting semester and it had its ups and downs. One thing that I am sure about though is that our group was very good. I have absolutely zero complaints about any other member of my group.
I thought that our individual skills and personality traits complemented each other and allowed for an enjoyable, effective, and efficient project.
Sonny's UI work was absolutely stunning and flawless. David's knack for code interaction, the web framework, and all the research he provided for the group was invaluable. James' database expertise and leadership allowed for smooth group interactions both in and out of the context of the database.
I could not have asked for a better fit in a group and am frankly surprised at how well it went for us.
It was an interesting semester and it had its ups and downs. One thing that I am sure about though is that our group was very good. I have absolutely zero complaints about any other member of my group.
I thought that our individual skills and personality traits complemented each other and allowed for an enjoyable, effective, and efficient project.
Sonny's UI work was absolutely stunning and flawless. David's knack for code interaction, the web framework, and all the research he provided for the group was invaluable. James' database expertise and leadership allowed for smooth group interactions both in and out of the context of the database.
I could not have asked for a better fit in a group and am frankly surprised at how well it went for us.
Awesome--Second Place!
Mechanapp received the honor of winning second place at the presentations yesterday. We are extremely happy and somewhat surprised! After having seen the hard work and polished products of the other groups it became obvious that there was some steep competition.
I am exceptionally satisfied with our final product. I believe it to be an impactful, useful, and polished product in its own right. It was an honor to have that affirmed by the professionals Professor Ackley brought in to judge the projects. I also was very appreciative of the insightful questions and feedback the judges brought to our group.
The conclusion of this project is bitter-sweet for me. It has been an extremely rewarding and educational experience.
I am exceptionally satisfied with our final product. I believe it to be an impactful, useful, and polished product in its own right. It was an honor to have that affirmed by the professionals Professor Ackley brought in to judge the projects. I also was very appreciative of the insightful questions and feedback the judges brought to our group.
The conclusion of this project is bitter-sweet for me. It has been an extremely rewarding and educational experience.
Sunday, May 11, 2014
Preparing for the Presentation
Tomorrow our group is meeting to hammer out and practice our final presentation for this course. It is exciting to be putting it all together into a single pitch. I am also happy that the entire group will have roles to play in this presentation (unlike the previous ones).
The details are still up in the air, but I think the distribution will be something like:
James does the introduction, business side, and a brief user case demonstration.
David then takes over and overviews the technological choices.
I (Alan) will then proceed with a demonstration of the learning feature of the application.
James will then conclude the presentation.
As per the usual, Sonny will operate the laptop and assist as the user in the demonstration.
My only concern with this setup--and it's a minor one as I am really excited for the change--is that we will have difficulties keeping the presentation under the time limit. We may find tomorrow that there are just too many features to proceed in the fashion that we have planned. We will see though, and I'll check in after the meeting tomorrow.
The details are still up in the air, but I think the distribution will be something like:
James does the introduction, business side, and a brief user case demonstration.
David then takes over and overviews the technological choices.
I (Alan) will then proceed with a demonstration of the learning feature of the application.
James will then conclude the presentation.
As per the usual, Sonny will operate the laptop and assist as the user in the demonstration.
My only concern with this setup--and it's a minor one as I am really excited for the change--is that we will have difficulties keeping the presentation under the time limit. We may find tomorrow that there are just too many features to proceed in the fashion that we have planned. We will see though, and I'll check in after the meeting tomorrow.
Social Media Login Thoughts
David and I recently modified our login approach to be handled on the side of the server. This is necessary we believe as client side authentication just doesn't mean anything. In some cases that may be okay if the authentication was desired for superficial reasons, but we needed a stronger form of auth to handle our commenting system.
Initially we researched and implemented a plug-in (with associated api) called SecureSocial. This plug-in made a lot of things very easy, and after awhile we had authentication through google accounts working well. This had to be done working in conjunction with the google developer console for registering client-ids.
There was an opportunity to use other social networking sites as well for authentication such as Twitter and Facebook, but the barrier to entry for developers was higher for these sites (and lets be honest, twitter just isn't a necessary feature for a DIY car diagnostic assistance tool).
SecureSocial is no longer how we go about the authentication for our app, but the knowledge gained by working through their documentation as well as their api enabled us to move forward with the processes that eventually became the permanent solutions.
Comments and the Art of Troll Avoidance
We recently decided to add commenting to our application. This made me immediately nervous as I suspected that within a few milliseconds of going live our website would be flooded by troll comments talking about how our mom's wore army boots when they fixed their Ford, or other such nonsense. As much as a right of passage as this would be, I do believe it is something to be avoided if possible (it probably isn't) or at least minimized.
We discussed this as a group briefly and decided that our approach would be to make commenting a function for logged in users (the log in being through a google account. This means that while there is no real protection from dedicated trolls, at least the veil of anonymity will be removed and if they want to postulate on the state of footwear of our mothers, at least they will have a name.
We discussed this as a group briefly and decided that our approach would be to make commenting a function for logged in users (the log in being through a google account. This means that while there is no real protection from dedicated trolls, at least the veil of anonymity will be removed and if they want to postulate on the state of footwear of our mothers, at least they will have a name.
Sunday, April 27, 2014
Striking a Balance
One thing that has been coming up quit frequently recently is the need to strike a balance between treating this project as a school project and treating it as a production piece of software as if from a software engineering company.
This has come up mostly as we realize that some things that make for good production level software actually cost money. Like real american dollars.
We really want to produce the best product possible and if we could maintain the illusion that we were a software engineering firm making a real life piece of software this would be ideal. But the fact is that we are not being paid for this (the opposite is actually the case), there is no company to fund development costs (all expenses come out of our pocket), and in all likely hood, the differences will not be missed by many (if any).
As poor college students this is turning out to be a difficult balance to strike. Do we pay a lot of money for a nice tls cert, or can we go the free self signed route? We have already invested money into things like presentation supplies and domain names. We keep having to address this issue and it is difficult.
I think that we are producing a professional quality product in the ways that we reasonably can--the coding. We have gone out of our way to use industry standard code practices in web applications. In this area the balance is clear, be as professional as possible. In the financial domain, it is less clear.
This has come up mostly as we realize that some things that make for good production level software actually cost money. Like real american dollars.
We really want to produce the best product possible and if we could maintain the illusion that we were a software engineering firm making a real life piece of software this would be ideal. But the fact is that we are not being paid for this (the opposite is actually the case), there is no company to fund development costs (all expenses come out of our pocket), and in all likely hood, the differences will not be missed by many (if any).
As poor college students this is turning out to be a difficult balance to strike. Do we pay a lot of money for a nice tls cert, or can we go the free self signed route? We have already invested money into things like presentation supplies and domain names. We keep having to address this issue and it is difficult.
I think that we are producing a professional quality product in the ways that we reasonably can--the coding. We have gone out of our way to use industry standard code practices in web applications. In this area the balance is clear, be as professional as possible. In the financial domain, it is less clear.
Subscribe to:
Posts (Atom)