TLDR: Blank lines in a .csv.erb template render as whitespace in the final CSV output.

Using the method I described for exporting CSV, I created a new template and was testing it. When I downloaded the CSV file and opened it, it appeared that the file was empty. What was going on? I noticed that the scroll bar was rather long, so I started scrolling… and scrolling… and scrolling, down 1369 lines. There’s the data. Then, I looked at the total lines in the file: 2738, which is double 1369. It appears that, somewhere, I was inserting 1368 blank lines into the file prior to the data being written.

I started debugging my .csv.erb template to see where this whitespace was coming from. First, I set a breakpoint in the template right before rendering the CSV. Ruby’s CSV library wraps a string in a CSV object, and I could verify that the string had no whitespace.

Next, I started removing elements from the CSV template until I found the culprit. What I found was that an entire section of the CSV document was where the problem was happening. No matter what subsection of that section I removed, the issue would still persist. If I removed the entire thing, the output would begin at line one.

Finally, I decided to try something that I thought was crazy: I had defined a few variables in ERB tags earlier in the document, and I had inserted a blank line between each of these for readability. What if I removed those? The output began at line one. Bingo! Not so crazy after all!

If you have more whitespace than you bargained for in CSV output and are using a .csv.erb view template, check for blank lines. These could be the culprit.

Exporting data from Rails to be used in different applications can be a tricky topic. What format do you need to export to? What if one export needs some data and another export needs other data? I had to solve exactly this problem with CSV. Ruby has an excellent CSV Library that is ripe for use with Rails. From my research, there are 2 basic ways of exporting CSV data from a Rails application that I have come across so far: calling to_csv on a model object in the Controller and generating CSV directly in the view.

Calling to_csv is a great option if you only ever need the CSV data in one format. My problem was more complex: I needed to allow the user to choose what format the CSV data was exported in, and then provide it in that format. To solve this problem, I chose to render the CSV in the view. Here’s how I did it:

The Controller

Rails controller actions respond to HTML by default. Luckly, setting up your controller to respond to CSV is really easy using ActionController::MimeResponds#respond_to, as follows:

def index
	# Standard model queries here...
	
	@template = params[:template]
	
	respond_to do |format|
		format.html
		format.csv { render template: "path/to/#{@template}" }
	end 
end 

The most important portion of the index action is the @template variable. When the user chooses what format they would like the CSV exported as, the download link provides a param that tells the controller what CSV template to render.

Bonus Tip: Optionally, you can also set the Content-Disposition header to make the CSV file download automatically and set a file name, like so:

format.csv do 
	headers['Content-Disposition'] = "attachment;filename=Your-File-Name-Here.csv"
	render template: "path/to/#{@template}"
end 

The View

Here’s where Ruby’s CSV Library comes in handy. Create as many CSV templates (in csv.erb format, so you can embed Ruby directly in the template) as you need and save them wherever it makes sense. They will each look something like this (obviously, with variation in the data displayed):

<% export = CSV.generate(" ", { headers: ["Array", "Of", "Headers"], write_headers: true, encoding: "UTF-8}) do |csv| %> 
	<% csv.add_row data %> 
<% end %>
<%= export.lstrip.html_safe %> 

Let me explain what’s going on:

1. The export variable is set to CSV.generate. This is the method that will be generating the actual CSV string that the user has requested.
2. CSV.generate takes 2 arguments: a string and a hash of options. I’ve passed a blank string and provided headers, write_headers, and encoding as options. headers is the content of the top row of your CSV file, and can be either an array of strings or a string separated by commas. write_headers specifies that the headers should be added to the CSV output (optional – false by default). encoding allows you to specify an encoding for the file (also optional – I’ve chosen UTF-8).
3. CSV.generate takes a block, in which you pass in the rows you actually want to add to the output. You can iterate over your data however you normally would in a view file in this block, and then pass the result to csv.add_row.
4. I explicitly have not printed anything in the view file until the last line. If the last line was left out, the CSV download would be a blank file. This is optional (you can alternatively remove the export variable and call CSV.generate in <%= %> tags). I did it this way because:

• My own CSV exports required that no blank lines be present in the export. I am calling lstrip because I found that a 0A (LF) character was being prepended to my CSV string, inexplicably.
• I am calling html_safe to avoid HTML escaping in the output. This should only be done if your data is known safe.

The Link

Now, when your user is given the option to select a CSV download, you can provide options that will provide the name of your CSV template to your controller. I implemented this by using a select_tag together with options_for_select that gathered the options from a Hash I provided. You can use whatever method provides the correct param to your controller.

In just a few lines of code, Ruby and Rails provide everything needed to create a very flexible CSV exporting system. Hope this helps with your CSV exporting needs!

It’s been almost a year since I enrolled and started down the path to change my career with the Firehose Project. While I’ve talked about my experience finding my first developer job, I haven’t talked about why I chose the Firehose Project.

Back in early 2015, I knew I wanted to transition my career into the tech industry, but I didn’t know exactly how. I had just completed my CompTIA A+ certification, a process that made me realize I would prefer being a developer to being an IT professional. The only problem: developers need to have a degree in Computer Science, right? I couldn’t afford to go back to University for another 4 year degree in either time or money. Shortly after desparing that I could never become a developer, something amazing happened: I was introduced to programming bootcamps.

I attended an info session for Bloc in April 2015 that really pumped me up. I could become a developer without having to spend 4 years in Univeristy and tens of thousands of dollars on tuition! My son was just 1.5 months old at this point, and he needed the time that I would otherswise have to spend working on bootcamp curriculum. I promised myself I would join a bootcamp in September 2015, when my son would be 6 months old. I spent the intervening months researching the bootcamp I would join. The Most Epic Guide to Online Coding Bootcamps, Ever by Laurence Bradford coupled with Course Report helped me make a difficult call. While many other bootcamps seemed like they were good, the Firehose Project stood out because they taught algorithms in addition to the regular Rails curriculum. In the end, I chose Firehose because:

1. The curriculum covered computer science fundamentals in addition to web development, keeping the changing framework material grounded in unchanging fundamental material and giving me a deeper understanding of how the frameworks work;
2. The time commitment (15 weeks, at that time) was shorter than other bootcamps, but didn’t skimp on ground covered; and
3. The price ($4,000, at that time) was more affordable than other bootcamps.

During my 15 weeks, I learned a ton at a surprising pace: literally drinking from a firehose. Some of the best moments include:

1. Building the first tutorial application, Splurty. Firehose is set up to give you quick wins, providing motivation to continue learning. It felt so good getting my development environment set up, generating a new Rails application, writing my first MVC code, typing rails server, and seeing the results instantly in my browser. Even more so when I could share what I built after getting it running on Heroku.

2. The sessions I had with my mentor, Jeff, were informative, challenging, and really, really fun. I prepared questions throughout the week as I went through the course material, and Jeff would go over everything with me on Sunday evenings. He went out of his way to be helpful to me, often going over the alloted 1 hour time period we had. Jeff is a really great mentor and developer – he never ceased to amaze me with his deep knowledge of practically any question that I could throw at him. I can trace many of my major successes to our sessions. I’m sure that the other Firehose mentors are of equal caliber.

3. The group project at the end of the program was worth the cost of the entire course. Being put into a group of 4 other developers and told to build a chess application from scratch together was an awesome experience. From going deeper into the Rails API and building out a database structure (including using single table inheritance), to pair programming with multiple members of the team using Screenhero, to solving complex problems and testing our solutions with TDD, this project had it all. It really gave me the opportunity to stretch my new developer wings and gain the confidence necessary to be able to go out into the world and present myself as a capable junior developer when it came time to look for jobs. Our team mentor, Travis, was a fantastic teacher and obviously very passionate about coding, and the weekly standups we had with him were great.

After graduation, I was supported by both Jeff and Travis, receiving feedback and advice about building my resume and how to ace the interview. Just a few months later, I achieved my goal and became a professional developer.

In the months since starting my job, I’ve learned a ton more and have improved my skills a hundredfold. And because of the fantastic foundation that the Firehose Project gave me, I’m confident that I’ll continue to learn more and grow to be a better developer.

Going from feeling not smart enough to be a programmer to being a programming bootcamp student was a big change. Getting my development environment set up, starting the initial lessons, and becoming part of the Firehose Community all produced a sense of relief and joy. I was finally on the path to becoming a developer! Fast forward 15 weeks and I actually was a developer. I had completed my assigned tasks on the group chess application and felt very proud of the results. My next challenge was to face the great unknown: the job market for bootcamp graduates.

Resume

My first task was to polish up my resume and include my new programming knowledge and experience. I also decided to build a simple resume page on this site to display it. After all, I’m a web developer – making a page for my resume seemed like the obvious thing to do. After completing my resume, I solicited feedback from my mentors. That was a fantastic decision, and I encourage you to do the same. Some of the advice that I got was:

1. Remember your audience. A technical hiring manager is someone who is, at very least, familiar with things like Rails or a pull request, making explanations of such things unnecessary. Don’t waste words (and space) on something that isn’t helping the hiring manager make a decision about whether you’re right for the job.

2. Make it easy for the hiring manager. Your resume is your first point of entry into an organization, not the end-all-be-all of you getting hired. Pay attention to what the job requirements are and check as many of those boxes as you have skills and experience. Make it easy for the hiring manager to move your resume to the yes pile for the next round.

3. Be honest. Don’t proclaim that you “know” something just because you’ve used it once, but don’t be afraid to say where your interests lie and what you’re currently learning. Being a developer means you’re in for a career of constant learning and growing. Show your curiosity.

4. The more the merrier. Another great decision I made was to not limit myself to a single resume location. I mirrored the information in my resume to LinkedIn and Stack Overflow Careers, allowing more potential employers to stumble accross one of my profiles. One benefit of the latter was that it also produced a nice PDF to submit via e-mail, for employers who wanted that.

Job Hunting

Once my resume was ready, I took to looking for jobs. My approach here was not very scientific: visit a few job boards daily that good companies advertised on, make a list of all the positions that sounded interesting, and apply to those positions on my list. My favourite job boards were:

1. Stack Overflow Jobs. This was my most used job board. There are a lot of companies that post here every day and the filters are great. If you create a profile, they will also match jobs with your interests and skills automatically.
2. We Work Remotely. This board is the board to look at for remote work. There are fewer listings, but they’re all guaranteed to actually be hiring remotely.
3. The Muse Jobs. The “Filter Jobs” feature on this board is great to look at larger companies in your area. The profiles they have of the companies you’re looking at are the best feature here.

Around the time I started looking for a job, The Complete Remote Jobseeker’s Handbook, an eBook from Coby Chapple (a designer at GitHub), was fortuitously released. This eBook is filled with great information for seeking remote work, including the benefits (and curses) of being a remote worker, lists of high quality job boards to look for remote work, strategies for applying for jobs (this was applicable to any job hunting, remote or not), and interviewing tips. My biggest takeaway from the book was that the interviewer wants you to succeed: finding and interviewing candidates is as much work for a company as applying and interviewing is for you. If you’re the right person for the job, their work is over, as is yours. It’s win-win!

Another resource I found helpful was Interview Cake, a site that promises to teach you to be good at programming interviews. While I didn’t actually face many technical challenges in the interviews I completed, this site was a great confidence booster as I realized that I was a better problem solver than I thought. And I learned a lot from the practice problems too! Well worth the cost of admission.

Applying for Jobs

During my job hunt, I kept a detailed spreadsheet of the companies I applied for (including a copy of the job description, the date I applied, and the title of the job). From late January to early April, I applied for 23 jobs, which lead to 4 interviews. Early on, I spent a lot of time crafting a unique cover letter to each position I applied for, which meant that I was only applying to 2 positions a week (or less, depending on the time I had to spend on applications). I asked Ken Mazaika for some advice as I was going along, and he suggested I focus on a higher volume of applications, as (he estimated) that you have around a 10% chance of getting a response from companies for a junior role. I took his advice and used the cover letters that I had already written to prepare a template. This enabled me to apply to 5 or 6 a week (at peak).

Of the interviews I had, 2 were telephone screens and 2 were in person interviews. When it came to technical challenges, one of the telephone screens had me answering basic object oriented programming and responsive web design questions and one of the in person interviews had me filling out a general web development quiz. I never had the dreaded whiteboard interview (whew!). I was also given one take home assignment: building a simple to do app with the technology of my choice.

A real surprise came when I was contacted on LinkedIn about a potential job opportunity – a company in Toronto was hiring Rails developers, and the recruiter noticed I had some experience with Ruby and Rails. After a phone screen, 2 in person interviews, and a take home assignment, I was given a job offer from BioConnect to work on their Rails time and attendance application, TeamWorks. I accepted that offer and have been working on TeamWorks since the end of May. My first month as a software developer has been better than I ever could have expected. I work with a great team, I’ve been given the opportunity to learn a lot of new things, and I’m doing something that I really enjoy.

If you’re currently in a bootcamp program, fear not about the great unknown of the job market. You may face a lot of rejection (or be ignored) on the road to getting your first job, and you may feel out of your league at times. Keep looking for the next big opportunity, keep seeking advice from mentors, and (most of all) keep coding!

That thought burned through my brain as I decided on a major for university. I should have been a shoe in as a computer science major – I spent all of my free time noodling on my computer at home and I was one of (only) 4 students in my high school’s computer science class. I was a classic computer nerd. And I loved high school computer science class! But my internal negative self-talk convinced me that I was no good at math and to be a computer science major (and a programmer), you needed to be “good at math”. I instead chose to study business (pragmatically, for transferable skills) and political science (as an interest).

Years later, I discovered Codecademy and got started learning Python. I chose Python simply because I had heard of it before. After completing all of what Codecademy had to offer, I realized that programming wasn’t insanely hard. There were rules and patterns and syntax, but it was learnable. And I wanted to learn more! A lot of individuals on Stack Overflow and Reddit suggested Learn Python the Hard Way, which I started but never really got into. Yet, I started thinking of myself as a programmer and deeply desired to learn more and get better.

I knew that I couldn’t afford to go back to school, especially since I had (and still have) a young family, but I felt overwhelmed at the volume of knowledge that was out there to absorb. Then I discovered coding bootcamps: organizations solely devoted to teaching new programmers the basic tools of the trade, preparing them to become capable junior developers. I did some research, settled on The Firehose Project and didn’t look back.

For anyone out there who is thinking of becoming a programmer but has the nagging thought “but I’m not smart enough”, let me be the first to tell you that you are smart enough. Computer science is an incredibly broad field. Not every programmer is devoted to discovering new algorithms and optimizing the speed of compilers. But if that’s something that you find you enjoy, its something you can devote your entire career too.

My biggest piece of advice for anyone interested: just get started programming! You’ll quickly discover 2 things:

1. Do I like this?
2. If so, where is my niche?

If you do end up liking programming, you’re on the start of a fun, frustrating, and ultimately rewarding path.

Further Listening

I was inspired to write this post after listening to Episode 6 of Under the Radar, a weekly podcast from Marco Arment and David Smith about independant app development that’s never longer than 30 minutes. I highly recommend listening to it.