FreeCodeCamp Bonfire Challenge Solutions

In order to help land that coding job I’ve been dreaming of, and since I’m currently unemployed, I thought I’d use spare time where I’m not coding on something cool, or applying for dev jobs to work on my craft.

Beginner Algorithm Scripting

Here are gists from the Bonfire Challenges:

Free Code Camp :: Bonfires

1. Bonfire: Meet Bonfire

2. Bonfire: Reverse a String

3. Bonfire: Factorialize a Number

4. Bonfire: Check for Palindromes

5. Bonfire: Find the Longest Word in a String

6. Bonfire: Title Case a Sentence

7. Bonfire: Return Largest Numbers in Arrays

8. Bonfire: Confirm the Ending

9. Bonfire: Repeat a string repeat a string

10. Bonfire: Truncate a string

11. Bonfire: Chunky Monkey

12. Bonfire: Slasher Flick

13. Bonfire: Mutations

14. Bonfire: Falsy Bouncer

15. Bonfire: Seek and Destroy

16. Bonfire: Where do I belong

Intermediate Algorithm Scripting

1. Bonfire: Sum All Numbers in a Range

2. Bonfire: Diff Two Arrays

3. Bonfire: Roman Numeral Converter

4. Bonfire: Where art thou

5. Bonfire: Search and Replace

6. Bonfire: Pig Latin

7. Bonfire: DNA Pairing

8. Bonfire: Missing letters

9. Bonfire: Boo Who

10. Bonfire: Sorted Union

11. Bonfire: Convert HTML Entities

12. Bonfire: SpinalTap Case

13. Bonfire: Sum All Odd Fibonacci Numbers

14. Bonfire: Sum All Primes

How to keep tables uncluttered by using profiles for each user type in Ruby on Rails

This is a continuation of my STI / Single Table Inheritance article: “How to use multiple User types with the same model in Rails aka STI or Single Table Inheritance

To keep your tables less cluttered and better normalized, I do recommend creating profile tables for each user type. What I did is this for my student’s example:

I have a student_profiles table with things like skype_username, birthdate, etc. To set this up You’ll want to do your migration.

Then we edit the Student model like so:

Now you can keep your user table and class more minimal and separate everything out into their own model. I also recommend putting all of these folders in models/users folder. To do that though you will need to edit config/application.rb and add the following line:

Thinking ahead you may want to group more models together, especially if you have a large number of models and tables, to do that you’ll just need to add a new line the same thing as above, just change the last part of the path to match the path to the folder with your models, and you should be good to go!


How to Use Multiple User Types (STI or Single Table Inheritance) with the Same Model in Ruby on Rails

Lately, I’ve been building a complex CRM for music teachers to manage students, invoicing, etc… It’s gotten a bit complicated, and I myself have learned a lot from this side project. One important thing I’ve learned is STI, or Single Table Inheritance. Basically, this lets you easily have sub models with their own intricacies, relationships, etc so you don’t clog up the main user class, but they all use the same table, and are easier to modify on their own.

I have admin.rb, student.rb, parent.rb, and teacher.rb files with classes to go with them…

I’ve built this all using Sorcery for the backend, but you can use devise, or whatever else floats your boat.

The first step is creating a “type” attribute on the users table. This is required by STI to know which type of user we’re dealing with. I’m going to assume you already have your user authentication system all setup.

Next you’ll want to create a subclass. For this example we’re just going to use Student.

When we create this, we also need to make sure that when the “type” attribute is set it’s always titleized. You’ll get errors and have issues if for instance the user.type was set to “student” and not “Student”. Case matters in this case.




Now, just make sure each user has a type, or perhaps have some sort of fallback, or default type as well. Then whenever you query Student.all or Teacher.all you’ll be pulling data out of the users table, but only get back Student and Teachers.

Next you may want to checkout my article on: How to keep tables uncluttered by using profiles for each user type.

More good articles on Single Table Inheritance / STI:



How to Use Local Environment as Default in Laravel Artisan CLI

I have to say, I absolutely LOVE Laravel – everything about it.

One of my favorite features is the ability to separate your app into local/production versions.

I use a lot of packages for development, that I just don’t need on my production version of the app. How do I resolve this? By using two different environments w/ different App.php configs. Read my tutorial on this here.

You might find that this only works for your app when running it in the browser. Here’s how to make sure that the local environment is ALSO set for command-line e.g. Artisan and Tinker.

One option of course is to do:

But who wants to write –env=local after EVERY artisan command? I am a pragmatist and believe in using technology to my advantage. This is great when needing to switch back and forth for a minute, but when doing it all the time you need an alternative.

next add “PatrickPC” to bootstrap/start.php

Now artisan should run w/ local environment as default when on this machine, let’s test it:

Got questions? Leave a comment!

How to setup Local and Production environments on Laravel

One great feature of Laravel is how easy it is to setup local and dev environments.

Why would you want separate environments?

  • Require separate packages for dev, and production.
  • Less bloat / potential for errors on production.
  • Turn off debug on production.
  • Special config options for local vs production.
  • etc…

Next we simply create a new folder at : App/config/local/

If you create a App.php file -this file will override the global App.php in the parent directory while working in the local environment. So you can add different providers/facades to this local version and not mess up the production version.