I use GPG for most of my personal encryption. Basically, if i need to have a sensitive file sit at rest on my hard drive, i like to have it encrypted with GPG. Recently, I had a sqlite DB file that was encrypted with GPG for transport. It’s not updated frequently, but it holds private information (not necessarily sensitive). Thus, it was encrypted.
So i want to access this DB via some node scripts. Turns out, like most things in the JS world, there’s a package for that and it’s quite easy to use.
Install GPG
brew install gnupg
Setup your primary key
This step can be confusing if you’ve never encrypted anything. If that’s the case I’d suggest installing a GUI application for GPG on your OS.
Install node-gpg in project.
npm i gpg
Now that your GPG file is setup globally, you can just use a simple method to decrypt files!
gpg.decryptToFile(
{
source: "./secrets.json.gpg",
dest: "./secrets.json",
},
(err, success) => {},
);
EZPZ.
Was researching some interesting concepts in UNIX and came across an interesting form of DOS attack, the fork bomb.
Essentially a fork bomb infinitely loops over a command that forks a new process. In doing so you use up all the available memory on the machine. Leaving the commands here for future reference and notes on how to prevent.
In bash:
:(){ :|: & };:
In ruby:
ruby -e "loop { fork { bomb } }" &
In perl, available on mac:
perl -e "fork while fork" &
To limit the max # of user forks, edit the /etc/security/limits.conf file. It’s worth noting that ulimit -u 100 will not prevent a fork bomb, as it only sets “soft” limits.
Good references here:
I started stacking up my programming books this morning, and realized how much I’d gleaned from the writing of other programmers. It’s no coincidence if you go looking for answers, you’ll find them.
I’ve started a github repo where I’m holding the notes of this reading, and I’ll be getting all my recommended software books into a nice pretty little list on here. Since I’m in a new book every couple weeks, it should be fun to keep up to date.
Books gave me ideas in software. Writing software helped me learn how those ideas and patterns work. All of the books I will upload are written my likeminded programmers, who tend to agree on the subjects: testing/TDD, refactoring, design patterns, etc.
A few books that shaped me as a software engineer:
Design Patterns - Gang of Four
Clean Code - Uncle Bob
Pragmatic Programmer - Hunt/Thomas
Hopefully me documenting the notes/books I’m reading will inspire others, help them on their software journey. Looking forward to doing some open learning.
In light of my recent post, I thought I’d give some insight into a not-so-small decision I’ve made.
I’m comitting to using the Go programming language professionally.
Now, there’s lots of articles sharing the praise of the Go programming language, and rightfully so. But this article will be more a personal excerpt of my last few months, and how I ended up adopting (in process of) this young systems programming language.
For the last few months, I’ve been writing a lot of game code. I find it challenging, fascinating, and ultimately rewarding when you can write code that impacts gameplay. All of the engines are built in C/C++, and then either expose C++ APIs (UE4), or allow scripting of the engine via C# (Unity).
C++ is great because of its power, bredth of use, and age. The creators are still working on the language, and that means a lot to me. The specification is thoroughly documented and there’s literally enough information to pour over for years (think 1986 release).
Well this led me into…
I write ruby/js most of my days, and I have to say I love statically typed code! It just clicks for me. This article is not about static vs dynamic typing systems. I just want to be clear that my last 3 months have been interesting, as I’ve realized something about myself. I prefer to read code with clearly documented types, and compiled languages favor that.
So, I start getting frustrated writing ruby. I start documenting types more. I even started building a simple ruby TypeChecking mixin to use as I need. Funny right?
I’ve had my eye on Go for awhile now, but never felt the need to make the jump. With my day to day including more C++, I’ve found the need to reevalute the langauge as an option. Here’s why I’ve made the decision:
Go is compiled, and portable
coming from ruby, a big complaint of mine is installing the runtime on a new machine, and then managing that moving forward. Look - I get it - RVM! RBENV! CHRUBY! It’s great. But sometimes I’d like to just download a binary, move it into my path and call it. Especially for devops tasks. Go solves that problem for me.
Go’s also readily available on Windows/Mac/Linux. I can download the installer from their website and be up and running on any OS (i have machines with all 3 installed), and get back to work. The best part is, my vim setup will actually be useful!
Go is built by Ken Thompson (and other CS veterans), so yeah
Vim support is vast
Go HTTP Suppport + Revel
Command Line Utilities
Good Programming Habits
each blocks before I knew about control flow as a topic in a language. I never really got great at looping over numerical objects, without the range or .times operator. Now, ruby made all of that enjoyable no doubt, but I couldn’t transfer my knowledge of those ruby APIs over to other languages. Shit even ruby abstracts public/private into attr_accessors/readers, and constructors into intialize. You almost never have to import stdlib files in rails, becuase they’re all baked in.var c string = 'hello'), along with syntactical sugar. Little utilities like their Time hierarchy etc have been a joy to come across.STD LIB IS SICK!
Overall, I still have a lot to learn about the language of Go, but I’ve had fun writing a few little CLI apps and learning about what real problems I could solve with it. I started taking notes on Go’s 8th birthday, when I realized that was the case. I took it as a sign and committed.
Happy 8th Belated, Go :)
It’s been awhile since I’ve posted something on the blog, and I’ve wanted to fix that. I took some time to reflect on the purpose of this blog and what I’d like it to do. This post details my plans with it moving forward.
This blog and website have always had the purpose of representing me and what I’m working on in technology. While it displays my experience clearly on the homepage, it falls far short of keeping the picture accurate and up to date.
A large part of my free time is gathering research across a wide variety of technology topics. Scattered across a dozen or more areas, I literally have notepads full of potential app implementations, source code reviews, tool evaluations. From esoteric unix tricks to meaningful patterns and practices, it’s there when I need it. Regardless, I wish I would’ve posted that research when I wrote it down, rather than leave it on paper where it’s not programatically accessible.
So moving forward, it’s my intention to post all of my research to this blog and have it serve as the public repository for things I’m learning. Right now that list consists of:
Programming Languages
Game Engines
Digital Art/GUIs
Of course, I’m using ruby/js/vim/bash daily. All of my projects are deployed to AWS. So new research in those areas will always be included.
This post makes it official. Look forward to knowledge!
Recently was running docker containers, and was trying to curl a tar file to unpack a binary.
Ran into the error:
returned a non-zero code: 127
If you’re getting this code, you probably are calling a command that’s not globally available. In my case, I was calling wget/curl – both weren’t installed on the docker image yet.
Just a quick note to self - non-zero code 127 means check your dependencies.
Sometimes you need a quick and dirty way to share a node module. Just ran through this and thought I’d post it.
The easiest way to share a module is via github.
To package your module, set your entrypoint in package.json, and make sure you export the package however you’d like it to be consumed.
Push it up to git like always
To install via cli
npm i git+ssh://git@github.com/<author>/<repo>.git --save
Or add to package.json
"your-package-name": "git+ssh://git@github.com/<author>/<repo>.git",