Being a full-stack developer means we have a lot of things to focus on in order to build a successful application. With so much evolution happening on the front-end, a lot of developers have drifted away from the back-end and dev-ops… that’s where MongoDB Atlas and Stitch comes in. MongoDB Atlas is a Database as a Service (DBaaS) that backs Stitch, their Backend as a Service (BaaS). Today I’m going to show how we can interact with MongoDB from our front-end logic without having to spin up an API! The React application we’ll be using can be found here.
Mistakes happen. It’s a fact of life. In fact, mistakes are often a precursor to growth... as long as you learn from them! Occasionally at work, our support team receives feedback from customers trying to sign up for one of our paid tiers, explaining that the transaction failed. Not only does that stink for our customers, but it was a pain point for us. We integrate with a third party for payments, that at times responds to a request with what’s essentially an unknown error. In most cases we’re able to surface a helpful error to the user based on logic that parses the response. But up until a few months ago, we had zero visibility into the unknown errors. We had no way to help our customers, and no way to learn from the problem! After looking at a few more third party solutions, we decided to leverage functionality our current stack already provided.
Some updates to our Angular-based UI and our Nginx web server was all it took. And while we were at it, we went ahead and used the approach to log uncaught exceptions too. In the UI, we built a simple service for posting errors to Nginx. We just have to get the username from the session, along with the error response and data posted, (of course, for compliance reasons, we never deal with credit card information, our third party services takes care of that) and post it back to our logs. No need to catch a rejected promise in the service either, because for our case, we don’t have a need for handling failed log attempts.
Now that I'm working on a larger code base, debugging has become increasingly important and complex. With that said, I decided to dig into some documentation, and explore how I can use tools that already exist more productively. Below are some of the tricks I've come up with so far.
Chrome Dev Tools
January 6th, 2014 seems like yesterday. Looking back though, I'm utterly amazed at what I've been able to accomplish in the past 12.5 weeks. The 'Front End' course at the Nashville Software School does indeed cover the 'front end'. However, within a few short weeks we were covering much more than basic JavaScipt and jQuery. From week 5 on, we used JavsScript on the full stack via Node.js. With that said, I wanted to take a short breather before the final three months of Ruby and Rails to reflect on everything I've learned while completing the first half of my six month program.
To our surprise, day one started off with us opening up Vim. Our instructor, who previously taught at both General Assembly and the Flat Iron School, drilled home that 'real programmers' don't point and click. From there, we rounded out the first month with lots of linux, HTML and Jade, CSS and Less, JavaScipt and jQuery, Ajax, Git, Pair Programming, some logic puzzles, OOP, TDD with QUnit, JShint, Grunt, and of course Tmux.
Somewhere around the 5th week, we had our first 'exam', which split our class into the Alpha and Beta groups. The Beta group ended up perfecting their front end skills, while the Alpha group dove into Node.js. Along with Node, we covered Express.js, MongoDB, TDD and BDD with Mocha and Chi, and deployed our first apps to an Amazon Web Services (AWS) Elastic Cloud Instance (EC2).
Thoroughly exhausted, week nine started us on our back to back, to back, to back, to back, Hackathon weekends. In other words, we had group projects, and our final two capstones to work on each weekend from here on out. And by group projects and capstones, I mean I was programming at least 15 hours a day seven days a week. In regards to classroom lecture, we covered Socket.IO, Travis CI, Coveralls (ensuring code coverage), Gemnasium, and more advanced Git topics.
So, that's roughly three months down, and three months to go. With Node.js being relatively new, I hope to be able to write additional posts on some of the more specific topics I was able integrate into my projects. Specifically, as time allows I plan to thoroughly discuss Passport OAuth and Stripe in Node.js. Especially, since Passport and adequate TDD proved to be a bit of an initial pain point for me on my capstones. In the meantime, feel free to checkout my final project on GitHub. https://github.com/AimeeKnight/Civic311
I'm pleased to report that my decision to begin the Nashville Software School's fourth cohort has been a wise one. I'm currently four weeks in to the first half of the program, and although intense, I'm loving each and every moment. We're snowed in today, so I'm going to write a brief post in place of my usual commute time.
Up until this week, I'd understood closures only at face value... I could explain what they were, but hadn't reached the point of knowing how to really utilize them in my code. So, I want to record some notes explaining how they work, and an instance for using them effectively.
I prefer to keep my posts technical, but I'll deviate from that for a moment to talk about my decision to attend the Nashville Software School (NSS).
Growing up as an athlete, I found that with enough grit, I really was able to accomplish whatever I had my sights on. However, with 'coding bootcamps' popping up left and right, I was drawn to the idea of being able to reach my goals faster, through an intense, immersive experience. With programming being quite possibly the largest rabbit hole known to man, I think the biggest benefit for me with be having a structured curriculum to follow.
A word of advice for anyone who may also be considering attending one of the many bootcamps out there. These programs are NOT all created equal. Specifically, I wonder how much you can really teach someone in a 10-12 week time span. The shorter programs that are successful, are filled with people who've already got a good bit of programming experience under their belt for that specific reason. Not to mention, I think it's important to have a solid 6-12 months exposure to the field before deciding whether or not a bootcamp is a wise investment for yourself. Personally, it seems a bit far fetched to think you can take someone who's done a few weeks worth of pre-work, and have them ready for a substantial job offer in that kind of time frame. Even with 18 months experience teaching myself, and pursuing a second Bachelor's in IT, I declined slots at other programs and decided to look at gSchool and NSS, both of which are 6 month programs. During gSchool's Skype open house, it seemed my concerns were shared by a lot of other prospective students, many of which had also declined their slots. With NSS being a non-profit, and with my family 70 miles away, I accepted an offer from NSS without moving further with my gSchool application.
Finally, I'll add that this is only the beginning, a next chapter as it may. Once I complete NSS, I will be continuing on with school, even if it means continuing at night while working. I want to dig deeper into some lower level languages, and while others may see formal education as being unnecessary, I definitely don't see the harm in utilizing every resource available.
Feel free to ping me if you have any specific questions about some of the other programs. I'd be glad to share more about my experience, and point those interested in a good direction!
As an aspiring full stack developer, I spend a lot of time in terminal (iTerm2 specifically). In fact, I actually prefer to work in terminal rather that with the OS X gui. With that said, I want to share some of the things I've learned in regards to customizing your bash prompt.
First up try this;
The env command is going to dump your current bash session's environment variables. Right now, since the focus is on customizing our prompt, we're focused on PS1 which stands for Prompt String One. Likely, PS1 will be set to a default resembling \h:\W \u$. Here, \h returns your computer's name. \W, returns your home directory. And \u returns the current user. Since I'm the only one on my machine, my machine's name, and my username are pretty useless. In fact, the actually clutter up prime real estate. So, for my purposes, I've chosen to only retain my working directory. For fun, I did explicitly add a name as well. (I'll post the code in a moment since I'm not done just yet.)
So, just like any variable, you can reset PS1 like this:
$ PS1="what ever you want here"
However, if you want the changes to take affect each time you start a new session you're going to need to edit your bash profile. I have sublime set up to open files from iTerm (see instructions here) so I can pull up mine for editing like so:
$ sublime .bash_profile
From there, I simply append the following:
Simply, my thoughts recorded for future iteration.
$ git clone
Only needed on first cycle.
$ cd cloned_root_directory_name
$ git pull
If done immediately after 'git pull' this step isn't needed.
$ git checkout -b feature_branch_name
5. do some hacking
git add .
git commit -m "your message"
Repeat steps 5-7 as needed.
$ git checkout master
$ git pull
Merging the remote master repo with your local master repo should be a clean fast forward since your hacking has been contained to your feature branch.
$ git rebase feature_branch_name
This is where things could potentially get ugly. To prevent complicated conflict's it is recommended to repeat this often.
$ git push origin master
Reminder, this is meant to be a simple workflow for a small team. It is highly advisable to check if there have been any pushes to the remote master since you completed step 8.
In the fall of 2012 I received a scholarship to the Team Treehouse website. Although my path is only beginning, I'm incredibly grateful for the foundation their tutorials have provided me.
Read my TreeHouse story here:
Context: I'm writing this as a quick reminder to myself. Sort of like when I was back in Catholic elementary school and the nuns would make us tirelessly write out our vocabulary words until our wrists were ready to fall off!
Just some notes written down for my own reference. Enjoy them if you wish!
Here's another cool trick I learned through pairing today during my apprenticeship. In IRB, you can use an underscore to retrieve your last return value. Seems like the perfect shortcut whenever you realize too late that you should have stored a value in a variable! Here's a quick example.
$ 1 + 2
$ _ + 3
I started an apprenticeship a week ago and I've learned an incredible amount of tricks through our pairing sessions. Side note... Screehero is the pairing app we're using and it's wonderful! Part of my task for the week was to automate the process for backing up our production database to our local machines in Ruby. By now, I'm somewhat comfortable with Ruby and terminal so separately these tasks didn't seem too bad. The challenge was to figure out how to execute bash in a Ruby script. To my surprise, this was actually MUCH easier than I was expecting. My trick, was to wrap my bash in backticks within my .rb files. I imagine this can be pretty powerful since instead of inputting endless commands in terminal, I can now simply feed it my .rb file to execute. Cheers to becoming a lazy programmer! Now if only I could get the benefits of logging 30 miles running each week with a shortcut like this!
Here my super simple Ruby script in case anyone needs some MySQL bash commands for a SQL dump.
Ever want to know what files would be generated for a specific rails generate command? I read today, that you can find this out simply by passing in a
-p flag to the end of your command. Cool!
$ rails generate model myModel -p
1. Find the setting button for your app on Heroku.com
2. Edit your apps name and click 'Rename'
Next, since the directions above use the Heroku website to update the app name, and because you may have other developers contributing to your project, the individual git remotes will also need to be updated.
3. In terminal (still in your apps root directory) run:
$ git remote rm heroku
$ git remote add heroku email@example.com:yourappname.git
You're now good to go!
UPDATE: There is actually a much simpler way to go about renaming your app. Simply run:
heroku apps:rename newname
If you've tackled your CLI fears this is much easier as it allows you to rename your app and updates your remote Heroku repo in one.
1. mkdir -p
If the parent directories don't exist, the
-p argument creates them.
$ mkdir -p unitedstates/illinois/chicago
Brings you to the absolute root folder.
$ cd /
Brings you to the relative user account home folder.
$ cd ~
4. pushd & popd
popd commands work just like array methods, allowing you to easily navigate between multiple directories. If you're at your
pushd and pass it the path to
chicago to change to
chicago. When you want to go back to your
desktop, just use
popd, (without a parameter) to take
chicago of the stack. You can do this for multiple folders, and it just pushes them on the end of an "array" of directories and pops them off as you need them, first in, first out. Note that
pushd can also be used without a parameter to swap between directories already on the stack.
$ cd desktop
$ mkdir -p unitedstates/illinois/chicago
$ pushd unitedstates/illinois/chicago
And for a little fun I have to admit something. I have a horrible irrational fear that my cat is going to somehow walk across my laptop when I've left terminal open and type
rm -rf /!
Here goes another newbie post. I’ve been told over and over again not to dig into Rails 4 yet since there’s not a lot of info out there. But, if I’m learning Rails for the first time, doesn’t it make sense to hash out the differences and not develop habits that are going to be depreciated? So now, I’ve set up my environment so I can have the best of both worlds!
In my newness, I’ve unfortunately allowed a slew of gems in my default gemset which makes things messy when you want to work with various versions of Ruby and or Rails depending on your app. My solution going forward is to create .rvmc files per app (or groups of apps), that will contain custom gemsets so I’m not polluting my default environment. This is best done with a clean (or minimally polluted default gemset), but works fine if you’re like me and already have Rails 3.2.X set as your default.
If you already have RVM installed, go ahead and get the latest version. In terminal run
$ rvm get stable –-autolibs=enable
The --autolibs flag tells rvm to automatically install necessary dependancies on you system as well (important for those of us still with student status)!
From there, you can check for any Ruby updates you want by running
$ rvm list known
Since Rails 5, (gasp, I’m still trying to learn 3.2 and 4) will require 2.0, I figured I might as well get going with that!
To install run
$ rvm install 2.0.0
Of course you can explicitly use any version returned from the known list also.
Now for the fun stuff (many thanks to Kevin Lawver from Rails Machine for helping me with this part)!
In terminal, cd into whichever directory you keep your rails projects, create a new directory for Rails 4, then cd into that one.
$ cd rails_projects
$ mkdir rails_4
$ cd rails_4
From there, you’ll create a directory specific gemset. I’ve explicitly stated I want to use Ruby 2.0.0, but of course you can choose whichever version you like.
rvm –-rvmrc –-create 2.0.0@rails_4
Cd out of that directory, and then cd back in. It will ask you to accept the new .rvmc file which you will of course say yes to.
$ cd ..
$ cd rails_4
For extra assurance you can run
$ ls –a
to see the hidden .rvmc file.
Then, all that’s left to do is to install Rails 4. Don't panic... it may take a few minutes.
$ gem install Rails
$ gem install bundler
You can now run
$ rails new myApp
To generate you Rails 4 app.
I recently made the switch over to SparkPost, which is one of Heroku’s newest add-ons (I also work there)! There is a free basic plan that includes up to 10K of emails a month. SparkPost has the highest inbox placement of any provider, and real-time analytics with over 40 different metrics. It's also built by Message Systems, which is the email provider for large scale companies like Facebook, Twitter, and Pinterest, so that made migration an easy choice! The move was straight forward, quick, and easy!
Once you have a card on file, just run
heroku addons:create sparkpost:free
to add SparkPost to your app.
I'm going to write this from the standpoint of where I was last week so here's some background. I, like many other newbies was happily going along completing various Rails Tutorials not aware that my "secret token" was being committed to my public GitHub repo for the world to see. For random tutorials this isn't really a problem, but when it's time to start an actual app you plan to deploy, then this is going to be necessary. The solution... environment variables. There are a ton of ways to go about hiding your apps token (and other confidential info like emails and passwords), but I opted for Figaro.
Configuration is pretty straight forward. Add Figaro to your Gemfile and run
$ bundle install
$ rails generate figaro:install
Figaro's generate command will create an application.yml file for you and automatically add it to your .gitignore!
Now, add the variables you want hidden into config/application.yml.
It will look something like this if you use Gmail:
I've been meaning to write my first blog post, but have a hard time stepping away from my own learning for a moment to share something I've learned. With that said, this is going to be short and sweet (but hopefully prevent some headaches)!
In development, make sure you're including bootstrap first!