DEV Community: Ed Rutherford

Native Naïveté: Why Native Applications Still Have a Future

Ed Rutherford — Sun, 01 Sep 2024 20:57:17 +0000

A New Wave

Over the past year, there's been a consistent growth in the number of videos, walk-throughs, and supportive articles regarding the use of cross-platform frameworks to build applications with. Heck, even I've written a couple articles touting the ease-of-use of cross-platform frameworks...namely React Native and it's popular Expo framework for mobile app development, and the Rust-powered Tauri framework for building desktop applications.

These frameworks have become powerhouses in the app-dev sphere, and are go-to's for rapid project development for both teams and individual developers alike! One could reasonably argue that the success of these cross-platform frameworks leaves other native platform languages out in the cold with no real purpose...but I'm not so convinced!

The (Not So Simple) Answer

I've begun to notice a growing trend as of late, and I'm sure many of you have as well:

Everywhere you turn, there's another new article or Youtube video touting that Native app development is dead, and that everyone should just come to grips with that, and start building their applications with some cool cross-platform framework such as Flutter...

At first glance, seeing so many people promoting these frameworks might make you think it's a no-brainer to make the switch! Personally, even I found myself drawn to checking out expo as a means of shifting my mobile development to a more cross-platform scheme...and it worked out great!

But here's a newsflash: cross-platform frameworks haven't all of a sudden become the end-all-be-all solution to app development!

I know, I know, I can hear many of you screaming it out already:

"Why would you say something like that?! Don't you know how awesome Flutter is?? It allows you to have the same codebase for all the different platforms! There's literally no reason to waste time learning multiple native languages when you've got Flutter!"

The same thing could be said for Expo, which I DO still use for some of my mobile app development. The important thing that many developers need to realize, is that while a number of these (truly impressive) frameworks have a legitimate use in building many different applications, they are not (and should not) be the only way to do so!

Frameworks such as Expo and Flutter offer an excellent alternative for creating applications for iOS and Android without having to spend time building separate codebases. Heck, they can even use the same code for building desktop versions of the app! The thing is, there's always a catch...

First things first, let's revisit why one might prefer to choose a cross-platform framework like Expo to prototype and develop their mobile app:

Uses JavaScript and React: If you have experience with JavaScript and React, React Native is a perfect fit, allowing you to leverage the same skills to build both impressive UI's and backend functionality.
Rich Ecosystem: The extensive library of third-party plugins and components accelerates development, and provides just about everything you would need to build a fully-functional production app (though it may take some configuring).

So, there are certainly a number of intriguing reasons to lean towards using something like Expo to build and release an Android application...but as I said previously, nothing is without a downside. I've had the unfortunate first-hand experience recently to deal with this myself:

Bloated Binaries: While having the ability to write both UI and backend code in JavaScript is a wonderful thing for experienced web developers, it brings with it the need for a translation layer that adds to the overall app binary size, and has the potential to impact overall performance
Dependency Hell: Node Modules have the ability to be a jumbled mess as-is sometimes, but all that aside, the constant dependency changes can regularly cause issues building your application from one version to the next...especially if core dependencies require a NodeJS version upgrade that by itself can break other modules
Native Module Nightmares: If you're looking to incorporate some kind of native Android functionality, in my case widgets, you're required to "eject" or generate native code to write these features. This requires additional work adding compatibility layers for it to work. It's a great feeling once it's all together, but once the NodeJS version gets bumped, instability may soon follow and require re-writes

With all this in mind, I've reached the following conclusion (and I think many of you would as well):

If you want to have a completely managed project using Expo, and have no plans for additional fancy bells and whistles, you have an absolutely fantastic set of tools at your fingertips using React Native and the Expo framework! By all means, check it out and see what magic you can write.

If you want something more, however, like the raw power and speed of a purely native application...keep reading!

Revisiting Native Development

For years, the one and only language that typically came to mind when thinking of Android app development was Java. It's a powerful and performant language, but requires a heck of a lot of boilerplate code to put everything together! Not only that: While Java powered the backend of these applications, XML markup files handled the user interface (UI).

I'm not sure what all of your opinions are of writing UI's using XML, but I'll tell you right now...it's definitely not my preferred option!

No worries, though! As is the case with iOS apps as well, Android development has shifted in recent years to utilize a declarative approach to building user interfaces, as well as handling app logic. The Android approach to this involves the use of a popular type-safe language developed by JetBrains called Kotlin, in conjunction with a newly revamped UI framework called Jetpack Compose.

A couple key features include:

Declarative UI: Allows developers to describe the UI in a straightforward manner, reducing code confusion and overlap thanks to more reusable components
Interoperability: Jetpack Compose can coexist with traditional Android Views, allowing for gradual migration in existing Java-based apps.

So not only do you get an application that runs at full native speeds, you're equipped with a flexible UI framework that doesn't require you to write any compatibility layers to work smoothly. Like I said earlier, though, nothing is without downsides. If you're not familiar with writing code in Kotlin, there can be a learning curve especially if coming from web development using JavaScript (perhaps not as much with TypeScript).

Drawing Conclusions

While there are clearly a number of popular and impressive cross-platform frameworks out there supporting mobile development, it should go without saying that by no means is native development dead...quite the contrary! The native landscape has continued to evolve and grow to become an extremely enticing option for those looking to get the most out of their applications, and in the smallest of packages. Android has Jetpack Compose and iOS has SwitUI, both of which offer an exceptional experience for both developers and application users...which is really what it all boils down to.

The sheer number of options can be dizzying at times, but I implore you, take the time to review what you're looking for in your app and make your framework choice accordingly.

Cross-platform options have come a long ways the past few years, which is truly a welcome reprieve for those looking for other ways to get involved in mobile development. And while that may be true, they're not the only option.

Some may not care to admit it, but native app development isn't going anywhere...anytime soon!

Ed RutherfordFollow

IT Support Engineer, Cybersecurity Journeyman, Multi-Language Programmer. Avid learner of all things, and enjoy sharing with those willing to listen!

Level-up Your Git Projects with Gitflow

Ed Rutherford — Thu, 06 Jun 2024 02:10:34 +0000

Take your project’s design and evolution to the next level by integrating Gitflow into your development process!

In the Beginning

I’m fairly certain that many of you reading this are plenty familiar with the fantastic ecosystem that is Git, as well as some of the gigantic version control platforms such as Github and GitLab. That being said, there could still be some newbie programmers reading this article, and may need a quick primer on what Git is…so here’s your brief explanation:

Git is a version control system that allows you to manage and keep track of your source code history. It’s like a time machine for your code, enabling you to save snapshots of your changes and collaborate with others. GitHub, on the other hand, is a cloud-based hosting service specifically designed for managing Git repositories. It provides a platform where developers can store, create, manage, and collaborate on code.

As I’m sure many of you can relate, getting new projects up and running can be a challenge…and I’m just talking about drafting out and writing the code! Like a lot of us come to find out, managing a codebase can be quite a bit more involved than one might think:

First, you initialize your new repo and link it to a remote branch (if doing it locally)
Then, you start writing some code…easy right?
Next thing you know, your project is growing, new ideas emerge to add to the project…and of course, the occasional bug or hot-fix that may be necessary!
Finally, you keep making changes bit by bit, then commit and push the changes to your remote, with the occasional tag here and there…then repeat…

If the codebase isn’t all that large or complex, following such a straightforward development approach is more than likely going to be okay. But what happens if you’re creative juices are flowing and your once-small project now becomes more of a thriving repo with the potential for other collaborators to get involved, or perhaps you begin planning on packaging and distributing the code as it becomes more developed?

Enter Workflows

Lucky for us, there are several solutions for dealing with projects that grow in scope and complexity! We'll be focusing primarily on one of these solutions, which has become a key piece in my own improved development life-cycle (as well as countless other developers). Before we dive into it, let's have a quick introduction into what all we're talking about here...

Some of you may or may not be familiar with the term workflow when it comes to project development strategy. I'm sure it rings a bell for many of you, whether you know exactly what it is or not:

A workflow is an end-to-end process that...move[s] data (tasks) through a series of steps from initiation to completion. Once it’s set up, a workflow helps you organize information in a way that is not only understandable, but also repeatable.1

When it comes to Git project development, there are three popular workflows that are typically implemented by developers and teams:

Centralized
Feature Branch
Gitflow

Each of these has their own pros and cons, and for many are reliable ways to effectively build and maintain projects. Many of you will more than likely identify with using at least one of these workflows in your day to day coding experiences, even if you never knew it!

Centralized Workflow:
- Uses a central repository (often named main) as the single point of entry for all changes.
- Developers commit directly to the main branch.
- Advantages: Simple and easy to understand.
Feature Branch Workflow:
- Developers create separate branches for individual features or bug fixes.
- Each feature branch is isolated and independent.
- After development, feature branches are merged back into the main branch.
- Advantages: Branch isolation as well as parallel development ability.
Gitflow Workflow:
- Extends the feature branch workflow.
- Introduces additional branches: develop (for ongoing development) and release (for release candidates).
- Feature branches are created from develop (or dev), and hotfix branches are based on main.
- Advantages: Clear structure, well-defined roles for branches, and support for both features and releases.

Implementing Gitflow

How many of you immediately identified with a particular workflow after reading the previous section? I have a feeling many of you relate to using the first style of workflow, which is totally fine! What I hope to do here is expand your understanding of other common flows, in the event that your projects grow or you simply want a more organized structure for all your code.

Like many developers, I too was consistently using a Centralized Workflow for quite a long time. Once my projects started becoming significantly more complex, it became clear that a new flow had to be implemented...and the flow that worked best (and continues to work great) for these projects was Gitflow!

Getting started is pretty straightforward and painless for most, especially if you have full control of your git repo (which from this point on, I will assume you have). There are only a handful of required actions that need taken when setting the flow up, many of which can be done automatically depending on the code management platform you're using.

As you can see in the above image, desktop Git applications such as GitKraken offer built-in Gitflow integration, making it extremely easy to implement Gitflow in your projects!

My personal preference is to use GitKraken for all my desktop-based code management, though you're free to utilize whichever platform works well for you...

If for some reason your desktop Git client doesn’t have the option to enable Gitflow, or perhaps you prefer sticking with the terminal…have no fear! There's a dedicated git-flow extension available to install using your system's package manager!

Once installed, you can just as easily enable the flow in an existing repository or when creating a new one...

# For Debian/Ubuntu Distros
sudo apt install -y git-flow

# For Archlinux
yay -S gitflow-avh

# Using Homebrew
brew install git-flow

Putting it Together

Once we have either enabled Gitflow functionality in our desktop Git client, or installed it locally using our system’s package manager, it’s time to actually put it to use!

Using a desktop client such as GitKraken works out to be the simplest option, since all we need to do is enable it in our repository’s settings tab, and define what we want the various branches to be named. Once that’s done, we’re off to the races!

When following the manual approach to things, we first need to initialize the flow in our repo and define what our various branches should be called using the git-flow CLI:

# Enable Gitflow in our project
> git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] main
Branch name for "next release" development: [develop] dev

How to name your supporting branch prefixes?
Feature branches? [feature/] feat
Release branches? [release/] 
Hotfix branches? [hotfix/] fix
Support branches? [support/] 
Version tag prefix? []

Now that our new flow is enabled, we can go about developing our code as we normally would…for the most part! Remember, the whole purpose of implementing a Gitflow-styled development process is to better compartmentalize the various stages of the entire process:

The core, stable codebase will always follow the main branch (or whatever you named it)
Use the dev branch to make and push changes as you test and grow your project
When something doesn’t work right after a dev commit, use the hotfix type branch to make corrections and merge into dev
After accomplishing a milestone (i.e. finished a new component or code section), merge the current dev branch into main

Any Thoughts?

Some of you may be wondering to yourselves: “What’s the point of doing all this?”. I’m glad you asked! While it may seem like a bit of extra work to enable and implement different branches in a project, doing so will help keep your code commits organized and overall project more structured than a typical single-branch style repo.

By maintaining such structure in your projects, you’ll without a doubt become a better developer that’s much better equipped to work on larger projects down the road…be they your own or even an internal corporate project!

Current and potential employers alike typically appreciate seeing such well-structured code and commit histories that models like Gitflow produce…

Get to it!

Now that you have a better understanding of what Gitflow is, and how it can help you become a better developer, get out there and try it out! The important thing to remember is that while not all projects need implement such a flow…many of them can and should.

Pick a project that you’ve been working on (or even start a new one), and follow the steps that apply to you to enable Gitflow. Once you do, see what kind of changes you experience while following this workflow!

Do you find yourself better organizing your commits and code merges as your project grows in complexity? Perhaps you don’t think it makes much of a difference for the project you’re currently working on? It can happen sometimes!

1) Martins, Julia. “Hitting Work Blocks? Try Workflows. [2024].” Asana, Asana, 17 Jan. 2024, asana.com/resources/workflow-examples.

Ed RutherfordFollow

IT Support Engineer, Cybersecurity Journeyman, Multi-Language Programmer. Avid learner of all things, and enjoy sharing with those willing to listen!

From NixOS with Love

Ed Rutherford — Sat, 23 Mar 2024 19:43:06 +0000

For those of you who’ve read my previous article on immutability, you’d know that I’ve been somewhat starting to spread the word about (increasingly popular) immutable operating systems. While the concept and existence of these systems is nothing new, there have been several candidates with their own unique spin on the concept that has been truly remarkable!

Many of the more popular and recognizable immutable operating systems include:

Fedora Silverblue
macOS (surprised??)
Vanilla OS
NixOS

It is the latter of these that I’ve found myself enamored with over the past year, and it’s been one heck of a ride! I figured it was high-time that I shared this truly awesome experience, and help other *nix enthusiasts understand the profound impacts such an OS could have on them as well!

Quick Recap

If you haven’t read my previous article on immutable systems, here’s a quick rundown of what we’re talking about here:

Immutable operating systems are built with the principle of immutability in mind. This basically means that the operating system is designed to be unchangeable and unmodifiable during runtime. Any updates or modifications to the system result in the creation of a new instance or snapshot…thus making it extremely easy to rollback to a previous configuration should a change produce undesirable effects.

This means that:

Instead of overwriting previous applications and files with their newest selves, an entirely new system state is created and stored separate from the previous one
This new state is then available at system boot, alongside any previous states from prior upgrades

Questions?

Many of you probably have many of the same thoughts, questions, and reservations that I did when considering testing out a system like NixOS. The very first thing that I thought of was:

If each system upgrade produces a new copy of the system to boot from, won’t that use up a crap ton of storage space??

The short answer to this is yes, it has the potential to use up large blocks of storage space on your hard drive…but like I said...that’s only the short answer!

A more accurate answer to this is that there’s the potential for high storage requirements, but only if you plan to keep multiple snapshot versions on your system! Generally speaking, when you upgrade your system, you will have a new image to boot into after restart, as well as the previous stable version. It’s totally fine to have one or two previous system images on hand to boot from in case a change you make ends up being no-so-good. NixOS makes rollbacks so trivial, it's usually good practice to have a generation or two on hand to rollback to just in case.

If you’re a bit clingy and think it’s necessary to hold onto 10+ previous images, though, you’re going to feel the weight of all that space being used up pretty quickly…

With that question answered, there’s no other possible downsides for any of you to worry about other than your own willingness to learn about something new and awesome…

Something Awesome Awaits

As a hardcore Arch Linux user, I was quite used to frequent rolling updates and library patches. I was also in the habit of regularly handling symlinks and ensuring executables were in my $PATH...which typically meant being located in the universal /usr/bin directory. To my surprise, among other things, was to learn that no such directory existed in NixOS...at least not in the traditional sense!

Everything as you know it when it comes to system paths and application directories will be completely flipped on its head with NixOS...and I'm talking some serious Inception type stuff here folks!

In a typical Arch system, you run an upgrade command to update all of your applications:



$ sudo pacman -Syu

During this process, any new versions of an application or library are downloaded and installed, replacing the old version. This applies to supporting modules and DLL’s too. Out with the old, in with the new! But what happens if your upgrade gets interrupted? Network disconnect, power surge, catastrophic shutdown cause of some weird possessed PC?? If you’re lucky, you are able to re-run the command and pick back up where you left off. Worst case, you get corrupted files, or have to fix pacman by unlocking it (among other possible scenarios)…this is no bueno!

With NixOS, updates are atomic, meaning that all update operations only get applied once the entire process has finished. If something gets interrupted or crashes during the update, no worries! No system files have been created/modified in any way whatsoever. This adds to the overall stability of the system!

Personally, I always enjoyed having bleeding edge versions of many of the applications I’d regularly use. As it turns out, NixOS has an unstable channel (a sources repo of sorts) that you can follow for all your system upgrades. This means you can have the stability of an immutable system, while also enjoying the newest versions of your favorite applications and tools!

The Cherry On Top

So far, we’ve seen that NixOS has several qualities that should peak all of your interest, including:

Atomic, safe, system upgrades
Snapshot-type versioning for quick-and-easy rollbacks (built-in!)
Stable and Unstable (bleeding-edge) application sources to choose from

All of these aspects are fine and dandy, but the real cherry on top is how the system itself is built and configured…that’s right, I said configured! NixOS isn’t some typical Linux system that you manage from the command line or GUI. It's an intricate, complex system that is realized and managed by a core configuration file (or flake depending on the setup)…the glorious configuration.nix!

Did you notice the file extension of the config file? That's right, the OS has it's own programming language which it is built on top of! If you were unaware of its existence before now, it's okay, but the name should say it all...

Package Manager | Language Framework

Nix is an interesting language, very similar to Haskell, and is the backbone of the operating system. I'm not going to get into it in this article, but will go a bit more in-depth in an upcoming article…so stay tuned and be sure to subscribe! As usual, I highly encourage anyone interested in the OS to at least spend a little time looking through the official documentation and tutorials to get an idea of how it works.

At first, the thought of building out a configuration file to control what applications were installed on my machine seemed downright ludicrous! Why not just run commands from the terminal to install why I need? News flash..you can! But it's much more efficient and customizable to do so from the configuration file. Below is a small section that could be imported or written directly into the main config file. You'll notice it's pretty straightforward to understand, especially when declaring the hostname for the system and enabling ssh and postgresql:



{ config, pkgs, ... }:

{
  fileSystems."/".device = "/dev/disk/by-label/nixos";

  networking.hostName = "mandark";

  environment.systemPackages = [ pkgs.firefox ];

  services.openssh.enable = true;
  services.openssh.forwardX11 = true;

  services.postgresql.enable = true;
  services.postgresql.enableTCPIP = true;

  services.xserver.enable = true;
  services.xserver.desktopManager.kde4.enable = true;

As it would soon turn out, using a configuration-based system is absolutely magnificent! Not only is it extremely powerful and flexible, it can be reproduced across machines! That’s right, I can tailor my own perfect system, and use the same configuration on my other devices to reproduce the exact same setup with absolutely minimal effort! Even more awesome, I can build the new system on a beefy desktop PC and push it over the network to a laptop and install everything there…like I’m some kind of Nix Warlock!!!

It’s these final features that convinced me to give NixOS a worthy shot of being a daily driver on one of my laptops. And before I knew it, I was running it daily on my main desktop and one of my Raspberry Pi’s as well! Even now, I’m writing part of this article on it because it just works so darn well, regardless of how powerful your hardware is!

Wrapping Up

There’s actually one other (freaking awesome) thing that can be done to make a NixOS system the best of the best that you can have on your device…but you’ll have to stay tuned for that article!

Whether you’re an Arch Linux power-user like me, or an intrepid newbie looking for the perfect OS to call home, I hope you take a moment to seriously look into NixOS. It has the potential to be the paradigm shift that many of you have been looking for, and it’s community is only going to continue to grow!

I hope you enjoyed a glimpse at my own personal experience and love for NixOS! Give me a like and leave a comment with your thoughts! If you’re curious and want to learn more about various programming frameworks and systems like NixOS, feel free to follow me and subscribe for updates on newly released articles!

Until next time, stay curious and seek knowledge!

Ed RutherfordFollow

IT Support Engineer, Cybersecurity Journeyman, Multi-Language Programmer. Avid learner of all things, and enjoy sharing with those willing to listen!

dedSyn4ps3 (Ed Rutherford) · GitHub

Founder and Lead Consultant for Null-Return IT Services and Consulting. Multi-language programmer and cybersecurity journeyman. - dedSyn4ps3

github.com

Goodbye Electron. Hello Tauri!

Ed Rutherford — Mon, 12 Feb 2024 01:21:24 +0000

Utilize the Rust-powered backend framework paired with a React frontend to offer an awesome browser-less experience

Many a developer can tell you about their love-hate relationship with the JavaScript GUI framework that helped revolutionize the way many desktop applications are made. The fact is that many of the apps we all use today, whether it pertains to development, social media, communications…you name it, have been built using the Electron framework.

If you’re ever curious, check out the curated list of apps that use Electron from their website.

The point is, Electron offered developers with web development experience the opportunity to create standalone desktop applications for multiple platforms…all without having to learn any new programming languages! It offered the ability to use the same JavaScript, CSS, and HTML that many of us use all the time, which of course is quite wonderful!

To briefly summarize how Electron was able to offer this:

Electron is a framework for building desktop applications using JavaScript, HTML, and CSS. By embedding Chromium and Node.js into its binary, Electron allows you to maintain one JavaScript codebase and create cross-platform apps that work on Windows, macOS, and Linux — no native development experience required.

One of the biggest downsides to building desktop apps using Electron, as some of you have probably seen throughout Stack Overflow and other forums…is the resulting binary tends to be outrageously large! So much so, that even just a medium-sized code base could result in a final binary ~60MB.

After experiencing this frustration firsthand, I started wondering if there was a magical solution to this problem…and as it turns out, Rust just so happened to offer one!

Tauri is a toolkit that helps developers make applications for the major desktop platforms — using virtually any frontend framework in existence. The core is built with Rust, and the CLI leverages Node.js making Tauri a genuinely polyglot approach to creating and maintaining great apps.

Diving In

To my excitement, their command-line scaffolding tool creates all the Rust files you need to get up and running using familiar frontend frameworks. Not only that, but once I was ready to start adding my own functions to the backend for the UI to use, Tauri makes getting everything working together rather seamless!

I decided to give Tauri a try to create a new desktop dashboard application for a community project I was planning on contributing to, and spoiler…it didn’t disappoint!

As I mentioned previously, getting started was rather straightforward:

Ensure your system has Rust installed
If on Windows or Linux, make sure to install the relevant dependencies
Run a simple command to set up your project

After that, it was a matter of getting the frontend source files all put together, while occasionally referencing the docs from Tauri when I needed some pointers on Inter-Process Communication between the UI and backend.

The beauty of using Tauri to create my dashboard is I no longer had to bother with creating a separate preload.js file just to be able to utilize inter-process communication properly.

All that was required was the proper annotation in the main.rs above the function that I wanted to call from the UI, and a simple additional import line in my React jsx file:

import { invoke } from '@tauri-apps/api/tauri'

The power of a Tauri-built app, in the end, comes down to the fact that its backend utilizes Rust. This allows developers such as myself to build their final product into a native-running binary at a fraction of the size of many Electron-built applications.

Conclusions

It’s become clear, at least to me, that Tauri certainly has the potential to continue growing to the point in which it topples Electron as the dominant “front-end” GUI framework. Even though there may be an intimidation factor due to being built on Rust, the small amount of time needed to understand its internals is well worth it!

I encourage anyone looking to start their journey into front-end GUI development to check out the Tauri framework, and resist the urge to immediately look to Electron as the immediate solution…you’ll be pleasantly surprised I assure you!

For completeness, you can find the entire code base for my community project on my Gitlab. Check it out if you’re looking for any ideas for your own projects!

Ed Rutherford / Enviro Plus Desktop · GitLab

GitLab.com

gitlab.com

Ed RutherfordFollow

IT Support Engineer, Cybersecurity Journeyman, Multi-Language Programmer. Avid learner of all things, and enjoy sharing with those willing to listen!

💻 Check out my Github, too!

Immutability: A Growing Trend

Ed Rutherford — Sat, 03 Feb 2024 20:07:15 +0000

What is it, how it works, and why you should seriously consider checking it out!

If you happen to pay any kind of attention to ongoing trends in the Linux OS sphere, you've more than likely come across posts, articles, or maybe a few videos that make reference to these interesting operating systems that tout having this magical structure that makes them "immutable".

Immutable operating systems are built with the principle of immutability in mind. This basically means that the operating system is designed to be unchangeable and unmodifiable during runtime. Any updates or modifications to the system result in the creation of a new instance or snapshot...thus making it extremely easy to rollback to a previous configuration should a change produce undesirable effects.

Ok, so maybe a literal kind of definition isn't exactly the most tasteful way of explaining what makes these OS's different from everything else...

Perhaps a better way to look at the difference between a typical OS many of us use, and an immutable one is like this:

Standard OS

The vast majority of Linux operating systems, such as Arch or Ubuntu, follow a standard file system hierarchy (shown above).
Users run their respective package manager commands to update their system, i.e. apt upgrade or pacman -Syu, to check whether or not there are newer software versions available.
If a more recent version exists, the application binary (or shared libraries) is downloaded from the remote source and installed…consequently overwriting the previous installation files.
Even though Windows differs in its system structure, it too follows a similar process for system updates.
Such processes of update and replace are ultimately what makes these mutable systems.

Immutable Systems

Upgrades happen in the complete opposite way.
Instead of overwriting previous applications and files with their newest selves, an entirely new system state is created and stored separate from the previous one.
This new state is then available at system boot, alongside any previous states from prior upgrades.

Immutable systems function similarly to version management tools such as git. Whenever you update or add new code to a project that's being tracked by git, you commit the new changes to the code base, which in turn receives a new hash and other metadata attached to it. Even though your code is updated, you're still able to rollback to the previous commit and toss all those changes if something happened to break after the commit was made.

Some Pros

Version Control Mechanism: Immutable operating systems enable easier version control and rollback capabilities. If an update or change results in an issue or unintended consequence, reverting to a previous version is as simple as switching back to a known stable image.
Simplified Maintenance: With immutable operating systems, the need for continuous patching and updates is significantly reduced. Since the system remains unchanged during runtime, there's no need for live updates or patches (unless of course you want to).
Increased Stability: Immutable operating systems provide a high level of stability due to their unchangeable nature. By eliminating the potential for unexpected modifications or conflicts, the system is less prone to errors and crashes.

A Few (Slight) Cons

Storage Requirements: Since each system version or change requires the creation of a new instance or image, the storage requirements for immutable operating systems can be higher compared to traditional operating systems. This isn't always the case though, as long as you keep the number of stored snapshots to a minimum.
Learning Curves: Moving from a traditional operating system to an immutable one can involve a learning curve for some, especially for a system like NixOS which utilizes a single configuration file for defining system state. Users sometimes need to acquaint themselves with new tools and workflows for managing and updating the system. As with everything, reading through documentation and user forums can quickly flatten any curve.

There have been a number of immutable systems that have increasingly become more popular with users, and each has its own implementation of immutable file structures.

A few of these worth mentioning include:

NixOS
Fedora Silverblue
VanillaOS
macOS (through similar mechanisms)

So What?

I can already hear some of you saying it out loud:

"So what? It sounds like just another flavor of something I don't really need"

And ya know, you may be right…or you may be dead wrong! The thing is, immutable operating systems aren't the be-all-end-all of things. For many, they are a means to an end, and for others…well, for others, they're the only option.

Personally, I use NixOS on a daily basis on several of my laptops and desktops, but also love the bleeding edge and raw power that Arch Linux offers, and in certain scenarios the sysadmin qualities of CentOS/Rocky Linux.

The beautiful thing is, as with all things Linux…the choice is yours!

Wrapping Up

If you found this article intriguing, and would like to keep up with the wide world of application development and systems exploration, give me a follow and feel free to leave your thoughts! I try my best to respond to everyone's comments, and highly value all of your opinions!

Ed RutherfordFollow

IT Support Engineer, Cybersecurity Journeyman, Multi-Language Programmer. Avid learner of all things, and enjoy sharing with those willing to listen!

💻 Check out my Github

Building a PinePhone App With React and Tauri

Ed Rutherford — Thu, 14 Sep 2023 03:04:08 +0000

Ed Rutherford / Enviroplus Pinephone · GitLab

GitLab.com

gitlab.com

The Time Has Come

Over the past few years, pure Linux-powered mobile devices have found their way into the mainstream. The ability to run a customized kernel on something like an Android device is nothing new, and the same can be said for iPhone jail-breaking.

The difference here is that these devices (many of them at least) are built from the ground up with a focus on free and open-source technologies. As such, they aim to run fully open Linux-based operating systems, and in many cases include physical hardware switches to disable various components to provide additional user privacy.

The rise of more powerful and inexpensive ARM-based chips now mean that many of the devices have the potential to function at levels equivalent or close to mid-range closed source devices running iOS or Android.

Many hobbyists and developers (such as myself) have started flocking to obtain these devices, leaving many of us with the same question after getting one: “This is awesome, but how do I go about creating my own apps for this thing?”. My hope is that this article will help some of you answer this question, and assist in developing your own applications for these popular devices!

One of the most popular Tux phones on the market is without a doubt the PinePhone (and more recently the PinePhone Pro) made by Pine64. I’ve unfortunately not had it in my budget to acquire a new Pro version, so had to settle on developing on the first-gen Community Edition instead. The project outlined here is by no means locked to running on just these devices. If you have something like a Librem 5 by Purism, see how you can make it work!

In a previous article, I wrote about a new (and now maturing) framework called Tauri that I’ve started using to replace my old Electron-based projects. Unlike Electron, it uses Rust for handling all backend functionality, and allows for using web technologies to build your UI!

Even though I initially used Tauri to create a new desktop application, I thought it would be awesome to test out its capabilities running on the PinePhone! Let’s get to the good stuff, shall we?

Starting Off

The Tauri documentation provides excellent guides on creating new projects from scratch using their command line tool, including the ability to generate a complete skeleton using the front-end framework of your choice. Because I already had developed a web app using React, I already had the UI code structure in place. Since that was the case, all I needed to do was create the necessary Rust and configuration files needed by Tauri in the project directory:

Install CLI tool → yarn add -D @tauri-apps/cli

Initialize Tauri → yarn tauri init

If you’re creating a brand new project from scratch and you need to generate all the needed files for both front and backend, you’d run:

yarn create tauri-app

Backend Functions

Because I was building a dashboard application that needed to make regular GET requests to a Raspberry Pi on the local network, I had to make sure to include the same backend Rust function that the other versions of my app use to make these requests.

With Tauri, there’s no need to create a preload.js file for the UI to call backend functions. Instead, all that’s needed is the @tauri-apps/api library added to your package.json file. You can then invoke the function from your JavaScript/React code with the following import:

import { invoke } from '@tauri-apps/api/tauri'

Using invoke, you can then call your backend function by name, passing any arguments necessary. For my application, I make this call using a JavaScript function that passes the URL endpoint that I am making the request to in order to retrieve a particular sensor value:

The corresponding backend function gets included in the main.rs file that Tauri creates in the projects src-tauri directory:

It’s important to keep in mind that since this application is being written to run specifically on the PinePhone (or some other mobile Linux device), component sizes and window dimensions need to be taken into consideration.

Binary Creation

Once you’ve gone through the process of setting up your interface and any backend function calls, tested and debugged everything, you probably want to build a final product! Because these devices run Linux, Tauri will build a .deb and .AppImage binary for running and distributing your application. Building everything is as simple as running:

yarn tauri build

I did notice an issue with the automated AppImage build script while trying to run on the aarch64 platform, so to successfully finish building the AppImage for my app, I simply downloaded and ran the appimagetool utility to finish packaging:

Test It Out!

After that, you’ll end up with a shiny new AppImage with everything required to run built-in! Simply make it executable and run it to enjoy your new PinePhone (or similar) app!

A Word of Warning

I love my PinePhone, but when it comes to doing all of the development solely on the device, I’d advise against it. It’s plenty capable, but hot reloading can take longer than you’d like, and the same goes for building the final binary.

I found doing the majority of development and debugging on a separate ARM-powered device (my Raspberry Pi 4) was much quicker. Once you figure out the right window dimensions, the devpreview still provides an accurate look as to how the app is coming along.

After building the final executable on the Pi, it’s super simple to transfer over to the PinePhone using either scp or a graphical SFTP tool!

Next Steps

Curious to see what you can make with this? Head over to the Gitlab repo and check it out!

Ed Rutherford / Enviroplus Pinephone · GitLab

GitLab.com

gitlab.com

I hope to see even more great mobile Linux apps out there powered by Tauri in the near future. For those of you interested in Android development, Tauri also has mobile capabilities currently in alpha!

I've also published a fairly lengthy walk-through of how to build such an Android app over on Medium that I encourage you to check out if interested. I'll be publishing it here as well in the near future. 🌟

Using PowerShell Forms for Repetitive (Work) Tasks

Ed Rutherford — Tue, 12 Sep 2023 03:06:04 +0000

dedSyn4ps3 / response-generator-example

Response Generator

A simple Windows form utility for generating quick response messages

About 🗃

As IT Support Professionals, we are constantly sending correspondance to various clients and end users Very rarely do we help only one or two customer groups each day, and because of that fact, it's normal for us to have to create tailored response messages with contact info specific to that client.

This repository is meant to supplement the Medium article: "Using PowerShell Forms for Repetitive Tasks"

Getting Started 🖥

The utility was designed as straightforward, custom module meant to be easily imported into a powershell session and invoked by the user. In order for this module to be imported, it's important to locate the designated system path to place this project's inner directory in. The easiest way to find that location is by opening a powershell terminal and typing the following:

PS > $env:

…

View on GitHub

PowerShell...Seriously?

Yes, really! I know that many of the excellent articles many of us read each day tend to follow the more flashy, exciting languages that dominate headlines as a result of their growing popularity and expansive use-cases. While that's all well and good, many of us that may work in IT aren't fortunate enough to use many of these new fancy releases in our day to day roles...usually because of this thing called Access Control Lists and Group Policy Objects (that's right, good ol' Active Directory management).
There is a way, however, that many in IT are able to utilize automation and scripting that in most situations is allowed by GPO (depending on your role of course), and that's by utilizing Window's very own powerhouse scripting language, PowerShell!

Quick Recap

For those who may not be all that familiar with what PowerShell is, and just how powerful it can be for developers, here's a brief intro:

PowerShell is a modern command shell that includes the best features of other popular shells. Unlike most shells that only accept and return text, PowerShell accepts and returns .NET objects. The shell includes the following features:

Robust command-line history

Tab completion and command prediction (See about_PSReadLine)

Supports command and parameter aliases

Pipeline for chaining commands

In-console help system, similar to Unix man pages

At its inception, PowerShell was originally developed on and designed to be a better and more feature-rich shell experience for Windows users and system administrators. As the project continued to grow and blossom, a decision was made by Microsoft to develop a cross-platform version of PowerShell and make it open source for the broader community to contribute to...and thus, PowerShell Core was born!

Sometimes this can be slightly confusing to new programmers that are trying to understand the differences between the PowerShell they see built in to their Windows device, and PS Core installs that they see online. It all comes down to the version of .NET that they run on:

Windows PowerShell 5.1 is built on top of the .NET Framework v4.5. With the release of PowerShell 6.0, PowerShell became an open source project built on .NET Core 2.0. Moving from the .NET Framework to .NET Core allowed PowerShell to become a cross-platform solution.

The project outlined in this article is solely dependent on Windows PowerShell. It will not function if ran on any version of PS Core, regardless of whether you're running it on Windows, macOS, or Linux. If you're wondering why that is exactly, it's due to the fact that the Windows Forms API that we will use is only part of the native .NET Framework included in all recent versions of Windows.

Harness the Strength of PowerShell

The goal of our project is pretty straightforward:

Streamline and automate the generation of response emails for customers
Build a custom PowerShell module to incorporate this functionality
Create a simple graphical interface using the Forms API to interact with the module

Because this project is merely a starting point for future applications, its structure will be pretty mundane. Even so, it demonstrates a great way for organizing any future module projects.

We're going to put together a relatively simple ResponseGenerator UI using .NET Forms via PowerShell. It provides a means of quick email response generation depending on the client ID chosen by the user. The following will be its structure:

.
├── ResponseCore.ps1
├── ResponseForm.ps1
├── ResponseGenerator.psd1
├── ResponseGenerator.psm1
└── assets
└── coding.ico

Building A Module

As I mentioned previously, the best approach for building our utility is to create a dedicated module for it. PowerShell modules are similar in structure to Python package directories and modules in other languages, so they should feel relatively familiar to many of you.

At their simplest, new modules can be made up of a single file, though in most scenarios they will consist of several files located in a central root directory. One very important factor to keep in mind when building a new module:

The root directory should be named exactly the same as the module file itself.

To start out, we’ll go ahead and create the module directory and primary declaration file for our utility by running the following:

PS > New-Item -Type Directory -Path "ResponseGenerator"
PS > Set-Location -Path ./ResponseGenerator && New-Item -Type File -Path "ResponseGenerator.psm1"

You may have noticed already that the extension of our newly created file is .psm1. These particular files are the “core” of a PowerShell module, in our case, ResponseGenerator.

It will be the primary entry point of our utility, but will only contain a handful of code. The primary body of our module code will be spread out between two other files, which we will create right now:

PS > New-Item -Type File -Path "ResponseForm.ps1" && New-Item -Type File -Path "ResponseCore.ps1"

NOTE: Don’t worry about creating the psd1 file just yet, we'll get to it soon enough!

Creating the Form

Now that we’ve got our core files in place, we can start adding the code needed to generate a nice looking graphical utility!

The following Gist shows how we declare our callback functions for specific button presses, as well as creating a ComboBox for storing the entire list of contacts to choose from, and a few quick response button shortcuts:

Adding the Rest

The only thing left to do for our module at this point is to finish adding the remaining core functions and contact info arrays to the other file in our project, ResponseCore.ps1:

Wrapping Things Up

Now that all of our utility code is written, the last thing to do to finish our PowerShell module is creating a .psd1 Module Manifest. This file allows developers to add fine-grained details about their module, as well as limit which functions are exported for use in the command line.

PowerShell provides a handy cmdlet (pronounced command-let) to generate this for us, which we can pass various arguments to in order to overwrite the default values for important fields:

New-ModuleManifest `
-Path "$PWD\ResponseGenerator.psd1" `
-Author "dedSyn4ps3" `
-RootModule ResponseGenerator.psm1 `
-Description "This module helps generate response messages"

This will create the last piece of our utility! There is a line of code in this manifest that I recommend making a slight adjustment to, however. It’s good practice to not export every single function declared in your module, and by default the manifest generator does just that.

Simply scroll down a ways until you see the field declaring FunctionsToExport and update it with the primary entry point to our utility, which we declared previously in the module file:

FunctionsToExport = 'Invoke-ResponseGenerator'

Run It!

And with that, you’ve successfully put together a PowerShell module that can be imported and run from the command line! When it comes to custom modules, it’s extremely convenient to be able to call it from our shell without having to specify the actual location path of the module directory.

In order to import and run our utility by name, it’s imperative that the module directory be placed in the designated location for all PowerShell modules for your user! This may very from system to system, so to be sure, simply type the following in your shell to find out the exact location to place the new module:

PS > $env:PSModulePath

With the module directory placed where it needs to go, importing and calling the main entry point is as simple as invoking any other command from our shell:

# import the custom module
PS > Import-Module ResponseGenerator

# start the utility by calling it's invoke method
PS > Invoke-ResponseGenerator

Project Code

The entire project repository can be found on Github, and I highly encourage those looking for a great way to kickstart their PowerShell automation to check it out!

Also be sure to give me a like if you found this article interesting, and be sure to subscribe for upcoming articles! And if you're on Medium as well, check me out there for early viewing! ✨

dedSyn4ps3 / response-generator-example

Response Generator

A simple Windows form utility for generating quick response messages

About 🗃

This repository is meant to supplement the Medium article: "Using PowerShell Forms for Repetitive Tasks"

Getting Started 🖥

PS > $env:

…

View on GitHub

Custom theming for React Native Applications

Ed Rutherford — Mon, 26 Dec 2022 03:40:31 +0000

TL;DR
If you prefer to dive straight into some code or follow along using project files, head over to the Github repo for this article and clone it to test and make your own changes!

dedSyn4ps3 / react-native-theming

React Native Theming

This repo is meant to hold the code files for the Medium article Hail to the Theme.

About

This is a demo application that utilizes the Expo framework to create a React Native-based mobile app capable of switching between custom light and dark color palettes depending on the host device settings.

The application makes use primarily of customized components offered by the awesome React Native Paper and React Navigation frameworks

You can create your own custom Material UI color palettes by going to react-native-paper's theme generator page.

Live Development

To run in live development mode, run npx expo start in the project root directory. This will start an interactive command line utility allowing you choose which device to run your app on:

Test on a physical device using the Expo Go mobile app (scan the QR for easy setup)

Run on an Android emulator…

View on GitHub

A Brief Introduction

Love them or hate theme, themes are all around us! Our operating systems provide custom theme options (some more than others), many popular web browsers allow for installing custom theme extensions…and of course, so do our mobile phones!

While mobile device theming may be a bit more limited than the other avenues mentioned above, there’s still the underlying commonality between both iOS and Android of now providing Light and Dark themes for core applications.

Before we dive into coding our app, it’s important to explain the means in which we do it! The example application used for this article will be written almost exclusively in JavaScript…more specifically Extended JavaScript (or JSX). This may come as a shock to those new to cross-platform development, who typically think of Java and Swift as being the only way to build a mobile app. It’s true, both Java/Kotlin as well as Swift/Objective-C are primary languages used to build mobile applications for Android and iOS respectively…but they aren’t the only way!

Enter React Native

React Native combines the best parts of native development with React, a best-in-class JavaScript library for building user interfaces…
…Create platform-specific versions of components so a single codebase can share code across platforms. With React Native, one team can maintain two platforms and share a common technology — React.

By using React Native, we’ll be able to take advantage of the power and flexibility offered by React, and also have the ability to re-use custom components to build mobile apps that can be run on both Android and iOS…all with the same code base!

To get our project set up, we’ll be using the outstanding Expo framework and its CLI (command line interface). Expo has become one of the most widely used tools for mobile development with react native, not just because of how simple it makes getting a project started, but also for the wealth of libraries it offers to customize the look and functionality of your app!

It’s important to make sure we have the following system requirements installed:

Node.js LTS Release (using the LTS specific release is important)
Git
Watchman (for Linux/macOS systems)
Yarn (not required, but recommended by Expo)

Open up your favorite terminal application or PowerShell, and navigate to where you plan to create your project directory. Once there, run the following to create a new expo project:

npx create-expo-app example-app && cd example-app

The Code

Alright, let’s get to the good stuff! Now that we have our basic setup, we’ll go ahead and create some components to put together in a small example app to look at how theming can be utilized in a straightforward way. The application will represent a store shopping list app, which adjusts its component theming based on whether the user’s device is set to light or dark mode.

The first and arguably most important step for us is to create a set of colors to use for our app’s theme. This project utilizes an awesome React Native framework react-native-paper. It will provide the key components used for building our UI. A great feature that can be found on their website is a generator for Material UI themes based on a provided primary color:

This fantastic tool not only takes the hard work out of creating proper light and dark color palette objects, but also follows the Material Design guidelines that all new versions of Android follow…allowing our app to effectively feel and look like any other natively built application!

If you haven’t done so already, make sure to add the following dependencies to your package.json to get all the magic installed:

{
  "name": "example-app",
  "version": "1.0.0",
  "main": "node_modules/expo/AppEntry.js",
  "scripts": {
    "start": "expo start",
    "android": "expo start --android",
    "ios": "expo start --ios",
    "web": "expo start --web"
  },
  "dependencies": {
    "@react-navigation/bottom-tabs": "^6.4.0",
    "@react-navigation/native": "^6.0.13",
    "expo": "~46.0.16",
    "expo-app-loading": "~2.1.0",
    "expo-font": "~10.2.0",
    "expo-status-bar": "~1.4.0",
    "expo-system-ui": "~1.3.0",
    "react": "18.0.0",
    "react-native": "0.69.6",
    "react-native-gesture-handler": "~2.5.0",
    "react-native-paper": "^5.0.0-rc.8",
    "react-native-reanimated": "~2.9.1",
    "react-native-safe-area-context": "^4.3.1",
    "react-native-screens": "~3.15.0",
    "react-native-svg": "12.3.0"
  },
  "devDependencies": {
    "@babel/core": "^7.12.9",
    "@babel/plugin-proposal-decorators": "^7.20.0"
  },
  "private": true
}

To use the theme objects we previously created, go ahead and open your project's App.js file and add them, as well as the other import statements for expo and react-native-paper :

The above gist is where all the theming magic happens in our app! We declare our theme objects using the color palette values generated by react-native-paper. Expo provides an API for adjusting the top status bar color depending on whether the device is set to dark or light mode, so we make sure to include that as well. The other important piece of this code involves the use of the useColorScheme hook when defining our two theme providers. This will allow our themes to be passed down and accessed by all child components in the app.

Speaking of Components

You may have noticed a particular import statement in the code above adding a MainNavigator component. This is where the primary navigation functionality of our app resides, and makes use of another powerful and appropriately named react-navigation framework to do so. Before we take a look at our Navigator, let’s throw together a couple smaller components to incorporate in our UI:

With our component files defined, we can now go ahead and import them into our MainNavigator file, along with the navigation components provided by react-navigation :

If you paid close attention, you may have noticed the key line(s) of code that allow us to apply our custom theme colors to the app’s components.

import { ..., useTheme, ... } from 'react-native-paper';

It’s this useTheme hook that allows us to access the custom theme objects passed down from the very top of our application. All that’s required to use these colors is calling the hook and storing the return value inside a variable, like in our PrimaryScreen component:

Testing

To run our new project in live development mode, run npx expo start in the project root directory. This will start an interactive command line utility allowing you choose which device to test your app on:

Test on a physical device using the Expo Go mobile app (scan the QR for easy setup)
Run on an Android emulator (using Android Studio)
Run on iOS emulator device (using Xcode)

The process of implementing custom themes can seem rather daunting at first for many developers, including myself. With the help of some amazing frameworks, however, it can be accomplished (relatively) painlessly!