Hack the News: Our First Hackathon
Read Full Article
From Chelsea Skovgaard A mad rush of two hours of writing code, merging CSS and Ruby on Rails, munching pizza, and drinking beer was our experience at our first hackathon. On September 16, a team of Turing students competed at the Hackthe.News event that was hosted by Name.com . The goal of the hackathon was to bring developers and journalists together to create ways that reporters can share important stories while maintaining their business’s sustainability. I, Chelsea Skovgaard, and Jasmin Hudacsek were lucky enough to be two of the students who participated. Often, it is challenging to participate in an event outside of Turing with the intensity of the work, but taking time to participate on the Friday before finals week was one of the best decisions I made during my first module at Turing. The Turing team consisted of me (1608 Front End), Orion Osborn (1410 alum), Noah Berman (1608 Back End), Jasmin Hudacsek (1606 Back End), Jean Joeris (1606 Back End), Christopher Calaway (1606 Back End). Our team members’ reasons for joining the hackathon varied from exploring technology careers linked to journalism to discussing the lack of quality news during this election cycle. After a short brainstorming session that involved talking to a couple journalists, we decided to work on a tool for journalists that would combine tracking story pitches along with a contacts database to streamline sources and stories. Due to the team’s background, we decided on an RoR application while I — being the sole front-end focused member — wrote the CSS. From Jasmin Hudacsek I’ve only been at Turing for the last four months, so it was a bit intimidating going into my first hackathon. However, the turnout for this event left me feeling a bit more at ease. The team to get second place...
Hands Off the Mouse!
Read Full Article
As a newcomer to the world of programming, I was somewhat reluctant to learn keyboard shortcuts. Using hot keys and being able to “type quickly” as I saw it seemed like finishing touches to my education rather than the keys to its success. As I’ve become more comfortable with code, shortcuts have become a way of personalizing my workflow, and something I’d encourage everyone who is new to developing to learn and learn quickly. Thus far in my education as a developer, workflow has been highly emphasized. That’s because it's actually pretty important to know your way around the keyboard. Constantly arrowing one key at a time around my code and manually searching a Rails project for a certain file not only takes time, but it takes your head out of the problem you’re trying to solve. After finally realizing the importance of what I was once so reluctant to learn, I’ve adopted some favorite shortcuts that I would encourage every developer to learn. Below I will go through a list of my favorite shortcuts, as well as ones I am still incorporating into my workflow. Keep in mind that these will be specific to my text editor, atom, and the browser I use most often, Chrome. Across different applications these shortcuts may vary so double check if you use something else. GitHub Shortcuts: These are not shortcuts I started out with, but ones I am learning. Anywhere on GitHub you can type: in order to see all handy shortcuts available on github. Keep in mind some of these are only available within a specific repo while some are sitewide. Take a look at some of these and try to incorporate them into your Git workflow. Chrome Shortcuts: Chrome is another area in which I am still working on improving...
Make Database Performance Great Again
Read Full Article
I built a Rails app that took 300 seconds to load. No, that’s not a misprint. I didn’t forget to include the ‘milli’ prefix, and I’m well aware an app that slow will never be more than a dumpster fire of sadness — no matter how interesting or visually appealing the data it renders is. So, how did I get there? And more important than that, how did I refactor my code to bring database performance back to a satisfactory state? Before we dig in, let’s take a step back. On the job, you’re likely to encounter database performance issues due to the average web app being so database reliant. When this happens, where do you start? Resist the urge to immediately start rooting out N+1 queries, and instead use a service that measures app performance one call at a time. The small time investment required up front will almost assuredly save you time and headaches in the long run versus the guess and check approach. Bullet, Skylight, and New Relic are all good options for Rails apps. I used New Relic and quickly confirmed the problem I suspected — an index page was calling nearly the entire database over 200 times when only a single query was necessary. So, we’ve found the bottleneck, now what? In my app, the ‘count_tweets’ method queries a database of 10,000 tweets, groups them by user location, and groups them once more according to a hashtag ID. Prior to the refactor you see in the screenshot, the return value from ‘count_tweets’ was called by four other methods in the class and the database was queried each time. A table in the index view called these four methods for each of the 50 states plus DC — 204 database queries in all! Gross. Let’s eliminate this absurd traffic jam. Wanting to...
Tips & Tricks for Using Travis CI
Read Full Article
My project at school this last week was to work with a team on an established Rails application in the same fashion we would if we were working together on the job out in the real world. We had to submit and comment on pull requests as each of us built out a feature, did research, or attempted to chase down a bug. I undertook the task of implementing Travis CI, something I thought was going to be very simple and only take a day, maybe two. In retrospect, this whole thing was very simple, but figuring out what I needed and how to string it all together the first time was a bit of a headache. So I'm going to lay out the basic steps here in a hopefully more straightforward and helpful manner than what I myself encountered. But first, what am I even talking about? Well, the 'CI' in Travis CI stands for continuation integration , a development practice in which each time a pull request is submitted on Github, the code is checked against an automated build and tests are run automatically. The idea behind it is that any issues will be caught early on, before a branch is merged into master. My favorite part is that I often forget to run my test suite before pushing up my code, so it's nice to have that check in place. The first thing you want to do in order to add Travis CI to your project is sign in to Travis with your Github account. If you then go to your accounts page and click Sync account you should be able to look at all your repositories. There will be a little toggle switch next to each repo - flip the switch on for any repos you...
Student Project Spotlight: Building an Interactive jVectorMap in Rails
Read Full Article
Upload Background Image