Scaling Rails

I’ve been practising scales since I was 5 and I’ve used a million and one different ways to track my progress. Some have been better than others but none have really stuck. I wanted to try and find a web-based solution to this problem held by musicians of all ages and abilities around the world!

Even just the regular Rails app creation gives you thing you don’t necessarily need. It’s quite cathartic to go through getting rid of them once you’ve realised they’re not magical files of unknown — they’re just empty files taking up real estate in your sidebar.

I have four models: Musician (user), Scale, Practise and Note.

As you can see, if I had scaffolded these, I’d have a LOT of extra stuff I didn’t want.

I faced quite a few challenges of varying complexity during this project but on Day 1 I was faced with three big ones that were core to the success of the idea:

This was extremely important and after a few cups of tea I came up with some thoughts:

Great. I was ready. But this was going to need a bevy of custom methods (dare I say it… algorithms?) to get this to actually be useful. Here are a few of my favourites that I came up with and are now implemented in the app:

The addition of the second octave is not implemented in the front end at the moment but the code is there ready for if/when it makes sense to add this.

My personal favourite method in the app is this one:

or maybe this one:

I like naming methods in ways that make me smile.

This was another big one. Of course, there are a few ‘standard’ ways to represent scales visually but the one I know best (the 5 line stave) is not readable by all. It is another language, a graphical one, which needs to be learnt.

How do you see music notation?

Do — Re — Mi — Fa — So— La — Ti

Those are the ‘major diatonic’ solfege notes. There’s a few more to cover all your bases (there are 12 notes altogether).

So each Note in my database has:

Clearly, this is primarily a question of User Experience and not the focus of this project but it was a very interesting problem to have to solve and one which I was only able to answer with personal opinion, not user feedback (yet). There are numerous improvements that could be made but this is more a question of music education and UX!

Initially, I was thinking to have a new instance of a Practise created every time a Musician (user) practised a Scale, regardless of whether they had practised that scale before or not. It became clear that this would be somewhat inefficient and so I changed my approach to have a new Practise created only the first time a user practises that specific scale.

For subsequent practices of that scale, the Practise instance for that user and scale will have its experience attribute increased by 1. With this, we can easily query how many times a user has practised that scale.

To satisfy the Type As, I wanted to add a rankings list. Savage but also kind of fun. It sounded easy enough but it took me a little time and revision to get my AR queries correct. I wanted a user to be able to order rankings by name (alphabetically), total practices logged and by who most recently practised.

The queries I used for this were:

I had a good time working with OmniAuth and the Facebook API. It can be quite finicky but really once you’ve done it once it’s fairly straightforward. I intended to add Google OAuth but the process was slightly different and I will add this at a later date. I was more upset that Soundcloud was not possible (see above!) as it’s a very relevant platform to have related to my app.

I didn’t want 3rd party authentication to be the only option. Up until recently I never used 3rd party authentication (I use it all the time now, although I’m picky about what permissions I give) and I know that many people will still not use it. I also wanted the app to be accessible to all ages and there’s a lot of people, especially younger and older generations who do not have social media accounts.

In my last project, I used a variety of different forms of validation. Partly to practice them and partly because I didn’t really know what I was doing. This time I tried to keep my validations much tidier, more effective and less vulnerable. I relied heavily on AR validations and the handy full error messages method to display my custom error messages without adding lots of extra lines of code as I did in the last project.

I did add some custom validations eg. into the process of creating new Practises. I believe this could be streamlined further but I chose to go this route for now.

If a user does try and access a private scale directly via the url, they are redirected back to the index where they see a flash error saying ‘Hey, that’s private’!

All in all, this has been an 8-day project (today is day 9, paperwork day!). Compared to my last portfolio piece, I spent much more time actually coding this time. Whilst making my Sinatra web app, GROTTO, I seemed to hit a roadblock every hour or so. I still hit knowledge gaps and gaping questions whilst making Scale This, but I am now much more fluent in problem-solving. My ability to find the relevant documentation and locate the info I need from it, is markedly improved.

I can’t even recognise myself in CSS land compared to the last project. Last time I was legitimately scared of CSS, I didn’t trust it let alone understand it. Between then and now I’ve been practising CSS Diner and Flexbox Froggy which have been invaluable in improving my fluency and understanding of CSS.

My improvements gave me the opportunity to be more creative and address questions of user experience, best practises and experiment, without feeling I was just clawing my way to producing anything I could.

For this specific app, there are certainly many improvements to make and fortunately, I will be able to address some of these soon when we revisit this project to officially add JavaScript.

It still amazes me how much I am learning, when I compare myself just to last week I have improved my understanding of Rails principles drastically. Comparing myself to the last project, I am more fluent and thinking more efficiently. Comparing myself to the start of this year, well, in January I was patting myself on the back for getting 2+2 to equal “Mickey Mouse”.

The progress is so exciting and the more I learn and do, the more creative freedom I have to make whatever my brain decides it wants to!

Related posts:

Customer acquisition costs for residential solar are expensive and rising. Large residential solar companies like Tesla and Sunrun paid close to .70/w to sign up customers in 2017. For local…

BUY K2 LIQUID SPRAY ONLINE. “K2 LIQUID SPRAY” is published by Larrymedium.

Tenho lido muitos artigos e assistido alguns videos sobre o medo de dirigir e a maioria fala sobre o medo de dirigir, fala algumas dicas de como perder o medo, e alguns arriscam em dizer vai e se…