sikrob

[sikrob]

Linux for the Day Job

I am actually figuring out how to use Linux for my day job. Wild!

It helps that my work is basically just webdev right now. Anything outside the scope of that is just the odds and ends and usually in the realm of helping someone else deal with a bug that’s more on their plate then my own right.

So my tech stack is heartily supported by the Linux community already – if not Linux first, it is at least a close second.

So what distro? And what tech am I actually using?

Distro Hopping No More

I’ve played with a fair few distros in the past, but initially settled with running Ubuntu for a little while. I ended up having some issues with part of my system, and in a fit of exasperation updated out of the LTS install and into 19.04... which lead to even MORE exasperation.

So I decided to try out System76′s Pop!_OS, which is an Ubuntu variant but geared more toward developers, or so it claims. And you know, maybe it is.

I found Pop!_OS a little bit easier to get running than Ubuntu, but only by maybe two steps difference. I documented my setup both times to compare and I’ll give that it was a little less of a head ache. The minimal differences make sense since it is still Ubuntu under the hood.

I ended up screwing up the install within a week of tweaking and blundering my way through Linux stuff. This time I was smart enough to follow the recommendation to install /home on a different partition, though, so reinstall was an inconvenience more than a real problem.

I’ve decided to stay settled into Pop!_OS unless or until I run unto a real reason that I can’t keep using it.

What Technologies am I Using?

90% of my job is fullstack webdev.

On the front end, I am using JavaScript or TypeScript and usually React + Redux, although occasionally Ruby on Rails. NPM and Webpack go nearly without saying.

On the back end, I am using Ruby with Sinatra (usually with Puma), and occasionally Ruby on Rails.

DB wise, Postgres and Redis, although truthfully I rarely have to mess with anything Redis related. My main work with DB calls is just trying to make existing PG calls faster or more compact, or figuring out how to structure new calls so that they will be fast enough.

Deploys and everything are all handled via GitHub/GitLab CI pipelines and AWS.

Environmentally, I use rbenv, but mainly because it’s what I know vs RVM. Most of everything else is determined by the project, with newer stuff using newer versions of whatever, and older stuff using whatever the project dictates. As is often the case, projects remain mostly contemporary to themselves except for security or performance issues – which thankfully our team actually cares to go through the trouble of updating for when we find out about this or that! The horror stories you read online sometimes make you wonder what’s going on out there!

What about the 10% that isn’t webdev? Well, truthfully, it’s still mostly internet related, just not as much “look at this website”, which is what I think most people mean by webdev. I think all of the remainder is in Ruby, although I’ve written the odd bash script to make my own workflow easier.

Outside of work, I continue to mainly dabble in more web or in Swift programming. I am getting interested in climbing back into the familiar world of C#, though. I used to feel like I could do anything with the power of dotNet and I wouldn’t hate getting back to that! All of that is supported in the Linux work environment, so no issues there either (although I haven’t actually tried to setup either on my current install yet...).

[sikrob]

Unity 2D Collision Gap

If you are diving into Unity2D and noticed that your objects are colliding but that a gap is always left between them, you are not alone. In fact, it turns out that this is just the way it works for Unity2D. It’s kind of crappy, but I supposed the price you pay for all the nifty freebies you get with Unity generally (and perhaps for using an engine that is really/originally designed for 3D).

Anyway, here are two of the more popular approaches people use to address it (based on diving through StackOverflow, Reddit, and Unity forums, at least):

I. Hand Craft Collider Shape/Size

Basically, you know that colliders of exact size will leave unseemly gaps, so you can just work on fine tuning the colliders to be slightly smaller so that the objects will collide without gaps.

This is perhaps the most straightforward approach because it allows many other default aspects of the Unity2D set up to work out of the box.

The downside is that you have to fine tune EVERY collider, more or less. A lot of manual work. Maybe it counts as doing good QA?

II. Adjust the Size of the Objects in the Project

This one works by essentially just letting the gap continue to exist but reducing it’s effective size – by just growing your project around it!

You accomplish this by, for each sprite asset you will use for your objects, setting the Pixels Per Unit from 100 to 1. I’ve read that if you use gravity, you will also have to adjust gravity from -9.81 to -981, although I haven’t played around with that when testing this stuff for my own project since I wasn’t working with gravity. You should adjust your camera scale as well.

(We’re blowing everything up by 100 times, essentially.)

Now you may have to adjust the kinds of values you expect for things like movement or whatever, but if you set up your project from the get go for this, you basically can just go on your way, at least in theory.

With this approach, the gap will still be there, but the idea is that it will be about 1 pixel in size or so, or essentially small enough to be safe to ignore.

Now What?

From what I can tell, there are plenty of people using either approach. I’m going with the first approach for now because I’m still working on my first Unity2D projects and I don’t want to accidentally create a new problem by using the big scale approach, but on the other hand the second is a common tactic – surely, if there were real issues with it, people wouldn’t vouch for it so often?

I definitely see myself trying the second way sometime soon. The hand manipulating approach for collision is fine for my current project where collisions just aren’t that important (or at least aren’t now), but I could actually see a project more dependent on that preferring the second way so that you aren’t stuck getting into the nitty gritty of every single piece, even on simple shapes! After all, even if you use the second approach, you can still fine tune the colliders.

But yeah, I’m going method one for now. We’ll see how it goes.

[sikrob]

Confirms something I’ve suspected, that iTerm2 is just not that performant compared to the default macOS Terminal app. It has one feature that makes me, as a human, faster on it, though, and that is the very decent autocomplete on `CMD-;`. The main benefit is that it lets me keep my git branch names descriptive, and I’m manipulating and working between branches constantly for work, so this is not a small thing to me.

How hard is it to make a terminal emulator? I had an idea to do so once before, but never got around to it. Hmm.

[sikrob]

mini2Dx, I guess?

Starting to play with mini2Dx because Slick2D is just so woefully left behind. Took me about an hour or so to get it going between looking at different things and just fiddling about on my computer. It’s been a while since I’ve done any game dev stuff, so bear with me...

One discouraging thing, the project builder, while apparently handy in all other regards, has an error in how it sets up for IDEA on macOS. The line that sets the texture in the initial set up reference the path for the asset directly. This causes the asset to be reported as missing.

The fix is to append “assets/” in front of the image name:

texture = new Texture("assets/mini2Dx.png");

I’m going to give this a go, though. Worst case, I have several projects in Slick2D I can go back to... it’s not like it’s going anywhere, for better or worse.

[sikrob]

Oh, okay. Makes sense.

[sikrob]

A bit dated, but a nice view on using the MS Natural Ergonomic 4000 Keyboard  with a macOS computer. Man, the name of this keyboard sounds straight out of a science fiction spoof. Still, it’s a decent ergo keyboard (or seems to be for my wrists) for way cheaper than most competing products.

My only gripes are: 1) I wish it didn’t have a number pad since that keeps the mouse far away and defeats some of the ergonomic gains. 2) The spacebar requires too much force for long typing sessions unless you remember to float your thumb over near the center. This isn’t undoable for me, but I have large hands. I’m also not sure if that defeats any aspect of the ergonomic gains. 3) The general feel of the keys is kind of mushy and unsatisfying. I know it’s crazy to have opinions on this if you’ve never noticed, but… man, how could you not notice.

Still, the keyboard solves the problem I wanted to solve, at least until I can afford to buy something nicer. Ergonomic keyboards get too expensive very quickly.

[sikrob]

A Short Guide to Using NSMenu (macOS Application Menu)

Coding new items into and watching for actions from the macOS Application Menu (aka: the main NSMenu and NSMenuItems, the menu bar at the top of the screen) is very easy to do, but I found kind of difficult to learn about if you want to just dive into making applications for macOS.

But rather than dwell on the frustration, let’s get straight to the how to. Note that this will not be an exhaustive guide but rather is based solely on the functionality that I needed at the time I was learning this.

Case 1: You want to implement basic menu commands such as New, Save, etc.

These commands are wired up to default menu items or are available as options that you can create a menu item for (creating new menu items is easily accomplished in the InterfaceBuilder right on your Storyboards or Nibs). These commands are sent to and acted by the First Responder that can do it.

In fact, for some of the pre-wired items, you will see the menu items start disabled – but they automatically become enabled as soon as there is code implemented that would get called somewhere in the responder chain! This is done as simply as just writing in the methods that those menu items would react to, perhaps in whatever location is most appropriate to react to it – your view controller might be good if you need to open new windows, for example.

Case 2: You want to create a menu item that does an action

Easy peasy. Create the menu item and control+click it into the AppDelegate, pretty much just like any other typical action. Note that the receivers of the Menu Item actions appear to be limited. I’m quite sure you can get around that, but I didn’t really need this functionality so that’s as far as I bothered to look.

Case 3: You want to create a new menu item that stores a choice.

In my own example, I wanted to create a “Dark Mode” for a text editing field.

First, I added a new Menu Item into my Storyboard. Next, (still in Interface Builder view), I opened the Bindings Inspector (7th tab of the right side column). Then, I expanded the Value section and clicked the “Bind to” checkbox, with the dropdown set to “Shared User Defaults Controller”. I left most of the options default, but I set my own value for the “Model Key Path” field. In my case, I used “darkModeEnabled” but you can fill in whatever you need there.

At this point, the menu item I created is enabled, and if you click it while the application is running, it will either gain or lose a checkmark next to it – and that choice is saved between launches of the application thanks to being bound into the Shared User Defaults Controller!

Of course, it doesn’t do anything yet. Since I want to be able to change the colors for my view each time this value is updated, the best way to implement this would be by adding an observer that track this change. I did this in my viewDidLoad method for the soon-to-be-affected ViewController.

In Swift 3, this looks like (note the forKeyPath must match or Model Key Path defined above):

       let defaults = UserDefaults.standard        defaults.addObserver(self, forKeyPath: "darkModeEnabled", options: .new, context: nil)

This adds my ViewController as the observer, checking for changes on darkModeEnabled, and looking specifically for the new value of changes.

Next, I override the method that allows my observing class to react to these changes when they are reported:

    override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {        if (keyPath == "darkModeEnabled") {            let darkModeEnabled = change?[.newKey] as! Bool            updateUiFor(DarkModeEnabled: darkModeEnabled)        }    }

Et voila! Now my updateUiFor(DarkModeEnabled) method will be run any time the menu item is updated and it will always match that menu item! And since my ViewController is always watching this value and this value is saved between application launches, I gain for free the ability to persist the choice to have Dark Mode on or off!

I really hope this was useful to any other people out there who have pointlessly struggled with trying to wire up menu items for macOS. Happy developing!

[sikrob]

This is awesome.

I want actual Visual Studio in Mac OS, but like first class support of Xamarin can’t be bad.

[sikrob]

I try not to just post crap I see on Reddit, but this is just so utterly delightful. Okay, maybe it’s more of a schadenfreude kind of thing.

I haven’t used something like this a good long while but man if this doesn’t just take me right back to undergrad!

[sikrob]

I enjoyed this read. I don’t think anything revolutionary but it does help explain why different teams make the choices that they do.

[sikrob]

Got frustrated with the absence of a free, simple text editor that provided a full screen (aka “distraction-free”) mode. Literally all I want right now. Has bugged me enough that I decided to just write one.

I’m certain that it is a bit cobbled together right now. It isn’t complete yet either. But it is pretty fun to watch these little projects come together.

I’ve been using Swift and diving into OS X development for this. I’ve learned a few things already, including a way to handle dealing with OS X Application Menus and a (probably flawed approach) to saving documents. I’ll have to figure out what the right way is and fix it all up.

More annoyingly, it didn’t occur to me to TDD this thing until about halfway through for where I am currently. I think I’m going to just start over and TDD it for the experience of creating my own app from scratch using TDD as opposed to following examples or tutorials.

Hoping to join a local Cocoa meet up soon. A bit bummed that it clashed with my time at the climbing gym, but it’s only once a month. Besides, I think this will help me to focus better on personal projects.

But regardless, I was able to pen this whole thing using my little text editor. Always a good feeling.

[sikrob]

A bit dated, but I found this useful in understanding how to deal with something that requires using FirstResponder – in my case, learning to deal with Application menus for OSX applications.

[sikrob]

I’ve finally implemented the Game of Life. Fun little thing. I’ve used a walled garden here, will get around to a wrap around garden in the future at some point.

[sikrob]

Launching Powershell Scripts with C# without Automation via Batch Scripting

Step 1: Write a batch script that launches Powershell with the Powershell script. Remember to set the execution policy since this is going to be launched by a process.

Example:

Powershell.exe -ExecutionPolicy RemoteSigned C:\Users\myUser\Documents\myScript.ps1

Step 2: Write your C# code to launch the batch file. As a bonus, I also capture the standard error and output below to assist with diagnostics (good for catching incorrect usage of quotes, for example).

Example: (with “using System.Diagnostics;” at the top)

try {     ProcessStartInfo startInfo = new ProcessStartInfo(”cmd.exe”, “/c “ + batchFilePath);     startInfo.CreateNoWindow = true;     startInfo.UseShellExecute = false;     startInfo.RedirectStandardError = true;     startInfo.RedirectStandardOutput = true;     Process process = new Process();     process.StartInfo = startInfo;     process.Start();     process.WaitForExit();     string errorText = process.StandardError.ReadToEnd();     string outputText = process.StandardOutput.ReadToEnd();     int exitCode = process.ExitCode;     // output the above values in your preferred way here     process.Close(); } catch (Exception ex) {     // Do stuff with your exception. }

[sikrob]

A great view in general if you work with Java. Pretty neat talk that starts with a pretty high level look at Java and drills down quickly to some interesting aspects with regards to working with the JVM.

[sikrob]

The above link has the answer! Well, it has a workaround, anyway.

This problem seems to be caused, although I couldn’t say if it was directly or indirectly, by the Storyboard "Use Size Classes” option being checked (visible in the File Inspector right side bar of the Storyboard file. No idea exactly why, but I bet it has something to do with the way that the Size Classes set up uses unique seeming views when looking between classes. Just a hunch with no substantiation, but it kind of makes sense in a terrible, why-oh-why kind of way.

The Size Classes are the ‘fun’ new thing whereby you capture several form factors at once using the Storyboard. They are apparently still full of growing pains or else require alternate approaches, as given in this example. (Actually, they seem pretty neat. Well, potentially neat.)

Threw me for a loop – I was working through something to POC some stuff for a project I’m working on and thought I had somehow completely forgotten how UITableViews work. Very frustrating feeling!

Turns out, it’s not the old stuff but the new stuff that I need to keep more on top of. Hazard of only doing iOS coding part time for fun, I guess.

[sikrob]

I hate the actual title of this article so much I almost didn’t read it, but at the end of the day I’m glad I did. So I shared it with a more descriptive title about what the article will accomplish.

Basically, it just outlines a line of code that you can add to your makefiles to easily view information on variables in your makefile. Handy.