The first Milestone for our Software Engineering project is approaching fast! I’m taking a few minutes to take a look at how things have gone since the last post, wherein we were just kicking off our mockup.
Play With Magic, as we’ve dubbed our project, is a website intended for Magicians to be able to create and share Routines, and then from a list of Routines that they’ve saved, build a Set. Confusing? Don’t worry, I’ll go over the details of each of these as we go along.
As part of our development, we were able to garner feedback from three professionally practicing magicians:
Each of them had great things to say about our project, and brought a ton of great suggestions to the table, many of which I don’t think we’ll have sufficient time to accomplish in the timeline of the project. However, it was quite exciting to get them on board, and know that we have a real hit with this.
Since then, things have gone into full development swing. We’ve gotten a better wrangle on GitHub Issues, and while it still doesn’t completely meet the needs of project tracking, we’ve added enough labels to it that it allows us to easily categorize things into multiple silos as necessary. A few labels like “perpetual” have been useful for items that we need to continually keep on top of, such as writing tests, making sure everything passes CheckStyle, and making sure that our code is formatted to standards that CheckStyle doesn’t catch.
Much of the time in our second run was spent moving from the mockup stage of development to a running framework inside of Play. The first round of this didn’t go so well. We tried to refactor a digits application (another project we’ve been using in class for practicing Play), and place it into the mockup project. However, since the mockup was originally made as a pure HTML application, it didn’t have any of the necessary supporting framework for Play, and eventually started to create all kinds of issues. Once we realized what had happened, an evening was spent using activator new to create a new Play Framework application from scratch, and the migrating everything from the fubar project into the new fresh one. Once this was completed, it resolved the majority of our development issues.
After this, we divvied up application development into the two major parts we wanted to build: Magicians and Routines. A Magician is a person that performs a Routine, and a Routine is a single magic trick that is performed. This was fairly straightforward, but partway into development, we decided we wanted to use some checkboxes in forms that would reflect boolean values. It turns out that Play and Scala do not do terribly well with boolean value checkboxes. Mark did find a solution to this issue eventually, but it wasn’t until a few days before our Milestone 1 presentation was due.
While working on application development, I still found myself having to frequently refer back to the issues list to remember what issue number to tag a commit with. It’s just not terribly descriptive for the developer to have to dig up a number to refer to a problem related to what they’re doing. I do continue to like being able to easily attach commit messages to issues using this, however, as it sort of self-documents progress on an issue without having to do any comments on the issue itself. In the end, I find the trade-off to be worth it.
We’ve also had our first few snags with merging commits, but nothing terribly messy. Most of our work is done in independent branches, and it’s only when merging back into our main Milestone-1 branch that anything has come up. And most of the times, we’ve done the merge commits over Skype together to make sure that we’re not accidentally clobbering anything that someone else has done.
After wrapping up the majority of development on Magicians and Routines, I turned my way to Sets. A Set in the magic community is a series of Routines that are performed in sequence; in short, it’s a show of magic tricks. I decided to make things easy and store the Routines associated with a given Set as an array of Routine IDs, which will make things easier when building the database out. However, I also ran into checkbox issues with Scala and Play. After an hour and a half of wrangling with it, I found the solution: make sure that for the input checkbox, make sure that the name field is the same as the List object being passed in, then append [] to the end of it. For example, name="routines[]" was used for the list of routines in each Set. This makes Play treat each checked form input as another item to add to the List; if it’s not checked, it’s ignored.
We also made sure to go over whether our application was functioning well as a responsive layout, and found a few bugs that were leftover from the original mockup. With these fixed, I’m fairly confident that the user experience on both small and large screens will be relatively identical.
Group cohesion has continued well with regular check-ins and meetings over Skype. We’ve set a routine wherein if we have a meeting, we list out the topics that need to be covered at the start, go over them quickly in turn, and usually wrap up well within an hour. If there’s not something we need to specifically address, we comb through the issues list and make sure we’ve covered all of the present issues, and if necessary, change labels or milestones. Overall, I haven’t felt at any point that we’ve been unbalanced in the work done, and that each of us has committed a good amount of effort into the project.
As of this writing, our site is now live on Heroku! We had a brief discussion and decided to appoint a “Heroku Master”, who is responsible for merging all work into our repository’s master branch, and then deploying it to Heroku. This was done to prevent the live running copy from accidentally being clobbered in case we needed to collect data from it. It’s also to prevent any issue with work that shouldn’t be in the master branch yet accidentally being merged in.
You can check out the current running copy of our application over at http://www.playwithmagic.org/!
Current functionality allows the end user to do the following:
- Browse, Create, Edit, and Delete Routines, with Materials lists in each Routine
- Browse, Create, Edit, and Delete Magicians
- Browse, Create, Edit, and Delete Sets, which group Routines
- View our project information on the About page
- Get help and information about the project on the Help page
From here we’ll be adding a database in our next stretch, so we’ll see what challenges that brings!
In addition, we are (as always) applying the use of ERDs using Athletic Software Engineering, and building our ERDs with the free online Lucid Charts tool. Here’s how each of our examples were built, and the resulting ERD diagrams!
Patrick A. Karjala 