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...).
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.
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.
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.
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.
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):
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!
Developers everywhere make mistakes. Sometimes, you have to figure out whether or not you are losing your tenuous grasp on sanity. Here is a practical hall of fame (shame?) of examples, and, be honest ā we've all been there.
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!
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.
Do you remember, back when you first opened Interface Builder? How long did it take you to understand the purpose of Fileās Owner? That is a proxy for the object that loads this NIB, usually ā¦
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.
Slick-Game-of-Life - An implementation of Conway's Game of Life in Java using the Slick2D and lwjgl (v2) libraries.
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.
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.
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.
}
For years weāve been told that the JVMās amazing optimizers can take your running code and make it āfastā or āas fast as C++ā or āas fast as Cāā¦or sometimes āfasterā¦
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.
I am using IOX8 and Xcode 6. I created a table with a customtype cell in storyboard, and I placed a label in it. I entered a tag number for the label in the IB, so that I could retrieve a reference...
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.
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.
