Hack hack hack...

An open journal-- some of it written for you, but most of it is for me.

Tcp, Udp, Http

I really had no idea between TCP and UDP.

This did a nice comparsion: Transmission Control Protocol ensures a reliable and ordered delivery of a stream of bytes from user to server or vice versa. User Datagram Protocol is not dedicated to end to end connections and communication does not check readiness of receiver.

  • HTTP uses TCP connection. But HTTP uses only one TCP connection.
  • Use persistent plain TCP sockets if both client and server independently send packets but an occasional delay is OK (e.g. Online Poker, many MMOs).
  • Use UDP if both client and server may independently send packets and occasional lag is not OK (e.g. Most multiplayer action games, some MMOs).

And there is always this

Moneyball on the Keyboard: Scouting Talented Developers

The central premise of Moneyball is that the collected wisdom of baseball insiders is subjective and flawed. Like baseball, the tech industry has a poor history of evaluating talent by favoring biased perspectives over objective analysis. As a baseball scout turned web developer and team lead, I explore how the lessons I learned in my former career can enable us all to make better decisions on how to grow our teams and surface undervalued skills.

I could have done better with some of the Q&A – repeating the question for one would have helped with the recording. I was a little suprised at the volume of questions about bootcamps rather than the core of the talk, but it’s what some folks latched onto.


How the Web Works

learn co

-> get IP address for server -> assemble http request, sends an ack -> open a tcp connection on 80 (or 443 for SSL) -> tcp port established between user and host (over 1024) -> ssl negotiation, user provides public key and the host provides its public key we validate based on a cert provider and then we are provided a symetric key that we use with that site going forward -> nat - network address translation -> GET HTTP request

On the server ->

  • HA proxy (ssl negotiation, load balancing) (we could replace this with nginx)
  • apache (speaks http, this is the web server)
  • phusion passenger (the workers that enable concurrancy)
  • hit the routes file


  • ubuntu 14.04 (LTS)
  • HA proxyd (port 443 -d SSL only)
  • sshd (port 22) -> run commands remotely (ssl encrypted)


  • apache, spawns passenger pushion
  • passenger spawns 5 wokers
    • takes the request and turns it into a rack ruby object

NFS - Network file system

Innovator’s Dilemma

Sustaining v Disruptive Technologies

  • sustaining tech are improvements that sustain a company’s focus, goals, and customers.

Distruptive Products

  • Generally these products underperform establish products in mainstream markets.
  • Cheaper, simpler, smaller, more convenient. (Dimensions: functionality, reliability, convenience, price)
    • The attributes that often make the distruptive technology worthless in mainstream markets often become strong selling points in emerging markets.
  • Do not improve the focus of the company. A market must be developed and new customers found.
    • Ignore the mainstream market. Find a market that values the disadvantages of the distruptive technology.
  • Neither the firm nor the customers know of distruptive tech can be used.
  • managers need to plan to learn and discover, not plan and execute bc markets are unknowable.
  • cannot rely on new breakthrough technology, it is usually combining existing tech in a new way.

Allocating Resources

  • Being a follower in sustaining technologies is a viable and possibly desirable strategy, but leadership in disruptive technology creates enormous value. (Ch 6)

  • Match the size of the organization to the size of the market. Implant projects aimed at commercializing disruptive innovations small enough to get excited about small market opportunities. (Ch 6)

    • Johnson and Johnson is comprises of 160 automonous companies each of which can introduce distuptive products.
  • small markets don’t solve growth needs of big companies. For disruptive technologies, markets are unknowable.

  • look at the performance improvement of new technology. If it is growing faster than market performance demand, then it can be distruptive (it will eventually intersect the market need curve). (Ch 10)


  • Managing innovation is a mirror image of managing the resource allocation process.

Stemming and Faceted Search

Faceted Search

Search of specific facets like a brand or size for a show search. These are limited set of values, not like a username or ID which could be anything. It’s like a taxomony search.



Reduces the word to its root. So ‘fishes’ and ‘fishing’ to ‘fish.’

This algorithm really hasn’t been around that long. First proposed in ‘68 it gained popularity in the 80s.


Warren Buffet Bio

  • The cornerstone of Buffet’s investment philiosphy: Never count on making a good sale. Have a purchase price be so attractive that a mediocre sale gives good results.

  • Book value is equal to that capital that have gone into a business, plus whatever profits been retained. An investoris concerned with how much can be taken out in the future; that is what determines the company’s worth or intrinsic value as Buffet would call it. Book value is blind to intangibles like brand and so there are opportunities to take aadvantage of the gap between the discepency of the book value and the instrinsic value.

  • Also read Benjamin Graham, Charlie Munger, & Philip Fisher.

What Working in Professional Baseball Taught Me About Web Development

Before I was a web developer, I spent my time on baseball fields helping teenagers realize their ultimate dream of playing in the Major Leagues. All of them had talent. Somewhere, someone had seen glimpses of it. Cultivating that talent and turning their potential into performance was the primary purpose of my job. In the vast majority of cases we failed. Now, a few years removed from the game, most of the players I worked with are out of professional baseball. Those who did succeed, found a way to endure the grind and adjusted to the game’s mental and emotional demands.

In 2012, I hit the reset button on my career and became a web developer. I thought I would be leaving baseball forever. However, I found that many of the same traits I saw in successful ball players, even those with very little formal schooling, were some of the very same characteristics I observed in talented engineers. The inability to manage failure, maintain consistency, and learn how to be a professional shattered the dreams of the vast majority players I worked with because they were skills that were so difficult to master.

When I see one of them on TV, it’s hard to not recall the younger, yet unmolded version. It is why I was never the best scout. The baseball scout’s job is to imagine the possibilities. They envision a future version of a gangly youth whose body and mind has matured and whose flaws have been smoothed away to the point they can perform in the Major Leagues. It is a hard job and one that I wish existed in other industries.

Facing failure

Successful people, in any field, often struggle with making mistakes. This isn’t surprising, we are wired for bad news. We internalize it. We personalize it. Repeated failure is exhausting. Ball players, whose hitting success rate is at best around 30% are forced to cope. Failure is inherently part of the game.

Resilient players’ confidences seem immune to repeated failure. In fact, failure appears to be inextricably linked to their progress. This makes sense. We improve fastest based on negative feedback. The great thing about that big red error message is that it leaves an obvious clue. Sometimes these hints are more obscure than others, but bugs and errors inform us where to look and where to improve.

Getting repeatedly beaten by the same pitch provides feedback on where hitters need to improve in the same way that a familiar error in our terminal window instructs us where in the code to start looking for our mistake. As humans we learn through repetition and experience. The goal is to not getting beaten again by the same pitch or the same problem.

When I first started learning to program, I focused on never repeating the same mistake twice. This, of course, is impossible but I recorded most my thoughts and posted it online so that I had a searchable collection of my mistakes. The frequency of my posts have waned, but I still find myself searching my blog archives when I know I’ve solved a similar problem in the past. While it was rare to see ball players jot down notes on opponents, most hitting savants have the ability recall previous pitch sequences from past at-bats. Either way, the secret to coping with failure is to reframe it as valuable feedback to be used in the future.


As developers, we know that consistent performance is important. We construct our dependencies on the most stable parts of our applications. The same goes for managers: when Sarah demonstrates she can be depended on to meet deadlines on a day-to-day, week-to-week, sprint-to-sprint or quarter-to-quarter basis, Sarah can be relied on to build the feature to satisfy the high priority business objective.

Consistency creates the opportunity for measurement. Like the measurement of feature velocity based on a set period of time, comparison of player’s abilities would be worthless without a standard 162 game schedule where the participants play nine innings with nine players on the field. Without a level playing field, comparisons are no longer valid and people can get really upset (see baseball and steroids).

Consistency is difficult because we are wired to break free from it. We are not as perfectly repeatable as the scripts we write. Our brains thrive on novelty. The day-to-day becomes mundane without it. We seek out adventure and variety. We create drama where there is none. We endeavor to learn new things.

But mostly being consistent is just showing up. Being there when products ship and stuff goes down. Career defining highlights are created when people are in the right place at the right time. Crashes on the production server and DEFCON 1 bugs are inevitable but these panic moments create opportunities. Under pressure, acting as you always do makes you a hero.

Derek Jeter’s lifetime batting average was .310. A consummate professional, he hit .308 in the playoffs. Just being yourself when the pressure is on and more eyes are on you makes it seem like you are rising to the occasion. No one is perfect, but bringing your best everyday provides predictability to our human unpredictability and separates the amateurs from the pros.


Professional baseball is a child’s game played by overgrown men who make millions of dollars. Make no mistake about it, baseball is a grueling sport. The schedule is relentless. Players arrive at the stadium five-plus hours before the first pitch to weight train, stretch, hit, throw, review scouting reports, etc.

After a three hour game, players are expected to hold court in front of their lockers and answer questions that essentially boil down to, “Tell us about your glaring mistake that you made in front of thousands of people across America.” Each major league team plays 162 games in about 180 days – not to mention the the month of spring training before the season starts and, if they are lucky, a month of postseason games. Eighty-one of these games in other cities meaning players are switching time zones for weeks on end. The truly blessed ones do this for 20+ years. What the casual fan sees of a player on any given night is the result of thousands of hours of refining subtle movements through exhaustive repetition.

And while we developers don’t enjoy the fame and fortune of Major Leaguers, we get to solve the worlds’ hardest puzzles. The impact of our code has touched the lives of nearly every human on the planet. The drudgery of implementing the vision of others is offset by the natural builder’s high.

Hacker News is littered with discussion on how writing software can crush your soul, but for the lucky ones, the “job” retains its joy. Despite the jeering fans and elusive bugs, there are a blessed few who simply love what they do.

The Same But Different

Of course, there are stark differences between baseball and software engineering. Software has been in the hands of laymen for less than a generation and baseball has remained unchanged since before the Civil War. While software’s impact continues to accelerate, we should pause to take breathers and remember that what is old becomes new again. There are lessons to learn everywhere we look and baseball has proven no different for me.

I love what I do. I’ve never been as challenged as when I’m muddling to make sense of a new concept or totally lost in a self-created code mess. The wins and losses I’ve experienced as a developer are like nothing else I’ve experienced as an athlete or a coach. While I’m still a relatively new programmer, my experiences in baseball have transferred as valuable lessons on coping with failures, reliability, and professionalism.

Not all that long ago my work day consisted of spotting the subtle deficiencies in a pitcher’s delivery and the sound of a shortstop’s feet as he ran a 60 yard dash, but when I watch how a junior dev deftly uses her VIM shortcuts or the ease of which she writes a complex SQL query, I’m reminded it’s not so different after all.