Developer Essentials

Suppose you have a Model User and it contains a global variable like this

COUNTRY_CODES = [['Anonymous Proxy', 'A1'], ['Satellite Provider', 'A2'], ['Other Country', 'O1'], ['Andorra', 'AD']]

and you want to access the key for the value '01' that is 'Other Countries'

User::COUNTRY_CODES.select{ |x| x[1] == '01' }.first.first

Same goes with controllers too.

The Hypertext Transfer Protocol specifies how a client machine requests information or actions from servers. This protocol specifies how two machines share information, which is called a request. These requests are composed of several parts which I’ll outline below.

+The first line of an HTTP request is called the Request-Line. It contains:

URI

Headers

Body

Method

Let’s take a closer look at these four elements.

URI

A URI or Uniform Resource Identifier is how objects are identified. Clients use URIs to tell the server what object to act on for a given request. In more general terms a URI is nothing more than a web address.

Request Header Fields

A client can communicate additional information to the server via a request’s headers. In addition to just communicating information about the client, ie. what type of browser the request originated from, these values can modify how the server responds to the request. For example, the Content-Type header value is used by the Rails framework to decode a request’s message body.

Message Body

The message body is used to send information from the client to the server about the entity the client wants to modify or create. The message can be communicated using several different encoding mechanisms, some of which I’ll discuss below. It is important to note that not all of the requests I discuss below are allowed to have message bodies.

Method

The method, sometimes called “verb” or “action”, tells the server what the client wants it to do. There are many different methods available, but we’re going to limit this blog to the four that are most relevant to Rails developers.

GET - how a client machine tells a server that it wants information about the item identified by the URI. Because GET requests are all about asking for information, they are not permitted to have request bodies. You still have the URI query string available to you if you need to send data from the client to the server on a GET request.

POST - how a client tells a server to add an entity as a child of the object identified by the URI. The entity that the client expects the server to add is transmitted in the request body.

PATCH - how a client tells a server it wants to modify an object identified by the URI the request is sent to.

DELETE - as you might guess, how a client tells a server to remove an object identified by the URI the request is sent to.

Let’s make some requests

cURL

cURL is a utility that makes it possible to send requests from the command line. We’ll use cURL to make some requests to a test Rails app which responds with strings.

Routes:

BackToBasics::Application.routes.draw do

 match '/curl_example' => 'request_example#curl_get_example', via: :get  match '/curl_example' => 'request_example#curl_post_example', via: :post end

Controller:

class RequestExampleController < ActionController::Base

 def curl_get_example    render text: 'Thanks for sending a GET request with cURL!'  end  def curl_post_example    render text: "Thanks for sending a POST request with cURL! Payload: #{request.body.read}"  end end

First we’ll make a GET request. We tell cURL to do a GET request (which is actually the default) with the “X” option.

% curl -X GET http://localhost:3000/curl_example Thanks for sending a GET request with cURL!

Rails server log:

Started GET "/curl_example" for 127.0.0.1 at 2013-06-21 14:38:22 -0700

Processing by RequestExampleController#curl_get_example as */*  Rendered text template (0.0ms) Completed 200 OK in 1ms (Views: 0.3ms | ActiveRecord: 0.0ms)

As you can see, our Rails app receives the GET request we sent from the terminal and then responds with the string we provided in the controller. The app uses the request’s URI and Method to figure out which controller and action to call.

Next we’ll make a POST request with a data payload. Again, we use “X” to specify the method. We also use “d” to specify the data to send in the payload.

1

% curl -X POST -d "backToBasics=for the win" http://localhost:3000/curl_example Thanks for sending a POST request with cURL! Payload: backToBasics=for the win

Rails server log:

Started POST "/curl_example" for 127.0.0.1 at 2013-06-21 14:47:37 -0700

Processing by RequestExampleController#curl_post_example as */*  Parameters: {"backToBasics"=>"for the win"}  Rendered text template (0.0ms) Completed 200 OK in 0ms (Views: 0.3ms | ActiveRecord: 0.0ms)

The Rails app receives our request. This time, in addition to the URL, it logs the data payload as hash of parameters.

Web Browsers

We’re all familiar with surfing the web. I’m sure it comes as no surprise that this experience is made up of a series of requests and responses. Let’s take a look at what’s happening when we type a URL into our browser’s address bar and hit enter. We’ll also look at what happens when we enter data into a form and submit it.

Below is the demo controller we’ll be sending requests to for this example.

Routes:

BackToBasics::Application.routes.draw do

 root to: 'request_example#index'  match '/request' => 'request_example#create', via: :post  match '/request' => 'request_example#create', via: :get end

Controller:

class RequestExampleController < ActionController::Base

 def index  end  def create    render json: params  end end

Address Bar

Typing a URL into the address bar of a web browser sends a GET request to the URLspecified. Sending a GET request in this fashion looks identical to sending a GET request through the terminal with cURL.

If we set the root path of our demo app to the index action of our dummy controller and navigate to localhost:3000 the browser will send the GET request. If we take a look at the Rails console we’ll notice the output is almost identical to what we saw with cURL.

Started GET "/" for 127.0.0.1 at 2014-01-31 15:09:53 -0800 Processing by RequestExampleController#index as HTML  Rendered request_example/index.html.erb (1.2ms) Completed 200 OK in 26ms (Views: 25.5ms | ActiveRecord: 0.0ms)

Forms

A form is made up of several key parts (we’ll look at several simple examples a bit later). In the opening form tag we have the action attribute. This attribute tells the form where to send the request. In addition to the action attribute we have the method attribute. This tells the form what type of request to send to the URI specified in the action attribute.

Request bodies are defined by a form’s markup. In the form tag there is an attribute calledenctype, this attribute tells the browser how to encode the form data. There are several different values this attribute can have. The default isapplication/x-www-form-urlencoded, which tells the browser to encode all of the values. If a form includes a file upload an enctype of multipart/form-data should be used. This encodes none of the values. Finally, you can set the enctype to text/plain this converts spaces, but leaves all other characters unencoded. Inside the inside the form element we have input elements. These elements will render as assorted input types in our website. Each input element in the form should have a name attribute. This name attribute tells the browser what to name the data specified in that input in the message body. The type attribute tells the browser in what format to communicate the data in the message body. There is more to this as outlined here.

GET

Let’s take a look at how we could send a GET request with a form.

The simple form below is made up of one text field and that text field will have the namemy_data. The final input is the submit which tells the form we actually want to send the request to the URI specified in the action attribute.

Let’s send a request. Assume a user has navigated to a page and the following form has been rendered. In the text box named my_data a user has entered the string “back to basics" and clicked the submit button.

<form action="/request" method="GET">

 <input type="text" name="my_data">  <input type=submit> </form>

Rails server log:

Started GET "/request?my_data=back+to+basics" for 127.0.0.1 at 2013-06-21 14:44:25 -0700

Processing by RequestExampleController#create as HTML  Parameters: {"my_data"=>"back to basics"} Completed 200 OK in 0ms (Views: 0.2ms | ActiveRecord: 0.0ms)

There are several interesting things about this request. You’ll notice that our Rails app received the request, but the URL includes a query parameter called my_data. This is the result of our decision to use the GET method for this request. Because GET requests have no payloads the data we collected with our form is added to the URI. In addition, you’ll notice that our text input ends up with a name of my_data in the payload, or the value we specified with the name attribute of our text input.

We can open the Network tab in our developer tools (Firefox or Chrome) and see that the data was added to the query string. This is because the action on the form is GET.

POST

The POST action works almost identically to the GET request with the exception of the payload. Let’s submit our form with the same text input and see what happens this time.

<form action="/request" method="POST">

 <input type="text" name="my_data">  <input type=submit> </form>

Rails server log:

Started POST "/request" for 127.0.0.1 at 2013-06-21 14:49:11 -0700

Processing by RequestExampleController#create as HTML  Parameters: {"my_data"=>"back to basics"} Completed 200 OK in 0ms (Views: 0.2ms | ActiveRecord: 0.0ms)

The first thing to notice is that our URL no longer contains the query parameter. It’s also important to note that our parameters hash looks identical. Let’s take a look at our network tab and see if we can learn anything about the request.

Examining the request we see that our payload includes what’s called form data. Our input elements are converted to a request payload and sent to the server. Again the name of our text input element is used as the name associated with the user’s text input.

XMLHttpRequest

It’s also possible to send requests via JavaScript. There is nothing special about these request from a mechanical perspective. They’re just requests like the ones we’ve sent above.

Because these requests are sent with JavaScript, in order to see what happens we’ll have to provide a function that deals with the response. We’ll use a simple function that will write whatever response we get to the JavaScript console.

function callback () {

 console.log(this.responseText); };

Ajax Form Data

When sending our Ajax requests we have several different options as to how we want to send the data. As we saw above there is a concept of form data. We can easily create a form data payload using only JavaScript.

var request = new XMLHttpRequest();

request.onload = callback; request.open("post", "http://localhost:3000/request"); var formData = new FormData(); formData.append('my_data', 'back to basics') request.send(formData);

Rails server log:

Started POST "/request" for 127.0.0.1 at 2013-06-21 14:53:03 -0700

Processing by RequestExampleController#create as */*  Parameters: {"my_data"=>"back to basics"} Completed 200 OK in 0ms (Views: 0.1ms | ActiveRecord: 0.0ms)

As is obvious from our log this request was handled no different than a “normal" form submission by our Rails application. There is no special magic about an Ajax request as far as our server is concerned.

Ajax JSON Data

Another option we have is to use JSON. In order to do this we need to slightly modify our request headers and tell our server that it needs to do something slightly different to parse our payload.

var request = new XMLHttpRequest();

request.onload = callback; request.open("post", "http://localhost:3000/request"); request.setRequestHeader("Content-Type", "application/json"); request.send('{"my_data":"back to basics"}');

Rails server log:

Started POST "/request" for 127.0.0.1 at 2013-06-21 14:55:55 -0700

Processing by RequestExampleController#create as */*  Parameters: {"my_data"=>"back to basics", "request_example"=>{"my_data"=>"back to basics"}} Completed 200 OK in 0ms (Views: 0.2ms | ActiveRecord: 0.0ms)

As you can see by simply modifying our request headers our Rails app is able to appropriately parse our payload and we end up with our my_data value available to our application.

Requests are one of the foundational elements of the internet as we know it. Understanding the individual elements of a request can make it much easier to debug issues with our Rails apps.

Keeping your code clean and organized while developing a large Rails application can be quite a challenge, even for an experienced developer. Fortunately, there is a whole category of gems that make this job much easier.

For most people, dead/inefficient code will build up over time. Others will find themselves in a similar predicament when they take over someone else's project.

Actually, my own experience with code cleaning/polishing gems stems from having to optimize someone else's Rails application. Considering its size and complexity, manual code refactoring was bound to be tedious and time consuming, so I decided to help myself as much I could with third-party tools.

If you want to keep your code maintainable, secure and optimized, take a look at some gems that have been doing the job for me:

1.

TRACEROUTE

Traceroute is a route cleaning tool for Rails applications. It provides a simple rake task for checking which routes are mapped to non existing controller actions, and finds out which controller actions are not reachable.

You will also be required to keep your controller helper methods and various before/after filters private, since they shouldn’t be a part of the public API. It sometimes has problems with showing false positives on mountable engines, but they can be easily overlooked.

2.

RACK-MINI-PROFILER

This is a nice tool used for finding bottlenecks of your applications. It does a live speed analysis of how long it took for the request to be processed and how much of that time it was doing various renderings, database queries and DOM loading. Just plug it into your Gemfile and you'll get a small window in the upper left corner of your page, showing you all of these information.

3.

BULLET

This one particularly blew my mind. The bullet gem helps you kill all the N+1 queries, as well as unnecessarily eager loaded relations. Once you install it and start visiting various routes in development, alert boxes with warnings indicating database queries that need to be optimized will pop out. It works right out of the box and is extremely helpful for optimizing your application.

4.

BRAKEMAN

A security analysis tool for your Rails applications. It scans through your application and outputs a nicely formatted table of possible vulnerabilities. Security warnings are grouped according to their severity (High, Medium and Low). You can learn more about their meanings onbrakeman's list of warnings.

Note that even if you end up not having any warnings, it doesn't mean that your app is secure, since brakeman sometimes overlooks some basic security pitfalls.

Security-wise, there is also a gem called bundler-audit, used for checking vulnerable versions of gems in your Gemfile.lock.

5.

DEADWEIGHT

Deadweight is used for cleaning unused CSS selectors. You have to hand out a set of your application's style sheets and HTML pages, and it will report which CSS selectors are safe to remove.

The gem won’t work out of the box in Rails, since most pages have dynamic content, but Jason Morrison from Thoughtbot wrote a blog poston how to create a Rack Middleware and integrate it into your test suite to collect all the HTML content in one place.

If you're using precompilers such as Sass or Less, you should compile all of your style sheets and hand them out as simple CSS files to the deadweight task. It is recommended that you remove all the vendor/third-party css files (such as Bootstrap files and similar) since they will end up clogging your output.

6.

RAILS BEST PRACTICES

Static code analyzer for finding Rails specific code smells. It offers a variety of suggestions; use scope access, restrict auto-generated routes, add database indexes, etc. For a full list of suggestions, check out the rails-best-pratices official page. Unfortunately, sometimes it reports lots of false positives, such as unused methods. Nevertheless, it contains lots of nice suggestions that will give you a better perspective on how to refactor your code and learn some best practices.

If you like the suggestions that rails best practices gives, you also might find Sandi Metz’s rules for developers quite interesting. You can check if your code complies to Sandi’s standards with the sandi_meter gem.

7.

RUBOCOP

A Ruby static code analyzer which you can use to check if your code complies with the Ruby community code guidelines. The gem reports style violations through the command line, with lots of useful code refactoring goodies such as useless variable assignment, redundant use of Object#to_s in interpolation or even unused method argument.

A good thing is that it's highly configurable, since the analyzer can be quite irritating if you're not following the Ruby style guide 100% (i.e. you have lots of trailing whitespaces or you double quote your strings even when not interpolating, etc.).

It's divided into 4 sub-analyzers (called cops): Style, Lint, Metrics and Rails. You can define which cops to use, as well as which files to exclude/include and tweak various other configuration options in a .rubocop.yml file.

8.

RUBYCRITIC

A relatively new gem that wraps around three static analysis gems - Reek(ruby code smells), Flay (code duplication detection) and Flog (ABC metrics). It creates nicely structured HTML files so you can browse through your smelly code and start refactoring. Out of all of the mentioned static code analysis tools, because of it's nice output, it's most convenient to overview and comment with your colleagues.

CONCLUSION

If you're working on an open source project or can afford to automate the process of running all of these static code analyzers on every commit, I would suggest using the code climate service. In case you decide to go down this route, I suggest reading "A Ruby on Rails Continuous Integration process using Github, Semaphore, CodeClimate and HipChat", a blog post written by my colleague, Jan Varljen.

Most of the functionalities that the listed static code analyzers can offer you is already wrapped inside it. Besides code quality reports, there is an optional code coverage report (basically what simplecov does).

A while ago I was in the mood for some experiments with new programming languages. Experimenting is almost always beneficial. Even if I study a language I never use, I might be able to learn some new concepts and become an overall better programmer.

I decided to build a command line tool that does some basic text analysis. First, I wrote it in Ruby because I needed to learn some Ruby for a task anyways. Later, I decided to try Go since everyone is talking about it lately.

The following is a summary of my thoughts about those programming environments.

What Ruby taught me

Ruby really feels like a higher level language. It focuses a lot on abstractions and DSLs. This makes it super quick to get certain tasks done. Also, it makes my code look almost like plain English:

describe '#total_words' do  it 'counts the total words' do    expect(@stat.total_words).to eq 904061  end end

Even the core language and standard library include so much sugar to work with that I don’t need to write much code since so many algorithms are provided (think map, filter, inject, …). I just need to find the right one.

Sometimes it’s really surprising how abstract the language core is. ARGF, for example, is a stream that reads lines either from STDIN or from a file specified as command line argument:

ARGF.each { |l| stats << l }

The dynamic nature of Ruby allows easy meta programming. Building blocks like the Enumerable class make coding really productive.

Reading this code I understand pretty quickly what it does. But it takes way longer until I also understand how it works under the hood:

def most_used(num = 1)  @histogram.sort_by { |k, v| v }.reverse.map(&:first).take(num) end

I also enjoy it a lot to have an interactive REPL as powerful as Pry. Since I can look up so many things right inside my development environment, I find myself spending way less time searching for API documentation.

What Go taught me

Static typing speeds up the workflow since I see many errors right in the editor. It protects me against silly typo errors. Go’s strictness also, by some extent, enforces cleaner code by not allowing me to declare unused variables and so on.

The default tooling provided by the Go environment is really helpful. I enjoy having golint and gofmt right in my editor. The default testing tools are great too. I would love to have tooling as mature as in Go when working with a dynamic language.

Since I need to declare the types of my data in Go, I need to think more about relations and architecture. By being forced to think about the data first, I separate concerns earlier on.

As an example: By thinking about the data first, I realized I can just collecttotal and length upfront instead of calculating them later on (as I did in the Ruby version):

type Histogram map[string]int type Textstat struct {    total     int    histogram Histogram    length    int }

Writing Go took me a little longer since I had to implement a lot of functionality provided for me in Ruby. However, for every task it also made me think about what the computer actually does. This way my program ended up doing fewer unnecessary things. It might also be more performant code.

Looking at the one-liner implementation of most_used in Ruby, the Go version is more difficult to understand. However, if you understand the Go version you actually know what the computer is doing:

func (t Textstat) MostUsedWords() []string {    max := minInt(len(t.histogram), 10)    words := make([]string, max)    for i := 0; i < max; i++ {        words[i] = t.histogram.RemoveMax()    }    return words }

Another thing I realized when writing Go was that I ended up thinking about every possible error. It might take a little bit more time if you just want to get something working, but the end result feels more robust.

What’s next?

It would be nice to have all of the advantages of both languages in one programming environment. Maybe my next target should be Haskell?

Most of the advantages listed here are actually not platform dependent.

I love to see the web as a programming platform improve in areas liketooling and coding style. In my opinion, Javascript can already compete with the expressiveness of Ruby. The latest efforts enable us to reason about problems in simple and declarative ways.

Now I would love to see a way to bring the safety and robustness of Go to the web. Unfortunately, I’m not really convinced by the solutions out there. Maybe we could achieve the same goals in a dynamic language by advancing our testing technologies? Which other ways can we find?

If you're using Git, you're probably using pull requests. They've been around in some form or other since the dawn of DVCS. Back before Bitbucket and GitHub built fancy web UIs, a pull request might've simply been an email from Alice asking you to pull some changes from her repo. If that sounded like a good idea, you could run a few commands to pull the changes into your master branch:

 $ git remote add alice git://bitbucket.org/alice/bleak.git

 $ git checkout master

 $ git pull alice master

Of course, randomly pulling Alice's changes into master isn't a great idea. master represents the code that you're intending to ship to your customers, so you typically want to keep a close eye on what gets merged in. Rather than pulling into master, a better pattern is to pull them down into a separate branch and inspect the changes before merging them in:

$ git fetch alice $ git diff master...alice/master

Using git diff's "triple dot" syntax shows us the changes between the tip of alice/master and its merge base (or common ancestor) with our local master branch. This effectively shows us all of the changes that Alice wants us to pull.

git diff master...alice/master is equivalent to git diff A B

At first glance, this seems like a reasonable way to review the changes involved in a pull request. In fact, at time of writing, this appears to be how most git hosting tools have implemented their pull request diffing algorithms.

However there are a couple of problems with using the "triple dot" diff approach to generate a diff for a pull request. In a real project, the master branch is going to significantly diverge from any givenfeature branch. Other developers will be working on their own branches and merging them in tomaster. Once master has progressed, a simple git diff from the feature branch tip back to its merge base is no longer adequate to show the real differences between the two branches. You're only seeing the difference between the branch tip, and some older version of master.

The "triple-dot" git diff master...alice/master doesn't take into account changes to master

Why is not seeing these changes in the pull request diff a problem? Two reasons.

Merge conflicts

The first problem is something you probably run into fairly regularly: merge conflicts. If you modify a file on your feature branch that has also been modified on master, git diff is still just going to show you the changes that have been made on your feature branch. git merge on the other hand will spit out an error and spew conflict markers all over your working copy, showing that your branches have irreconcilable differences. Or at least differences beyond the capabilities of git's sophisticated merge strategies.

No-one enjoys resolving merge conflicts, but they're a fact of life for all version control systems. At least, version control systems that don't support file-level locking, which has its own problems.

But merge conflicts are far preferred to the second problem you can run into if you use a "triple dot" git diff for pull requests: a special type of logical conflict that will merge cleanly, but can introduce subtle bugs into your codebase.

Logical conflicts that merge cleanly

If developers modify different parts of the same file on different branches, you might be in for some trouble. In some cases, different changes that work independently and appear to merge happily without conflicts, can actually create a logic bug when combined.

This can happen in a few different ways, but one common way is when two or more developers incidentally notice and fix the same bug on two different branches. Consider the following javascript for calculating the ticket price for an airfare:

// flat fees and taxes

var customsFee         = 5.5;

var immigrationFee     = 7;

var federalTransportTax = .025;

function calculateAirfare(baseFare) {

  var fare = baseFare;              

  fare += immigrationFee;

  fare *= (1 + federalTransportTax);

  return fare; }

There's a clear bug here - the author has neglected to include the customs fee in the calculation!

Now imagine two different developers, Alice and Bob, each notice this bug and fix it independently on two different branches.

Alice adds the customsFee before the immigrationFee:

function calculateAirfare(baseFare) {

  var fare = baseFare;              

+++ fare += customsFee; // Fixed it! Phew. Glad we didn't ship that! - Alice

  fare += immigrationFee;

  fare *= (1 + federalTransportTax);

  return fare;

}

And Bob makes a similar fix, but on the line after the immigrationFee:

function calculateAirfare(baseFare) {

  var fare = baseFare;              

  fare += immigrationFee;

+++ fare += customsFee; // Fixed it! Gee, lucky I caught that one. - Bob

  fare *= (1 + federalTransportTax);

  return fare;

}

Because different lines were modified on each branch, these two branches will both merge cleanly intomaster, one after the other. However, master will then have both lines. And, a serious bug that will cause customers to be double-charged the customs fee:

function calculateAirfare(baseFare) {   var fare = baseFare;                 fare += customsFee; // Fixed it! Phew. Glad we didn't ship that! - Alice   fare += immigrationFee;   fare += customsFee; // Fixed it! Gee, lucky I caught that one. - Bob   fare *= (1 + federalTransportTax);   return fare; }

(This is obviously a contrived example, but duplicated code or logic can cause pretty serious problems:goto fail; anyone?)

Assuming you merged Alice's pull request into master first, here's what Bob's pull request would look like if you used a "triple-dot" git diff from the branch tip to the common ancestor:

function calculateAirfare(baseFare) {

  var fare = baseFare;              

  fare += immigrationFee;

+++ fare += customsFee; // Fixed it! Gee, lucky I caught that one. - Bob

  fare *= (1 + federalTransportTax);

  return fare;

}

Because you're reviewing a diff against the ancestor, there is no warning of the impending doom that will occur when you hit the merge button.

What you really want to see in a pull request is how master will change when you merge Bob's branch in:

function calculateAirfare(baseFare) {

  var fare = baseFare;              

  fare += customsFee; // Fixed it! Phew. Glad we didn't ship that! - Alice

  fare += immigrationFee;

+++ fare += customsFee; // Fixed it! Gee, lucky I caught that one. - Bob

  fare *= (1 + federalTransportTax);

  return fare;

}

This diff clearly shows the problem. A pull request reviewer will spot the duplicated line (hopefully) and let Bob know that the code needs some rework, thus preventing a serious bug from reaching masterand eventually production.

This is how we decided to implement pull request diffs in Bitbucket and Stash. When you view a pull request, you're seeing what the resultant merge commit will actually look like. We do this by actually creating a merge commit behind the scenes, and showing you the difference between it and the tip of the target branch:

git diff C D where D is a merge commit shows all differences between the two branches

If you're curious, I've pushed the same repository to a few different hosting providers so you can see the different diff algorithms in action:

a pull request with GitHub's "triple-dot" diff

a pull request with Bitbucket's "merge commit" diff

a pull request with GitLab's "triple-dot" diff

The "merge commit" diff used in Bitbucket and Stash shows the actual changes that will be applied when you merge. The catch is that it's trickier to implement, and more expensive to execute.

Moving targets

The first problem is that the merge commit D doesn't actually exist yet, and creating a merge commit is a relatively expensive process. The second problem is that you can't simply create D and be done with it.B and C, the parents of our merge commit, could change at any time. We call a change to one of these parents rescoping the pull request, because it effectively changes the diff that will be applied when the pull request is merged. If your pull request is targeting a busy branch like master, your pull request is likely being rescoped very frequently.

Merge commits are created any time either branch changes.

In fact, every time someone pushes to or merges a branch into master or your feature branch, Bitbucket or Stash is potentially going to need to calculate a new merge in order to show you an accurate diff.

Handling merge conflicts

The other problem with performing merges to generate pull request diffs is that, every now and then, you're going to have to handle a merge conflict. Since your git server is running non-interactively, there won't be anyone around to resolve them. This makes things a bit more complicated, but actually turns out to be an advantage. In Bitbucket and Stash, we actually commit the conflict markers as part of the merge commit D, and then mark them up in the diff to show you how your pull request is conflicting:

In Bitbucket and Stash diffs: green lines are added, red lines are removed, and orange lines are conflicting.

This means we can not only detect ahead of time that your pull request is conflicting, we can also let reviewers discuss how the conflict should be resolved. Since conflicts always involve at least two parties, we feel that the pull request is the best place to determine an appropriate resolution.

I find that I operate in one of two modes when I’m writing software. I’m either approaching a project asa quick hack or as developing software. As much as anything else, this affects how I approach the project and what kinds of results that I get.

When I’m operating under the auspices of the quick hack, everything is moving toward and subordinate to the goal. The end product of the quick hack is everything. I approach the actual hacking in a fit of pique, it’s annoying that this thing isn’t done yet. I always take the way that’s most expedient and I’m always looking for a shortcut or quick fix.

When I set out to develop software my mindset is different. Here I’m nurturing a seed of an idea. I’m taking small pieces and building connections between them. I have the sense that I’m making something new, or at least I’m making something that’s mine – I feel ownership. I also assume that the thing that I’m building has to last.

The natural habitat of a quick hack is a framework. When I’m confronted with something that doesn’t fit, I look for that next StackOverflow answer that’ll tell me how to shoehorn it in among the Tetris pieces that I already have. The framework is not malleable, I must square-off my round peg.

Libraries are what support developing software. Properly in charge, I choose a subordinate library and apply its talents appropriately. There is no hint of having to make my design fit within the strictures of someone else’s plan. I have the skeleton, I merely need the flesh. If I find that a library no longer suits my needs, it is easily removed. Well-scoped libraries tend to match one another much more closely than frameworks do. The problem that the library solves, the abstraction that it grants, tends to be more universal than a framework. Two HTTP client libraries will tend to expose those actions that HTTP supports. With a framework, I must first accept its world-view before I can start using it.

As I’ve grown as a software developer, I’ve come to believe that whenever possible I should use libraries over frameworks. This has been said many times before, but now I’m getting there via my own experience. I’m beginning to see that the advantages of frameworks can be matched by a powerful language combined with a little sense about the high-level architecture that the application demands. Over time, I’ve developed my own palette of designs and code to accomplish most tasks. I can act as a linker, assembling only those functions that are needed to accomplish the task at hand.

Lastly, I worry that time and brainpower that I pour into frameworks goes unrewarded. When I don’t want to use a framework, the framework changes, or I want to do something that the framework doesn’t support, I’m left out in the cold. All of these scenarios play out often. Each time a new version of Rails comes out, it is infused with whatever OOP fashion is reigning at the time: concerns, presenters, etc. The way that I used to do something is rendered obsolete without warning and without recourse. The knowledge that I had about how to work with the framework has gone stale – like money, “you can’t take it with you.”

There are several ways to execute shell code in Ruby. Spawn is the method behing exec, system and %x[…], don't use it, but check the documentation below.

%x{ } or backticks – quick and easy

Returns the standard output of running the given command in a subshell. This is an alias for `…`, and you can use string interpolation.

Example:

name = 'ls' result = `which #{name}`

It does not escape anything you inject in the string.

If you want to find out if the call was successful you can ask $?.success?.

system – when you want to know how it went

Similar to exec, but executes the given command in a subshell. Your script will go on. Returns:

true if the command gives zero exit status

false for non zero exit status

nil if command execution fails, $? holds an error status.

Example:

result = system 'cp', '/full/path/to/my_file', '/target/directory' if result.nil? puts "Error was #{$?}" elsif result puts "You made it!" end

exec – the last thing you do

Replaces the current process. Take care: when an exec command exits, it exits your script as well; i.e. exec will be the last statement executed in your Ruby script. Output is written to stdout.

Raises SystemCallError if the command couldn‘t execute.

Example:

puts "Creating directory..." exec 'mkdir', 'new_directory' # the code here and below will never be read

spawn – gives you a good level of control

Takes the same parameters as exec and system: [env,] command [,options]

envOptional hash with :name => environment_name, e.g. spawn(:name => 'development', 'echo hello world')command, either:

A single string which is passed to the standard shell (with shell expansion), e.g. exec('cat * | grep denied')

The command name and one or more plain arguments (without shell expansion), e.g. exec *[ 'git', 'add', 'Gemfile' ] If the first command is a two-element array, the first element is taken as the command to be executed, and the second argument is used as the argv[0] value, which may show up in process listings. E.g. exec ['ls', 'foo'], 'foo.bar', 'baz.bar'

optionssee the Ruby docs

The shell used is /bin/sh on Unix-like systems, ENV["RUBYSHELL"] or ENV["COMSPEC"] on Windows NT series, and similar.

Spawn calls IO.popen.

open3 – for those who want to control everything

"Open3 grants you access to stdin, stdout, stderr and a thread to wait the child process when running another program. You can specify various attributes, redirections, current directory, etc., of the program as Process.spawn." Quoted from the docs

Is it reasonable to expect mere mortals to have mastery over every facet of the development stack? Probably not, but Facebook can ask for it. I was told at OSCON by a Facebook employee that they only hire ‘Full Stack’ developers.  Well, what does that mean?

To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology.

Good developers who are familiar with the entire stack know how to make life easier for those around them. This is why I’m so against silos in the work place. Sure, politics and communication challenges get in the way in large organizations. I think the point Facebook is going for with their hiring policy is, if smart people use their heads and their hearts, a better product gets built in less time.

layers of the full stack:

Server, Network, and Hosting Environment.

This involves understanding what can break and why, taking no resource for granted.

Appropriate use of the file system, cloud storage, network resources, and an understanding of data redundancy and availability is necessary.

How does the application scale given the hardware constraints?

What about multi-threading and race conditions? Guess what, you won’t see those on your development machine, but they can and do happen in the real world.

Full stack developers can work side by side with DevOps. The system should provide useful error messages and logging capabilities. DevOps will see the messages before you will, so make them count.

Data Modeling

If the data model is flawed, the business logic and higher layers start to need strange (ugly) code to compensate for corner cases the data model doesn’t cover.

Full stack developers know how to create a reasonably normalized relational model, complete with foreign keys, indexes, views, lookup tables, etc.

Full stack developers are familiar with the concept of non-relational data stores and understand where they shine over relational data stores.

Business Logic

The heart of the value the application provides.

Solid object oriented skills are needed here.

Frameworks might be needed here as well.

API layer / Action Layer / MVC

How the outside world operates against the business logic and data model.

Frameworks at this level should be used heavily.

Full stack developers have the ability to write clear, consistent, simple to use interfaces. The heights to which some APIs are convoluted repel me.

User Interface

Full stack developers: a) understand how to create a readable layout, or b) acknowledge they need help from artists and graphic designers. Either way, implementing a good visual design is key.

Can include mastery of HTML5 / CSS.

JavaScript is the up and coming language of the future and lots of exciting work is being done in the JavaScript world (node, backbone, knockout…)

User Experience

Full stack developers appreciate that users just want things to work.

A good system doesn’t give its users carpal tunnel syndrome or sore eyes. A full stack developer can step back and look at a process that needs 8 clicks and 3 steps, and get it down to one click.

Full stack developers write useful error messages. If something breaks, be apologetic about it. Sometimes programmers inadvertently write error messages that can make people feel stupid.

Understanding what the customer and the business need.

Now we are blurring into the line of architect, but that is too much of a hands off role.

Full stack developers have a grasp of what is going on in the field when the customer uses the software. They also have a grasp of the business.

  Other Pieces of the Puzzle:

Ability to write quality unit tests. By the way, even JavaScript can have unit tests these days.

Understanding of repeatable automated processes for building the application, testing it, documenting it, and deploying it at scale.

An awareness of security concerns is important, as each layer presents its own possible vulnerabilities.

  Closing Thoughts:

It is very bad practice to tightly couple code to a specific implementation (library, OS, hardware, etc). Just because a full stack developer understands the entire spectrum doesn’t mean they have license to take shortcuts. Well, actually they do if it is a build and throw away prototype.

Technology start-ups need full stack developers for their versatility!  However, as an organization matures, it needs more and more focused skills.

At the start of every year, I do this thing where I update my resume with falsehoods. I lie, intentionally and boldly: proficient in X; launched Y; led a team and successfully Z'd. I mold it to perfection.

The spacing, superb. The type, crisp. The language, terse. The experience, impressive. I craft it as perfect as an antiquated and dead document can be crafted. And in it's perfect state, wrought with lies, I think about what steps I can take in the coming year to make it less fiction and more non-fiction.

I do this because my resume serves me. I'm the audience. When someone other than me requests a copy of it, I lie some more. I serve them a part of my resume. I take my wonderfully crafted piece of fiction, and, omitting the falsehoods, or more specifically, the falsehoods that remain at that time, and serve the requestor a non-fiction form.

-- Via Akshay shinde

Our current engineering education system has some flaws which need to be addressed.

Let me briefly run you through the pros and cons of our current education system.

Good things

Helps students to grow socially

Forces us to study things which if given a choice we will never study and sometimes they turn out to be good

Bad things

No exposure to the actual industry, very few people can start working on live projects without a good training program

More focus on theoretical knowledge and less on practical knowledge

Waste of time studying useless subjects (More precisely non optimal use of time. I liked maths, studied it for four semesters but none of that knowledge was used while working as a programmer)

People are forced to study subjects which they don’t like

Very few teachers actually want to teach (I’m talking about India)

The cost, which is increasing with every passing day

Now I don’t think the pros weigh more than the cons, then why are we still sticking with the current education system. Is the certificate that we get at the end of four years worth it? Majority of the people who graduate from my class didn’t have any clue about their future job role. And if you don’t have that exposure then how will you decide which job role suits you the best. I read this somewhere in a meme

In India everyone first becomes an engineer and then decides what he wants to do in life

It’s funny but the sad part is that it’s true. So how do we fix that?

The awesome college

Now imagine a college where you learn by building things. It’s not a college, but it’s more like an IT startup. Lets start with only the software sector because that’s what I’m good at. You start working on small client projects. You start learning things required to finish that project. It can be a programming language, hardware knowledge, designing, user experience, communication skills or rocket science. This gives you the exposure about how software world functions and where you can fit in. After that you can dig deeper into what suits or attracts you the most. Slowly you start learning more by working on bigger projects. At any point of time you can change what you want to learn. Also you can choose to work on your own product or start your own startup. The company/college will be self sustaining. You don’t need to pay any tuition fees and you might get paid some stipend if you are doing a good job.

The teachers

Obviously there will be teachers who are experts in their respective domains. Their job role is to work on live projects as well as teach. People who can give you the best advise related to their field of expertise. The best part about the teachers will be that they are teaching because they want to teach and not because they couldn't get a different job (I don’t want to insult teachers here. There were very few good teachers in my life who helped me become what I’m today, I wish there were many). As the teachers will be working on live projects, the disconnect between what you are learning and what is happening in the industry will vanish.

The company

Now lets take a look at the company part of this project. The company will focus more on quality than quantity. We won’t be selling low quality software at cheap price instead we will sell quality software at premium price. Students and teachers will work together to build software products. The employees will be domain experts and at the same time people who love to teach. The students will be offered a full time job in the company on completion of their four years. The main focus will be on cumulative growth instead of profit.

Helping the underprivileged

One objective of this company/college will be to help students who can’t afford higher education. I got financial help from many people while I was completing my engineering, without that I would have never done computer engineering. Now I don’t think that everyone gets this kind of help. This college will provide you quality education at zero price. Hopefully when it grows, it will be able to provide you other facilities too.

Financial model

The company/college will make money like any other IT company, that is by building software. The full time employees will spend half of their time building great software. At the same time the students will spend good amount of time working on live projects. This way the students pay for their education while learning new things at the same time. We don’t want to take donations. If someone really wants to help, they can give guest lectures, give us software projects to work on or invest in the company/college. This way it won’t become a charitable organisation.

The final objective

The final objective of this project is to create a better education system. To build a renowned university where people learn by doing. Where creativity is valued as much as intelligence and to assess people based on their actual work and not theoretical knowledge.

By - Danny Nunez

I see countless posts and questions by new developers who want to break into the PHP development world. A common question is  What is the best way to gain PHP experience? Common answers are to build up a github profile, start blogging, internships or pro-bono work. Yeah that sounds great but for someone who is truly green that may be a little outside of their comfort zone If it is for someone looking to learn relevant skills to break into the job market the advice is a little vague. Most of the advice given online is from the hobbyist’s perspective and not from the perspective of someone who has a mortgage to pay and a family to take care of.  Below is a list of options a new php developer should take to gain experience that will hopefully land you that first PHP Web Development job.

CMS or FrameWork

I recommend picking either a CMS or a Framework. Please choose one of the popular options listed below. And stay away from small lesser known frameworks unless you want to code for fun then please do. The goal of this advice is to get the new developer into the job market faster. A quick search on indeed.com for a framework or CMS in your area will give you an idea of what Job Skills are in demand.

ZEND - http://framework.zend.com/

Tutorials – Good Luck.

Pros: 

High Salary – Low Supply of PHP Developers with Zend Experience

Job Security – very few PHP developers take on the challenge of learning Zend

Cons: 

Extremely High Learning Curve

Used mainly by enterprise business – ( This could be a plus if you are looking for stability. Just be prepared for the corporate lifestyle. )

Symfony  -  http://symfony.com/ 

Tutorials - 

Tuts Plus 

KNP University 

Screenfony 

The Symfony Book 

Pros: 

High Salary

Lots of Documentation

Very Large Community

Cons: 

High Learning Curve

Laravel -  http://laravel.com/

Tutorials - 

Tuts Plus 

Laracasts

medium.com

Pros: 

Low Learning Curve

Lots of Documentation

Large and Growing Community

Cons: 

A relative newcomer to the php framework there are fewer employers looking for developers with Laravel experience.

Other Frameworks:

YII

Silex

Slim

CakePHP

auraphp

Phalcon

WordPress - http://wordpress.org/

Tutorials - 

Tuts Plus 

wp101

Lynda.com

Pros: 

Low Learning Curve

Lots of Documentation

Large Community

Low barrier to entry for Jobs

Cons: 

Oversaturated Job Market

Low paying entry level jobs

WordPress Developers are expected to be a Jack of All Trades – Frontend and Backend

Hated by PHP Elitists

Drupal - https://www.drupal.org/

Tutorials - 

Tuts Plus 

Durpalize ME

Lynda.com

Pros: 

Low Learning Curve

Lots of Documentation

Large and Growing Community

Cons: 

Oversaturated Job Market

Low paying entry level jobs ( But they do increase nicely with experience)

Drupal Developers are expected to be a Jack of All Trades – Frontend and Backend

Hated by PHP Elitists

Drupal 8 is changing a lot of the under the hood code – So beware you will have to learn two version of the CMS to enter the Job Market as you will have to maintain Drupal 7 and build out new Drupal sites with Drupal 8.

Joomla - http://www.joomla.org/

Tutorials - 

Tuts Plus 

SiteGround

Lynda.com

Pros: 

Low Learning Curve

Lots of Documentation

Large and Growing Community

Cons: 

Oversaturated Job Market

Low paying entry level jobs

Joomla Developers are expected to be a Jack of All Trades – Frontend and Backend

Hated by PHP Elitists

Certifications

PHP Certification: http://www.zend.com

MYSQL Certification: http://education.oracle.com 

COMP TIA Linux Certification: http://certification.comptia.org 

Unicorn Skills That will be required – (Some how through magic)

Linux - https://linuxacademy.com/linux

Apache - lamp-stack

Nginx – Scaling PHP

Git Version control - https://try.github.io , https://www.codeschool.com/courses/try-git

HTML5 - http://html5doctor.com/

CSS  2 and 3 - https://developer.mozilla.org/en-US/docs/Web/CSS/Reference

JavaScript - https://developer.mozilla.org/en-US/docs/Web/JavaScript

Jquery

Jquery UI 

At least  one JavaScript Framework

Angular JS

Backbone JS

Ember JS

htaccess - http://htaccessbook.com/

Photoshop  - Yes PM’s will expect you to also be a designer for some reason.

UI/UX - Yes PM’s will expect you to also be a designer for some reason.

Unit Testing - http://phpunit.de/ or Chris Hartjes will destroy you. 

PHP Composer  - Composer is a tool for dependency management in PHP. 

PHP Code Standards - http://www.php-fig.org/

REST  - Restful Web Apis 

PHP Security – Building Secure PHP Apps

Sample Projects

You will need to complete a few sample projects to get a few of the basic skills required for an entry level developer.

Build a CMS – If you choose to take the framework route you will more than likely be asked to build a small custom cms.

Pages

Posts

File management

User management

Sitemap Generator

Menu Management

Build a Web Scraper – When transferring old sites to a cms. You will need to have the skills below to make the process easier.

Scrape Links from a website

Scrape Content from a website

API – API integration is all the rage. A must have for any web developer.

Google Analytics

Facebook

Twitter

Instagram

Salesforce

Build a Custom Plugin for the CMS of your choice.

Build a Custom Theme for the CMS of your choice. ( Use themeforest for inspiration )

Stock Bootstrap Theme

Stock Foundation Theme

CSS Dropdown menus and Flyout Menus – PM’s love these

Crazy CSS Animations - PM’s love these

JQuery Animations - PM’s love these

Sliders - PM’s love these

Conclusion

By John Sonmez

My software development career began about 15 years ago.

But only in about the last 5 years did I really start to see a large boost in my software development career.

Here are some of the things I wish I would have known when I got started in the software development industry; things that would have made me more successful, much earlier, if I would have known them.

There is no “right way” in software development

I wasted a large amount of time, both in studying and arguing, early on in my career, falsely believing there was an absolute “right way” for many aspects of software development.

It turns out that just about everything I once thought was correct about software development at some point turned out to be wrong.

But more importantly, I found that very few things were black and white.  Almost every decision when writing code and developing software is based on the current circumstances.

I’ve talked before about how the religious adoption of a technology can be harmful to software developers, but this topic goes beyond just a technology.

It is also true that no best practice is universal.  Even highly charged topics like whether or not to unit test or whether agile or waterfall methodologies are best, do not have straightforward one-is-always-right answers.

In my career, I’ve wasted plenty of time on the “right way” road that led to nowhere instead of taking the “pragmatic” (practical) road, which would have carried me much further.

Reading a book cover-to-cover is not the best way to learn

When I first started wanting to grow my knowledge of programming and different technologies, I spent too much time reading technical books about a specific technology cover to cover.

There is nothing wrong with reading books, but often the choice of what book to read and what parts of it to read are very important.

For example, I remember reading a very large book on programming with Visual C++.  (I’m pretty sure it was an earlier version of this book.)  Anyway, the book was a good book with lots of information, but reading it cover to cover was not the best approach to learning Visual C++.

I would have learned and retained a lot more by skimming over the chapters of the book to get a broad understanding of what there was to know about Visual C++, then figuring out what things were most important to learn first.

I would have had much more success by sitting down and actually practicing the basics by trying to actually build something than just reading or going through examples in the book.  You don’t really learn a technology until you’ve solved real problems with it.

Learning particular technologies in-depth is a waste of time

Not only did I waste time by reading books cover to cover, but I also often chose to read the wrong books.

I had mistakenly believed that learning a particular technology inside-out would be a good way to advance my career.

I spent too much time reading books about very specific technologies like ASP.NET or Hibernate instead of reading more books like “Code Complete,” “Clean Code,”and “Agile Principles, Patterns And Practices in C#.” (All of these books, by the way, I recommend that you read, if you haven’t already.)

While it is important to know about the technology you are using, it isn’t important to be an absolute expert in that particular technology.  There isn’t much benefit to knowing the exact API call to make when you can just easily look it up when you need it.

Too many technologies that I spent a good amount of time learning about in depth, ended up either dying out or being technologies that I eventually abandoned myself.  Most of the knowledge about those specific technologies ended up representing a big waste of time.

I found that it was important to become an expert at whatever programming language that I was using at the time, because expertise in a particular programming language will usually last you a pretty long time; I definitely would have still spent time learning in depth about C++, C# and Java, but, I perhaps, spent a little too much time learning all the intricacies of C++, which isn’t benefiting me much now.

Community is extremely important in your software development career

Early in my career, I made the mistake of not really reaching out to the community for help and to provide help to others.

I was always good about helping my coworkers and being social at the various jobs I held, but I never really reached much beyond my company.

I spent a large amount of time trying to make an investment in my career at a particular company at the expense of making an investment of my time in the software development communities that I was involved in.

I spent lots of time creating internal presentations on technologies or best practices that could have been spent creating content and material that could have served the community as a whole, as well as brought me recognition at my job.

I also made the mistake of not thinking that I had something valuable to contribute.

I talk to many beginning software developers now and sometimes I think they have much more to contribute to the community than us software developers that have been in the field for a long time, because they understand better the issues that other beginners are struggling with.

If I could do it over again, I would have made sure to be much more involved in conferences and user groups earlier in my career.  I would have started my blog much earlier and I would have used much of my learning time to create projects and resources that would be able to help others rather than just reading a book.

Always have a side project

Perhaps the biggest change I would have made that would have impacted my career the most would have been to cut out all the TV watching, Everquest and World of Warcraft playing I did earlier in my life and replace that time with work on a side project.

I’ve wasted a pretty sizable amount of time in my life doing things that were enjoyable, but didn’t produce any long term benefit for my life.

About 3-4 years ago, I pretty much cut out watching TV completely and now I hardly ever watch movies either.  TV and most movies are just a huge waste of time that you could be using to do something useful.  The same goes for video games for the most part, but at least with video games you are actively doing something not just absorbing useless information.

I’ll always love to play video games and I don’t think I’ll ever stop, but I do wish I would have spent a good deal of the time I spent playing video games and watching TV on a side project instead.

Sadly, the first real side project I actually took on was only about 3 years ago when I started creating my first Android application.

When you are working for someone else, it is really important to spend time working for yourself as well, otherwise you are building someone else’s empire while neglecting your own.

This is a small introduction that how should one proceed with SEO.

Before starting any SEO efforts, it is necessary to start collecting data about how your site is being used. Google Analytics is a great, free system that lets you track how your site is being used and by whom.

While you are tracking what is happening on your site, it is a good idea to figure out what business goals you want your site to accomplish.

Once you understand your goals, you will want to create a strategy for achieving them. There are many tools that will help you narrow down keywords and ideas for content, such as Soovle.

It is always a good idea to figure out who your competitors are and investigate their webpages as well as your own. Can't think of any competitors? Try using Similar Web for some ideas. A good tool for analyzing your competitors are: SEMRush. A particularly brilliant idea is to investigate who has linked to your competitors and to try to get links from them. AHrefs and Open Site Explorer can help.

While rebuilding your site (and analyzing other sites), you can get instant feedback on the keywords that are being used with Craawler.

No one wants a slow site. Google has created Page Speed Insights which will calculate how long your site takes to load and suggest methods for improving the speed. Very technical folks might prefer GTMetrix orPingdom for detailed analysis.

To ensure that your website works with all browsers, it is a great idea to validate your pages with the w3 validator service. It will report back if your html contains any errors.

Across the board, the more CEOs get paid, the worse their companies do over the next three years, according to extensive new research. This is true whether they’re CEOs at the highest end of the pay spectrum or the lowest. “The more CEOs are paid, the worse the firm does over the next three years, as far as stock performance and even accounting performance,” says one of the authors of the study, Michael Cooper of the University of Utah’s David Eccles School of Business.

The conventional wisdom among executive pay consultants, boards of directors and investors is that CEOs make the best decisions for their companies when they have the most skin in the game. That’s why big chunks of the compensation packages for the highest-paid CEOs come in the form of stock and stock options. Case in point: The world’s top-earning CEO, Oracle billionaire Larry Ellison, took in $77 million worth of stock-based compensation last year, according to The New York Times, after refusing his performance bonus and accepting only $1 in salary (he made a stunning total of $96 million in 2012). But does all that stock motivate Ellison to make the best calls for his company?

The empirical evidence before fell on both sides of that question, but those studies used small sample sizes. Now Cooper and two professors, one at Purdue and the other at the University of Cambridge, have studied a large data set of the 1,500 companies with the biggest market caps, supplied by a firm called Execucomp. They also looked at pay and company performance in three-year periods over a relatively long time span, from 1994-2013, and compared what are known as firms’ “abnormal” performance, meaning a company’s revenues and profits as compared with like companies in their fields. They were startled to find that the more CEOs got paid, the worse their companies did.

Another counter-intuitive conclusion: The negative effect was most pronounced in the 150 firms with the highest-paid CEOs. The finding is especially surprising given the widespread notion that it’s worth it to pay a premium to superstar CEOs like Jamie Dimon of JPMorgan Chase (who earned $20 million in 2013) or Lloyd Blankfein ($28 million) of Goldman Sachs. (The study doesn’t reveal individual results for them.) Though Cooper concedes that there could be exceptions at specific companies (the study didn’t measure individual firms), the study shows that as a group, the companies run by the CEOS who were paid at the top 10% of the scale, had the worst performance. How much worse? The firms returned 10% less to their shareholders than did their industry peers. The study also clearly shows that at the high end, the more CEOs were paid, the worse their companies did; it looked at the very top, the 5% of CEOs who were the highest paid, and found that their companies did 15% worse, on average, than their peers.

How could this be? In a word, overconfidence. CEOs who get paid huge amounts tend to think less critically about their decisions. “They ignore dis-confirming information and just think that they’re right,” says Cooper. That tends to result in over-investing—investing too much and investing in bad projects that don’t yield positive returns for investors.” The researchers found that 13% of the 150 CEOs at the bottom of the list had done mergers over the past year and the average return from the mergers was negative .51%. Among the top-paid CEOs, 19% did mergers and those deals resulted in a negative performance of 1.38% over the following three years. “The returns are almost three times lower for the high-paying firms than the low-paying firms,” says Cooper. “This wasteful spending destroys shareholder value.”

The paper also found that the longer CEOs were at the helm, the more pronounced was their firms’ poor performance. Cooper says this is because those CEOs are able to appoint more allies to their boards, and those board members are likely to go along with the bosses’ bad decisions. “For the high-pay CEOs, with high overconfidence and high tenure, the effects are just crazy,” he says. They return 22% worse in shareholder value over three years as compared to their peers.

Yet another surprising finding: The high-paid CEOs did poorly for themselves when it came to cashing in their options. Among the bottom-paying firms, 33% of the CEOs held onto their options when they could have cashed them in for a  profit, which the paper calls “unexercised in-the-money options,” while more than twice as many high-paid CEOs, 88%, held onto their options when they could have made money selling.

What can be done about all those negative numbers? The paper doesn’t venture to say but Cooper notes that some finance experts have suggested so-called claw-back provisions. In a CEO pay contract, there would be an item that says, if the firm does poorly compared to its peers, the CEO loses a share of his compensation. “That proposal hasn’t gone over real well,” says Cooper. “There is another school of thought, that CEOs are just too highly paid, period,” he adds. “The U.S. is pretty egregious as far as the ratio between median pay and what the CEO makes.”

Though four years ago the Dodd-Frank law instituted a requirement that firms divulge the ratio between CEOs and median pay, the SEC has yet to issue a final rule ordering it, and companies have been less than forthcoming. But Bloombergcompiled data last year showing that the average multiple of CEO compensation to that of rank-and-file workers was 204, up 20% since 2009. At General Electric, with its star CEO Jeffrey Immelt ($28.2 million in 2013), the ratio was 491, according to Bloomberg.

The Occupy movement, labor unions and some members of Congress have pushed companies to divulge more information about pay ratios, and complained about excess CEO pay, while boards have pushed so-called say-on-pay provisions that would allow them to vote on executive compensation packages. Now those groups have some new empirical evidence to support their positions.

For the last year, the Monterail team has been using AngularJs and Rails together. I’d like to share with you some of the experiences that we’ve gained throughout this process.

If you don’t want to read, then go ahead and dive into our sample application.

Zuza the pug on AngularJS

We are using rails-assets

# Gemfile source 'https://rubygems.org' source 'https://rails-assets.org' # etc .. # assets gem 'rails-assets-lodash' gem 'rails-assets-angular', '~> 1.2.0' gem 'rails-assets-angular-cache' gem 'rails-assets-angular-ui-router', '~> 0.2.9' gem 'rails-assets-angular-translate'

We are passing configuration by JsEnv module and Angular constant

# lib/template_paths.rb module TemplatesPaths extend self def templates Hash[ Rails.application.assets.each_logical_path. select { |file| file.end_with?('swf', 'html', 'json') }. map { |file| [file, ActionController::Base.helpers.asset_path(file)] } ] end end # app/controllers/concerns/js_env.rb require 'templates_paths' module JsEnv extend ActiveSupport::Concern include TemplatesPaths included do helper_method :js_env end def js_env data = { env: Rails.env, templates: templates } <<-EOS.html_safe <script type="text/javascript"> shared = angular.module('SampleApp') shared.constant('Rails', #{data.to_json}) </script> EOS end end # app/controllers/application_controller.rb class ApplicationController < ActionController::Base protect_from_forgery with: :exception include JsEnv end

// app/views/layouts/application.html.slim body h1 Sample App Main Page = yield = javascript_include_tag 'application' = js_env

# app/assets/javascripts/controllers/pages_ctrl.coffee angular.module('SampleApp').controller 'PagesCtrl', ($scope, Rails) -> $scope.test = Rails.env

Yes, we use coffeescript and we use ng-min as well.

We take advantage of sprockets and AngularJs interceptors

# config/initializers/sprockets.rb # register .slim for assets pipeline Rails.application.assets.register_mime_type 'text/html', '.html' Rails.application.assets.register_engine '.slim', Slim::Template

We put slim templates under the app/assets/templates directory.

With a JsEnv and small AngularJS interceptor we will always get the right path for our template, even on production after the rake assets:precompile.

# app/assets/javascripts/init.coffee angular.module('SampleApp').config ($provide, $httpProvider, Rails) -> # Assets interceptor $provide.factory 'railsAssetsInterceptor', ($angularCacheFactory) -> request: (config) -> if assetUrl = Rails.templates[config.url] config.url = assetUrl config $httpProvider.interceptors.push('railsAssetsInterceptor')

Throughout the whole Angular application we can use asset paths normally like: /pages/index.html. The railsAssetsInterceptor factory will translate asset paths to their version after compilation. It changes the asset path from/pages/index.html to /assets/pages/index-sha.html.

Yes, this works. Check it out!

We are using angular-translate with custom loader

# app/assets/javascripts/init.coffee angular.module('SampleApp', [ 'pascalprecht.translate' ]) .factory 'railsLocalesLoader', ($http) -> (options) -> $http.get("locales/#{options.key}.json").then (response) -> response.data , (error) -> throw options.key .config ($translateProvider) -> $translateProvider.useLoader('railsLocalesLoader') $translateProvider.preferredLanguage('en')

railsLocalesLoader is a custom factory for loading locales from Rails. We server locales via the assets pipeline in the same manner that we do with templates. It works after the translation has changed in theconfig/locales/[KEY].yml file and works properly after rake assets:precompile. This is possible thanks to JsEnv andrailsAssetsInterceptor.

The Rails part of the code looks like this:

# config/initializers/sprockets.rb # add custom depend_on_config sprockets processor directive class Sprockets::DirectiveProcessor def process_depend_on_config_directive(file) path = File.expand_path(file, Rails.root.join('config')) context.depend_on(path) end end # register .json for assets pipeline Rails.application.assets.register_mime_type 'application/json', '.json' # enable to use sprockets directive processor in .json Rails.application.assets.register_preprocessor 'application/json', Sprockets::DirectiveProcessor

Put locale under the app/assets/locales/locales directory.

// app/assets/locales/locales/en.json.erb //= depend_on_config locales/en.yml <%= Translations.new.for(:en).to_json %>

In the code above we use a custom depend_on_config directive which relays on sprockets depend_on directive. Thanks to depend_on_config directive, we can expire an asset’s cache in response to a change in yaml file.

Translations service in ruby prepares flatten hash from your locale yaml file. You can find an example implementation here.

We are using client side cache

Before, I explained some of the magic behind how sprockets and AngularJS work together, thanks to server side cache solutions. Now we can just as easily cache templates on the client side to get an even greater boost.

# app/assets/javascripts/init.coffee angular.module('SampleApp', [ 'jmdobry.angular-cache', ]) .config ($provide, Rails) -> # Template cache if Rails.env != 'development' $provide.service '$templateCache', ['$angularCacheFactory', ($angularCacheFactory) -> $angularCacheFactory('templateCache', { maxAge: 3600000 * 24 * 7, storageMode: 'localStorage', recycleFreq: 60000 }) ]

Import Web Data into Google Docs

This video tutorial explains how you can import web data – like HTML tables and lists – from external web pages into your Google Docs sheets with a simple formula.

couch modeprint story

Build a Web Page Monitor with Google Docs using ImportXML

Find Your Most Popular Web Pages on Twitter with Google Docs

How to Insert Images in Google Spreadsheets

Google Tables for Viewing Large Excel Spreadsheets on the Web

Better Ways to Embed Tables and Spreadsheets in Web Pages

You have been using Google Docs to create basic documents and spreadsheets but did you know that Google’s cloud-based Office suite can do even more.

For instance, you can directly import data from web pages and edit it inside Google Docs. You can translate the text of a cell from one language to another. You can read RSS feeds inside Google Docs. You can even use Google Docs for monitoring web page changes - this is handy for tracking price fluctuations for a product on any shopping website.

You don’t have to be a geek nor do you have to write any scripts to do such amazing stuff inside Google Docs. All you need to know is a couple of Google functions - ImportFeed, ImportHTML and ImportXML – and you’ll have a head start. Ready?

Import Web Data into Google Docs

Today we’ll discuss ImportHTML, a useful Google formula that will help you fetch tables and lists from an external web pages into a Google Sheet.

Let’s start with an example. Open a new spreadsheet inside Google Docs, double-click any cell to enter the Edit mode and copy-paste the following function:

=ImportHTML("http://en.wikipedia.org/wiki/List_of_Bollywood_films_of_2012", "table", 2)

When you press Return, Google Docs will instantly import the second table from the corresponding Wikipedia page into your current sheet. If you replace the value of the third parameter in the above formula from 2 to, say, 4, Google Docs will import the forth table from the Wikipedia page.

In addition to <tables>, you can also import HTML lists into Google Sheets that are created using the <ol> or <ul> tags. Try the next function on your Google Sheet:

=ImportHTML("http://www.labnol.org/internet/tips-for-tech-startups/19483/", "list", 2)

The 25 start-up tips are listed using an Ordered HTML List and you can import the entire list into your Google Sheet with one formula. If there are multiple lists on a page, you can change the third parameter with the index of the list that you wish to fetch inside Google Docs.

10 Secrets You Should Have Learned with Your Software Engineering Degree – But Probably Didn’t

By Andy Lester Posted in Nerd Culture, Tech Topics 3 June 2014

It’s an all too common story: You go to school for years and years and walk out with a freshly printed diploma, snag your first job, and yet get immediately blindsided by unwritten rules and other day-to-day complexities that no one bothered to warn you about. And programming is no exception.

Few students are 100% prepared for their first real job. And a computer science degree is lot more than a vocational degree solely designed to prepare students for a job writing banking apps. But I’m still continually surprised to see how many recent graduates—and even some experienced programmers—who still edit their code in Notepad or Pico and don’t know how to use version control.

If you don’t want to be “that person” – or don’t want to be that person anymore — take the time to learn these 10 basic skills and you won’t need hand-holding to get the real work done:

1. Version control systems

It’s perhaps the biggest omission in computer science curricula. Institutions of higher education teach how to create source code for programs, but usually ignore everything about the management of that code. Every programmer should know how to create repositories, edit and commit code, and branch and merge effectively as part of a project workflow using Git or Subversion. Knowing about version control systems also means that you’ll know better than to work for any organization that doesn’t use one.

2. How to write

Working as a programmer is more than just writing in a programming language. You also have to write release notes for your projects. You write commit messages for version control. You write tickets for bugs in the system. All of these and many more require clear, effective English communication – a skill that computer science programs seldom emphasize.

3. Regular expressions

Regexes are a language all their own, and every modern programmer needs to be adept in their use. Every programming language supports regexes or has standard libraries to work with them. If part of your code assignment is to validate that a part number is five letters, a dash and a digit, you should be immediately able to express that as /^[A-Z]{5}-\d$/.

4. Using libraries

It’s 2014, and nobody needs to use a regular expression to extract the hostname from a URL. Every modern programming language includes a standard library of common functionality, or has standard libraries easily available.

Programmers need to understand that code that has already been written, tested, and debugged is going to be better quality than new code that she has to create. Even more important, code that doesn’t have to be written can be implemented much faster.

5. SQL

As someone said to me at a meetup recently, “All the SQL I know I learned on the job. Why are databases an elective? What doesn’t use a database?”

The era of storing data in flat files is over. Everything goes into and out of a database, and SQL is the language that’s used to retrieve it. SQL is also a declarative language, not a procedural language, and so requires learning a new way of thinking about problem solving. But every programmer should understand the basics of database normalization and be able to do SELECTs (including basic INNER and OUTER JOINs), INSERTs, UPDATEs and DELETEs.

6. Tool usage: IDEs, editors, CLI tools

A carpenter would never complete an apprenticeship knowing how to use a only hacksaw, so it’s astonishing that schools can turn out CS graduates who know only Notepad or pico. It’s the job of programming tools to help manipulate the source code and all other data in the computer to make the programmer’s life easier. The Unix command line, shell scripting, find, grep, and sed should be part of every programmer’s knowledge set.

7. Debugging

Every programmer should be able to debug with an interactive debugger or by sprinkling print statements liberally throughout the code. The ability to track down a problem through stepwise refinement is too important to be left for programmers to learn by the seat of their pants.

8. Defensive programming

Even rockstar programmers are fallible, much of the world is out of our control, and things will go wrong. Defensive programming is about understanding that simple truth. If things didn’t go wrong, we wouldn’t have to check file opens for success, or assert that customer IDs are valid integers, or to test our code to make sure that it works properly.

Programmers need to grasp that compiler warnings are helpful tools that make life easier, not nuisances to be avoided. Every programmer should know why each PHP program should start with error_reporting(E_ALL), or each Perl program with use strict; use warnings;.

9. Teamwork

Very few programming jobs allow you to work entirely on your own–and those that do are often intellectually crippling and leave you a worse programmer than when you started. Your code must interact with code written by others, or often be intermingled with code from others. No matter how talented, a programmer who can’t collaborate on projects with others has negative productivity, an quickly becomes a liability to the organization.

10. Working on existing code

In school, every class assignment is a new, greenfield project. That’s not how it works in the real world. The first thing that happens to new hires is they get assigned to fix ticket #8347 in the bug tracking system. After that, they have to add a small new complementary feature to an existing system with an established codebase. Designing new code comes months later, if they’re lucky.