Ruby Fork Bomb

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:

Programming Bookshelf

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.

Comitting To Go Lang, on its 8th Birthday

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.

C++ and Game Engines

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…

Code preferences change

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?

Ending up on Go

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

    • Ken Thompson worked side by side with Dennis Ritchie during the development of C and Unix. He’s the father of Unix, and worked at Bell Labs up until 2006. Since ‘06 he’s been working at Google, and began buiding Go sometime after that. Needless to say, if Ken thought it’d make sense to improve upon C, I believe him. I also believe there must’ve been a very important reason to improve upon our current language options, since he released the language at 66 (he’s 74 now). So basically if Ken built it, I cosign it!
  • Vim support is vast

    • Most of the times when I use a compiled language, it’s very important that I setup my IDE (xcode/vscode/vs2017). Always a pain in the ass for a Vimmer. What are all these GUIs?? Y U NO WORK FAST?? Well go has an amazing vim plugin with tons of useful functionality, and a lot of the official go videos are livestreams using this plugin! I was instantly supportive of that and it helped me get up and running much faster.
  • Go HTTP Suppport + Revel

    • Now, more relevant professional reasons. Most of my days are spent building API and a wide variety of clients. But at the end of the day, they all talk to some API. Go is awesome for APIs. Go HTTP is well documented as a high performant HTTP server. Revel is what interests me, a rails-like framework for Go. I long for structure, convention, etc that most compiled languages don’t enforce (you should know what you’re doing and how to organize software). Though I haven’t used it, it seems to be well supported and in Go that will ‘go’ a long way.
  • Command Line Utilities

    • Go has as ton of command line utilities, almost more than ruby now. gocui was what caught my interest, and I’m super interested in using that lib. The go toolset is a little bit of learning curve to non-nixers, but to me it was a welcome home. Just type the help command and start trying stuff.
  • Good Programming Habits

    • Go makes you a better programmer in any language, plain and simple. A big qualm with ruby for me, is and was, learning ruby first. I mastered 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.
    • Go again solves that. Go files will have all dependecies clearly imported. Go requires you manage your types, but if not, they will inferred in certain cases. Go offers traditional ways of declaring vars (literally var c string = 'hello'), along with syntactical sugar. Little utilities like their Time hierarchy etc have been a joy to come across.

    • Go’s STD LIB is heavy. There are some amazing tools baked right into Go, which you have to install in other languages. I’m talking crypto/http/more. Take the time a look for yourself.

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 :)

Onward to 2018

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

  • C++
  • Go

Game Engines

  • UE4
  • Unity

Digital Art/GUIs

  • Blender
  • Meshlab
  • Zbrush

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!

Exit Code 127

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.

Bundling a node module on github

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.

  1. Package the module
  2. Upload to git
  3. Install with url

Package the module

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.

Upload it Git

Push it up to git like always

Install with url

To install via cli

npm i git+ssh://<author>/<repo>.git --save

Or add to package.json

"your-package-name": "git+ssh://<author>/<repo>.git",

Vim set nocompatible mode

This lil post is about a single setting in Vim that you’ll see in just about every modern .vimrc.

set nocompatible

“nocompatible” is a mode that I feel most aren’t familiar with, which is seeded in a lack of knowledge on the history of Vim.

Vim stands for Vi (Improved). Essentially all that means is Vim has modern tech built into it, Vi is antiquated and wonky.

Would anyone still prefer vi?

Realistically, they shouldn’t. But plenty of people will have to work with vi day to day, just because their OS or shell can’t (or won’t) run Vi(m).

So set nocompatible is described as such in the Vim docs:

This option has the effect of making Vim either more 
Vi-compatible, or make Vim behave in a more useful way.

You can see all of the the options related to nocompatible here.

Just wanted to illuminate the meaning behind something I see in every .vimrc (including mine), yet most people don’t bother to look up.