JavaScript is like socialism

  • JavaScript is like socialism, there are too many bad examples out there make this awesome idea unfairly blamed.
  • JavaScript is like socialism, it has a lot of good things in it but they are hard to get. Whoever don’t get it blame it.
  • JavaScript is like socialism, the theory is always looks better those practices.
  • JavaScript is like socialism, if you get it right, it will gives you more benefits than you can imagine.
  • JavaScript is like socialism, it’s dark side is so easy to be abused to create evil.
  • JavaScript is like socialism, most of the people swear on it out loud are the people don’t really know about it.
  • JavaScript is like socialism, it’s hard to prove it will works well in large scale because we don’t have that productivity yet.
  • JavaScript is like socialism, the older generation think it’s awful while the younger think it’s cool.
  • JavaScript is like socialism, if you believe in it’s philosophy, you will think our current system sucks.
  • JavaScript is like socialism, it’s not a proud thing to admit you are a practitioner in a traditional system.
  • JavaScript is like socialism, whoever exercise it correctly are the hell smart geniuses.
  • JavaScript is like socialism, you can argue it is a religious, however, there aren’t that much preachers, but hardcore practitioners.
  • JavaScript is like socialism, you can see almost everywhere use a little of it, but people don’t take the whole thing seriously.
  • JavaScript is like socialism, you may use it’s features to fix you system or rethink the fundamental of your system in it’s way.
  • JavaScript is like socialism, people won’t believe such an idea from so many years ago will works in the future.

The dark side of the software industry

  • Use complexities against complexities, add layers above layers
  • Tools addict and don’t pay attention to enhance one’s skills
  • Have customers to pay for our laziness
  • Keep covering up failures and refuse to learn from them
  • Neither learn from our own history, nor someone else intellectual outputs
  • A bunch of people know nothing about software engineering claim themselves as software engineers

To be continues…

describe vs. context in rspec

In Rspec world, you often see people using both “describe” blocks and “context” blocks together, like this

describe "launch the rocket" do
  context "all ready" do
  end

  context "not ready" do
  end
end

So what’s the difference between “describe” and “context” really?

According to the rspec source code, “context” is just a alias method of “describe”, meaning that there is no functional difference between these two methods. However, there is a contextual difference that’ll help to make your tests more understandable by using both of them.

The purpose of “describe” is to wrap a set of tests against one functionality while “context” is to wrap a set of tests against one functionality under the same state. Here’s an example

describe "launch the rocket" do
  before(:each) do
    #prepare a rocket for all of the tests
    @rocket = Rocket.new
  end

  context "all ready" do
    before(:each) do
      #under the state of ready
      @rocket.ready = true
    end

    it "launch the rocket" do
      @rocket.launch().should be_true
    end
  end

  context "not ready" do
    before(:each) do
      #under the state of NOT ready
      @rocket.ready = false
    end

    it "does not launch the rocket" do
      @rocket.launch().should be_false
    end
  end
end

This code is more readable than wrapping all the stuffs with “describe” blocks. Because when you read the tests under “context”, you know they are all testing the same thing the “describe” talk about. And you know a “context” is to setup the state of your object, in this case @rocket.ready which will effects the behavior of @rocket.launch() that gives you a conclusion, right away, without scanning the code back and forth.