The presentations today (including ours) went really well in my opinion. However, I don't think there was any question of who the winners were going to be. MechanApp and VisualScheduler had nice presentations and a lot of potential from the very start of the practice presentations. MechanApp had a slick presentation (as usual!) and their website interface is very simple and elegant. VisualScheduler is extremely useful with a nice interface. I think their schedule generator adds a lot of value to their site (on top of the value already added by removing the horror that is scheduling on myUNM!) and, from the sound of it, they are going to turn this into an actual product, which is great. It almost (almost!) makes me wish I wasn't graduating so I could actually try it out.
All the other presentations showed a lot of improvement from the last round of practice presentations. There were almost no glitches and the presentations themselves looked quite professional. I was pretty proud of our team in particular since our initial practice presentations had been so weak (due to lack of practice for the most part). After the optional practice round with Prof. Ackley, we really buckled down and practiced the presentation 10+ times. As I mentioned in a previous post, I also went through and made some edits to the slides, changing the colors, font sizes, and adding graphics, which I think helped make the slides look more professional and less "academic." Overall, I think we improved significantly since Friday (our last practice presentation) and I am glad that we were able to revamp the slides and do a lot of practice because it made a huge difference.
So back at the beginning of the semester, this day seemed so far away. Then suddenly it was the end of April and we were scrambling to wrap up any loose ends before the final presentation. As a team, I think we delivered an application that met our goals, looked pretty polished, and had a presentation to match. I learned a lot from this project, especially since this was my first time using Ruby, Rails, Bootstrap, and Haml and I had only had some limited experience with JavaScript and CSS prior to this. I'm glad that I decided to go with a project that used technologies that I wasn't familiar with since it challenged me and really helped me improve as a software developer. And kudos to everyone on my team; it was good working with you and I learned a lot!
Tuesday, May 13, 2014
Sunday, May 11, 2014
So, does practice really make perfect?
Ok...well maybe not perfect, but certainly it makes you better! Yesterday morning, Matt S., Matt F., Fernando, and I met to practice our presentation. We had made some changes based on Prof. Ackley's feedback (particularly the addition of our slogan--"Help you become a better you") so now we just needed to practice. We were able to practice in the room where the final presentation will be held, which was a great opportunity for us to familiarize ourselves with the projection equipment and figure out whose laptop would work best with the projector's resolution. It was decided that we would use my laptop since the higher resolution projector plays nicely with it.
Once we got everything set up, we went through the slides about five or six times, with Matt F. and Matt S. switching parts (i.e. changing up who would talk through the demo, who would talk through the slides, etc.) to see what worked best. Fernando and I were the audience and judges. In the end, we decided that the best format was to have Matt S. talk though the slides (which, by the end, he was able to do very nicely without any notecards) and to have Matt F. talk through the demo. Since Matt F. was in charge of running the computer, it made it smoother and easier if he also talked through the demo since there would be no possibility of mixing up what was being shown versus what was being said. All in all, it was a very productive few hours and I just wish that we had actually done a lot more practice prior to our practice presentations because we would have done so much better initially. But, at least we are finally practicing now so hopefully the final presentation will go really well.
After the meeting, I started going through the slides for the presentation to make more changes that were brought up during our presentation to Prof. Ackley yesterday. I decided to include a few graphics from the app on some of the slides to break up the monotony of text. I also removed all but the necessary keywords from most of the bullet-points to reduce the overall amount of text. For the bullet-points (not the text, just the bullet-point circles themselves), I reduced the font size significantly and changed their color to green (the same green used in our website) so that they are not so prominent. I think this helped make the slides look a little less academic, which was a criticism that has been brought up during several of our practice presentations.
I still think we might be able to make a few more changes that will improve the overall look and feel of the slides, but at least we have made some significant improvements that I think will help our final presentation.
Once we got everything set up, we went through the slides about five or six times, with Matt F. and Matt S. switching parts (i.e. changing up who would talk through the demo, who would talk through the slides, etc.) to see what worked best. Fernando and I were the audience and judges. In the end, we decided that the best format was to have Matt S. talk though the slides (which, by the end, he was able to do very nicely without any notecards) and to have Matt F. talk through the demo. Since Matt F. was in charge of running the computer, it made it smoother and easier if he also talked through the demo since there would be no possibility of mixing up what was being shown versus what was being said. All in all, it was a very productive few hours and I just wish that we had actually done a lot more practice prior to our practice presentations because we would have done so much better initially. But, at least we are finally practicing now so hopefully the final presentation will go really well.
After the meeting, I started going through the slides for the presentation to make more changes that were brought up during our presentation to Prof. Ackley yesterday. I decided to include a few graphics from the app on some of the slides to break up the monotony of text. I also removed all but the necessary keywords from most of the bullet-points to reduce the overall amount of text. For the bullet-points (not the text, just the bullet-point circles themselves), I reduced the font size significantly and changed their color to green (the same green used in our website) so that they are not so prominent. I think this helped make the slides look a little less academic, which was a criticism that has been brought up during several of our practice presentations.
I still think we might be able to make a few more changes that will improve the overall look and feel of the slides, but at least we have made some significant improvements that I think will help our final presentation.
That dang checkin button...again!
As I had written a few posts back, we had been having issues with the Checkin button; it was not disabling when it should and we had initially traced the problem back to the abandon challenge functionality, where certain records were not being removed and were being associated with the wrong challenge. So, I had fixed this issue...I thought. Then it starts appearing again without any apparent rhyme or reason. When it showed up in our presentation this morning, that was the last straw. As soon as I got home, I started combing through the code again to try to figure out what I had overlooked last time. I cleaned out my database and started taking challenges, abandoning challenges, completing challenges and....ah ha! I found where the bug was occurring. When you completed a 1 checkin challenge and then went to take another challenge within that same week, a date range search was being done in order to find the latest week record associated with the current challenge. Problem was, this was being called with ".first" to return on the first matching record. Thus, if two challenges were completed within the same week by the same user, the week record associated with the first challenge taken would be returned instead of the latest week record. Fixing this issue was a simple matter of replacing ".first" with ".last".
I did some testing after this fix to make sure that it was all working correctly and everything appears to be functioning as expected. I also made a small change to the abandon challenge functionality to make sure that all the Week and History records associated with the abandoned challenge are deleted so that they do not end up causing issues later on.
I did some testing after this fix to make sure that it was all working correctly and everything appears to be functioning as expected. I also made a small change to the abandon challenge functionality to make sure that all the Week and History records associated with the abandoned challenge are deleted so that they do not end up causing issues later on.
Saturday, May 10, 2014
Practice presentation...again
We had volunteered for a final practice presentation with Prof. Ackley yesterday morning. I think it was good that we did it because it is always helpful to get feedback. I think our biggest issue with our presentation is lack of practice. I think we really need to just sit down and run through it at least five or six times in order to figure out what works and what doesn't. You can have a decent presentation, but it won't have much impact if it isn't practiced and smooth.
Prof. Ackley also brought up a lot of things that we can change to make our presentation better. For instance, having a slogan ("Help make you a better you") and, at a minimum, using this slogan in the first and final slides. Also, and this is something I have brought up a previous meetings, we need to justify the honor system choice--i.e. if the user cheats they are only harming themselves. Regarding the competition, we should have more "damning with faint praise" for competitors to help emphasize what sets us apparent from these other applications and why we are "better".
The demo of the app itself still had some glitches and there was some confusion about whether we should show a user signing up (this was nixed as not a good idea) or just logging in. Also, initially starting with taking a simple, pre-made challenge (like "Check-in for signing up" or something similar) would be better than jumping into creating a challenge (though this can be done a little later, since it is an important feature of our application). I also think that whoever does the actual run-through of the slides should be the one whose Facebook account is used since this is less confusing than trying to switch accounts all the time. Prof. Ackley also mentioned that we should try to unify the fonts on our site a little more to go with our mostly lowercase theme. This is something that I finished working on last night so now the font capitalization looks a little more cohesive.
Prof. Ackley also brought up a lot of things that we can change to make our presentation better. For instance, having a slogan ("Help make you a better you") and, at a minimum, using this slogan in the first and final slides. Also, and this is something I have brought up a previous meetings, we need to justify the honor system choice--i.e. if the user cheats they are only harming themselves. Regarding the competition, we should have more "damning with faint praise" for competitors to help emphasize what sets us apparent from these other applications and why we are "better".
The demo of the app itself still had some glitches and there was some confusion about whether we should show a user signing up (this was nixed as not a good idea) or just logging in. Also, initially starting with taking a simple, pre-made challenge (like "Check-in for signing up" or something similar) would be better than jumping into creating a challenge (though this can be done a little later, since it is an important feature of our application). I also think that whoever does the actual run-through of the slides should be the one whose Facebook account is used since this is less confusing than trying to switch accounts all the time. Prof. Ackley also mentioned that we should try to unify the fonts on our site a little more to go with our mostly lowercase theme. This is something that I finished working on last night so now the font capitalization looks a little more cohesive.
Friday, May 9, 2014
Debugging
Yesterday I ran through the website again, doing some randomized testing (i.e. just clicking on buttons in no particular order to make sure things are working) and found an issue with challenges that have parent challenges (i.e. where there are levels of challenges). If, for example, you click a level 2 challenge and you have not yet taken the level 1 challenge, the display modal just shows a button saying "View Parent Challenge". However, I discovered that this button was not actually "hooked up" to anything. So, I spent about an hour googling around and trying to figure out how to get a modal to refresh its content while it is being displayed. After some frustration, I found that some simple jQuery:
worked perfectly. It clears out the old content so that the new content can be loaded (in this case, the new content is the information about the parent challenge).
As I was testing this fix, I found some problems with the .csv file that is used to seed the challenges in the database. Some of the challenges were not having their parent challenges set properly and therefore were not being displayed as child challenges in the application. I went through the list and fixed this issue so that the challenges will now be correctly associated with their parent.
$(document).ready(function(){
$('.modal-id-here').on('hide.bs.modal', function () {
$('.modal-id-here').removeData();
});
});
worked perfectly. It clears out the old content so that the new content can be loaded (in this case, the new content is the information about the parent challenge).
As I was testing this fix, I found some problems with the .csv file that is used to seed the challenges in the database. Some of the challenges were not having their parent challenges set properly and therefore were not being displayed as child challenges in the application. I went through the list and fixed this issue so that the challenges will now be correctly associated with their parent.
Wednesday, May 7, 2014
Ruby on Rails...then and now
I was thinking about my impression of Ruby on Rails now that I've been working with it for ~12 weeks. I had to learn a language that was very different from what I'm used to (Java, C, and C++), which was a little intimidating. I had picked Demigod partly because of the idea itself but also because of the opportunity to learn something more than just Java. I could have gone with a project that had more familiar tools, but I decided to try out something different and I'm glad I did. As frustrating as it was initially trying to remember how models, views, and controllers fit together (not to mention the seventh circle of hell that is setting up Ruby) and where a certain file is located in the maze of folders that makes up a Rails project, I felt I was finally (around week 4 or 5) able to really start making sense of it all.
As someone who is used to working in Java (school and work) with some C and Scheme/Haskell classes thrown in for good measure, I don't have much opportunity to work in other languages unless they are my own personal projects. I've taught myself the basics of Javascript, HTML, and CSS through some of my own projects, but it is never quite the same as having to work on a relatively large project in an unfamiliar language. I think it is a little like learning an actual language: you can take a lot of classes and practice as much as you like, but nothing is better for learning that going to the actual country and immersing yourself in the language. Having a large project is somewhat like that. You have to immerse yourself in the language so you can understand as much as possible as quickly as possible, otherwise there is no way that you can be a functioning member of the team. Though learning RoR could be quite a challenge at times, I think it worked well for our project and we were able to implement all the necessary functionality, create a good layout and design, and deliver a final project that met our requirements. For me, that indicates that the choice of language was a good one. If your language of choice does what you need in a relatively simple and efficient manner, then I say it was the right language for the job. As with any language, there are unique issues and problems that you have to overcome, but, overall, RoR worked for our project.
As someone who is used to working in Java (school and work) with some C and Scheme/Haskell classes thrown in for good measure, I don't have much opportunity to work in other languages unless they are my own personal projects. I've taught myself the basics of Javascript, HTML, and CSS through some of my own projects, but it is never quite the same as having to work on a relatively large project in an unfamiliar language. I think it is a little like learning an actual language: you can take a lot of classes and practice as much as you like, but nothing is better for learning that going to the actual country and immersing yourself in the language. Having a large project is somewhat like that. You have to immerse yourself in the language so you can understand as much as possible as quickly as possible, otherwise there is no way that you can be a functioning member of the team. Though learning RoR could be quite a challenge at times, I think it worked well for our project and we were able to implement all the necessary functionality, create a good layout and design, and deliver a final project that met our requirements. For me, that indicates that the choice of language was a good one. If your language of choice does what you need in a relatively simple and efficient manner, then I say it was the right language for the job. As with any language, there are unique issues and problems that you have to overcome, but, overall, RoR worked for our project.
Sunday, May 4, 2014
Meeting: Clean up and fixes
We had a meeting today to make some final updates/improves to the code and go over our presentation. I updated the code that determines when the user can check-in and what defines a "day" and a "week" is. Previously, for testing purposes, we had set a day to be 20 seconds and a week to be 7*20 s = 140 seconds. This made it much easier to test the current progress code to ensure it was working as expected.
So I make the changes and run the code and...it breaks. When I take a challenge and check-in, everything is fine. But once I complete my first check-in, the "Checkin" button should then be greyed-out until 24 hours later since check-ins are permitted only once per 24 hours. However, the Checkin button is not disabled and I can click it until I finish the challenge. I ask Fernando to run his copy of the code with the seconds usage just to make sure that changing the timing didn't mess things ups. Well, the version of the code on his machine is behaving perfectly fine so I run grep in the command line to make sure that I have replaced all instances of 20.second and 140.second (rails handy way of giving a number of seconds) with 1.day and 7.day. There are no lingering occurrences so I comb through the Javascript for the current challenge progress bar to make sure that I haven't missed some code that might be messing up the timing. Nope, everything looks to be in order.
I clear out my database and take a challenge again. It works fine this time! I then login to my Facebook account and take a challenge there to make it is still working and...it breaks! The Checkin button doesn't disable after the first check-in. So it appears that this problem is caused when two or more users are all taking challenges (not necessarily the same ones) at the same time. Obviously, this is a major problem since our app should be able to handle this fine.
Matt S. and I start looking over the user's controller (which is where most of the methods that run the current progress bar are placed). We also query the database from the Rails console and notice some inconsistencies in the way the weeks and user challenges are being saved in the database. It appears that the wrong week record is being associated with the wrong user when the user is taking a challenge. We skim through the methods in the user's controller to see if we spot a place where the database is being accessed without specifying the current user id. Nothing. We can't find anything out of place so I go back to looking over the presentation.
However, the issue is still bugging me since it is a major problem with the logic of the code. I decide to go over the user's controller once again and finally find the problem. A "where" query is being run on the Weeks model but the current user id is not being passed in so there is the potential for a week record from another user to be returned for the current challenge depending on the matching results returned by the query. Once the current user id is specified in the query, I clear out the database and take challenges in both my administrator account and my Facebook account. Now the Checkin button is properly disabled no matter which account I am in.
So, problem is solved! Not quite. About an hour later, I find that it shows up again, but only after the Abandon a challenge button is pressed. After some digging around in the user challenge model (where the abandon challenge method is located), we discover that the Week records for an abandoned challenge are not being deleted and are causing issues when the next challenge is taken. After adding a line to delete all the Week records for the abandoned challenge, the code runs correctly.
We also spent some time going over the presentation and how we are going to do the demo. Next weekend, we'll meet to really hammer it out and hopefully, if we can get access to the room we will be presenting in, we can also practice in there, which would be really nice.
So I make the changes and run the code and...it breaks. When I take a challenge and check-in, everything is fine. But once I complete my first check-in, the "Checkin" button should then be greyed-out until 24 hours later since check-ins are permitted only once per 24 hours. However, the Checkin button is not disabled and I can click it until I finish the challenge. I ask Fernando to run his copy of the code with the seconds usage just to make sure that changing the timing didn't mess things ups. Well, the version of the code on his machine is behaving perfectly fine so I run grep in the command line to make sure that I have replaced all instances of 20.second and 140.second (rails handy way of giving a number of seconds) with 1.day and 7.day. There are no lingering occurrences so I comb through the Javascript for the current challenge progress bar to make sure that I haven't missed some code that might be messing up the timing. Nope, everything looks to be in order.
I clear out my database and take a challenge again. It works fine this time! I then login to my Facebook account and take a challenge there to make it is still working and...it breaks! The Checkin button doesn't disable after the first check-in. So it appears that this problem is caused when two or more users are all taking challenges (not necessarily the same ones) at the same time. Obviously, this is a major problem since our app should be able to handle this fine.
Matt S. and I start looking over the user's controller (which is where most of the methods that run the current progress bar are placed). We also query the database from the Rails console and notice some inconsistencies in the way the weeks and user challenges are being saved in the database. It appears that the wrong week record is being associated with the wrong user when the user is taking a challenge. We skim through the methods in the user's controller to see if we spot a place where the database is being accessed without specifying the current user id. Nothing. We can't find anything out of place so I go back to looking over the presentation.
However, the issue is still bugging me since it is a major problem with the logic of the code. I decide to go over the user's controller once again and finally find the problem. A "where" query is being run on the Weeks model but the current user id is not being passed in so there is the potential for a week record from another user to be returned for the current challenge depending on the matching results returned by the query. Once the current user id is specified in the query, I clear out the database and take challenges in both my administrator account and my Facebook account. Now the Checkin button is properly disabled no matter which account I am in.
So, problem is solved! Not quite. About an hour later, I find that it shows up again, but only after the Abandon a challenge button is pressed. After some digging around in the user challenge model (where the abandon challenge method is located), we discover that the Week records for an abandoned challenge are not being deleted and are causing issues when the next challenge is taken. After adding a line to delete all the Week records for the abandoned challenge, the code runs correctly.
We also spent some time going over the presentation and how we are going to do the demo. Next weekend, we'll meet to really hammer it out and hopefully, if we can get access to the room we will be presenting in, we can also practice in there, which would be really nice.
Subscribe to:
Posts (Atom)