Today was my first foray into electronics since high school, in the form of some simple Raspberry Pi experiments. I managed to get a circuit working where a switch controlled an LED with a potentiometer to control the brightness of the LED.

However, I am confused by the wiring of the switch. Firstly, here's a photo of my amazing work:



NOTE: the black lead on the potentiometer is not connected to anything (hard to tell in the photo). Also, I realised afterwards that I could have just inserted the potentiometer into the breadboard rather than soldering wires to it. Noob mistake (one of many).

Here's an attempt at a schematic (also probably wrong because I don't know what I'm doing):







simulate this circuit &ndash; Schematic created using CircuitLab

As you can see, I used a PiFace, which comes with the four switches located at the left and towards the bottom of the photo. It is the wiring of this switch that befuddles me. Since each switch has two terminals, I was expecting one terminal to act as an input and the other as an output. That is, I just feed my circuit through those two terminals and job done. But that didn't work.

I managed to find this image online:



This is what prompted me to guess the configuration below, which works. However, I don't understand why it works. Nor do I understand why there are two terminals for each switch if only one seems to be used. I suspect the clue is embedded within the text in the above image:


  The four switches, numbered S1 to S4 are connected in parallel to the
  first four (0-3) inputs


However, I do not understand what this means. Perhaps a practical example of how I would use each terminal and an explanation of why the grounding is necessary would help my understanding.


Question: When to use tools vs custom development?
Answer: The "buy vs build" decision comes down to a number of factors.  Can you maintain the tool that you are buying (even if it's open-source)?  Is there adequate support for it, if you run into a problem?  Do you have the resources to build it yourself, and are you smart enough to generalize it so it can be reused in a variety of scenarios?  And so on.

Regarding dependency injection: DI containers are not needed for most applications.  Unless your application is a large, enterprise-type application, you don't need a DI container, and if you do need one, there are a number of containers already available that would serve the purpose well. 

Smaller applications benefit more from a simpler form of DI, like injecting your dependencies directly through the constructor methods of your objects.  You would only use a DI container if you needed to provide a central place to manage your dependencies in, say, an XML file describing them.

In the vaguest of terms, there is a "rule of three." If you find yourself doing the same thing three times in a software application, you either refactor it into its own tool or method, or find an off-the-shelf tool that replaces those three things with one generalized thing.  Knowing when to do this comes with experience.