chronicdi-blog

[chronicdi-blog]

Phase 3 @ Dev Academy

The last three weeks of dev academy are a change of pace, the dynamics between the students and teachers becomes more like that of senior developer - junior developer or master - apprentice. This is intentional and engineered by the academy to create a transition phase between the academy learning environment to industry work environment.

For myself this has been a great time, as I don't particularly like the student - teacher relationship (reminds me too much of school) and prefer the master - apprentice relationship which previously I had only experienced in WMA (Western Martial Arts).

During this time there was a focus on bigger projects and pushing ourselves to understand other technologies. The students got to take different directions to each other, focusing on backend or frontend. Our forays into APIs in phase two paid off here as the backenders were able to develop an API and publish the documentation for the frontend folk to than consume and use.

It was exciting to see the students split into different teams that ran independent of each other while having the common goal of producing a functional app at the end. This was represented in the tickets on the KanBan boards of each team.

While this phase was extremely busy and tiring, finishing off the apps by the week deadline was exhausting and for the final week project we each pulled out the stops and worked long hours, stretching ourselves and reaching for ever more challenging learning goals. My team, The Borrowers, developed a web app that gave you the power to operate your own library. Lending books to friends only to be forgotten and lost will never be a problem again.

This was fantastic, a great final challenge to test our understandings for holes and build upon our foundation of knowledge. My primary focus during this time was on having fun and working efficiently with my team, cultivating a positive and constructive team culture and stretching my understanding of javascript. Our product was built with a Ruby on Rails backend that gave me the opportunity to see the similarity between C# and Ruby code. We also stretched ourselves to deploy our application onto mobiles using Adobe Phonegap. This was fantastic and after learning about the technology surprisingly easy.

Phonegap allows you to take an html, css and js based application and package it as a distributable app for each of the common mobile platforms. In essence the service does two things:

It packages the app into a cut down browser that may be distributed as an installable app.

It provides an API layer for interacting with the phones/devices services. eg contacts and camera.

My final achievement during this last week was novicing git. I consider that there is far more to learn about version control but during this week I started to feel comfortable with managing our teams two repos, resolving merge conflicts and undoing boo boos. Going forward I would like to learn about continuous integration and continuous deployment.

All in all attending and succeeding at EDA has been one of the greatest adventures and life altering decisions I have made. Because more than teaching me to code it has taught me how to work better and understand others. The knowledge around emotional empathy I have gained is invaluable and has fundamentally changed the way I see the world.

I will continue to pursue developing these soft skills along with my programming skills, as for me they are of equal importance.

[chronicdi-blog]

How APIs made me write better code

Application Programming Interfaces - hence API, were introduced to us this week. It took a while to grasp what it meant and how they may be of use. The reason is (In my opinion) that it has two distinct meanings. One is the abstraction of creating an interface for a given object, which can be easily applied to reality. eg we interact with a car through the interface of the dashboard. It is a point where one type of thing can interact with another in a predefined and prescribed way.

Then there is the other meaning of API, the practical way or writing it in any given language/framework and what it means to be interacted with from either server side or client side. This distinction seems obvious now, but at first it was hard to reconcile learning how the code I wrote was related to the abstraction.

Now I cant get enough of APIs they just make sense, there is a pattern for writing code called the façade pattern, the idea of creating façades to your code much like you would for a building. Effectively each façade becomes a place of interaction with the outside world while it conceals the inner workings of the building. To continue the analogy the building may be a mammoth archiving warehouse and the façade a single door going in and another out. This might represent a data structure with a read/write function on the API. From the outside world all we can see are these two doors - entry and exit. Boxes of files go in and are later retrieved when needed.

You may also use a façade internally to divide up the workings of the warehouse. This could be seen as the various departments of a factory. In a car factory the paint department effectively has a two door entry/write and exit/read façade. To the other departments they don't care what's going on in the department only that if they push a car towards into it at a given time later it can be retrieved or sent back painted. This is basically an API for a sub program. The scope of the analogy can be shrunk down until you have a single method that does a single function, in effect the methods name is the API to the rest of the program and defines how it will be interacted with.

So why the fuss? How does this warrant a whole week of focus inside the boot camp and this corresponding blog post. Well its simple - to write an API is more work and adds an extra level of complexity to the code. However it is definitely worth it, WebApps use the HTTP application protocol and allow developers to define API façades that enable other programs to interact with theirs. The Google maps api is what allows many other webseverices to use Google maps with custom elements for their own service. Amazon heavily uses APIs internally allowing for interactivity between departments as well as external software. APIs make code more usable/easier to maintain and allow for unpredicted uses from the outside of the façade.

For myself the unpredictability of how a web API will get consumed is the exciting part. It gives the code an almost organic quality as its uses adapt and grow. In a way APIs and the façade pattern are simply bio-mimicry of how the natural/physical world works. Surfaces/skins are the interfaces between the internal and external in everything.

[chronicdi-blog]

Forays into JavaScript and how the rug got pulled out from under me

Week 5, JavaScript week.

I had ben looking forward to this week, anticipating it as a break from the frustrations of Orms and my sparse understanding of Asp.Net. It was also a week where the C# students and Ruby students would inter-mingle and pair with each other on JavaScript challenges.

In the beginning I was happy, in fact looking around the room I noted a sense of excitement and perhaps hopefulness among the students. Finally we get to work with the more familiar, as JavaScript is something we have all experienced in web browsers.

My fellow student (a Rubyest) and I started the first challenge with gusto and quickly realised that we were sailing on a very rickety ship of knowledge into the deep ocean of Dev Academy JavaScript challenges.

This pattern proved to continue for the rest of the week, our confusion was often around translating what we knew in Ruby and C# into JavaScript. This was fascinating as we were learning about the similarities between the two core languages and the specific differences between them and JavaScript.

The most important and allusive to grasp was the implication of what it means for a language to be a functional programming language. On the last day of the week I was working on a mostly JavaScript ClientSide app. I was trying to create a well defined seam/gap between the object that contained my application logic and that which contained my data read/write logic. This way the read/write logic could be easily altered later for talking to a different database. My goal was for the logic object have a very loose coupling/dependency on the read/write object and for the read/write object to have no reference to the logic object. This is how I have been coding in such arrangements in C#.

I discovered that though I could write the code it did not function as expected, as JavaScript runs asynchronously the methods in the read/write model would be called and then the next method after that. This meant that by the time the called method returned the requested data it would be to late as the function that needed it had already run with no data. To get around this I simply had to write in the read/write method which method to call next, though this meant the read/write object was more tied to the logic object than I originally planned.

It felt wonderful to have this understanding and made JavaScript make far more sense to me.

I find the idea of many little methods running in tandem rather fascinating, a complex program becomes a collage of many moving parts where as with procedural programming there is a sense of what is happening. An analogy would be that functional programming is like a painting that paints itself, where as procedural programs are painted by a brush. In one no part is aware of another, in the other the brush tracks every stroke.

Note: I was going to make a reference to Santa's North Pole factory running autonomously or with his guidance but felt the painting analogy had more panache.

[chronicdi-blog]

The yellow brick road of ASP.Net and the MVC Framework

This week I was (finally) introduced to ASP.net and developing projects from the starting point of the MVC project template that exists in Visual Studio.

However my delight was quickly quenched when I realised this was a two edged sword, for though I now got to develop from the starting point of a framework, it meant i had to go and learn how the framework actually worked.

Once you start a project you are given a whole bunch of folders with various files in them, including bootstrap styling some example pages, a login system with associated files to save the user information to a database and jQuery and some other scripts.

After discovering this my first order of business was to learn about the framework and understand what and where things were happening. The hardest thread to follow was the login system. Out of the box the framework provides encryption and authentication as well as several tables for managing saving the users profile information. This is great until you want to interact with the data in a way not defined in the framework scope, i.e. logging in. My pair buddy and I worked on creating a one-to-one relationship between the built in user table and a new table that we could define new fields in. This way we could add things like favourite band, best day of the week and profile image. This felt like it took an age to get to work, we had to work out where we could piggy back off of the MVC framework so as to get the current user information.

The end of the week was great, we had made a functioning messaging page (think twitter core functionality). It was a grand Aha moment and was the first time I saw everything just click together and work. We had deployed the app to Azure hosting, so it could be said we had completed the nose to tail feast of web app development.

In the Emotional Empathy and Emotional Intelligence classes and discussions this week I realised why I was struggling to pair with my fellow students on tasks, Unfortunately my skill toolbox for this was last used and ruined at University where I had studied architecture. Over the years I had many group assignments and a theme emerged: the students were relied on to distribute work among themselves, organise team structure and facilitate logistics for themselves. I found that this chaotic situation time and again led to the inevitable: students not pitching up when needed and not doing what they had said they would.

Now it wasn't all bad, but my overall experience was that to finish projects required that I take a team leader roll, lead by example and be involved in every facet of the project as contributor and manager. This allowed me to assist my fellows at any point in time and if necessary pick-up some of the responsibility. The side effect was that this became my de facto behaviour for collaborative study environments.

My experience at Dev Academy has been very different to this. At first pairing was rather painful, there were other factors but my broken skillbox definitely contributed to making the pairing sessions very tiring. However its all over, after becoming concious of this I became very proactive in changing the status quo, my conscious model for the collaborative skillbox is that it is constantly evolving. Pairing is now enjoyable and productive with far better focus.

Though the lectures and discussions have been very helpful with puzzling this out, the primary motivator and informer was the feedback I was receiving from my fellow students. So a big thank you to them for helping me grow, having the patience and integrity needed and investing their energy in helping me.

[chronicdi-blog]

To build an Orm or not to build an Orm

Our task this week was to create our own ORM (Object Relational Mapper) which is a collection of files in the project that contain all the information and functions needed to talk to a database and perform operations on the data set.

For this we used Ado.net (a set of components we can use to access the database) and though we managed to make all four of the C.R.U.D. operations:

Create

Read

Update

Delete

It became obvious that this was rather painful and that we had made a litany of mistakes. The most interesting was that our code was insecure and allowed SQL commands to be written and passed to the database, this is commonly known as SQL Injection and is very, very bad. The result is that a user may intentionally or unintentionally send a command to the database that irrevocably changes it. Including deleting all the data!

Of course our database was full of dummy data and so it didn’t matter when we purposely changed it. There was even a certain amount of excitement and feeling of power that could be had in it.

A day passed and in the morning the C# student crowded into a little room that would become our learning rocket that would take us to Lightspeed ORM and beyond. (For those not understanding my corny analogy, Enspiral Dev Academy has a rocket ship as a symbol)

Lightspeed makes Ado.net seem like a old painful memory, all the finicky things are sorted out and it is full of promise of a brighter future of easy access to the database. Unfortunately it is a little harder than that and for a junior developer (first time i have referred to myself like that - feels good!). Perhaps it was that my expectations for what it would do were far higher than what it actually does or that I did not want to invest the time to learn how to use it as I was single minded in my pursuit of learning C# and the .net framework. In any case after receiving some help from the C# coach Darcy I managed to wrangle an understanding of what was going on with this runaway rocket ship traveling at Lightspeed (what terrible Humour !).

After gaining control of Lightspeed we started to write applications that persist data to a database rather than having it disappear between sessions of running the application. This was very exciting as it is the beginning of making more complex solutions.

[chronicdi-blog]

Got to catch that feedback fairy

Feedback is important in our society and culture, it is the returning of pertinent communication on feelings and thoughts to the source or controller. Humans do not possess a natural sense for this and so by necessity have relied on language and the five senses to facilitate it. However by its nature this hybrid communication is interpretative and so can be misinterpreted.

This is a surprisingly big problem, small misunderstandings can, and have, become the seed for conflict at a later date. Over the years societies have developed a tool box of coping strategies for there members that we all pick up over years, for a group of people by themselves in an unchanging world this might work. However when a group is comprised of people with differing social backgrounds the coping strategies are no longer that of the group, but rather that of the individual. They may synergise, but more likely have core differences that will need to be addressed for them to be used. This is made harder for those involved who have never articulated nor thought upon this.

Coping strategies include those for giving feedback to one another. Things like a scowl, shouting out "Not cool Bro" or ignoring someone are all ways that i recognise as strategies I have picked up over the years, there must be many others.

Unfortunately our societies have for many years pursued efficiency as a virtue and it has become entrenched as an ideal that should be striven for at all times. It resonates with the feeling that time passes to quickly and so being efficient feels like a valuable and time saving value/attitude to have.

The fallout from this is that we tend to see investing time in bettering our understanding of others and their understanding of ourselves as to time costly and so focus on the easier task of improving our one directional communication skills eg talking to a group.

At Enspiral Dev Academy I have been encouraged and had the opportunity to learn and experiment with giving formal feedback to my fellow students. Specifically we are asked to follow a pattern of providing A.S.K. feedback:

A The feedback should be actionable, i.e. the receiver of the feedback should be able to discern how they might change their behaviors so they may improve their ability to work with others in the future.

S The feedback should be specific, i.e. the receiver of the feedback should be able to understand the point of the feedback. If it is vague it will just create confusion.

K The feedback should be Kind, i.e. the giver of the feedback should respect the other person and work on the assumption that the other person is a rational human being who is interested in developing their pairing/teamwork skills.

This has been a very interesting time (and its not yet over!) and I have found that to my surprise I am not as good at teamwork as I had thought. I also noticed I was less flexible in paring as I had considered my ability to work with others a feather in my hat and so did not question how I might improve. I now approach it as an evolving skill set with only the practice of giving and receiving feedback being a permanent skill. One that I must practice.

[chronicdi-blog]

Rhythm and Blues @ EDA

0440/4.40/4hrs and 40 min am…

The sleep cycle alarm on my phone starts up. It fades in and out trying to pull me out of sleep, I reach out and toss it a foot in the air to the bottom of the bed. The accelerometer kicks in and puts it on snooze, at least for 2 minutes then it starts its rhythmic insistence that i rise from my slumber.

This is the start of my day at Enspiral Dev Academy.

After meandering in and out of the shower I assemble a bowl of three Oatbix (they are so much better then normal Wheatbix!) to the tune of the ugly thrumming sound omitted from my espresso machine as it ever so slowly drips out the black cure to my droopy eyed demeanor.

At about 5.30 with coffee and breakfast in hand I jump in the car and drive into Wellington City, heading for the end of Oriental Parade where I plan to park the car. As I drive in I am always struck by how few cars there are on the road, I know people think it is horribly early, but i would of thought there would be more people that like myself hate traffic and rush hour more.

By 6.00 I am at the end of the Parade where the Coupon Parking zone ends and it becomes free parking. I park the car, wind down the window, tune in to New Zealand National Radio with the volume nice and loud. I jump out the car feeling good because I now get to eat my Oatbix and drink my coffee while overlooking Wellington Harbour across to Eastbourne in the East while the morning sun has yet to make an appearance but plays with colours of the sky.

6.15ish I open the boot and pull out my folding bicycle and make my way to the academy, a very easy 15 minute ride around the esplanade and past TePapa Museum.

By 6.45 I have arrived at the academy, I have about one and a half hours until everyone arrives. I spend the first 15 minutes learning to play an Irish Bodrhan that was on a shelf of the academy, I have learned two beats so far and hope to be able to play more musically by the end of the coarse. Next I sit and practice mindfulness meditation for 10 minutes, after which its coffee time and I have about an hour remaining.

I spend the next hour reviewing the previous days work, looking over the current days challenges or reading up on different concepts I am learning.

By 8.45 everyone has arrived and we hear a light gong sound signifying it is time to check-in with your coarse accountability buddies. There are many different groups we break into on any given day for learning, but your buddy group is the most constant.

After the buddy check-in the gong sounds again and we all make our way into a side room for our first lecture of the day.

After this the day flies - we learn so much and practice even more. We are constantly trying new things and just when you think you have a handle on something the next “thing” to learn and try appears, as if conjured by an evil omnipresence(not pointing any fingers) that will not let you rest.

We break for a long lunch but I often find I am drawn back to the computer to carry on learning. Some days we also have a yoga class just before, which is great! I definitely feel looser, before I came on to the coarse I was concerned with getting a sore back from all thesitting. But thanks to the yoga and cycling every day this has not happened.

14.00 the gong sounds and we have our afternoon lecture. In the first week I found my energy levels dropping off at about this point. However by the second week this was no longer a problem.

18.00 marks the end to the day. The coaches go home and in come a couple of tutors to help you in the evening. These are often previous students who know what it is you are going through and provide a different perspective (one closer to your own) from the coaches.

I continue to work on the days challenges or read until about 21.00 at which point I pack up, I make my way home and find I am typically in the kitchen scrounging for food at about 21.30.

22.00 The day ends as I meander from the shower back to bed and go to sleep ready for the new day.

For myself this rhythem is only sustainable as long as I have a good rest on the weekend. More than anything I am happy, everyone of us needs to work on our rhythem so as to maximise our learning environment. Mine focuses on rising earlier and having an absolute time I work until. During the day you pace yourself and take many breaks, at the moment they are for tea, honey, ginger and lemon drinks for the winter blues.

[chronicdi-blog]

Week one @ Enspiral Dev Academy [The Boot Camp Edition]

Looking back over the last week is a little scary, we did so many things and i learned a many new things. It makes me a little dizzy trying to remember everything! The reality is I know i can't and that is why reflecting upon it is so important. The other very apparent theme of the last week has been how energized I feel, sometimes its tiring when you are in the trenches of a new coding problem, but then you peak up and out see the other students constructive energy crackling in the air. I feel it keenly, a hunger for knowing, understanding and driving towards a solution.

Another very obvious quality of the learning environment is how collaborative it is, there is no holding back of knowledge or input, if you can aid some one in their understanding you do so and you expect and rely on that same support from others. This is in stark contrast of the learning environments i have been through at university and before that my schooling. Yesterday i was speaking with another student listening to how he was tackling a problem and and giving my opinion on different parts, by comparison back in 6th form (age 17) I have a clear memory of choosing not to help a student next to me in math as it would mean they would get a lesser grade and i would be more likely to get a good grade (schools were allocated a certain number of each grade level to hand out). I have regretted that moment ever since and have tried to never repeat it. Here at EDA i dont even have to think about it, I can help and be helped as much as I can/need.

At EDA i feel very balanced, there is a very conscious emphasis placed on creating a balanced environment, the students and coaches are all encouraged (and do) to eat well, exercise, understand ourselves, understand others, create the space we need to learn, ask questions, sleep and feel good. I can report - it works! For the last few years i have been learning working with designing and coding websites. I quickly realised there was a glass ceiling for what i could learn. I spent hours trying to understand a given concept where as here at EDA it is situation that simply cannot occur, firstly you may discuss it with fellow students and if that does not resolve it you may ask your coach. This dual layer support for answering questions allows me to maintain a far higher rate of learnings per hour then previously possible.

This week also introduced Engineering Empathy, a new approach to investigating ourselves and how we perceive and react to others. In one of the classes Joshua Vial (one of our coaches) roughly said "One of things we are trying to do is reconcile our conscious beliefs with our unconscious behaviors", which may be applied our singular self or to a group we belong to. eg. Our family. For me this summarizes the EE studies of this week which has been focused on diversity, however I think it can be applied in a broader context.

The final challenge of the week was to write a Sudoku solver, this was fantastic! I got to take all I had learned in the week and apply it in to make a algorithm solver. My pair buddy Linden and I worked through the challenge making mistakes and melding our ideas to produce something that worked! Well at least for Sudoku that didn't require guessing. It was so rewarding to see that our logic worked, though midway through we already knew we were on the right track and it was just a matter of diligently debugging. A skill I plan to spend time honing.

Its now Monday of week two and we are just kicking off the day. I am feeling good and looking forward to learning, growing and making friends.