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!
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
Great, we’ve caught our edge cases. Let’s update our SPEC file.
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!
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.
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!
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 relationships, 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 collaboration 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!
By Katlyn Whittenburg, Campus Director
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@example.com . Until next post!
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.