Wants vs Needs

Today is Sunday April 13, 2014.

Tomorrow begins my 12th week at Dev Bootcamp.

I have 1 more week of Phase 2, 3 more weeks of Phase 3, and then I will need to start looking for a job.

Currently, I need to:

  • Finish my part of a group project for Dev Bootcamp.
  • Continue working on portfolio challenges, with a focus on client-side JavaScript, jQuery and AJAX to make sure I really understand them.

Currently, I want to:

  • Sleep 12 more hours.
  • Pick up my bicycle from House Scrimshaw and ride it to our new apartment (Kevin and I moved to a cozy little studio downtown! I’ve been too busy to write about it, but I will soon!)
  • Purchase all the spices I regularly use for cooking so that I have them on hand no matter what I’m making for dinner (it’s very frustrating when you want to make something and you have all the ingredients except the spices!)
  • Stretch. Do some yoga. Try to focus on my neck and shoulders which are a wreck from stress and working at a computer with bad posture.
  • Go outside for a while. Take Pepper for a long walk exploring the city instead of just a quick jog to the park over my lunch break.
  • Work on a craft project. Any craft project. I have plenty of them in various stages of progress.
  • Study node.js and learn more about server-side JavaScript (this will probably be added to my To-Do-After-DBC list
Me right now

Me right now

I’m a video-editing software-engineering machine!

…basically I’m calling myself a computer.

Anyway, my career path has officially come full circle! Apparently I’m coding and video-editing now. :)

Here’s our spoof on MTV’s “The Real World” starring the 2014 Golden Bears:

I forgot how much fun this stuff is! And even though I don’t have Final Cut Pro on my computer and have to make do with iMovie, and even though I don’t have the time to really nit-pick some of the color-corrections and audio issues, I’m still very happy with it. :)

Also, when I wasn’t editing, I spent most of today at a Girl Develop It workshop on JavaScript and the Web, which really helped cement the things I’ve been learning at Dev Bootcamp in my mind. I absolutely love their instructors, their teaching styles, their learning environment, really just every single thing about them. If you have any interest in code whatsoever, you should really check out one of their meetups. I can’t say enough nice things about that organization!

Also, while you’re at it, go ahead and sign up for Women Who Code and if you like crafting and building robots check out San Francisco Coders & Crafters!

AJAX will NOT be the death of me!!!!

When you’re having a hard time understand or learning a particular thing, get 3 different people to explain it to you with 3 different styles of teaching. Some people are hand-wavey explainers, some people are draw-picture explainers, and some people guide you as you write it or type it out for yourself.

At least one of these teaching method will probably help you out and result in you finally clicking with the concept you’re struggling with.

So yesterday I was extremely frustrated with AJAX because it’s so simple and it’s only a few lines of code but those lines do so much stuff and it’s all so abstract to me because I’m coming from a non-STEM background so EVERY SINGLE THING that I’ve learned so far has started off seeming really abstract and confusing to me.

Today it clicked. I got it. I fucking understand it! So naturally I made a crappy picture with MS Word (because I don’t have photoshop, illustrator or even MS paint on my laptop) to explain it.

This sad, ugly picture should serve as a reminder to myself and might help out someone else who is struggling.

Screen Shot 2014-03-26 at 3.37.16 PM

The request can be any HTTP verb and the response does not need to be a JSON file, but in my current example it is.

Helpful Links:

PS. This is me right now:



AJAX will be the death of me


This is a GET request:

  type: 'GET',
  url: '/my/url',
  success: function(resp) {
  error: function() {

This is a POST request:

  type: 'POST',
  url: '/my/url',
  data: data

Just a few little lines. That’s it. Looks so innocent.

You’d never believe that I am losing my damn mind over these short little lines, yet here I am.

Phase2 Freak-Out

My first day of Phase 2 of Dev Bootcamp began on March 10, 2014.

In Phase 1 we learned Ruby and created apps that were accessible from the console.

In Phase 2, we’re building web apps.

Shit just got real.

Shit just got real.

One week to learn Sinatra, partials, MVC, helper methods, HTTP requests, RESTful routes, user authentication, active record and deploying apps to Heroku.

One week to learn Object-Oriented JavaScript, jQuery, AJAX, Jasmine (and other testing methods), CSS and making our apps pretty, functional and dynamic.

One week for API’s, exception handling, background jobs and even more testing. After that, Phase 3 will begin.

Every week we have personal portfolio challenges to access our retention and understanding of all of this information. Every weekend we work on group projects to present on Monday morning.

Have you ever seen one of those money blizzard machines that used to be on game shows? The contestant would stand inside a glass case and have a set period of time to grab as much money as they could. The dollar bills would be blowing around them like crazy and the contestant would usually exit the machine clutching a wad of singles and maybe a 5 dollar bill or two.

Grab the jQuery selectors!

Grab the jQuery selectors!

That’s how I feel right now. THERE IS JUST SO MUCH TO LEARN! Information is whirling around my head and I’m desperately grabbing as much as I can and shoving it into my brain. Sometimes I’m just memorizing stuff. Sometimes I’m diving deep and trying to understand the WHY behind the techniques. I constantly feel panicked because there’s always something I still don’t completely understand.

Phase2 is the most frequently repeated phase for DBC students, and it’s easy to understand why. Even the students with CS backgrounds are struggling to stay afloat in this tidal wave of information. Most of us don’t leave the building before 10pm, and even then we still have unfinished work.

I’m extremely lucky in that I live in SF so if I choose to repeat Phase2, and give myself an additional 3 weeks of time to absorb and understand the information, it won’t cause any problems with my living situation or personal relationships. Some incoming DBC students book their AirBnB or subletted apartment for exactly 9 weeks and can’t renew, or end up miss their loved ones too much to stay away for any additional time. Some DBC students still have jobs to go back to and can’t afford to take additional time.

Everyone is physically, mentally and emotionally exhausted but we keep pushing ourselves further and further, promising ourselves that we’ll go home and go to sleep just as soon as we can get these tests to pass or as soon as we submit a pull request for a particular challenge.

There’s a reason it’s called a boot camp.

BUT once you see your silly Flash Cards app up on the web where people can actually see it, and you realize that you just created something with your bare hands, you remember why you started doing this in the first place and you keep going. It feels good to be a maker. Even if I’m just making simple things.



DBC is not just teaching me how to code.

DBC is teaching me how to learn, and undoing 20-some years of bad learning habits.

It has not been easy.


First, I had to learn how to ask for help.

It sounds easy when you understand the topic to ask an informed and relevant question, but gets significantly harder when you’re completely lost and can’t grasp a concept.

I’m getting better about that, but I’m still not great. My pride interferes a lot and I have to remind myself that there’s no pride in being willingly ignorant.


Secondly, I had to learn how to learn.

Do I retain information best by taking notes or drawing pictures?
Do I need to repeat it back to myself out loud?

Attending public school K-12 plus 4 years of college have taught me that lectures do absolutely nothing for me. I can’t just sit and absorb information like a sponge. I need to interact with that information if I’m going to understand it.


Thirdly, I’ve learned how to take breaks.

Working furiously all day and then breaking for dinner is going to guarantee that I’ll feel too burnt out after dinner to continue working, but that’s what I’ve done during my 8 or 9 hour shifts at every job I’ve ever had.

Stopping every 2-4 hours and taking a walk or getting a snack is much more sustainable and means that I get more work done by the time I call it a day. This is a better fit for working long hours at DBC or a startup once I graduate. Even if I find a job with “regular” office hours, it would still be nice to come home with enough energy to cook dinner or play with my dog instead of collapsing in front of the tv.


Lastly, I’m learning what my capabilities are.

Yesterday I asked my husband a hypothetical question about OSX, ended up googling it, learned about it and implemented it. Previously, I probably would have asked Kevin to do it for me since he’s ‘the IT guy’.

It seems so trivial, but just testing the boundaries of my knowledge and going beyond them into new territory is amazing to me! I am able to learn things that I never thought I would.

Testing Testy Tests

No time/energy/brain power for a proper blog post but I do want to combine a bunch of the stuff I’m learning about testing code.

Raise Exceptions

If something goes wrong, you want to avoid breaking things! Stop the code and raise an error message.
Example: a = 10, b = “42″ a + b
returns something like this: TypeError – “42″ is not an integer! Can’t add a string to an integer! Stop it!

You can also add a rescue statement to display a specific message showing what went wrong.
Example: a = 10, b = “42″
a + b
rescue puts “Can’t add variables a: #{a} and b: #{b}.”
puts “a + b = #{a+b}”

Assert Statements

Here’s a simple one that will compare what you actually got with what you expected to get from your code, and either return that the actual is equal to the expected, or raise an informative message.

def assert_equals(actual, expected)
puts actual == expected || raise(“expected #{expected} but got #{actual}”

And here’s an example of assert_raise

Screen Shot 2014-02-23 at 4.55.15 PM

There are lots of assert statements that you can create. Currently I’m just using assert_equals and assert_raise but I’m sure I’ll be using more of them very soon!


Here’s a link to rspec on github. The install is quick and easy!

rspec uses the keyword describe to narrow the scope of what you are testing to a single string or class, and it to act on it. Sometimes describe has a buddy called context that can specify a method within the class you’re testing, and narrow the scope even more.

describe “something” do
context “one context” do
it “does something” do
thing.should be_true

context “another context” do
it “does something else” do
thing.should be_false

Treehouse has a great tutorial for learning rspec and relish explains the syntax very simply.

My brain is so full of information that my creativity seems to be leaking out of my ears (Do you like the titles of my blog posts lately? Lots of creativity there!). I remember once upon a time having conversations about movies or music or crafts. Currently I’m at dev bootcamp 6 days a week (and only because I force myself to NOT go into school on Saturdays and instead focus on various things like grocery shopping and laundry and paying attention to my husband and dog) therefore if it’s not related to programming or an event that happened at DBC (A speaker came to talk about women in tech! The bottom microwave is way better than the top one! My locker smells like my yoga mat! Gross!) I can’t think of anything else to say.

Once DBC ends, I’ll attempt to catch up with the news and find out what all the normal people were up to during the weeks I’ve been stuck inside my computer, but for now I’m just going to be really really boring.

Quick Sorting

A few weeks ago I was learning sorting algorithms in Ruby, and my pairing partner and I just picked a random one from a list and spent the evening learning Bubble Sorting.

Bubble Sorting isn’t bad, but it is slow, especially if you have a large file to sort. So I promised myself that I would go back later and learn Quick Sorting. And here we are!

For me, the most confusing part of learning anything is the vocab. Rarely do people actually explain or define the words/acronyms that they are using and that leads to further Google searching and confusion if I can’t find what I’m looking for. I’m going to try to make it a point to explain Quick Sorting using plain English, but if you don’t understand PLEASE let me know in the comments so that I can clarify! And, as always, if I make a mistake in my code PLEASE correct me! I’m still learning and I can’t get better if my errors are never pointed out! :)

Here we go!

Quick Sorting Explained:

  • Your quicksort method will accept an array of integers as an argument.
  • We’re going to use recursion, so set your base case. A base case is a piece of code that halts the recursive process so that it doesn’t continue to run forever and/or crash your computer. In our case, since we’re sorting an array of integers we can tell the method to stop when the array length is less than or equal to 1.
  • Next we need to pick out a random element from our array. This is called our pivot. We’re going to compare the pivot to other elements in the array and sort them according to whether the pivot is greater than or lesser than the element we’re comparing. For example, if our array is [2,3,1] and we pick 2 as our pivot, we’d compare 1 2 and sort the 1 into a new array called “lesser” and the 3 into a new array called “greater”.
  • Now that we’ve separated our elements into a pivot, an array called “lesser” that contains all of the integers less than the pivot, and an array called “greater” that contains all of the integers greater than the pivot, it’s time to combine them back again! Let’s concatenate the lesser array into a new empty array called “sorted_array” and continue to call our quicksort method on the lesser and greater arrays to continue sorting them and adding them into the new sorted_array. Returning two arrays is partitioning! The pivot is in its final position, so we can add it to sorted_array and stick it with glue. We add each sorted element of the lesser and greater arrays the same way.
  • Lastly, we flatten the sorted_array because it’s currently an array filled with other arrays and we just want one big array with elements in it. Once we’ve flattened it, we return it! We’re done! Sort ‘em, stick ‘em with glue, then flatten and return ‘em!

Screen Shot 2014-02-18 at 2.48.44 PM

Helpful Links:

Inheritance vs Composition

Okay, so in my studying yesterday I went over the concept of Inheritance and how it applies to classes. Today I’m going over composition, which is an alternative to inheritance and is another way to create relationships between objects and combine simple objects into more complex ones. Inheritance and Composition are called design patterns and they can be used as templates for your code.

With inheritance, we think of one class as the parent and another class as the child. The child has all of the attributes and methods that the parent has, but sometimes the child is different from the parent so we can use the super class to override an inherited method.

With composition, it’s more like one class is a car and another is a steering wheel or an engine. The car is a complex object and it is made up of objects of a similar type. With composition, you build up the functionality of a class through other classes.

vroom vroom!

vroom vroom!

Another important design pattern is the Factory. A Factory is pattern that manufactures other objects. This pattern is modeled as a Factory class, module or method. Factory methods can create objects without specifying which class the object will belong to. They let the class who implement the factory method decide which object belongs to which class. Factory methods rely on inheritance.

Screen Shot 2014-02-09 at 2.49.31 PM

Click to visit the Ruby Forum page on The Factory Method

So when do you use composition and when do you use inheritance?

Use composition to package up code into modules that is used in many different unrelated places and situations. If you are unsure, default to using composition.

Use inheritance only when there are clearly related reusable pieces of code that fit under a single common concept, or if you have to because of something you’re using.

So here’s my problem, I understand all of the above, but I’m still not 100% sure how to connect my factory method to the rest of my code so that it works. I understand the include method, but I’m still confused. I think that will be something that I need to talk to a DBC coach or teacher about. Look for edits once I figure it out!

Helpful Links: