Also, worked hard on updating the Trello board... I've added a lot already. More to come. Need to work on the help site and a simple update to the main marketing website.

Been working all day to get Simple Schedule beta ready... pretty excited about it. Maybe tomorrow ;)

Slowly getting ready for the beta...

It’s been an active week for the project. Even though I haven’t been feeling too well, down with a cold, I feel progress has been great. Out of curiosity I also started logging time on when I work on it.

You can see last week times below:

That doesn’t include the 3 hours I did after Sunday :) All in all, I spent 32 hours on Simple Schedule this month.

There are many things I worked on as I etch closer to the beta launch of the site.

Email templates

Monday was pretty much filled with hate of hacking together email templates, using tables. I don’t want to go into too much details, but at least now the emails look nice when I send them out. There are further tweaks I’d like to do this week.

I’m not sure why I say that “links are only valid for roughly 15 minutes”. I know exactly how long they are valid for. The email above has changed in wording since.

I’m glad you signed up and hope you enjoy the service. It's ever evolving and run by me personally.
You'll need to verify your email account using the link below.

I'm always around to help you get set up with Simple Schedule, so drop me a line if you have any questions. You can reply to this email if you'd like to say hello.

Note that links are only valid for roughly 15 minutes. If you need another, you can do so in Settings.

There is also a delete email, with a red button:

That swiftly concludes email templates. May I never speak of them again.

Event details redesign

As I started implementing the logic for the details page, https://frontend.dev.simpleschedule.net/app/events/details/, I quickly realised that I didn’t like the look too much. It felt very distracting and all over the place. True, I rushed it a bit when I designed it.

So, starting from scratch I came up with the following:

Much nicer and cleaner… I hope. With some real world data it looks like this:

You can see I introduce some additional controls and a search bar when there is data. I don’t actually show search until there are more than 5 bookings for an event.

I also introduced some slight changes to wording. Instead of “Attendees” I am now just calling these “Bookings” for events. Easier to type in code ;-) And obviously makes a bit more sense!

Add a booking

I’m not sure why, but this section was rather difficult for me. But… as most things… got there with determination. We have a simple booking page, which also does a autocomplete for any attendee in your database. It works quite well and I’m happy with the results here.

Clicking on anyone will pre-fill all the data for you. Nothing else required. If you’re interested I’m using this: https://github.com/Pixabay/JavaScript-autoComplete

It’s vanilla JS and doesn’t rely on jQuery. So a win win for me!

Although it all seems quite simple there is some logic going on behind the scenes when you create a booking, even if you decide not to use autocomplete.

When you save the entry it checks if the attendee exists in the database. If they do, it will check if there are already any bookings for this event for this person, if there is it will tell you and offer you a link to the booking in question.

Ok, if there is no booking, it will create a booking. Easy as that. If the attendee is already on the master list, it will not create a second entry there, nor will it update any data - doesn’t matter if you type it in manually or not. I just check against the email here.

Next scenario is if the attendee is not on your master list. Here I create the attendee entry in the system and assign the booking after it successfully creates the attendee.

The booking logic is some of the longest I wrote for the entire app. There are many checks I have to perform to make sure it’s all good. However I found that Rails really helps a lot here especially with validating models of different data.

The public booking, for when someone enters their details on the public page for the event, works in a very similar way. So I won’t go into detail. Although it performs similar checks and stops you from registering twice.

Booking search

This one was hard. But glad I spent time until very early morning completing this. I had to get my head around how to best search bookings by date and also filter them by name.

My booking table looks like this, with the following columns:

event_id, event_date_id, attendee_id

Obviously not everything there but I had to scratch my head on how to get the attendee data across. Thankfully, after hours of looking into it, it’s quite easy. I also want to thank John Maguire over at http://www.rubyonrails.link for help with showing me how to best try and search when it comes to referencing different models.

I’m actually using ‘pg_search’ for attendees already: https://github.com/Casecommons/pg_search. After reading through the documentation again and again I found out that you can search for associated models too. Handy!

 pg_search_scope :search, :associated_against => {
 :attendee => [:name, :email]
 }

Here we go, this did the trick for me on the ‘Booking’ model. Works as advertised and returns exactly what I want, including the date filter! Happy about that small achievement. I was actually going to leave out the name search until after beta, but I had to scratch the itch.

Public event view

Not sure why I was holding it off, but here is the public display for an event:

Simple and clean, no drama. It’s got room for improvement for sure, but it does the job nicely and shouldn’t be an eye sore!

I’ll be working a little more on this over the course of the week but feel it is feature complete for now. The logic is working and bookings are created without issue. As people use it and hopefully give me feedback I’ll make changes here and there. I do want to offer a few options to let the user decide what shows up or not.

Next steps… beta

The app, as it stands, is pretty much ready for beta testing. There are a few tweaks I’d like to do beforehand. There are certain specific beta features I need to add before it goes out to the public. Not to mention finish off those items on my 'alpha' Trello board.

There is also now the urgency to work on a simple holding site to show off the product a little more and get the help page up.

I’m planning to open up another Trello board and have a Slack group for the beta so I can work with everyone that signed up. I’ll also be looking at emailing everyone on the list to give them an update on the app. It’s important I get feedback so I will probably ask them to fill out a very short questionnaire.

No doubt errors will happen, so I’m going to be setting up some extra logging. I already use Papertrail for my servers so I will try and add it on in Heroku (not even sure you can use the same account).

Before I open up beta invites, there also need to be T&C’s set up and all that good legal stuff…

If you like to contribute, please email me or let me know via Micro.blog. There is also the Simple Schedule holding site where you can sign up for a beta. On top, there is now a public Trello board with dev site progress. You can visit the 'pre-alpha' website to play around.

For other posts on the challenge, check out the links below:

1. Code challenge - from zero to web app in 60 days.
2. Code challenge - Prelude and Day 1 - Setting things up.
3. Code challenge - Day 2.
4. Code challenge - Day 3. Holding page.
5. Code Challenge - Day 4. A login page and a few tweaks.
6. Code Challenge - Day 5. Registration page and preliminary app navigation.
7. Code Challenge - Day 6. Getting in the groove, new events, MVP considerations.
8. Code Challenge - Day 7. 'My Events' view.
9. Code Challenge - Day 8. Burning the midnight oil, loud music and good progress.
10. Code Challenge - Day 9. Progress, changes and regrets.
11. Code Challenge - Day 10. There are no events, pricing thoughts and badges.
12. Code Challenge - Day 11. New logo, further changes to event details and a tiny tweak.
13. Code Challenge - Day 12. Final frontend stretch.
14. Code Challenge - Day 13. Choosing Rails, getting into the swing and thoughts on a multi tenancy app.
15. Code Challenge - Day 14 & 15. Blog post thoughts, passwords and learning.
16. Simple Schedule - Day 16 & 17. Register, Login and sharing progress.
17. Simple Schedule Dev Diary - Week 4. Profile, Settings, Passwords and Attendees.

Was totally worth staying up till 03:00 AM to work on adding better search to bookings. Now I must sleep.

Still a bit of work to do, but I've worked on some basic styling for the public event view for Simple Schedule. Hope to expand it a little later on. The form works!

Would certainly help to add this to some of my recently created controllers...

before_action :logged_in_user

Only a few more items on my list before I feel comfortable launching Simple Schedule to 'beta'. Going to try and complete 2 out of 4 tonight.

I'll also have to create the actual marketing site and a help site...

Thinking of creating random placeholder text when you load a page with inputs. Liven it up a little...

Happy to have spent the morning working on 'auto complete' for bookings. Works pretty well. Will need some more refinement during beta though.

Spending some time today to re-work the 'Events' detail page. Not happy with the way it looks. I'll also be working on getting the 'public' link designed and done.

check_if_date_to_changed_and_set_multiday_false

Is that a long method name? I never know what to call them...

Getting to that stage where I look at the design and want to make many changes...

As January closed and February begun, I was hoping to have the beta ready. Plans are plans and are always changing, although some of it was out my control.

I’m happy with the progress during the week and am pleased that I’m learning a lot and getting more confident with using Rails. Did I ever mention that Ruby is also a really nice language?

Profile and Settings

Earlier this week I purely concentrated on getting the profile and settings pages complete. This allows you to update certain things like email, display name and a URL for you or your organisation. Those two will show publicly on the Event page. It was my plan to add a profile image but decided to wait for ‘ActiveStorage’ to be released so I don’t have to rely on a gem to get this done. ActiveStorage basically integrates with many online hosting solutions like AWS S3, which I’ll use. Can't wait to see it in Rails 5.2!

When the email is changed, it sends out an email, using Mailgun, to that email to confirm it. Just want to make sure it’s correct and can be verified as I plan on using magic links for log in. I’ve got a few other features planned so I’d like to keep emails verified. If it doesn’t get confirmed and you try to login, it will use the old email. I may change the way this works though.

Profile and settings don’t have many options at the moment, but I have a few in mind after beta, for example I want to add the option for optionally logging into the system with a password, send out email digests for signups (daily, weekly etc) and a few others like setting a standard ‘time zone’. Oh and not to forget the profile image.

During the week, I actually reworked this section a few times. I usually get something working and then refactor to make it that much nicer (that I can live with).

Another feature I added was account deletion. This sends out a link to the registered and verified email address with a delete link, which is active for 15 mins. After 15mins it will no longer work and you will also have to be logged in, in order to delete the account. There is similar logic to the email verification link and login.

Passwords

When you spend time logging in and out all the time to test things, you sort of realise that having a password option would actually be nice! Emails usually take a bit of time to arrive, not too long… but long enough. I don’t expect many people to always log out of their sessions, they are set with a long cookie (20 years)… however, I just don’t know.

I’ve had a quick think about this and will probably implement this during beta. At the moment, during registration, I’ll create the account and log the user in straight away, this fires off a ‘email verification’ email. Here I'd like to work on an on-boarding section (optional) which will also give the user a choice to use a password instead.

Similar to Basecamp, when you log in with the email, it will check if you prefer a password to login and present the user with the password field.

I think giving the option would work quite well.

Attendees

With the above account sections complete I got to work on the ‘My Attendees’ page. This is something I wanted to do before getting to work on ‘My Events’ to ease me into it nicely. True, I usually like diving into the deep end but thought it best to start with something a bit easier.

I’m happy that I’m following my design and I’m also glad that it is something I have done beforehand. It just makes it that much better to work on the code part and concentrate on getting that to work.

The design isn’t perfect and didn’t accommodate too much for errors and other things, so I worked hard on getting all those to work too. As I already had most of the groundwork done, it was easy to add design elements that I didn’t consider. Also, learning about “object” errors in Rails was good.

You can see here that I added the information of what went wrong and highlighted the field.

I also wanted to make sure that every attendee is unique for the current logged in user. Nothing like having multiple entires for the same attendee. This was quite easy to achieve using ‘scope’ on the Attendee model within Rails.

validates :email, uniqueness: { case_sensitive: false, scope: :user_id }

I shortened the above code somewhat to display here, but this works really well! The screenshot above shows me trying to add a user that already exists for my logged in account.

Pretty happy with how that works.

Depending on how many attendees there are, it will also show you a search box. No point in showing search when you only have 5 attendees in total. I think it’s nice to be able to hide elements when you don’t need them. Search shows up when there are 10 or more, a good number I hope.

Here is the search:

Hope to add something a bit more dynamic as you type, to update the list below. This form just posts data and displays results.

If there are no users found… I show the create modal:

Happy with the way it worked out at the end. Once I finish ‘My Events’ I’ll be coming back to this section to complete it.

Hope to also add a bit more fuzzy search. For searching I use the ‘pg_search’ gem. Works great and I’m happy with it!

With this section near complete I also worked on re-working some logic of previously coded section, thanks to me getting wiser with Rails.

Another neat trick, as I wanted to highlight the current page your are on in the navigation and also show certain options depending on the controller or ‘action’.

That was quite easy to implement and am finally happy with using something like below:

You can see that I look for the current ‘action_name’ as I’m posting values for ‘search’ in order to render the search bar when there are no results or less than 10. Really handy!

For the header bar I now use the same logic to highlight the button depending on the section you are on:

<% if controller.controller_name == "attendees" %>class="active"<% end %>

Please don’t ask me what I used before that!

current_page?(root_url)

Bleh. Didn’t work out so well… especially when posting data and others. Although... useful!

Next steps

I wrote down the Events database/model which also includes Bookings, Dates and Times. They will be their own model and will help me with figuring out multi day events with time slots. I left it out from my frontend design as I didn’t know how to tackle it. I think I know how to now. It will need to be designed at some stage.

All going well, I’ll make a start with Events tonight and continue this throughout the week, inching ever so closer to the first beta release. I don’t want to put a date on it just yet but hoping for either by the weekend or the next. Let’s see. Loads to do.

Trello board is being kept up to date and I’ll also be creating a new one for the Beta release.

There are a few tiny design changes that I’d love to do but perhaps I leave these until the end of beta.

If you like to contribute, please email me or let me know via Micro.blog. There is also the Simple Schedule holding site where you can sign up for a beta. On top, there is now a public Trello board with dev site progress. You can visit the 'pre-alpha' website to play around.

For other posts on the challenge, check out the links below:

1. Code challenge - from zero to web app in 60 days.
2. Code challenge - Prelude and Day 1 - Setting things up.
3. Code challenge - Day 2.
4. Code challenge - Day 3. Holding page.
5. Code Challenge - Day 4. A login page and a few tweaks.
6. Code Challenge - Day 5. Registration page and preliminary app navigation.
7. Code Challenge - Day 6. Getting in the groove, new events, MVP considerations.
8. Code Challenge - Day 7. 'My Events' view.
9. Code Challenge - Day 8. Burning the midnight oil, loud music and good progress.
10. Code Challenge - Day 9. Progress, changes and regrets.
11. Code Challenge - Day 10. There are no events, pricing thoughts and badges.
12. Code Challenge - Day 11. New logo, further changes to event details and a tiny tweak.
13. Code Challenge - Day 12. Final frontend stretch.
14. Code Challenge - Day 13. Choosing Rails, getting into the swing and thoughts on a multi tenancy app.
15. Code Challenge - Day 14 & 15. Blog post thoughts, passwords and learning.
16. Simple Schedule - Day 16 & 17. Register, Login and sharing progress.

I worried how best to avoid duplicate emails for 'attendees' for a logged in user but allow that same email to be used for other attendees tied to other users (but at the same time being unique to that user_id).

Lucky for me, Rails has that baked in with 'scope'. Pretty awesome!

validates :email, presence: true, length: {maximum: 255}, format: {with: VALID_EMAIL_REGEX}, uniqueness: { case_sensitive: false, scope: :user_id }