AMPed a Web Dev Adventure blog by amarkpark

About Time

Much as I wish this were an Allen Watts-esque style discourse on the eternal yet ephemeral nature of time, my Post Title is more a sign of contrition… I have let my blog lapse for a month as I transitioned from a student to… well something approaching ‘Intern’ on the learning spectrum.

My last month in the Firehose Project was intense and fulfilling and draining all at the same time. I was rushing to finish a few solo projects and starting a group project and trying to cram as much learning and doing into my last precious days as I could.

Did I emerge from the program a Ruby on Rails Expert? Nope. But I DID emerge as a well-indoctrinated Ruby on Rails Novice with some solid skills and a hunger to build upon them. As with any new discipline, I now have a much better idea of the scope of what I do not know. And I add to my knowledge and skills daily.

I am currently working on a group project with a team of FHP students and a skilled Lead (Group Mentor) in the “Product Manager” role (though sometimes that may be closer to a kindergarten teacher role - he wrangles cats and bolsters egos and makes sure we clean up our Legos™… hmm come to think of it that’s probably about right for “Product Manager”)

Hard to describe the highs and lows of this venture. A friend asked me yesterday how I like it. And here is the gist (no github pun intended, but there it is!) of my response(s):

“It is good, frustrating, up-hill progress that has me working 10-12+ hours in a stretch without looking up.” “I love it so long as I don’t spend more than ~24 hours hard-core stuck.” “It stimulates my brain.” “Every little section I finish is a new reason to party.” “I get to see results of my work. It’s like editing sound, there is immediate gratification and satisfaction.” “I get to move Trello cards from Backlog to In Progress to Completed and get little stickers of accomplishment just like flippin’ kindergarten! I LOVE IT!” –me

This group project is kicking my arse, but in a GOOD way. It challenges me and keeps me on my toes and helps me learn and practice all sorts of useful skills that run the Gambit from working on a team to version-control to the nuts-and-bolts of writing code. I am utterly leveling up my TDD and Git skills. No question. And the satisfaction of watching our App grow from printed instructions to a functional piece of software is BRILLIANT!

I’m not saying there haven’t been challenging days, but each stumbling block is a learning-experience-in-disguise and each frustration is the potential for satisfaction. Now if only I could remember that whilst in the thick of it!

Heh... On that note: I happened to be watching Bill Burr last night (don't hold it against me, I didn't pick it!) and he said something about the process of learning home repairs and maintenance that I feel COMPLETELY applies to the process of learning to code... The pertinent sound-byte is in the first 10 seconds, watch the rest at your own risk. ;-)

Just the facts Ma’am…

I haven’t felt this happy/content/satisfied on a daily basis for a very long time. I am learning and growing my coding skills daily and having a blast. Choosing to Ride the Rails has started me in a truly rich and positive new direction for my life.

Today I feel much like I felt in my First Post “The Adventure Begins…” and I am eager to get to the next stop on the Ruby Express.

~AMP

Deep Dive Week In Review

My coding mentor instructed me last week to “Dive Deep” while working on my current App. Essentially he wanted me to spend time understanding the whys and hows of all the commands, connections, methods, assets, interactions between components of the MVC, calls to the ORM… Anything I touched I was supposed to deepen my understanding of. I even took notes longhand « with a pen « in a paper notebook for some of these.

The following (non)exhaustive list of what I touched upon (and sometimes snorkeled in) during my Curricular Annotations this past week includes:

Yeah. The ones without links are still cooking. Suffice it to say I’ve been drinking from the Firehose this past week. And I have more homework/leads to research more of for the COMING week. No big surprise there, I’ve still got lots to learn and tons to review. I’m pushing myself to progress as far as I can prior to the start of my Group Project, now slated to kick off come Saturday… 5 days from now.

Caught somewhere between nervous and eager at this point. I should write some test classes to help me determine which way is UP once we get going. But would they be Functional or Unit tests? Functional tests on the GravitationalForcesController?

Something to contemplate.

~AMP

1. It TRULY pays to read community posts! - Thanks to community-active FHP alumnus Colin Rubbert for the link to that Dev Tips!

A Number Stack

So I wrote a Stack Class in the process of working on a new coding challenge yesterday. The Stack was explained as an abstract data structure that is Last-In-First-Out. I needed to have a functional stack to complete my assignment and at some point I went off on a tangent to code a Number Stack.

This is somewhat my ode to the IP Stack, in that it encodes data and bit lengths to represent items on the Stack.

class NumberStack
	attr_reader :data, :topval

	def initialize
		@data = nil
	end

	def push(value)
		value = value.to_s(16)
		@data = "#{value.length.to_s(16)}#{value}#{@data}"
	end

	def pop
		length = @data.byteslice(0).to_i(16)
		topval = @data.byteslice(1, length).to_i(16)
		remainder = (@data.length - length)
		@data = @data.byteslice((length+1), remainder)
		topval
	end
end

Or Find Gist here

There is a functional limit to the integers that can be pushed to the stack of 1152921504606846975.

That is “fffffffffffffff” in Hexadecimal.

I could increase the functional limit by changing the base I convert to to push the data onto the stack, but I didn’t need a gianormous limit and I’m used to working with Hex so I kept it simple.

~AMP

Check Your Assumptions

I spent much of the weekend frustrated. The REASON I was frustrated was because I didn’t Check My Assumptions.

I was working on a coding challenge. My solution involved having two copies of a multi-dimensional Array. I would inspect the first copy (hereafter FC) and based on the results of the inspection make CHANGES to the second copy (SC). This wasn’t necessarily a difficult proposition. I had already solved this problem once and was working on a refactor to improve efficiency.

I started with a clone of my original code and I set about making modifications to eliminate a secondary method and fold it in to the initial iteration of the Array.

Every time I ran the refactored code I found that it was not only changing the SC of the Array, but also the FC. Note: Needed deep copy by way of Marshaling, ‘tis another story.1

The thing that was frustrating the begeebers out of me was that each time I reran my original solution IT WORKED! The FC was unchanged and the SC was properly modified HUZZAH!

…Except that that WASN’T actually the case.

I needed to Check My Assumptions.

I forgot that I had changed the order of the methods I called when I tested my refactored script. And while the original solution DID properly make changes to the SC, it WAS simultaneously changing the FC. Problem was I didn’t know that because I was only inspecting the FC BEFORE calling the method to apply the changes to the SC.

I hadn’t held my test methodology constant in the refactored script, so I was seeing a different set of results. Once I realized my error I changed the order I was calling the methods in my original solution script and found that IT TOO had changed the FC at the same time it was changing the SC.

Had I just Checked My Assumptions I might have saved myself days of frustration and headaches as I chanted over and over “But it worked in the original solution!”

Check Your Assumptions At The Door!

The moral to this story is this: Check Your Assumptions. Start with a fresh pair of eyes EACH AND EVERY TIME you look at the code. Reset your expectations. Go back and examine your code, your methodology, your order of invocation. Faulty assumptions are PEBKAC 100% of the time, so CYA.

~AMP

1. Marshal, and a lovely way to invoke Marshaling to achieve Deep Copy

Leveling Up

Oh the Whirlwind…

Since my last post I think it’s fair to say that I have Leveled Up, both in Ruby and in Rails.

Leveling Up Rails with TDD

Since my last post I have been working on a new App, the catch is that this one is being built from the ground up with Test Driven Development practice of writing the tests first and then coding the feature. This makes incremental changes less likely to break any necessary features, it also seems to increase the time it takes to build anything by orders of magnitude.

Granted, the first set of features took the longest to build the tests for first, by the second and third I was starting to get the hang of it. Still, the essential process is 1) Build tests that fail because the feature isn’t built yet. 2) Build out the feature until the tests pass. Generally speaking this includes multiple Assertions per test to account for facets of the feature in question, such that as the feature is built in stages, the test for that feature goes from Failing, to Erring on successive Assertions, to passing all Assertions, at which point the feature SHOULD be built as designed.

By the third set of Tests/Build-outs I was really starting to feel comfortable with the process. I know I have a lot to learn, but going from building apps haphazardly to building with TDD seems like a solid case of Leveling Up. That was my Rails breakthrough.

Leveling Up Ruby with Coding Challenges

I also successfully completed about 3 dozen CodeWars Kata. I think technically that has me Leveled up twice… I went from 8kyu to 6kyu… I have that much-coveted score of “69” … SO not kidding. Yeah moving on. What a brilliant learning tool! Form of a game, form of a challenge, form of a competition… however you take it, CodeWars can help anyone Level Up their programming skills… I was working in Ruby but they also have Clojure, CoffeeScript, C#, Haskell, Java, JavaScript and Python. I am considering myself well-informed at this moment because I have at least HEARD of the majority of those languages. Yikes. This is what I get for dropping out of programming for two and a half decades. I have a WEE bit of catching up to do. Thankfully CodeWars can help!

In the meantime I also completed a coding challenge in FHP that certainly WAS a challenge. I beat my head against the wall for hours at a time for two days and then in the wee hours of the morning when I should have been sleeping a new approach occurred to me and sure enough on day three I was able to tackle the challenge from a different direction. The change in perspective allowed me to solve the problem that had me pulling my hair out for two days. This harkens back to my days working at the Center for Creative Learning and some of the techniques I encountered there. Essentially, if you can’t get in the front door, try climbing in a window around the side. But I feel pretty strongly that I Leveled Up my Ruby capabilities along the way.

I am finding that breakthroughs in skill level tend to follow shortly on the heels of feeling frustrated to the breaking point, and/or beating my head against a brick wall. I take my skills as far as they can go and then I have to Level Up in order to progress further, unlocking both capacity and potential in the process. There is a distinctive feeling of that “click”… the intangible sensation that pieces of the puzzle have just moved into place and the picture has become more clear. It is a good feeling. Gives me just the right surge of energy to start tackling the next level.

~AMP