How to make Windows 10 usable

[Updated 12/31/2018]

Recently I upgraded my computer to Windows 10.  Microsoft, for whatever reason, with every release of Windows completely changes things.  For no good reason they move stuff around and change things that weren't broken.  So here is a guide on how to make Windows 10 more like Windows 7, which makes Windows 10 usable.

• When installing Windows 10, if you have the choice select Windows 10 Enterprise.  Enterprise is nice because it does not come pre-loaded with all the Windows Store Apps that Home and Professional do.  So out of the box it's closer to Windows 7.
• Download and install Open-Shell (formerly known as Classic Shell).  Windows 10 does include a "start menu" which was removed in Windows 8, but it's no where near as good as the start menu in Windows 7.  Open-Shell restores that start menu in all its glory.  In fact, Open-Shell is even better than the Windows 7 start menu and works on Windows 7 too!  Spend a few minutes exploring all the settings in Open-Shell, you can customize it exactly how you want it.
• Download and run OldNewExplorer.  This extension fixes Windows File Explorer to the look and feel more like Windows 7.  When you run OldNewExplorer, click "Install" and then select the options you want.  Here are my settings:

• Download and install Explorer++.  Even though OldNewExplorer fixes much of the Windows File Explorer, it's still not as good as the Windows File Explorer in older versions of Windows.  That's where Explorer++ comes in.  This open-source program is a very good file manager.
• Download and install FileLocator Lite.  This program is free for personal use and it's a very good Windows file search program.  The file search in Windows 7/10 is horrible compared to Windows XP.  FileLocator Lite restores that Windows XP style search.
• Download and install Process Hacker.  Although Task Manager in Windows 10 isn't that bad, they did still change it from Windows 7 and I preferred the simple process view.  Process Hacker is a great open source tool that is very configurable.  It even has an option to replace the built-in Task Manager for keyboard and mouse shortcuts.  If neither the Windows 10 Task Manager nor Process Hacker work for you, give Process Explorer (also from Microsoft) a try.
• Windows 10, more than any previous version of Windows, sends a lot of data back to Microsoft.  Data like which apps you use, how long you use them, what websites you visit.  It even downloads data from Microsoft such as ads to display in Windows.  A program called ShutUp10 allows you to turn all this off if you want.  You can turn some things off and leave other things on.  I always run this on new Windows 10 machines.  I personally don't turn off all settings, some things like Windows Update I leave enabled.  But ShutUp10 does a great job of explaining each setting and even gives their recommendations as to enabled or disabled.
• If you want a "pure" desktop environment, remove as many of the Windows Store applications (formerly called Metro-apps) as you can.  This can easily be done using the following PowerShell script.  This script will remove all packages except A) those packages deemed by Microsoft to be required and thus cannot be uninstalled using any technique and B) the "Windows Store" package.  Strangely the Windows Store package is not marked "required" but if you remove this package you cannot install Windows Apps in the future if you want to.  Best to play it safe and leave this one package installed.  Save the following script as "RemoveApps.ps1" then run PowerShell as an administrator.  Then run the script.  If this is the first time you've run a PowerShell script on your system you might get an error.  If so, run this command "Set-ExecutionPolicy RemoteSigned" to allow the script to run.  Note, after you run this script there may still exist some Windows apps in the start menu, annoying things like "Candy Crush."  That's because these apps aren't actually installed, the Windows start menu puts them there as advertisements.  If you click on them the app is downloaded and installed.  You can right click and uninstall these annoying advertised apps.

# RemoveApps.ps1

$storepkg = (Get-AppxPackage Microsoft.WindowsStore).PackageFullName

$pkgs = (Get-AppxPackage *).PackageFullName
foreach($pkg in $pkgs)
{
    if($pkg -ne $storepkg)
    {
        Remove-AppxPackage $pkg
    }
}

$pkgs = (Get-AppxPackage -AllUsers *).PackageFullName
foreach($pkg in $pkgs)
{
    if($pkg -ne $storepkg)
    {
        Remove-AppxPackage -AllUsers $pkg
    }
}

• Right click on the start menu and remove Task View and Windows Store.
• Right click on the start menu and select Search | Hidden to hide the Cortana search bar.
• Select Settings | Personalization | Colors | and enable Show Color on Title Bar.  This adds color back to the application caption bar instead of the default plain white bar.
• Inactive windows in the background still have a white title bar.  Adding color to this helps it to stand out as a background windows.  Open regedit and browse to HKCU\SOFTWARE\Microsoft\Windows\DWM.  Create or edit the DWORD value AccentColorInactive.  Set it to the hex value for the color you want, e.g. 00c0c0c0 for 192 192 192 (light gray).
• Add my computer and network links to the desktop by selecting Settings | Personalization | Themes | Desktop Icon Settings and enable Computer and Network.
• Disable that annoying lock screen which forces you to "swipe" to login (which is annoying for keyboard and mouse).  Open the registry editor and ensure the following key and value exists:  Key: HKLM\SOFTWARE\Policies\Microsoft\Windows\Personalization  Value: "NoLockScreen"  Type: DWORD, set to 1.  Update:  I have noticed not all versions of Windows 10 will honor this registry key, in particular Windows 10 Home and especially newer updates.  But after much trying I got this to work, even on Windows 10 Home Creators Update.  In addition to this registry key, you need to make a Group Policy change.  The trick is, Windows 10 Home does not include the Group Policy Editor, so you need to install that.  This website has a batch file you can download and run that installs the Group Policy Editor.  Then run gpedit.msc and browse to Computer Configuration | Administrative Templates | Control Panel | Personalization.  Find "do not display the lock screen" and change it to "enabled."  If you try and that and it still doesn't work, here's one final thing to check.  Browse to (or create if missing) the following registry key: HKLM\Microsoft\Windows\CurrentVersion\SystemProtectedUserData\<SID>\AnyoneRead\LockScreen.  There should be a DWORD registry value "HideLogonBackgroundImage" and set to 1.  Note, this last registry key is a system-protected registry key, you'll need to take ownership of the registry key in order to change the value.
• If you try and copy files to/from your Windows 10 machine using the admin shares, you might get access denied even when you enter valid credentials.  To fix this, open the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System then create a DWORD value "LocalAccountTokenFilterPolicy" and set it to 1.

These steps make Windows 10 very usable.  In fact, with these changes I think Windows 10 is better than Windows 7.  But without these changes Windows 10 is hard to use and navigate.

C++ Programming Tips

For 2 decades now I have been a professional C++ developer.  Along the way I have learned a lot about programming in C++.  I've made a lot of mistakes and learned from them.  There are thousands of other C++ developers out there of all skill levels who could benefit from this knowledge.  So below is a list of tips I've learned that will help you to write better C++ code.  For each tip I include a brief explanation why that tip is worth remembering and using.


Consistent Coding Style

Every developer has their own coding style.  I'm not going to tell you to use one style over another.  But it is important that you are consistent in your coding style.

Reasoning:  If you are consistent in your coding style it makes things like global searches more effective.

Virtual Destructors

Always make your class destructors virtual.

Reasoning:  Without virtual destructors you can introduce bugs and memory leaks.  I wrote an entire post on this topic alone.  There is one exception.  If your class has no other virtual functions, and if your class does not derive from a base class, and if you mark your class "final" then you can safely omit the virtual destructor.

Const Function Parameters

Whenever possible, function parameters should be made "const."  If a given parameter is not modified by the function, then the parameter should be marked const.

Reasoning:  It's great self-documenting code.  Just by looking at a function declaration you can tell if a parameter will be modified.  It also can help you catch bugs in your code because the compiler may warn you if you accidentally try to violate the const variable.

Const Member Functions

Whenever possible, class member functions should be marked "const."  If a given function does not modify a class member variable or call another non-const member function, then the function should be marked const.

Reasoning:  It's great self-documenting code.  Just by looking at a function declaration you can tell if the class object will be modified.  It also can help you catch bugs in your code because the compiler may warn you if you accidentally try to violate the const function.

Static Member Functions

If a class member function does not modify a class member variable nor call a non-static member function, then that function should be marked as "static."

Reasoning:  Again, it's great self-documenting code, and it can help you catch bugs in your code because the compiler may warn you if you accidentally try to violate the static function.

No Classes without Member Variables

If you have a class that has no member variables, instead turn that class into either standalone functions or use a namespace to group the functions.

Reasoning:  A class with no member variables is not an object at all.  By using a class you are wasting a small amount of runtime memory because of things like the "this" pointer.

Properly Size Integers and Floats

When declaring a new integer or (to a lesser degree) a float, consider the range of possible values for that integer and choose accordingly.  For example, if the variable will store a person's age then all you need is an 8-bit integer, don't just type "int" and be done with it.

Reasoning:  Choosing properly sized variables will help to minimize memory usage during runtime.

Use Signed and Unsigned Integers Appropriately

Most developers seem to use signed integers when an unsigned integer is what they really should have used.  For example, a variable to hold a percentage should be an unsigned 8-bit integer since the valid range is 0 - 100.

Reasoning:  If you properly use signed and unsigned variables, the compiler will usually generate warnings if you try and improper operation.  This helps to prevent bugs in your code.

Use Pre-operators Instead of Post-Operators

Whenever possible use pre-increment (++itr) and pre-decrement (--itr) instead of post-increment (itr++) and post-decrement (itr--).

Reasoning:  It turns out that pre-operators are faster than post-operators if the object in question is a class.  For simple data types like integers there is no difference.  The reason pre is faster than post is because post must make a copy of the original object before performing the operation, but pre does not need to make a copy of the object.

Avoid Large Array Variables

Do not declare large array variables, for example:  char buffer[8192].  Instead large arrays like this should be allocated using malloc/new.

Reasoning:  All function variables, include arrays, are allocated against the stack not the heap.  It's well known the dangers of using a recursive function, you might blow the stack.  But large arrays like this could also lead to a stack overflow.  So avoid large arrays and malloc/new them instead.  It's alright to use small arrays in this way.

Use "bool" and "nullptr" instead of "BOOL" and "NULL"

If your compiler supports them, then use the newer data types bool and nullptr.

Reasoning:  By using native types instead of the older #defines the compiler can help you to catch mistakes.  For example, if you accidentally type the following the compiler should give you a warning: bool bResult = (n = 5);  You meant to type "n == 5" but make a common mistake.  Since you used "bool" the compiler should catch this.  But if you used "BOOL" the compiler sees this as valid code.

Don't Compare Against TRUE

Do not test for true like this:  if(func() == TRUE) or this:  if(func() != TRUE)  Instead test like this:  if(func() != FALSE) and this:  if(func() == FALSE)

Reasoning:  "TRUE" is defined to be 1, but a function could return something other than 1 to represent true.  The only way to guarantee a correct comparision is to only test against FALSE.  Of course the best option is to use the newer native type "bool" if it's available.

Use malloc/free Instead of new/delete for Simple Types

If you are allocating memory for native types (ints, floats, chars, enums, or structs containing only these types) then use the older C malloc instead of the newer C++ new.  If you are allocating memory for a class object, or a struct containing one or more class objects, then you must use new.

Reasoning:  Calling malloc is faster than new.  They both allocate memory on the heap, but new then checks for and calls constructors.  This means for simple data types malloc is faster.

Do Not Test for NULL After Calling new

If you allocate memory with new, do not test the result to verify the allocation was successful.  For example:

CMyClass *p = new CMyClass;
if(p)
{
     ...
}

Reasoning:  This test is a complete waste of time and code.  The new operator already tests the allocation.  If the allocation fails then new throws an exception.  So testing the result yourself is redundant and a waste.  Note this is not true of malloc which does not test the result.  So if you use malloc or other similar allocator, be sure to verify the result.

Know When to Test for NULL Before Freeing Resources

Some release/free functions test the input before attempting to deallocate them, others do not.  For example, CloseHandle on Windows does not test the handle against NULL first.  On the other hand, "delete" does test the pointer against NULL.

Reasoning:  Not testing first may result in an application crash if the release function does not check.  If the release function does check and your code also checks, that is wasted CPU cycles.  Learn which functions to check first before calling.

Size Versus Length

When naming things like functions and variables, be aware of the difference between size and length.  Size is the number of bytes an item requires whereas length is the count of or the number of items.  This is really a problem when it comes to strings (character arrays).  With "char" arrays size and length ARE the same, so many developers use "size" and "length" interchangeable.  But with newer Unicode and wide strings size and length are different.  So name functions and variables accordingly.

Reasoning:  Properly named functions and variables reduce the chance of bugs.  Since size and length are not always the same, using the wrong one would be a bug.

Do Not Put Conditional Statements on One Line of Code

Do not simplify your code by condensing things down to one line of code.  For example:

if(p) delete p;

Instead this should be:

if(p)
    delete p;

Reasoning:  When you condense code like this it makes it harder to debug.  When debugging line by line it is harder to tell if the conditional statement succeeded or failed.

Do Not Use "catch(...)"

Never use "catch(...)" in your code!  This form of exception handling catches all exceptions.

Reasoning:  Catching all exceptions prevents your code from ever crashing, which is a good thing right?  Wrong.  In the event of an exception your code continues to execute but it is now running in a "compromised" state.  Memory may be corrupted, variables or registers may be wrong.  So what ends up happening is your program will crash randomly some place else.  These random crashes are impossible to debug postmortem.  It is best to remove "catch(...)" and let the original crash occur.  Then you can debug and fix the original problem.

Do Not Use Exceptions for Flow Control

Do not use exceptions as a simple way of transferring flow to a different part of the code.  For example, if you are deep inside nested loops and it's time to exit, you could throw an exception and catch that exception before leaving that function.  Instead you should exit each loop or even use a goto.

Reasoning:  When it comes time to debug your code often times it's nice to attach the debugger and tell the debug to break on all exceptions (handled or otherwise).  But if you used exceptions for flow control then the debugger will constantly break when no problem has occurred.  Exceptions should be reserved for just that, an exceptional condition has occurred that needs special attention.  Flow control is not "exceptional."

Only Include Required Files in Your Headers

Do not #include a lot of extra things in your header files.  Only include what that file must have.

Reasoning:  First, it reduces compile time as the compiler has to open up and parse fewer files.  Secondly, if that file gets included somewhere else or in another project, it prevents you from having to pull in a lot of extra unnecessary files.

Forward Declare What You Can in Header Files Instead of Including More Headers

If your header file references a pointer to a class object only, do not #include the header for that class.  Instead forward declare the object and put the #include into the CPP file.

Reasoning:  The benefits are the same two as the previous.  First, it reduces compile time as the compiler has to open up and parse fewer files.  Secondly, if that file gets included somewhere else or in another project, it prevents you from having to pull in a lot of extra unnecessary files.

Only Include Required Files in Your CPP File

Do not pull in extra unused headers in your source code files.  Make an effort to only include required files, which means removing old headers as code changes over time.

Reasoning:  It reduces compile time as the compiler has to open up and parse fewer files.

Avoid Putting Function Bodies Into Header Files

Header files should be for class and function declarations.  All the function bodies should be located in CPP files.  There are two exceptions; inline functions and templatized functions - both of which many compilers do not allow you to split them across header and source code files.

Reasoning:  Again, it decreases the time it takes to compile your code.  It also simplifies your headers meaning you do not need to pull in as many files if the header files are used in another project.

Use "#pragma once"

In all of your header files use "#pragma once" and not the older #ifndef guards.

Reasoning:  Using pragma once is the only way to guarantee a file is included only once.  Problems can occur with guards such as copy and paste bugs (you copied from one file to another and forgot to make the guard unique).  Also, if your guard matches a guard from another file (perhaps from an SDK) then a bug might occur.

Beware of Unsafe Macros

As a general rule, do not pass a function into a macro.  For example, assume a macro MAX(a,b)  Do not do something like this:  n = MAX(1000, crypt.CalcCryptoHash());

Reasoning:  Do you see the problem with the call to MAX above?  Probably not, because the macro hid the details from you.  If I expand the macro as the compiler would, the above becomes:  n = (1000 < crypt.CalcCryptoHash() ? crypt.CalcCryptoHash() : 1000) ;  Now the problem should be obvious, the function CalcCryptoHash() is potentially called twice.  At best this is a performance hit, at worst depending on what this function does it could be a bug in your code.  So be careful when using macros.

Learn When and Where to Use References

If you are writing a function that takes a pointer (*) as an input, consider using a reference (&) instead.  In fact, probably the only time to use pointer instead of a reference is if the caller of the function might pass in NULL/nullptr.  But if the parameter can never be NULL/nullptr, then use a reference instead.  Also, if the item being passed to a function is an object (class or struct) or even a native type that is larger than the system architecture (e.g. a 64-bit integer on a 32-bit system) then pass by reference as well.

Reasoning:  References are more efficient and make for cleaner code compared to regular pointers.  When passing things by reference it becomes even more important to use "const" for variables the function will not modify.

Raspberry Pi Weather Station - part 4

In the last post I covered the hardware for the sensors.  In this post I want to talk about the software that ties this all together.  There are several goals with the software.  Obviously it needs to read the sensor data.  I would like it to output that data to a local web page so I can access it with a web browser.  I also want it to export the sensor data to a Personal Weather Station (PWS) account registered with WeatherUnderground.  And lastly, I would ideally like it to record or save the data to a database in case I want to analyze the data later on.

Doing searches on the Internet I quickly found WeeWX, an open-source project that does all of this.  It reads sensor data, generates a web page, and can optionally log to WeatherUnderground.  I was ready to go with this option, but then I discovered it was written in Python which gave me pause for concern (more on that later).

I next found wview which, like WeeWx, is an open-source weather station project.  It's written in C which is good, but it sounds like the project has grown rather large over the years.  It's become a huge behemoth that's capable of doing almost everything when all I want/need is a simple targeted application.

In the end I decided to write my own weather station application.  After all, isn't that was software engineers do, write software?  I wrote a small simple program that reads all the sensors and outputs the data in 3 different ways.

1. It generates a local HTML file which can be viewed from another computer using a web browser.  My code is not a web server, it just outputs an HTML file.  So you still need a web server such as Lighttpd or nginx.
2. It sends all sensor data off to WeatherUnderground so the results can be viewed on their web site.
3. The sensor data is written locally to a SQLite file for later analysis.

I wanted to go back and talk about my opposition to the use of Python in WeeWX.  The main problem is I do not consider Python to be a "real" programming language.  It is a scripting language, and scripting languages have their place.  But not in final applications in my opinion.  I also do not like the extreme performance hit Python incurs.  And remember, this is running on a Raspberry Pi which is not a powerful machine to begin with, so any unnecessary overhead is exaggerated.  How much of a performance hit are we talking about?  Using the sample Python code from Adafruit, reading the temperature sensor takes approximately 5 seconds.  Most of that overhead is spent loading the Python libraries and creating the runtime environment.  Compare that to the C++ code I wrote to read the temperature sensor which is instantaneous.  To me writing this application in C++ was not only the only way to go, but it was a fun project!


I have uploaded my C++ code to GitHub for anyone to download, use, or modify.  Bear in mind this code was written specifically for my weather station.  So it assumes the sensor hardware I'm using connected to the Raspberry Pi on the GPIO pins I'm using.  But this could be a great reference for anyone doing a similar project.

And finally, the results.  Here's a link to my PWS on WeatherUnderground.

Raspberry Pi Weather Station - part 3

Next I wanted to talk about the hardware for the sensors my weather station will employ and how each sensor is wired to the Pi's GPIO pins.

BME280
As I previously said the BME280 can be access via either SPI or I2C.  I decided to use I2C.  In order to wire to the Pi you will need to connect 4 wires.  The first is the power wire which connects to the 3.3V pins on the Pi.  The second is ground which connects to one of the ground wires on the Pi.  And lastly are the two I2C data lines which get connected to the I2C pins on the Pi.  Wiring this sensor up is not hard, it just requires a little bit of soldering and time.

The rain, wind speed, and wind direction sensors were a single package and clearly not designed specifically for the Pi.  The output wires have RJ11 connectors (telephone connectors) on the end of them.  I believe they were originally designed to plug into a specific weather module that reads the sensors.  Since I am using the Raspberry Pi as my homemade weather module, I will need to modify each sensor.

Rain Gauge
The rain gauge is an interesting sensor.  It literally has two buckets side by side.  When one side fills with water it gets too heavy and tips over.  The other side then fills up and eventually tips back.  Each time this bucket tips over a magnet passes by a reed switch.  This causes a momentary close in the switch which can be detected by the Raspberry Pi.  This only requires 2 wires, power in and the signal detect line coming out.  For power in I used the same 3.3V pin as the BME280 sensor, and for the signal wire I picked any available GPIO pin.

Wind Speed
For wind speed there are 3 cups that are free to spin as the wind hits them.  Each time it spins another magnet passes by a read switch.  As with the rain, the Pi can detect these events and use that to calculate the wind speed.  Again, only 2 wires are necessary, one for power (the same 3.3V pin) and a signal detect line which is any available GPIO pin.

Wind Direction
The wind direction sensor works using magnetic reed switches, but unlike the previous sensors it contains 8 reed switches.  Each reed switch corresponds to a direction; N, NE, E, SE, S, SW, W, and NW.  As the magnet moves around according to wind direction it closes different switches which allows you to determine direction.  To complicate matters, it is possible for the magnet to close two neighboring switches at the same time.  This gives you a total of 16 possible bearings.

Reading the wind direction was by far the hardest.  The problem is the wind direction sensor is designed to be read using analog and only has 2 wires, power in and signal out.  So if you apply 5V in then the output voltage will be one of 16 different values between 0 and 5V.  The Raspberry Pi however cannot read analog values, it only reads digital signals.  One possible solution is to use an analog to digital converter which requires additional hardware.  But there is a cheaper way, hard wire the 8 reed switches directly to the Pi.  To do this I had to open the wind direction sensor and remove the circuit board.  On this circuit board are 8 small surface mount resistors which had to be desolder.  In their place I soldered 8 wires, one for each switch.  Lately I soldered a power wire to the outside ring which ties all reed switches together.  This allows me to provide power in (again, 3.3V) and read each sensor one at a time using the 8 signal wires I attached to available GPIO pins.  This required a lot soldering on a small circuit board, but the end result is a digital wind direction sensor that was originally designed to be analog.

Raspberry Pi Weather Station - part 2

Continuing this project, in this post I will talk about preparing the Raspberry Pi to become a weather station.  I won't go into the details about installing Raspbian onto the SD card or using raspi-config to set the time zone and locale info for your system.  You can read my previous Pi posts for those details.

For this project the Raspbian group has released something new - a "lite" version of Raspbian.  This is perfect, I can get a clean bare bones Pi right out of the box.  Getting wifi setup on the Pi zero is a little more complicated because there is no ethernet port.  So it's a multi-step process.  First you must use a keyboard and monitor and manually edit the /etc/wpa_supplicant/wpa_supplicant.conf file to add info for your wifi network.  Then power down the Pi, remove the keyboard and monitor, attach the wifi adapter, then power up the Pi and connect via SSH.  This is where I ran into my first problem.  The RNX-N180UBE I've used in the past and ordered for this project did not work.  I quickly discovered Rosewill is now making "version 2" of the adapter which uses a different chipset and Linux does not have drivers for this adapter.  After much searching I found this forum post with details on where to download drivers specific to the type or Raspberry Pi and version of Raspbian you are running.

For the BME280 sensor I bought, it can be accessed via SPI or I2C.  The Pi supports both, but is one better than the other?  From what I can tell, SPI is a faster connection, but I2C is a better designed interface with more control.  Since reading this sensor won't involve large amounts of data, I decided to go with I2C.  But in order for this to work you need to enable the I2C bus inside of raspi-config.

Another step was to solder in the header to the Pi Zero.  This isn't hard, and in fact it's kind of fun.  But if your soldering skills are lacking then save yourself the trouble and use a Pi 1, 2, or 3.

Raspberry Pi Weather Station - part 1

My latest Raspberry Pi project is a home weather station.  My original goal was a have a useful set of sensors connected to the Pi, and to make the results accessible over the Internet.  That said, this process took several twists and turns along the way, probably because there are fewer people out there doing this type of project than say my previous projects of a homemade DVR or home theater.  This project, unlike my previous Pi projects, is less a step-by-step guide.  This is for several reasons.  First, this project morphed and changed several times so it was harder for me to document as I went.  And secondly, I had less free time to work on it, so I gave up on documenting while I worked.

When I decided to make a homemade weather station, I wanted to do as much "homemade" as possible.  So all my sensors are connected to the Raspberry Pi's GPIO pins.  The more common solution for people is to buy an off-the-shelf weather station and connect that to the Raspberry Pi's USB port.  I purchased all the hardware necessary for this project (more on that later) before I even knew how it would fit together.  I just had faith it was possible to do what I wanted to do.  The major missing link was the software.  I did not know how to read the sensors and display it meaningfully.  And it was researching the software solutions available is where this project deviated from my initial thoughts.  But I'll get into all that in a future post.  First let's look at the hardware I used.

Raspberry Pi Zero:

For this project I went with the new Raspberry Pi Zero.  Any Pi would do, but I chose the Pi Zero for several reasons.

1. The smaller size, so the weatherproof enclosure doesn't need to be as large.
2. The extremely low-power consumption.  As a weather station this won't need the processing power of the Pi 2/3, so save on electricity use.
3. It's new and cool.  I've worked with the original Pi and the Pi 2, so this was something new to try.

However, working with the Pi Zero did have several drawbacks.  First and foremost was obtaining the Pi itself.  Pi Zero's are in VERY short supply and hard to get.  It took 2 weeks of waiting for Adafruit to get a shipment in before I could order one.  And even then, they only sold the Pi Zero in a "kit" with other things I didn't need like power supply, memory card, USB adapters, etc.  Another issue with the Pi Zero is you have to manually solder the header connector onto the Pi.  I like soldering so this was no problem for me, but others might find the regular Pi models more appealing since the GPIO pin headers are soldered on at the factory.

Temperature / Humidity / Pressure
For basic atmospheric measurements I went with the Adafruit BME280.  This sensor measures temperature, humidity, and pressure.

Wind / Rain
For the final set of sensors I went with the SparkFun weather sensors.  These sensors measure wind speed, wind direction, and rainfall.  But at $77 they are by far the most expensive item in this build.

Miscellaneous
To complete the project I needed a bunch of smaller items.  I bought a Samsung Pro micro SD card because it's one the fastest cards available and I've had good luck with them in the past.  For wireless I went with the Rosewill RNX-N180UBE.  For power I selected an Anker wall charger (I selected a dual-port model because this single charger will power a couple of my Raspberry Pi's) as well as a 10' long Anker power cord.  Lastly I purchased a waterproof electrical case at Home Depot originally designed for running conduit outside, but houses the Pi nicely and has openings on the bottom where I can run wires into the housing.

Programming Languages

As a computer programmer the language I prefer to program in is obviously an important subject.  In my opinion C/C++ is the best all-around programming language.  When I was learning to program in the mid '90s, C/C++ was the undeniable king of programming languages.  However, in the time since then I feel like the industry has moved away from C/C++ to the point where some developers consider me to be a "dinosaur" for using such an old language.  But I don't think I'm a dinosaur, so I wanted to talk about languages in general and defend my preferences.

There are literally hundreds if not thousands of programming languages.  If you're learning programming for the first time or if you're starting a new project, how do you know which language to select?  Programming languages breakdown into 4 categories; 1 low-level category and 3 high-level categories.

Assembly:
Assembly is the only low-level language where the developer writes code targeted at a specific hardware platform.  Whereas hand-written assembly can be used for general purpose programming, it's very difficult to manage and nowadays assembly is mostly reserved for very specific cases, typically firmware and embedded programming systems.

Native Machine Languages:
Native machine languages are high-level languages that are compiled to target a specific platform.  That is to say, if your code will run on different platforms you must compile your code once for each platform it will run on.  This category includes languages like C/C++, Pascal, Fortran, Cobol, and Ada.

Virtual Machine Languages:
Virtual machine languages are similar to native in that they are compiled.  But the output is not hardware or platform specific.  Instead the output is "virtual" machine code that must be converted at runtime to the native machine code for the platform where your code is running.  The benefit is the developer compiles once and releases a single binary, but it can run on multiple platforms.  This category includes Java and C#.

Interpreted Languages:
Interpreted languages (often times called scripted languages) are not compiled.  Instead at runtime a program called the interpreter converts the code from human-readable to machine code.  Interpreted languages have the benefit of not needing the slow compilation process and can be quickly changed or tweaked.  This category includes Python, Perl, PHP, Javascript, Ruby, and many more.


So how do you pick a language?  What is the best programming language?  Well, the answer is the right tool for the right job.  All languages have pros and cons, so picking the best language requires an understanding of those.

Skipping assembly, because it's not really general purpose in today's world, let's talk about interpreted languages first.  I might take a lot of flak for this, but I don't consider interpreted languages to have much use outside of academia.  Interpreted languages are perfect for learning the basics of programming.  Because these languages don't require the developer to think about things like variable types, memory management, strings, etc. they allow the person to focus on learning the basics of programming.  After all, pilots don't fly a 747 as their first plane, they start on small propeller planes.  To me the only use for interpreted languages is when used as a scripting language to speed up tasks and eliminate human errors.  For example, say an IT person needs to create a new user account, add a machine to the domain, and assign that user to the machine.  This is a perfect task for a scripting language.

But languages like Javascript, Python, PHP, and Ruby are some of the most popular programming languages, so what's wrong with these languages?  The problem is speed and efficiency, or lack thereof.  Because these languages are interpreted at runtime there are significantly slower than other languages.  A recent comparison found these languages can be as much as 400x slower than a natively compiled program.  Probably a good rule of thumb is expect between 10x and 100x slower performance compared to natively programs.  That is a huge price to pay.  I'm dumbfounded that so many server applications are running in languages like Javascript.  That's like entering a car race with a bus.


Ok, so that leaves us natively and virtually compiled programs.  Here too native programs have the performance advantage, although it's much less pronounced.  A recent study found that on average C/C++ outperforms Java/C# by 20%.  On the flip side, Java/C# can be faster and easier to develop in compared to C/C++.  For many software companies, their highest cost is developers' salaries.  So picking Java or C# may result in quicker development times which results in lower development costs.  This all assumes your application is not performance critical (which most client/desktop applications aren't).

However, there is another side to the equation which developers rarely consider.  If your application runs on the server side, that extra 20% performance increase by going with C/C++ translates directly into 20% less electricity used by the servers.  It also means less electricity for cooling the server room which saves even more money.  When you start talking about applications that run on servers, suddenly the hardware for those servers, electricity used to run those servers, and the cooling costs for the servers outweighs development costs.  So in cases like this a native language is probably your best choice.

There is another benefit to native languages - extended battery life.  In that same study above, they found that C/C++ programs ran for approx. 20% longer on a given battery charge compared Java/C#.  So anyone developing applications that will run on a laptop, tablet, or phone should seriously consider a native language.

It is true that C/C++ is not the king it once was.  However, when you group C/C++ together it's still the number 1 programming language ahead of Java.  Also, any programming field where you need performance (e.g. video games) then C/C++ is the language of choice.  Yet another example is operating systems.  Every major operating system in existence is written in C - which includes Windows, Linux, Mac, Unix.  Even "mobile" operating systems like Android are built on top of Linux which is written in C.

So without a doubt C/C++ has a place in the modern world.  I think it's unfortunate that so many developers have gotten caught up in the virtual and interpreted language hype and forgotten about the power of a native programming language.  That said, recently there has been a resurgence in native programming languages driven largely by mobile devices with their relatively low resources and battery power, they are the perfect platform for a native programming language.