After the Project Showcase, I am quite impressed with the level of all the presentations. From my point of view, all of us made a great effort in the last weeks to improve the pitches and demos. VisualScheduler (1st) and MechanApp (2nd) were the winners of the Spring 2014 CS 460 Project Showcase. Honestly, my personal bet before the event was exactly the same as the final jury's decision. It was obvious that both projects were the best ones, and finally the judges opinion was similar to (I guess) the rest of my classmates.
In my opinion, VisualScheduler is, by far, the most helpful app, because all of us know how difficult is to build your schedule using the current UNM system, so you (and the judges) quickly realized that this application could be really useful for a lot of students, not only at the UNM, but also in other universities along the U.S. Additionally, they gave a very good presentation (as usual), so they deserved the first place, with no discussion. On the other hand, MechanApp also gave a decent presentation, and their application looked very cool, especially in terms of design. Apart from these facts, I think that, in terms on usability, this is the second most useful application, only surpassed by VisualScheduler. I would like to congratulate all the teams, especially the winners. As said before, the level of all the projects and presentations was higher than I expected at the beginning of this course.
Regarding to my team, I believe that we gave a very clean presentation, much better than only a week ago. In this sense, Matt S. and Matt F. did an awesome job, all went as planned. It was worth getting together last Sunday and Monday for walking through the presentation, as well as the practice pitch on Friday and definitely, the feedback provided by Ackley.
Despite not winning any prize, I am very proud of the project I was working on. I believe that we worked very hard along the last months, and I have learnt to use new technologies such as Ruby on Rails. However, the most important thing I may say about this course, is that I was able to work as part of a development team in a country different from I am used to work, which is a priceless experience for me. Thank you to all the classmates, and especially to my teammates!
Software Engineering
By Fernando Serrano - CS 460 Spring 2014 - University of New Mexico
Wednesday, May 14, 2014
Tuesday, May 13, 2014
The die is cast
The day before the final presentation, we have met again at the Centennial Engineering Center conference room. We wanted to practice one more time the presentation, including the pitch and the demo. This time, we had the slides with all the modifications that Ackley suggested us last Friday.
As we agreed last Sunday, Matt S. will start the pitch, and then, he will pass the baton to Matt F., who will go through the demo. Finally, Matt S. will close the presentation with some conclusions. Therefore, we walked through our pitch&demo three times, and now, I am pretty sure that we are ready to the final presentation.
However, we decided to make some minor changes on both the slides and the pitch. Regarding to the slides, we changed the size of the icons and text on the Maintenance slide, because they were too small, and it was hard to read the titles. On the other hand, we moved the part of the pitch in which Matt S. explained why to cheat when using Demigod does not make sense, "because you are actually hurting yourself". Initially, we had this part in the end, but we decided to move it to the Demigod Users slide, because it seemed a better moment to talk about the honor system.
Additionally, we included a QR code in the handout which redirects users to the website (www.demigod.me) if they read it with a smartphone. We are planning to print out about 50 copies of the handout. It should be enough for the audience we expect on the Project Showcase event.
The die is cast, in just a couple of hours we will have presented our project. Which project will be the winner?
As we agreed last Sunday, Matt S. will start the pitch, and then, he will pass the baton to Matt F., who will go through the demo. Finally, Matt S. will close the presentation with some conclusions. Therefore, we walked through our pitch&demo three times, and now, I am pretty sure that we are ready to the final presentation.
However, we decided to make some minor changes on both the slides and the pitch. Regarding to the slides, we changed the size of the icons and text on the Maintenance slide, because they were too small, and it was hard to read the titles. On the other hand, we moved the part of the pitch in which Matt S. explained why to cheat when using Demigod does not make sense, "because you are actually hurting yourself". Initially, we had this part in the end, but we decided to move it to the Demigod Users slide, because it seemed a better moment to talk about the honor system.
Additionally, we included a QR code in the handout which redirects users to the website (www.demigod.me) if they read it with a smartphone. We are planning to print out about 50 copies of the handout. It should be enough for the audience we expect on the Project Showcase event.
The die is cast, in just a couple of hours we will have presented our project. Which project will be the winner?
Monday, May 12, 2014
We are (almost) ready...
We decided to get together on Sunday morning to practice the pitch one more time. Fortunately, the Centennial Engineering Center conference room was open, and we were able to practice our pitch in the same place as is going to be held tomorrow. This was really helpful, because we had the opportunity to set up the projector, try the TV's, as well as set an appropriate resolution. It was much easier than I expected, and we had all ready in just a couple of minutes.
As the configuration process went pretty quick, we could focus on the pitch itself. Based on the feedback provided by Professor Ackley on the Friday's optional pitch practice, we previously made some changes both in the slides and in the pitch. We decided to practice three ways of giving the presentation:
While Matt F. and Matt S. practiced the pitch, Natalie and I, acted as judges. I particularly liked the second version, because I saw Matt S. more confident when he spoke about the Demigod's features (maybe because, along the last weeks, he had practiced the pitch more times than Matt F.), whereas Matt F. did a great job explaining the demo, using a natural language, easily understandable by the audience. Additionally, I realized two more things when we followed this version:
- Matt S. can take a rest in the middle of the pitch, and be ready for the second part.
- As Matt F. only explained the demo, he was able to take control over the laptop, showing exactly what he wanted to display. This avoids any lack of coordination between the speaker and the laptop's handler.
Natalie also preferred the second version, so we went again through this way twice, and finally, I felt that we chose the right option. I saw Matt F. slightly more confident, and Matt S., who had brought a bunch of notecards, did not use them any more (which is good, because it gives a better impression to the audience).
The rest of the weekend, we worked on finishing the slides clean up based on the Ackley's feedback (font sizes, colors, slogan, graphics, etc.). Besides, I created a shared folder on Dropbox and several sub-folders in order to add all the project materials. So I included the documentation we have on Google Drive, as well as the story board, the timeline, and the full commit log.
This evening, we are going to practice one more time trying to debug some minor things on the pitch, but I am absolutely convinced that our presentation will go well tomorrow.
As the configuration process went pretty quick, we could focus on the pitch itself. Based on the feedback provided by Professor Ackley on the Friday's optional pitch practice, we previously made some changes both in the slides and in the pitch. We decided to practice three ways of giving the presentation:
- Matt F. (Intro), Matt S. (Demo and some slides), Matt F. (Last slides after the demo)
- Matt S. (Intro), Matt F. (Demo), Matt S. (Last slides after the demo)
- Matt S. (full presentation)
While Matt F. and Matt S. practiced the pitch, Natalie and I, acted as judges. I particularly liked the second version, because I saw Matt S. more confident when he spoke about the Demigod's features (maybe because, along the last weeks, he had practiced the pitch more times than Matt F.), whereas Matt F. did a great job explaining the demo, using a natural language, easily understandable by the audience. Additionally, I realized two more things when we followed this version:
- Matt S. can take a rest in the middle of the pitch, and be ready for the second part.
- As Matt F. only explained the demo, he was able to take control over the laptop, showing exactly what he wanted to display. This avoids any lack of coordination between the speaker and the laptop's handler.
Natalie also preferred the second version, so we went again through this way twice, and finally, I felt that we chose the right option. I saw Matt F. slightly more confident, and Matt S., who had brought a bunch of notecards, did not use them any more (which is good, because it gives a better impression to the audience).
The rest of the weekend, we worked on finishing the slides clean up based on the Ackley's feedback (font sizes, colors, slogan, graphics, etc.). Besides, I created a shared folder on Dropbox and several sub-folders in order to add all the project materials. So I included the documentation we have on Google Drive, as well as the story board, the timeline, and the full commit log.
This evening, we are going to practice one more time trying to debug some minor things on the pitch, but I am absolutely convinced that our presentation will go well tomorrow.
Saturday, May 10, 2014
Optional pitch practice
Despite not being required and not having any direct impact on our grade, we decided to take part into the optional pitch practice proposed by Ackley in the last lecture of this course. In this sense, we considered that we could improve our pitch in somehow, and having direct feedback from Professor Ackley would be one of the easiest ways to get it.
We based our pitch on the model that we cleaned up during our last team meeting. From my point of view, this time the demo slides flew better than other presentations in class, and Matt. S. spoke calmer and more confident. Anyway, Professor Ackley give us useful feedback on the presentation and the demo:
Presentation reactions:
We based our pitch on the model that we cleaned up during our last team meeting. From my point of view, this time the demo slides flew better than other presentations in class, and Matt. S. spoke calmer and more confident. Anyway, Professor Ackley give us useful feedback on the presentation and the demo:
Presentation reactions:
- Slightly long (1 minute over the scheduled time)
- Set up issues (again). We need to get everything setup before the presentation, and we should keep the VGA cable unplugged until all is ready.
- Hide the left sidebar (Ubuntu) when displaying the demo.
- We have to think about a "catchy" slogan to display at least on the first and the last slide (Ackley suggested: "Help you become a better you").
- Mention in some point of the presentation the fact of cheating is in fact "hurting yourself". So, this game does not make sense if users cheat.
- Introduction & facts: match rankings and speech.
- Our slides look "too academic". We need a new theme with bigger fonts (more striking).
- Remove the "Demonstration" slide. Just show the demo.
- Change the title of Sustainability slide to something more informal like “Keeping the lights on”.
- Be sure to mention in the Competition slide that Demigod "puts everything together for free".
- Some minor changes regarding to the slides order.
- He liked the technology choice justification.
- He do not like the lack of email confirmation when a new user sign up.
- Change the name of the non-logged page (first page that user see when enter the website) from "marketing page" to "Home page" or something similar.
- He also do not like the fact of starting the demo by showing how to create a custom challenge. Move this example later, and emphasize on the Demigod's flexibility and customization.
- Choose a challenge (as an example) that you can really do. For example, ride your bicycle twice a week, and say something like "I have ridden my bicycle to come here".
- Consistence on text capitalization. There are several inconsistencies especially on the home page.
- Close the presentation with the slogan and the URL. We need to cause impact on the audience.
Now, I believe that we are ready to the project showcase which is going to be held next Tuesday. Cross our fingers, and go ahead!
Wednesday, May 7, 2014
What is the connection between Computer Science and Software Engineering?
We discussed about this question last Monday in our last lecture. In fact, the real question was a quote from Steve Jobs: "Real programmers ship code". From my point of view, this course brings you the opportunity to apply all your previous knowledge to a particular project, which is actually a clear connection between CS and SW Engineering.
I think that this happens continuously when you face a new project, like decide when is better to use certain resources (even little things that, apparently, should not have too much impact on the project). I think SW Engineering implies something beyond programming, efficiency or performance. In this sense, "new" terms like deadline, schedule, compromise, customer, stakeholder, task, etc. arise when you deal with a real project.
I agree with the way that Ackley talked to establish the difference between CS and SW Engineering. He said that CS is about "building ideas", and SW Engineering is "take these ideas and apply them to specific cases" (i.e., "building stuff"). It is clear that there exists a connection between both disciplines, and I believe we can say that CS makes no sense without SW Engineering, and vice versa.
I think that this course is especially useful to realize why you took other previous CS courses, because you have to use all your knowledge, applying the best of your skills and experience for the good of your team.
Last, but not least, working successfully as part of a team is also a key part of this course (and in the real life), because Software Engineering does not only mean engineering. This is very important for output quality, talent, and communication.
I think that this happens continuously when you face a new project, like decide when is better to use certain resources (even little things that, apparently, should not have too much impact on the project). I think SW Engineering implies something beyond programming, efficiency or performance. In this sense, "new" terms like deadline, schedule, compromise, customer, stakeholder, task, etc. arise when you deal with a real project.
I agree with the way that Ackley talked to establish the difference between CS and SW Engineering. He said that CS is about "building ideas", and SW Engineering is "take these ideas and apply them to specific cases" (i.e., "building stuff"). It is clear that there exists a connection between both disciplines, and I believe we can say that CS makes no sense without SW Engineering, and vice versa.
I think that this course is especially useful to realize why you took other previous CS courses, because you have to use all your knowledge, applying the best of your skills and experience for the good of your team.
Last, but not least, working successfully as part of a team is also a key part of this course (and in the real life), because Software Engineering does not only mean engineering. This is very important for output quality, talent, and communication.
Monday, May 5, 2014
Another profitable team meeting
Our team had a meeting this Sunday. We spent almost 4 hours going through all the stuff that needed to be done. It was actually a kind of coordination sessions, and we finally accomplished several things:
- We worked on the slides, which are now ready for the final pitch. In fact, we are going to have a last practice pitch next Friday at Ackley's office. I think this will provide us a very useful feedback.
- Natalie updated the code that determines the duration of a day and a week, because we had been assuming that a day was 20 seconds (for testing purposes).
- I finished the Frequent Asked Questions page
- I added links to the FAQ page and Contact form both from the homepage and profile page.
- I made some changes in the contact form. Concretely, I became some critical variables (Gmail account and password) in the application.rb file from plain text, to environment variables. We still have to test them, because we were not able to make it work properly.
- Natalie and Matt S. fixed several important bugs regarding to the check-in and abandon challenge buttons.
- Matt F. created a Google document with the headlines of the speech we are planning to make.
- We also made a practice pitch with the updated slides and the new demo. It seems that it is going to be better than the previous ones.
This week, we will work basically on running some test, trying to find bugs before the final demo. Additionally, we have to prepare the final group turn-in, which is due to the next day of the final project showcase.
- We worked on the slides, which are now ready for the final pitch. In fact, we are going to have a last practice pitch next Friday at Ackley's office. I think this will provide us a very useful feedback.
- Natalie updated the code that determines the duration of a day and a week, because we had been assuming that a day was 20 seconds (for testing purposes).
- I finished the Frequent Asked Questions page
- I added links to the FAQ page and Contact form both from the homepage and profile page.
- I made some changes in the contact form. Concretely, I became some critical variables (Gmail account and password) in the application.rb file from plain text, to environment variables. We still have to test them, because we were not able to make it work properly.
- Natalie and Matt S. fixed several important bugs regarding to the check-in and abandon challenge buttons.
- Matt F. created a Google document with the headlines of the speech we are planning to make.
- We also made a practice pitch with the updated slides and the new demo. It seems that it is going to be better than the previous ones.
This week, we will work basically on running some test, trying to find bugs before the final demo. Additionally, we have to prepare the final group turn-in, which is due to the next day of the final project showcase.
Saturday, May 3, 2014
Contact form
In the last team meeting, I proposed to create a contact form to enable users a way to contact us directly if they have any question or problem that needs support. After a quick research on the Internet, I found some information about how to create forms in Rails, so I got to work...
First, I created a new Gmail account for Demigod, because I did not really have any contact email so far. Having the account, I started working on Rails by configuring the email parameters in the application.rb file:
config.action_mailer.smtp_settings = {
:address => "smtp.gmail.com",
:port => 587,
:domain => "demigod.me",
:user_name => "new_account@gmail.com",
:password => "************",
:authentication => :plain,
:enable_starttls_auto => true
}
config.action_mailer.default_url_options = {
:host => "demigod.me"
}
Then, I created the message model file (message.rb), as well as the mailer model (/mailers/notifications_mailer.rb) and views. So I add the files /views/notifications_mailer/new_message.text.erb (for message layout):
Name: <%= @message.name %>
Email: <%= @message.email %>
Subject: <%= @message.subject %>
Body: <%= @message.body %>
Besides, I generated the controller file (app/controllers/contact_controller.rb), and I added the two required actions (new and create):
class ContactController < ApplicationController
def new
@message = Message.new
end
def create
@message = Message.new(params[:message])
if @message.valid?
NotificationsMailer.new_message(@message).deliver
redirect_to(root_path, :notice => "Your message was successfully sent")
else
flash.now.alert = "Error: Please fill all the fields"
render :new
end
end
end
Then, I created a new Haml view file to display the form itself. I focused on the functionality rather than on the design, because I first wanted to check if it worked properly. Finally, I added the corresponding routes (GET and POST) in the routes file to make sure about the previous actions worked. I set the URL /contact to get access from the website:
match 'contact' => 'contact#new', :as => 'contact', :via => :get
match 'contact' => 'contact#create', :via => :post
I tested the new form with several examples and, fortunately, I received correctly all the emails sent through the new contact form. In the coming days, I will work on the design of the contact form, but I want to run more tests before going further. Additionally, I would like to figure out how to hide the email account and especially the password from the configuration file, because it is clear that, in terms of security, this is a huge vulnerability for our website.
First, I created a new Gmail account for Demigod, because I did not really have any contact email so far. Having the account, I started working on Rails by configuring the email parameters in the application.rb file:
config.action_mailer.smtp_settings = {
:address => "smtp.gmail.com",
:port => 587,
:domain => "demigod.me",
:user_name => "new_account@gmail.com",
:password => "************",
:authentication => :plain,
:enable_starttls_auto => true
}
config.action_mailer.default_url_options = {
:host => "demigod.me"
}
Then, I created the message model file (message.rb), as well as the mailer model (/mailers/notifications_mailer.rb) and views. So I add the files /views/notifications_mailer/new_message.text.erb (for message layout):
Name: <%= @message.name %>
Email: <%= @message.email %>
Subject: <%= @message.subject %>
Body: <%= @message.body %>
Besides, I generated the controller file (app/controllers/contact_controller.rb), and I added the two required actions (new and create):
class ContactController < ApplicationController
def new
@message = Message.new
end
def create
@message = Message.new(params[:message])
if @message.valid?
NotificationsMailer.new_message(@message).deliver
redirect_to(root_path, :notice => "Your message was successfully sent")
else
flash.now.alert = "Error: Please fill all the fields"
render :new
end
end
end
Then, I created a new Haml view file to display the form itself. I focused on the functionality rather than on the design, because I first wanted to check if it worked properly. Finally, I added the corresponding routes (GET and POST) in the routes file to make sure about the previous actions worked. I set the URL /contact to get access from the website:
match 'contact' => 'contact#new', :as => 'contact', :via => :get
match 'contact' => 'contact#create', :via => :post
I tested the new form with several examples and, fortunately, I received correctly all the emails sent through the new contact form. In the coming days, I will work on the design of the contact form, but I want to run more tests before going further. Additionally, I would like to figure out how to hide the email account and especially the password from the configuration file, because it is clear that, in terms of security, this is a huge vulnerability for our website.
Subscribe to:
Posts (Atom)