DEV Community: Chazona Baum

Freelance Web App with Rails 5.1 API and React Frontend, Part 1: Getting Set Up

Chazona Baum — Tue, 14 Nov 2017 01:56:09 +0000

It's time to get started with the Rails API and React front end. In Part 0, I gave some background about the project, what technologies would be used and why. Feel free to check it out if you haven't already.

Prerequisites

To get started with this project, you will need the following installed on your system. Let's get downloading!

Ruby - I will be using version 2.4.2 for this project. rbenv is a popular way to manage your Ruby versions, but RVM is still an option. I recommend reviewing the two options and deciding for yourself.
PostgreSQL - PostgreSQL is a robust, feature-rich database system, and it's the one I'll be using.
Postman - Postman will make it easier to build the API and test out the API calls.

Get the right version of Rails

For this project, I'll be using Rails 5.1 (currently the latest is 5.1.4), so if you don't have it, be sure to install the correct version:

gem install rails -v '~> 5.1'

Set up the API app

Let's go ahead and generate our new API app:

rails new freelance-api --database=postgresql --api

Not too many changes here, just setting the database to Postgres and using API mode. For testing, this project will stick to the default MiniTest.

Go ahead and look at the directory structure in your text editor or in your terminal with tree. If you've worked with Rails for regular web applications, you'll notice this app is a lot slimmer.

The first changes to make are with the Gemfile and the CORS initializer:

Uncomment the gem rack-cors line in the Gemfile and run bundle install in your terminal.

And in the API directory, open config > initializers > cors.rb, uncomment and modify it to read:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

This will allow the API to play nicely with the front end app. The origins can be adjusted once you know what domain you'll use for the front end app and are ready to deploy.

Version control and documentation

While this API needs a lot of work before it's done, it's a good idea to get in the habit of updating the documentation and keeping track of changes as we go.

You can start by creating a repository in GitHub or another repository hosting service that uses git. It should be fairly straightforward:

Before adding the files to the repo, it's a good idea to start on some of the basic files you may not feel like working on as the project wraps up: the README, LICENSE, and CONTRIBUTING files.

Your README should already exist, but go ahead and modify it to make sense with what you have so far. For example, right now mine looks like:

# Freelance API

Make your freelancing more efficient by managing leads, proposals, project documents, clients and more.

*This is a work in progress.*

## Getting Started

### Prerequisites

#### Ruby ~> 2.4

Download and manage via [rbenv](https://github.com/rbenv/rbenv) or [RVM](https://rvm.io/)

#### Rails ~> 5.1

    gem install rails -v '~> 5.1'

#### PostgreSQL ~> 9.6

Follow the [instructions for downloading PostgreSQL](https://www.postgresql.org/download/) based on your operating system, and be sure to [create a database user with privileges](https://wiki.postgresql.org/wiki/First_steps).

### Installing

Clone the repository:

    git clone https://github.com/chznbaum/freelance-api.git
    cd ./freelance-api

Install the gems:

    bundle install

And set up the database:

    rails db:create
    rails db:migrate

Start the development server:

    rails s

You can test this by making a GET request to `localhost:3000` using Postman or an alternative.

## Tests

### End to End Tests

TBA

### Coding Style Tests

TBA

## Deployment

TBA

## Built With

* [Rails](http://rubyonrails.org/) - Web Framework
* [rbenv](https://github.com/rbenv/rbenv) - Environment Managemet
* [Bundler](http://bundler.io/) - Dependency Management
* [Heroku](https://www.heroku.com/) - Deployment Platform
* [Travis CI](https://travis-ci.org/) - Continuous Integration

## Contributing

Please read [CONTRIBUTING.md](CONTRIBUTING.md) for details on the code of conduct, and the process for submitting pull requests.

## Versioning

TBA

## Authors

* **Chazona Baum** - Initial work

## License

This project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for more details.

## Acknowledgements

There's still a long way to go, but already a surprising amount can be included!

Go ahead and create a CONTRIBUTING.md file and a LICENSE.md file in your project root. My CONTRIBUTING file just lists TBA, and I am using the MIT license for my project.

Now that these documents are set up, the files can all be added to the repository you created.

git add .
git commit -m "initial commit"
git remote add origin https://github.com/<YOUR GITHUB USERNAME>/freelance-api.git
git push -u origin master

Wrapping up

You're almost done with the basic setup! To create and update the database, go ahead and run:

rails db:create
rails db:migrate

It seems like we've done a lot without much to show for it, but we've set up the environment we'll need to start giving the API functionality.

At this point, you can test the API out by opening Postman and starting your Rails server in the terminal:

rails s

Once the terminal indicates the server is running, in the Postman request bar, send a GET request to localhost:3000. You should see the following:

Look deeper into the HTML you received, and you'll see it's Rails' "Yay, you're on Rails!" success page.

With that accomplished, the next step is to actually plan out what the API should do in a little more detail and actually start creating the data models.

Freelance Web App with Rails 5.1 API and React Frontend, Part 0: Why?

Chazona Baum — Tue, 14 Nov 2017 01:50:53 +0000

In my rush to try to earn something from my code learning so far, I've had to shelve some of my plans to dive deeper into Ruby on Rails and to learn front end frameworks like Angular and React. When marketing freelance work to non-coders, the most common request seems to be to make something fast, pretty and cheap, which means focusing on static or WordPress sites.

But I'm finding that trying to reach out to potential clients the traditional way is extremely inefficient, especially when conversion rates as a newbie freelancer are basically nonexistant. And solutions for non-technical folks to manage their clients and improve their sales are expensive when it might take several months to actually earn anything.

So it seems to make sense to go ahead and put together an app that will allow me to keep track of and reach out to leads, as well as managing proposals and project documents, and provide clients with access to materials relevant to them. Once the basics are there, I'll look at integrating an invoicing API like FreshBooks to get more out of the app.

And since it's been a while since I've blogged about what I'm learning, this seemed like a great opportunity.

Over the next few weeks I'll be building a freelance dashboard app, using Rails 5.1 for the API backend, and React.js on the front end.

To follow along, it's a good idea to be comfortable working with your terminal and console, have a basic understanding of how a simple Rails app works, and to have a working knowledge of JavaScript. But I'll try to keep things simple just in case.

You can either wait for the next post to start building, or feel free to dig a bit deeper into why I went with this stack below:

Why Rails?

I'm setting aside for a moment the fact that I love working with Ruby, since it's not always going to be the best tool for the job.

For one, Rails is pretty fast and easy to set up compared to other options. Given that I intend to use this toward trying to make some income soon, being able to get something up quickly and iterate improvements is a huge advantage.

If I wanted to build the back end and front end in the same application, Rails makes that easy, too. Starting with 5.1, Rails includes Webpack and makes it easy to create apps that use front end frameworks and libraries like Angular, React, Vue, or Ember rather than jQuery. I've played around with that a bit, but I think I'd still rather separate out these two key parts into an API and a front end app.

Rails is also well-known for being a great framework for building RESTful APIs. Rails 5 even provides an API mode that makes getting a JSON API up and running even smoother.

And I have some basic experience building applications with Rails. While I want to learn new things, having some familiarity with the back end will help get this built quicker, especially since I'm picking a front end framework I have no experience with.

If I didn't go with Rails, I would have considered:

Phoenix - Phoenix is built on Elixir, and the framework was recently brought to my attention as a more performant alternative to Rails. I definitely want to play around with the pair some, but possibly on a different project. Plus, the performance issues with Rails are generally more of a problem when it's a lot bigger than I expect this to get.
Node.js - When working with JSON and a JavaScript front end framework, a JavaScript back end would seem like a convenient option. I've only played around with Node in small pieces, like building Twitter bots. I want to explore Node more in the future, but Rails' benefits edge out for this project.
Sinatra - Sinatra is another Ruby-based option, one that's supposed to be great for tinier applications where Rails might just get in the way. I'm expecting this app to be a little larger than one I might use Sinatra for, though I'm eager to try it out on a project one of these days.

Why React?

React has gotten a lot of attention lately between concerns about licensing issues (which it seems were ultimately much ado about nothing) and its parent company Facebook constantly ending up in the headlines.

It seems most companies that have gone with JavaScript front end frameworks have landed with either Angular or React. From a pragmatic perspective, there are more jobs out there for either one than for, say Vue.

React is also a more mature framework than Vue, while having fewer breaking changes than Angular.

And React also has the benefit of React Native. If I wanted to implement a native mobile app for this web application, which I eventually do, React Native makes it much easier.

If I didn't go with React, I would have considered:

Vue.js - Vue, like Ruby, is a joy to use. I've tinkered with it before to build a simple PokÃ©mon-based monster battle game. If I wasn't going with React, I would have definitely gone with Vue to have the most flexibility with my front end.
Angular - The other pragmatic approach, Angular is used by a lot of companies I know. It's also frequently paired with Rails.

Other Considerations

I considered breaking this project up into microservices to make individual features easier to develop and maintain, and initially started it that way. However, it's been brought to my attention that microservices should be left to situations where teams of people will be working on different services, so this project will take a monolithic approach.

And since I'll be attending RubyConf this week, posts about this project may be interrupted by posts about the conference.

This should be a fun project to work on, and I look forward to showing you along!

Roughing It Dev Style: Coding Without a Computer

Chazona Baum — Wed, 19 Apr 2017 20:15:51 +0000

A terrible, horrible, no good, very bad thing happened to me this month: the Surface Pro that was my exclusive personal and work computer died. Even though I found an inexpensive replacement to order, I couldn't imagine not coding for about a week. I was totally freaking out.

After a few unsatisfying days of merely reading about web development topics, I set to work on figuring out how I could get some real work done, armed only with my iPhone.

Trial and Error

Not wanting to hunt down a new solution if it was unnecessary, I first turned to tools I've used before:

Codepen

Codepen wasn't terrible in a pinch. However, the layout and on-screen keyboard really wasn't optimized for coding on a phone. Making minor changes took a lot of time, and it was easy to end up with really buggy code.

Cloud9 IDE

Cloud9 had the same problems but with an already more cluttered interface. It explicitly doesn't support mobile browsers and it has been made clear multiple times that making Cloud9 mobile-friendly or developing a native mobile app for it is not anywhere on the roadmap.

CodeAnywhere

When exploring the Cloud9 issue, I saw mention of an alternative cross-platform cloud IDE called CodeAnywhere. However, the iOS app appeared to have not been updated since 2014 and after four unsuccessful attempts to so much as create an account and login, I figured there had to be something better.

What Finally Worked

After some frustrating experiences, I came across tools and techniques that worked beyond my expectations, allowing me to code productively with just a phone and that can allow you to do it, too.

Editor: Buffer Editor

Buffer Editor was a hidden gem in the App Store. It didn't have a presence from advertising or word of mouth or even enough reviews to warrant a rating. It would be easy to underestimate Buffer.

When actually downloaded, though, it's clear that Buffer Editor is a real, powerful editor truly optimized for a mobile experience. Features that won me over included:

An extended keyboard that makes typing quick (for one-handed) and intentional.
A well-designed built in terminal.
Full-screen editing, a necessity on such a small screen.
Syntax highlighting and autocomplete for 40+ languages and technologies.
The ability to connect via SSH, FTP, SFTP, GitHub, Dropbox and iCloud.
Sending files by email.

It also included useful features that I didn't utilize such as Vim support and support for bluetooth keyboards.

While it isn't free, the 4.99 USD price I got it for was well worth it, especially compared to the popular Coda at almost 25 USD.

Server: Digital Ocean

Being confined to a phone gave me the push I needed to start building more websites and applications directly in a VPS solution like Digital Ocean rather than starting out solely on a local machine. Using a Virtual Private Server (Digital Ocean calls them droplets) allows setting up a development environment and managing files/servers without needing a local environment to work with, since it's on another computer in the cloud. Another benefit of VPS is that from the start, a project isn't tied down to one local machine, even if it hasn't been checked in to version control yet.

Digital Ocean has proven to be easy to use (and inexpensive), and there is a wealth of documentation and guides for folks new to running servers.

Accessing the droplet remotely was easy in Buffer Editor, simply involving adding a new SSH connection and filling out the relevant settings with information from the droplet.

Browser Access: Local Server Binding

The wonderful and problematic thing about web development is, of course, the primary thing you need is a browser. Using a VPS to develop, you have access to a terminal console, but not a Graphical User Interface or a traditional web browser.

When developing a web app, you often need to be able to start a local server and access localhost in the web browser, since that's where the development server displays the app. Unfortunately localhost means this computer, and so it's inaccessible outside of the VPS hosting the app files.

The workaround here involved learning more about servers and requests:

When starting a server, it sends what is called a bind request to indicate that it is ready to receive requests associated with an IP address. Local servers typically bind to 127.0.0.1 because that IP address is used to loop back to the requesting computer; each computer can only request 127.0.0.1 from itself, which is usually convenient for developing.

That's clearly not an option. You need to have the server bind request indicate its publicly accessible IP address instead so that it's accessible from a browser outside of that computer. This IP address is easily obtained from Digital Ocean, and the workaround involved adding a --binding flag like this, for starting a Rails server:

rails s --binding=XX.XX.XX.XX

Now, instead of typing localhost:3000 into the browser's address bar to view the app, you would type the publicly accessible IP address, like XX.XX.XX.XX:3000. As long as the local server is running with the binding flag, the app will be accessible remotely from the server's IP address.

Buffer Editor is especially convenient by keeping the server running after you back out of the terminal (so you can open it again and continue to develop). This can be confusing at first, but to stop the server, lock and unlock your phone.

Get Back to Coding Productivity

From here, you can utilize git like usual, get to work and debug your code wherever you are and regardless of WiFi/Ethernet availability. In fact, the day before my new computer arrived, I was able to make 6 commits and push them to GitHub, all from my iPhone.

While my day to day coding will be on a traditional desktop or laptop when it's available (since two hands are faster than one), I continue to utilize these tools to work on my projects when I can't bring my laptop somewhere or when mobile internet is all I'll have access to, such as riding in a car.

I'm actually thankful for the experience of losing access to the computer, because it forced me to find a solution that now allows me to code virtually anywhere.

Nevertheless, Chazona Baum Coded

Chazona Baum — Wed, 08 Mar 2017 12:44:08 +0000

I began coding because...

English was not my first language. I think partly because of that I've always been fascinated by languages as a means of expression and creativity, both as way to include others as well as to withhold information from those who didn't understand. (Side note: writing your teenage diary in Tolkien runes is a great way to ensure no one you know can ever read it.) Every spare moment growing up was spent on reading or creative writing. By college I had learned English, Latin, Spanish and Japanese, and toyed around with basic HTML and CSS. To me it was the same thing, just a different audience, vocabulary and different grammatical structure.

Accepted coding culture at my college at the time was pretty different, even though it was only a decade ago. IT and CS were pretty firmly divided, web developers were looked down on by programmers, and no one I knew studying these topics was a woman or nonbinary person; my own presentation was pretty masculine at the time. Even though I was fascinated by the web and was objectively good at math, I let other people's comments get into my head. I never viewed this as a possible "real job" for me, so when the time came to get a real job, I stopped coding altogether.

Along the way I've been gradually drawn back into code, inquiring about ways to transition into IT departments, but being pushed out of the workforce when I had my kids. When I discovered Free Code Camp's online curriculum last summer, it was the catalyst that got me back to learning code and building things. It kind of feels like coming home.

I'm currently hacking on...

I'm currently working with Vue.js to make reactive web apps and games.

I'm excited about...

The rapidly changing web development landscape. What we can do with the web has come so far in the last decade! I'm excited to see what new frameworks and technologies emerge and how the web changes as everything gets connected to it, even if we do see some wacky IoT shenanigans along the way.

My advice for other women who code is...

Find online communities of women in tech, and if there are Women Who Code meetups or something similar near you, check them out in addition to your regular learning/networking efforts. As a local code meetup organizer, I've definitely noticed how often I am the only woman in the room.ðŸ˜… Having somewhere where you know that won't be the case can help when you feel intimidated or like you don't belong.

Also, if you happen to be in a position where you can do this: speak up about inclusion of parents even if you don't have kids or plan to yourself. If you haven't had kids, you really don't know how much of our systems in society (at least in the US) are designed to keep women at home if they have young children. Ensuring your workplace has good family leave policies and that your meetups are either family-friendly or show consideration for those who need childcare are a great way to help. Nursing tends to get all the attention, but the barriers don't end there.