February 28

Why the Raspberry PI is Still Awesome

By now, I’m sure most of you have already heard of the Raspberry PI. If you haven’t, Google it.

For me, the Raspberry PI is an affordable and versatile computing device, ideal for a wide spectrum of users. I initially purchased my PI in the year 2015, and have used it over time for various different software and server development projects. Here are several great modern uses for the PI…

Desktop

The PI can be used as a normal desktop to perform normal day to day duties, such as checking E-mail, taking notes, etc. While the board does come with various ports and available hardware that can deem it a wireless device (i.e. connect a screen and integrated power supply and you can turn this bad boy into a wireless tablet), it can also be set up as a traditional desktop computer. An HDMI and multiple USB ports enable you to hook up this miniscule board to an external monitor, mouse an keyboard as you normally would with your other over-the-counter brand PC’s.

Dashboard

The PI can be used to serve as an always-on dashboard, powering an external monitor. I’ve used this setup to provide realtime visualizations and analytics of an online business I once set up.

Home Automation

The PI can be used as a home automation powerhouse. A friend and I installed and configured Hassbian to run on the PI. This build helped serve as a centralized home automation hub. We were able to control and automate when and what happened on connected home automation devices, from Smart TVs to lighting and voice assistants.

Automating Scripts

The PI can be used as a general server to run and automate scripts. I’ve personally employed the PI as a service to mine, scrape and load data. This proved to be a very low-cost but highly reliable ETL service for a variety of different projects.

Web Server

Saving the best for last, the PI can be used as a WLAN web server for testing purposes. I recently worked with a start-up where I had to develop on a local deployment rather than tampering with the production environment. It served as a great, low-cost and low resource intensive alternative to a traditional server or local deployment. I had it running in an always-on fashion, so rather than using my desktop pc as a server, or my macbook with a local server, the PI itself was the server, and I could connect remotely or access the files via FTP to work my magic from any machine of my choice within the same network.

The Verdict

To summarize, I’ve always hated raspberries. But the Raspberry PI is an extremely high-value product when you look at how much it costs and what its capabilities are, even in 2021 when nobody is talking about it anymore.

Category: Automation, Software Engineering, Thoughts | LEAVE A COMMENT
December 31

Naming Variables – my camelCase story

One of the many arts or etiquette of coding can be attributed to your choice of naming convention for your variables.

I say art because it’s partially aesthetics. The way you name your variable can make your line look very beautiful or very ugly. I say etiquette because it’s really just professional and respectful best practice to name your variable in a way where it’s easier for another person to follow the flow of your code.

My variables typically look like the following:

i_item_name_str

Examining this, there are typically at least 3 parts to my variables. the [i] here represents that this is an input variable. In this case, it is a parameter being processed from within a function (thus, input). So right away, the beginning of the variable can tell where this variable came from (i.e. is it an input? an output? or just a non-derived variable?) The [item_name] represents what this variable is, which in this case is the name of the item being passed. The [str] helps identify what type of variable this is, so right away I know this is a string (or varchar) field.

Now, we all know there are certain standardized means of naming variables, especially for certain languages. One of the most common methods is camel casing. That is, instead of i_item_name_str, it may look something like itemName. While this is absolutely fine and visually sexy, I’ve come across some unanticipated obstacles in my career that deemed the camel casing methodology a risky one, and one that I am hesitant to use.

As a solutions architect, I work with many different layers or technologies. A project may consist of working with a combination of MySQL and PHP. While you may be able to get away with camel casing in PHP, there was an instance where I had used it throughout my procedure names and variables in MySQL. I then, at a later time, had to migrate to another server, after which my applications all broke. When I did some diagnostics on it, I came to realize it was because the migration lowercased everything and ultimately made everything unusable since the camel casing was no longer in tact! Now that I look back, I’m almost positive there could have been a setting in the server configuration that I could have used to enable case sensitivity. But now that I’m traumatized, I’d rather never take that risk ever again and never put myself in a position to do any unnecessary work. At the end of the day, i_item_name_str is almost just as legible as itemName, but less prone to fail across platforms and migrations. That is, until we come across one that prohibits the use of underscores. Oh boy.

So tell me, what is your single most used variable naming convention and why?

Category: Software Engineering, Thoughts | LEAVE A COMMENT
November 30

3 Tests to Identify the Best Tech Solution

By profession and passion, I am, at heart, a problem solver as most of us are in various walks of life.

When it comes to solving a complex problem or overcoming an obstacle, it’s important to take 3 elements into consideration when shortlisting solutions. It’s equally important to consider these as qualifiers in the same sequence as listed below, as the first element would serve as a Minimum Viable Product (MVP), and the latter two build upon it for a more intelligent solution before we even get into optimization.

Does it solve the problem at hand?

Your solution needs to solve the problem that was presented. Maybe you innovated something marginally better than the current outgoing process, or took the extra mile and came up with an awesome solution that does fancy things, but does it solve the actual problem that was presented? Passing this test is absolutely critical, and logically that makes sense. This is why it is necessary to brainstorm “What Am I solving for?” as the very first step. Identify the actual problem and focus on the NEED before the NICE-to-HAVE.

Is it sustainable?

So now that we have a solution in mind that solves the problem presented, the next area to focus on is sustainability. How robust is your solution? Does it have multiple dependencies, such as the use of certain licensed software or human intervention which may be subject to excessive maintenance or intervention? In other words, is this a truly autonomous solution that can run on its own; that has failsafes built-in and the ability to not only alert developers during failure but to correct itself? If not, that’s OK, since the ease of doing so varies based on the nature of the problem, but this needs to be the vision when developing the solution. It needs to be designed with autonomy in mind, so that it is developed with dynamic abilities, and less dependence on manual intervention.

Is it scalable?

If you’ve come up with a solution by now that passes the first two tests presented above, passing this third one will likely deem your solution the holy grail of solutions. The third test is scalability. Again, this is subject to the nature of the problem, but in most cases, you can’t go wrong designing your solution with scalability in mind. What I mean by this is, think of your solution as not just a solution to the problem presented, but a solution that will be a dynamic enough solution to cater for other, similar problems. In doing so, your solution would serve as a re-usable template, and just by passing a few parameters or settings to it, it can become an intelligent, dynamic plug-and-play repurposed solution.

Conclusion

In summary, we’ve covered the 3 sequential steps that I consider are necessary to identifying the most optimal high-level solutions, before getting our hands dirty with development. It’s important to understand that applicability of these considerations depends widely on the scope and type of problem and the technologies you have available to solve it. Ultimately, it’s just necessary to design the solution with this mindset as much as you can, even if you can’t apply all of the principles completely.

Category: Automation, Software Engineering, Thoughts | LEAVE A COMMENT