DEV Community: Joe Ivans

Not Committing Frequently Enough? Clone To RAM Disks!

Joe Ivans — Mon, 15 Nov 2021 10:18:41 +0000

What are you nuts? RAM is volatile!

You ever tell someone you're working with to save a document and they go, 'Oh ya, it has autosave... sooo.' Well, git doesn't do that. In fact, git doesn't care about how you choose to use it; it was designed that way by Linus himself for fundamentally good reasons.

Git also doesn't help you with your stale branch problem -- again, for good reasons.

As an FYI, if you haven't experienced this yet, management will freak out if you don't push code at regular intervals -- I reaaaally want to say this is also for good reasons.

So, in order to make the team happy, I've developed a workflow I use to ensure I'm always rebasing, adding, committing and pushing. I make the fear of losing the code a reality. I'd like to share that fear with you now.

Like a good engineer, RAM doesn't hang around long, and neither should your feature branch

RAM actually disappears, unlike most hard drives, statistically

So, if I know that every second is a huge risk for my branch, because it's sitting in a RAM-backed virtual disk and not on a drive, I'll fetch/rebase/ACP it more frequently (FRACP??! - this is not a thing).

WARNING. What could possibly go wrong?

Unlike the potential hard drive crash dilemma, you actually will lose work on a RAM disk. Make sure you actually add/commit/push your work so it doesn't go to bit purgatory.

WARNING. What could possibly go right?

Personally, I like getting a fresh clone when I go back to a repo to work on it after some time has passed. Whatever's deployed now certainly doesn't match that crusty old thing that's been hanging around for three month's worth of time machine backups... with a ton of .gitignore excluded files that nobody else can see. Should I really spend time rebasing all my stale branches? And what about all those freaking node_modules, just sitting there?

Cool story. Let's try it

Try it on Mac

Fire up your terminal.app and type in the script below to mount an ~6 Gigabyte RAM disk called git:

diskutil erasevolume hfs+ git `hdiutil attach -nomount ram://$((6*512*4096))`

Then you can clone something to it and start working. This example clones the amazing Algorithms 4th Edition book source code:

cd /Volumes/git \
&& git clone https://github.com/kevin-wayne/algs4.git \
&& cd algs4 \
&& less README.md

# if you're stuck in the readme, press q to quit

Try it on Windows (using WSL / Ubuntu)

There's a way to do this using PowerShell but I think it's kind of clunky. There's tons of info on this out there, and there's also some paid utilities you can get. But my approach is to use WSL Ubuntu because that's what I'm mostly using on Windows anyway.

My approach is adapted from linuxhint's great tutorial.

# make the mnt directory
sudo mkdir /mnt/git

# mount 6 GB of RAM under the directory
sudo mount -t tmpfs -o rw,size=6G tmpfs /mnt/git

Now you can also clone the awesome Algorithms 4th Edition book source code:

cd /mnt/git \
&& git clone https://github.com/kevin-wayne/algs4.git \
&& cd algs4 \
&& less README.md

# if you're stuck in the readme, press q to quit

In Windows Explorer, you can go to \\wsl$\Ubuntu\mnt\git to access the RAM disk in the GUI.

Mac/PC/Linux, it's easier to stay in one environment

I like Windows and I like OS X. But as an engineer I need to speed up my setup process. So I choose to use the OS X Terminal on OS X, and the WSL Ubuntu on Windows. Most of the terminal navigation is the same. Much better than jumping between PowerShell and z-shell.

Other uses for RAM disks

I do this workflow on the Mac all the time, not just for code things. Especially with filesystem stuff like zip/unzip or Chrome's temp files, which don't need to eat up my SSD lifespan. I'll fire up a RAM disk, get the final state of things I need, move them off the disk (or not), then unmount the drive.

Until next time

I hope this article helps you. It's actually the second one I've ever written. This workflow has helped me over the years and I wanted to share it with you in case you're struggling with finding a productive ACP workflow. Have fun out there, Joe.

I Disregard Tedious Grammar Rules For The Same Reason Your MVP Sucks - On Purpose

Joe Ivans — Fri, 12 Nov 2021 20:48:20 +0000

Your MVP is not a finished product. If you spend too much time thinking about your product, you'll never have a product, because no-one will ever get to use it. Why don't you just deploy something small that somebody actually needs? You can just fix it after you find out it's wrong. But you need to fix it fast. - Joe, this guy, right here

I know what you're thinking

Rules are for professionals. Smart people made the rules. Maybe I should follow the rules. You know, the same rules that everyone follows. If everyone follows them, maybe they're correct?

Ya, maybe. But so what? Are we thinking about things at all or following rules? Are they simple rules? How serious are these rules? Can people get hurt? Will I fail? Will I be the cause of someone else's failure?

Will these rules persist long after I'm gone? If not, will I have been wrong for following the wrong rules?

Should I have therefore been thinking about the wrong rules and why they're wrong?

Or do I just want to get to a minimally viable product?

I had some great opportunities this week.

One of them was the freedom to just write stuff down. I feel the same way when I code just for the sake of coding. I realized today, when trying to blog for the first time, that I forgot a bunch of grammar rules I learned back in my school days.

And then I thought, should rules prevent me from doing something?

Probably. But it depends.

It depends on everything!?

There are so many things to think about. And man, I could go off. But, what's important? That's usually a good start.

When I'm writing software, I usually think of how cool I can make my code. I say usually here because I still think of optimization at the wrong times, but at least I catch myself and go "Hey Joe, STOP IT". My customers have never cared about the cleanliness of my code. But they do care when I can't change it quickly. That's a personal rule I choose to follow because of experience writing code and having customers change their minds. This pretty much sums up the point of agile software development.

But it doesn't quite sum up my problem with grammar rules. I'll tie that in now.

If I cared so much about my code, more than delivering my product to a customer who is waiting anxiously for me to produce value for them, would that choice cause me to fail? Yes.

If I cared so much about my grammar, more than --just starting my blog--, would that prevent me from --starting my blog--? Yes.

So there it is. Rules in real life are just personal guidance usually preventing us from making mistakes.

Agile rules. Magic Bullets And All That

I don't mean that like "Agile is the best".. I mean that like, "Agile is now like a thing and an action combined instead of a bunch of good ideas that you can cherry-pick as long as you actually know what the hell you are doing".

I can take Agile's rules, write an Agile Rule Library and share it on NPM for JS consumption, and share it on NuGet for .NET consumption. Or you know what, maybe I'll create AAAS - Agile as a Service - feel free to pronounce that however you see fit. Then that should fix everything, right? We'll all be on the same rules, our work will get rejected when it doesn't fit the rules and we can all live happily in Agile bliss, analyzing our work against the rules, making up story points for making up story points, and staring at charts until we realize - we have no MVP to deliver.

OK, What Does This Have To Do With An MVP?

Agile is a word. Neo from The Matrix is agile because he 'moves that fast' and Trinity 'never saw anybody move that fast'... 'how do you move that fast,' she asks him. He, due to a well-encapsulated system designed by 'the machines', doesn't know how to answer that question.

If a customer asked me anything about my code, I would have the same Keanu Reeves look on my face. My reason though would be more like 'Did something go wrong? How are you seeing the code? Tell me what's wrong with the thing you're using so I can deliver a better thing.'

The bottom line is this: You gotta deliver fast. You gotta get and respond to feedback fast, directly from your customer. But you gotta remember, your MVP will suck until it's not an MVP anymore. It's up to you to ask why it sucks and do something about it. And hopefully move as fast as Neo does.