A coworker blamed me that our git server is rejecting his changes. Turns out his commits are 200MB large each, including binaries of all newly added libraries. And I was all like:

I've been working on implementing a fairly large feature on a project at work--

**Sorry. I should rephrase that**

I've been *trying* to work on implementing a fairly large feature on a project at work.

It's slightly complicated because I'm not as "in the know" with the project as I should be. I get tossed around projects a lot as the only designer+developer so I've got my hands in a lot of buckets... Or git repos I should say... My source tree has a lot of tabs open and each project is run by someone with their own ideologies on how stuff should be done and laid out and what not. Basically jumping between these projects leaves you mildly capable on all of them but not amazing at any of individual one them--

--I digress.

There's a bug I've been trying to fix.
--Stupid simple bug, literally just a casting issue or something but there's so much data in this one object that it's taking a few solid minutes of concentration to figure out which variable is busting it all up. It shouldn't take long to fix...

But it has. It has taken 4 days.

FOUR. DAYS.

...To fix what is basically a null reference exception.

Every time I sit down to work on this bug real quick I get pulled away to do a wireframe or change a flow chart or diagram or colour or print styling.

Every. God. Damn. Time.
4 days. Soon to be 5.

My commits are real low at this point guys.

Please boss man, just let me code...

The last software I worked on in my previous company (a few months back), was a temporary replacement because they were switching techs. It was meant to be replaced within 2 years.

So, before I left, I added a kill. 2 years and 2 months into the future. First it spams the devs with emails "how is the tech upgrade going?" with no further clues. 6 months later it will start throwing random exceptions at random intervals. 6 months after that it just terminates the application immediately upon startup. Snuck it in between large commits, and since they stopped code reviews when I left, doubt they found it.

There is a setting in configuration with an obscure name to disable it all.

I marked the dates in my calendar. Would love to be a fly on the wall then.

I think that two criterias are important:

- don't block my productivity
- author should have his userbase in mind

1) Some simple anti examples:

- Windows popping up a big fat blue screen screaming for updates. Like... Go suck some donkey balls you stupid shit that's totally irritating you arsehole.
- Graphical tools having no UI concept. E.g. Adobes PDF reader - which was minimalized in it's UI and it became just unbearable pain. When the concept is to castrate the user in it's abilities and call the concept intuitive, it's not a concept it's shit. Other examples are e.g. GEdit - which was severely massacred in Gnome 3 if I remember correctly (never touched Gnome ever again. I was really put off because their concept just alienated me)
- Having an UI concept but no consistency. Eg. looking at a lot of large web apps, especially Atlassian software.
Too many times I had e.g. a simple HTML form. In menu 1 you could use enter. In menu 2 Enter does not work. in another menu Enter works, but it doesn't submit the form it instead submits the whole page... Which can end in clusterfuck.
Yaaayyyy.
- Keyboard usage not possible at all.
It becomes a sad majority.... Pressing tab, not switching between form fields. Looking for keyboard shortcuts, not finding any. Yes, it's a graphical interface. But the charm of 16 bit interfaces (YES. I'm praising DOS interfaces) was that once you memorized the necessary keyboard strokes... You were faster than lightning. Ever seen e.g. a good pharmacist, receptionist or warehouse clerk... most of the software is completely based on short keyboard strokes, eg. for a receptionist at a doctor for the ICD code / pharmaceutical search et cetera.
- don't poop rainbows. I mean it.
I love colors. When they make sense. but when I use some software, e.g. netdata, I think an epilepsy warning would be fair. Too. Many. Neon. Colors. -.-

2) It should be obvious... But it's become a burden.

E.g. when asked for a release as there were some fixes... Don't point to the install from master script. Maybe you like it rolling release style - but don't enforce it please. It's hard to use SHA256 hash as a version number and shortening the hash might be a bad idea.

Don't start experiments. If it works - don't throw everything over board without good reasons. E.g. my previous example of GEdit: Turning a valuable text editor into a minimalistic unusable piece of crap and calling it a genius idea for the sake of simplicity... Nope. You murdered a successful product.
Gnome 3 felt like a complete experiment and judging from the last years of changes in the news it was an rather unsuccessful one... As they gave up quite a few of their ideas.

When doing design stuff or other big changes make it a community event or at least put a poll up on the github page. Even If it's an small user base, listen to them instead of just randomly fucking them over.
--
One of my favorite projects is a texteditor called Kate from KDE.

It has a ton of features, could even be seen as a small IDE. The reason I love it because one of the original authors still cares for his creation and ... It never failed me. I use Kate since over 20 years now I think... Oo

Another example is the git cli. It's simple and yet powerful. git add -i is e.g. a thing I really really really love. (memorize the keyboard shortcuts and you'll chunk up large commits faster than flash.

Curl. Yes. The (http) download tool. It's author still cares. It's another tool I use since 20 years. And it has given me a deep insight of how HTTP worked, new protocols and again. It never failed me. It is such a fucking versatile thing. TLS debugging / performance measurements / what the frigging fuck is going on here. Take curl. Find it out.

My worst enemies....

Git based clients. I just hate them. Mostly because they fill the niche of explaining things (good) but completely nuke the learning of git (very bad). You can do any git action without understanding what you do and even worse... They encourage bad workflows.
I've seen great devs completely fucking up git and crying because they had really no fucking clue what git actually does. The UI lead them on the worst and darkest path imaginable. :(

Atlassian products. On the one hand... They're not total shit. But the mass of bugs and the complete lack of interest of Atlassian towards their customers and the cloud movement.... Ouch. Just ouch.

I had to deal with a lot of completely borked up instances and could trace it back to a bug tracking entry / atlassian, 2 - 3 years old with the comment: vote for this, we'll work on a Bugfix. Go fuck yourself you pisswads.

Microsoft Office / Windows. Oh boy.
I could fill entire days of monologues.
It's bad, hmkay?

XEN.
This is not bad.
This is more like kill it before it lays eggs.
The deeper I got into XEN, the more I wanted to lay in a bathtub full of acid to scrub of the feelings of shame... How could anyone call this good?!?????

I take a colleague's project... and find this. How? Why? It was a small feature and now I have to maintain it. Fuck!

If you've ever tried using Go plugins raise your hand.
If you've ever tried doing plugins in Go, raise your hand.
If you think that the following rant will be interesting, raise your hand.
If you raised your hand, press [Read More]:

This is a tale of pain and sorrow, the sorrow of discovering that what could be a wonderful feature is woefully incomplete, and won't be for a very long time...

Go plugins are a cool feature: dynamically load pre-compiled code, and interact with it in a useful and relatively performant way (e.g. for dynamically extending the capabilities of your program). So far it sounds great, I know right?

Now let me list off some issues (in order of me remembering them):
1. You can't unload them (due to some bs about dlopen), so you need to restart the application...
2. They bundle the stdlib like a regular Go binary, despite the fact that they're meant to be dynamic!
3. #2 wouldn't be so bad if they didn't also require identical versions of all dependencies in both binaries (meaning you'd need to vendor the dependencies, and also hope you are using the right Go version).
4. You need to use -trimpath or everything dies...

All in all, they are broken and no one is rushing to fix it (literally, the Go team said they aren't really supporting it currently...).

So what other options are there for making plugins in Go?

There's the Hashicorp method of using RPC, where you have two separate applications one the plugin, one the plugin server, and they communicate over RPC. I don't like it. Why? Because it feels like a hack, it's not really efficient and it carries a fear of a limitation that I don't like...

Then we come to a somewhat more clever approach: using Lua (or any other scripting language), it's well known, it's what everyone uses (at least in games...). But, it simply is too hard to use, all the Go Lua VMs I could find were simply too hard to set up...

Now we come to the most creative option I've seen yet: WASM. Now you ask "WASM!? But that's a web thing, how are you gonna make that work?" Indeed, my son, it is a web thing, but that doesn't mean I can't use it! Someone made a WASM VM for Go, and the pros are that you can use any WASM supporting language (i.e. any/all of them). Problem inefficient, PITA to use, and also suffers from the same issues that were preventing me from using Lua.

Enter Yaegi, a Go interpreter created by the same guys who made (and named) Traefik. Yes, you heard me right, an INTERPRETER (i.e. like python) so while it's not super performant (and possibly suffering from large inefficiency issues), it's very easy to set up, and it means that my plugins can still be written in Go (yay)! However, don't think this method doesn't have its own issues, there's still the problem of effectively abstracting different types of plugins without requiring too much boilerplate (a hard problem that I'm actively working on, commits coming soon). However, this still feels to be the best option.

As you can see, doing plugins in Go is a very hard problem. In the coming weeks (hopefully), I'm going to (attempt to at least) benchmark all the different options, as well as publish a library that should help make using Yaegi based plugins easier. All of this stuff will go (see what I did there 😉) in a nice blog post that better explains the issues and solutions. But until then I have some coding to do...

Have a good night(/day)!

First rant... I'm on a large project where en use Git. Apparently I am the only one who, after pulling the dev branch, do multiple local commits to track (and possibly) undo my local work before I merge into development again. Everyone else do ONE local commit. Am I gitting wrong?!

I have a unreasonably large amount of commits just for these files in the repository.
Is there something wrong with me?

Context: ive been porting a single threaded D.A.G scheduler into a lockless multithreaded one. Point is its an objectively complicated project where theres lots of overlap in the code and architectural boundaries are very fuzzy.

My boss: "Can you just make new branches for every 'large' change youve done. Its too hard to merge this one giant branch youve got"

Me: "Fuck bro, but this is 2 months worth of significant refactoring where the commits are not atomic and you told me way back then that it was cool to work in my own repo. Now ive got to go redo half my work"

Boss: "Well yea but isnt it so much better to work with clearly seperated histories"

Me: "yea its great if you tell me thats the workflow you want upfront. This is gonna suck but ill but my balls and dive into this pit of lava if u say."

Turns out that stuff you commit and remove in later commits stays in git history and is searchable.
That, kids, is why you either squash your commits or just don't put swears in your debug code.
Especially if you have literally dozens of colleagues on the same codebase.
And you work in a large organisation where this sort of thing is frowned upon.

The crime was months ago, I wonder what the statute of limitations is on that.

And yes, in the years-long history of the codebase it's JUST me that's used any of the big three.

Questions more then a rant...

I've moved from being a lead on imploring DevOps and Agile practices in a large Telco to now working for a security consultancy... The team I'm with are s*** hot when it comes to SecOps (which is why I changed jobs) and I've been hired to he the automation and working practice expert on the team. Already got some of them learning Ansible which is a great start!

I've got delivery now being pushed to Git and all client work being tracked in Jira and properly documented and collaborated through HipChat and other CI tools on the way....

My question is this... Does anyone have some awesome resources to teach people Git, Jira, Jenkins, etc. quickly without forking or branching out on expensive training? Focus on being a technical but consultative team. Ideally just wanna pull some awesome guides and make. My own commits on them for the team... Please fire a story or epic away!

So, I am in the last stages of development of a really big project and I need to figure out a way to package future patches and updates for the client in order for them to manually update the project on prod server.

For reasons I cannot specify here, they will not use any automated process, and we need to provide regular patches and updates for the next year.

So I was thinking of using git archive to package changed files from our repo for every new commit, or series of commits, and just give them that, along with any database schema updates as sql files (again, no automation can be used).

We are talking about a large PHP + MySQL app, and cannot use automated deployment strategies.

I feel there must be a better way to do this, but this is the best I could come up with so far.

What do you people think?

Any ideeas?