Making Event Planner

So, a few months ago, our class was divided into groups, and were given freedom to pursue our own project of choice. While this sounds like quite an exciting thing, I learned whilst working on it a few things:

1. Coming up with a product idea is really tough
2. Issues are a great way to make actionable tasks
3. Keeping in contact is important
4. Sometimes, you have to wrangle technology

I’ll break down how I came to these points when you’re thinking of starting a project of your own. You can check it out here, and check out the code on GitHub here.

Coming up with a product idea

We had been split up into groups, and the first question that came out was,

“So, what are we making?”

Turns out that is a really difficult question to ask, and not something that really can be sorted easily by students studying web development, and not marketing.

We were able come up with a few ideas, including:

• A map that shows useful facilities around cities
• An ingredient database which notifies users when food is about to spoil
• An event planner which users can use to organise, conduct, and pay for events

After that, we sort of ran out of ideas. We agreed that we should definitely pick just one of those things listed above, and just run with it. Event Planner won.

In retrospect, I think the personal ingredient database might be more marketable since it solves a problem I tend to have, it doesn’t seem particularly difficult to implement, but not everyone was for it.

Issues make good actionable tasks

Of the constraints that we had at the time, it was quite a busy time of the year. With multiple assignments from other subjects, it was important to prioritise certain tasks over others.

For our group assignment, this could be done intuitively since we could make use of GitHub Issues. This could also be achieved with functionality in GitLab, but for the purpose of the assignment (as well as keeping friction low), we went with GitHub.

Our project wasn’t exceptionally large, so the main features we made use of in Issues were:

• Assignees
• Labels, and
• Milestones

Being able to delegate tasks to other group members was essential in guiding their work into problems that need solving, and it also tells us how much work is done by people in the group

Labels (a.k.a tags) were useful to tell us what sort of problems or tasks we were coming across, and it helped with assigning people to the issues.

Milestones were useful to prioritise essential features over the fancier features which were nice, but not part of the core set of things to include. This ended up in a document of its own with the specifications.

Staying in touch

Our group could only meet up reliably about once every week, since some of us weren’t available for class all of the time—one member of our group was a part-time student.

Communication through GitHub Issues is helpful in talking about specific problems, but for general day to day things, we needed another platform to talk on.

We ended up going through Slack. It provided a free plan which was adequate for our needs—after all, we were unlikely to need a message history past 10,000 messages, huge file storage, compliance features, or the more deeper administration settings that the paid plans had.

Slack ended up very handy for immediate communication when we were working. When working on any particular issue, we could talk about problems we had along the way, and everyone could chime in with ideas and potential solutions.

Wrangling the technology

Laravel is pretty good. But when you’re running short on time in the semester, you really have to hustle to grab everything and pull it together into a coherent project that you can demo.

The last time I worked on a major project was with a framework called CodeIgniter. Currently maintained by the British Columbia Institute of Technology, its structure is ideal for the concept of MVC (model, view, controller), which is a good way of separating data operations, displaying information to users, and all the logic that glues it together.

Laravel is similar in that you can use it with MVC. But the structure is different enough to my use of CodeIgniter that not everything that I assumed would be the same was actually the case.

The best way of learning Laravel is through some video tutorials, which I felt was a downside since I prefer to read the steps and get going at my own pace. With the videos, I typically had to pause and rewind several times before I had a process down.

Mind you, this is from my perspective; someone who is already into video tutorials would likely have a great time using them.

But wait, there’s more!

We used Laravel in hope of deploying it to commercial infrastructure, and for that, we decided to go ahead and use Microsoft Azure, using their App Services.

As a student, we can use basic Azure services, which means we don’t have access to any paid services (which turns out to be a lot of services) such as creating an instance to run our database, more on that later.

It was a relatively simple job to set up the deployment so we could push our Git repository to the container that was allocated to us. Of course, we needed to automate a few things for it to work:

1. Composer, so we can resolve the back-end dependencies for our app
2. Node.js, so we can resolve dependencies for compiling front-end assets
3. Execute a PHP command (namely php artisan migrate) in order to make clean changes to the database structure

This all went well, up until the demo day.

Day of the Demo

It’s typically dangerous to make changes to your software when you’re about to present it. I push the changes from our repository live, and it seems alright for a bit.

Then we try to fill in some demo data, so the visitors have something to look at. Not much help making an events site without no events to go to, right?

It throws an error, and then we scramble.

Turns out that the migration tool couldn’t connect to the MySQL in-app instance, which meant that the migrations made to creating the categories table did not work at all. So we had to backpedal a significant chunk of code for linking categories with events.

At the End of the day

I haven’t at this time been able to get any migrations to work on the App Service. Despite the environmental variables being set, the artisan script doesn’t seem to utilise them.

There’s some work to be done on the back-end and front-end stuff, since we weren’t able to get all the features in to make it feature complete. Some of the things to do include:

• Implementing a published flag so unpublished events do not show up
• Fixing a hover effect which doesn’t make the site usable with mobile devices
• Implementing the categories feature more fully
• Better looking search component, since it was basically just a text list
• Letting organisers set an event image

Despite all the work to be done, I’m pretty happy with how the group operated and the work that they did. We learned a lot about creating and deploying an application, from development to a live site. Hopefully, this will be useful for you!

Once again, you can check out the code here and the demo site here.