DEV Community: Jesse Bennett

Layers Exposed

Jesse Bennett — Thu, 20 Jan 2022 19:59:26 +0000

Data oriented programming is here to stay and along with it comes the deconstruction of popular programming idioms. When coming from a productivity oriented stack the typical 3-layer idiom is DAL, BLL, and OBJ. These would be "Data Access Layer" and "Business Logic Layer" and "Object Layer". "Object Layer" is interchangeable with "Presentation Layer" depending on the architecture of the application. Whether it's native apps or web apps there is probably at least one application with this architecture buried somewhere in the repo at nearly every company I've ever worked at.

What Happened to N-Tier?

After years of maintaining applications like this I can say wholeheartedly that each one becomes much like the subject of Chemistry where typically there is no good place to start. Using N-Tier monstrous applications begin to unfold and over years of maintenance a lot of code gets developed just interacting with the "Layers".

Rather than some silver bullet solution getting developed the term just became more popular to describe interfaces to data. That is an idea I can actually get onboard with because that is exactly how it feels. The term "Interface" in Object Oriented Programming changes every year because (surprise!) it just takes whatever it takes to communicate with "Layers". The new definition in C# 8.0 for interface is IMHO everything but the kitchen sink except for state to be used in tandem with classes.

Okay...well what about C++ I mean an interface in C++ has to be very specific right? Actually, there aren't any concepts in C++ which use the term "Interface" but a similar concept is the use of an "Abstract Class" which cannot be instantiated but can be used as a base class. A class is made abstract by declaring one of it's functions as a pure virtual class. The newer updates in C++20 allow for "constexpr virtual" (you can read about it here constexpr-virtual). In a convoluted sense- the "Interface" got another update.

This is getting complicated

What I think we should really be after is creating interfaces where layers of data are not so coupled. Depending on the interface it may need to be tightly coupled or it may actually be running in a container or VM somewhere or on another port. The interface should be standardized within an organization if needed. This might be why it's common to see the term "Interface" and "Layer" being used almost interchangeably in recent times. I would recommend creating an "Interface" that can talk to multiple "Layers" or creating a "Layer" that can have multiple "Interfaces" but going 1-for-1 is where the code bloat comes from. It's actually very easy to create an "Interface" for each "Layer" or vice versa. It's very challenging to create reusable code on either side but happens to be the cleanest solution.

NoSQL Layers and APIs

Now that we've delved a little into "Interfaces" and "Layers" the programming model becomes even more reduced in the world of NoSQL. Respectively, when it comes to Cosmos DB or FoundationDB, the "Layer" is something which resembles more of an API which translates the resulting output to NoSQL using an "Interface". This is a shift away from N-Tier because no longer can N-Tier fit all of this into its definition. Solutions are still being developed under FoundationDB and the solutions for Cosmos DB are varied but hosted only on Azure.

Both systems are in heavy use worldwide and the concepts of NoSQL take some getting used to. Mainly- the convergence of certain principles into a single principle. The "Interface" is the "API" which also becomes the "Data Access Layer (DAL)" as it translates usable data into NoSQL. Altogether, they form a "Layer". Can you use the same code you've relied on for years to leverage these technologies? That is up to you, the developer, and how much performance you wish to squeeze out of the whole thing.

Curb your enthusiasm for tech

Jesse Bennett — Sat, 15 Jan 2022 18:08:31 +0000

Part of going online and saying things is that you tend to want to make them a reality. It was some time ago I really put my foot in my mouth claiming that I wanted to make a "streaming web server with foundationdb as a backend". Wow! I had no idea what I was getting into. Originally I wanted to use C# but, as it's pretty obvious, I use BSD so porting and building entire languages was a non-option when scaling down to minimal embedded hardware. I, unfortunately, unloaded on the FDB forums much of the turmoil in my soul.

Rather than completely stew about it I actually took the suggestions given to me in the FreeBSD forums. What I did was do the research comparing all the different languages discussed which were C#, C++, GoLang, and Rust. I even took a sharp turn into F# and Bosque. Still though, the main target was the web server. The web server has not seen many changes IMO since the days of DHTML and Perl other than a slew of extra options. I proudly use NGINX it's really good and have even reviewed it's internals when I was messing around with C++. With NGINX and it's module system it is possible to make just about anything which is why it has been so popular. I use it all the time as a proxy and for interactive stuff that is mainly how it is configured. What if this could all be done in one place? Enter the streaming web server.

It's actually such a broad idea it doesn't mean much is what I learned. Really, from the web developer perspective what is needed are "buffers". These buffers should work like they do in Kakoune or Emacs. Ok, so now an idea is starting to emerge let's see what all the research yielded.

C# .Net Core
I was able to make a very simple web server but all the more important methods for the MS web stack became more and more private creating a web of dependencies. I could not hoist my code into anything reasonably efficient on an alternate OS despite getting really far. I did create a working web server on FreeBSD.

F# .Net Core
Somehow this ended up being a better choice than C#? Not sure why that is but probably has more to do with it being a non-mainstream language so more of the features are there. I forked MiTLS to create a modern F# web server which was pretty cool but, again, the tooling was a problem on an alternate OS.

C++
I actually got pretty far with C++ using Kqueue and Sendfile(2) but realized over time that I could not be productive enough to build out all of the internals. I got the performance I wanted and really settled in but this whole thing about "memory safety" guarantees was really bugging me.

GoLang
GoLang, as I discovered, was really fun and refreshing. I would have completely chosen it if it hadn't had been for some changes to the base system which had me feeling like I was just at the wrong place at the wrong time. At this point with GoLang and C++ I'm on the ARM architecture and embedded is getting closer and closer.

Bosque
I fell in love with Bosque but when I found myself writing my own internals and major shifts to the ecosystem began arriving I had to back down from Bosque. In terms of running on an alternate OS it's perfect. I got Bosque running on my freaking iPhone via the Ish app! It's one to look out for but a little too early in the game.

Rust
Rust was the only language I could feel productive enough in, have those memory safety guarantees, build on ARM without any hassle all while being on an alternate OS. Server Sent Events arrived last year and the "streaming web server" has been created with FoundationDB as a backend. It was a long journey but I guess it was worth it in the end to give all of this consideration to each and every language.

Holiday Void Install

Jesse Bennett — Sun, 02 Jan 2022 18:00:11 +0000

What would I describe a hacker Christmas to be? This year it was the gift of hoodies, mirror shades, end-to-end encryption on mobile, and provisioning a “deck” all for @reallyjanejones. The choice for hardware was an Asus Eee PC with the Intel Atom.

The choice for OS was Void Linux and was pleasantly surprised to see that Unix philosophy in practice with this distro.

Nothing really kicked off that wasn’t allowed beforehand which is another thing I really like about Void.

If you made it this far I’ll go ahead and let you know, of course, Wi-Fi and ACPI and Battery all work on this machine.

I did some work messing with a self-made web server and moving files to an ARM machine and this whole install was a success. No real hoops to jump through.

So, if you were looking for a quick way to put something completely mobile with a full keyboard together I highly recommend this combination. For web dev I am just swapping out video clips here and did xbps-install xterm to get UXTerm which seems to be able to handle ZSH on FreeBSD as well as PowerLevel

I don’t see any reason to move off of Vim and ffmpeg either so the term emulation works out well as I shuffle clips from Intel to ARM. For many tasks the fact the Atom processor is used in automotive can be seen, for instance, in starting up and shutting down the deck the speeds for that are ludicrous.

Playout for video and multimedia tasks are not the point of using an Atom of this vintage however for ad-hoc web dev this machine really is worth the effort.

Getting back into the groove

Jesse Bennett — Sat, 01 Jan 2022 17:21:00 +0000

Recently, I deleted all my social media after having some personal realizations. This has been long overdue even though I truly miss creating content for the small audience which had been cultivated over time. Really I was coding around the edges of what was normal like a journal of Unsolved Mysteries concerning Unix while also poking the bear. I started contributing a little again to OSS and had a super-productive run before settling in for the holidays. A corner has been turned and so subsequent content will be in this format. It's a new year and time to explain @wolfspidercode was an account meant to, ironically, cause some laughs but actually highlight the technologies used for real purposes. I had a lot of fun and actually created a lot of lurkers with it. Some people got the joke and others didn't and living in that in-between space had me really coding for that next bit of content. I actually do have a lot of respect for the real tech evangelists out there and a lot of truth came out in those posts it would seem. Happy New Year to everyone wherever you are and whoever you are!

Patching my graphics driver in FreeBSD

Jesse Bennett — Mon, 04 May 2020 15:59:48 +0000

While going through an archive of content I made during the transition to some new hardware I found some steps in FreeBSD which may be useful to others in a similar situation. This was a while back and during that time finding a balance between a desktop environment, ZFS, and building up a development environment created some interesting outcomes. ZFS has many attractive features including it's ARC cache. Files will get cached on the system for faster access and allocates RAM while doing so. These settings can be adjusted and between releases 11 and 12 of FreeBSD ZFS received a major tune-up in this department. Back in the days of 11 it was common that between ZFS and my integrated i915 gpu they would start to fight for RAM. The culprit was the graphics card mainly and it was eating up RAM very quickly. My options were to reinstall everything with UFS instead and just deal with it, tear down my desktop and run headless, or actually try and sort out the i915 issue. I chose the latter because my development relied heavily on benchmarking the results while running on top of ZFS. Just searching around on Github I found a similar report and some good results for 12 but was not available for 11. I decided to patch this fix into 11 and test it out myself.

Drop A GEM On 'Em
GEM stands for Graphics Execution Manager and is a generic DRM (Direct Rendering Module) memory management framework. That is the description in the drm-memory man page. Many of the user land drivers in BSD actually track changes in Linux graphics drivers. There are places where they diverge and in this case that is where the issue was located.

While flipping pages and marking them as dirty what seemed to be missing was the correct memory management functions. This was easy enough to see in the patch for 12 so I began editing the code brought down from the FreeBSD ports collection. I just had to make sure it was added in there like so:

In the FreeBSD ports system most of the files being compiled can be found in the "work" folder. Even if you edit them recompiling will generally pull down the latest port files and overwrite them so what you really want is to patch the file. This can be accomplished with the "diff" command:

If you just "make" after building everything like I did here the compiler is well within reason to believe nothing needs to get built. Just be sure to "make clean extract patch" and everything should build. Running the command "make install" will deploy the code after building:

Afterwards I reported my results and everything ran much better. This kept me rolling until it was time to upgrade.

How to build .Net Core on FreeBSD (UPDATED AGAIN?)

Jesse Bennett — Thu, 27 Jun 2019 03:58:28 +0000

Sorry! These are not the Core you are looking for...

This article previously had the instructions for the 2.x .Net Core which has officially been replaced by 5 preview 3.

The most recent version of .Net Core on FreeBSD can be found here