October 2015 – Mongolian Princess Codes

Week 3 – Day 12 & 13

What the heck does capybara have to do with Sinatra? Maybe they both like donuts?

Well…they are both gems, and free!

I am continuously amused by the variety of wicked names for gems that we come across in the coding world. For those of you who are new to software development, gems are libraries that make developers’ life so much easier.

As a visual learner, I found it really difficult to grasp the ‘big picture’ when we are learning the concept of web development . There are so many different components and frameworks – honestly I struggled to picture how they ‘talk’ and relate to each other. The below diagram is an example of said attempt to understand how everything fit together.

Today I Learned

Web application is very much a request and response mechanism between the client and the server, period.

The client is usually the browser (sends request), and the server (receives request and send response back) can either be a remote server in another part of the world, or it can be a local server on your computer. This week we are learning to use Sinatra (not the jazz singer) as a web framework that enables us to write our web application, acting as the local host. Words on the street says that Sinatra is lean but powerful, when compared to other ruby based web frameworks, such as Rails. Guess we will find out later in the course when we play with Rails but I have done my due diligent research.

TDD to BDD

Continuing the practice of Test Driven Development, in which every line of code we write is conceived first with a test, we are testing that our web application works with Rspec, which speaks ruby to Capybara, who then talk to many different web automated drivers to execute the tests we have written.

We are working on a fun challenge that makes a battle game, (an un-animated dumbed down version of street fighters) between two players, where one can attack by pressing a button.

It’s very interesting how we are writing the tests now that’s largely driven by the behaviours of how a user would interact with the application. It takes a little while to get used to writing tests in Capybara syntax, though I find it very helpful to break down the user story and picture how I would have wanted to use the application step by step with a diagram.

It’s sort of like walking through the different rooms of a house, it’s all about how one moves about and interact in different spaces.

Daily Inspiration

Wow, there is no way I could have written the above at the beginning of the day, when all my research led to funny youtube videos such as capybara being punched double fisted by a monkey.

I am sure the afternoon sleep meditation was a huge bonus to today’s productive learning, a special Wednesday treat.

Today no one snored, or at least I didn’t wake myself up. 🙂

Week 3 – Day 11

Weekends are basically non existent at Maker’s Academy, thanks to the weekend challenges. If anything, it’s more like a long drawn out day of coding in isolation with no one to ask questions to, though perfect timing for doing some much needed laundry + assuring your loved ones that you are still on planet earth.

The past weekend we worked on the takeaway challenge that sends a completed order via text message using Twilio API. It’s really neat seeing how ruby can be integrated to something that’s got functionality and more resembling what we actually use in real life.

Speaking of context, I think by end of week 2 we are finally ready to step outside of our little sand box for coding toddlers, into the playground of monkey bars & slides for the ‘big kids’.

I only hope that there are no bullying in the playground.

Introduction to the Web

Week 3 kicked off in a new direction – we are moving from Test Driven Development and Object Oriented Programming into web development. I am really excited to be one step closer to ~~world domination~~ building more tangible projects that have real world applications. The web is where the magic of code gets unleashed into the world.

It’s incredible how little we know about the autonomy of the web and what actually happens behind the scene, considering how much our lives revolve around the web and the internet.

The Anatomy of URL

Here is a beautiful diagram that illustrates the autonomy of an URL, courtesy of Blair Millen’s awesome blog post.

A picture is worth a thousand word.

In the context of digesting mountains of technical reading while learning to code, you really come to appreciate beautiful diagrams that’s so powerful in its simplicity. If anyone is reading this and considering joining Makers, it’s worth it improving your speed reading skills because there is just so much material to read!

Pairing of the Day

When I first met Fergus I had to make sure he wasn’t related to Liz Lemon from 30 Rock. Not only was he the most awesome Lemon I know in real life, I had an amazing day and sharing makes the world go round !

Week 2 – Day 10

The future of Teal Organizations

At Makers, Friday means many special things. One is lunchtime Pecha Kucha talk by any fellow makers on any topic they are passionate about, followed by the afternoon cohort retrospective that ends with a cold hard earned beer at 4pm to wrap up yet another week of intense learning. We makers work hard and play hard.

I will start with the inspiring lunchtime talk by Evgeny, the CEO of Maker’s Academy, who shared the secret behind Maker’s success based on the concept of a teal organizations, best described by Frederic Laloux’s book ‘Reinventing Organizations’.

I’d never thought that a topic on how organizations evolved would have ignited such passionate discussions in the audience. Is it possible that through hundreds of years of evolution, our current day default ‘orange’ organizations aka efficient money making machine can evolve to the next level of ‘teal’ organization that functions entirely based on Trust and alignment of values centred on personal growth?

Pairing of the Day

It’s a threesome! We lost Alaan by the end of the day so Eleni timingly stepped in for the group photo with George and myself.

Columns are good for bracing yourself if you ever feel light headed while pairing!

Week 2 – Day 9

TLC of Dependency Injection

“We might need a little Dependency Injection over there”, my pair partner said casually, as we tried to wrap our brains around refactoring(the process of editing code) and keeping track of the design of our code/classes.

So why do we care about dependency injection in the process of writing good code? In a short answer, it decouples the class objects so changes made to one class’s behaviours will not directly change another object that it is linked to. Essentially, dependency injection means giving an object its instance variables (this is a ultra short explanation).

The benefit of practicing dependency injection means that the structure of the code is independently functional, or as loosely coupled as possible, so that the program has a level of flexibility to change over time without dependencies that can cripple the entire code base.

I’d like to think of it as a building with seismic proof structure that has movable joints – the the building has structural elements that are linked together, but each part can fail or change independently to reduce the impact of damage as a whole.

Pairing of the day

Julien and I would like to introduce our new family member : the fake-breathing-puppy who has been calmly purring in the background while we struggled with class extraction and dependency injection, real fun stuff.

Julien, I love our little pairing family for the day.

Week 2 – Day 8

Protect yourself with Encapsulation

Encapsulation in a nutshell is a way of wrapping up data within a class object itself so that you don’t get a knock-on affect of changing one element of a section of code that will change the behaviour of your entire code. When code is well encapsulated, it’s like putting up a fire wall around its behaviours, so that any changes that we make will only affect the behaviours contained within the wall. In the context of a system of complicated code, it’s like we have a well fire compartmentalized building, where fire hazard can be monitored and control within each room.

Encapsulation has benefits in avoiding interdependencies by restricting access to data that you don’t want the public to access. In general this is good practice to avoid changing one thing and breaking the rest of your code that reinforces the Single Responsibility Principle that we talked about yesterday.

Here is an example of not so well encapsulated code that contains the recipe to making the perfect cup of coffee

Here we have put the recipe ratio into its own separate class and restricted accessing this information by changing attr_accessor to attr_reader to have only read capacity.

Pairing of the Day

Raphael recounted, “We didn’t get very far with the challenge today… we were waiting for the pony to show us what to do”

Week 2 – Day 7 – Single Responsibility Principle

What is Single Responsibility Principle?

Has anyone ever tell you to do one thing well at a time? That’s basically the principle that we want to adhere to when we structure our code – that each class is only responsible for one functionality, and nothing more. This minimizes interdependencies and flexibility in future changes or bug fixing.

Consider the following examples. I have made myself as a class, and created a method ‘happy’ in the context of having dinner. The happy method will throw an error message “I am still hungry!” if a randomly generated number is less than 5. However, since many external elements can make Mongolian Princess happy or unhappy (such as food, weather or people) it violates the single responsibility principle.

Here is a better example where I actually created a separate class ‘Meal’ containing the dinner? and dinner_randomizer methods.

Vuuuuala! It’s all about keeping each class object happy doing one thing at a time!

Pairing of the day

Inspired by this spooning technique for pair programming, I had the idea of making a photo documentary of my pair partners everyday at Makers. It’s amazing how it only took 7 days to feel like I have an extended family at Makers for life – and I look forward to pairing with each and everyone of them. Today’s lucky winner is lovely Rebecca, who made sure I knew how to appreciate a proper cup of English tea as well as passing on the great idea to write feature tests in a separate ruby file to track our code progress.

Week 2 – Day 6 – Keep calm while crashing and burning it

I never thought the today was going to unfold the way it did. In hindsight, it was the perfect storm.

It was 2 minutes to our 9:00am weekend challenge deadline, and I was already a stress ball frantically scrambling to submit the pull request for the airplane challenge(that I didn’t manage to complete), while pretending to be a cool cucumber as my fellow classmates rolled in /made small chats over breakfast. The weekend challenge was an extension of the Boris Bike challenge that we worked on last week while pairing, and was meant to be completed on our own. Yes, you heard me right, there was no pair partner to ‘put two heads together’. Although we can google and make reference to all the books and materials available, I have to say that coding in isolation feels like being lost in the wild, naked.

Code Review

After our short morning standup, it was our first code review, going through the weekend challenge with the seniors. No big deal, right?

For all I know, code review is kind of like the stormy variable in the airport challenge – the weather is random, and when there is the 10% chance of storm – YOUR PLANE CAN’T TAKE OFF OR LAND. You quickly go from “I think I sort of know what I am doing”, to “I don’t even know what I don’t know”, that leaves you feeling ashamed having to explain your lousy code to someone who can see right through you. When asked why I did so and so, I had my mouth opening and closing like a gold-fish, not knowing what to say….

This is what (it felt like) happened after :

I was not the dragon, but what’s engulfed in flame…

Alright…. for those of you who knows me, I might tend to exaggerate my feelings slightly, but it’s just one of those days when you can literally watch yourself crash and burn into an emotional abyss.

Today I Learned

Giving yourself a break from the harsh voice of your inner dialogue is something easier said than done. I thought having gone through 8 years of architecture school would have hardened me into a fossil, but today I have learned that, crashing and burning after a design critique (typical trauma of architecture), was my default coping mechanism, and it doesn’t have to be that way.

I spent the rest of the day calming the storm within and made the conscious effort to seek out one on one time with Dana. At Makers, you quickly learn to be in tuned with what you need, so you can get to the resource / solution as quickly as possible. In my case, Dana’s invaluable insight reminded me that I am only the best that I can be and that’s enough and I love myself no matter what, even if my code sucks. I choose to be at peace with myself, because you can always refactor and make the code better.

Your Code != You

In programming syntax speak “!=” means “does not equal”.

Wrapping up my day with my super pair for the day, Aaron, who was patient and kind in saying to me “Go do you” when that meant sacrificing precious programming time. Thank you Aaron.

One Bricklane samosa and two beers after, plus some more therapeutic constant – laughing – out- loud pairing with Raphael (my potato man), going over the double method for rspec test in the airplane challenge – we are back in business ready to kick some ass.

Week 1 – Day 5 – First Friday Awesomeness!

PLAY is what we do all day & EVERYDAY at Makers

SPIKE gave a lunch time talk about Non Violent Communication

Daily Inspiration

Beautiful things that you build will only exist for a finite period of time, and will eventually be torn down, and you do it again – Sam Morgan

Our ‘Retro(spective)” review Friday afternoon as part of the Agile process – amazing way to share our collective successes, struggles and suggestions

Wisdom from the Senior

Don’t hesitate to ask the coaches to review your weekend challenge code that is solely yours -Philip

Make sure you give yourself permission every Friday night to relax and socialize with your cohort / seniors – their support is invaluable -Adrian

Battling it out on the Ping Pong table with the seniors to let off some steam at the end of week 1

Week 1 – Day 3 – Boris Bikes, STD and Promiscuous Pairing

The past couple of days have been intense, but the gorgeous autumn sun really helped and we have been busy working on a ~~music video~~ challenge in Ruby(a programming language) Boris Bike (perhaps we can add the video at the end of the challenge?!)

STD TDD

The Boris Bike challenge is designed to teach us the process of Test Driven Development, which in plain english, meant that we are to write our code first by breaking down what we want to achieve as the final result (Feature), by writing and failing baby step unit tests first (Rspec), using them as building blocks to write code that actually works. The full cycle of TDD goes from seeing your test fail (expected), to your test passing (after writing the actual code), to passing the final test in IRB (ruby environment) as a person would use it in real life. And you iterate the cycle over and over again.

It’s really counter intuitive at the beginning like you have to die first before given the parachute to fly, but it forces you to structure your thinking and approach to the problem while training your ability to troubleshoot when errors flare up (like wild fire all the time). At the end, it is an incredibly powerful practice/ process that results in more elegant code.

Well, after 48 hours of thinking, writing, saying ‘bike’ quadrillion times, this is what my brain sounds like at the moment:

Maker’s typical day routine

I am still trying to get a hang of a day’s rhythm, but it pretty much follows this pattern:

9:30am – Morning Stand up where we discuss any issues/ mainly concepts
10:00-12:30am – Pairing on the challenge
12:30pm – Lunch time talks from industry practitioner / alumni
2:00pm – Meditation with Dana
2:30pm – Afternoon Stand up
3:00pm-6:00pm – Some more pairing
6:00pm – ? Some more individual learning / goofing around

I find it really helpful to go through my notebooks and highlight questions that I encountered at the end of the day, ready for next day’s morning stand up.

What I learned today

Or rather, what is (promiscuous) pair programming?

Pair programming (sometimes referred to as peer programming) is an agile software development technique in which two programmers work as a pair together on one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed

Makers encourage ‘promiscuous‘ pair programming – my first reaction to this was “Do we need any protections?” Fear not. Apparently anything promiscuous without the risk of extracting STD is guaranteed safe and fun.

That’s the magic of pair programming! I got the opportunity to spend quality time with some talented individuals, Rob and Ivan over the past few day. It was a pleasure to pair with people who have different perspective & insights from you – it feels intimidating at first (like diving deep head first into someone’s brain, which is extremely personal), but very rewarding as a learning experience. The collaborative process (at times slow and frustrating) does improve the overall design and structure of your code by the end of the day!

DOs and DON’Ts of good pairing etiquette

Firs and foremost, always make sure you smell delicious for your partner, same for all the memorable moments in your life.

DO slow down & make sure both of you understand the concept
DO have patience and be gentle with your pair and most importantly with yourself
DO draw diagrams / visual aids for communication
DO use real life analogies and metaphors
DO listen, really listen
DO take breaks – 45min sprint is ideal

DON’T rush it, coz it will hurt later
DON’T be afraid to ask for help when you don’t get it
DON’T hug the keyboard when you are not driving
DON’T be intimidated if your pair knows more than you, this is the opportunity to extract their knowledge
DON’T get competitive or hold any preconceived judgement of your pair or of yourself

Striving to do exactly what I am told as a good student, I promised myself to be as promiscuous as I can at Makers everyday (sorry Dario), given all the incredible benefits of guaranteed fun at such low risk!

Daily Inspiration

And we end the day with a beautiful purple coloured sunset looking over the City’s skyline – what more can you ask for?

FullSizeRender_1 — I can see the beautiful roof of Bevis Mark, feeling proud of FPA’s great work and contemplating on where life will take me next

Day 1 – Back to school

How else can I describe my first day at Makers? Of course it started with getting no sleep at all, and the rest is history…

CAN'T SLEEP WHEN YOU NEED TO WAKE UP EARLY — **CAN’T SLEEP** WHEN YOU NEED TO WAKE UP EARLY ON AN IMPORTANT DAY ……

In retrospect, the day kicked off with tasty croissant breakfast (courtesy of Makers!) washed down with a cup of black coffee – you can feel the palpable energy and excitement amongst the fellow makers who will be embarking on this incredible journey together. Then we formally kicked off with introductions of ourselves, why we are here at Makers, and a naming game that gets us to remember everyone’s name and where they are from to build rapport and connections. Then we touched on the philosophy and organizational structure of Makers that emphasizes on the mindset of giving feed-back, transparency and compassion, which is very much embodied in the teaching method of peer learning. I find the concept extremely refreshing – it is self evident as you can feel the contagious level of enthusiasm and energy that seems to pour out of every single person at Makers, coaches and students alike. This is what being alive and switched on feels like.

Very interesting discussion ensued in the afternoon about what Knowledge Worker means:

Someone who quickly amass relevant information and create something new with it
Someone who is constantly learning & processing new information
Even senior developers spend 30% of their time researching
Junior developers spend 60% of their time researching
Learn how to learn

And most importantly – YOUR BRAIN WILL CHANGE

Friends1 — This is practically my reaction.

I suppose after you never get comfortable with getting stuck all the time…

I find it fascinating how much this resembles a philosophy of life more than anything else. Damn I am excited and terrified at the same time.

This is when Dana’s voice (the Chief Happiness Officer) comes in the background “Just relax into it”, which is exactly what we did to round off the day at a nearby local pub. Phhhewww, first day is over.