Tips as we head into the 2nd half of our first cohort!
This post was written by Katlyn Whittenburg, the Campus Director in Austin. Follow her on Twitter and check out her bio!
Our students have been kicking ass all day, and I’m super proud and impressed. It’s insane to me that we have reached the halfway point for our Front End and Rails classes. Whaaaat??? To celebrate, this Friday we are having a special Iron Pints. I’ll make sure I post pictures of the event next week. Expect some craziness.
So, for this post I just wanted to give some pointers to you coders/aspiring coders out there. Coding, as fun and rewarding as it can be, it can also suck the life out of you if you don’t take breaks. Staring at a computer screen for hours at a time and trying desperately to fix some broken code can make you question some things. But that’s only if you don’t understand how to handle being stuck. While it’s important to persist and keep trying as you reach an obstacle, it’s just as valuable to stop trying. Quit. That’s right, quit. Okay… don’t quit in the forever sense. Quit in the temporary sense. Better yet, quit trying in the way you are trying. If it’s clearly not working, it’s time to change it up. And sometimes you need to clear your mind. Reboot, so to speak. Here are some great ways to do that:
Take a nap! Napping ain’t just for babies, people! (Sorry I said “ain’t”.) A power nap can change your day. You will be refreshed, more optimistic and more level headed.
Dance! No, but for real. Do something that gets you moving. You can go on a walk or a jog. You can go to the gym, if that’s your thing. I prefer spurts of embarrassing dance moves. It gets my blood pumping and provides onlookers with entertainment. It’s good for everyone!
Do something creative! Paint! Write a poem! Even if you’re a terrible artist, do something to work that other side of your brain. A great programmer looks at problems creatively so don’t neglect your creative side!
And then get back to it! Don’t give up on yourself. Even though the problem may seem insurmountable, you can do this! If you're a beginner, the only way to move past the beginner phase is to just keep at it. Great programmers practice and fail a lot. Each failure brings you that much closer to a great success.
This post was written by Justin Herrick, Austin's Ruby on Rails Instructor. View his profile on The Iron Yard's website and follow him on Twitter!
As developers, we use a lot of tools. Software tools, programs we run to aid is in writing programs. We even use tools to build our tools. To a developer, writing code becomes just another problem that a tool can help solve, so they will write the tools to make code easier. For any task you are looking to do in software development, rest assured there is a tool out there (trying) to make it better.
However, tools come at a cost. Every tool needs to be learned and many tools take time to master. At a certain point, it becomes more work to figure out the tool to solve the task than it is to just solve the task. This ‘learning cost’ exists for everyone on the team for the remainder of the project, so adopting the newest untested tool will need to be careful considered first.
One, sometimes overlooked, benefit of tools is their ability to aid the learning process of a larger system or project. I like to think of these as ‘tools you grow out of’. They are the tools that help you get your feet in a new project. They will help you make progress and feel productive, and subtly, you will begin to learn what needs to be done. Eventually, the learning will end, and the once amazing jump in productivity is replaced by the annoyance of having to customize and repeat effort on each new project. This is the period of time when you realize you have grown out of that tool and need to stop using it.
Many people in this period decide to write about how awful the tool is and elaborate on how unneeded it really is. Most of the time these complaints come without the acknowledgement that a tool you no longer need is not a bad tool. It is just not for you anymore.
For every tool you find you will grow out of, there is another tool you will have to grow in to. These are tools you are meant to master over time. For a developer, these are typically your programming language of choice and your editor. Every language and every editor will have its own learning curve and a depth to its mastery, but knowing this curve exists is the real first step.
My editor of choice is VIM. VIM is notoriously difficult for beginners, and in a lot of ways is a bad way to learn other things. I routinely recommend to friends and students that they only begin the process of learning vim when they have nothing else on their plate. Still the road to mastery is a long one and it took me years to feel comfortable and proficient in VIM.
There is a sense of accomplishment that comes from growing out and beyond a tool. Realizing you are now more proficient that this tool that helped you get started. There is a sense of pride that comes with the mastery of a tool. Either the editor that fits you and your personality like a glove or the language where you know exactly what method to call.
I challenge you to look critically at all your current tools, which of these are mastery tools, and which are tools to grow out of? Invest in those you seek to master and learn all you can from the others.
This post was written by Daniel St. Clair, a current student at The Iron Yard's Front End Engineering course in Austin. This was originally posted on his student blog.
This post comes a little late but you’ll understand why as you read on…..
For those who still haven’t heard of this amazing place (The Iron Yard), it’s a learning institution that offers 12 week intensive courses in different aspects of web development. The school promises to turn it’s graduates into a junior-level programmer by the end of that time with lots of career support to boot. To be honest, when I first visited their site a while back ago, I thought it was bologna. How can anybody learn enough to be able to completely change careers in that short amount of time, especially one as vast and complex as software or web development? Regardless, my curiosity was peaked, so into google I went. I found out that the Iron Yard originally started as a startup accelerator and quickly began offering classes for kids. Shortly after, they expanded into a full fledged academy for adults where the courses were short but course load very intense.
Fast forward to now…
I don’t think I’ve ever been tested like this mentally. In the last four weeks we’ve covered html, CSS, Sass, JavaScript, jQuery, Bower, Yeoman, Ajax, Bootstrap and have started week five off with Backbone.js…it’s a lot like drinking water from a firehose. Here’s an example: Our first day seemed okay- building colored blocks with html and css and placing them using different ways such as floats. Not bad, right? Our second day we had to rebuild an entire responsive site to specs with all breakpoints. Yeah.
This last weekend we had to build a chat room. Each of us paired up with a member of the Rails class and they built out the API while we (front-enders) built out the front. Up until this point we’ve only had projects for ourselves. Sure, we all help each other out and talk our code out loud to each other like crazy people, I mean, professionals, but we haven’t actually relied on another person for our assignments and what a learning experience:
The easy: I got along swimmingly with my partner and we were both very clear in communicating what we needed at any point in time as well as what we were working on at the time and what the challenges were.
The difficult: I learned that the beginning of a problem can sometimes start with underestimating your task. For example, I originally thought that only building out the message and user name in the API would be alright and I could hack away the timestamps. This resulted in a few hours of wasted work as I was only getting the current date and time as opposed to when the messages were actually created. As soon as we built the created_at feature in the API, the timestamps were a breeze.
Considering that we learned about ajax calls only a few days earlier and had four days to build an entire working application, I’d say it went great. This is a general example of the speed of things and why the last month has just flown by. Today our instructor had us refactor one of our old projects using backbone, a framework we started covering today. Tomorrow? Who knows. Probably rebuild Facebook in a day.
This post was written by Nathan Hall, our Ruby on Rails TA. Check him out on LinkedIn!
We ended the last lecture with our all_prime_numbers method not working for a lot of big numbers because it took waaaaaay too long. We could not even do prime_upto(1000000) at first, until we changed is_prime? to only check up to the square_root of the number being examined.
When we changed it, how much faster did it run? prime_upto(100000) went from 33seconds, which is crazy slow, to less than half a second! Imagine if your website had a method that took 33 seconds before the page loaded. Oh, the depravity!!! This leads us to an important concept in computer science. which was affectionately termed (and stolen from Mathematics) Big O. This is used a lot in interviews as a quick screen to see if a candidate has an idea what they are talking about. Well, then what the hell is Big O?
If you go to the wikipedia page, it will look like a ton of gibberish (or maybe not, I’m just not particularly adept at discerning the meaning of mathematical equations). But, for computer science purposes, it is one overarching question.
Worst case scenario, how long will this function take?
That’s it. That is what we want to know. Because if we have a worst_case scenario that a function will take 33 seconds, I sure as hell won’t be going back to the site. So how do we determine the Big O, and what does it mean?
Let’s start with a few, simple examples.
1. O(1) - Constant Time
O(1) means, no matter what the size of the inputs, the function will always take the same amount of time. Let’s set our input value
array1 = (1..100).to_a`
array2 = (1..100000).to_a`
Ok, now let’s write a method that’s constant time. I want to check and see if the first item in any input is “#IVENEVERGIVENABIGO”.
<code>
def constant_time(input)
if input[0] == “#IVENEVERGIVENABIGO"
true
else
false
end
end
</code>
If we run, `constant_time(array1)` or `constant_time(array2)`, it will take the same amount of time. Even if we made an array with 23479857428584924524353252523 elements, it will still take the same amount of time to run our function, because it only cares about the very first element in the array. Therefore, it is Constant Time, pro O(1).
2. O(N) - Linear Time
O(N) means the time it takes the function to run grows at the same rate that the size of the input grows. So if you give it a larger input, and then a larger input, the function’s runtime grows linearly. Let’s make a method that checks to see if an element is inside an array, and if it is, return where it is.
<code>
def linear_time(input, value)
value_location = "I'm not here"
input.each_with_index do |element_in_input, index|
if element_in_input == value.to_i
value_location = "I'm at position #{index}"
end
end
puts value_location
end
</code
This function will loop through every item in the input array, and if it is in there, will tell you exactly where it is. It makes sense that the larger the input is, the longer it will take to run, because it has to go through all the elements once. So if you run `linear_time(array1, “#IVENEVERGIVENABIGO”)`, it will take longer than `linear_time(array1, “#IVENEVERGIVENABIGO”)`. Let’s take a look. Fire up pry
bigO = BigO.new
Benchmark.measure { BigO.linear_time(BigO.myarray1,”HELLO”) }
Benchmark.measure { BigO.linear_time(BigO.myarray2,”HELLO”) }
Benchmark.measure { BigO.linear_time(BigO.myarray3,”HELLO”) }
Benchmark.measure { BigO.linear_time(BigO.myarray4,”HELLO”) }
Benchmark.measure { BigO.linear_time(BigO.myarray5,”HELLO”) }
Benchmark.measure { BigO.linear_time(BigO.myarray6,”HELLO”) }
INPUT SIZE TIME TAKEN
10 | 3.10E-05
100 | 4.70E-05
1000 | 0.00029
10000 | 0.001877
100000 | 0.014091
1000000 | 0.146048
10000000 | 1.47874
100000000 | 14.698122
Looks linear. If you add a 0 to the input size, you roughly add a 0 to the time it takes to run the function.
3. O(N^2) - Exponential Time.
O(N^2) [or O(N^3), O(N^4), etc] means the time it takes to run the function grows exponentially as the size of the input grows. A good example of this…let’s say you have a method that checks to see if any element plus another element == given_value
<code>
def exponential_time(input1, given_value)
input1.each do |first_elem|
input1.each do |second_elem|
if first_elem + second_elem == given_value
puts “#{first_elem + #{second_elem} is equal to #{given_value}!!!"
end
end
end
end
</code>
Let's run exponential_time([1..100], 202)
What’s going on here? The method starts at the array, and holds that first element value (1). It then starts looping through the array again, checking if first_elem + second_elem is equal to the given_value. Next, it takes the second element in the first array (2), and it loops through all the elements in the first array again. printing any time the elements combined equals 202. It changes to the third element (3)… and so on. Let’s look at why this one be exponential. For this, I will be using the two next to each other as inputs exponential_time method
`@test1 = (1..100)
@test2 = (1..1000)
@test3 = (1..10000)
@test4 = (1..100000)
And time
exponential_time(@test1, 150) => 0.0021 seconds
exponential_time(@test2, 150) =>0.065 seconds
exponential_time(@test3, 150) => 5.8743 seconds
exponential_time(@test4, 150) => 586.27 seconds
Look at how much longer it takes as the size of the input grows. I can’t even run with inputs of length 1,000,000 because it would take too long. If we add one 0 to the input size, we add two 0s to time it takes to run. That is why this function would be O(N^2), or exponential time. We could extrapolate the 1,000,000, because if we multiply the input of 100,000 by 10, then we’d multiply the run time by 100, or 586.27*100, == 58,627 seconds which is roughly 16 hours.
To come full circle to our prime number method from last time,
<code>
def is_prime?(given_number)
if given_number.is_a?(Fixnum) && given_number.is_a?(Integer) && given_number > 1
2.upto(Math.sqrt(given_number - 1).ceil) do |x|
if given_number % x == 0
return false
end
end
true
else
"Invalid Entry"
end
end
#Check is prime, if is, shovel
def prime_upto(given_number)
all_primes = []
2.upto(given_number) do |n|
if is_prime?(n)
all_primes << n
end
end
all_primes
end`
What’s the BigO of prime_upto(given_number)?
We know at the very least, that it has to be O(N), because it will have to grow linearly every time the number is bigger to check if it’s prime. But in addition, it is to call is_prime?.. and is_prime? checks all the numbers up to the square root of the given number. So if we call prime_upto(10),
Step 1 -is_prime(2)
Step 2- 2.upto(square root(2).ceil -1 ) % num == 1
Step 3 . all_primes << 2
Repeat all the way up to 10.
So we have a linear function in prime_upto, and then a square_root of (n) inside the prime_upto(n). So we have O(N) * O(N^1/2). So the Big O, drum roll please, is……
O(N*square_root(N)) — definitely wish there was a prettier way to write this.
So this one is worse than linear, but better than N^2.
I think this is enough for one lesson. Before we get into run-time logarithmic functions, we will take a leap step to recursion!
Until next time!
This post was written by Drew Kerr, a current Ruby on Rails student here at The Iron Yard in Austin.
We are now one month into The Iron Yard and it has truly been an experience that I am grateful to have had. If you are on the fence about joining a program like this I really hope that my post would help lead you to the right decision. With that said, DO IT!!!! You owe it to yourself and regardless of your background take the challenge head on and embrace it. You won't be disappointed.
I am in the Ruby on Rails class and it has been a wonderful journey thus far. Sure you are learning how to program but more importantly you are developing a new way of thinking. To be able to develop a skill set so pertinent in today's world is invaluable. Keep in mind, we are in a day in age where an idea can truly become something tangible, that is extremely empowering and also liberating.
With that said, it has been a ton of work. We have made tremendous progress but there is still work to be done. Our first week we were learning the basics of Ruby and now by week four we are actually building small applications. One thing I want to point out is that this is a learning experience unlike any I have ever had. It actually took some adjusting being able to go into assignments and not know all the answers. The thing I want to convey is that you are learning how to approach a problem in order to solve it. Learning does not stop. You will be given the tools to get started but it will be on you to take it further.
I also would like to point out that the people in the class are very cool. Truly cool. We have people from various careers and backgrounds and it makes for a wonderful experience. So in closing, if you are considering attending a coding bootcamp then give The Iron Yard some thought. The instructors really love what they are doing and one month down I am starting to hit my stride and get acclimated to the craft. I'll be back with another post after the second month is done. One.
This post was written by Katlyn Whittenburg, the Campus Director at The Iron Yard Austin. Check out her bio and follow her on twitter!
This week is half done already. Sheesh! It’s been a fun one so far! Our design students started on Monday. Love getting new students.
Our design students learning the ways of web design from Sam Kapila
I have had collaboration on my mind this week quite a bit. A large part of what I do is helping the students gain the most from this intense experience. Offering some guidance and help and even a hug or two. Sometimes you just need a hug! (Just for the record, I am not a hugger, but I love my job so I’ll hug if it’s what needs to happen.) I reflect often on what I’m doing that works, what doesn’t work, and what I need to improve upon.
This week has demonstrated to me the importance of embracing differences. Each of our students brings his or her own history, goals, fears, struggles and skills to the program. And all these things affect how they learn and how they interact with their instructors, with me and with the other students. Even more interesting to me is how different each class is. One class may be super social, while students in another may keep to themselves more. Upon noticing drastic differences between our classes, I realized I need to devote some real thought to what this means for me and the instructors. Is there a right way and a wrong way? Should both classes strive to be more outgoing and collaborate more? Isn’t collaboration the way to success in the tech field? Heck! In life?
I decided to do a little research into the value of teamwork and collaboration and found some interesting information on the disadvantages of teamwork. WHAAA? Aren’t teams amazing and beautiful and special and sacred? Well…. far too often, not really. Often politics gets in the way of progress. Fear of rocking the boat or not fitting in or even the fear of not saying things in a PC way could keep people from really collaborating effectively. Should there be a leader? If so, who? Does that person want to be a leader? Can the leader still be your friend? Teams are pretty complicated little societies, and those complications can end up watering down innovation and replacing actual progress with pleasantly mediocre work done by pleasantly mediocre people. Not cool.
Why am I talking about this? Well, I’ll tell you! I have to admit that I originally thought that the quieter class should aspire to be way less quiet, and much more collaborative. And while I do not think that is completely incorrect, I have now lessened the expectation for the intensity at which they should accomplish this. And what helped me reach this conclusion, in addition to the research, is asking the students, themselves, why they don’t usually work together outside of lecture. The answers made perfect sense. People need a break; They work better without the distractions of other students. And the like. These are very valid reasons to not stay and work in groups every single day.
BUT the problem with this non-collaborative approach is that when learning a new skill, seeing others work through the same problems you are facing and being able to work through these problems with someone of approximately the same skill level is super helpful. He or she may think of tactics that would have never crossed your mind and vice versa. You will have help if you get stuck, but you also won’t be fed the exact right answer, which allows you to work through the process of figuring it out. And this process of figuring it out is the whole point. To become a great developer, you have to be a great problem solver. And working with others helps with this.
So the conclusion I have drawn from all this is that teamwork is not the simple and clear way to success. It’s a challenge, in and of itself, to create a truly effective team- one in which each person feels as if he/she accomplished something out of the collaboration. Here at The Iron Yard Austin, I want to strive to inspire great teamwork and great collaboration because in the “real world,” that’s what many jobs call for. But I also want to learn ways to get great work from people in a way that is efficient and rewarding for them. And so forcing the “quieter” class to collaborate on every little thing, in my opinion, is not a way to get great work from them.
It’s a balance between challenging people to go outside their comfort zones so they can grow, but also allowing individuals to be themselves and work the way they work best. I don’t think enough people actually think about what working in a team should look like and put an effort into making sure the team is truly benefitting everyone. And that is why I am thinking about this...so that I am not one of those people.
This post was written by Aaron Larner, Austin’s Front End Engineering Instructor, on his personal blog. Follow him on Twitter
When I moved to Austin Texas I had a whole laundry list of goals that I wanted to accomplish. I had been living in Madison, Wisconsin for five years, the longest period of time I had stayed in one place during my adult life. Needless to say, moving to Austin was a big deal for me I wanted to get the most out of my time here.
One of the biggest goals on my list was to climb a V5 (a grade of bouldering problem), so when I got to Austin in September, 2013 I started climbing really hard in a effort to check that goal off of my list. A few weeks later I injured my finger and was out for a month. "That's okay" I thought to myself. I'll rest up and get back to it when I'm all healed. At the beginning of November I was ready to go again. I was in climbing withdrawal and so excited to get back on the wall. By December I had injured myself a second time. This time it was my elbow.
While visiting family over the holidays I had some time to reflect on my last four months in Austin. I was not nearly as far along towards my climbing goal as I had hoped. Even worse, I was really upset that I couldn't climb at all because of my injuries. This was even worse than not accomplishing some arbitrary goal, because it impacted my happiness on a daily basis. I wasn't able to do something that really made me excited to get out of bed in the morning. My new years resolution for 2014 was not to climb a V5. Instead it was to climb 100 days.
This might not seem like a very big change, but for me it represented a change in the way that I think about goal setting. Now, instead of focusing on some arbitrary finish line I'm focusing on the process to get me there, and then beyond. This process will be helpful whether I want to climb a V5 or V15. It encourages me to pace myself and think about my long term health and strength. Most importantly it encourages me to do something I love, twice a week. When I feel sick I take a few days off. If I feel week or like I'm being sloppy I leave the gym. It doesn't matter how long I climb as long as I make it out 100 times. I keep a spreadsheet of every day I've climbed and as of today I'm up to 87 days. I feel stronger than ever and haven't taken off a single day due to injury this year.
Scott Adams, the Dilbert cartoonist says goals are for losers. I agree with him. Focus on the process or system to get you what you want. In my experience if you figure out the right process you'll get there eventually and enjoy the journey much more.
This post was written by Justin Herrick, Austin's Ruby on Rails Instructor. View his profile on The Iron Yard's website and follow him on Twitter!
It's human nature to want to avoid mistakes. We want to make progress and mistakes seem like the antithesis to progress. However, sometimes we can learn more from a mistake than we would from smoothly sailing forward. I think this is demonstrated exceedingly well when programming.
A mistake in your code could reveal more about the nature of your code and the libraries it is using. Take for example this common situation in Rails.
#game_controller.rb class GameController < ApplicationController def about_game end end
#routes.rb Rails.application.routes.draw do get ‘about_game’ => ‘game#about_game’ end
I create a new action in my controller and I also create a route pointing to my action, but when I navigate to that route I get an error. Specifically, I get this error.
Great. I messed up. Now I gotta figure out why my code doesn’t work. Rails is saying my template forgame/about_game is missing. It also says that it tried looking in app/views. With a little bit of context, we can see that this error is actually telling us what we need to do, not just what the mistake was. Rails says it cannot find the template for our new route and that we should create it inside ofapp/views. Not only that, but that it should be inside of game/ and named about_game. Well, that wasn’t too hard to fix. I also learned a little about Rails in the process. Rails looks for templates inside of the view/ directory and then looks for a directory that matches the name of the controller and a file that matches the name of the action.
Mistakes happen, errors occur. When developing software, they are more than a daily occurrence, they are an hourly or minute to minute occurrence. The key is to realize that errors are good, they are here to help you. They are giving you feedback about the state of what you are building. They are just one more step in growing as a developer, and as you grow, you will make less errors and build your own system for handling those errors. My steps for when I run into an error normally go something like this:
Stop and take the time to understand what the error is telling me.
Discover where the error is coming from.
Look for typos.
Make sure my files are saved.
Walk through the logic of my code right up until the error occurs. Normally this is done out loud and with someone listening.
Try it again.
If the the piece of code and the error are modular enough, I will try to replicate the code in a REPL and see if the error exists there as well.
If the error is hard to pin down, I will start to remove sections of code systematically to find the problem area. Allowing me to focus my search
Consult peers who may have run into the same issue.
Search the internet for others who have may have found this issue and also found the solution.
I rarely find an error that cannot be solved by making it through this list and even rarer yet is the error where there is no learning to be found.
Many times when I talk to a student who is stuck, I find myself telling them that it is time to put on our detective caps. Feeling helpless or frustrated where an error occurs is normal, but its not very productive. By taking the time to re-approach the error as a clue of where to go next, instead of a stop sign, I have turned a potential setback into a positive.
This post was written by Katlyn Whittenburg, our Campus Director at The Iron Yard in Austin. Check her out on our website and follow her on twitter!
It has begun.
Well, Austin, The Iron Yard has officially started. Our Front End and Rails Engineering courses are up and running. Future devs have taken over our awesome space at Penn Field, and I couldn’t be happier having them here. As the Campus Director, I was working in the office for a month before anyone else arrived, and it got kinda lonely. I talked to myself a lot. It was weird. Now, though, eager students are working hard to become developers, and it’s a glorious sight to behold.
We are just wrapping up our second week with our first students. These first couple of weeks are crucial. It sets the tone for the entire cohort. We want to make sure we communicate clearly with the students about our expectations for them and about what they can expect from us. Equally as important, we want to make sure the students understand that The Iron Yard is here for them. This is a huge challenge they are taking on, and they are entrusting us to provide them the resources they need to become developers in 3 months. We do not take this commitment and trust in us lightly. The instructors and I are here for the students, and not just to throw code at them and send them on their way. When the challenge feels too immense, the instructors and I are here for guidance and encouragement. We are here to share in the victories, and we are here to tell them to take a break when they have been staring at their computer screens for hours.
As I mentioned in my first post, I went through The Iron Yard’s Front End program in Atlanta so I have real empathy for what the students experience during these 3 months. It is a life-changing program, but it can be scary. You walk in on that first day, probably not knowing anyone, and you likely have no experience to compare this to. It’s difficult for some people to believe that we can actually teach you to code in 3 months, and “What did I get myself into?” is a very understandable question on that first day. So, it is my job and the instructors’ job to let our students know, we know what we are doing and we can get you through this. If you work. Work really really hard. And use the resources we offer. That’s why you’re here.
Each week culminates in our Friday Huddle. This is a time when we all get together and check in on how the week went. The structure will vary from week to week, depending on the needs of this cohort. The point, though, is to give the students (and us) time to share our experiences, offer encouragement when needed, offer advice when needed, and remind each other that we are in this together (it’s corny, but true :) )
This first Friday Huddle was very rewarding. Hearing these students talk about how hard they’re working and how happy they seem to be here with us was the best way to end a busy and wonderful week. We had the students write letters to their future selves and we will return these when they graduate so they can realize how far they've truly come. For many of these students, this experience is a chance to completely change paths in life. This makes my work as Campus Director very meaningful, and I feel lucky to be a part of their journey. I cannot wait to look back at this post three months from now when all our students have graduated and are starting their new lives as developers.
I will use this blog to take you along the journey of our first cohort in Austin. It's guaranteed to be a hoot of a time, so follow along! And as always, if you have questions for me about The Iron Yard or about how to cook an amazing meal in under 10 minutes, hit me up! Except not really about the latter because I don't know how to do that... K bye!
This post was written by Nathan Hall, our Rails TA at The Iron Yard in Austin. Check out his LinkedIn!
WEEK 1
PRIME NUMBERS UPTO 1,000,000
Whiteboarding problems is something you will probably experience in the coming months for a ruby on rails job. What!? I can’t use my computer to code?! Fraid not, Timmy.
I’m going to try and do a weekly lecture, where we will
A) start whiteboarding the type of problems you may be asked to solve together B) learn BigO notation C) learn basic data structures D) learn basic algorithms, like merge sort
Not necessarily in this order.
PROBLEM SOLVING — This is how I do it, but this is not THE way to do it, and any other way may be just as good or better. Please feel free to criticize anything on here and/or provide your own method to problem solving.
Problem: Find all the prime numbers up to a given number. (1,000,000)
Step 1: Figure out what I’m getting. The problem states that I’ll be receiving a number. We can begin by defining a method
def prime_upto(given_number) end
Step 2: Figure out what I’m returning. The problem wants me to return all the prime numbers up to a certain number, but does not specify how it wants them to be returned. In an interview situation, we would ask what the interviewer is expecting as output. For this situation, I will return an Array that lists all prime numbers up to the number given.
Step 3: Determine my assumptions.
Here, I’m assuming the number given is a Real Number, and an Integer. I’m assuming it is not negative. I’m assuming it is ok to return an Array of all Prime Numbers, but maybe they want them stringified, or stored in a hash structure.
During the interview, ask the person about your assumptions. Assumptions are an easy way to mess up your problem if you don’t try to get clarification. Maybe the person interviewing you wants you to return only prime numbers that are prime factors of larger numbers. IT is always ok to ask for more information. The interviewer is most interested in how you think, and if you are asking good clarifying questions, it shows you are considering edge cases and details that need to be understood in the real world.
Step 4: Writing Tests.
This might not be necessary for the interview, but it will help you with all of your assumptions. When you’re asking your interviewer about the assumptions you have for the problem, you are helping determine a lot of your tests. I have my tests written below:
describe ‘#prime_upto(given_number)’ do context ‘when the number given is negative, float, 0, or letter’ do it ‘tells the user “INVALID ENTRY” and exits” do expect(prime_upto(-1)).to eq(“Invalid Entry”) expect(prime_upto(1)).to eq(“Invalid Entry”) expect(prime_upto(“HELLO")).to eq(“Invalid Entry”) expect(prime_upto(0)).to eq(“Invalid Entry”) expect(prime_upto(1.9999)).to eq(“Invalid Entry”) end end context ‘if the number 8 is given’ do it 'should return all primes before 8’ do expect(prime_upto(8).to eq([2,3,5,7]) end end end
Ok, I think we have handled our edge cases, and we have started to think about the problem…now………
Step 5: Break it into parts and solve.
Here is what we currently have:
def prime_upto(given_number) end
We know we need to return an array of all the prime numbers up to given_number. How should we think about that? First, and most important, we need to check if the number is prime. We should make a new method first, that checks if any number is prime. (If you are wicked, you can use ruby specific prime module, but that is cheating!)
def is_prime?(given_number) end
From our edge cases, we know that we want to return “Invalid Entry”, so let’s start there.
def is_prime?(given_number) if given_number.is_a?(Fixnum) && given_number.is_a?(Integer) && given_number > 1 DO SOMETHING else "Invalid Entry" end end
describe '#is_prime?(given_number)' do context "when the number is given is negative float, 0 or letter" do it 'tells the user "Invalid Entry" and exits' do expect(is_prime?(-1)).to eq('Invalid Entry') expect(is_prime?(1)).to eq('Invalid Entry') expect(is_prime?("Hello")).to eq('Invalid Entry') expect(is_prime?(0)).to eq('Invalid Entry') expect(is_prime?(1.9999)).to eq('Invalid Entry') end end end
Come on RSPEC, don’t fail me now. GREEEEEN. Now for the hard stuff.
A prime number is a number that is only divisible by 1 and itself. So 2 is the first prime number, and 3 is a prime number, then 5,7….etc. To think about it differently, any number that is divisible by another number besides 1 and Itself, is not prime. That means for a given_number, that if any number between 2 and given_number minus one gives a remainder of 0, It is not prime: So we need to use a .each loop to check the range of numbers, leading up to given_number -1, that do not produce a remainder of 0. If they do not, return true
Let’s write some tests!
describe '#isPrime?(given_number)' do context 'given these number it should equal the expected output' do #this is ugly but you get the gist. AND HEY. at least i am testing it 'should return true' do expect(is_prime?(3)).to eq(true) expect(is_prime?(5)).to eq(true) expect(is_prime?(101)).to eq(true) end it 'should return false' do expect(is_prime?(4)).to eq(false) expect(is_prime?(10)).to eq(false) expect(is_prime?(15)).to eq(false) end end end
AND update the other tests
describe '#is_prime?(given_number)' do context "when the number is given is negative float, 0 or letter" do it 'tells the user "Invalid Entry" and exits' do expect(is_prime?(-1)).to eq('Invalid Entry') expect(is_prime?(1)).to eq('Invalid Entry') expect(is_prime?("Hello")).to eq('Invalid Entry') expect(is_prime?(0)).to eq('Invalid Entry') expect(is_prime?(1.9999)).to eq('Invalid Entry') end end context 'if the number 8 is given' do it 'should return all primes before it return' do expect(prime_upto(8)).to eq([2,3,5,7]) end end end def is_prime?(given_number) if given_number.is_a?(Fixnum) && given_number.is_a?(Integer) && given_number > 1 (2..(given_number-1).each do |num| if given_number % num == 0 false end end true else "Invalid Entry" end end
Ok, let’s run RSPEC. WHAT?!?!? EVERY SINGLE NUMBER IS PRIME!??!? Hmmm… I must have done something wrong. Oh!!!! As it stands, ruby will say false every time a number is not prime, but at the end it always returns true! I need it to exit the loop if ANY of the numbers are not prime. So it can’t just be false, it must return false.
def is_prime?(given_number) if given_number.is_a?(Fixnum) && given_number.is_a?(Integer) && given_number > 1 (2..(given_number-1).each do |num| if given_number % num == 0 return false end end true else "Invalid Entry" end end
Let’s run this. Boom!! We now can tell you if a number is prime or not. Now back to getting all the prime numbers up to a certain number.
We should do another loop, all the way upto given_number, and check if the current number is prime. If it is, we should inject it into the array we want to return. If it is not, we go to the next number! Upto sounds cool… I wonder if ruby has a method that does that. OHH RUBY, you are such a GEM!! Let’s use UPTO!
def prime_upto(given_number) all_primes = [] 3.upto(given_number) do |n| if is_prime?(n) all_primes << n end end all_primes end
Let’s RSPEC it, and GREEN it passes. Now, let’s open up console, and run our program, giving it a 1000. So fast! Now let’s do 10,000!. Hmmm, slowing down. That took half a second. But it works. Let’s trying 100,000! …. hmmmm this is taking forever. That took 30 seconds. I can only imagine how long it’s going to take if we do a million, we’re going to have to speed this up! But HOW?!?
I do not expect anyone to know this, but! You actually do not have to check every single number on the way up to given_number. I will not be supplying the mathematical proof for this, but all you have to check is all the numbers leading up to the SQUARE ROOT(rounded up) of the given_number. For instance 3-1 = 2 .. sqrt(2) = 1.73.round = 2 .. 3% 2 == 0 ? No… PRIME 4-1 = 3 sqrt(3) = 1.73..round = 2 … 4%2 == 0 ? Yes NOT PRIME
Lets work this back into our solution.
def is_prime?(given_number) if given_number.is_a?(Fixnum) && given_number.is_a?(Integer) && given_number > 1 2.upto(Math.sqrt(given_number - 1).ceil) do |x| if given_number % x == 0 return false end end true else "Invalid Entry" end end
And now let’s see how long it takes. prime_upto(100000) .. wow, that went from 33 seconds to 0.28 seconds. now for a million DRUMROLL PLEASE!!!
5.4399999999999995 seconds. if we set that to a variable and count it. We have 78,498 numbers that are prime between 1 and a million. Crazy.
But what about why it took so long. Why does it take exponentially more time to run prime_upto(1000) vs prime_upto(10000) vs prime_upto(100000)? We will get to that next time. When we start talking about BIG-O notation!
RECAP STEPS:
Step 1: Figure out what objects I’m getting. Whether it is an array, a number, a string, whatever, I need to know what I’m getting initially.
Step 2: Figure out what I’m giving back. This will drive how I write my solution. If I need to return true when a number is prime, I will write my solution differently than if I needed to return an array of all the prime numbers up to 1,000,000.
Step 3: Figure out my assumptions. You have to figure out what you don’t know about the problem. Is the value be supplied an Integer? Can it be Negative or 0? Could it be a strings? Could it have complex numbers? Could it contain a function? Could it be empty? If you can ask someone for more clarification, like in a technical interview, do it. If not, start thinking about all the possible inputs.
Step 4: Start writing your tests based off of your assumptions. If you get an 0, does it return the correct thing? If your number is actually a string, what does it return?
Step 5: Break the problem into parts and start solving each part individually. The biggest issue that I see is that people try to solve a large problem all at once. Instead, break it into parts. You don’t want to try to solve everything at once. That’s very hard to do (borderline impossible for complex problems) and makes you prone to mistakes. It will also overwhelm you. Every. Time. Figure out one part of the problem and solve that, then move on to the next.
Step 6: Review the problem and see where you might improve it.
This post was written by Sam Kapila, our Web Design Instructor at The Iron Yard in Austin. View her profile on our site or follow her on Twitter.
Last week at the Iron Yard Austin campus we kicked off classes in Front End Engineering and Ruby on Rails. And with Web Design starting at the end of January, we’ll have a full house of designers and developers learning and working together. Students in all three classes will learn about many industry-standard tools and processes including one of our favorites, Sass. Students in all three of our Austin courses and at other campuses are learning about Sass, a pre-processor for CSS that supercharges code, saves designers and developers time, and allows those of us to value super clean code to feel things well organized and structured.
Something else we love? Austin’s booming meet-up scene. Lucky for us, we can have it all with Austin’s very own Sass meet-up, ATXSass. ATXSass is a great Sass- and CSS-specific meet-ups and one of Austin’s newest tech groups. Organizers Ian, Una, and Elyse have been organizing monthly events with speakers who use Sass in their project workflow since last summer. Since we’re huge fans of Sass at TIY, we sponsored the first meet-up along with other awesome sponsors! It was a great event and it was so cool to see seasoned Sassy folks and people interested in learning work through demos and code on screen and share pizza and enjoy a beer or two! We enjoyed it so much that we’re ecstatic to announce that we’re back for 2015 as annual sponsors!
The first meet-up of the new year is on January 22nd at Capital Factory with Paravel Inc’s very own Dave Rupert. Dave Rupert will be sharing his experience and tips with Responsive Web Design (RWD) page bloat and how to improve site speed and performance on responsive sites. Students and staff at the Iron Yard are excited to attend and learn more about how RWD has evolved into more than just aesthetics but consider the users of the sites and apps we make. You can register here and come find us. We’ll be the ones with a whole bunch of TIY stickers!
This post was written by Katlyn Whittenburg, our Campus Director at The Iron Yard in Austin. View her profile on our site or follow her on Twitter.
Our Austin campus is going strong as it quickly approaches the January 5th start date for its very first cohort. We are thrilled about being in Austin and have already formed some amazing collaborations, including one with IBM Design. They are amazing: IBM Design is a unique component of the IBM corporation, utilizing inspired studios and user-focused processes to make their products better.
But they’re also awesome people: IBM Design was even kind enough to host our first Advisory Board meeting and give everyone a tour of their inspirational design studio here in Austin.
Here’s a quote from Katie Parsons, a Front End Developer at IBM Design:
I’m absolutely thrilled that IBM’s pairing up with The Iron Yard—we’re always on the hunt for candidates with both design and dev skills, and The Iron Yard will bring us a fresh new crop of talent! I can’t wait to see what our partnership brings in 2015!
This collaboration is a great opportunity for our students to be exposed to the inner workings of an incredibly successful and influential technology company, and we are excited to help provide future IBM designers and developers through our program. We foresee many exciting opportunities in working with IBM Design and we’ll keep you posted on all the great things we are working on together!
Let me introduce myself. I’m Katlyn, the Campus Director at The Iron Yard in Austin. I’m new in town. Moved here about a month ago from Chattanooga, TN with my two daughters to start this new adventure with The Iron Yard. It’s been an insane few months since I found out I would be working for TIY in Austin. I didn’t even have a chance to visit before the big move, so I was quite worried that I would get here and hate it. I decided to risk it, though, because in the wise words of someone wise, “You gotta risk it to get the biscuit.” Apparently, biscuits are very valuable. So, I moved here, and thus far, I feel like Austin has not disappointed in the biscuit department. Or in the taco department. Or in the coffee department. Or in the BBQ department. Basically, I’m saying Austin has amazing food. So many calories have happened since I arrived in town. It doesn’t just have amazing food, though. It has amazing people. I expected that “big city” attitude. I expected people to be too busy and too important and too hip to be friendly. That is just not true, though. People are busy and important and hip, AND they are friendly. Austin is anomaly among cities. So thank you, Austin, for showing me such a warm welcome!
Before Austin and this job, I was actually a student of The Iron Yard Front End Engineering program, myself, in Atlanta, GA so I have a pretty unique perspective on this whole Iron Yard thing. I know what it’s like to be a student trying something completely new, taking that risk of devoting 3 months of your life to learn an entirely new skill, and being scare sh**less that it won’t take, and it will have been all for naught. I also know what it’s like to build an app. Like… a real working app. That works. A whole app! (Okay… you probably get the point.) I went from thinking that the internet used actual magic to show me all those fancy websites and apps to being able wield the power of the internet, myself, and build something from scratch. I basically control the internet now. (Ok… not quite. But it feels like it sometimes.)
Gaining that skill did not come easily. No part of the process is actual magic. It’s really just a lot of really freakin’ hard work. The Iron Yard doesn’t call it an “intensive” program ironically. It gets intense. After that first day, I was terrified. I already felt terribly behind and overwhelmed. Now, I would say not everyone felt quite as behind as I did so immediately. Everyone in these courses comes from a different background. You’ll have students like me who know nothing about the interwebbernet except for how to Google things; You’ll have students who have been developing for years but maybe want to learn a new language, and you’ll have students of all sorts in between. It’s an odd and interesting mix, and after a week or so of class, I began realizing how beneficial this broad spectrum of skills and backgrounds and personalities is.
Your class is your team. They are your lifeline. They are your family. For those three months, you forget about your ego (if you’re smart) and you ask for help A LOT and you help others A LOT, and this bonds you, and this teaches you. The people of The Iron Yard are an essential part of the process of learning to code. And not just your fellow classmates. Your instructor and your Campus Director and the amazing guest lecturers you get to meet. This group of people gives a shiz. In fact, they give several shizzes. It’s this passion and empathy and collaboration that made me love The Iron Yard, and is what made me want to work for them. Lucky for me, the feeling was mutual, and here I am. Now I get to help shape The Iron Yard experience for new students, I feel very grateful for that. I want all the students to love The Iron Yard as much as I do. I want all the students find this experience to be life-changing. I this to let you know that I actually do care. So please, reach out to me if you’re a student or thinking of becoming a student. It’s my job and my pleasure to help.
Well, I wanted this post to be an introduction to me and my job and why I do what I do. So I hope you got a sense of that. Aside from my job at The Iron Yard, I love writing, reading plays, drinking sugary frozen coffee drinks, dancing awkwardly, but with purpose, to Britney Spears, and taking care of my two sweet girls. Wanna chat about The Iron Yard or plays or choreograph a number to a Britney Spears hit? Email me: [email protected] . Until next post!
Sam Kapila: Thwarting the Challenges of Starting a Coding Career
By Eric Dodds, Partner at The Iron Yard
After six years of full-time teaching on Communication Design at Texas State University, Sam Kapila joined The Iron Yard Austin in October of 2014 as a Web Design Instructor. The Iron Yard is both a code school and a startup accelerator that began in Greenville, SC and has since expanded the code school side of the operation to ten more cities throughout the country.
While at Converge Florida, Kapila opened up about her recent transition in a conversation with Clark Buckner of TechnologyAdvice. Along the way, she also shared how technology teachers can help students bridge the gap between graduating and getting a job.
When asked how she got into educating others on web design, Kapila recalled being against the idea from a very early age because she thought her parents’ jobs—her father was an engineer and her mother was a teacher—were boring. But as the youngest sibling, her room became the computer room, and with so much free access, she found herself on the computer a lot, playing games and making Geocities pages.
Still, it wasn’t until she began teaching that she realized how much teaching was making her a better coder. “By being able to verbalize what you already do, you have a better understanding for it,” she said. It was during her time at Texas State University that Kapila “became really passionate about wanting to help people who wanted to find out more” about coding and web development.
Bridging the Gap Between School and a Career in Technology
Kapila first witnessed “disconnects” between her students’ work and employers’ expectations when she conducted portfolio reviews at TSU. In her words, “what’s being taught isn’t necessarily what people are hiring for.” Part of the problem stemmed from academic bureaucracy. Kapila noted that it typically takes three to five years to change the curriculum in a state university. With web design and development being such a fast-moving industry, it’s little wonder that what was being taught hadn’t caught up to what was being requested in “the real world.”
Kapila brought up two other suggestions to help bridge the gap: schools and agencies should communicate more frequently. “They could all benefit from having advisory boards on the school side and then having teaching apprenticeships on the agency side.” Furthermore, Kapila cites employers’ acronym-filled, jargon-laden, experience-heavy job postings as an unnecessary impediment to qualified graduates who want to apply for those jobs. “We need some way to quantify someone’s experience, but I don’t know if the right unit of measure is years of experience. I think someone can learn more in one year than someone in a different situation [can learn] in three years.”
Despite these issues, Kapila believes that the gap has decreased over time, especially with the rise of Twitter and web design blogs. She cites StudentGuideWebDesign as an imminently helpful resource for design and development students to read. According to Kapila, a student named Janna Hagan, created the website and asked others to guest write for it because she noticed the same kinds of disconnects that Kapila spoke of. The website was his way to help bridge the gap.
Of course, Kapila believes that The Iron Yard Academy, and especially the one based in her backyard of Austin, will definitely help students young and old bridge the gap between learning code and landing a job. Free from some of the constraints that accompany teaching at public institutions, Kapila aims to regularly update what the Academy teaches on design and development that can be immediately implemented into most job hunts.
Listen to the full TechnologyAdvice interview to learn more about The Iron Yard Austin. To see if The Iron Yard is offered near you, visit TheIronYard.com, or connect with them on Twitter @theironyard. You can also connect with Sam Kapila at @samkap.
This interview was conducted by Clark Buckner of TechnologyAdvice, an Inc. 5000 company that is dedicated to educating, advising, and connecting the buyers and sellers of business technology. Clark hosts the TechnologyAdvice Podcast, and also keeps tabs on news and events in the company’s tech conference calendar. Tweet him a hello or connect with him on LinkedIn.
The Iron Yard | Austin @tiyaustin - Tumblr Blog | Tumgag
