The Flatiron School

Make yourself useful.

Flatiron School + Fog Creek

Sweet! Today is the day we get to tell you about the new Fog Creek Fellowship.

We’re so excited to announce our brand new partnership with Fog Creek Software—creators of Trello, FogBugz, and Kiln. As part of a two-month fellowship program, Fog Creek will host and mentor a select group of freshly-graduated Flatiron women. Paired with a Fog Creek engineer, Fellows will get to spend their time honing their new skills with dedicated pair programming and full access to all of Fog Creek’s resources. Together, we hope to help awesome Flatiron School women land programming jobs they love.


Fellows will be spending time at Fog Creek’s offices in the Financial District.

Develop Great Talent

The Fellowship will give great talent a place to grow. Fellows will spend two months hanging out with Fog Creek’s team and participating in a structured mentorship and job training program. They’ll get interviewing practice and resume reviews with top-tier tech recruiters, a chat with the company’s founders Joel and Michael, and of course, a designated Fog Creek mentor.

Mentors will join Fellows for a weekly 1:1 lunch, a mock coding interview, a bi-weekly pair-programming session and more. In the end, Fellows will become even more talented programmers, bolstered by long-lasting relationships with both their mentors and with Fog Creek.

Encourage Amazing Women

Programs like our NYC Web Development Fellowship allow women to start closing a massive skills-gap in tech. Fog Creek’s Fellowship will pick up where we’ve left off and provide women who have just learned a new skill-set and are eager to kick off their careers in tech with the tools they need to get their first programing job.

We know how great the women who come to Flatiron School are. Unfortunately they are sorely underrepresented industry-wide—including at Fog Creek, where in the last six months just 14% of technical applicants were women. With the Fog Creek Fellowship, we hope to encourage even more great women to start programming, grow into senior positions, enrich the tech industry, and excite future generations of female programmers. Our goal is to ultimately see these efforts reflected in a higher percentage of women in applicant pools at Fog Creek and across the tech industry.


Our alums are great—we know they’ll help inspire even more women to start programming.

Why Fog Creek

We spend a whole lot of time making sure our grads get the best first impression of the tech industry possible. We want them to love their new gigs, and we’re pretty sure they’re going to love spending time at Fog Creek. They’ll get to experience what it’s like to work at a company built by developers for developers. They’ll also get to immerse themselves in a company culture that really values their people—so much so that every developer gets a sustainable workload and a private office.


Fog Creek’s culture in action

Fog Creek’s focus on people and collaborative learning has so far helped them attract some of the smartest folks around (their acceptance rate for full-time developers is .4%). We could not be more excited that Fog Creek’s exceptional people are donating their time to mentor and support our incredibly talented women—and encouraging even more to apply.

Expect more announcements in the coming days and weeks on the official program page. In the meantime, if your company would like to get involved and mentor Flatiron grads, get in touch.

We can’t wait to start making it happen!

Canyon of Heroes

Or a lesson in Financial District history, from Ruby student (and archivist!) Ashley Blewer, originally posted here.

When walking to and from class every day at the bottom of Manhattan, I’ve noticed plates of text on the ground with a date and name of a famous person. I didn’t realize what these signs were about until I was walking out of the southmost Bowling Green stop and saw the initial plaque on the ground:



After that, everything clicked! They are commemorating every ticker-tape parade held on Broadway, starting with the first to commemorate the dedication of the Statue of Liberty in 1886.

Before I came to the Flatiron School, I was working as a moving image archivist. I primarily worked with collections of newsreels from the 1920s and 1930s. My job was to catalog them and put them online for access. When I realized what the text on the ground stood for, I immediately ALSO realized that I recognized so many of the names because I had seen some of the actual parades happen (on film)! The text that struck me the most while walking up the street was this one:



I’ve definitely watched this footage. I ran to the (digital) archive and sure enough, there it was.

Footage identification can be difficult when you don’t have a lead, but this connection was pretty easy to make. I watched the footage, paying attention to the structures of the buildings, and then pulled up Flatiron School’s address on Google Streetview. Boom! It was a total match!

Here is a screencap of the Amelia Earheart ticker-tape parade superimposed on top of Google streetview.



Pretty cool!

Bonus: The building that the Flatiron School is located in used to be the office building for the White Star Line, which built the RMS Titanic (and many other, sturdier ships). Cool!

A Better Git Workflow: A Better World AKA My Induction Into The Git Police

Originally written and posted by Web Fellow Edward Leon Jasper right here.

I can’t possibly think of anything more joyous than a great Git workflow. What I thought was once so easy has proven to be not easy at all. Working with Git in a group has been a scary monster: hours of work lost in a single key stroke, app breaking bugs appearing out of thin air, forms that render twice! It’s enough to make you want to scream! I wanted to finally explore a better way to work with Git in a group setting.



So we all know that when making a new feature we should be working on a separate branch. It’s important to understand that the master should remain deployable at all times! No one works off the master once the app is fully functional. This is one of the reasons I love pull requests with Github. It allows for features to be discussed before they are integrated with the master. This also allows you to ask for help on a feature without touching the polished copy.

Tip: Feature branches should have descriptive names of their purpose such as movie-form-view.

Tip: Commit often. When doing labs, we would often wait until the end to commit and push. This is a horrible practice where we need to be committing changes very often, such as when we’ve made a measurable change. The Picklebacks(soon to be link to their project) had it right when they played Salt-n-Pepa’s “Push it” everytime they where ready to commit a change.



Once we have a feature that is ready to be merged, the two parties should discuss the changes made. Once that is ready we can run:



It’s pretty simple but important to have a firm grasp on.

Merge conflicts are easy, even a few lone line breaks can make an issue.

Tip: Work on your files only! If a grammatical error needs to be made on your home page and that is not part of your feature. LEAVE IT ALONE. Let the developer in charge of maintaining the master make those changes THEN pull those changes to your branch and continue to work. Feature branches are as simple as changing what you want when you want it. Each branch and pull request should be for its own individual issue and nothing more.

Following these simple steps will help your work flow drastically but if you need some help…just call Git-1-1 and the Git Police will be right there!

Project Recap: Kickammender

Like so many of our alums, Michael and Joe both applied to Flatiron School at points in their lives when they weren’t sure what was next: Joe was an economics major turned Marine, and Michael was shirking questions about applying to PhD programs. Now full-time developers, they used their time at Flatiron to level up their programming skills and work on a project called Kickammender—a recommendation engine for the ridiculously popular crowd-funding site Kickstarter.


How They Got Here

When Joe left the Marines, he felt like he needed a new skill to join the workforce and started learning to program. “I never really considered myself a technical person,” he said, “But it was gratifying to write code and have it actually do something.”

After graduating university with a degree in Electrical Engineering, Michael worked for a hardware company with 2,000+ employees. He had a lot of ideas he wanted to bring to life at a smaller startup but felt he like he needed to know how to program in order to get a job. “Programming gives you the power to make your ideas,” he explained, “By the end of the program [at Flatiron], I was able to do stuff that I wouldn’t have dreamed of before.”

“By the end of the program, I was able to do stuff that I wouldn’t have dreamed of before.”


Why Kickammender?

As students, Michael and Joe worked on Kickammender to apply their interests, grow what they’d learned, and fill what they perceived as a gap in Kickstarter’s user experience. Although Kickstarter users can follow their Facebook friends’ activity, preference-based recommendations don’t really exist.

“It’s hard to find better, more personalized recommendations,” Joe explained. “If there’s a new project out that you might want to check out or back, there was no way to know or be notified.”

Their solution? Just a few weeks into the program, Michael built an engine that used machine learning to make dynamic product recommendations. “I was just going to write a blog post about it,” he said, “But I got kind of obsessed.” They decided to use the momentum and excitement from this initial project to make something bigger.

How it Works

Kickammender uses machine learning and the k-means clustering algorithm to compare users to the thousands of other people on Kickstarter. When the app finds a group of users with similar preferences, it recommends projects that real people in that group have backed.

Users simply log in through Facebook and receive dynamically updated recommendations based on what they’ve liked before. They can also tailor their recommendations with feedback, save projects they’re interested in, and find Kickstarter users outside of their Facebook network with similar preferences.





Challenges and Highlights

Challenges ranged from having to go through the process of scraping Kickstarter’s infinitely scrolling site in the absence of an API to disappearing data points. “Disappearing clusters,” Joe explained, “we’d have 100,000 data points, process them through the algorithm, and at the end of that process, half of the them would be gone. It took some refactoring to fix.”

In spite of technical challenges, they still point to Kickammender as a big achievement in their learning process. “It was the first software project that I ever started and finished,” Michael said. “Everything about it was challenging, but I’m really proud we did it.”

“It was the first software project that I ever started and finished. Everything about it was challenging, but I’m really proud we did it.”





Although Kickammender was developed independently, it got a shout out from a Kickstarter Product Manager on Twitter. Still, the real praise is in the product itself. Even as fresh-out-of-the-box Rubyists, Michael and Joe took a great but little-known feature on a popular website and made it even better.

The Stack

Built with Ruby on Rails
PostGreSQL on the backend
Javascript Bootstrap on the frontend
Served up by Digital Ocean


Um, so we have these chairs…

… and Ruby 005 student Ben Serviss has cleverly used them as an analogy for learning to program. Who knew! Here’s his post, reblogged from here

The first time I walked into The Flatiron School, I thought to myself: “What are these crazy orange things?”

I had come to one of the weekly NYC on Rails meetups in December of 2013 to check out the vibe and decide if I wanted to apply to the school’s web development program. Strewn about the main meeting space were knee-high, accordion-esque bright orange… things.

Were they chairs? Were they stools? Were they the missing business ends of giant toddler-sized toy hammers?

image

Spoiler: They turned out to be chairs. Ergonomic chairs, in fact, created by designer Alan Heller. The ErgoErgo chairs (as they’re officially called) were designed to encourage active sitting, relying on the sittee’s core muscles for stability as you rock gently back and forth.

Once I had gotten used to the concept, using the chair turned out to be fun in its own novel way. Figuring out how to best use the chair added a playful dimension in talking to the other meetuppers, helping ground the evening in a more open-minded mood.

Now that I’m a full-time student at Flatiron, I’ve noticed how easily my classmates have incorporated the chairs into their routines. Since they’re so modular and light, it’s easy to grab a few and turn any table into a lunch spot or meeting area, use one as a footrest, or even corral a bunch into a nifty nap corner. In just a matter of weeks, the ubiquity of these strange little chairs had become a given.

Cool, right? There’s something else entirely that explains why these peculiar little chairs fit in so well here – and it’s because the entire process of encountering, evaluating, interacting and experimenting with them is a perfect metaphor for learning to program.

image

Upon first glance, ErgoErgo doesn’t look like any chair that belongs in an office setting – there’s no back, they’re too short, the shape is wrong, the color is far too bright – and you’re immediately thrown out of your comfort zone, just as someone new to programming is quickly buried in confusion.

Then, as you figure out that it’s just another type of chair, you try sitting on it and gradually learn how it operates – how much rocking you like, how much give each side allows, etc. This is analogous to the long acclimation phase of learning to program – deciphering what error messages mean, how data structures behave, what kind of commands are expected, and so forth.

Finally, as you accept ErgoErgo’s new definition of what a chair can mean, you grow comfortable in its use – turning something that was strange and unfamiliar moments ago into something you totally understand. It goes without saying that the programming equivalent to this stage is rather long, but the metaphor is already complete. Something that once beguiled you as intimidating or impossible is now something eminently knowable, with time and experience the only obstacles to an increased understanding.

The entire process of encountering, evaluating, interacting and experimenting with them is a perfect metaphor for learning to program.

A major part of becoming a programmer is mental. The mental shift from “I need a programmer to help me” when faced with a technical problem to “I can figure this out” is an important one; the transition from being frustrated with code defects to being driven by curiosity to find the problem is critical in staying motivated to improve.

As much as I may be reading into this, and as off-the-wall a metaphor it may seem, having these odd chairs around as I’m trying to mold myself into a programmer is a constant reminder that what may seem unfamiliar and alien one day may become familiar, welcome and fun the next.

Flatiron Students Present

Yesterday evening, we kicked off this semester’s weekly student presentations. Every Flatiron student has to give at least one technical presentation while they’re here. There’s pretty much no getting out of it, but last night’s presenters had the reckless audacity to go first. It’s kind of a big deal considering they’ve only been coding for a month, and, of course, they did an incredible job.

Here’s the evidence:

iOS student Tarik Fayad presented his music player, which played us music.

image

Ruby students Spencer Tang and Edward Warren used the Yelp API to give us timely restaurant recommendations.

image

Web Fellows Yaritza Rodriguez and Rebecca Poulson broke down a GET request and explained the Internet. 

image

And Amber Tunnell and Ben Shore made Ruby gems.

image

Then when we remembered that they’d only been doing this for a month, we were all like:

image

We can’t wait to see what everyone else gets up to! A few students will present every Tuesday until the semester’s over and we can’t actually make them do it anymore (though they usually keep presenting at Meetups and conferences!). In addition to Flatiron Presents, we’ve got a lot of free, public events happening soon. Feel free to take a look at our Meetup page and stop by!

Tonight we’re talking Swift. So if you’re an iOS developer, RSVP to come learn with us and get approximately 2 hours of Swift experience.

Thank you, NYC

Flatiron Loves NYC

We are thrilled that The New York Times chatted with recent alum Jahmil Eady about her experience with the NYC Web Development Fellowship. The program is incredibly special to us, and it’s awesome to comb through tweets to see Jahmil’s story excite and inspire people—mostly because of how deeply it excites and inspires us.

The Fellowship is just one of so many amazing initiatives made possible by NYC Workforce1 and the NYC Department of Small Business Services. Both the Bloomberg and DeBlasio administrations have made enormous strides in workforce development in the innovation sector and in making technology accessible to all New Yorkers.

We feel incredibly lucky to be a part of their plans and to help them make our city even better. Thanks to their help, guidance, and foresight, we’ve been able to offer a programming education to great people, totally free of charge. It’s been an amazing experience, and we can’t wait to accomplish even more together. Thanks, NYC, for making this possible!

Project Recap: GemifyJS

Sunwoo and Wontae both picked up programming to make their respective workplaces more efficient with code. They’ve only recently graduated from Flatiron’s full-time Ruby course, but they’re already able to save other programmers a lot of time, too. As students, they built a development tool called GemifyJS to help developers create and manage Rails gems. And it seems to be useful.



How it Started

Sunwoo was a marketing intern who’d traveled around Asia teaching English, and Wontae worked as an architect for 5 years before deciding to start programming full-time. Both initially started to fill in gaps in non-technical positions.

“I started learning Ruby on Rails, so my company could roll out features faster,” Sunwoo explained. After learning enough on his own to take an internship in web development, he realized that getting the fundamentals weren’t as hard as he’d thought. “It’s made out to be incredibly difficult and inaccessible,” he explained. “It is sometimes, but I didn’t realize that if you can understand the basics, you actually already know enough to make a web app that does something cool.”

“It’s made out to be incredibly difficult and inaccessible. It is sometimes, but… if you can understand the basics, you actually already know enough to make a web app that does something cool.”



As an architect, Wontae was tasked with creating a database of building materials. He signed up for Codeacademy, and enjoyed a new, more objective way of approaching problems. “I like programming because there are a lot of ways to get to the same solution, but in the end it’s either solved or not solved,” he explained.

“I like programming because there are a lot of ways to get to the same solution, but in the end it’s either solved or not solved.”



Because they both started coding to make their jobs easier, it seems natural that they’d work together on a project that can help programmers be better at theirs.



How it Works

“There are plenty of gems around that developers can use to augment their projects, but a lot of the newer CSS and Javascript libraries don’t have the rails gem equivalent,” said Sunwoo. If developers want to use the libraries with Rails, they would have to take time away from the task at hand, see how the libraries are formatted, and manually create the gems..

Initially developed over two weeks, GemifyJS simplifies this often-frustrating process of sharing front-end assets. Users just drag and drop their files into the application, which then packages them into gems that are compatible with the Rails asset pipeline, and pushes them to the user’s Github repository. The gem is then instantly available for developers to add to their projects with just one line of code.

Highlights

Work on GemifyJS naturally divided between front-end and back-end. Each area came with its own challenges—like learning how to manage problematic gems and how to build the app so that it naturally felt like one page. Sunwoo and Wontae had to work through a lot of technical problems that extended beyond what they were studying, but even less technical challenges come with big learnings.

Wontae drew on his experience as an architect to inform the UX for GemifyJS, and found that it didn’t always apply. “Like in designing for the web, architects are always very worried about a user’s flow through a space, but in programming, the medium is very different.” With user feedback rolling in, he had to adopt a new way of thinking about design and adjust the front-end to reflect what users were actually expecting. “I found it quite challenging,” he added, “It was a fun experience.”

What’s Next

Since they graduated from Flatiron School, Wontae and Sunwoo both started working as full-time developers at Cardflight and AlphaSights, respectively. So making improvements to the app (rather than growing its user base) is now a side project. “At the moment it does what it’s supposed to do well, but it’s not perfect,” said Sunwoo. Once the two finish their improvements, they’d like to start actually marketing it. “Honestly, it’s useful app that can save people time,” said Sunwoo, “I use it, and we had a lot of fun making it.” As the library of gems they maintain grows, GemifyJS will only get more useful.

“Honestly, it’s a useful app that can save people time, and we had a lot of fun making it.”


GemifyJS is also open source, so feel free to fork and contribute!

Team

Sunwoo
Blog
Twitter

Wontae
Blog
Twitter

Technologies

Ruby on Rails, including a custom Rails generator
Javascript

Alums Win LOLs at Comedy Hack Day

If Flatiron School alums weren’t as funny as they are super-talented, we wouldn’t see them hanging around hilarious coding events with armfuls of trophies. But, hey, guess what they did last weekend. They won Comedy Hack Day.


All images from comedyhackday.org

Grand Prize

Ruby 004 alum Daniel Fenjves teamed up with fellow devs Dustin Nelson and Kito Pastorino to win the grand prize with Timesify. It’s an app that makes browsing listicles and goat pics less horrifically ego-damaging than usual by cleverly disguising them as New York Times articles.

Just drag Timesify into your browser bar and feel great about reading even the most ridiculous click-bait. Best of all, it provides a tl;dr snippet of a real news article. So you can BS your way back to those doge-themed pick up lines.

Timesify also took home most hilarious use of its API and People’s Choice awards.

Finalist

BK 000 alum Sarah Ransohoff worked with Zoe Daniels and Alyssa Varner to snag a finalist position with Dad 2.0—a generator of vaguely supportive advice for common life crises. It also generates some unexpected fashion tips, if you think a purse will do the trick.

As always, we’re stoked to see alums making awesome things. But it seems like everyone’s a winner at an event where code and comedy go together like Kimye.