armw4

This is a Judgement Call...but not a Difficult One

If you're a resident of redux land, you've probably heard the tale of container components vs presentational components. The latter has no knowledge of redux, does the heavy lifting rendering wise, and communicates with the former via callbacks. The former knows about redux, state, actions, the store, etc. There's a clear demarcation between the two sides. That being said, sometimes you don't need presentational components. If the rendering is simple enough, you can "just do it". You hear a recommendation, guide line, or best practice suggested by a framework author, and over time you apply it rigorously; treating it as a fact of life. I'm guilty as well (although I go out of my way not to be). Ultimately you have to be pragmatic about how you apply idioms and best practices. Sometimes it's worth asking "does this really make sense". I found myself wondering just that when I was staring at a container component that was a mirror image of the present

armw4

The Beginning

Yes...it's true...redux is smart....smarter than you even know. It really does want to help you. It strives to be sane and easy to reason about. With that being said, redux gives you optimizations for free that you probably were completely unaware of.

connect()

connect is the most important thing in redux land IMO. This is where you tie the not between redux and your underlying components. You usually take state and propogate it down your component hiearchy in the form of props. From there, presentational

armw4

I only had 45 minutes in total to finish the entire assessment, but this was question 5/6. I ran out of time before submitting my final answer (which I'm disappointed in). Once the challenge was over, I thought more about the solution to the problem and was able to figure it out. What made the challenge more tricky is that the input was coming in from standard input and being buffered via the data event. Seeing this in node just kinda freaks you out when you're racing against time. All you can think is 😳. The authors of the assessment were kind enough to register the required event handlers for accumalating the input, and even provided the location of where to act on the final, fully buffered version of the input (I believe this was the 'end' event). Yes, stdin is a stream in node, and as a result, an event emitter. I'd still have run out of time even if I were able to fully derive my solution, as this took me at least 20 minutes of heuristics with a clear head, after the fact. That's pretty shocking.

armw4

Streaming Resources in node With request From Source to Destination

The Beginning

If you've ever worked with http in node what you quickly come to realize is that it's not all that straightforward. You'll be bold, at least initially. Like me, you'll go read up on the docs for the http module. You'll properly subscribe to all the right events like on('data), and feel good about yourself. But if you're anything like be, you're bound do this wrong at some point. You probably won't subscribe to all the right things in the right order. You might not properly buffer the response. You may just have a WTF moment in production on day that brings down your entire site (just like I did about 2 years ago). Whatever the case may be, I believe you'll ultimately just settle on using request as your go to for http. If you want a promise based variant then you might go with some wrapper library as well.

So, we know request is the hip way of doing HTTP in node. request is kool. It's got a ton of usage and it pretty

armw4

Why?

Why...why are we here good sir? Well...I don't want to be here right now. I really don't. It's Saturday night, the Warriors beat the Clippers by the hair on the chinnies and dodged a late fourth quarter comeback, and I really want to eat. But...I have to blog. I have to do it now. If I don't, this story will not be the same. Why are we here? Because I'm on production support, that's why. I got an email from pagerduty that was like:

Unhandled rejection TypeError: next is not a function

I'm like huh? Wtf. What broke now? Why now? It's the weekend, I don't want to be here. I want to do me!!!!! But...I'm on production

armw4

Why?

Working with streams in node can be a scary and daunting task. The first time I saw the stream handbook, it left me quite perplexed. After seeing stuff like through, through2, and @acrute doing some stream kung fu on the job, I knew it was time. Streams are actually pretty straightforward once you get the hang of things. Read the handbook and the node docs and eventually your epiphany shall be born. I think one of the most confusing things for me was that Readable streams are for reading values that are produced by you, while Writeable streams are for dealing with values that are to be consumed by you. Say I wanted to put (write) some data from another stream into a file, and I wanted to take control of this process. Or say I just wanted to log (write) the results of a stream to say the console. These would be prime for Writeable

armw4

# https://docs.angularjs.org/api/ngMockE2E/service/$httpBackend

### @usage
path = require './path'
urlMatcher = path '/users/:guid/helloworld/:guid'

phones = [{name: 'phone1'}, {name: 'phone2'}]

$httpBackend.whenGET(urlMatcher).respond(phones)

armw4

by Antwan Wimberly

So I'm setting up my first project using gulp, karma, and jasminejs. I setup my karma task, and after repeatedly banging my head against my desk, I finally managed to get everything properly configured....or so I thought. It seemed like all the errors and warnings I'd encountered had been resovled (and they were). But for some reason, when I ran the task, I kept getting this output:

[13:03:58] Starting 'clean'...
[13:03:58] Finished 'clean' after 3.28 ms
[13:03:58] Starting 'files:scripts'...
[13:03:58] Starting 'files:specs'...
[13:03:58] Finished 'files:scripts' after 37 ms

armw4

# monkey patches jasmine (node) to provide beforeAll and afterAll hooks
#
# be sure to add this file as a helper as described in my answer on SO:
#
# http://stackoverflow.com/a/22054113/389103
#
# inspired by https://groups.google.com/forum/#!msg/jasmine-js/1LvuiUPunwU/SXPo6PMGSSMJ
#
# targets jasmine-node@1.13.1 and jasmine@1.3.1
#

armw4

by Antwan Wimberly

I recently encountered issues with yanking text in Vim. Yup, you know it, the infamous

E353: Nothing in register *

Only problem was, I wasn't sure if the issue was MacVim or spf13. Before logging an issue in either project, I decided to do a little research in hopes that someone had encountered a similar problem in the past. Luckily I can across this article by googling

macvim cant yank text