CLI Efficiency: Common Basics

I like the command line. I like the keyboard.  For me it’s all about the efficiency: if done right, it’s just faster & easier to use the keyboard to tell the computer what to do than it is to use the mouse to show it. (Yes, there are exceptions – it’s usually easier to do graphics work with a mouse, for example.)

The first time I ever got really excited on a computer was when someone started showing me all of the keyboard shortcuts available at the time. I immediately found myself substantially more productive, and that productivity just fueled a desire to learn even more shortcuts, more tips and tricks, and to find the most efficient way to do whatever it is I needed to do on the computer.

While there are many different keyboard shortcuts available, depending on the application or the shell, there are also many similar ones. Even an unintuitive interface or standard is useful when it is common: learn once and use (almost) everywhere. One of those standards is the line-editing functionality most often implemented using the GNU Readline library or one of its functional (but differently licensed) equivalents like Haskeline, Editline, vrl, or others. In a nutshell: these libraries provide a common user interface for interacting with a command line and editing its contents using special keystrokes or key combinations. In what may be no surprise to those familiar with GNU, these key combinations are very reminiscent of Emacs and tend to utilize the Control key extensively.

Readline actually dates back to 1987 and either it or one of its equivalents has been available for most of the vast number of command line shells ever since. This is true for both general purpose operating systems like Linux and Mac OS X (both of which include the Bash shell which uses Readline), or for purpose-specific or embedded operating systems like VMware’s ESXi (with its Busybox shell), Cisco’s NX-OS, NetApp’s Data ONTAP, or many others. Once you become familiar with the basics of these keystrokes, you’ll be able to be more efficient in virtually any CLI environment (with the notable exception of Windows, although there is a project even for that – WinEditLine).

Note: the list below is not all-encompassing, but includes the key combinations that appear to be supported consistently across platforms. There are other key combinations that work on one or more platforms but not on others; a future post will provide more detailed comparisons for these other key combinations.

Movement:

Keystroke Action
Ctrl+a Move to the beginning of the line
Ctrl+e Move to the end of the line
Ctrl+b Move to the left (back) one character
Ctrl+f Move to the right (forward) one character
Esc-b Move to the left (back) one word
Esc-f Move to the right (forward) one word
Ctrl+p Display previous command (in history buffer)
Ctrl+n Display next command (in history buffer)

Editing:

Keystroke Action
Ctrl+d Delete the character under the cursor
Ctrl+w Delete the word to the left of the cursor
Ctrl+k Delete all characters from the cursor to the end of the line
Ctrl+u Delete all characters from the cursor to the beginning of the line

Always Be Learning

In today’s always-on, always on-line world, it should be no surprise that the amount of information available to further your self-education is virtually limitless. Combine this with the ever-more-rapidly changing technologies in the market, and it’s easy to be in a state of constant learning & intellectual stimulation.

Despite this, I’ve often found technical people – IT people – who fail to take advantage of what’s out there, and are sometimes even dismissive of growing their skills. I’ve encountered this most often in shops where the IT team are being provided little paid training by the company, and so some team members develop an attitude of “I’m not going to learn <insert new skill/tech> just because the company needs me to; if it’s important to the company, then the company should pay for real training.” While it’s certainly true that a company should be providing the resources necessary to run their business – including personnel training for the technologies on which the business relies – this perspective only helps further negativity in the workplace and harms not just the business and the IT team, but also the individuals themselves. Yes, investing in your skillset will benefit your company, but the education, the skills, and the experience you gain in learning new things are fundamentally yours, and benefit you most of all. Refusing to take the initiative to learn on your own is a quintessential case of “cutting off your nose to spite your face.”

Yes, training often costs real money, but not always. There’s an immense amount of training available completely free of charge. Phil Wiffen (Twitter: @phil_wiffen) has helpfully put together a nice list of free IT training on his blog, and a lot of it is even official, straight-from-the-vendor training: http://www.twistedethics.com/2014/07/13/completely-free-it-training-resources-to-help-diversify-your-it-career/

There’s also an immense amount of reasonably-priced (some might even say unreasonably cheap) tech resources and/or reference material out there. The ones below only begin to scratch the surface:

  • PluralSight: The premier on-line purveyor of IT/tech video training, particularly following their acquisition and integration of TrainSignal. PluralSight stand out for two reasons: their all-you-can-eat-buffet approach to training (low monthly or annual charges for as much training as you can absorb, starting at $29/month or $299/year) and because of the quality of their authors/instructors.  They have a strong contingent of people who really walk-the-walk and have already been recognized for their skills by acquiring VCDX, CCIE, and other high-level certifications or technical recognition. Just to point out a few:
  • Safari Books Online: One of the oldest on-line resources, and brought to you by the fine folks from O’Reilly Media, they have a number of plans (starting as low as $24/month or $249/year) providing access to a wide library of technical publications (from O’Reilly, No Starch Press, Microsoft Press, Cisco Press, and many others), but also video training, audio books, conference talks and more.
  • PacktPub:  “Only” a publisher of books and ebooks, PacktPub is distinguished for the variety of their pricing models, their frequent discounting/sales on their ebooks (often 50% off or flat-pricing at $10 a title), and the variety and quality of some of their authors. They also offer a subscription option which provides online access to all of their titles, as well as a free ebook download per month, for $22/month or $220/year. Some of their titles worth checking out:
  • LeanPub: This is a new one for me, having really looked at them only this week, thanks to my finally getting around to buying one of Greg Ferro’s (@etherealmind) ebooks from their site. Apart from his work, they have a variety of other titles that are mostly reasonably priced with a pay-what-you-like model – including some that are completely free.
  • Books/eBooks by Michael W. Lucas: I first discovered Lucas’ work through a series of on-line articles focused on Unix/BSD back around the turn of the century (accurate, despite how strange it feels applying that phrase to such recent times), and he quickly became one of my favorite tech writers. Since then, he’s published a number of wonderfully written, and highly informative, books through the great independent No Starch Press including Absolute FreeBSD, Absolute OpenBSD, Cisco Routers for the Desperate, and Network Flow Analysis.  More recently he’s been releasing smaller, more tightly focused books via self-publishing that are short, sharp, and cheap ($8.99-$9.99):

There’s more than enough high-quality resources out there to keep you in a constant state of learning for the remainder of your career. As Bob Dylan  said, “He not busy being born is busy dying.” If you’re not learning and improving yourself constantly, you’re just stagnating – and no one really wants that. Do it for yourself – get busy being born.

VCDX Boot Camp at VMworld 2014

On Saturday, I was one of the lucky 40 or so attendees of the latest VCDX boot camp organized by John Arrasjid (VCDX #1 – @vcdx001) and graciously hosted at the local EMC office in San Francisco. I had been able to attend a previous boot camp at PEX 2013 which had been a great learning opportunity, but I must say that this one was even better: the more casual atmosphere greatly contributed to better and more organic discussions, and a more interactive experience overall.

John led the boot camp, and was joined by a number of other VCDXs: Mostafa Khalil (VCDX #2 – @MostafaVMW), Matt Vandenbeld (VCDX #107 – @vcloudmatt), Chris McCain (VCDX #79 – @hcmccain), Nathan Raper (VCDX #85 – @nateraper), and Ben Lin (VCDX #45 – @blin23). All were kind enough to spend their Saturday afternoon helping our group of wannabes better understand how to be successful in our VCDX application and defense.

While we did not have enough time to formally introduce ourselves, there were a number of people I know pretty well from Twitter  – and in at least one case, the real world – who attended and helped make the discussions as productive as they were. Just a few of the attendees: Bob Elwertowski (@BElwertowski), Dan C. Barber (@dancbarber), Kyle Ruddy (@RuddyVCP), Byron Schaller (@ByronSchaller),  Adam Eckerle (@eck79), and @aus_effendi.

We went through the VCDX boot camp presentation (available here) in great detail, answering questions from the attendees as we went along. This covered the overall VCDX program and related VMware certifications tracks, along with the actual design submission and defense, the separate design scenario, and the troubleshooting scenario. Chris McCain talked about the VCDX-NV – how it’s both similar to and different from the other tracks (datacenter virtualization, desktop, and cloud). For example – a valid NV design may not include ESXi or vCenter at all, as NSX can be used with other hypervisors and cloud management platforms (like OpenStack).

Throughout, each of the VCDXs in attendance provided personal insights, recommendations, and reminders. Some of the ones that stuck out most for me:

Design Submission

  • On required design complexity for a successful submission: can you talk for 75 minutes about this design?  While there are no hard & fast rules on environment sizes, feature sets, or complexity, there does need to be enough aspects of the design to  cover all of the blueprint areas thoroughly enough to discuss the project at length.
  • A design must be able to be implemented to be successful. While this seems obvious and intuitive, not all submissions can pass this test. Especially if you are using a fictitious or semi-fictitious design, make sure that it will really work – lab out as much of it as you can.
  • You have to understand and be able to explain everything in the design, even if you weren’t the original architect. There are no acceptable excuses of “that was someone else’s area.”
  • You don’t necessarily need to be able to personally implement each portion of the design. For example, you don’t need to be able to perform the storage administration tasks step by step, but you do need to be able to tell the storage admin what configuration needs to be made, and articulate how the configuration (and *other* possible configurations) will impact the design.
  • A pretty cool feature is not a business requirement. The goal of the design is always to address the business needs, not the “ooh, shiny!” needs of the architect.
  • Designs are confidential, and individual copies are destroyed after the defense itself. VMware does keep a copy of the design at HQ after the defense, but only for a limited period of time (for legal reasons).
  • You can (and often should) redact any confidential information from your designs: business names, contact names and information, IP addresses (potentially), etc.
  • The largest submission was approximately 1,200 pages, with most being several hundred pages. Don’t be that guy (at either extreme) – be thorough but reasonable.
  • If submitting an existing, or real-world design, you may only need an additional 40 hours or so of work on the application for it to be complete in addressing the submission documentation  guidelines. For fictional, semi-fictional, or designs without sufficient existing documentation, applicants can spend 300 or more hours on their submission.
  • Joint submissions can be successful and co-applicants provide each other built-in sounding boards & reviewers throughout the process. Each individual submission must indicate the other authors and architects who contributed to the complete design. One co-applicant’s successful defense of a joint design doesn’t guarantee success for all co-applicants as a lot still depends on the individual’s performance during their defense.

Design Presentation and Defense

  • Keep your presentation short, but provide yourself plenty of backup material. You should be able to go through your presentation in about 15 minutes, but you can help yourself out significantly by including as much reference material as possible. When Chris McCain defended, his presentation was around 17 slides but had 70 slides of supporting information.
  • Keep your presentation as visual as possible – diagrams, diagrams, diagrams, and tables.
  • Use hot linking as much possible. You can save yourself a lot of time not skipping back & forth between slides if you have quick links on each slide to the table of contents and possibly directly to specific reference slides.
  • Don’t introduce new material in your design presentation – it should all be taken from your submitted application. You can correct mistakes you may have discovered after submission, but the design itself should not change.
  • You must know your design in and out, but you must also understand the reasons for each design decision, and the implications of changing those decisions. Your design may be all NFS, but you must be able to demonstrate your knowledge of block storage as well.
  • During your design defense, panelists act as peers rather than as the customer from your submission. In the design scenario they act as the customer (with varying degrees of displayed technical ability).
  • There’s no required dress code, so dress appropriately and comfortably.  You’re going to be on your feet for 2 hours or more during your defense. Don’t wear anything distracting to the panelists, either – and pants are *not* optional.
  • You can’t use your own laptop during your presentation; a Windows laptop will be provided for you. Bring your presentation on a USB key (preferably multiples to safeguard against loss, corrupted files, etc.) in both PowerPoint and PDF formats.

Design and Troubleshooting Scenarios

  • The timer starts when you write on the whiteboard or ask a question that provides additional information.
  • The first thing most successful candidates do is write down the business requirements on the whiteboard.
  • Don’t spend time doing math in your head – if needed, calculators are available.
  • Don’t assume information provided in the scenarios is correct – just as in real world customer interactions, there may be inaccurate information provided.
  • When asking questions, always explain why you’re asking – let the panelists see what you’re thinking and how you’re approaching the problem.
  • Identify and prioritize the business requirements, constraints, and risks in the scenario.
  • Diagram the proposed scenario – don’t just write down words.
  • The panelists are looking at what questions you ask and the methodology you follow – they need to see how you are tackling the problem at hand and not just randomly attacking it.
  • The panelists are also looking for how you change your approach, or the prioritization of the business requirements, constraints, and risks, as you adapt to the information you’re given.
  • Provide “proactive dramatics”. Just as the panelists are playing roles, so too are you playing the role of architect – overplay that role for maximum effect.
  • Continuously validate and adapt to the information you’re provided.
  • For the troubleshooting scenario, your first question should be “Did you open a Support ticket?”

Overall

  • Focus on business requirements first and foremost – not the technologies.
  • Study groups and mock defenses are highly recommended. One key thing noted is that doing these *before* you submit can be critical as it gives you the opportunity to correct mistakes or gaps ahead of time.
  • Mock defenses should include non-technical people as they will often ask more questions than highly technical peers (for whom aspects of the technology or design may seem too obvious to question). This was specifically and strongly recommended by both Chris & Nate.
  • When answering questions, talk out loud. This has been repeated ad nauseam in regards to the defense, but an interesting new point was mentioned: not only does it show the panelists your thought process and allow you to score points, but you may actually answer questions the panelists have in mind but have not yet asked, saving yourself critical time in addition to scoring points.
  • The more questions you can answer, the more opportunities you have to score points. Don’t provide too little information, but if a question can be answered in a sentence, don’t waste your limited time on an extra paragraph.

How to Fail

  • Don’t write things down on the whiteboard
  • Don’t explain your questions or thought process
  • Don’t provide answers to the panelists’ questions
  • Don’t listen to (or use) the answers the panelists give you