WDI with General Assembly

WARNING: Excessively long post. If you want the summary version instead...

I started to freak out about the post-WDI Meet and Greet event

Got an interview for a Node.js developer role

Got sick, started losing my voice and couldn't work on my portfolio and so freaked out some more

Had another inteview for a .Net MVC role (in C#)

Landed the Node.js role the day before the Meet and Greet so didn't have to attend! Phew!

We finished up our course on Wednesday (the 21st of May) and all of us headed off to Atlassian. We were first getting a guided tour of Atlassian's office space and then hanging out for SydJS in the evening (which is hosted at Atlassian). Joel was going to repeat his talk from JSConfAU at SydJS so we wanted to stay to support him… And also because they provide free beer and amazing pizza! 

Anyway, the Atlassian tour was very cool. They truly do have an amazing office space. It's in the Westpac building on the corner of Martin Place and George Street which is obviously prime real estate. The office itself is equally amazing with a stocked kitchen, plenty of beer fridges (including a mini bar with tap beers), a room with a table tennis table and pool table, a breakout area with an arcade machine complete with all emulators imaginable, bike racks on all floors and is just a nice environment all round. Every staff member also has a desk that can be elevated to allow them to work while standing and stretch their legs. Definitely a great place to work.

At the end of the tour we got to ask questions to the Atlassian staff to get a feel for the company and their culture. During this Q&A, Scott Farquhar (the co-founder) casually wandered into the room and answered a few of our questions. Most of the class didn't recognise him but I had seen him in an article not long back. Was nice to get a visit as I'm sure he's a very busy man!

After the tour, I got a call from an agent I had sent my resume earlier. I had a chat to him about my background and also what types of roles I was interested in. Initially I said to him I was interested in rails roles, but I then also mentioned that I was also interested in javascript developer roles (front end roles minus the excessive CSS). It was lucky I did. Having mentioned this he said, oh yea, I might have a javascript role coming up, I'll let you know. He was also attending SydJS so I had a brief chat to him during one of the breaks between talks.

SydJS was good and we all made the most of the beers and pizza. Joel's speech was predictably hilarious and well worth a watch. We finished up with a few beers afterwards at the pub before parting ways for the last time as a complete group (Erik and Mathilda were both off to Byron Bay).

I intended to spend the Thursday and Friday chilling out, playing games and doing as little coding as possible. But in reality I spent most of the day doing boring shit I'd neglected for months and applying for a few jobs. The weekend wasn't any less hectic as we had a wedding to attend on Saturday (a friend of Pavs) and then Pav flew out for Malaysia on the Sunday. Finally Monday and Tuesday I got a little time to relax before it suddenly dawned upon me... I've only got a week until the Meet and Greet the following Thursday (the 5th of June)!

The Meet and Greet event is something GA uses as a means to set up new graduates with work opportunities. Essentially they invite companies to come and see the work that we have done in class and we spend 3 hours talking to them, showing off our portfolio and trying to sell ourselves. They had 60 companies sign up for the event so it was likely to be pretty big. This is a great initiative but also requires a lot of preparation. So a week after finishing my course, I stopped stressing about my final project and moved on to freaking out about my portfolio. 

For the Meet and Greet, we each needed to prepare a personal portfolio site to show off our work and also touch up any issues with our projects. I knew this was going to be a lot of work, as although my projects were in fairly good shape, I'm not a designer and building an aesthetically pleasing portfolio was a scary prospect. Me and a few of my former classmates decided GA was a good place to get shit done distraction free, so most of the week I headed into class to work on my portfolio and hang out with them.

Around the middle of the week, I got a call back from the recruiter who asked me if I was interested in a role with a company called Prismatik for a role as a support developer in Node.js. I hadn't heard of the company but he told me they have very talented javascript developers working their and told me their sister company Thinkmill, built KeystoneJS (a Node.js CMS) and also the SydJS website.

I was immediately excited about the role. It felt strange to go for a role in Node when I had spent a good part of the 3 months learning Ruby on Rails. But I was excited at the prospect, as I knew Node was likely to be the next big thing and I really enjoy Javascript but had stayed well clear of Front End roles as writing CSS all day is not my idea of fun. I was concerned that I wouldn't get the role due to a lack of Node.js experience but this wasn't going to stop me from trying and I knew there aren't enough experienced Node developers around.

The interview got scheduled for Monday which was awesome, but also left me in a difficult position. I knew I had a lot left to do on my portfolio, but I also wanted to make sure I at least knew something about Node.js before my interview. Shit.... Naturally I chose the more interesting option and set about learning Node.js through the Code School tutorials. 

By Monday I felt like I knew enough to at least talk some Node speak. Literally just before the interview I got a phone call from Tarun (the careers guy from GA) who suggested I would be a good candidate for a role he was recruiting with. This was again in a language I wasn't familiar with, .Net MVC (C#). This role was with an amazing company and this made it appealing, but I was much less interested about the prospect of learning C# when compared to Node. He wanted to set up an interview and I asked that this happen after the Meet and Greet event (on the Thursday). He said that was fine but to keep him posted on my Node.js role in case this moved quickly. I agreed but thought it unlikely I'd get an offer after a single interview.

The interview with Prismatik went really well and by the end I was confident I would get an offer without a second interview. The interview was with the CEO who was just a nice genuine guy and seemed very interested in taking me on board. It definitely helped that I was eager to learn node.js and had already put in some personal time to do so (and have continued this afterwards also). I also briefly got shown the office space and introduced to the team. I left the interview feeling pretty elated and praying that the offer would come in!

Having had such a good interview however, I wanted to do the right thing and let Tarun know that this offer was likely to progress quickly. Because of this he wanted to move the interview forwards to Wednesday (the day before the Meet and Greet). This was super awkward as I knew I had so much to do on my portfolio but Tarun is a good guy and I felt I owed it to him to at least have the interview before I got the offer. So I agreed to the interview on Wednesday.

Right on queue on Tuesday night I started to get sick with the flu. I contemplated cancelling the interview Tuesday night but felt this would be a pretty shitty thing to do. So I rocked up to the interview in Green Square (which was a bit of hike), feeling like shit, having lost half my voice and was operating on very little sleep. The interview went very well and Bevan (the CTO) was also a nice guy and very knowledgable. He offered to setup a second interview to which I agreed, not wanting to reject any opportunities until I had signed a contract. I left the interview still feeling pretty shitty and so headed home to go back to sleep.

At this point things were not looking good for my portfolio. It was 3/4 finished but I just felt too shitty to keep working on it. But then, just in time, on Wednesday morning I got a call from the agent telling me the offer had come in from Prismatik. I was thrilled! I had given the other offer consideration but reached the conclusion that Prismatik was the company for me. I accepted the offer and immediately felt a huge wave of relief. The timing couldn't be better as having a part finished portfolio and only half my voice wasn't going to make for a successful Meet and Greet event for me.

So now what? Well this post has been WAYYY too long as it is, but maybe I'll look back on it one day to reflect on my time at GA. For me, the future is now Node and I can't wait to get started in my new role (on the 1st of July). Recently, I have a new idea for a continuation of this blog. In the lead up to my job and obviously once I start, learning Node is going to be a huge component. As such, I'm going to endeavour to post my Node learning experiences on Tumblr (in a seperate blog). Hopefully this will be of help to others who have intentions of learning Node.js also. 

So to summarise on backbone, I feel that if you know how to use a front end framework whether it is backbone, ember or angular, I would argue that there is no point in building static sites unless time is a constraint.

After we had moved on from the joys of backbone it was time for 'Computer Science week'. This was mostly devoted to how to write more efficient code and compare various algorithms. This brought back memories of 10 years prior studying COSC122 at university and the joys of linked lists, stacks and bubble sort.

Once Computer Science week was over it was on to our final projects. Unfortunately by this stage myself and most of my classmates had exhausted of our favourite app ideas and undertook projects that we were only semi-interested in. In my case, this was "ReviewMi". The idea was to build a 'content review site', similar to that of say Metacritic, where users can rate movies, tv shows, books and games and then share these reviews with their friends. The idea wasn't fantastic but it was the best I could come up with.

As a sucker for punishment I decided I would use Backbone to build the app. While I felt like I had a fairly good idea of how to use Backbone I knew this would inevitably slow down my project. In addition TDD was a requirement for our third project so I was also going to have to learn RSpec.

To start with I wanted to focus purely on movie reviews and use the omdb api as my source for meta data. We had used this before in class so it seemed like a good choice. I was concerned that I may not have time to implement other content types but felt that a movie review app would still be presentation worthy.

By the end of the week, I wasn't exactly thrilled with the final product but was so worn out that it was going to have to make do. The week had been very intense as aside from stressing about my assignment I had two job interviews which required suiting up and preparing for potential interview questions. I then also had a less formal meeting at a local pub with another company. So I had spent more than a few hours during the week very distracted from my final project.

In the end, my app allowed user signups, user logins, searching omdb for movies and reviewing movies, but little else. I didn't get to the point where I was able to implement other content types or even establish friendships between users, so it was a little disappointing. But looking on the positive side I did learn a lot about Backbone, RSpec and had built a very very responsive app. What was particularly impressive was that searches for movie titles were cached on the server side meaning repeated searches for the same title did not re-query omdb. So while it wasn't the final product I wanted, I did learn exactly what I wanted to learn.

The final presentation went reasonably well and we were all presented with our leavers hoodies which are very cool. It was sad to leave class for the final time and knowing we were now on our own with future Rails or Javascript issues and also no more Joel. But on the upside we were all excited to find a job in the industry and start studying up on some mysterious technologies that had so far eluded us ala Angular and Node.

I'll be writing one final post after this to summarise the post course world and where I'm at now. Thanks for reading!

As is often the case, people get slack with their blogging. That's certainly been the case with me lately but it's also a testament to just how busy the final few weeks of WDI were. We graduated on the 21st of May so it's been a few weeks since finishing up and several more since I last posted. So I'll do my best to recap the end of the course and touch on the future of my blog.

After finishing our 2nd project we were promptly thrust into the joys of Backbone.js. Now you would think this should be a relatively straightforward task right? We already know Javascript, so how hard can it truly be to learn a library? The short answer is, pretty damn hard.

Joel took great pleasure in throwing us in the deep end with Backbone with a little project called "Burning Airlines". Our mission? To build an Airline reservation system with a group of 5 in 2 days. The catch? It had to include live updating. If I click on a seat, this seat needs to become unavailable if someone else had the same page open in real time (or close to it). Joel enjoyed telling us that no team had ever completed the project prior, but that wasn't really the point, the point was to learn backbone.

The A-Team was formed, and me, Kriss, Anne, Tom and Mark set out to achieve the impossible. As expected, the project was soul crushingly difficult, but by some miracle we managed to get it over the line. It wasn't pretty (we didn't have Nix on our team sadly) but it worked! Literally before the morning before we had to present I managed to get cancellations of bookings working, which was the final requirement. It was a proud accomplishment of ours although I do suspect Joel may have exaggerated the project having never been finished prior. The other team of 4 did not fare so well although hopefully learnt plenty about backbone, or at least learnt to hate it.

At the end of our week or so of Backbone, most of the class still found Backbone incredibly difficult and some swore they would never use it again and couldn't see the benefit in it. It was at this point that I realised just how much we learnt in the course. Saying that we learn't HTML, CSS, Javascript and Ruby really doesn't cut it. Learning a library, framework or psuedo language is often sufficiently complex that it might as well be another language. So in total I would argue that during the course we really learnt 8 languages (I'm counting Git, Rails, RSpec and Backbone.js).

So what's my perspective on Backbone? It was definitely hard to learn, but once it finally starts to click, you won't forget it. It does no doubt take more work to achieve a website that may appear the same on the surface, but the speed... oh the speed.

The beauty of Backbone is evident in instant page loads and as a result the website feels amazingly responsive. Essentially, you aim to cache all the information the user will need up front by including all of the required HTML on a single page and nesting this within script tags (to be rendered by bb views) and then performing one Ajax request to fetch the required model data. From this point on, the site is essentially entirely running from within the browser. It truly is a beauty to behold.

This was particularly evident on my final project (which I'll talk about later) which was entirely built in backbone and everything (including user logins and signups) was blazing fast because of backbone.

Over the weekend I dedicated my Saturday to refactoring the code. I'm a bit of a perfectionist and I'm not happy if my code isn't neat, efficient and well commented. Saturday was a productive day and I made many improvements to the code I'd written.

On the Monday we had agreed to all meet up in the city to merge Nix's code with the chatroom styling. The first issue was trying to find a venue. GA had recently moved into the York St building and we weren't able to go there as we didn't have security passes for the weekend. We first tried the UTS library but when we realised there was no internet available to non-students this was a problem.

Unfortunately everything was closed due to the public holiday so we wandered around the city aimlessly for an hour or so before deciding to just go back to UTS and use tethering on our phones. As it happens, the UTS library is a pretty nice venue!

After we sat down and Nix gave us a progress update on the styling it was apparent that we had a long way to go. To cut a long story very short, we had underestimated our styling time. I had originally thought that the 4 day weekend will easily be enough time, but what I was forgetting was that our styling wasn't just CSS anymore we were now using all manner of javascript / jquery plugins to make things pretty. This becomes a lot more troublesome.

The main issue we faced however was the lightbox... the fucking lightbox! Nix was determined to have the user login occur via a lightbox. For the unfamiliar this means that when you click 'login' the login form pops up on the page overtop of the page you were on, so you can fill in your details without having to be redirected to a separate sign in page. I don't blame him for wanting this, as it does look cool and a lot of modern websites use this technique, but it may have been more trouble than it's worth....

To have a lightbox the first requirement is that your login needs to occur via AJAX. There is no point having a lightbox pop up and then when the user clicks 'Sign In', the page then reloads (that defies the whole point). This was further complicated because we had chosen to use Devise so there was no simple way to change the server side code to accept AJAX logins. Fortunately Nix had managed to get this working via googling up some Devise hack on the interwebs.

However on the Monday, the realisation dawned upon us that there was another major problem. On all of our pages the logged in user's username and avatar were displayed. So even if we could get the login via AJAX fully working, we now also need to then go and fetch the username and avatar and immediately update the page. There wasn't anyway to cache this as we don't know which user it is until they actually log in. Now, this isn't a hugely hard problem to solve, but it's not the problem we wanted to be solving on Monday when all we wanted to do was a final merge and push to github.

After spending most of the day in the library we fortunately managed to get this up and running. It was a high pressure day but we did get it over the line. We knew there were a few bugs here and there and weren't all 100% satisfied with where we got up to, but it was presentable. We all went home tired and exhausted, the 4 day weekend had seemed far too short.

The presentation itself went fairly well. We managed to get the entire class online and using our app to send messages which was fairly gratifying. Joel did manage to expose a major bug in our app that allowed anyone to send a message and include html or javascript in it's content which would then run on everyone's machine who was in the chat, but at least it was him who found it so we could fix it.

But I guess the most important aspect was that I learnt a tonne. The project was very javascript heavy and used AJAX for almost all interactions with the server. I wrote the majority of the javascript with respect to the chatroom functionality (Nix handled the styling) and I would like to think I now have a pretty solid understanding of JS as a result. I would almost go so far as to say I enjoy it?

So we're now into week 8 and it's been a long couple of weeks.

On the 10th (of April) we started our second project. This was a group project and our team consisted of myself, Nix and Mark. We decided to attempt to create an idea of mine, which was to create a "Democratic Web Based Chat Room Client". Essentially this was to replicate a chat client (similar to that of IRC) in the browser, but instead of having admins to manage chatrooms all decisions regarding managing the chatroom would be made democratically.

We were given about 12 days to work on the project, the deadline was significantly extended thanks to Easter weekend. On Thursday we set out with high spirits and fairly lofty expectations of building an app to rival Hipchat but be free for all to use. Needless to say things didn't go quite to plan...

The first weekend went fairly smoothly as we managed to bash out the basic chat room functionality without much difficulty despite using plenty of Javascript and all of us being relatively inexperienced in the subject matter.

Early in the week we managed to get an initial version of the voting working, so that users could create "kick votes" against a user and respond either "Yes" or "No". These votes didn't actually kick the user but the Vote and Response objects were being created much as we expected.

Scheduled Tasks...

In the second half of the week I started to look into what I had termed "server side timers", I have no idea what the technical term for this is, so let me explain. Early on in the project I had recognised that we needed some way to trigger various methods (scheduled tasks) on the Rails server on a periodic basis. There were two reasons this was necessary...

If the user closes their browser window without logging out, how can we make it so other users no longer see them in the chatroom they were viewing.

After a vote has been created, at some point in time we need to close the vote and determine if it succeeded or failed. Closing a vote isn't driven by the user, it should just happen X minutes after the vote was created.

So I began doing my research on how we could setup scheduled tasks on the server side. There were many solutions available but the vast majority were more complex than what we needed and I was also struggling to understand how to implement these solutions. Joel had also warned me that I may have limited success using these on Heroku as when your web server enters a sleep state, the tasks may either start queuing (so hundreds are scheduled to run as soon as the server wakes up) OR worse, they may not run at all after the server sleeps. 

After a fair amount of time researching and some failed gem implementations I ultimately landed on the "whenever" gem. This was simple to setup and I got it running with little effort. But come Thursday afternoon (Friday was Good Friday Holiday) and a test deployment on Heroku there was a resounding "Oh shit" when we discovered "whenever" was not working online.

After an emergency conversation with Joel he helped me devise an alternative solution. Why not trigger these periodic checks off user activity? Every user who is viewing our site is constantly pinging the server via AJAX to inform the server they are still online, so why not make this run the scheduled tasks we needed to run? There were only two issues with this approach...

What if there aren't any users on our site? Then all of our server side tasks will not run.

If there are many many users on our site, we can't have the scheduled tasks run on every ping or the server will be overloaded by running them so often.

But then it occurred to me... who cares if all the scheduled tasks go into stasis? If there are no users online, no one is using our site anyway and as long as they run immediately when someone comes online it won't be noticeable.

The second issue wasn't so bad, it could be resolved within the code by simply determining when the scheduled tasks last ran and skipping the process if it was within the last X minutes.

So within the space of an hour or two, with Joels help I wrote a solution such that "server side timers" were no longer necessarily. But not only that, I built an extensible solution so that other scheduled tasks could easily be added just by adding a record in the database and specifying the frequency. It was a pretty good feeling!

At about 5pm on Thursday we fired up the latest code on Heroku and low and behold it all worked beautifully! Despite having basically zero styling it was a great feeling for all three of us to be having a conversation over the internet with our app.

On Thursday I left pretty happy knowing that all our core functionality was delivered and working, I knew I wasn't going to escape working at least some of the weekend, but I was happy where we were at. Nix had committed to doing the styling and he's a hard worker, so I felt that come Tuesday (Monday was Easter Monday holiday), we'd be good to go.

It's a great feeling to finally be done with WDI project 1. I'm really pleased with what I put together within a very short time span (7 days). It's amazing that on Sunday night I was completely stressed and wondering why I'd taken on such a complex / ambitious project and then on Friday to see it all come together and present something I was proud of.

I guess the morale of the story is if you can set yourself a goal that perhaps seems slightly out of reach at the time, this will push you to your limits. But if you can persevere the result should be something awesome and even if you don't quite make it, you'll no doubt learn a lot along the way. The same is true for me in that I had to scale back my ambition slightly to be able to complete my project on time, but if I hadn't challenged myself I would have created something I was much less proud of as I wouldn't have had to work so hard to make it happen.

At the end of our presentations Joel asked the class if anyone was likely to revisit their projects at a later date. I was surprised that the vast majority said definitely not! I honestly can't wait to revisit mine when time permits maybe this is because my project is a subject matter I'm interested or maybe they just felt the past week was too traumatic to revisit... who knows?

I feel like there is so much more I can add to it and I think it would be a great piece to have in project portfolio to show to potential employers. Check out the front page of my site for a list of all the things I'd like to add in future.

So on Friday we finally started our first WDI project. Everyone was excited to finally get stuck into their own creations but also nervous contemplating the work involved to get there. We'd been forewarned it may be the week from hell, but we knew what we signed up for!

I was determined to do something a little less CRUDy (see what I did there?) than my previous project with the Back End Web Development course. CRUD projects are great as first projects but they become so simplistic with the magic that is Rails that I wanted to do something more challenging.

Ultimately I decided to build a text adventure builder app. This is not to be confused with old school text adventure computer games like Kings Quest. I always found those games to be frustrating as hell as 90% of your time was spent trying to figure out the exact syntax to open a door. Something like...

"Door Open" - invalid command "Open Door" - invalid command "Door Open?" - The door is closed "Action Open Door" - I do not understand action at this point I'd normally rage quit...

The type of text adventure I am talking about is the 'old skool' pick a path books. I have very fond memories of the Fighting Fantasy books (written by Steve Jackson and Ian Livingstone) when I was younger. For those unfamiliar, in these books you would read the first page and then be presented with several decisions. Each decision would tell you to turn to a different page, so depending on the decision you chose, you would get a different outcome. They were a lot of fun and usually also incorporated some form of itemisation (acquiring keys, poitions etc...) and also combat (fighting monsters by rolling dice).

Building a web app for these types of stories / adventures opens up huge possibilities. Firstly, why not let others create whatever stories they want and then share these with their friends? If they can create an adventure via a simple web interface this would be pretty neat. Also, using the web allows creators to incorporate images in their story telling. This could be their own artwork, hot linking an image on another site or they could just leave it blank if the scene didn't require it. I'm much more excited to see what others might create than I am to build any adventures myself.

Joel was quick to point out that my creation may result in a lot of erotic fiction tales but whatever floats your boat I guess!

As is always the case, this seemingly simply project quickly turned into something much more ambitious than anticipated. These adventures are much more complex than I gave them credit for. Essentially an adventure is a set of scenes where there are paths between each of these scenes to allow the player to make choices and progress in the story. But I quickly realised that you cannot have a single path to reach a scene. If this were the case, every time you offer the player a choice you've created a new branch in the story that would never consolidate. The result of this would require hundreds of scenes to be created for a relatively short adventure OR providing the player with very few choices to progress each scene.

Saturday and Sunday were spent largely staring at my computer screen wondering how can I solve this problem (allowing multiple paths to the same scene) without creating a coding nightmare. Allowing this also creates new problems such as what if a adventure creator deletes a scene and has now cut off access to a whole bunch of scenes due to inadvertently removing the path to these scenes.

Fortunately on Sunday night I had an epiphany. The solution? Let the creator delete the scene and cut off access to the other scenes. But to help them out provide some nice creator tools that identify dead end and orphan scenes so they can easily fix these problems when they create them.

From here on out it's been pretty smooth sailing really. I have a ridiculously complex scene model, that links to 'tracks' (paths to other scenes) and then back to scene's again (and also the reverse!). But it's all working pretty nicely and I've learnt a lot about complex model relationships along the way. I have had to scale back my ambitions slightly in that I've decided to forgo itemisation (collecting items) and also combat but these are addons I can look at in future.

When I first started out with Ruby I was quite confused by it's use of functions, where the hell is return!?

Firstly, what is a function? Without googling the correct definition, I would describe a function as something that takes inputs (this part is optional), computes a value and then returns a result. For example...

def add(x,y) x + y end

In this example, when I call the function add, I have to pass in two values (x & y), the function will then add these two values together and return the result.

For those new to programming, every function does return a value, even when that value is not used. For example...

@name = "" def set_name(new_name) @name = new_name end set_name("Simon")

In this example, the function does what we need it to do without returning any value (that is set @name = the function's input). But, it still does return a value. In this case, the returned value is immediately discarded as the function 'set_name(x)' is not assigned to any variable.

In other languages, you must explicitly state what value to return. e.g.

def add(x,y) result = x + y return result end

So in Ruby, it is not necessary to use the keyword 'return', it will simply return the result of the last code that is run within the function ("the last evaluated expression"). This is called "Implicit Return" and ultimately reduces the amount of code you must write as a lot of the time, the last computation is what you want to return.

But even in situations where you need to add an extra line to the end of your function to ensure the desired value is returned you still won't need to use the 'return' keyword. You can simply put the variable name or value in directly as this will be evaluated as the last line of code. For example...

def add(x,y) result = x + y <some other code here> result end

In this case, simply putting the variable 'result' at the end of the function is sufficient to return this value.

But, you can still use 'return' if you like, and it is useful. When 'return' is used, no further code within your function will be run, so it can be useful as a means to immediately exit the function.

For example we did an in class excercise to check an array of possible anagrams against a word to test if any were anagrams. In this example we were only looking for a single result so return was useful to stop the code as soon as the first result was found e.g.

def anagram?(word,anagrams) target = word.split('').sort anagrams.each do |word| return word if word.split('').sort == target end "no anagrams found" end Anagram.anagram?('listen',%w(enlists google inlets banana))

Rails Notes - Gist is a simple way to share snippets of text and code with others.

Late last year I completed the Back End Web Development (a purely Ruby on Rails) course with General Assembly and I wanted to share a couple of the things I've learnt during my WDI course that I wish I knew back then.

Pry - Pry is to ruby programming what Jesus is to Christians. It's our saviour. When doing the Back End course I was blissfully unware of this gem (see what I did there?). My instructor had recommended a similar gem called debugger but I could never seem to get it working. This resulted in many frustrating hours wasted trying to figure out exactly what was / was not present in my params hash. Pry makes debugging a breeze. Simply add "require 'pry'" to your code, then add "binding.pry" at the point in your code where you want to launch into pry in terminal. Finally, type params to view what's inside the hash. You can also use "ls" while in pry to list all local / instance variables. It also makes creating some basic seed data to test a new model or relationship easy.

Zen Coding - This greatly reduces the amount of shitty HTML code you need to write and saves huge amounts of time. The beauty of Zen Coding is that it uses CSS syntax, so it's not like you are learning some arbitrary new syntax for this purpose.Simply type some CSS and press TAB and blam! your HTML is generated. In addition you can do things like "ul>li*3" which will generate an Unordered List with 3 List Items. Even better is just type "!" and press TAB to get a basic HTML template generated in seconds.

How you install this depends on what editor you have so look here for details https://code.google.com/p/zen-coding/. For Sublime Text 2 you need to use the Package Manager to install "Emmet"

Direct Database Access - During my previous course I was fully aware that a 'model' is an object that represents a row in the corresponding table in the database but had no idea how to view the database. How you do this will depend on if you're using postgres, sqlite3 or something else but it is definitely worth finding out.

With some fairly basic SQL knowledge this gives you a huge amount of visibility of what is going on with your program rather than solely relying on your models in Ruby. This is particularly useful in diagnosing why your relationships aren't working or even just to check that your models are in fact saving.

To access your database from terminal...

SQLite3 Navigate to where your .db file is sqlite3 [databasename.db] type ".schema" to display your table structure

Postgres Make sure postgres.app is actually running! psql [database_name] type "\d" to describe (display the tables)

From here you can run queries i.e. "select * from table_name;" and view the contents of your database.

Ruby Warrior - This game is amazing and educational so you should play it...

This will blow your mind...

Tonight I attended the RoROSyd meetup @ Trinity Bar in Surry Hills. This was my second attempt at networking with the RoR community. Networking is definitely not my thing, but I’m determined to mingle as it can only help my future career prospects. Despite a few of my classmates saying they were going, when it came to the crunch I was the lone ranger. Fortunately, I managed to chat to a few of the guys from the other WDI course (currently in week 10) and not be a complete Nigel.

The speeches were great and although I admit much of the content was over my head, I feel like I got the gist of what was being said. I shall try to summarize for those who did not attend but bear in mind that this is my interpretation only!

In summary…

If you use MongoDB and Ruby gem mongoid to connect to the database there are plenty of quirks to consider. Definitely download the slides if you use this one!

Avoid using models (objects inheriting from active record) for complex validation rules. Build this logic into separate objects.

Building many small applications that interact with each other is likely a better option than building one massive application. But this introduces a whole bunch of additional problems that haven't yet been worked out (e.g. deployment, monitoring etc...).

If you have a single page web application (with plenty of javascript) this is likely to be overlooked by search engines. To fix this, use their app that caches your page and presents this to the search engine (https://snapsearch.io/).