Opinion on inherent site

GK61 Review

Sat, 04 Sep 2021 14:49:11 +0300

Intro

A little less than a month ago I bought a new keyboard, the HK Gaming GK61. It’s a 60% mechanical keyboard with RGB backlighting and a few different switch options. I’ve been using full-size membrane keyboards up until now so this was quite a bit different.

Overview

The GK61 comes in black, white, red or pink colors. It can be outfitted with gateron optical black, blue, brown, red, silver or yellow switches. As denoted by the name, its 60% size is a noteworthy selling point. Of course you can’t buy anything without RGB nowadays so it has that too. There is also a piece of software for configuring keyboard settings and saves them on the keyboard itself. I paid 70 euros for it in greece and I bought the black model with blue switches. With the big picture view out of the way, let’s get a bit more into the specifics.

Switches

As previously mentioned, I went with the gateron optical blue switches. This was mostly done because I like the noise and tactile feedback. I have a habit of bottoming out the keys so blues being a little slower for people that only barely activate the switch is not an issue. One potential drawback I was made aware of is that optical switches are not as common so replacing them is potentially more difficult. All the keys work fine, the sound is enjoyable, the physical feedback is good so no real complaints here.

60% layout

The size of the keyboard was a big change for me but also one of the big reasons I chose it. The unfortunate part is that it was only available in ANSI and not ISO locally but I’m aware that an ISO version exists. So what’s the deal with the 60% size? What does that mean exactly? There is no numpad, no F1 to F12, no end, home, pgup, pgdown, insert, delete or arrow keys. What does exist however, is an Function (Fn) key that acts as a modifier. This means that you can press Fn and something else to access the alternative function of a key. It saves size but can also be a bit annoying when you can’t access some keys directly. My personal changes were that I remapped caps lock to escape, right alt to left arrow, right ctrl to right arrow and escape to backtick. I’m slowly finding out that I’d prefer it if there were arrow keys that are just arrow keys on the main layer. Overall I like the small size but I think a 65% size with an ISO layout would be a better option for me.

Software

This is where things get a bit more gloomy. There exists software for the GK61 but not all software utilities are the same. In specific, I got a GK61v2 which has a serial number that starts with GK61US and things get interesting. The earlier versions of this keyboard use seemingly different firmware and different software utilities. Additionally, the alternative key functions are different for the GK61v2 so the M1, M2, M3 mode keys don’t work. At any rate, the software works fine. It allows remapping keys as well as customizing the lighting mode. Well…about that lightning customization… One would think that customizing one of the custom lighting modes would allow it to be permanently saved but no. If you make a custom one and then hit Fn and \ to cycle all of them, your custom mode will be nowhere to be found. This is unfortunate but I don’t mind since I just wanted to have a solid color and move on however it’s a downside worth mentioning. In totality the software side of the keyboard is a downside but it isn’t completely unusable I guess.

Conclusion

After almost a month of use, I’m overall pretty happy with the GK61. For 70 euros it was a fairly big investment, it was my first mechanical keyboard as well as my first 60% keyboard. Ideally I would like to have an ISO layout and separate arrow keys so when I upgrade in the future I’ll look at getting a 65% one with the appropriate key layout or possibly build a custom one. Overall I’d recommend it just be aware that it’s a lot smaller than what you might be used to. Thank you for reading, I hope you got something out of this.

The Power of the Library Example

Thu, 06 May 2021 14:25:41 +0300

While considering what kind of example I could use for a service that was supposed to be a tech demo, I settled on a catalog/library of books. I think it’s a powerful example because it includes the basic CRUD operations and also allows for a lot of flexibility and detail of implementation. Below I’ll try to explain the most important ones and maybe help convince you to rethink about it and maybe use it as the next step after the usual todo list one.

The Library example

Let’s start with an explanation of what this example actually is before going into its advantages. It’s pretty simple, you have a library of books and want to perform operations associated with managing a library. Simple concept, simple to implement and uses real-life things that people have experience with and can reason about. Is it really this simple though? In the intro I said it’s supposed to be a step-up from the usual todo list example but so far it doesn’t seem different other than being another object in the place of a todo item. Well, let’s dive a little deeper.

Data Structures

When you start, there is the dilemma of what fields/attributes to give the book. The ISBN stands out as a convenient unique identifier which is great, then there is the title, the number of pages, year of release, format as in hard cover or soft cover or pdf or epub or mobi, edition, categor(y/ies), author, publisher, subtitle, cover art, bookmark for reading progress, description in the back cover, if you own it or not, did you lend it to someone or not, are you lending it from someone or not, if it’s a physical copy where is it located and so on and so forth. I think you get my point, you can get really deep into it if you want or pick some of the basics and go from there. Are they really basics though? Specifically when it comes to who wrote the book, it could be one person or it could be more than one. Especially in technical books it’s not unusual to have 2 or 3 authors so you’re getting into a situation where you have something like the following (silly example but please stay with me):

{
  "books": [
    {
      "ISBN": "0189219181",
      "Title": "hey",
      "Author": {
        "authors": [
          {
            "AuthorID": 1,
            "FirstName": "anguish",
            "MiddleName": "none",
            "LastName": "mental",
            "YearBorn": 404,
            "YearDied": 201,
            "BooksWritten": 5
          },
          {
            "AuthorID": 2,
            "FirstName": "big",
            "MiddleName": "boo",
            "LastName": "ba",
            "BooksWritten": 9543
          },
          {
            "AuthorID": 3,
            "FirstName": "me",
            "MiddleName": "notme",
            "LastName": "notyou",
            "YearBorn": 1999,
            "BooksWritten": 2
          }
        ]
      },
      "Year": 1999,
      "Edition": 1,
      "Publisher": {
        "PublisherID": 3,
        "Name": "urmom",
        "YearStarted": 1237,
        "YearEnded": 2077,
        "BooksPublished": 9001
      },
      "Pages": 100,
      "Category": "tech",
      "PDF": false,
      "Owned": true,
      "Lended": true
    }
  ]
}

Here we see that each author is inside an array which is the value of a key called authors which is the value of a key called Author which is a part of one of the objects in the array called books which is inside the outer JSON object. Fairly complex, right? Additionally, you have to pay attention to this throughout the entire application including saving it and retrieving it from a database, when passing it to other services that might use this data for example a cover art finder or a media aggregator service and when those services process it. Following that, there are logistical considerations about storing an author or publisher twice since the client shouldn’t have to deal with sending the right ID for the publisher or the author(s), checking if a book with the same ISBN exists, potentially handling cases where you bought it again cause the person you gave it to never gave it back and so on. The main takeaway is that you can decide how real-world you want to make the example, add complexity at will and introduce edge cases that defy previously established preconditions such as the ISBN being a unique identifier.

Functions

I touched on this before I believe it warrants repeating. Similar to the data structure you go with, there several functions of differing depth you can implement. The simple CRUD operations might be taken as a baseline but what even if that rule was able to be defied? Do you want to delete the book or simply set a hidden state because you want the library to act as an archive? Should the cases of the author’s year of birth and death be allowed to be set incorrectly (like in the example above with author 1), partially (author 2) or not at all (author 3)? Should the person that the library belongs to be able to mark the books as lended but not necessarily to who or should they be able to record who they lended the books to? Are the books editable after being added or not? Should there be a url for the digital edition visible to anyone or only a signed-in and authenticated person? Do we even want to support multiple people using the same instance of this library service? So many different things to consider and this can be a perfect opportunity to learn to use data while also being the one that defines what that data should look like. You get be the one producing and consuming the data which is not the case with 3rd-party APIs thus giving you the opportunity to figure things out on the way there. And speaking of accessing the data…

Interfacing

I’ve only spoken about server-side stuff this far (unless you count the output of jq -M as a frontend) but let’s round this out with the client-side. I showed some example JSON previously but in the intro there was a mention of a tech demo and you can bet I’m not writing REST for this. The main definition in my case is a protobuf file so I get control of the struct only as far as the proto v3 syntax allows. This presents an interesting challenge where there is limited or no option for annotations so no ORM (gorm for golang) can be used. Since I’m using gRPC with that and also want JSON to be able to be returned, a translation layer was used, grpc-gateway to be specific. With the ability to use JSON to communicate, a cli, desktop, mobile or web client can be made in a variety of languages while not losing the great service-to-service communication that gRPC provides. After having mostly nailed down the data structures I wanted to use and most of the entity-related functions I wanted to implement I decided to take a look at reactjs again. A post about it will come later after I’m done with this project but the example is given to demonstrate that you can pick something that can make an http request and process JSON then run off with it and build something. The way you choose access the library is noteworthy and can become another important part of using this concept as the example in a tutorial.

Conclusion

I believe the book/library example to be a very good one as a second step after a todo list one due to the complexity that it allows to be introduced in the data structures, the functions, the interfaces and APIs as well as the possibilities it opens up. Thank you for reading, I hope you enjoyed it and maybe learned something.

REST Is Over

Sun, 04 Apr 2021 17:33:02 +0300

Web APIs are terrible

After watching a talk a few months back about REST vs GraphQL and the history of APIs, I agreed with the speaker that the API is supposed to be a way of communication, a language of sorts. In programming languages this codified way of communication is enforced by the compiler or the interpreter or the runtime. If you write invalid code in the programming language of your choosing, it won’t work. Something or other will complain or break and prevent you from miscommunicating. This got me wondering APIs especially web ones are so bad.

RESTing comfortably

With the introduction of what we call REST nowadays, basically JSON over HTTP, it’s all too common for application to use this mode of communication. How this is enforced in practice is very variable though. From different path schemes, to the same HTTP verbs used for different purposes, to (invariably bad) ways to communicate from machine to machine what the API is, it’s all up in the air. Most fairly complex things that have a REST API, don’t even expect you to use them by directly interacting with it but instead use client libraries. This has been going on for about a decade or two and it seems things are changing. Some thought that GraphQL would be the end of that and it’s a pretty good step up but adoption is nowhere near as high. In general REST is the assumed default way to interact with something programmatically. Should it be though? Is GraphQL the best replacement we’ve got? I don’t think so.

gRPCee what I did there

A somewhat recent thing called gRPC started picking up steam. Talks about it, articles about it, large software projects using it but not really prominent on the web. With this nifty little thing after writing a file that describes what your program does, you can generate some ready to use code, write the logic and grpc.Serve() to the moon. Even better, anyone wanting to write a client in any of the many supported languages can generate the boilerplate for a client from the same definition file and start calling the functions of the server really easily. I’m being a bit simplistic for the sake of brevity but it’s really cool, trust me. It’s also really fast. Alright, it’s better than freshly baked bread apparently so why is it not used on the web? Cause it’s only HTTP/2 and the support for that is pretty limited. Fear not though, we’re going to circle back to our crusty old frenemy, REST.

Support for REST is widespread and there is a webdev in every city block ready to POST some JSON to your endpoint. So we can’t immediately get rid of the kludgy wart but what about giving pixel pushers some REST while service to service communication is improved? You see, since definitions exist for what the service sends and receives, the types of all the things being passed around, it’s quite easy to use some simple annotations to auto-generate a REST API. This doesn’t 100% fix the problems that exist but it does smooth over some parts of it. Okay so that’s it? Not just that, since the API is standardized we can even auto-generate documentation for it! OpenAPI (formerly Swagger) docs can be easily generated and served to potential downstream users of the API. Brilliant I think.

Conclusions

Over the past few months I’ve been reading a lot about gRPC, grpc-gateway, different ideas and implementations, trying out quite a few of them but I’ve yet to see one that makes me super excited and go “Aha! this is The One” or whatever. I could do a link dump of about 100-150 tabs that I have open but that would be tiring and essentially do nothing to help. Currently I’ve been trying to decide among 2-3 options for how a service should be structured and such but I’m still testing out prototypes, haven’t reached any conclusions. However, I hope this was a semi-educational read and got you a bit interested in the ecosystem. That’s all for now, I hope you enjoyed reading.

pardon me

~~check out the tutorials section for my Go REST API Part 2 coming soon~~ sorry, I had to :^)

Golang Is Fucking Rad

Thu, 18 Mar 2021 21:21:15 +0200

Radical Gopherism

I’ve been using Go for the better part of a year at this point and I’m loving most things about it. You know the typical stuff, types, compiled, fast, portable, easy to cross-compile and the rest of the goodness. However that’s not what made me stick with it although those things helped. The main things I liked were mostly that it was in many ways not like Java. There is no need for an IDE, the language is not endlessly complex, I can read other people’s code right away. Don’t forget the compiler-enforced formatting, easy static compilation allowing for tiny container images. The standard library is also phenomenal if frameworks are not your cup of tea it’s very possible to avoid them in a lot of cases. And the new file embedding functionality? Amazing, my site is now a portable self-contained binary. And the adoption? Practically any project I’m interested in just so happens to be written in it! Most things I use, kubernetes, docker, terraform, vault, gitea, droneci, fluxcd, minio and more I’m probably forgetting.

Reality

Time to stop drooling though. While I wasn’t inaccurate or misrepresentative above, I want to look at pros-cons for a moment.

Dank Reality

The main thing I do is write backend web microservices and small operating system utilities. As mentioned previously, the stdlib is amazing and quite a few things I’ve written use that almost exclusively. If web frameworks are needed, there are plenty from piece-by-piece like gorilla, go-kit(depends if you count it) or go-chi, to all-encompassing gargantuan ones like go-micro (ironic name, I know) to middleground solutions like gin-gonic. I can find client libraries for everything I want be it any sort of api, databases, application messaging systems and recently I found out I can even run ML models generated by keras in python from go. I didn’t harp too much on this before but the static compilation is sweet. Using docker multi-stage builds and starting from the 150MB fat golang image with devtools in it but then being able to run the resulting binary in a run stage based on scratch and have a 3MB production image is incredible. I use it more and more every day and basically haven’t looked to shell scripting for anything except heavy string manipulation but even there I’m starting to move as see in gopasswd.

Sad Reality

This site is my doomer cabin in the woods so the fun stops here. Also lists are scary so let’s go

language package manager: having maintained gentoo ebuilds, I’ll never not hate language package managers
not very competitive alternative compiler: gcc-go produces slower artifacts and I don’t want a dotnet situation
google is very heavily involved: the pkg.go.dev shit just showcased it but I’m not comfortable with google being involved and yes this goes for k8s as well
grpc support: google came up with grpc and is too involved in go but you need a 3rd party plugin for protoc to output go which is stupid
dev2prod: translating from local to remote dependencies and vice versa is handled poorly
modules: kinda weird, I’ve come across too many cases where rm go.mod go.sum && go mod init && go mod tidy was needed
generics: don’t want generics but everyone is begging and the advantage of small and understandable might be lost in the future

Conclusion

Good language, fits what I do, like using it, will continue using it, wish some stuff was improved or fixed. That was all for this post, I hope you enjoyed.

Computers Were Faster

Tue, 29 Dec 2020 17:10:41 +0200

I own 3 operational 32-bit computers and I find them fun to play with and useful for software projects. Two of them are socket 475 and one of them is for slot form factor intel cpus. For the slot form factor one, I have a Celeron, a Pentium II and a Pentium III. The socket 478 based ones are much closer to usable for most of my use cases and the other one is fun to tinker with. How can that ““obsolete trash”” be useful, one might rightfully wonder.

My Use Cases

Development use case

Computers with less than 4GB of RAM and 2 cores are completely unusable and nobody should ever touch them, a “muh modern” advocate might cry. However I use those computers at least once a week for various tasks. First off, as a 32-bit docker registry. They don’t need to mix with the rest of the environment since there is no actual dependency between the 32bit and 64bit infrastructure. In addition, I can see how long it takes to build a certain image based on my software, test its performance and experiment with multi-architecture images. I would do the same thing for the raspberry pi but I only have one and that is not enough to warrant the effort. If the above wasn’t enough, they are very useful for testing things such as bare metal provisioning with a mostly DIY setup, how to configure new things I’m interested in such as the aforementioned DIY bare metal provisioning solution as well as new software stacks like ELK or TIG. They are also useful for API load testing and discovering where the bottlenecks are in a piece of software. On a newer multi-core cpu with loads of RAM and fast storage the bottleneck only shows up when the workload origanically overwhelms the software. However on a more limited system it becomes apparent very quickly where the bottleneck could be. For example, if the hard drive access is more than it should be, you hear the damn thing click every time so you know where to look.

Networking Use Case

In addition, old computers make great routers. Routers? They’re old and weak computers you might think. Well, that anemic MIPS or ARM based all-in-one network box that many ISPs provide you with has a CPU that is orders of magnitude slower than either of my 32bit boxes. For the router use case the same thing applies to the amount as well as speed of RAM. In fact, that’s how I originally got into DIY and selfhosting. The case that used to hold my server had one of the 32-bit motherboards and cpu and ram as well as a hard drive. After finding about pfsense and having that computer as a spare, naturally, I gave it a try. A quick install of pfsense later and I was learning about DNS, DHCP, ARP requests, MAC addresses, gateways, how to set up an access point and started my journey into learning about networking. Another use that requires a somewhat low-cost investment is getting a picoPSU or microPSU or something to that extent to power one of those 32-bit machines, connect it to a TV and use it as a dashboard display for monitoring software.

That’s not the end and imagination is the main limit into making this sort of hardware perform a useful task.

Conclusion

Before you go around calling older computers obsolete, check if PEBCAK is the bottleneck. Thank you for reading, if you have a cool project using older hardware, feel free to let me know.