The Tail of Truncation

Last week I came across a pretty solid problem, by the time I found the most appropriate solution it had evolved quite a bit. I felt it had the making for a worthwhile blog post, so here it goes.

The problem: we need to display only the first 220 characters of the body of a Press article on the Press Index page.

Initial solution: implement Rails truncate helper. It can be used in the view, as such:

truncate(press.description, length: 220)

This worked for the first 9 items on the page, running as a standard each loop. But we are also implementing infinite scroll on this page with javascript, which renders each item after the ninth through an HMTL template and JSON. So, for the template I had to make a method in the press_serializer.rb file that looks like this:

def description
    object.description.truncate(220)
end

That all worked, but didn’t render well with the other styles on the page, was showing some markup tags, and isn’t the most efficient solution. So, I moved the nuts and bolts from the view to the application_helper.rb and made it into a method:

def truncate_description(description)
    description.truncate(220).html_safe
 end

So now in the view it looks like this:

truncate_description(press.description)

I also modified the method in the serializer for the html template to this:

def description
    object.description.truncate(220).html_safe
end

It’s definitely cleaner code in the view file, and its faster coming from the application helper.

Note that the .html_safe is necessary because we are using a WYSIWYG (What You See Is What You Get) editor to create the description, so there are potentially a lot of opening and closing of tags.

This all worked in our QA and the clients. The first 9 records were being produced via the each loop, and all the rest with the JSON and HTML template. But, as it so happened, we came across an edge case, and that was my problem to solve.

New problem: Basically, what was happening was that the clients wrote a description and included a link within the first 220 characters, which was cut off by the truncate helper. This meant that there was a tag that wasn’t closing, and it bled the link content onto the first piece of text in the next description card.

What would have been super easy was just to tell the clients to rewrite the article, and move the link. Oh, and in the future, don’t put a link within the first 220 characters, thanks! But, of course, that’s not an option. The solution seems like an obvious one, even to me as a write this, but it actually took a good bit of googling to find it.

New Solution: Ultimately I ended up using the truncate_html gem for the Ruby components and html-truncate gem for the JSON components. The Ruby part can be setup like this:

Add truncate_html gem to Gemfile

Replace truncate with truncate_html in the view

truncate_html(press.description)

It can be as simple as that, but to add some versatility I also created a truncate_html.rb file in my initializers folder:

TruncateHtml.configure do |config|
   config.length        = 220
 end

The length could have been added to the line in the view file, but it’s cleaner to have the initializer file, and allows for growth, should any other parameters be necessary.

As for the JSON and HTML templates, after I installed html-truncate I just had to two variables to the top of the HTML template file:

var truncate = require('html-truncate');

let description = truncate(press.description, 220);

Now both the Ruby gem and JS package will close any open tags before truncating, allowing for there to be links, bold tags, or whatever at any place in the description with no problem at all.

Resources:
http://api.rubyonrails.org/classes/ActionView/Helpers/TextHelper.html#method-i-truncate
https://github.com/hgmnz/truncate_html
https://www.npmjs.com/package/html-truncate

Ask Me Anything!

I’ve been developer for nearly 4 months now, and it baffles me how hard it is to digest anything I’ve done into something I feel is post-worthy. It’s the same situation with presentations for Boulder Ruby Meetup, I just don’t know what to talk about. Don’t get me wrong, I have leveled up more in the last three months than I could have even dreamed of, but I’m just not sure how to filter that into something to talk about. I’m thinking I might do a ‘brain dump’ post, where I literally just list off all the things I can think of that I’ve come across, or gotten help with since I started, but I’m still working on that list.

One thing I have been doing in the past few months is giving advice. I’ve had people get in touch with me about various things, but mostly asking specific questions about my path from non-dev to student to paid dev. I got to where I am because I asked a ton of questions to just about anyone I could get in touch with, so I am always more than happy to do the same to anyone who contacts me. With that said, I want to be more proactive about helping others and put it out into the whole of the interwebs that I’m open to any questions from anyone about my experience up to this point. Im not claiming to be any kind of expert, but ask away and I’ll do my best to respond with helpful input.

Yes, I’m serious. To be honest, just about everyone I’ve ever encountered in this field would probably do the same, but few advertise it. And I know for a fact that a lot of people wouldn’t think to ‘cold-call’ someone they didn’t know with questions, so I’m opening the door. As a student I followed up on a strangers’ Twitter post where he offered a half hour of his time to anyone, and it helped steer me in a better direction when I was getting a bit off course with school.

This isn’t a one-way street, the interactions will help me determine what the community as a whole would like to hear more about, which will help guide me as to where I should focus future posts and presentations. And the flipside is, if I get questions I don’t have immediate answers to, that will force me to dig around and find those answers, helping with the ‘you don’t know what you don’t know’ scenario.

For the time being, let’s start off with emails. Ill try to get back to them within a few days, but who knows what might happen, so I’ll say with certainty within a week. For the sake of my spam box I’m not going to link my email, but a message sent to noelworden(@)gmail will get to me.

This is an experiment, lets see how it goes!

Weeks 33 – 35

161017 – 161106 — Total classroom hours – Stopped counting

Well, not too long ago I said I wouldn’t let the blog go more than two weeks without a post. I’m not going to go back and count, but it was probably less than two months ago. So, I didn’t hold true to that very well, but better now than never! I’m not one for excuses, but it definitely didn’t help that I didn’t really feel like I was kicking ass in anything, but at the same time still felt incredibly busy. I did reach some high notes at the end of this week, so that was a good morale boost.

We had our first retrospective at my internship. Scheduled retrospectives of some sort was a prerequisite for my accepting the internship position. He was all for it, so it’s not like I had to fight for it, but I wanted to know that I would be getting and giving feedback to ensure forward progress for both of us. Up to this point the internship didn’t have a whole lot of structure. What I mean by that is I never really knew what we were going to be getting into during each meeting. That, coupled with the fact that it was running on Rails 2.x, and that the codebase was pretty crusty (as my mentor willfully admitted), all made for a learning, but not super productive experience. During our retrospective we discussed this and decided that working on a different codebase might benefit both me and him more.

This new project is a current codebase, Rails 4.2.5, has a full Rspec test suite, and is much less crusty. During the retrospective we decided that we should try me working on my own more, for many reasons, mostly to force me to dig through tough problems and make decisions based on my best judgement. I was a little hesitant at first, thinking it would take me hours just to decipher what was being asked of me. But I sat down on Saturday and looked at my Pivotal Tracker user story and started to chip away at it.

It felt really good to be working through current Rails again. I’ve been working all front-end with Bloc, and old Rails/JS with the internship. This felt like seeing an old friend again. I took about 30 minutes clicking through the file tree to get an understanding of what was going on, then tackled some routes and fresh .haml files. What’s nice about working on an existing codebase is that there’s a good chance a lot of the solutions to the problem at hand can be found somewhere in the code if you know what to look for and how to find it. I blocked most of Saturday for this user story, and to my amazement I had the first PR ready to submit after about 4 hours. I did go back and forth with my mentor a few times about some syntax I wasn’t quite understanding, but I tackled most of the overall problem on my own and I think pretty efficiently. I mean, I’m writing production code! Thats a huge step in the right direction!

When I started this project I also started a sort of journal to keep track of what I am doing, where I’m getting stuck, and what I need to research more. Initially I started it to be able to talk my mentor through my process, but I think I’m going to keep the entries for a while to reference later on down the road. Im sure that if I find myself at a roadblock once I’ll probably be there again in the not-so-distant future. I probably should have been doing some kind of journal all along, but, as is the theme for this blog post, better late than never.

As far as Bloc goes, at this point I’m really just trying to get it done as ‘efficiently’ as possible. The deeper I get into the front-end section the more I’m finding that I’m probably more of a back-end, database developer. That might change, and I hope it does, I hope that I do enjoy both aspects equally, but right now the front-end isn’t nearly as fun as Ruby/Rails. I stopped logging my hours that I spend on the curriculum. I’m on pace to finish quite a bit early, not unlike the back-end section, so I think it’s safe to say that I understand what I’m doing within the scope of how fast Bloc wants me to pick it up. I probably put more hours into the internship per week, especially now that I’m working on Rails code from home. At the end of all this, some day soon, I’ll need to prove to a team that I’m a solid web developer, and I feel like any and all experience that I have under my belt will help me in that endeavor whether it be from school, internship, or personal projects.

Weeks 31 & 32

161003 – 161016 — Total classroom hours – Less than 10

I think the biggest event that’s happened in the last two weeks is that I gave a Beginners Track talk at the Boulder Ruby Group’s Presentation Night (I don’t think I’ve typed that out until now, it’s a mouthful). I’ve been wanting to give a presentation for a while now, but didn’t think I had anything to contribute, being that I’m kind of a noob. I had recently gotten positive feedback on my standardized git commit message formatting, and it occurred to me that not only would an audience of developers appreciate it, the ‘beginners’ might like to know how to set it up.

Now, I’m not going to claim that one day the clouds parted and I had this vision of the perfect commit message, of course I had help, as is the nature of web development, and most of life. One of my now many mentors, Corey Davis, introduced me to this concept a while back when we were working on a group project. He send me a .txt file and then I dug around the interwebs to figure out how to configure it with git. At this point in my coding path I even more green than I currently am, so it took some trial and error to get the message to properly configure. As I found out again recently, testing changes to git configuration can be a beast. Unless I’m missing something obvious, the only way I’ve found is to have a burner file, make a change to it, work through the git add and commit process, and confirm that everything is how it should be. The caveat, especially when dealing with the commit message, is that if something’s not configured properly it can hang the whole process in limbo, which requires an entirely new trial and error process to figure out how to fix that. This is all that to say that I felt like it would benefit some people to give a quick tutorial on how to efficiently setup a standardized git commit message.

I’ve heard from other people how beneficial giving a presentation is for both the audience (obviously) as well as the presenter. I have to say that this couldn’t be more true. I started putting a GitHub Gist together the night before the presentation and quickly realized that although I knew the general workflow of how to create and configure the commit message file, there were a lot of little details that I didn’t know and should probably read up on before I gave the presentation. Because of this I now have a deeper understanding of git and why the .txt file that Corey sent to me was configured as it was.

Before I started the presentation I informed everyone that this was simply my workflow, not the gospel, and that I welcomed any and all feedback. I’m always trying to improve my workflow, which is another reason I wanted to present. What better opportunity to see if you’re doing something right than to show a room full of other developers? I did get some great feedback, in fact there was quite a bit of back and forth during the entire presentation, which to me makes for a better presentation than me just jabbering the entire time. One nugget I received was about another technique on how to stage files for commit.

My previous workflow, mostly because I was mainly only working on one feature or bug issue at a time, was to use git commit -a. Thiswas staging everything for commit. I’ve quickly come to learn, from both my internship and this presentation, that this is the lazy way to stage. I’ve also learned that I should be more thoughtful about what gets staged and what doesn’t. For this I’ve been staging each file manually, then performing a git diff --cached, which essentially shows you all the changes made to each staged file. Then, if there was a file staged that shouldn’t be for that particular commit I would have to go back and manually unstage it. That is, until now! During the presentation I was informed of the command git commit -p, which I’m pretty sure is the patch option. Basically, when this command is run it shows the changes of every file that has been altered since the last commit, and gives the option to stage, not stage, quite the staging process, and about 10 other commands. (here’s a stackoverflow link showing all the commands). This is now my workflow. It handles the code review and staging in one go, which is exactly what I want.

All in all the presentation went very well. I did a little live coding with VIM (with sweaty, shaky hands), had a great dialogue about how/when/why to commit certain things at certain times, and checked a few items off of my programmer-in-training to-do list. I adamantly recommend to every student I meet to attend meetups in their area, and I can now recommend from experience that everyone give a talk as soon as they feel comfortable doing so. This is the link to the Gist, if you have any interest in standardizing your own commit messages. At the bottom of the Gist are some more git references if you want to dive even deeper.

Weeks 29 & 30

160919 – 161002 — Total classroom hours – 23

Well, apparently Im doing something right, because I’m currently two weeks into an internship! It’s with an independent contractor, working on two client-side Rails apps. I’m working with him 4-5 hours a week, so it’s not too taxing on the already tight school/work/life schedule. It’s a completely different beast to work with an existing code base, especially when the other person built it, and knows it forwards and back. As I’m sure is common with a good portion of web development jobs, a lot of what I’m doing is dependent on my abilities to even find the necessary file that needs to be refactored. I think its actually a legitimate ‘test’ for someone in my position, something that evaluates my problem solving skills right out of the gate. When looking at a locally-run web app, how can I identify the problem and find the necessary file in a codebase with 1000+ files. Oh, and did I mention that the entire app itself is being refactored, admittedly by mentor in a very ad-hoc way, so one quarter of the existing files are non-functioning. Im getting skilled at mining for files.

Once I’ve actually found the file, with him literally over my shoulder, knowing exactly where it is in the first place, now I have to identify the code to be refactored. This has two factors that make it interesting, the first is that I have no idea how this file was written. It. Is. Full. Of. Partials. As it should be, I suppose. The idea of DRY programming is that if theres a way to not repeat yourself you utilize it. Digging into a file and its partials just ‘spices up’ the whole process on my end, which, ultimately, I appreciate. The second factor is that the entire app has been refactored from .erb to .haml. Ultimately, it’s not that much different, it’s doing essentially the same thing, but its just something that I’ve never worked with before now, and it’s a bit daunting to take it all in, especially with the other elements that are being introduced to my workflow.

AND! Those new elements are vim and tmux! I’ve known of vim for a while, but the idea of moving that direction was a bit spooky to me. Then, in the course of one week, I was told by two different people that I should give vim a try. I started digging into it and quickly found that vim has a built in tutorial (next time you’re in the terminal type ‘vimtutor’), so thats pretty awesome. The tutorial took me about 45 minutes to work through, and once I was finished I was pretty confident that I could start editing files with vim without causing too much damage. It’s still not part of my everyday workflow, I’m just quicker with a text editor, like Atom. What I did was set vim as my default editor for my commit messages and terminal aliases. This way I have to use it a little bit every day (I’ve been making a lot of terminal aliases lately) and after a while I’m sure I’ll start using it on everyday file editing.

Tmux is also a super handy tool that seems to be widely used. In a nutshell, tmux subdivides your one terminal window into as many different independent terminal windows as you need. Before tmux I was doing a similar thing, only with tabs. I had my first tab as the standard terminal (file navigation, git commands, etc), the second as the server, and the third as the console. The same setup on every project. Now I can have all that in one window. My workflow was pretty good before the introduction of vim and tmux, but now its getting even better (faster). What I’m learning is that its all about your fingers never leaving the keyboard, and when you get really serious about it, your fingers never leaving the home row of keys.

All of this and I haven’t even touched on school yet. School is school, only now its frontend instead of backend. The first round of HTML/CSS curriculum went super smoothly, and now I’m working through Javascript. It seems to be coming to me pretty ‘easily’. I’m sure that I will get tripped up by something, but I feel like having spent so much time troubleshooting languages and frameworks as complex as Ruby and then Rails, the concepts of Javascript aren’t all that much different. And I’ve become pretty good at searching the interwebs for answers to questions. I’ve probably been spending more time on the internship and networking than I have on school. But I’m ahead of the school’s pace at the moment, so I’m more than ok with my current time distribution.

Speaking of networking, I attended Rocky Mountain Ruby last week and it was a pretty great experience. That was definitely the first time I was in a room with so many other Rubyists ( I think thats a term…). I’m also pretty certain that I was one of probably less than a dozen non-working professionals in attendance. I’m sometimes surprised at how few students I come across at events like that, or even meetups. This industry seems to be all about the people you know, and theres no better way to meet people than to go to events where everyone has something like web development in common. Almost my entire web dev network has come from events and meetups, and I’m talking to those people about one thing or another almost daily. I’m sure this is something that is obtained with less effort when attending a brick and mortar code school, but when attending an online program like Bloc I have to go above and beyond to make it happen.

I feel like I’m on a good trajectory with everything so far. Finished the first half of school with time to spare, landed a solid internship, have an ever-growing network of fellow developers, and starting the second half of school with a bang. I’m looking forward to the next few months.

Week 28

 160905 – 160918 — Total classroom hours – 20

Project parkfinder has turned into AdventureSearch, and by the looks of available domain names, I have a hunch that it will change again. But, luckily, it’s just a name. More importantly, its complete!(ish) When I say complete in this case that doesn’t mean that I will never have to touch it again, but instead that I have accomplished the cards I have assigned to the project and it is in MVP (Minimal Viable Product) stage. It works almost exactly like I had envisioned it, with the user merely clicking a button and the three closes National Parks are then shown. Its rough, but entirely functional. I have ideas on how to improve upon it (include more recreation areas, add more user functions to the park’s individual pages, etc) but I’m going to let it be and see what I can apply to it from my work in the frontend portion of the program that I will be starting next week. Take a look and find the closest three National Parks to you!

http://adventuresearch.herokuapp.com/

My other project over the last two weeks has been to clean up the code of my four main projects I have on GitHub repository. This is definitely one of those scenarios where it would have just been easier to do it right the first time (which is usually my style), but when I’m debugging things I have a tendency to get it working and jump to the next card. I’ve come to realize that in this debugging process I have pretty clean code, but my indentations are terrible. I’ve gotten comments on my ‘proper’ formatting when getting help from people, so it seems that people are looking for it, or that it stands out like a sore thumb if it’s not done properly. With this in mind, and because of a comment from my mentor, I decided that it would be well worth the time to make sure all my code looked as clean as possible, not just functional. I have the links to all my projects github repositories on my resume, so if someone is curious they will dig, and it will be one of their first impressions of my programming abilities. Im positive that I’m not the most efficient programmer, but I can at least be a formatting-conscious one and show my attention to detail.

That leads me to the other work I’ve been doing, networking. Networking my ass off. Its been quite some time since I’ve talked this much about myself. I’m a pretty modest person, so this exercise is something that I have to refamiliarize myself with. It’s been nice though, Ive had 3 or 4 very informal conversations about my intentions and goals of being an intern, and those have been followed quite conveniently later in the week by slightly more formal conversations. If things go well, the formal conversations will turn into the most formal conversations in the way of interviews. Time will tell, and in that time I will keep making moves to help ensure that I get to those most formal of conversations.

I have the next week ‘off’ as I am between programs at the moment, but I don’t intend to just sit around. I’ve got some companies to research as well as some pre-coursework to complete before the frontend program begins. No rest for the weary!

Week 26

160829 – 160904 — Total classroom hours – 9

The end is near. As gloomy as they may sound, in this case it’s a good thing. I have two more weeks of school, then a week ‘off’, then I start the frontend course. Not knowing exactly what to do with my remaining time, I consulted my mentor, I mean, he knows best, right? I expressed to him that doing code challenges for the sake of code challenges wasn’t really something I was all that interested in. I can’t remember if he necessarily agreed with me, be we ultimately came to the conclusion that I should start working on another project.

I had plenty of options, there are like 6 projects I could choose from in the curriculum, I had the group project that I could continue to contribute to, and I also had/have a few ideas floating around for a capstone personal project. He quickly recognized the enthusiasm I have for the personal project, and after helping me flesh out the idea and the stages of development, we decided that was the path I should pursue.

rails new parkfinder -T

And just like that, I’m off. A new project is in the works. It’s going to do a few things for me, mainly keeping me fresh on ruby/rails, especially when I start the frontend program and begin learning another new language. Its also going to be a much different structure from the Bloc.io projects, so it will keep me on my toes and have me asking new questions. There is also a lot of room for growth, so I can keep expanding it as my skills increase. I’ve been thinking about this project for some time and I’m pretty excited to get working on it.

Weeks 20 – 25

160718 – 160828 — Total classroom hours 10/week(ish)

Well, that was a slippery slope! Five weeks without a post, not sure how that happened, but it did. Let’s see, what’s new? I have a new mentor until roughly the end of the backend program, I’m still fine tuning the projects that are up on Heroku, I have a snazzy new resume, and I’m actively looking for an internship/apprenticeship position. I think those are the highlights, I’m sure Im forgetting something…

Firstly, the projects. Im coming to realize that it’s really hard to call something ‘done’. Although I was technically done with the projects weeks ago, and pushed them up to Heroku, they were still needed some polishing before they were ready to present. I spent probably about 3 hours on each of the projects getting the frontend styling decent enough to be presentable. There’s not a lot of uniqueness to them, but their databases work -for the most part- and that’s what counts. I hesitate to say that the databases completely work because I’m still finding bugs, mostly in the push from local host to Heroku. One particular glitch I have yet to tackle is getting the Stripe keys onto Heroku site. I cant imagine its that hard, just haven’t gotten to it yet.

I now have a different mentor. The mentor I’d been working with for this course is having a baby and is taking paternity leave, so I’ve been assigned to another programming expert. Initially I was a bit disappointed with the change, only because I am so close (2 weeks as of this post) to finishing the program. But I do think that paternity and maternity leave is super important so I just rolled with it and I am super pleased with my interim mentor.

One area I have been working a lot on recently is my LinkedIn profile and resume. I went to a meetup a few weeks ago and was told by the hiring staff of a Denver startup that he doesn’t even look at a resume if it doesn’t have some kind of graphic design element to it. It makes sense, but I hadn’t really given it much thought up until hearing that. I also figure that making my resume look interesting can only help, whereas if I were just to leave it as a plain text document it could definitely make me seem less desirable. Luckily I did spend 4 years at an art school, so I have some design experience. It definitely took some time, but I am super proud of how it turned out and am eager to show it to anyone who inquires.

That leads into my last highlight from the last few weeks, I’m looking for work! I was happy with my work on the Bloc projects, and felt really good about my ability to complete assigned stories with the group project. I feel that I have strong enough skills to be useful to a consultancy or startup as long as they are willing to provide some kind of mentorship capabilities. I mean, it can’t hurt, worst case scenario I get turned away because I don’t have enough experience, but that won’t be the case for long, and I’ll just get in touch with them again. At the very least I’ll be able to start honing my interview skills, and that in itself is reason enough to put the effort into contacting companies.

I don’t intend to let this much time lapse between posts again. It’s kind of a weird spot to be in, with all the the coursework technically completed weeks ago, and nothing really pressing that needs to get done. Like I said, I’ve been fine tuning the projects and making sure my resume and online presence is legit, but that’s not super intense work. I also realized that I needed to brush up on my pure Ruby skills, so I’ve been doing that with codewars and exercim.io. But, again, that only takes so much time, and I do get a little burned out doing challenges for the sake of doing challenges. I am looking forward to starting the frontend program and having established checkpoints to accomplish.

Weeks 18 & 19

160704 – 160717 — Total classroom hours 20(ish)

I missed another week, but it’s 19 weeks in and the blog is pretty up to date, so I’m not sweating it. Still pushing along at a steady pace, with two projects in the works simultaneously. Talk about time management… Not only am I trying to make noticeable progress between mentor meetings (twice a week now), but I’m also trying to make headway with the non-school project that I’ve been invited into.

Besides not having enough time in the day, things are going pretty well. The Blocipedia project is complete! It was by no means a cakewalk, but I felt pretty good about the code I was producing. The one major hangup I encountered was with a collaborator model. Even as I write this I’m still not sure why I wasn’t able to wrap my head around it on my own. There was just something about a model that existed for the sole purpose of connecting other models that just threw me. I will say that I was definitely over complicating the process, and my mentor did a great job of correcting that with me.

But it’s done! Which means that my two curriculum-required projects have been completed! And, with ~10 weeks left in this part of the program, I’ve still got some time to dig even deeper. Let me say that when I refer to my projects as ‘completed’ I mean that all the data and views function properly. As far as the front-end design goes, its, um… rough. But, my focus is the backend at this point, and I do have time to show the front end some love, when the timing is appropriate. Also, as of last weekend, both projects are up on Heroku, functioning live, with legitimate user-emailing functionality.

I wasn’t necessarily looking forward to the Heroku push or the email changeover, but it actually went pretty smooth. I used Sendgrid to handle the emailing. After some trial and error (which is a pretty tedious process when working locally, committing, merging, and pushing master to Heroku) I found that setting up a Sendgrid Add-on was the most efficient way to go. I used this Sendgrid article to help with the process. I also used this blog post to help fill in the gaps a bit. The one caveat is that the ‘sent from’ email is a random string, so it doesn’t look super professional if trying to show off a functioning site. I’m confident I could change that when I find the time to do so (it’s pretty low on the list at the moment).

So that was school, now the other half of my workload, the collab project. To be honest I find myself thinking about this project most of the time. I don’t know if its because I’m basically done with the school work and the fine tuning minutia of it doesn’t seem as appealing as a whole new project, or if I’m just more excited to work on a team project. I will say that creating code that I know someone is going to go over with a fine tooth comb makes me code better. I’m sure I’ve mentioned this before, but it’s also forcing me to not only write tests, but write solid tests. Some of the spec code is borrowed from the coursework Blocitoff project, but tests are tests, and I don’t see any reason to try and reinvent the wheel.

I’m learning a lot about the industry standards for programmers. I’m almost certain that there is not one ‘holy grail’ of programming standards. It makes sense that there are slight differences in practices based on regions or other factors. I’ve already come across a few things with this collab project in terms of standards that are different than what I’ve learned with Bloc. That’s not to say that one is right and the other wrong, but I appreciate that I’m now aware of  both ways and because of that I am a better programmer overall.

Week 17

160627 – 160703 — Total classroom hours 14.5

Things are really picking up! Not only am I on the cusp of finishing my second Bloc project, I have officially started a collaborative project with my friend (and unofficial mentor) Corey. Its not that I didn’t think school was enough of a challenge, but Corey approached me with an idea and offered to use it as a learning experience for me, which is something I couldn’t turn down. I’m always actively seeking out opportunities to work with other people in any way. Its a point that I keep coming back to, and its not something unique to Bloc, but I think an inherent dilemma with online schooling in that there isn’t a whole lot of collaboration outside of you and your mentor. Don’t get me wrong, working with my mentor has been an awesome experience, but theres also something to be said about collaborating with your peers on a project.

I’ve only been working on this project with Corey for a week and theres so many valuable nuggets that I’ve picked up. On the workflow end, I had never dealt with working on someone else’s Github repo. Theres a bit of pressure when setting up your local repo to communicate properly with another persons Gitub repo, the entire time I felt like I was one wrong keystroke from wiping it all off the map. After I got that all setup correctly Corey set me up with parameters for commit messages. Im a stickler for detail and continuity, so the idea of having a template for commit messages was something I was fully onboard with. It creates uniformity across commits, allowing anyone who looks at the commit history to easily see what was changed or added. Changing the default commit message template is relatively easy, and this article helped me a lot.

Arguably the most valuable aspect of this collaborative project (I keep calling it collaborative, but in actuality almost all projects involve more than one person, so I should probably just be calling this a ‘project’) is that I will have my code reviewed by another experienced programmer. Once again, I have nothing but great things to say about my mentor, but with just about any learning process its not a bad idea to get the views and opinions of more than one professional. I am definitely paying closer attention to the details of my code, making sure its as close to perfect as I can write. And testing, oh man, the testing. One goal of my current Bloc project was to keep my testing current with my code, and I admittedly fell behind pretty quickly. With this project I am being forced to write tests before my pull requests will be merged, so I have no choice but to write TDD code by the books.
Less than a week in Im already feeling a bit more pressured now that I have two irons in the fire, but I’m ok with that, its a good pressure, and to me it means I’m heading in the right direction. During my mentor meeting we decided to move me from the 72 week timeline to the 36 week to finish out the Ruby course more quickly. This means that I will finish this half of the schooling almost two months earlier, and in the meantime will have two mentor meetings per week instead of the one. I wasn’t as concerned with moving up the finish date, As I knew I was on track to finish early regardless. But I was finding myself getting hung up a few days after my mentor meeting and then basically grinding my wheels for three to four days until I could speak to him again. My school work schedule didn’t help this scenario, in that most of my work has been getting done between Friday PM and Monday AM, and (rightfully so) my mentor tends to take the weekends off. But now I have two opportunities to speak to him, so hopefully my multi-day grinding sessions have come to an end.