Contract Work

Friday, February 28, 2014

Interesting Reads Double-Wammy edition

I know, last week you were so disappointed when you didn't see the weekly interesting reads posted. Truth is, I had a list of them, but hadn't had a chance to read any of them yet. Hopefully this week's double-wammy list makes up for it.

Enjoy!

RR last week was on passion and I think had some very interesting points.

As I've mentioned a few times, I'm doing A LOT of Ember now. It's actually really interesting and pretty enjoyable. This is a great post about ember that explains reasons for using it clearly and goes into the technical components as well.

Reading articles like this makes me feel better when I make these same mistakes.

There are lots of articles about saying no, but I think this one is actually worth a read.

Software development reading list.

Finally, So you want to be a software dev, but do you?

Saturday, February 15, 2014

Interesting Reads 2/7 - 2/14

Yes yes yes, I owe the world a more interesting blog post than just interesting reads, and I've got a bunch in the works! In the future, you can look forward to the last post on the gem, a post on ember, a random learnings post, probably a post about my first few weeks as a professional programmer (which have been crazy and amazing and exciting and scary and pretty much all the emotions) but for now, I have to just give you the interesting reads for the week. Hopefully you find them interesting as well.

Enjoy!


Yes! This! Tech and Tiaras

Software Developers Changing Lightbulbs

Thoughts on Working Remotely

I don't agree with all of this but there are some really interesting points made about how everyone shouldn't learn to code.

A Year of Code. Similar to the piece above.

Friday, February 7, 2014

Interesting Reads 2/1 - 2/7

Well, it certainly has been a busy week for me. Fortunately, I've also come across some really interesting articles and things to read/watch. AND I've actually read all of the articles this week (except for the last one... it's a video I haven't had a chance to fully check out yet). There's a variety of stuff in here this week so ...

Enjoy!

Will NOT Work for shoes! I love shoes, but this is a great article about women and their workplace value.

If you've had a rough week or are a newer developer, this short post is a great pick-me-up.

Personally, I'm not very good at celebrating small wins. That, coupled with the fact that I'm getting used to a "dev" to do list, as opposed to a non-dev to do list, makes it hard sometimes to feel like I'm accomplishing greatness. This post talks about that and some great ways to reflect regularly on your work.

Okay, I lied!! I haven't had a chance to read this article about the amazing new Marvel API, but I've gotta find time soon!

On a slightly dryer note... here's some great HTML5 documentation.

In my new position, I'm learning Javascript... lots of Javascript, but Ember.js in particular. Since I'm new to it, I thought this article gave some interesting, basic pointers about the differences between some of the more popular JS languages.

A great post from Aaron based on a question asked at RetroRuby's Newbie track last week!

And to close out this week, here's a video I haven't watched yet about Postgres and things you haven't found.

Monday, February 3, 2014

Getting the Information

In order to actually get the information on the action campaigns that I needed, I needed to use nokogiri to parse the information, create new actions and clients, and then map that information. I started with this code:
# def self.fetch
   #Nokogiri::XML(SalsaLabs::Client.new.request_data('/api/getObjects.sjs', object: 'Action')).css('item').map do |attributes|
   #SalsaLabs::Action.new({title: atributes.css('Title').text)})
   #end
#end
And then used that code to break it into smaller, more transparent methods. I broke the code into five separate methods. First, I created a new class for it called ActionFetch. Then I initialized (or set up) that class setting an instance variable for api_client
def initialize(api_client)
  @api_client = api_client
end
Then, starting from the meat of the class, I created this method:
def data_request
  return @data if @data 
  body = @api_client.fetch('/api/getObjects.sjs', object: 'Action') 
  doc = Nokogiri::XML(body) 
  @data = doc.css('item') 
  @data
end
The data request method starts by saying if there is anything already in the @data instance variable, then just return, if not, then go through the rest of the method’s steps. This is also called Memoizing which basically means storing a value for future use so that you don’t have to run the call over again which saves you time.

The next line says that take the api client (which is the actual http request, set up with faraday, using credentials, etc., set up in a different api client class) and get the stuff that is located at that api endpoint with the params of the object which is named Action. Then, use nokogiri to parse the information that is in the body string (set above). Finally, look at the doc (which is the result of the nokogiri parsing and is now an xml doc) and use the css selector to find all the items. Finally, return the value.

Then, I took those results and fed them into the get_results method.
def get_results
  data_request.map do |attribute_set| 
    new_action(extract_attributes(attribute_set)) 
  end
end
This method takes the results from data_request and for each one (each attribute set), it extracts them into a hash and then makes each of them a new action (it wraps each of the attributes sets in an action class). It does this by using the extract_attributes method which looks like this:
def extract_attributes(action_data)
  action_data.children.inject({}) do |memo, node|
    memo[node.name.downcase] = node.text 
    memo
  end
end
and takes each of the item nodes (action_data is the Nokogiri item tag) and makes them into a hash. And finally, wrapping it in an action class is done by using the new_action method which looks like this:
def new_action(params)
  SalsaLabs::Action.new(params)
end
It just stick each of the params into an object called action which gives the attributes pretty names.
Phew!

Okay, so then, what do I mean by pretty names? Well, in order to see that, I look at the Action class which I’ll cover in the next post.