A New Home for the PC

Whilst moving from an FX-6350 to Ryzen 2600, I couldn’t help but notice how poorly designed my case was. Sure, there’s a great need for aesthetically pleasing units and there’s a wide selection available, but let’s have a reality check.

As do many, budgeting on the case and PSU (as did I in 2016) for better hardware could be problematic. With cheaper cases, the choice is limited and picking the best unit for your needs might take a bit more time than simply adding one to your basket that meets the budget.

Changes in modern case design are a lot more noticeable for those used to having a “drive rail” at the front of the case and is worth understanding what has changed from the “classic layout”. Let’s explore this further.

ODDs

ODDs (optical disk drives) are less likely to make an appearance then maybe 10 years ago. This might be because flash media is smaller, less noisy, more efficient and can be supplied whilst buying Windows. Also, games aren’t bought on CD or DVD anymore and are usually downloaded straight from the source.
This conclusion has allowed the limitation or in some cases (no pun intended), the complete removal of ODDs completely in Mid-Towers.
Full towers still have plenty of bays.

Storage

Before SSDs became mainstream, the standard storage unit fell to hefty 3 ½” HDDs. SSDs are now considered to be mainstream and usually found in smaller sizes: 2 ½” and M.2 and of course the less-seen size in the form of a PCI-e card.
Like ODDs, the 3 ½” drives are just about hanging on with at most a couple of spaces dedicated for the larger HDD. There’s more room now dedicated for SATA 2 ½” SSDs because of their form factor in Mid-Towers.
Full Towers usually have plenty of space for HDDs and are worth considering if you need space for your RAID 5 array.

PSUs

This may be a little odd but there are some points worth mentioning. Modern Mid-Towers tend to position the PSU on the bottom of the case. There are a few reasons for this which are helpful to understand.

  • The weight is closer to the ground, and this is important in the reduction of unit being “top-heavy”
  • A dedicated ventilation grill for the PSU that isolates the airflow through the PSU to the rest of the system.
  • Modular PSUs can be helpful in cable management by reducing unnecessary plugs or cables.

Cable Management

Cable Management is an aesthetic “nice to have” but can play an important role during maintenance and any more adding/removing hardware. I also realise that it can help to reduce dust settling on meters of cable. As I like to think of it, keeping your workspace clean and tidy allows you to work more efficiently. The same can be said whilst maintaining your system.
A well-managed case is heavily dependant on the design. This is achieved with:

  • Space behind the rear access panel for cables
  • Space around the PSU for tucking away lengthy cables
  • Access points around the motherboard for cables to connect from behind the motherboard tray, such as front I/O headers and SATA connectors.

GPUs

GPUs have grown in size and is worth making sure that the card you are buying/have will fit. Usually, case manufacturers are good at letting you know the maximum length of the card that could house.

Also, think about future upgrades and expansions; it could be worth finding the size of the largest GPU and seeing if it will meet the specifications to be better suited for years to come.

CPU Coolers

Many budget coolers are quite tall and you’ll want to be sure it will fit. Again, most good case manufacturers will note the maximum height of the cooler for the case and could impact your buying decision.

Front I/O

USB-C is still quite a way off from being mainstream, but it could be worth looking into, even if your motherboard doesn’t currently have an I/O header for it. If you use USB frequently, having a nice choice of USB2 and USB3 interfaces on the front can be a deal maker. If you are into photography or use SD often, card readers integrated to the case isn’t too uncommon.


Everyone is different and has different needs and tastes. Doing the research properly will allow for a better-equipped case for your needs, and may help you decide about the cooler you buy!

A case can (and should) last longer than the original hardware that it originally intended to house and being clear on current hardware trends can future-proof your purchase, even if it is bought to a budget.

Buying correctly will not only cut down on e-waste but will save your future-self some money too.

Python3: Getting Weather Conditions Through API

For a project, I wanted the current outside temperature for my local area. For different reasons, I decided on an external choice but mainly because it would be more accurate then dangling a temperature sensor out of the window!

I will walk you through the steps of building your own API calls in Python3.

The API

There are many different API’s out there in the wild, some premium and some entirely free. I stumbled upon a site called https://openweathermap.org/ which has free limited access or the option for a more powerful premium service.
Currently, the accounts have a limit of 60 per minute for their Current Weather API which is well within my needs (1 call per 15 minutes), so I chose this one.

After signing up for a free account, (you do not need to supply a payment method), you are able to create an API key for your app. There should be one already made by default, which I just changed the name of to my current project.

Requests

Once you have an API key for your project, you might need to wait for it to activate but it should be ready to use fairly quickly. You are now ready to start building your request!

To make the API request over http, I used the powerful requests library which makes this job more “pythonic” and easier to work with then the standard urllib.

Installing requests is easy with pip:

pip3 install requests

Now we can start building our API call. In a new .py file, add the following.

# requests docs : http://docs.python-requests.org/en/master/user/quickstart/
import requests

def main():

    # define the GET string for the Http query
    payload = {
               'q': 'London,UK',  # q is the place name for your query
               'units': 'metric',  # units is the unit of measurement
               'APPID': 'YOUR_API_KEY_HERE',  # APPID is for your app's API key (keep secret)
              }

    # The URL for the current weather API call
    # (full docs here: https://openweathermap.org/api)
    api_url = 'https://api.openweathermap.org/data/2.5/weather'

    # make the API call with defined parameters
    query = requests.get(api_url, params=payload)

    # convert raw json response to a python dictionary with json()
    data = query.json()

    print(data)

if __name__ == "__main__":
    main()

In the payload dictionary, change the “APPID” to your newly created API key.
Requests will use the supplied payload dictionary to form a complete GET string at the end of the api_url and will automatically build websafe escaping for special characters where required!

Response

If everything is succesful, the data from your API call will be parsed from a raw JSON object into a Python3 dictionary object. Your output will be like so:

{
  'coord': {
            'lon': -0.13,
            'lat': 51.51
           },
  'weather': [
              {
                'id': 741,
                'main': 'Fog',
                'description': 'fog',
                'icon': '50n'
              },
              {
                'id': 500,
                'main': 'Rain',
                'description': 'light rain',
                'icon': '10n'
              },
              {
                'id': 701,
                'main': 'Mist',
                'description': 'mist',
                'icon': '50n'
              }
             ],
  'base': 'stations',
  'main': {
            'temp': -0.01,
            'pressure': 997,
            'humidity': 100,
            'temp_min': -1,
            'temp_max': 1
          },
  'visibility': 8000,
  'wind': {
            'speed': 3.6,
            'deg': 300
          },
  'clouds': {
              'all': 90
            },
  'dt': 1548199200,
  'sys': {
           'type': 1,
           'id': 1414,
           'message': 0.0041,
           'country': 'GB',
           'sunrise': 1548143498,
           'sunset': 1548174807
         },
  'id': 2643743,
  'name': 'London',
  'cod': 200
}

As you can see, it is mainly made up by a parent dictionary object containing inner lists and child dictionary objects.

You can now navigate the data through the usual way in Python. For example:

data['wind']['speed']

will return the wind speed value of “3.6” (m/s) in this example.

And to retreive the current recorded temperature, you will use they key values:

data['main']['temp']

which will return a chilly value of “-0.01” (degrees)!

Conclusion

In just a few lines of Python code you have an endless pit of on-demand data at your fingertips. This is incredibly useful in many different situations, and not limited to the example seen here.

Though this code is simple, it was designed to show a working illustration of using APIs in Python. In a real project, it would be necessary to check the response status to make sure the data has been delivered correctly. Without this, a program can crash by another of exception errors.

Further Implementation

In order to properly use this code into a working application, you may need to think of corner cases to catch exeptions and stop it from crashing in the event of an unexpected circumstance.
For example:

  • What happens if the current device loses internet connection or the URL is unreachable?
  • What happens with a bad API request?
  • What happens if the API key expires or gets blocked?

These 2 cases are infact quite similar, but can lead to many different errors further down the line.

In my case, I will:

  • Check the requests status code first. If this fails, I will record the information as “NULL” and skip everything else.
  • If the status is good, I will use a Try Except clause to access the data through dictionary keys. If the data is somehow not there due to a bad request, I will avoid a ValueError exception and record the data as “NULL” instead.

There might be a few more cases that I havn’t mentioned, but that is down mainly to what YOU decide to do with the data and how important it is for your application.

Questions? Have I missed something?
Comment below!