At the FlatironSchool, we are currently learning about JavaScript and jQuery. Since we aren’t yet building our own apps from scratch, we’re usually given a template.

I took a closer look at one of the templates and will explain the following two lines, which are typically found at the bottom of your index page:

1
2

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/jquery-1.8.0.min.js"><\/script>')</script>

Line 1 in our code requires jQery from Googles CDN.

Line 2 basically says “If you can’t reach Google load the local version”.

This got me thinking. Why do we even need a CDN if we have a local version any ways?

Well, as it turns out, there are a number of reasons why this can be important…

What is a content delivery network?

A Content Delivery Network refers to a large network of servers deployed across multiple networks in several data centers, often geographically distributed.

Content Delivery Networks are all over the web. You use them every day when downloading files from Dropbox, or watching Orange Is the New Black on Netflix.

But apart from big consumer applications, they also play an important role in our day-to-day applications.

Three reasons why you should use a CDN for your code:

1. Low latency

When using a professional content delivery provider, there is a much higher chance of one of their servers being geographically close to your user. This may not be the case when you host your website on your own server.

As a result, content will be loaded faster.

2. Higher chance of having a cache-match

Static files like the jQuery library are cachable. Google will try and store them for up to one year in your computer. The more companies use their CDN to deliver jQuery, the higher the chances are that your user already has jQuery in their cache and does not require to download it at all.

3. Increased parallelism

Browsers typically limit the number of connections that can be made to any given site. Using a CDN will allow your users to download more of your local content in parallel. This in turn will increase the speed at which your app is up and running.

Conclusion

You may have noticed that all the stated reasons help increasing the speed of your app. Well, speed these days is important and every milisecond counts.

People aren’t patient so you should try and not only keep your code as clean and fast as possible, but also choose best practices over where to host your files and libraries.

Introduction:

If you want to get your feet wet in actually creating an application that lives on the web, this is the guide you’re looking for. It will take you from start to finish and only assumes you already have an idea. The following tools will be covered:

• Sinatra
• Heroku
• Git & Github team workflow
• Bootstrap

If at any point you don’t understand what’s going on, I’m sorry, but I can’t help you. After all, this is only a loose guide. Our example application will be a simple search app that scrapes reddit.

Before we start:

When thinking about what to do next, or how to approach a problem/feature, keep in mind the following principles:

• single responsibility
• make it work, make it right, make it fast
• form follows function

We are building a single responsibility app. Sure you can think about features and fancy stuff to add to it, but right now our goal is to deploy something.

Basic outline of the process:

1. Think about what your app will do
2. Write down your conclusions
3. Set up the initial file structure
4. Start working
5. Finishing touches and troubleshooting
6. Deploy to Heroku

Let’s get into it!

1. Think about what your app will do

Your guiding principles here should be the single responsibility principle and working from the outside in. This means you should first write down a general list of things that your app has to do. In our case:

1
2
3
4

search reddit/ELI5
choose best match
choose best answer
display best three answers

As you can see, this is quite simple. During this process, questions like “Should I use an API or just crawl?” have to be addressed and answered. Again, keep in mind that you want to make it work first and foremost. Don’t obsess with API’s or gems that confuse you if you already have a tool you know how to use.

2. Write down your conclusions:

Now put those answers to paper and be a little more precise. Start looking at some of the details but don’t get caught up in them just yet.

1
2
3
4
5

get user input
search http://www.reddit.com/r/explainlikeimfive/search?q=  user.input  &restrict_sr=on&sort=relevance&t=all
open first search result with title explained
get the first answer with the highest upvotes
display that on our awesome web app

At this point you should already have a more concise idea of how you’re going to do things and you can already start thinking about division of labor.

Who should build the backend? Who should do the crawling? Who should set up the repo? Who should style and create your views? Who writes tests?

After those questions are answered, it’s finally time to get your hands dirty!

3. Set up the initial file structure:

At this point you should know enough about what your app has to do to be able to quickly set up your file structure and require your dependencies.

Don’t forget to git init a new repo and set up a remote so your teammates can fork it.

Keep in mind that when we want to deploy to Heroku later, we have to use Bundler and a Gemfile. A typical structure could look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

root/
├── Gemfile
├── Gemfile.lock
├── README.md
├── Rakefile
├── app
│ ├── controllers
│ │ └── app_controller.rb
│ └── views
│   └── layout.erb
│   └── index.erb
├── config
│ └── environment.rb
├── config.ru
├── public
│ └── stylesheets
└── spec
├── controllers
├── features
└── spec_helper.rb

Your Gemfile could look like this:

1
2
3
4
5
6
7
8
9
10
11

source 'http://rubygems.org'

gem 'sinatra'
gem 'pry'
gem 'shotgun'
gem 'rake'
gem 'rspec'
gem 'thin'
gem 'nokogiri'
gem 'require_all'
gem 'rack-test'

Your environment.rb file could look like this:

1
2
3
4
5
6

require 'bundler/setup'
Bundler.require
require 'open-uri'

Dir[File.join(File.dirname(__FILE__), "../app/controllers", "*.rb")].each {|f| require f}
Dir[File.join(File.dirname(__FILE__), "../app/models", "*.rb")].each {|f| require f}

Your config.ru has to look something like this. Later we’ll get to why it has to.

1
2
3

require './config/environment.rb'
use Rack::Static, :urls => ['/css', '/js'], :root => 'public'
run AppController

Download Bootstrap and put it in it’s rightful place

4. Start working

At this point you should have pushed the initial setup of files and dependencies to github so that your teammates can fork your repo and get started on their own respective branches/features.

A few tips for using git correctly:

• Everyone in the team should work on feature branches
• Once a feature branch is developed:
  • rebase master into it
  • merge the branch into master (switch to branch master before merging)
  • push to your remote repository
  • submit a pull request to upstream master from github
• You should commit often and leave precise comments

Talk to each other every now and then to make sure the different parts of your app will also be able to talk to each other later.

How to use Bootstrap in the real world

CSS has many many different selectors and ways to style your websites, ok! Just stick with a neat little framework called google&bootstrap. If – like me – you don’t know ____ about bootstrap and css and all that stuff, all you need to do is have these two tabs open:

Bootstrap Documentation&Google

The bootstrap documentation will give a few good ideas on elements and their styles, but can be overwhelming. Lucky for us, bootstrap is a popular framework and you can find a lot of your answers on the web.

Just google what you want to do, then paste whatever bootstrap html you can find, and see what it looks like in the browser. Keep what you like and get rid of what you don’t like. Rinse and repeat, it’s really that simple.

5. Finishing touches and troubleshooting

After everyone has submitted their pull requests and you’ve merged everything into master, it is time to put the finishing touches on your app. This means fixing little bugs or formatting issues and making sure all your files are required properly.

This should really not take too long since hopefully, you and your teammates were talking to each other, and stuck to the agreed formats.

Keep in mind that rackup will only work correctly with your styles if you tell it where to look for your css directory. You can do that in the config.ru like above.

Alternatively you could use shotgun which will work just fine, but avoiding this will cause problems with Heroku later.

6. Deploy to Heroku

If you’ve set up your Gemfile and your config.ru correctly, deploying to Heroku should be a breeze.

1. Download the Heroku Toolbelt
2. Sign up for Heroku
3. From your master branch run
   • git remote add heroku <address>
   • git push heroku master
4. Watch it compile and copy the resulting link into the browser to see your web app live!

Yes, it is really that simple. If you want to change the name of your Heroku app because blazing-mist-4652 isn’t up your alley, do it from the command line using heroku apps:rename newname.

If you run into problems with your stylesheets, it is most likely for the same reasons rackup didn’t work. Heroku can’t find them. Take a look at the config.ru to change that.

Enjoy shipping your app

www.get-an-answer.com

Nice job on that app. From here you can feel free to add more functionality beyond the bare basics to make your app much sophisticated.

Part 1

At the Flatiron School, it’s all about trying to fit an elephant inside a fridge. Your brain being the fridge and Ruby plus everything else being the Elephant. Needless to say, it can feel a little bit crammed in there.

But wait, this is a good thing! It means you’re expanding your comfort zone and actually learning something. Here’s why:

Novelty – a two-edged sword

Novelty can both be good and bad. You’re being awarded pleasure for learning, while feeling the discomfort of not knowing what to do. It’s confusing.

Here’s the scary part:

Everybody loves novelty. If your job doesn’t challenge you in new ways, it will only keep on dragging you down until you eventually quit. This is a no-brainer. But that’s just part of the story…

Discomfort and Emotions

Wouldn’t it be nice if the discomfort would actually feel good too? Well, chinese scientists have discovered that due to the nature of the design of our brain, this is not possible. Sorry.

But wait, how about a workaround? Yes, now we’re talking. But before we go into that, let’s inspect discomfort in a little bit more detail:

What I mean by discomfort, are generally negative emotions. Feeling lost, hopeless, angry, annoyed or frustrated are all pieces of the pie. So why do we feel them? Because they are necessary.

Think about it, when you were a little kid and put your hand on that stove for the first time, you needn’t make that mistake twice. You see, linking experiences to negative emotions will make them stick better.

And that’s really all there is to it. Read it again. It sounds simple, because it is!

But what about programming?

Persisting and struggling with concepts you don’t understand will assist you in learning them. Simply stated, it may be more painful, but you will gain a deeper understanding.

To make a point, when I was working through the collections practice lab, it took me a full four hours to work through one method! But I discovered and learned a lot! Taking on pigeon organizer afterwards felt as easy as binge-watching a season of Game of Thrones.

So here is what you should do:

Use this piece of information as a framework to help putting things into perspective. The next time when you feel really frustrated, don’t take the easy way and look at someone elses code.

Struggle with your own code first, feel frustrated, browse the Array Ruby documentation for the hundredths time. Stay with it. Remember that all this frustration will help you in the long run.

No pain, no gain.