Gigi Labs

Please follow Gigi Labs for the latest articles.

Friday, September 27, 2013

C#: Understanding Recursion with Directory Traversal

Greetings, and welcome to this brand new article at Programmer's Ranch! :)

In this article, we're going to talk about recursion. This technique is often considered an alternative to iteration (i.e. loops), and is useful for a wide variety of situations ranging from computing factorials to clearing empty areas in Minesweeper:


Since factorials are boring, and Minesweeper is a bit complex for this easy tutorial, we're going to look at the filesystem in order to learn about recursion. For example, take a look at the folder for the solution I just created in SharpDevelop:


See, the filesystem is actually a tree data structure. Each folder can contain other files and folders, which can in turn contain other files and folders, and so on. It isn't easy to work with things like trees using loops, but with recursion it just comes natural. Let's see how.

After creating a new console application, add the following at the top, which we need to interact with the filesystem:

using System.IO;

The first thing we want to do is get the current directory where the executable will be running. We do this by using Directory.GetCurrentDirectory(). Let's try that out:

            String currentDir = Directory.GetCurrentDirectory();
            Console.WriteLine(currentDir);
            Console.ReadKey(true);

...and here's what we get:


Now, we want to navigate up to the first CsRecursion folder, which is the solution folder. From there we'll be able to list the contents of all the subfolder. To do this, we create an instance of DirectoryInfo:

            DirectoryInfo dir = new DirectoryInfo(currentDir);

This allows us to get to the parent folder:

            dir = dir.Parent.Parent.Parent;

...and this is what we have so far:


Right, now about listing the folder and subfolder contents. Let's add a method to do that:

        public static void ListContents(DirectoryInfo dir)
        {
           
        }

In this method, we first want to list all the files in that folder. We can do this using DirectoryInfo.GetFiles(), or else using the static Directory.GetFiles() method, which is easier and works directly with file paths (Strings):

            foreach (String file in Directory.GetFiles(dir.FullName))
                Console.WriteLine(file);

Okay, now all we need is to do the same thing for all subfolders. It turns out that our ListContents() method can actually call itself, and pass in each subdirectory as a parameter:

            foreach (DirectoryInfo subdir in dir.GetDirectories())
                ListContents(subdir);

When a method calls itself, it's called recursion. In this case we say we are recursing into subdirectories.

Let's just change Main() so that it calls our ListContents() method:

        public static void Main(string[] args)
        {
            String currentDir = Directory.GetCurrentDirectory();
            DirectoryInfo dir = new DirectoryInfo(currentDir);
            dir = dir.Parent.Parent.Parent;
            ListContents(dir);
           
            Console.ReadKey(true);
        }

...and voilĂ :


As you can see, there's a very small amount of code, and recursion is a perfect fit for this kind of thing, because the same method can work on folders at different levels of the filesystem.

There's an important concept about recursion you need to be aware of, that might not be so evident in this example: the stopping condition. If a method calls itself and has no way to stop calling itself, you get a sort of infinite loop which actually ends in a stack overflow (in short, there's a limit to the number of times a method can call another method). Therefore, a recursive function always needs a way to stop calling itself.

If you're doing factorials, recursion stops when n=1. If you're computing a Fibonacci sequence, n=0 and n=1 are the stopping conditions. In our case, recursion stops when a folder has no further subfolders. In Minesweeper, recursion stops when there are no more adjacent blank squares (you either hit an edge or a number).

Anyhow, as we have seen in this article, recursion is a great technique to use when your data has divergent paths (most notably when dealing with trees). There are a few other interesting applications of recursion that I'll probably be writing about in the future, so stay tuned! :)

Wednesday, September 25, 2013

Best Practices: To Always Use Braces for Conditionals and Loops... or not

Hi everyone! :)

While following a number of Pluralsight courses by Jesse Liberty (which I highly recommend), I was reminded of the long-running debate about whether one should always use braces when control flow statements (conditionals and loops) are involved. Jesse Liberty is one of many who suggest always using braces. So let's say we have the following conditional:

            if (x == 0)
                Console.WriteLine("x is zero");
            else if (x < 0)
                Console.WriteLine("x is negative");
            else if (x > 0)
                Console.WriteLine("x is positive");

The proponents of the always-use-braces camp would have us write them like this:

            if (x == 0)
            {
                Console.WriteLine("x is zero");
            }
            else if (x < 0)
            {
                Console.WriteLine("x is negative");
            }
            else if (x > 0)
            {
                Console.WriteLine("x is positive");
            }

In this article, I'm going to discuss the advantages and disadvantages of this approach, as well as my personal opinion based on my experience. I want to say from the beginning that this article is subjective and not completely factual or objective - so take it for what it is. There is no general consensus on this matter precisely because it is a matter of personal taste.

Brace styles


Braces (or curly brackets) are a feature in just about any programming language that uses the C-style syntax, including C, C++, Java, C#, JavaScript, PHP, and many others. They define a scoped block that can be executed as a single statement as part of control flow (conditionals and loops). There are many different styles in which they can be used.

The Java folks seem to like this kind of style:

            if (x == 0) {
                Console.WriteLine("x is zero");
            }

The .NET camp, on the other hand, seems to prefer aligning braces vertically:

            if (x == 0)
            {
                Console.WriteLine("x is zero");
            }

If you have just one statement, you can technically leave out the braces, so you can write your code like this:

            if (x == 0)
                Console.WriteLine("x is zero");

...or like this.

             if (x == 0) Console.WriteLine("x is zero");

Personally, I think the first and last options aren't the best in terms of readability (especially when code becomes complex) so I'll focus on the second and third. I normally use the second option (with braces) when I have multiple statemenents, and the third option (no braces) when I have just one. Many people recommend always using braces, and dismiss the third option as bad practice. Let's take a look at the reasons why.

If you need to add statements, you'll find the braces ready


So let's take the same example as before, where you have this statement:

             if (x == 0)
                Console.WriteLine("x is zero");

If you need to add additional statements to be executed as part of the conditional, the braces will have to be added anyway. Some people recommend always using braces so that you'll find them ready when you need to add additional statements.

In that case, I suppose, we shouldn't use empty element syntax in XML:

<RowDefinition Height="30" />

...and instead always write our tags in full:

<RowDefinition Height="30"></RowDefinition>

...simply because we might need to add something inside the element at some point. I think this is a very weak argument, because it disregards a language feature that may be very convenient, and at the same time bloats code with something that adds no meaning to the code. Take a look at the first two code snippets in this article - the one that uses braces is twice as long (in terms of lines) as the other one. And for what? Because people are too lazy to type in the braces when they are eventually needed? Wat.

Adding statements can be error-prone


Another reason why omitting braces is considered bad practice is that it may be easy to introduce logical errors when maintaining such code (see this question on Programmers StackExchange and this other one on Stack Overflow). Let's say you have this:

            if (x == 0)
                Console.WriteLine("x is zero");

Then, you add an additional statement intended to be within the conditional, and you do it like this:

             if (x == 0)
                Console.WriteLine("x is zero");
                Console.WriteLine(" which means it's neither positive nor negative");

Oops! The second Console.WriteLine() isn't actually part of the conditional, so it always gets executed, no matter what. This is a valid argument. But let's dissect it a little further.

First, let's start again from our simple single-line conditional:

             if (x == 0)
                Console.WriteLine("x is zero");

Now, if you want to add code at this point, you have two courses of action. If you want to add statements as part of the conditional, you know that there's just one statement and no braces, so adding them should be a pretty automatic response:

            if (x == 0)
            {
                Console.WriteLine("x is zero");
                Console.WriteLine(" which means it's neither positive nor negative");
            }

On the other hand, if you want to add a statement that is not a part of the conditional, you add it at the same level as the if statement:

            if (x == 0)
                Console.WriteLine("x is zero");
            Console.WriteLine(" which means it's neither positive nor negative");

Even in absence of braces, the indentation shows clearly that one statement belongs to the conditional and the other does not. So actually, when seeing this kind of code:

             if (x == 0)
                Console.WriteLine("x is zero");
                Console.WriteLine(" which means it's neither positive nor negative");

...I can't help but think that the readability problem (which results in incorrect control flow) is one of indentation, not of whether to use braces or not.

I can certainly imagine beginning programmers making this kind of mistake, but I find it hard to believe that more seasoned programmers find it hard to read basic conditionals. As one of the answers to this question states:

"I even find it implausible that this should be a common mistake: blocks are a fundamental part of programming. Block level resolution and scoping is an automatic, ingrained mental process for programmers. The brain just does it (otherwise, reasoning about programming would be much harder). There is no additional mental effort required to remember putting the braces: the programmer also remembers to indent the newly added statement correctly, after all; so the programmer has already mentally processed that a block is involved." -- Konrad Rudolph

Also, one of the sections in this article states that:

"Programmers with enough discipline to always notice the braces (and put them in when needed) don't need this idiom [always using braces].
"Auto-indent editors make it obvious whether your new statement is part of the else clause, making it unlikely you'll have the bug this idiom tries to prevent."

Summary


Personally, I think that using braces when they aren't necessary is a waste of space, resulting in a lot of unnecessary lines of code. I use them when needed, and don't use them for single statements. I find nothing wrong with omitting braces when they aren't needed. This has worked for me for many years, and you may or may not agree wtih me. Different people find themselves comfortable using different approaches, and there is no general consensus on what is best.

So find out what works best for you, and don't let anyone tell you how you should write your code based on subjective arguments. While you should definitely learn from more experienced programmers and best practices based on rational and logical arguments, be practical and don't get too religious about your code.

Sunday, September 22, 2013

C#: Mocking and Dependency Injection for Unit Testing a File Sorting Program

Hullo folks! :)

In yesterday's article, "C#: Unit Testing with SharpDevelop and NUnit", we learned about unit tests: what they are, why we use them, and how we write and execute them. The article ended with a number of insights about them. One of these insights was that it is not easy to write unit tests for code that relies on databases, the network, or other external resources.

In today's article, we're going to address this problem by learning about mocking and dependency injection. These might sound like big buzz-words, but you'll see in this article that they're really nothing special. To see this in action, we'll write a small program that loads a file from the hard disk and sorts it alphabetically, line by line.

This article is a bit on the advanced side, so ideally you should know your OOP and also be familiar with basic unit testing (e.g. from yesterday's article) before reading it.

Start off by creating a new Console Application in SharpDevelop. When this is done, add a new class (right click on project in Projects window, Add -> New Item...) and name it Sorter. At the top, add the following to allow us to read files and use lists:

using System.Collections.Generic;
using System.IO;

Next, add a member variable in which we can store the lines in the file:

private String[] lines;

Add a constructor in Sorter that takes the name of the file to sort, and loads it into the variable we just declared:

        public Sorter(String filename)
        {
            this.lines = File.ReadAllLines(filename);
        }

Now, add a method that actually does the sorting:

        public String[] GetSortedLines()
        {
            List<String> sortedLines = new List<String>(lines);
            sortedLines.Sort();
            return sortedLines.ToArray();
        }

This way of sorting is not the only one and not necessarily the best, but I chose it because it's simple and doesn't change the lines variable, just in case you want to keep it in its original unsorted format for whatever reason.

Let's try and write a test for this code. Add a new class called SorterTest (as I've already mentioned in yesterday's article, people usually put tests into their own project, but I'm trying to teach one concept at a time here). After adding a reference to nunit.framework.dll (check yesterday's article in case you're lost), set up the SorterTest.cs file as follows:

        [Test]
        public void GetSortedLinesTest()
        {
            Sorter sorter = new Sorter("test.txt");
            String[] s = sorter.GetSortedLines();
          
            Assert.AreEqual("Gates, Bill", s[0]);
            Assert.AreEqual("Norris, Chuck", s[1]);
            Assert.AreEqual("Torvalds, Linus", s[2]);
            Assert.AreEqual("Zuckerberg, Mark", s[3]);
        }

Create a file in your bin\Debug folder called test.txt and put the following in it:

Zuckerberg, Mark
Norris, Chuck
Gates, Bill
Torvalds, Linus

Open the Unit Tests window in SharpDevelop (View -> Tools -> Unit Tests) and run it. You can see that the test passes.

Great.

Actually, this is the wrong way of writing unit tests for this kind of thing. We have a dependency on the filesystem. What would happen if that file suddenly disappears? As a matter of fact, we are supposed to be testing the sorting logic, not whether the file is available or not.

In order to do this properly, we're going to have to refactor our code. We need to take our file loading code out of there. Create a new class called FileLoader and add the following at the top:

using System.IO;

...and then set up FileLoader as follows:

    public class FileLoader
    {
        private String[] lines;
      
        public String[] Lines
        {
            get
            {
                return this.lines;
            }
        }
      
        public FileLoader(String filename)
        {
            this.lines = File.ReadAllLines(filename);
        }
    }

In Sorter, remove the constructor as well as the using System.IO; and the lines variable. Instead, we'll pass our FileLoader as a parameter:

        public String[] GetSortedLines(FileLoader loader)
        {
            List<String> sortedLines = new List<String>(loader.Lines);
            sortedLines.Sort();
            return sortedLines.ToArray();
        }

This is called dependency injection: instead of creating the dependency (in our case a file) from within the Sorter class, we pass it as a parameter. This allows us to substitute the dependency for a fake (known as a mock). To do this, we'll need to take advantage of polymorphism (see "C# OOP: Abstract classes, fruit, and polymorphism". Create an interface (when adding a new item, instead of Class, specify Interface) and name it IFileLoader:


An interface is a form of abstract class - it cannot be instantiated, and it declares methods and/or properties that don't have any implementation because they should be implemented by the classes that inherit from (or implement) that interface. In an interface, however, no methods/properties have an implementation. It is used as a contract, saying that any class implementing the interface must implement its methods/properties. In our case, IFileLoader will be this:

    public interface IFileLoader
    {
        String[] Lines
        {
            get;
        }
    }

We then specify that FileLoader implements IFileLoader; this is the same as saying that FileLoader inherits from IFileLoader:

public class FileLoader : IFileLoader

FileLoader already has the necessary Lines property, so we're fine. Next, we replace the FileLoader parameter in Sorter.GetSortedLines() with an instance of the interface:

public String[] GetSortedLines(IFileLoader loader)

This allows us to pass, as a parameter, any class that implements IFileLoader. So we can create a class, MockFileLoader, that provides a hardcoded list of names:

    public class MockFileLoader : IFileLoader
    {
        private String[] lines = { "Zuckerberg, Mark""Norris, Chuck""Gates, Bill""Torvalds, Linus" };
      
        public String[] Lines
        {
            get
            {
                return this.lines;
            }
        }
    }

We can now rewrite our unit test like this:

        [Test]
        public void GetSortedLinesTest()
        {
            IFileLoader loader = new MockFileLoader();
            Sorter sorter = new Sorter();
            String[] s = sorter.GetSortedLines(loader);
          
            Assert.AreEqual("Gates, Bill", s[0]);
            Assert.AreEqual("Norris, Chuck", s[1]);
            Assert.AreEqual("Torvalds, Linus", s[2]);
            Assert.AreEqual("Zuckerberg, Mark", s[3]);
        }

If you run the unit test, you'll find that it works just like before, just that this time our unit test isn't dependent on any file and can run just file without one:


In this article, we have seen how to create mock classes that emulate the functionality of our normal classes, but can replace them in unit tests when dependencies exist. To facilitate this, both the mock class and the normal class implement a common interface, and an instance of this interface is passed as a parameter to the method being tested. This is called dependency injection and allows us to control what is being passed to the method.

It is not always easy to write mocks. First, as this article has shown, code may need to be refactored in order to isolate dependencies and support dependency injection. Secondly, mocking complex classes (e.g. an IMAP server) can take a great deal of effort and might not necessarily be worth it. Use your own judgement to decide whether you need unit tests in such situations.

Thanks for reading, and be sure to visit here often to read more articles that might be useful.

Saturday, September 21, 2013

C#: Unit Testing with SharpDevelop and NUnit

Hey there! :)

In today's article I'm going to introduce unit testing, and show how basic unit tests can be written and run from within SharpDevelop. This is just one way of doing unit testing; Visual Studio's integrated unit testing suite is a pretty good alternative, or else you could use NUnit separately from your IDE; but let's not go there at this stage.

As usual, let's avoid lengthy overviews and learn about unit testing by doing it. To start off, create a new SharpDevelop project. Then, right click on the project in Solution Explorer and select Add -> New Item...; from there, add a new class called EmailAddress:


Set up the class such that it can be used to store an email address provided in its constructor:

    public class EmailAddress
    {
        private String emailAddress;
      
        public EmailAddress(String emailAddress)
        {
            this.emailAddress = emailAddress;
        }
    }

In the EmailAddress class, add a simple method to check whether the email address it contains is a valid one:

        public bool IsValid()
        {
            if (this.emailAddress.Contains("@"))
                return true;
            else
                return false;
        }

Let's add also add some code in Main() that will allow us to test this manually:

         public static void Main(string[] args)
        {
            Console.WriteLine("Enter your email address: ");
            String emailStr = Console.ReadLine();
            EmailAddress emailAddress = new EmailAddress(emailStr);
          
            if (emailAddress.IsValid())
                Console.WriteLine("Congratulations, your email is valid!");
            else
                Console.WriteLine("Oops, that's not a valid email address!");
          
            Console.ReadKey(true);
        }

Now, we could run the program several times, each time giving it a different email address to test it, but this would be tedious. Instead, we can write unit tests. These are normally kept in a separate project, but to keep things simple, we'll use the same project. Before we proceed, though, you'll need to download and install NUnit. When you're done, you should be able to find nunit.framework.dll in NUnit's bin\framework folder:


Back in SharpDevelop, from Solution Explorer, right click on the project and select Add Reference...:


In the window that appears, select the ".NET Assembly Browser" tab, hit the "Browse..." button, and locate the nunit.framework.dll file as above. This will allow you to use NUnit's functionality directly from within SharpDevelop.

Add a new class called EmailAddressTest and replace the default contents of the file with the following code:

using System;
using NUnit.Framework;

namespace CsSdUnitTesting
{
    [TestFixture]
    public class EmailAddressTest
    {
        [Test]
        public void EmailAddressTest_Simple_Valid()
        {
            EmailAddress email = new EmailAddress("test@example.com");
            bool isValid = email.IsValid();
            Assert.IsTrue(isValid);
        }
    }
}

Note how, on the second line, we are using the NUnit.Framework namespace, which comes from the nunit.framework.dll to which we have just added a reference. This allows us to mark classes containing tests with the TestFixture attribute, and test methods with the Test attribute.

The method you see above is an example of a unit test: in it, we create an instance of our EmailAddress class, and test a particular method (in this case the IsValid() method). We hardcode an input, evaluate the method, and define an expected output using one of the many methods in the Assert class.

Let's actually run this unit test. Open the Unit Tests window by going to the View menu and then selecting Tools -> Unit Tests:


Once the Unit Tests window opens up on the right, you can just hit one of the Play buttons to run your tests:


Your unit tests should capture not only valid data, but also cases that are meant to fail. For example, this unit test catches invalid email addresses that are missing the '@' character:

        [Test]
        public void EmailAddressTest_NoAt_Invalid()
        {
            EmailAddress email = new EmailAddress("hello");
            bool isValid = email.IsValid();
            Assert.IsFalse(isValid);
        }

When you run this test, you should get a green light just as before, showing that the test has passed.

Now, let's try a different test:

        [Test]
        public void EmailAddressTest_NoDomain_Invalid()
        {
            EmailAddress email = new EmailAddress("test@");
            bool isValid = email.IsValid();
            Assert.IsFalse(isValid);
        }

This test is supposed to catch cases where there is no domain, and we expect it to be invalid. So we run the tests again:


Crap. Our test failed, so we need to go back and fix the code. When logic is complicated, you can set breakpoints in the tests and run the tests within the debugger, saving you from having to actually run the program itself (which may take time for more complex applications).

There are many ways to verify an email address, including using the MailAddress class or using a regular expression. In my case I wrote a simple regular expression which does not cover every case but is enough for what we need. I haven't covered regular expressions, but don't worry, just use this code for IsValid():

        public bool IsValid()
        {
            if (Regex.IsMatch(emailAddress, @"\w+\@\w+(\.\w+)+"))
                return true;
            else
                return false;
        }

You will also need to put this at the top for it to work:

using System.Text.RegularExpressions;

If you run the tests now, they should all pass. If someone happens to change the regular expression in the future and breaks something, re-running the tests should allow you to detect the issue. Re-running a test to see whether something broke is called a regression test, and is a great way to detect problems early and fix them before they make it into a release.

In this article you have seen how unit tests are used, with the example of validating an email address. There is a lot more to say about unit tests, but this should suffice as an introduction. I will mention a few points however:
  • Unit tests allow you to test a single unit of functionality, often a method or property.
  • As such, they work great with methods that have a clear input and output (such as a method which takes an email address in String format and returns a boolean indicating whether it is valid or not).
  • Unit tests are not easy to write for methods which are not public, which are void, or which do not take parameters. In Visual Studio there is a way to get around this, but in NUnit you have to refactor your code.
  • Unit tests are really tricky to write for methods which rely on external resources such as files, databases, or remote network locations. To make them work in such scenarios, techniques such as dependency injection and mocking come into play.
  • Unit tests won't make your code bug-free, especially if you don't write unit tests to handle the majority of possible inputs. They won't solve all your problems, so use them only when they are worth the effort.
  • Some people like to write unit tests before the actual development code - this is called Test Driven Development (TDD).
That's all, folks! Stick around, as articles are posted here regularly. :)

Friday, September 20, 2013

VB .NET Basics: Input and Output

Sup people!

In today's article we're going to take a look at Visual Basic .NET (VB .NET for short, or even just VB if you're lazy). Like C#, VB .NET is based on the .NET framework, and so many classes and methods will be familiar. The syntax of the language, however, is quite different. Let's get our hands dirty and see for ourselves.

Fire up SharpDevelop (or Visual Studio, if you prefer). From the File menu, go to New -> Solution... so that you get the New Project dialog:


You'll need to open up the "VB" node in the Categories treeview to the left, select "Windows Applications", and then choose the "Console Application" template in the panel to the right. Select a name for the project, choose where on your filesystem to place it, and you're good to go. Hit the "Create" button.

You get the following code in SharpDevelop by default:

Module Program
    Sub Main()
        Console.WriteLine("Hello World!")
       
        ' TODO: Implement Functionality Here
       
        Console.Write("Press any key to continue . . . ")
        Console.ReadKey(True)
    End Sub
End Module

This is no different in functionality from what we saw in my first article here, C# Basics: Input and Output. Here's some example output:


Let's change code to achieve functionality similar to what we had in that article:

Module Program
    Sub Main()
        Console.WriteLine("What is your name?")
        Dim name As String = Console.ReadLine()
        Console.WriteLine("Hello {0}!", name)
        Console.ReadKey(True)
    End Sub
End Module

There are a few things to notice here. The Console methods are exactly the same as in C#, and even support the same {0}-style formatting. The general syntax, however, is very different:

  • There are no semicolons to end statements in VB .NET.
  • Variable declarations begin with the Dim keyword. Its etymology is pretty irrelevant - it's just an ugly way of saying "This here is a variable". Variable types, if included, go after the variable name.
  • Many blocks that are enclosed in braces ({ and }) in C# need an End statement in VB .NET instead (as you can see above). The same goes for things like If statements.
  • Module is like a class - in fact it's the equivalent of a static class. If you don't know what that means, don't worry about it.
  • In VB .NET, functions (also known as methods) come in two flavours. A Function is a regular function that returns some value. A Sub, on the other hand, is a subroutine that doesn't return a value (equivalent to void functions in C/C#/Java, or procedures in Pascal).
When it comes to variable declarations, you can actually leave out the data type, like this:

Dim name = Console.ReadLine()

That's perfectly valid, and name is automatically declared as a String since the type is deduced from the assignment. You can also declare just the variable name:

Dim money

However the type you want to use can't be deduced in this case, and is defaulted to Object.

I consider both of the above examples to be somewhat bad practice - I prefer to always include the variable type as it helps whoever's reading the code understand how that variable should be used. While there are legitimate reasons why you might want to leave it out, most of the time it's not a good idea (a very similar debate revolves around C#'s var keyword for the same reasons).

An important thing to note is that in many cases, VB .NET uses different keywords for data types. For example, you'd declare an integer like this:

Dim age As Integer

...and you declare your typical DateTime like this:

Dim dateOfBirth As Date

Woohoo! :) In this article, we've written our first VB .NET program, and taken a look at basic console input/output as well as dealing with variables.

Personally I don't like VB .NET much because its overuse of keywords, as well as their oddness (see Dim above) makes it a pretty ugly language to use if you're used to using languages with C-style syntax. However, you don't always get to choose which languages to use. So whether you're learning VB .NET as a first language or are switching over from C#, I hope you found this article useful! :) Be sure to check back here for more.

Wednesday, September 18, 2013

Linux: Navigating Text with vi

Howdy folks! :)

In the last article here, "Linux: vi Essentials", we looked at several of the vi text editor's basic commands. Today we'll take a look at a few more, and we'll focus on commands that allow you to quickly jump across portions of text. You will begin to notice patterns in how vi commands are structured, and this will allow you to harness its power and use it very efficiently.

Let's start off with some text that we can work with. First, open a Linux terminal and fire up vi with the following command:

vi test.txt

Enter insert mode using the i command, and press Shift+Insert to paste the following lyrics from Queen's song Friends Will Be Friends:

It's not easy love, but you've got friends you can trust,
Friends will be friends,
When you're in need of love they give you care and attention,
Friends will be friends,
When you're through with life and all hope is lost,
Hold out your hand cos friends will be friends right till the end.

Press ESC to go back into command mode. Move the cursor to the second line, and alternate between pressing e and b. You'll see that e takes you to the end of the word (the 's' in 'Friends'), and b takes you back to the beginning of the word (the 'F' in 'Friends'). Next, try pressing 'w' repeatedly - you'll notice you will move to the next word each time (first to the 'w' in 'will', then to the 'b' in 'be', and so on). This will continue to take you to the next word even if it is on another line.

If you've read "Linux: vi Essentials", you have already seen the 'w' command in use - as part of the 'cw' (change word) command. As a matter of fact, such commands are really made up of several parts. The first part is the command itself, such as c (change) or d (delete). The second part tells it until where it should work, so cw actually means "change from where the cursor is until the next word". You can achieve a similar effect with other commands - dw will delete characters until the next word.

The ^ command will take you to the beginning of the line the cursor is on, and the $ command will take you to the end of the line. Once again, you can combine these with other commands. c$ will change from the current cursor position until the end of the line. y^ will copy (for later pasting) from the current cursor position back to the beginning of the line.

These multi-character commands also have some other interesting patterns. If you re-type the command rather than specifying where it should end, it will affect the entire line you are on (no matter where in the line the cursor is) - we have already seen this with dd and yy. The same goes for cc. If you put a number between or before the command (as we have seen in the last article, d5d and 5dd both delete 5 lines), you affect a number of lines. If you type the command as a single uppercase character (e.g. D), you affect from the current cursor position until the end of the line - so C is actually equivalent to c$.

Other handy navigation commands allow you to run around the entire file or jump to specific line numbers. The gg command will take you to the beginning of the first line in the file, and the G command will take you to the beginning of the last line in the file. A handy way to clear an entire file is to first go to the beginning of the file (gg) and then delete until the end of the file (dG).

You can jump to a particular line number using :n, where n is the line number you want (e.g. :1 is equivalent to gg). The line number you're on is indicated near the bottom-right of the editor together with the column. If you want to show line numbers, you can use the special command :set nu, but the lines will take a portion of your editing space. Use :set nonu to turn off line numbers.


There are a bunch of navigation commands that you can check at the Vi Cheat Sheet if you really want to go deep. I think the ones I mentioned above are more than enough to get you rolling. I'll just mention one more thing you'll definitely find useful.

Use a forward slash (/) followed by a word to search for that word (e.g. /hand). vi is very powerful (I keep repeating that) and supports regular expressions as well as search and replace, but those are beyond the scope of this article. You can read about them at the Vi Cheat Sheet or elsewhere on the internet.

Nice! I hope this helps you in your day-to-day vi operations, and check back for more articles! :)

Update 2013.11.28: if you want to learn some of the more advanced things you can do with vi, the answer to this question is a really fantastic overview.

Sunday, September 15, 2013

Linux: vi Essentials

Hi people! :)

I've already briefly discussed vi in my article "C: Hello World on Linux". vi is a text editor, and a pretty versatile one at that. It takes a bit of time to learn because there are so many commands you can use, but once you learn it, you can do things really fast.

Learning to use a text editor like vi on Linux is important because you can use it for many things, from editing configuration files to writing code. Even better, make sure you have vim (vi improved) which brings syntax highlighting and better keyboard navigation (and probably more):


Now, there are many tutorials and references on vi, including this great cheat sheet. However, instead of teaching you every vi command, I'm going to go through the most important commands in a practical manner, in the usual spirit of Programmer's Ranch.

So let's start off by opening a file called test.txt:

vi test.txt

Note that the file does not actually exist until you save it. You can save it at any time using the :w command. You can save and quit using the :wq command. You can try to quit only with the :q command, but if there are pending changes, you'll get a warning (as below). In that case, you can quit and discard your changes with the q! command.



Basically, in vi you can be either in insert mode (in which you're actually writing stuff in the file) or in command mode (in which you write commands, such as those I just mentioned, and press ENTER to execute a variety of operations. You start off in command mode, and can switch to insert mode using various commands (which I'll mention in a minute). You can go back into command mode by pressing the ESC key.

To try out a bunch of commands, go into insert mode (press the 'i' key) and paste the following lyrics from The Eagles' song Lyin' Eyes:

City girls just seem to find out early
How to open doors with just a smile
A rich old man
And she won't have to worry
She'll dress up all in lace and go in style

You can move the cursor around the text using the arrow keys, whichever mode you're in. If you're in command mode, you can also use the h, j, k and l keys to move left, down, up or right (these are especially important if you have some old version of vi that doesn't support the arrow keys.

The basic keys to go into insertion mode are 'i' and 'a', meaning 'insert' and 'append' respectively. Try them both by moving your cursor over the 'r' in 'rich' while in command mode, and pressing the respective key. You'll find that 'i' goes into insert mode right before the 'r', while 'a' goes into insert mode starting right after it.

To copy and paste a line of text, go on that line and press yy. Then, move to another line and press p to paste the line of text right after it:



You can use dd to delete an entire line, or D to delete from the cursor until the end of the line. Try that by pressing dd while you are on the last line, and pressing D (Shift+d) while the cursor is at the beginning of the word "lace".

You can delete single characters by pressing 'x'. One of the great features about vi is that you can instruct it to repeat commands for a number of times. So, the command 5x will delete 5 characters. This also goes for other commands, for example you can delete 5 lines by using either d5d or 5dd.

The 'u' key will allow you to undo your last command - great if you accidentally deleted something. The '.' key, on the other hand, will allow you to repeat a text edit - but not in the way you're used to it. What it does is remember what your last command was, and reapply it at the cursor's current position. So if your last command was 'x', pressing '.' will delete the character at the cursor position.

At this point we've covered the very basics, and you can already get to work with these few commands. However, I'd like to add a few other commands that I've found particularly great when using vi on the job. Start over with a fresh copy of the lyrics at the beginning of this article.

Let's say we want to replace the word "lace" with the word "red". There are many ways we can do this (e.g. 4x on "lace", i for insert mode, and then type "red). A faster way is to hit cw (change word) while the cursor is on the beginning of "lace". That deletes "lace" and goes into insert mode automatically, so then you just have to type "red":



Another great command is 'o'. This will create a new line below the one your cursor is on, move the cursor to the beginning of it, and switch to insert mode. A variant is 'O' (Shift+o), which starts a new line directly above the one your cursor is on.

As an exercise in these extra commands, start off with this text:

select *
from yourtable
where 1=1

and find a quick way to change it to:

select *
from mytable
where 1=1
and 2=2

Great! :) I hope you find this useful, and don't forget to like the Programmer's Ranch Facebook page to stay up to date with articles as they are posted.

Thursday, September 12, 2013

On Mystery Meat Navigation and Unusability

Hello folks! :)

Today I'm going to talk about Mystery Meat Navigation (MMN). This term was invented 15 years ago by Vincent Flanders of Web Pages That Suck. It refers to a horrible practice of filling a website's navigation with meaningless icons. When a user moves his mouse over one of these icons, the icon changes or pops up some text, revealing what it really does.

User Experience Invention has a couple of fantastic examples of mystery meat navigation. First, the icons at the top are completely meaningless until you mouse over them to reveal things like "Buy our Stuff" and "Jobs". At the bottom is a road sign analogy: imagine you're driving and there's an empty sign, which transforms into an "Exit" sign just as you drive past it. Oops!

Even now, 15 years later, MMN is still used on the web. Even reputable web design companies here in Malta have fallen in the MMN trap. Alert eBusiness, for instance:


Right, so what do those icons mean? The last one seems pretty clear: a shopping cart. Mousing over it reveals it stands for Alert Payment Gateway, which is close enough. But what about the rest? The first one is a mouse, for instance. Would it ever cross your mind that it actually means "Web Design"?

Another example: Pcionix:


The home icon is pretty obvious, so that can be forgiven. But a pie chart that stands for SEO - seriously?

But this, from design.com.mt, is even worse:


This has got to be the worst of them all. Whereas you might be able to somehow guess what the icons in the other sites mean, the navigation here is hidden behind meaningless numbers that you again have to mouse over to understand.

It gets worse: there are videos on YouTube of sites with iconic navigation that actually floats around, so you actually have to find out where that "About Us" cube thingy moved to (examples: Mandarina DuckQualcomm).

So why is MMN bad? In case it isn't obvious, it is very annoying for users to have to click on stuff to figure out what the page offers. A website should give a clear indication of how it is structured, without the user needing to interact with it just to get an idea. Imagine you're driving and need to interact with a bunch of direction signs (such as these) one by one to get an idea of the places in the area. Then, after sifting through a dozen, you forget what you saw earlier and have to go back and interact with them again. Sorry, the "just a click away" idea is not an excuse when it comes to navigation, which is really a website's backbone.

Another great example comes from feedback that Vincent Flanders received, and illustrates how MMN would be if applied to a business's answering machine:

"You've reached XYZ Corporation. To find out what option #1 is, press 1. To find out what option #2 is, press 2. (Etc....) If you'd like to continue doing business with our company after we've slapped you around and wasted your valuable time, press 9"

MMN is a slap in the face of usability. It shows meaningless icons in the place of important navigational information. What could possibly worse?

The only thing worse than showing meaningless icons is not showing any icons at all! That's pretty much the direction taken by Windows 8's notorious alternate UI, formerly known as Metro. One if its design principles is "Do more with less" which includes "Put content before chrome". In this case the "chrome" refers to the stuff that makes the application - menus, the 'X' button at the top-right, toolbars, etc. So basically you end up with something like this:


That's the default PDF viewer on Windows 8 - one full screen Windows 8 Style (the new name for Metro) app with the PDF content and nothing else, not even an 'X' to close it. In fact Windows 8 users are somehow expected to know beforehand ("by osmosis", as this Windows 8.1 review puts it) that to close a Windows 8 Style app you have to grab it from the top and drag downwards with your mouse. Contrast this with the same PDF viewed on Windows 7:


Needless to say, everything that you can do with a PDF is immediately accessible either from the toolbars or via the menus. There is no hidden stuff, no needing to drag your mouse into a corner to open some Start Screen or Charms Bar. See, the program actually shows you what it can do, and for new users that's important. The "Content before Chrome" idea is wrong precisely because when you use a program, you want to do stuff, not just see stuff.

So it's no wonder that Microsoft seems to have made a U-turn on its Windows 8 Style design stuff. If MMN is an example of bad usability, this Windows 8 abomination is an example of... unusability.