I learned something from the Gilded Rose kata. It turns out it was significantly easier and less time consuming to just drop a couple more if statements into the already giant mess of if statements. With this approach I was done in under two minutes with all tests passing, whereas before it took me over an hour to properly refactor everything (compounded by not being able to touch the item class).

At first, I thought to myself, “Wow, this kata sends entirely the wrong message.” It seemed to illustrate that making the ‘wrong’ decisions saves a huge amount of time and effort. As I thought about it more, though, I realized that’s exactly what working on real code is like. It can be very tempting to make ‘wrong’ changes that work because they’re easier at the time. This is the way that code decays and eventually becomes unmaintainable. Developers make instant gratification choices with their code to get one piece working without thinking about the future.

If you’re working on a project that will never be changed again, and does not need maintenance (such as this kata), then the easy approach may be okay. If, however, this project will need new features and need to be updated and maintained, it is better to take the proper approach. What may take you an extra hour today could potentially save days or weeks worth of work in the future.

This is the thought that developers need to keep in mind while working on their code. Best practices are considered as such because they are what makes code readable and easy to work with. However it’s important to find the balance between refactoring and implementing new features. If you endlessly refactor and try to get the code perfect, you’ll never be able to add new features. On the other hand, if you just hack in new code and never think about how it should fit into the larger application, you’ll soon end up with an unmanageable mess of code where every small change breaks several other pieces. So, like many other aspects of our lives, this principle relies on finding balance.

This just goes to show that although you can learn a lot by trying out new tech, using new gems, or tackling problems you’ve never seen before, there are also subtle but profound lessons to be learned from things that you already know how to do.

So, each entry into this post will follow this format:

• Date
• What did you learn yesterday?
• What are you going to do today?
• What do you expect to learn?

Each entry should be relatively short, but important topics may expand out into their own posts. We’ll see.

January 27, 2016

What did you learn yesterday?

Yesterday, I did the Gilded Rose kata. I got some great experience in refactoring code that isn’t structured well, and learned some about how much easier it is to add features into a program once it broken down into easy to understand parts. I got a little more familiar with collection_select fields as well.

What are you going to do today?

Today, I’m going to try my hand at the Gilded Rose kata without refactoring the original code. I’m curious to see how much effort it takes. I’m assuming it will make the jumble of if statements even more complicated and harder to maintain.

After that, I’ll be working on the Rails Bookstore app. I’ve got the books model and controller in place, and the books are sortable by any field on the index (although it’s currently not done the best way). I’ll likely implement user/admin accounts today as well.

What do you expect to learn?

I’ll be using devise to handle the user/admin accounts. I’m expecting to learn how to properly manage the different account types and control their access to different parts of the site.

January 26, 2016

What did you learn yesterday?

Yesterday, I learned about iTerm2 and zsh. I had heard of them previously, but had not used them. I’m now running oh-my-zsh with the candy theme. I’m probably not using all of its potential yet, but it is nice to have branch and ruby information right in my prompt.

I also spent some time at the end of the day yesterday writing controller tests for the ToDo API. From that, I learned testing JSON is tedious. It’s easy to have tiny discrepancies that cause the tests to fail. Like most things, I’m sure it’ll get easier with time, but not quite yet.

What are you going to do today?

Today, I’m finishing up tests for the ToDo API. I’ll likely be starting on the Rails Bookstore, which is the last major project of the apprenticeship. I expect that to take some time, so that’s likely what I’ll be doing for the next several days.

What do you expect to learn?

I expect to learn some more about testing JSON and an API in general.

January 25, 2016

What did you learn yesterday?

These are always the worst to write on Monday. Friday, I learned a bit more about the proper place to put new actions and that it’s okay to make an extra controller with only a couple actions for the sake of organization.

What are you going to do today?

Today I’m finishing with the Twitter clone. (How many times have I told myself this already?) Anyway, I just need to finish refactoring to better, more RESTful routes. After that, I’ll be working some more on the Rails Refactor project, and possibly on the Rails To-Do API as well.

What do you expect to learn?

I’m expecting to learn more about getting data to views without violating mvc flow and also without having several instance variables in the controller. (Sandi Metz says more than 1 is too many.)

January 22, 2016

What did you learn yesterday?

Yesterday I learned about decorators and Draper. Essentially, decorators allow you to clean up your views by removing logic from them without cluttering up your model with methods that just format output. Since those methods don’t really fit in either place, Draper provides a wrapper class to the model that is called by appending .decorate on the end of instance variable assignments. e.g. @user = User.find(params[:id]).decorate. Very cool.

What are you going to do today?

I need to get in the habit of writing these posts earlier. Today I have worked on getting a bio and picture ready for smashingboxes.com. I spent some time this morning trying to think of a better way to make the roman numerals kata, but beyond moving the conversion hash into an instance variable, I came up short. This afternoon, I’ll be working on the API for the todo app and pairing with Annie on a project.

What do you expect to learn?

It’s been a little bit since I built an api, so I expect to get a refresher on jBuilder. I’ll likely also learn about writing integration tests for api’s. I don’t know what Annie and I will be working on, but whatever it is, I’m sure I’ll gain some valuable knowledge from her as well.

January 21, 2016

What did you learn yesterday?

Yesterday, I spent some time working in vim. I used it for my morning kata, and also for editing the nginx config file on Digital Ocean. I feel slightly more comfortable with it. I’ve gone from not being able to edit text at all with it and desperately typing :q every time I open it, to being able to write what I need at painfully slow speeds. That’s an improvement, right? I learned a bit about nginx itself. The ssh portion was familiar, but editing the nginx config file was new to me.

What are you going to do today?

Today, I’m working on getting my environment set up to run the ember portion of the to-do app. Assuming that goes well, I’ll likely start building the API for it today. I believe I have some code review comments to address for the Twitter clone, so I’ll also need to incorporate any recommended changes into that.

What do you expect to learn?

I’m going to do my katas in vim from here on out, so I’ll get more practice with that. Yesterday ended with npm vanishing as a command in my terminal, so perhaps I’ll figure out why that happened. I’m sure there are nuances of code development that I’ll learn today as well. It seems like every day I learn at least a few new things that I could not have predicted in this blog.

January 20, 2016

What did you learn yesterday?

As I mentioned yesterday, I learned quite a bit about tests and fixtures. I’ve gotten a bit better with integration tests. I went from feeling like I was just getting tests to run and pass through shear luck to feeling like I am ready to work on improving my test writing style to better meet best practices at SB.

What are you going to do today?

Today, I’m going to set up the nginx server on Digital Ocean. This needs to be done using vim, so in preparation for that, I wrote my code kata entirely in vim this morning. Using vim at the moment sort of feels like trying to run a marathon with my legs on backwards. I can see where I need to go, but getting there is slow and cumbersome.

What do you expect to learn?

I expect to learn some about containers, ssh, vim, and setting up a web server. So, it seems like today will be a lot of devops type of work. While some developers shy away from things that aren’t strictly development, I think it’s important to understand the whole environment I’m working in. I don’t think I need to master every aspect right away, but at the very least nothing should feel like it’s just done by magic.

January 19, 2016

What did you learn yesterday?

I learned the basics of Cucumber. I like the feature files, and the steps aren’t all that hard to write either. I got follower functionality up and running yesterday, but I feel like I understand only about 80% of it. I should be able to use what I’ve learned to get the ability to favorite posts up today.

What are you going to do today?

I’m going to write more comprehensive tests, primarily model tests, but also more integration tests since I no longer hate them. Annie helped me understand how Cucumber, rspec, and FactoryGirl all work together. Test writing can be time consuming, but I know how important they are, so I’m determined to get good at writing them. I should be able to finish the Twitter clone project today.

What do you expect to learn?

I expect to learn more about testing best practices. My talk with Annie this morning helped me to understand all the different pieces of the tests. Tomorrow I plan to start on the task of setting up nginx on Deep Ocean, so I’m sure I’ll learn a lot about that tomorrow.

January 18, 2016

What did you learn yesterday?

I’ve gotten a bit more comfortable with Devise and how to modify its generated structures. I’m gettting familiar with rspec syntax.

What are you going to do today?

This morning I started working with Cucumber. Annie showed me how to write integration tests with it, and it’s already much better than minitest. I’m going to work on getting my pull requests merged into master and I should finally get started on the follower functionality. I will also add more integration tests to make sure that everything I’ve written thus far continues to work.

What do you expect to learn?

I expect to learn a lot about proper testing. It (understandably) seems that testing is very important here, and while I can write tests and make them pass, there seems to be a long way to go before I have proper DRY and comprehensive test suites.

January 15, 2016

What did you learn yesterday?

Today is day 3 of my Smashing Boxes adventure. Day 1 was orientation, meeting with the teams, awesome lunch at Dashi, overall just getting situated. Yesterday was when I first started doing work. My first project is to build a Twitter clone. What makes this more challenging for me is that I must use Devise for authentication and rspec for testing. I’m getting a handle on rspec. It’s pretty straight forward, it’s just a matter of learning the syntax differences between it and minitest. I spent a lot of time looking over the Devise docs. It’s easy enough to generate a user model and get a working authentication system in, but everything feels hidden away, so customization has been tricky.

tl;dr: I learned a lot about Devise and rspec.

What are you going to do today?

So this entry is being done a little late today, so I’ve already been working on some things. I got a test that I was struggling with yesterday (Putting to the update action within the Devise User Registration Controller) working. I updated my branch to meet the criteria my awesome mentor Annie (Hi Annie!) put forth for me. This afternoon I will work on putting together the user profile page, and if I have time start working on follower/following capabilities.

tl;dr Keep working on my Twitter clone

What do you expect to learn?

I expect to continue gaining experience with rspec and Devise. I’m working on my ability to not just produce working code now, but code that is good as well.

tl;dr It’s 2 sentences. Just read it.

Quick disclaimer: Some of the advice in this post can have potentially negative effects on your device like voiding your warranty or bricking your device. Ultimately it’s your decision what you do with your phone, and I am not responsible for those decisions or the results thereof.

So, TowelRoot says your phone isn’t supported and/or you’ve confirmed your software version is VS450PP2. Abandon all hope, ye who enter here. Actually, the process isn’t all that bad. It took me a few hours the first time to research everything and get it all working, but now that the process is in place, I can take a new phone, flash its software, and have it rooted in about 10 minutes. I’ll give you an overview of the necessary steps, then go through each one in detail. You will need a Windows box (physical or virtual, it shouldn’t matter) and a USB cable (which comes with the phone).

To flash the old software, you must:

1. Get the necessary software on your PC
2. Put the Exceed 2 in download mode
3. Run the flash tool.
4. Reboot the phone and reap the benefits of a rootable device.

That’s it. 4 steps. My coffee takes more than 4 steps to prepare, so flashing shouldn’t be any trouble at all. Let’s get started.

1. Get the necessary software on your PC

You will need:

• The LG Driver
• The LG Flash Tool 2014
• The VS450PP1 KDZ file
• The Visual C++ Runtime Library (only if you have problems running the LG Flash Tool 2014)

Install the LG drivers and make sure the LG Flash Tool runs for you. Also, this is IMPORTANT, put the KDZ file in the same folder as LGFlashTool2014.exe. Not doing so can cause problems with flashing, and you don’t want that.

This is worth saying again. Put the KDZ file in the same folder as LGFlashTool2014.exe! Right now!

2. Put the Exceed 2 in download mode

To do this, first shut down the phone. Plug your USB cable into your PC. While the phone is off, hold the volume up button and plug the other end of the USB cable into your phone. Keep holding the volume up button until the phone is in download mode. You do NOT need to press any other buttons for this to happen. Step 2 complete.

3. Run the flash tool

When the software first loads you’ll be presented with this window.

You don’t need to change anything here. Just click the folder icon and select your KDZ file (remember, it’s in the same folder as LGFlashTool2014.exe). Once you do that, the window should look like this:

Once everything is good, click on CSE Flash. Normal flash does not wipe the phone, and can cause problems like endless boot loops. Don’t use it.

On the next screen, click start. Don’t click on anything else. Just Start. A Select Country & Language window will appear. Just click OK. I know it has information about Korea filled in. Don’t worry about any of it. The app will default to doing everything in English.

Finally, the LG Mobile Support Tool will appear. It may warn you about not being able to connect to the server. Just click OK and keep an eye on your phone. You will see the progress bar fill as the software installs. The phone will automatically restart once the install finishes. With any luck, it will boot back to the Verizon setup wizard. The phone will reboot once more after being at this screen for a few seconds. When it’s done booting again, feel free to bypass the screen using the super secret combination.

Go ahead and check your software version. It should now read VS450PP1. Congrats, you did it! The phone is now ready to be rooted.

Quick disclaimer: Some of the advice in this post can have potentially negative effects on your device like voiding your warranty or bricking your device. Ultimately it’s your decision what you do with your phone, and I am not responsible for those decisions or the results thereof.

The LG Optimus Exceed 2 is a pretty decent prepaid phone running Android 4.4.2 KitKat. Amazon recently had these available for $11.99, which is dirt cheap. I managed to get my hands on 4 before they ran out of stock. It took some time to get things up and running properly on them, and I wanted to share my experiences (as well as make some notes for myself) on how to gain complete control over these devices.

Bypass Verizon Setup Wizard

Once you turn on your new phone, you’ll be greeted with this seemingly inescapable screen. Since we won’t be needing Verizon’s services, let’s just go ahead and use the built in button combination to bypass this screen.

Press the following buttons one at a time in this order:

• Volume Up
• Volume Down
• Back
• Home

You should then get a popup window asking if you want to leave setup. Don’t worry if it doesn’t work the first time. The timing has to be just right. Too fast or too slow, and you won’t get the popup. Just keep trying until it shows up. Don’t worry, once bypassed, the setup wizard will no longer run on startup.

Root using TowelRoot

TowelRoot is incredibly simple to use as long as you have the correct version of software running on the phone. To check your software version, go to Menu -> Settings -> About Phone -> Software information. On the bottom of this screen, under Software version, the phone should report VS450PP1.

If it says VS450PP2, you will need to flash the phone to version 1 before TowelRoot will work.

Once you’ve confirmed the software version, there’s one more preparation step before installing. You need to enable the installation of apps from unknown sources. To do this, go to Menu -> Settings -> Security -> Unknown Sources. Make sure this box is checked, read the warning (or not), and tap OK.

Now that all of that is taken care of, go ahead and open a browser and head over to towelroot.com. Click on the giant lamba in the center of the screen, ignore the security warning, and tr.apk will be downloaded to the phone.

Run the apk, install the app, and click open when done. You will be presented with this screen:

Go ahead and click make it ra1n. You should get the message informing you that your phone has been rooted and no reboot is required.

Congratulations, you have root! There’s only one more step to control which apps have root access. If the phone reboots, just run the app and try again. 2 of my phones failed and restarted, but everything went smoothly when I tried again. Technology, amiright?

If it says your phone is not currently supported, then you likely have the version 2 software I mentioned above. Follow the instructions to flash the older version then retry the steps in this section.

Finally, you need an app to manage root privileges for other apps. Go ahead to the Play Store and download SuperSU. Install it and update the binary if necessary. The app may ask you to reboot. That’s it. Your phone is fully rooted. Hurray!

These experiences come from my time at The Iron Yard. We just wrapped up week 6 (of 12) and I thought now would be a good time to talk about what you should know before diving in.

1. They take a lot of time

So, you want to go from 0 to dev in 12 weeks? Well, you don’t get there without practice. A lot of practice. Over the course of 12 weeks, your practice time should be somewhere to the tune of 700+ hours. A typical week is about 60 hours, but depending on the project, some may be longer. I wake up between 6:00 and 6:30 every morning, and I’m out of the house by 7:30 at the latest. Our day runs from 9-5, including lecture and lab time. I typically get home sometime between 6:00 and 8:00, but have been there as late as midnight. If you did the math, that’s a minimum of 11.5 hours between when I leave and when I get home. On top of that, most nights I have code to finish, which can take a few more hours. Some require more time than this.

You will not be able to hold down a job while you’re attending. It may seem tempting, but it’s just not going to happen. Even if you’re super awesome and can do everything, trying to split your time between the camp and your job will be absolutely detrimental to your learning. Beyond that, there are events to attend, including meetups, job fairs, field trips to local companies, etc. Before you decide to enroll in a code boot camp, you need to decide if you can be fully committed to your learning. If you decide that’s what you want, then you need to tell your s/o, your friends, your family, your dog, and everyone else you know that you will be completely unavailable while you attend.

2. Meet the instructor ahead of time

This one is pretty important. You will not get much from the course if your instructor’s teaching style doesn’t match your own learning style. Just because someone is well qualified in a field does not mean that they are good at teaching. My instructor is awesome at explaining difficult concepts and explaining what works where and why. As a result, I have learned a ton from him, but things could have very easily gone the other way. I met him briefly once during my technical interview, but looking back now it probably would have been a good idea to sit and ask him about his teaching methods ahead of time.

So, how do you meet up ahead of time? The simple solution: ask. Contact the school and tell them you are interested in joining. Tell them you’d like to get a feel for the instructor’s personality and teaching style. My school happens to offer free crash courses on occasion, so if the school you’re looking at offers the same, sign up for one. It’s much better to find these things out in advance before you’ve committed your time and money.

3. Having some programming experience is a BIG help

Yes, many schools will tell you that you can start with no programming experience and be a junior dev in 3 months. While that may be possible, it will be significantly easier if you have some programming experience under your belt. If you’ve never touched code before, then something like Codecademy can be a great start. Be forewarned, though, that it’s easy to get overly confident while working on a site like that because they do so much hand-holding. Once you’ve completed a track, move onto something a little more challenging. Some of the most important concepts to understand are:

• Control flow
• Defining and writing methods
• Common data structures (e.g. arrays, hashes)
• Classes and instances of classes
• Objects
• Git basics

This list is not comprehensive, but should give you a big head start. We covered everything above in the first two weeks. Also, depending on the school and the course you’re taking, you may need a Macbook. This can be an unexpected expense, and if you’re not familiar with OS X or terminal, then getting the basics down can also be a big help.

4. You can learn it all online for free (but you probably shouldn’t)

So, there are many factors that go into this. There are people out there who have taught themselves to code in a few months using only online resources and books. Hats off to them. Seriously.

That being said, there are many places that things can go wrong with trying to learn on your own. The first is that once you move past being a complete novice, the learning resources start to dwindle. There are a ton of sites that will teach you how to set a variable and write your first loop. There are far fewer who will guide you through the process of understanding the benefits of writing a recursive function or how to set up advanced database associations.

Beyond that, one of the biggest challenges is knowing what to learn. Programming isn’t a single career, it’s an entire industry. Do you want to develop web apps, mobile apps, games, hardware drivers, enterprise applications, security applications? What language should you start with, C++, Java, Python, Ruby, Javascript, C#, the .NET stack? What framework should you learn, Angular, Rails, Django? Front end, back end, big data? There is so much information out there, that it’s very easy to spend years reading this and that but never really improve your odds of getting hired (Ask me how I know!).

Finally, having an instructor and a team to work with are vital to learning correctly. Sure, I don’t have to go to the gym to work out, and I could certainly lift weights without a trainer. I could also really hurt myself by using bad form. Luckily code is a little more forgiving in that it won’t physically hurt you to use bad form, but bad coding habits can be detrimental to your software, and especially to others who try to collaborate with you. Prospective employers may not like it very much, and nearly every coding job in existence will require you to work on others code and require others to work with your code.

5. Boot camps are not the same as a CS degree (and that’s okay!)

I attended a traditional 4-year university and majored in computer science. I quit after year 3 due to a number of circumstances at the time. By this point, I could write code, but the program focused much more heavily on theory and low-level topics like circuit design, detailed coverage of networking principles, and number systems like binary, octal, and hexadecimal.

While all of these are great to know and give you a better understanding of the work you’re doing, they are not completely vital to building a web app. In all the time I spent in college, I never once used git. Those of you new to code are wondering why that’s a big deal, while the experienced devs are crying. If you don’t already know, git is a form of version control software that nearly all devs use every day.

Code boot camps are focused much more on practical skills that will be used in your day-to-day work. Since the time they have to teach is so short, everything that isn’t completely vital is cut from the curriculum. All programming is learned over a lifetime, so you’ll have plenty of time to learn the rest.

Regardless of where you’re coming from, employers know that junior developers are still going to need a lot of hand-holding. To them, the most important quality in an applicant is a passion to learn more. You may not be able to land that awesome gig at Google straight out of code boot camp, but if you’re in an area with a decent tech scene, you shouldn’t have much trouble finding someone to take you in.

6. It’s all about making connections

This is an important bit that not everyone seems to get. Many believe (and I used to be one of them) that coding skill alone will determine what type of job you get. Well, the reality is that you can be the best coder in the world, but if no one knows who you are, you’re probably not going to land those high-paying awesome jobs. I heard recently on a podcast that somewhere near 80% of jobs are fulfilled through some type of personal recommendation. If you’ve ever been on a job site and came back to an empty inbox after sending out 40+ applications, that’s why.

The Iron Yard has been a great asset in connecting me to businesses, people, and events that I didn’t even know existed near me. I’ve had the opportunity to speak with board members of multi-million dollar companies, I’ve met a ton of students who share the same passion for coding as me. Even if I had taught myself to code, getting in touch with all of these people would still have been another hurdle on my way to employment.

That being said, you need to make these connections. If you enroll in a code camp, be sure to go to every event you possibly can. It’s tough. Time suddenly becomes very precious, and many of us are nervous talking to new people in large group settings. You really need to set that discomfort aside. Deciding to opt out of an event can cost you thousands of dollars in potential pay. How many thousands are you willing to give up for the sake of avoiding a couple hours outside of your comfort zone?

Whew! If you made it this far, thanks for reading!

This post turned out much longer than I anticipated. Code boot camps can be a big investment in both time and money, so there’s a lot to know before you decide to invest. I hope this covers a good chunk of it, though. If there’s anything else you’d like me to cover, please leave a comment below.