DEV Community: Vincent Milum Jr

PHP Altaform Framework - Zero Boilerplate!

Vincent Milum Jr — Thu, 25 May 2023 07:34:39 +0000

In this video, I discuss the Altaform framework for PHP that I created.

Altaform allows you to create APIs in under 30 seconds with less than 5 lines of code!

All boilerplate from other frameworks is entirely gone.

FreeBSD 13.0 Released!

Vincent Milum Jr — Sun, 18 Apr 2021 18:58:49 +0000

TLDR: FreeBSD 13.0 release notes:
https://www.freebsd.org/releases/13.0R/relnotes/

Join the FreeBSD discussion over on Discord! We'll answer any questions you may have, host live chats, demos, and generally geek out over technology.
https://discord.gg/n2wshsy

Over this past week, FreeBSD version 13.0 was released!

There are many great improvements in this new version of FreeBSD, but I'd like to highlight a few personal favorites.

But first, what exactly IS FreeBSD?

Way back in the early days of computing, there was AT&T UNIX. The University of California, Berkeley started using and modifying UNIX. They released this new system under the name "BSD", or "Berkeley Software Distribution". Over the years, there were several iterations of divergent paths taken by the BSD code base, one of which is now known as the operating system FreeBSD!

If you've used Linux, many of the FreeBSD features will feel very natural. Linux was designed to be an independent clone of UNIX, and FreeBSD has direct lineage to UNIX. Linux and FreeBSD share a similar mindset in many of their tools available to end users.

The command shells available on FreeBSD and Linux are mostly the same, such as tcsh, bash, and POSIX sh. Graphical environments such as Gnome, KDE, and XFCE are the same as well! Common sysadmin command like top, htop, ps, and more are also the same. You will also find the same developer tools like git, python, php, llvm, rust, go, node, and more.

BUT, there are some very key differences!

FreeBSD 13.0 now ships with OpenZFS 2.0 as its default file system. With OpenZFS 2.0, many new awesome features have become available, such as better latency performance diagnostics, as well as the new zstd compression standard. OpenZFS on FreeBSD adds significantly more flexibility for managing storage over the Linux file systems like XFS, EXT, or BTRFS.

ARM CPUs are becoming a highly prominent player in computing at all scales now. ARM powers the fastest super computer in the world, is powering the MacBook Air M1 I'm typing this on right now, power AWS Gravaton instances, and is making headway into the workstation class of computers. With the release of FreeBSD 13.0, Aarch64 (64-bit version of ARM) is now a Tier-1 architecture on the platform. This means that it will be treated the same as AMD64 (64-bit version of x86) in regards to patching, updates, security fixes, bug fixes, package availability, and more.

Speaking of the ARM support, VMware has been testing their ESXi hypervisor on ARM as well! There is now ESXi ARM Fling, an experimental hypervisor that works on devices such as the 4GB and 8GB models of the Raspberry Pi 4. Along with that, FreeBSD has extended their virtual machine client support to work beautifully under ESXi ARM Fling with the release of FreeBSD 13.0! This means that installing a virtual machine on ARM is the same effortless process as it is with AMD64 systems. Simply create a fresh virtual machine, boot off of the FreeBSD 13.0 iso image from the virtual CD-ROM, and it'll boot up into the installer and run exactly the same as it would on any other platform.

There are many more advancements. Please take a look at the release notes to see highlights pointed out from the core FreeBSD release engineering team.

https://www.freebsd.org/releases/13.0R/relnotes/

Enter The Matrix with FreeBSD

Vincent Milum Jr — Mon, 12 Apr 2021 04:39:48 +0000

Have you ever wanted to enter The Matrix, but didn't know how? Well, today is your lucky day!

FreeBSD makes this possible by downloading one simple command line utility.

First, let's download and install the termatrix command.

pkg install -y termatrix

From there you will see some installation status messages such as:

The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        termatrix: 0.2

Number of packages to be installed: 1

10 KiB to be downloaded.
[1/1] Fetching termatrix-0.2.txz: 100%   10 KiB  10.2kB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Installing termatrix-0.2...
[1/1] Extracting termatrix-0.2: 100%

After that, we can now enter The Matrix! From the command line, simply run:

termatrix

You should now see The Matrix on your screen!

The termatrix utility is available on virtually every architecture supported by FreeBSD. So this means if you're running on an Intel or AMD PC, it will be available and work. This also means it works perfectly on ARM devices like the Raspberry Pi as well! You can view the full compatibility list and more details about this program over on FreshPorts: https://www.freshports.org/misc/termatrix

FreeBSD on Discord

Vincent Milum Jr — Tue, 30 Mar 2021 16:41:35 +0000

FreeBSD on discord: https://discord.gg/vDFeUc7EqQ

FreeBSD is an amazing operating system with a lot of great features presented in simple ways compared to other free/open source OSes.

Native support for the most advanced file system ever created, OpenZFS right out of the box! Plus Dtrace, one of the best debugging tools out there. And it also has Jails, the gold standard in secure containerization. All of this AND MORE™! with an interface familiar to Linux/Unix users as they share many of the same userland utilities!

FreeBSD has these and more in a tiny footprint that runs on a Raspberry Pi Zero, yet performant and scalable enough to run one of the largest content delivery networks in the world.

Curious about FreeBSD? Then please join the discussion over on Discord! We'll happily answer any questions you may have :)

https://discord.gg/vDFeUc7EqQ

Compiling MariaDB from Source - On FreeBSD

Vincent Milum Jr — Sun, 28 Mar 2021 06:56:35 +0000

This is part of a series of articles I'm writing on how to accomplish common tasks in FreeBSD. Every day, I see new tutorials on "How To Do (THING) on Linux in 20 easy steps!" - so here I am, matching each of those articles, but from the perspective of showing the amazing simplicity of FreeBSD instead.

Compiling MariaDB from Source

On many other platforms, they'll start out with a complicated set of steps to create the build environment, setup the compiler and tool chain, then download and extract the source code before even getting to the compilation. This is all 100% automated in the FreeBSD world!

1) Enter the directory for the MariaDB Port

cd /usr/ports/databases/mariadb105-server/

2) Download, configure, and compile MariaDB (yes, all in one command)

make

3) Install your now compiled MariaDB binaries

make install

And just like that, MariaDB is not only compiled, but it is also installed! What about all of the compiler tools required? What about runtime dependencies? All of that is taken care of for us automatically via the FreeBSD Ports collection!

Alternatively, if you want to install MariaDB from pre-built binary packages, that option is also available. Simple replace steps 1-3 with with the following:

pkg install -y mariadb105-server

But wait, there are actually two more important steps after this... because we need to actually RUN our server, not just compile and install it!

NOTE: For the time being, MariaDB still uses the "mysql-server" service on FreeBSD, as it has yet to be renamed.

4) Enable the MariaDB service to start at boot time

service mysql-server enable

5) Start the MariaDB service without first rebooting

service mysql-server start

But wait, what about the utility to create the initial MariaDB database? That too is taken care of for us automatically on first run! Everything is designed from the ground up for easy sysadmin automation.

Recap

So, let's recap. Step one, draw a couple circle. Step two, let FreeBSD draw the rest of the owl! ;)

Should I become a Front-End or Back-End developer?

Vincent Milum Jr — Sat, 26 Dec 2020 23:07:41 +0000

This is a post that I've been meaning to write for quite some time now.

The question of "Should I become a Front-End or Back-End developer" pops up quite regularly, so I thought I'd pose the question here too. No, not for me, the author, but for you, the reader who may be new to programming and wondering which of these directions you should head in.

This question is usually phrased in such a way that the options are either-or, but never both. But more importantly, the question is usually phrased in such a way to imply that these are literally the only two avenues to pursue as an aspiring developer.

I want to offer you an exploratory thought experiment into the vast array of other possibilities that you could potentially explore if you want to get into software development. Front-end and back-end web development is only an extremely small fraction of what is out there!

Why might you consider other areas of development? Web dev is where all the hype and buzz is, surely that's the best possible path, right? Well, that honestly depends. Lesser talked about positions usually means there is less competition for those jobs, and with less people applying, they often offer higher payouts as an incentive to try to get the best possible candidates for these less popular jobs.

But, you may ask, "what ARE these other possibilities as a developer?"

Let's start by expanding on the idea of a web developer. The core back-end languages and toolkits used today revolve around PHP, Node.js, Python, Ruby, .Net, and other similar languages.

Now think of each of the libraries for these languages.

Do you include a module to access a database? Ask yourself, "who writes that library?"

How about something that parses JSON? Or generates JSON for data? Same for XML? What about the library that reads the metadata from a JPEG image file? Or how about the library that fetches HTTP(s) content from another system?

Each of these libraries are pieces of code that someone, or a group of people, wrote, manage, and maintain. These types of libraries are often open-source, and available to accept contributions too!

But how did they come into being? Usually someone is working on a particular project, saw a need, wrote some re-usable code, and decided to package it up as a library.

One such example is when doing web development in PHP, I was frequently writing complex SQL queries to interact with my databases. Over time, I realized most of the code was repetitive, so I eventually bundled it up as a separate library and published it publicly.

Sometimes it may be something that seems simple and trivial, but it can save a significant amount of someone else's time to research. Another library I published is a single file, a single function. It translates shipping/tracking numbers into a URL for each shipper's tracking web site. Pass in a USPS tracking number to the function, and it spits out the URL for tracking that particular USPS package. Not terribly complex, but it means the research of several different tracking number formats can be crowd sourced! As users of the library handle other shippers, they provide those shipper's tracking number formats as either issue tracker items or pull requests, and everybody benefits. :)

Now let's take things into a slightly more complex direction. Computer languages don't inherently exist on their own, and they get updated over time. How exactly is this?

The ability for a computer to read and understand code such as PHP or JavaScript inside of Node.js are themselves programs written in other languages. These are also areas of active development. Some of them have high profile companies backing them, such as .Net from Microsoft, Go from Google, Swift from Apple, or Hack from Facebook. Each of these languages has an entire team of people who work on them full time at their respective companies!

Let's take a step back for a second, and look at the wide picture instead.

Are you a Mac user? Or Windows? What about Linux? Or possibly even FreeBSD? Each of these are also programs that have people actively maintaining them!!! Well, kinda...

Yes, each has a mountain of people that work on them. However, they're each not an individual program. They're collections of programs all bundled together, often maintained by entirely separate teams.

For instance, the Windows Start button is an entirely different codebase managed by entirely different people than Notepad!

But this doesn't stop at just user-facing desktop applications.

An entire computer is layers on top of layers of different types of programs all interacting with one another.

Your keyboard for instance is most likely USB (even possibly true if you're on a laptop, with an internal USB connection). There is firmware on modern keyboards that accept the key presses, and then sends the signal over USB back to the USB root device.

Think to yourself: "who writes the keyboard firmware?"

But then the USB root communicates back to the rest of the system, sometimes over PCI-Express.

Think to yourself: "who writes the USB interface code?"

And then there is a keyboard driver in the operating system to receive and interpret those commands.

Think to yourself: "who writes the keyboard drivers?"

From there, the driver sends a signal to the operating system kernel to handle and route.

Think to yourself: "who writes the keyboard kernel subsystem?"

At that point, the keyboard subsystem routes the message to the active, in-focus application though the kernel's ABI (application binary interface)

Think to yourself: "who writes the ABI?"

Now let's say our application just so happens to be a web browser. This web browser is displaying a form on the screen with several elements that are interactable.

Think to yourself: "who writes the browser code to handle the keyboard event, sending it to the right focused item on the web page?"

And all of this is for a single key press, every key press, every time you type.

Web browsers can do quite a bit more than just accept keypresses though. They send and receive data over networks using a variety of protocols, encrypt your data for privacy and protection, decode and display a variety of photo, audio and video formats, and countless more features.

This may seems like a single monumental task, but that's not entirely the case. Instead, like mentioned previously, this is all handled via a collection of smaller, simpler libraries. Most of these libraries are maintained entirely independently of the browser itself.

Curious what these libraries may be? In Chromium based browsers (Google Chrome, Microsoft Edge, Opera, etc), Go to "Settings" > "About" and click on "open source software". Microsoft Edge that I'm typing this on currently has 371 libraries listed.

Do you use the command line interface in your operating system?

Every single CLI command is a program or a script that somebody at some point wrote.

Who wrote all of those commands? Who manages and maintains them? And who will write the next iteration of them? That could possibly be you!

But what happens when we step away from the desktop computer, what else is out there?

Think to yourself...

Who writes the user interface for my smart TV?

Who writes apps for cell phones?

But wait, who writes the OS itself for the cell phones!?

How about those IoT devices, who writes the program for those smart outlets, smart switches and other IoT devices?

And how about those drones everyone loves to fly, who writes the software for those?

This being the Christmas holiday season, who writes the microcontroller code that allows Christmas lights to blink?

Who programs the digital interface on your microwave or stovetop?

Who programs the traffic lights when you're driving down the road?

What about digital signs on billboards and in windows of businesses?

RGB LEDs are all the crazy right now! But who writes the code for those to change color and blink?

... lastly, obligatory ... who programs the VCR?

But this is still nowhere near an exhaustive list of areas a programmer can explore! This can also become quite overwhelming very quickly, being flooded with endless possibilities.

The vast majority of these, however, can be broken down into a simpler context: problems and solutions.

In the end, all we're doing as developer is using structured commands to have electronic machines solve problems for us.

So next time you think to yourself "should I be a front-end or back-end web developer", change that up to "which problem am I trying to solve, and which set of tools would best solve it?"

It may be that extending an existing library might solve the problem at hand. It may be that a new command line tool could solve it too. Or maybe it does require a nice web based graphical interface. It all comes down to what tools are available, and which ones are the best at the time to get the job done.