StatCounter

Monday, February 27, 2017

Troubleshoot Your Internet Connection


There are several types of internet connections. Briefly they are as follows, in order of increasing speed/bandwidth.

(Bits per second is abbreviated as bps. Kilo, Mega, and Giga represent one thousand, one million, and one billion respectively.)
  • Analog (up to 56 Kbps)
  • Satellite (less than 1 Mbps)
  • DSL (up to 8 Mbps)
  • Cable (up to 20 Mbps)
  • Tier (T1 through T5, with 64 Kbps per channel, cumulatively up to 1 Gbps)
  • Optical (1 Gbps+)
  • Internet2 (100 Gbps)
Most homes use either Cable (e.g. Comcast) or Optical (e.g. Verizon FiOS).


You Know Your Project Is Dysfunctional If...



I discuss below five easy-to-recognize smells that point to some serious dysfunction within your project team. Often the dysfunction can be traced to a specific person who is poisoning the team. Most likely it's a team member who is defensive and doesn't wish to ask for help or be called out when s/he makes a mistake. But it can also be a stakeholder who is too overbearing and/or disengaged. Either way, these smells are merely symptoms (like an incessant cough that finally causes you to seek a doctor's professional opinion). Don't make the mistake of interpreting symptoms as problems. Fixing the symptom without ferreting out and addressing the underlying malady will only make the problem worse. (Analogous to taking cough syrup when what you really need is an x-ray to identify pneumonia.)

So, here's my list of top five smells I use to identify a dysfunctional project.

  1. You can't remember the last time you saw two team members huddled over the same computer screen

    This is the most obvious of the smells. Collaboration is an essential facet of a well-functioning team. While an interactive session might initiate over email or phone, it often concludes with two or more team members sitting at the same desk looking at the same screen (or in the same room using a projected screen). This shared problem-solving and cohabitation is critical in order to align on requirements, solution approaches, and issues. If your project has this odor, ignore the score card below and head for the hills!

  2. Far too much time is being spent checking and discussing the burndown and/or velocity

    Processes and metrics become counterproductive if they take center stage. Delivering functionality is the main objective of your project. If your burndown or velocity (or some other process adherence) is poor, acknowledge it and move on. Occasionally, the team should empower itself to explicitly drop an element of the process if it doesn't seem to work in the context at hand. Being obsessive compulsive about process or metrics is not helpful.

  3. There's hardly any light conversation in the team area

    A team that laughs together stays together. Software development is, above all, a human activity. If human elements start to fade from the work environment, it's unlikely that the team is truly enjoying their time at work. And a team that isn't happy is going to have a really hard time producing enlightened and spectacular results.

  4. More often than not, the team doesn't eat lunch together

    Okay, so perhaps your team isn't endowed with the comedic gift. No big deal. But each and every one of us breaks for lunch during the work day. If the team is working well together and gelling as a team, it should not be a stretch to expect that most team members would eat together on most days. Occasionally, the team might leave the building and go out for lunch. There could be many reasons this isn't happening. Either the team members can't stand each other. Or they're too stressed about project deadlines and deliverables to dream of anything more leisurely than inhaling cafeteria food at their desks. Regardless, it's not healthy for the team or for the project.

  5. The team dreads code reviews

    Code reviews are dreaded for fear that dormant animosities will flare up once again.
Now that you've reviewed the smells described above, here's a score card to figure out where your team stands based on whether your project exudes one or more of these odors.

  • 0-1 Smells

    You've got yourself a model project. Relish the experience and, if possible, help others eliminate some of their dysfunction.
  • 2-3 Smells

    Your project is on the verge of collapse. You urgently need to dig deep to find the real dysfunction (a team member or a bad practice) and eliminate it.
  • 4-5 Smells

    You've on a sinking ship. Don't bother trying to plug the hole. Bail immediately and find a better project before your sense of smell is ruined.

Web 2.0


It's disappointing that the O'Reilly book Web 2.0 Architectures: What Entrepreneurs and Information Architects Need to Know (Nickull, Hinchcliffe, Governor) hasn't received more attention and acclaim. It should have. Too many developers today dive headfirst into programming without first appreciating the 10,000 foot view and a sense of how we got here. As the saying goes: if you don't know where you came from, then you don't know where you're going.

For example, how many developers know that Microsoft's introduction of the XMLHTTPRequest (XHR) object to its Internet Explorer browser is what led to the revolution called AJAX (ignited by Google Maps), that underlies Web 2.0? Google has also been behind much of the NoSQL innovations that are now fueling Facebook, Amazon, LinkedIn and other Internet giants. Awareness about how major innovations took place in the past is important because it enables the early identification of opportunities for future innovations.

Dave Winer, who is responsible for many of the technologies that collectively became known as Web 2.0, recently quipped on Twitter: "Web 2.0, whatever that is." He was, of course, conceding that the definition still isn't clear. However, what should be clear to everyone by now is this. Web 2.0 isn't the future, it's the past and the present. It is us looking in the rear view mirror and recognizing that the Internet underwent a sea change with the advent of a number of technologies whose arrival and confluence no one could have predicted.

Call me ignorant, but I learned enough from reading just this book's preface to make it worth my money. As an architect, I am always looking for a succinct overview of the big picture. There's a lot of information out there and few, if any, people can claim to know it all. In fact, Winer's quip was at least partially responsible for me taking the plunge. So, I went looking for a book on Web 2.0 that could paint the landscape rather than get me knee deep into a specific technology (I already have plenty of books that do a good job of that). And although this book has not received the volume of good reviews I would have expected, I could not find a single other book that even comes close to taking on the task, i.e. provide a perspective on what we've learned from the success of Web 2.0 by distilling it into patterns, paradigms, and a forensic (after-the-fact) reference architecture. (Although I will offer a hat tip to Pragmatic Ajax: A Web 2.0 Primer, honestly, with the exception of the MUST-READ chapter 4 on Google Maps, this book jumps right into implementation details and doesn't do half as much justice to the history, patterns, paradigms, and architecture as the book under review.)

A refresher on the history of how the Internet evolved into what we know today as Web 2.0 also drives home the point that there isn't a lot of permanency on the Internet. Many of yesterday's giants (MySpace, Napster, Flickr) have been superseded. We would do well to keep this is mind before buying a ton of shares in Groupon or even Facebook. The book also reminds us that Internet's innovators tend to get gobbled up by established media companies whom the Internet threatens (AOL by Time Warner, Expedia by USA Netwroks, Infoseek by Disney). In this context, also see The Master Switch: The Rise and Fall of Information Empires (Tim Wu).

REST, broadly a minimalist SOA and web services alternative to the additional layers mandated by SOAP. Read this for more on the intricacies behind the debate.

HTTP 1.1 persistent connections and chunked transfer encoding allow content to be streamed rather than buffered.

Raspberry Pi Setup Notes

Figure 1 | Raspberry Pi
Introduction

First, let me clarify that this blog is about the $35 Model B (512 MB RAM, 2 USB ports, and an Ethernet port), not its cheaper cousin, the $25 Model A (256 MB RAM, 1 USB port, no Ethernet port).

To learn more, see the FAQ. The FAQ is short and informative. I recommend reading it even if you don't have questions.

Take 1

My first goal was to get my Raspberry Pi up and running.

The first thing I needed was power. So, I hooked up a cable/adapter combination to connect the USB A port on my laptop (5 V, 500-900 mA) to the USB Micro B port on my Raspberry Pi. Doing so caused the red LED on my Pi to turn on (see figure 1). So, I figured I had a good power source established. (As it turns out, learning about USB standards is one of the many educational side-effects of trying to setup a Pi device of your own. There are some finer points about whether the power source is providing the Pi with sufficient power, relative to the required 3.3 volts. However, I won't get into that just now.)

My next step was to provide my Pi with something beyond the firmware that it shipped with. I needed to get some software to comprise an operating system (OS). Thankfully, the Pi box points you in the right direction on where to download the OS. As most folks seem to recommend, I downloaded the version of Linux that is called Raspbian "wheezy". (There are some finer points here as well, such as the right way to get the image file onto the SD card that serves as the Pi's primary data source. Again, I won't get into those details here and now.)

If you power your Pi after inserting a correctly imaged SD card, you should not only see the solid red "power" LED but also the flickering of the green "activity" LED as the Pi goes through its boot up process. But without a display you're not going to find out any more than that.

So, it seemed that the SD card was valid, but I still couldn't confirm what was going on as far as the boot process. The quickest way for me to get a display going was to run one of those yellow RCA/composite video cables from the Pi's RCA/composite output to my TV's RCA/composite input. (Everyone either has a RCA/composite cable lying around or can easily pick one up from RadioShack or online.) Once I connected both ends of the RCA/composite video cable and switched my TV to video1 (or video2, depending on which input I had plugged by RCA/composite cable into), I was able to see the familiar Pi configuration menu.

Figure 2 | Raspberry Pi Setup (Take 1)

The setup described above is summarized in figure 2. At this point I figured I had a working Pi and I could start thinking about a more practical setup.

Take 2

In my quest to make my Pi more portable I was helped by several online articles and videos that describe how to hookup a Pi to the now defunct Motorola/AT&T Atrix 4G Laptop Dock. The dock is available for $60 or so online and is a compact way to augment the Pi with audio (the dock has speakers), video, keyboard, mouse (track pad), and power all in one shot. I haven't seen any of the site describe the setup I have documented in figure 3. I will describe in it a bit more detail to try and fill in the blanks and provide additional information.

Figure 3 | Raspberry Pi Setup (Take 2)
As the astute reader will note, the most efficient route is to go directly from the connector type on the Pi to the connector type on the dock. However, you will find that not all imaginable cables, adapters, and dongles (henceforth mostly referred to generically as "connectors") are equally available. Given a random combination from connector type A to connector type B (e.g. HDMI A port/female to Micro HDMI D plug/male shown in figure 3), chances are that such a cable does not exist or isn't readily available. Many that are available are not available in the US and have to be shipped from overseas, mostly from China. I should mention here that someone with adequate knowledge of electronics and access to electronics components (e.g. some adapters may require a resistor to be added to reduce the current) and equipment (soldering iron etc.) can create the desired cable at home. For those who are interested in taking that extra step toward electronics, the best book I've seen on the subject is Make: Electronics by Charles Platt (O'Reilly, 2009).

As you will note by studying the setup described in figure 3, at least one connector in any leg of the setup must be a cable (in order to provide the needed maneuverability). The remaining connectors in a leg can be adapters/dongles. For example, the HDMI leg of the setup has two connectors, i.e. #1 and #2. Only one of them needs to be a cable. The other is free to be a cable or an adapter/dongle. The same goes for the middle leg. However, the last (power) leg has only one connector, i.e. #5. Therefore, #5 must be a cable.

For your convenience, I am listing out the connectors used in figure 3. Again, make sure that at least one connector in each leg is a cable. See figure 4 for a useful diagram of the standard USB types.
  • #1. HDMI A (regular) male/plug to HDMI D (micro) male/plug cable or adapter/dongle.
  • #2. HDMI D (micro) female/receptor/port to HDMI D (micro) female/receptor/port cable or adapter/dongle. Also known as a gender changer (this is the case whenever both ends of a connector have exactly the same connection type).
  • #3. USB A (regular) male/plug to USB A (regular) male/plug cable or adapter/dongle (gender changer). 
  • #4. USB A (regular) female/receptor/port to USB B (micro) female/receptor/port cable or adapter/dongle.
  • #5. USB B (micro) male/plug splitter (a micro female/receptor/port at one end and two micro male/plugs at the other end).
Figure 4 | USB Types
A final point about terminology. As you would have noted in the text above, the male connector is variously also known as a jack or a plug. Similarly, the female receptacle is also known as a socket. As a point of confusion, in the US, a jack can often refer to a female receptacle. Furthermore, in the US, a jack can refer simply to the immobile part of the connection pair that's typically attached to a wall or panel.and a plug can refer to the mobile part of the connector pair that's typically attached to a wire. For more on this interesting topic, see the following article. Due to the above mentioned sources for potential confusion, I recommend always using the terms male connector and female connector so that there is no room for ambiguity or interpretation. This is the approach I have consistently tried to use in this blog post.

Friday, February 3, 2017

HI RES IMAGE XebiaLabs' Periodic Table of DevOps Tools v2

See the original interactive version here

This site seems to compress the image. So, you can view the original I created here.

XebiaLabs' Periodic Table of DevOps Tools v2