ChuntaoLu

This doc proposes an abstraction to set fixture expectations for mock clients during a test run.

Overview

The goal is to treat fixtures management as first class citizen and maintain clean fixture semantics. Fixtures that belong to a specific client should reside in a centralized place associated with that client. It should be recognized that the mock client and its affinitivie fixtures together can become one functional unit. With this realization, the action of setting input/output expectations for a mock client method becomes implementation details and can be abstracted away by defining a method with the same expectation semantic on the combined functional unit. For example, instead of writing

import store "import/path/to/store/fixture"

// ad-hoc fixtures
userHeader := map[string]string{
	"x-client-version": "1.1.2",

ChuntaoLu

• create a new redis .conf file

$ cp /etc/redis/6379.conf /etc/redis/6380.conf

• edit /etc/redis/6380.conf, illustrated as below

...

ChuntaoLu

1. brew install gnupg21, pinentry-mac (this includes gpg-agent and pinentry)

2. Generate a key: $ gpg2 --gen-key

3. Take the defaults. Whatevs

4. Tell gpg-agent to use pinentry-mac:

   $ vim ~/.gnupg/gpg-agent.conf 
   

ChuntaoLu

HTTP Streaming (or Chunked vs Store & Forward)

The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.

However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on

ChuntaoLu

  --log_gc (Log heap samples on garbage collection for the hp2ps tool.)
        type: bool  default: false
  --expose_gc (expose gc extension)
        type: bool  default: false
  --max_new_space_size (max size of the new generation (in kBytes))
        type: int  default: 0
  --max_old_space_size (max size of the old generation (in Mbytes))
        type: int  default: 0
  --max_executable_size (max size of executable memory (in Mbytes))
        type: int  default: 0

ChuntaoLu

describe "Shopping Cart Requests" do
  let!(:user) { Fabricate(:user) }

  before(:each) do
    login_user_post("admin", "admin")
  end

  context "when I visit the shopping cart" do
    it " show the logged in users' cart items " do
      #Test stuff

ChuntaoLu

=Navigating=
    visit('/projects')
    visit(post_comments_path(post))

=Clicking links and buttons=
    click_link('id-of-link')
    click_link('Link Text')
    click_button('Save')
    click('Link Text') # Click either a link or a button
    click('Button Value')

ChuntaoLu

var parser = document.createElement('a');
parser.href = "http://example.com:3000/pathname/?search=test#hash";

parser.protocol; // => "http:"
parser.hostname; // => "example.com"
parser.port;     // => "3000"
parser.pathname; // => "/pathname/"
parser.search;   // => "?search=test"
parser.hash;     // => "#hash"
parser.host;     // => "example.com:3000"

ChuntaoLu

var serial_maker = function(){
  
  // produce an object that produces unique strings.
  
    var prefix = '';
    var seq = 0;
    return {
        set_prefix: function (p) {
            prefix = String(p);
        },

ChuntaoLu

A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.

I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.

I'd love comments and suggestions about any of these.

I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.

I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".