9.1 Risk-driven specification

• Specifying safety and security specs by starting with the risks.
• Risk analysis:
  • 9.1.1 Risk identification – identify potential risks—> risk description.
    • Each risk is a hazard in a specific class. Think about each class: (physical, electrical, biological, radiation, service failure)
    • In case of software, one is normally concerned with service failure or failure in the monitoring and protection systems.
  • 9.1.2 Risk analysis and classification – analyze each risk, is it serious (severity)? Is it likely (probability)?—> Risk assessment
    • A category for each risk:
      • Intolerable – Risk should not arise, or if it does, not cause and accident.
      • As low as reasonably practical (ALARP) – Take measures, but consider the impact of the risk, and the costs involved in preventing it. Keep it reasonable.
      • Acceptable – Reduce probability of risk, but not at additional cost.
    • Risk categories may shift over time: Pollution prevention is more important now than it was 50 years ago.
    • Risk analysis uses relative terms such as “high, moderate, low”, not numbers.
  • 9.1.3 Risk decomposition – What are the root causes of each risk? Possibly use fault-tree analysis. —> Root cause analysis.
    • Two directions:
      • Deductive: top-down, easier. Start with the risk and work down to the possible system failure.
      • Inductive: bottom-up, harder. Propose a system failure, then find hazard that could cause it.
    • Fault-tree analysis: Take a hazard and try to find its possible causes. Each cause can have sub-causes.
  • 9.1.4 Risk reduction assessment – Make proposals to reduce or eliminate risks. —> Dependability requirements.
    • Three strategies:
      • Avoidance – the risk simply cannot arise
      • Detection and removal – the risk will be detected and neutralized before any damage can be done
      • Damage limitation – the damage from the risk is minimised if it occurs

9.2 Safety specification

• A standard exists for safety specifications: IEC 61508. However it separates safety specs from the other specs.
• Redmill’s model for safety requirements for control systems:
  • Functional safety reqs – the safety functions of the system
  • Safety integrity requirements – the reliability and availability of the protection system
• Figure 9.7

9.3 Security specification

• Security specs are something other than safety specs. Differences:
  • Security management methods are less well developed.
  • Security requirements are often the same accross many different systems.
  • Security techniques (e.g. encryption, authentication) are quite mature. Safety techniques often are unique for each situation.
  • Security holes often affect a large quantity of software, because many people run the exact same program. For safety-critical systems, it is often a custom-made solution, so this does not apply.
• The security specification process:
  • Asset identification and evaluation – The assets (data + programs) and their required degree of protection are identified
  • Threat analysis and risk assessment – Possible security threats are identified and the risk is analyzed
  • Threat assignment – Linking threats to assets, so that each asset will have a list of threats
  • Technology analysis – Assess which security technology might be applicable for a threat
  • Security req specification – The security reqs are specified, and where appropriate, they identify which technology to use
• Firesmith’s 10 types of security reqs:
  • Identification – Should the system identify a user before interacting?
  • Authentication – How should the system identify the user?
  • Authorisation – What are the priveliges and access permissions of users?
  • Immunity – How does the system protect itself against worms, viruses etc.
  • Integrity – How can data corruption be avoided?
  • Intrusion detection – How are attacks on the system detected?
  • Non-repudiation – How can a party be made unable to deny its involvement in a transaction?
  • Privacy – How is data privacy achieved?
  • Security auditing – How can system use be audited and checked?
  • System maintenance security – How to prevent that authorized defeat security mechanisms?

9.4 Software reliability specification

• Reliability is often considered at the system level, because it involves many components.
  • Three dimensions of reliability:
    • Hardware
    • Software
    • Operator – what happens if the user makes a mistake?
  • Consider the risk of a bad error message: confuses the user, which then acts incorrectly and causes more damage!
• 9.4.1 Reliability metrics that can be used to indicate the level of reliability:
  • POFOD – Probability of failure on demand – Likelihood of failure when a request is made. Between 1 and 0 – Good for systems where requests are made with big or irregular intervals.
  • ROCOF – Rate of failure occurance – How frequent are occurances of failure in normal operation? Written as a ratio: 2/100, 2 out of 100 – Good where system is used often
  • MTTF – Mean time to failure – The average time between observed failures. A positive number. 500 means one failure every 500 time units – Good for systems used for long periods of time
  • AVAIL – Availability – How likely a system is available at any given time. Between 1 and 0 – Good for systems that are always-on, like servers.
• 9.4.2 – Non-func reliability reqs
  • Types of failure:
    • Transient – Only with certain inputs
    • Permanent – With all inputs
    • Recoverable – System can recover without operator intervention
    • Unrecoverable – Operator intervention required to recover
    • Non-corrupting – Failure does not corrupt system state or data
    • Corrupting – Failure corrupts system state or data
  • Steps involved in making reliability specs:
    • For each subsystem, define types of failure, analyse consequences of these failures
    • Put each failure into one of the above classes
    • For each class of failure, define the reliability requirement using an appropriate reliability metric
    • Where appropriate, identify functional reliability requirements to reduce the probability of critical failures
• The higher the reliability required, the harder to physically test this. Say you want a ROCOF of 1/100.000, you will have to test 100.000 times to make sure.

Detailed system reqs may be written in a more technical way, because they are for the developers. Graphical models are often used to describe a system in detail, as they are more effective than using natural language. Different models exist for different perspectives of the system.

8.1 Context Models

• At an early stage in the reqs elicitation and analysis, determine the boundaries of the system. Distinguish system from system’s environment.
• Social and organisational concerns influence the system boundary.
• After deciding on the boundaries, you can create a context model showing how the system will interact with other systems.
• Because architectural models do not show the interaction with other systems, they are often supplemented by other models, such as process or data-flow models.
• You can show the boundary in a process model easily.

8.2 Behavioural models

• Behavioural models discribe the overall behaviour of the system.
• Data-flow models:
  • Simple, the client can also understand these.
  • Often done in a hierarchical fashion, starting with the top layer and creating new models for each sub-process to illustrate details.
  • Show the data processing of the system
  • Sometimes these alone are sufficient as most business systems are primarily driven by data.
  • Symbols:
    • Rounded rectangles: Functional processing
    • Rectangles: Data stores
    • Labeled arrows: Data movements between functions
• State machine models:
  • How the system reacts to events through system states and events which change states.
  • Very useful for real-time systems which are event-driven with minimal data processing.
  • Inside a state you can describe what the system does. See fig 8.5

8.3 Data models

• A database is often used to store data used by the system. A database may already exist. To model a database various systems exist, the most common being Entity-Relation-Attribute modelling (ERA).
• Database models are commonly in ‘3rd normal form’, a characteristic which avoids storing data in a redunant manner.
• ERA entities are very similar to Objects in UML, except that they cannot have methods.
• ERA models lack detail, often it is needed to add descriptions to go with the model. One such description is the Data Dictionary:
  • An alphabetic list of names used in the sytem models
  • Each item has a description
  • Advantages of a Data Dict:
    • A mechanism for name management – Prevents duplicate names if all system names are stored in it.
    • A store of organisational information – Information about each entity can be looked up here.

8.4 Object models

• Object models are very common, they are implemented in OO- programming languages.
• Object modelling is used to represent both data and processing.
• Although practical for the programmers, the end users have trouble understanding object models and prefer a clear separation of data and processing.
• Classes are like ‘blueprints’ for Objects, which are instantiations of Classes. When modelling, be sure to model the Classes, not the instantiations thereof.
• Object classes in UML are represented as a vertically oriented rectangle with three sections (top to bottom):
  • The name of the Class
  • The attributes of the Class
  • The methods of the Class
• 8.4.1 Inheritance & multiple inheritance blah blah we learnt this two years ago.
• 8.4.2 Object aggregation – UML diamond shape, learnt two years ago.
• 8.4.3 Objects behaviour modelling – Sequence diagrams, nothing new here.

8.5 Structured models

• Structured methods are systematic ways of producing models of existing and new systems.
• CASE tools exist for these models.
• Various disadvantages:
  • No effective support for non-functional reqs.
  • Do not adapt well to specific problems, systems, are very generic.
  • Produce too much documentation, which may hide the essence under all the detail.
  • Too much detail makes the models hard to understand for the users.
  • In practice, these disadvantages aren’t so bad, most req engineers use multiple modelling techniques to complement each other.
• A comprehensive CASE tool supports:
  • Diagram editors – not just drawing tools but aware of the entities and their relations.
  • Design analysis and checking tools – process the design, point out errors.
  • Repository query languages – allows the designer to find designs and associated design information in the repository.
  • Data dictionary – with information about the entities from the design.
  • Report definition and generation tools – to automatically produce paperwork.
  • Forms definition tools – to specify screen and document formats
  • Import/export facilities – to exchange information between the central repository and other development tools
  • Code generators – to generate code or code skeletons

Goal of the requirements engineering process is to create and maintain a sytem requirements document. The process can be seen as a spiral going from elicitation to specification and then to validation. After that it starts over. Fig 7.2

7.1 Feasibility studies

• Made at the start of a project, to determine if it’s worth carrying on with the project.
• In a RUP project, they’re part of the Inception phase.
• They aim to answer the following:
  • 1. Does the system contribute to the overall objectives of the organisation?
  • 2. Can the system be implemented with current technology and within given cost and schedule constraints?
  • 3. Can the system be integrated with other systems which are already in place?
• Phases:
  • Information assessment – What information is needed to answer the above three questions?
  • Information collection – Finding the answers to the above three questions by consulting many sources. Many different people and sources can be used.
  • Report writing – Actually writing the report.

7.2 Requirements elicitation and analysis

• Achieved through cooperation between software engineers, customers and system end-users.
• Stakeholders can be anyone who will be affected by the system, directly or indirectly.
• It is difficult to elicit and understand stakeholder requirements:
  • Stakeholders often don’t understand what they want from a computer system and badly understand how much work is needed to create something.
  • Stakeholders may have trouble explaining their work to laymen (in this case, the software engineers)
  • Many different reqs from many different stakeholders. Mind duplicate and conflicting reqs.
  • Office politics can influence reqs from certain stakeholders.
  • Businesses are ever-changing, stakeholders and their requirements can change during the elicitation process.
• Figure 7.3 – The req elicitation process. Iterative, spiral model. Each company has its own variation on this:
  • Reqs discovery – Interacting with stakeholders to collect their requirements.
  • Reqs classification and organisation – Ordering and sorting all gathered requirements. Often sorted by using a model of the system architecture. Inseperability of reqs and design.
  • Reqs prioritorisation and negotiation – Solve conflicting reqs through priorities and negotiation (compromise). Compromise to avoid angry stakeholders that attempt to undermine the project.
  • Reqs documentation – Putting the reqs in a document. This document may help with further reqs discovery. Writing reqs on cards is a common approach.

7.2.1 Requirements discovery

• Reqs discovery is the process of gathering information about the proposed and existing systems and distilling the user and system reqs from it.
• Reqs can come from stakeholders, the domain and existing systems. These sources overlap a bit.
• Various approaches for reqs discovery:
  • Viewpoint-oriented – Advantage is that because it recognises multiple perspectives, it provides a framework for discovering conflicts between stakeholder reqs. Best organised in a hierarchy. Three generic types of viewpoint (VP):
    • Interactor VP: People or systems that interact directly with the system. Leads to detailed system reqs for features and interfaces.
    • Indirect VP: Stakeholders who influence the reqs, but who don’t use the system themselves. Leads to higher-level organisational reqs and constraints.
    • Domain VP: The domain characteristics and constraints. Leads to domain constraints.
    • Also important: Engineering VP. From the people who develop, manage and maintain the system. Importance of this VP:
      • The engineers may be familiar with similar systems and the reqs thereof.
      • Because management costs are a significant part of the total lifetime cost of a system, these might be lowered significantly by gathering reqs from the future maintainers.
• Interviewing – Finding reqs through asking questions to stakeholders:
  • Often a combination of a set list of questions and questions that arise during the interview.
  • Hard to elicit domain knowledge from interviews:
    • Jargon and terminology are hard to understand.
    • Stakeholders might not tell everything, for them it may seem too trivial or so fundamental that it speaks for itself.
  • Hard to elicit knowledge about organisational reqs and constraints because of office politics, which people don’t talk about or even want to keep secret.
  • Characteristics of a good interviewer:
    • Open-minded. Avoids preconceived ideas about reqs.
    • Promts the interviewee to start discussions with a question, a reqs proposal or by suggesting working together on a prototype system.
• Scenarios – Real-life examples which people easily relate to.
  • Good for adding detail to reqs.
  • At its most general, a scenario may include:
    • Preconditions – What the system and users expect at the start of the scenario.
    • The normal flow of events in a scenario.
    • Exceptions – What can go wrong and how this is handled.
    • Other activities that might occur simultaneously.
    • Postcondition – The system state after the scenario has finished.
  • Can be done informally or with use-cases
• Use-cases – A scenario-based technique for requirements elicitation.
  • Now a fundamental feature of the UML notation.
  • Actors are shown as stick figures, each class of interaction a named ellipse.
  • A use case encapsulates a set of scenarios. One scenario for the normal interaction, plus others for each possible variation and exception.
  • Sequence diagrams are commonly used to add information to use-cases.
  • Because of the focus on interactions, they’re not very effective for eliciting high-level business, non-func and domain reqs.

7.2.2 Ethnography

• Ethnography is an observational technique to understand social and organisational reqs. Achieved by immersing an analyst in the environment in which the system will be used.
• Social and organisational factors affecting the work may only be visible to an unbiased outsider.
• Very effective for two kinds of requirements:
  • Reqs that reflect the actual rather than the formal processes.
  • Reqs that come from cooperation and awareness of other people’s processes.
• Effective to speed up prototyping, less prototype refinements will be needed!
• Should never be used alone: Does not find organisational and domain reqs.

7.3 Requirements validation

• Concerned with showing that the reqs actually define the system that the customer wants.
• Achieved through checks:
  • Validity – Are the reqs real?
  • Consistency – Are there no conflicting reqs?
  • Completeness – Are there no reqs missing?
  • Realism – Can the reqs be implemented?
  • Verifiability – Can the implementation of the reqs be demonstrated?
• Techniques available:
  • Reqs reviews – A team of reviewers analyse the reqs systematically. * Both client and contractor check the reqs document for omissions and anomalies.
    • Stakeholders need to agree with the final reqs before the development begins.
    • In a formal review, the dev team ‘walks’ the client through the reqs, explains them.
    • Review team checks for:
      • Consistency – No contradictions?
      • Completeness – No reqs missing?
      • Verifiability – Are reqs testable?
      • Traceability – Is it clear where the req comes from? Important to assess impact of a change in reqs.
      • Adaptability – Can the req be changed without significantly affecting other reqs?
    • A review document is produced at the end, lising conflicts, contradictions, errors and omissions. Users, developers and procurer must find a solution to those.
  • Prototyping – An executable model of the system is demonstrated. Customer and end-user give feedback.
  • Test-case generation – Test cases demonstrate how a req implementation can be verified.
• May continue even after the reqs document has been finished, because omissions and misunderstandings are discovered later.

7.4 Requirements management

• Reqs change. The bigger a system becomes, the more often.
• Sometimes, a problem cannot be fully defined. Hence reqs will be incomplete and need to evolve.
• After a system has been implemented, new reqs arise:
  • A large user base leads to different reqs from each user. A compromise needs to be made. After some usage of the system, the compromise may need re-evaluation.
  • The actual users and the people paying for the application are often not the same. Conflicts may arise, system might not properly reach its goals, reqs change to compensate.
  • The business and technical environment of the system change, causing changing reqs.
• Separating reqs based on likeliness of change:
  • Enduring reqs – Unlikely to change.
  • Volatile reqs – Likely to change:
    • Mutable reqs – Reqs changing because the environment of the organisation changes.
    • Emergent reqs – New reqs emerging as the customer understands the system better.
    • Consequential reqs – New reqs resulting from the introduction of the system. E.g. the organisation’s processes change due to the arrival of the system.
    • Compatibility reqs – Reqs change due to changing business processes or other systems that change.
• Reqs management means deciding on:
  • Reqs identification – How to uniquely identify reqs so they can be cross-referenced and used in traceability assessments.
  • A change management process – How to assess the cost and impact of changes.
  • Traceability policies – How to define relationships between reqs, between reqs and system design, and how to record and maintain these.
    • Three types of traceability information:
      • Source traceability – Linking reqs to stakeholders and the rationale for these reqs
      • Requirements tracability – Linking dependent reqs within the req document.
      • Design traceability – Linking reqs to design modules where they are implemented.
    • A traceability matrix is a good representation format for small amounts of reqs, but too elaborate and expensive for large amounts:
      • Fig. 7.12
      • A D indicates the req of that row depends on the req of the column.
      • An R indicates a weaker relationship than a true dependency.
  • CASE tool support – Which special tools to use to manage the reqs. Some specialist reqs might need a special tool. Tools support:
    • Reqs storage – A secure, managed data store available to everyone involved in the RE process.
    • Change management – A formal process to manage changes. Simplify change management through tool use. Three stages:
      • Problem analysis and change specification – Analyse a req problem or change proposal. Make sure it is clear what will need to be changed. Communicate with change requestor.
      • Change analysis and costing – Assess the effect of the change. This is where traceability information comes in.
      • Change implementation – The reqs document, and possibly teh system design and implementation are changed.
    • Traceability management – Generate/maintain matrices from the tool.

As promised, here is the summary of lesson one. Note I wrote this mainly for myself, so the language used may be odd. Any feedback to the accuracy of the summaries is appreciated though.

Summaries of other lessons will show up after the classes.

From the presentation

Requirements Engineering is: “The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.” “The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.”

• Risk management identifies risks and attempts to minimise the effects of potential risks.
  • A risk can affect three areas, possibly more than one at a time:
    • Project: bad for schedule, resources
    • Product: bad for quality, performance
    • Business: bad for the company making the software
  • Risk types indicate where cause of the risk lies:
    • Technology: Framework might turn out to be slow
    • People: Programmers catch a flu
    • Organisational: Management is a mess. Financial problems.
    • Tools: CASE-tool cannot be used properly.
    • Requirements: Changes to requirements. Devs get angry, this is a lot of work. Customer doesn’t understand the fuss, also gets angry.
    • Estimation: Over- and underestimations in the planning.
• Need for good requirements: Prevents different interpretations of developer and client. Try to be as complete and consistent as possible. It’s impossible to be this perfectly.
• Guidelines for making requirements:
  • No jargon.
  • Standardised use of language and bits of text.
  • Highlight important passages in a text.

From Sommerville chapter 6

• Requirements can be very abstract (“needs internet connectivity”) or very concrete (mathematical functions explained in detail). Abstract ones are useful to get a contract, concrete ones form the basis of this contract, to verify the work has been done. Requirement document types:
  • User Reqs: Written for customer. In plain speech with diagrams. Simple to understand. Hard to be precise. Func and non func are both in this document, but sometimes get mixed. Sometimes multiple reqs get expressed together.
  • System Reqs: Written for contract between client and contractor. Detailed. Defines what needs to be implemented.
  • Software Design Specification: For the developers.
• Func and non-func reqs (diagram page 122):
  • Functional: What the system should do. Depends on software, users and the platform on which the system will run.
  • Non-functional: How the system should do the above. Agree what goal must be reached with the non-func req’s. Then indicate how can be measured if the goal has been reached.
    • Product: Speed, reliability, security.
    • Organisational: Compatibility with certain standards.
    • External: Interoperability, laws that must be followed.
  • Domain: Aspects typical for the domain in which the system is used, such as medical environments. Be careful for jargon and other difficult language, the developers might not understand without explanation.
• User reqs should explain func and non-func reqs in a way understandable to the client. Use simple Natural Language (NL).
• System requirements. Reqs are what the system should do, design is how the system should do the reqs.
  • Reqs and design practically inseperable:
    • An initial architecture must be designed to help structure the requirements document.
    • Often interoperability is required with existings systems. This constrains the design.
    • Use of a specific architecture to satisfy non-func reqs might be necessary, client might demand it.
  • Usage of NL leads to problems:
    • Ambiguity: multiple interpretations
    • Over-flexibility: Multiple ways of saying the same thing
    • Lack of modularisation: NL structures inadequate to structure system reqs.
  • Solutions to NL usage problems:
    • Structured NL: using forms and templates. Writer can’t express too freely, but still use NL’s flexibility.
    • Design description languages: Pseudocode. Simple code, not in a true programming language, to illustrate details.
    • Graphical notations: UML, use-cases, sequence diagrams.
    • Mathematical specifications: Z-specs or finite state machines. Often hard to understand for client.
• Interface specifications are to define interoperability with existing systems.
  • Three types of interface:
    • Procedural: Services offered by existing systems, available through an API
    • Data structure: How data is passed between systems. Graphical modelling is used often.
    • Representation of data: How data is structured on the bit-level. Often used for embedded systems. Graphical modelling with annotations is used here.
  • Formal specifications exist for defining interfaces unambiguously. See chap 10.
• The software requirements document, aka the software requirements specification (SRS):
  • Includes both user and system specs
  • Large diversity of readers: clients, managers, developers, testers, maintainers
  • An IEEE standard exists for this document

Something I’ve been using to download stuff from Usenet is SABnzbd. This is a web-based program written in Python, which you feed NZB-files. These are files that contain lists of posts on Usenet.

SABnzbd downloads these files, checks if they’re intact, and if not, attempts to download repair files and repairs them, and then extracts files if the usenet post consisted of archive files (often .rar).

It’s one of those applications that do exactly what computers are supposed to do; automate repetitive tasks. And this allows me to let a dedicated computer do the downloading, as it takes a lot of CPU and hard disk traffic to do the verifying and extracting.

Now this application has its drawbacks. It’s no longer under active development, not past 1.0 yet, and requires some very specific versions of certain Python frameworks. Although a convenient installer for Windows is provided, those on Linux may have a bit more trouble.

Yesterday I found a nice post on the Ubuntu forums which shows you how you can install SABnzbd in your home dir, along with all its dependencies, including Python itself. This is safer than installing those exact dependencies system-wide, and also a lot easier. It should also not be too hard to do this on other flavours of Linux.

I only experienced one minor problem when setting it up. When editing SABnzbd.ini, be sure to set all directories, and make sure the folders you enter actually exist.

There is one line you absolutely mustn’t forget to set:

## web file dir for (custom) Cheetah templates and the default.css file
web_dir = "/home/<USERNAME GOES HERE>/.SABnzbd/sabnzbd/templates"

Otherwise you’ll see a nice 500 error page, with no indication what’s wrong.

Have fun downloading!

Today I’m sharing with you some code snippets I find myself looking up often, because they’re important but I don’t use them frequently enough to remember them yet.

Often the default environment (development) suffices, but sometimes you need to run migrations, do a few things on the console or import data to a production environment with a script.

To run a migration:

rake db:migrate RAILS_ENV="production"

To open a console session:

script/console production

And to run a script:

script/runner -e production script.rb

All three have a slightly different way of specifying the environment, which is important to keep in mind. And obviously, you can replace “production” with whatever environment your application has available.

At my internship we use svn repositories with a /development and /production subdirectory. The /development directory is where all the programming happens, and anything in the /production directory gets sent to a production server after each commit.

Every now and then development has progressed sufficiently to warrant a new release to the production server. Here’s how I merge all the changes that have happened in the /development directory since the last commit in /production.

cd production
svn up

Note the revision number, 85 for example.

svn info

Note the revision number found under Last Changed Rev in the output. In this example, let’s say it’s 70. Also in the output you should find the URL to the repository. Now we can merge. Remaining in the /production directory, execute the following command:

svn merge -r 70:85 svn://server/repository/development

I’ve told svn to merge all changes from revision 70 through 85 in the directory /development from the repository svn://server/repository to the current directory.

All that’s left is to commit the files that have been changed/added/deleted, and we’re done.

As you may have noticed, the blog has changed a bit in layout. I’ve replaced WordPress with Typo, which is written in Ruby on Rails, a language I’ve been writing in for the last ten weeks at an internship. This will make it easier for me to tweak this thing when I feel like it.

Also, I’m going to blog differently. As you may have seen, I haven’t blogged a lot, each post took me about two hours; a bit too time-consuming for me.

Expect shorter posts with a lot less background information, and more to-the-point stuff.

SSH tunnels are encrypted "tunnels" between two systems running SSH (a client and server). This is achieved by setting up a port mapping in the client, for example port 12345 on the client is directly linked to www.google.com:80. When the tunnel has been set up, and I connect from the client to port 12345 on the client system, http://localhost:12345, the traffic is caught by the SSH client, encrypted, sent to the server, and the server then sends it to www.google.com at port 80 (the default port for HTTP).

This is useful in situations where, for example, www.google.com cannot be contacted due to a firewall. As long as you can still set up an SSH connection with a server, you can have the data traffic take a detour through the encrypted tunnel, and still gain access.

I use SSH to gain access to certain services in my home network which cannot be accessed directly from the Internet. Nearly all of these are on the same system as the SSH server, so the configuration can be a bit confusing. In order to gain access to the IMAP server running on my home server, I mapped client port 143 to localhost:143. If the SSH connection is running, I then point my e-mail client to localhost and port 143. The SSH client makes sure that all traffic from my mail client ends up going to the mail server on the same system as the SSH server.

SSH servers and clients are available for pretty much every operating system. Linux, Unix and OS X systems often have both a client and server installed, and sometimes it's already running. For Windows it's possible to run a SSH server under Cygwin.

Setting up a tunnel is pretty straightforward. I'm going to give examples for the popular Windows client PuTTY and the command-line client used in Linux, Unix and Mac OS X. I'm going to demonstrate a mapping that links the local port 12345 to www.google.com:80.

Start up putty and enter the server data in the first screen.

Next, enter your login data, go to Connection --> Data and enter your username in the box "Auto-login username".

Then navigate to Connection --> SSH --> Tunnels. In the "Source port" box enter the port number on the client you want to use. We chose 12345 so let's enter that. In the "Destination" box we enter www.google.com:80. You can leave the radio buttons as they are.

Then press the "Add" button.

At this point you might want to save your settings as a profile, so you can easily re-use them. Go to Session, enter a name for the session and press "Save".

Keep in mind that when you want to change the profile, PuTTY can be a bit confusing:

• Select the profile
• Press "Load"
• Change whatever you want to change
• Go back to the Session screen
• Press "Save"

It's very easy to accidentally press "Open", which will start a new session with the new settings, but it won't save them to your profile.

The final step is then to open a connection with the profile, and direct a browser to http://localhost:12345 and see what happens.

Doing the same with the command-line SSH client is done like so:

ssh user@ssh.example.com -L 12345:www.google.com:80

The -L option is followed by the local port, a colon, the destination system, another colon and the destination port.

Command-line SSH doesn't allow you to save sessions, but you can easily add it to a script or save it as an alias:

alias mytunnel='ssh user@ssh.example.com -L 12345:www.google.com:80'

Then you can just start the session with just mytunnel.

Further reading:

• Cygwin
• How to set up an SSH server on Windows
• PuTTY
• OpenSSH (popular client/server software for *nix)

1. Our/Are. Are is a verb, indicating action. Our is a posessive pronoun, indicating ownership. Depending on the accent used in English, you might pronounce these differently and notice right away.
2. Its/It’s. Its is a posessive pronoun, indicating posession. It’s is a contraction of “it is”. If you can replace it with “it is”, then you should use it’s.
3. Your/You’re. Like the above, your is a posessive pronoun, you’re a contraction of “you are”. If you can replace it with “you are”, then you should use you’re.
4. There/They’re/Their. There indicates a location. They’re is a contraction of “they are” and their is a posessive pronoun. If you can replace it with “they are”, then you should use they’re. To illustrate the other two: “Over there was their car”.
5. Plurals with apostrophies. The apostrophy is the character ‘, located two keys to the right of L on a QWERTY keyboard. It’s not the one in the top left of the keyboard. Neither are used in plurals. Period. This is especially confusing to foreign speakers like me, for whom the apostrophy in a plural is required in the mother tongue. The apostrophy + s is used as the “genitive s”, for example children’s books, Bob’s car and men’s wear. Note how it works in names which end in s: Chris’s bicycle. Dutch readers pay attention; this is different from how the genitive s works in Dutch.
6. Then/Than. Then is used when referring to a moment in time. Than is used when comparing. To illustrate: “Alice trained years for the race. Only then could she reach a faster time than Trudy”. There is also a subtle difference in pronunciation between then and than.
7. Witch/Which. A witch is a character often encountered in fairy tales. Which is used to ask someone to specify something, or to refer back to something mentioned earlier. To illustrate: A: “Which witch did you mean?” B: “The one riding the broomstick, which looked rather ridiculous.”

• 10 flagrant grammar mistakes that make you look stupid [zdnet.co.uk]
• Learn the finer points of punctuation [lifehacker.com]
• 100 Most Often Misspelled Words [yourdictionary.com]
• List of common misspellings [wikipedia.org]