Blurredbits

Searching for the gray space between 1 and 0.

[blurredbits]

George R.R. Martin pictures the end as wind blowing through a cemetery. Everyone get your booze cabinets ready!

[blurredbits]

Delicious Boogle code. My new life.

[blurredbits]

My morning routine - waiting for the train. 

[blurredbits]

Slacker

Finally got around to sending out an update email to all my family and friends this week. Everyone's continued support and well wishes made my day and have given me some extra fuel to keep going strong at DBC.

Week 3 has been a lot better than week 2. We finally got into persistence, and just like riding a bike, some of my old SQL knowledge reluctantly came back when tasked with fun things likes sub-selects and joins.

Yeah - that's right. One of my fellow cohorts said this morning - "DBC is kinda like going to the zoo in a drag racer" and I couldn't agree more. We got introduced to SQL on Monday and Tuesday we were already doing relatively advanced queries that when I was programming before took me months to grasp. With only 9 short weeks to cram everything in, I suspect that will be a repeating pattern. Hope I can keep up.

So tomorrow is a big day. Assessment day. We get feedback on our code, and the practical application of the teachings so far - and we find out if we move into the next phase. Hope to do well, and look forward to the challenges the next phase brings - assuming of course, that I make it.

Next week, we also celebrate the arrival of the next cohort, the Otters. Looking forward to the exciting day that Monday is sure to be and helping out the new guys and gals. It's a tough adjustment period for all the new boots, hope to pay-it-forward with the same consideration that the Squirrels showed to us Foxes.

Off to bed with dreams of code running thru my head.

[blurredbits]

Pattern Matching Variables

What a great way to start the week. After the stress and train wreck of algorithms last week - today turned out to be a relatively easy day at DBC. We started the week exploring minions to do our bidding - er, objects and object oriented design.

So in preparation for the wonderful world of objects, one of our challenges had us exploring the different types of variables (instance, local, etc.) Part of the exercise had us read in the pickaxe and that's when I discovered this little nugget: pattern matching variables.

When I first started playing with Ruby and Regular Expressions, I was getting a little frustrated with the operators and return results. When I'd get a match using the =~ operator, it'd return a number.

WTF? A number? What the hell am I supposed to do with that??! 

Ok, so I've learned a little bit more since then - the number actual represents the index of the string where the match starts, but for a Ruby noob - it wasn't what I was expecting.

So today, when I discovered pattern matching variables - I let out a deliciously evil laugh. Finally! Sense would be made of the RegEx madness! Ok - so here's my feeble attempt at explaining some of the wickedly cool global variables that get set - pulled straight from the pick-axe p.340.

$& Matched String

$+ Contents of the highest numbered group match.

$` String preceding the match

$' String following the match

$1...$n contents of the successive groups in a match

$~ Object containing the match data.

So one of our challenges was to convert both words and sentences to pig latin. With this new knowledge in hand - here's just a sample:

"Mark".downcase =~ /[aeiou]{1}/

p "#{$&}#{$'}#{$`}ay"  # => "arkmay"

Not exactly readable or intention revealing - but functional nonetheless.

Cheers!

[blurredbits]

Head Check.

One week down.

92 hours. Soduko solver achievement unlocked.

Not bad.

So finally got a chance to talk with Corey Ehmke tonight, also known as @bantik in twitterverse. Saw him speak at Ruby Midwest and he is a great guy. So glad that him and other mentors are showing up in support of Dev Bootcamp and all of us boots. I hope they know how much it means to all of us to have an outside ear to ask questions of and guide us on our journey. Our conversation was mostly just chit-chat about his days writing for 2600 - but he did remind us all about the pomodoro technique.

For those that haven't heard of it:

Set a stopwatch for 25 minutes.

Concentrate on a single task for those 25 minutes. No interruptions, distractions or otherwise - if possible.

Once the timer goes off - take a 5 minute break. Stretch, relax. Do whatever.

Rinse and repeat - except after the 3rd cycle, take a 15 minute break.

Definitely gonna start next week.

Week 2. Objects!

Yum.

[blurredbits]

Vulnerability

Another long day in the crusade to be a programmer - but a pretty good one. Had a great meeting with one of my mentors and really look forward to his guidance and input during my journey. It'll be great to have another set of eyes to review my progress and in his terms - help with a few shortcuts towards a new career as a programmer.

So to the main point of the post - Dave Hoover brought it up on the very first day - but expounded upon his background as a developer. He told us a story of how he was sitting in Detroit working with a Senior Dev and how he felt completely vulnerable - "How did I get here? What the hell am I doing? I'm not qualified to be here."

While it might not have echoed with any of the other boots - it certainly rang true for me. After doing some PHP development at Waterpik, it's something that I struggled with there. I wasn't officially attached to an IT department - I was essentially given just enough rope (er..server access) to sink or swim. I felt lucky that I was able to offer a few cobbled together programming solutions - but I never really felt like I had really earned my developer "strips". No CS degree. No real background. Just a self-taught computer geek given an opportunity.

Looking back when I was offered the chance at more money and a new position in Logistics/Supply Chain - it seemed like an easy choice, I was never a "real" programmer to begin with. After all, back then - all the programming jobs were moving overseas, right?

What a mistake.

What I'm learning now is that it is never too late to shake off those old mis-conceptions. If you have a dream, and a true passion - you can never give it up, no matter how the chips may land. Even if it means you have to be vulnerable for a little while.

G'Night.

[blurredbits]

Day 2

Had a much better day and actually started to feel like some things are starting to click. It doesn't alleviate any of the pressure, but I'm starting to find ways to manage some of the workload.

One of my most essential steps is reviewing the material that is going to be required for the next day or two. Simply glancing over the challenges seems to help kick my sub-conscious problem solving into gear. 

Normal challenges seem to be taking an hour or two in a pair programming environment - even relatively simple ones that were repeats from the prep work. The practice is good and just re-enforces the core concepts I will need going forward, but it is kinda frustrating however, when regexs rise up and kick my ass all over again. Mad props to the person who created Rubular.

Biggest take-aways today - the awesome feeling of helping another student out. Our classmate from Germany was having a tough time a shuffling algorithm (not allowed to use #shuffle), but with a few simple hints we worked thru it together. The bright smile of understanding and joy as his solution worked was a pleasure to behold.

So far, it's been really great getting to know all of my classmates. We've got a long road ahead of us and I know we'll be leaning on each other to get through this.

Reached out to my Mentors tonight - I'll meet one of them tomorrow and the other tomorrow night. Anxious to get to know each of them.

Not quite ready to shut the brain down yet - so more studying, but enough bloggin'.

[blurredbits]

Ground Zero

Day 1 of Dev Bootcamp.

After months of waiting, it was finally go-time today. The beginning of what I hope to be a turning point in my career and my life.

So after a restless night, I started my day with an awesome introduction to DBC. Talk about fired up and ready to go! The staff, existing students (squirrels) and current classmates are all inspiring. It's easy to see the drive and passion for programming in everyone - and it's very humbling.

One the things that was discussed today was vulnerability, and opening up yourself to the experience. Not exactly one of my strong points - but I better be ready to jump in - and quickly. I found myself falling into some bad old habits - loner coding and a reluctance to ask for help.

If I'm going to make the most of this, I'd better knock that shit off - pronto!

'Nuff said - to damn tired to blather about anything else.

Out.

[blurredbits]

Fort Collins Internet Pros - Content Strategy

With my busy schedule lately, I was half considering skipping out on one of my staple meetup groups, the Fort Collins Internet Pros.

At the last minute, I decided to go - and boy, I sure am glad that I did.

The topic tonight was Content Strategy. Kind of a new one for the group as most of them lately have been tech oriented.

Background: The talk was given by Laura Bailey, the Content Strategist/Web-Editor/Social Media Manager (talk about multiple hats!) for The Wilderness Society.

I couldn't help but think as an aspiring software engineer, what sort of tools currently exist to help with content strategy - and what tools could add value to an existing site?

So while the speaker was talking about content voice - I couldn't help but think - how could that be built into a form to help guide a content producer toward a strategic goal. Seems like if an organization is going to take the time to develop tone & style guides - it seems appropriate to put them at the point of use rather than rely on external documentation.

The other thing Laura mentioned was an editorial calendar - again rather than an external spreadsheet, seems like another opportunity to build a tool into a site to help manage content timing.

So, I'll readily admit that I don't have a whole lot of experience with CMS systems like Wordpress or Drupal - so maybe some of these technologies already exist - but if they don't, what an opportunity!

Guess it sorta goes back to my supply chain training, in which, I was taught, just like the name says - it's a chain. A chain in the sense that it's important to keep in mind your supplier's supplier and your customer's customer.

Given how much an organization invests in time and resources in a web presence - it seems the value-minded developer must understand and help provide the tools to power the strategy. This will help the organization keep the web content relevant and focused on the business goals.

[blurredbits]

One Ruby Noob's First Experience with Refactoring

Last Thursday night (3/14/13), I was in for quite a surprise - one that I didn't expect, but one that opened my eyes in way that left me reeling...

First, a little back story. In Boulder, CO there is a meetup group called 'Ruby on Beer'. It's run by Foraker Labs and was recommended to me at a getting started with Ruby session at DaVinci Coders. So last month, I headed down for the first time, and was promptly greeted by several Foraker team members who were celebrating Mardi Gras - king cake, hurricane punch and strings of colorful beads. Thankfully, no flashing was required ;)

Overall, it was a good meetup. I met lots of other developers in the community and had a great talk with Neil Enssle (Foraker - Director of Technology) - who gave me several great book recommendations, and gave me lots of hints/tips about interviewing for a developer position. All-in-all, there was lots of beer and socializing - but no Ruby.

So, when the meetup schedule came around again for March. I thought I knew what I was in for - more beer, more socializing and a chance to do some more networking.

Well, the evening started out that way..but at about 6:30, Stirling Olson (Foraker - President) announced to the group that, contrary to popular belief, there would actually be Ruby at Ruby on Beer and announced a refactoring challenge. Everyone was to pair up, pull down the code from Github and refactor for 45 - 60mins. The code was "sanitized" as to not give away the identity of the client, but was essentially, real code as received from a client.

Wow.

Real code, and a chance to put a little of what I've been learning into practice - and a room full of seasoned programmers from some high profile companies in the area (Pivotal Labs for one).

So after pairing up with my Dr. friend, Raman (another Ruby noob) - we ran the tests, and made some minor edits. Basically, just re-arranged the code a bit, looked for commonalities that we could use to refactor. The code was still a mess after our feeble attempt, but we submitted it anyways.

Then the learning began. Here's what I learned:

1. Commit early. Commit often. Most of the teams only made one final commit - but one of the pivotal teams made over 20 commits. Essentially, every time they modified some code, and re-ran the tests - they made a commit. I immediately saw the value in that - especially when refactoring.

2. Not only is the cake a lie - comments are too. I had heard about it on Ruby Rogues - that comments were just lies waiting to happen, but it was comical to actually see it in real code. Most of the teams simply deleted all the comments at the beginning of their refactoring. Lesson learned.

3. Your editor is your BFF - learn it! Raman, my pairing partner for the exercise is a Ruby noob, but a full time PHP developer. Apparently, I was figuratively "killing" him with my newbie usage of Sublime text. Do yourself and any potential pairing partner the favor of working efficiently within any editor you decide upon. I know I need a LOT more practice.

4. Refactor into readable code first. In some of my learning, I had heard that a case statement was a code smell - or a new method just waiting to happen. Raman had heard that too, so rather than refactor a couple of elaborate conditionals, we decided to leave them in place and see if we could optimize their logic. After seeing other team's work - I realized that  we might have been better off taking the intermediate step of a case statement to more clearly see the opportunity for a new method later.

5. 10,000 ways to shave a yak. I think the most amazing part of the evening was the review of all the different ways to approach refactoring. Even from our simple attempt, we found that we had done a couple of the simple ideas that all the other teams had done - but there really are multiple ways to tackle any given problem. It was great to have that point hammered home with a real example.

For a first experience at refactoring - it was both exciting and staggering - and I'm extremely grateful to Foraker for hosting such an event. It was a great event and I hope to participate in many more!