Forem: michelemauro

5 things you may may want to know before an Event Sourcing project

michelemauro — Mon, 18 Nov 2019 10:18:57 +0000

I recenlty spoke at the Google DevFestVeneto 2019, in Venice last saturday.

Here are my slides: I'll follow with a more detailed writeup of my experiences. Enjoy!

I'm thinking about taking over an abandoned GitHub project: what is your advice?

michelemauro — Wed, 16 Oct 2019 07:38:44 +0000

I'm asking for the collective DEV wisdom about how to proceed in a situation I'm getting into.

At work, I may be interested in using a small tool to add it to the development toolset (I won't be more specific for now; it's not that important). We are talking about a little library, a port from a similar library in another language; nothing fancy. The project is a Java/Groovy mix (with a bit of Kotlin for fun 🤔), and is Apache licensed.

The original GitHub project seem to be abandoned: no updates in 2 years, no answer to issues. Moreover, the project is actually broken (even for a 0.2 release): since a critical subproject is not properly published, you can't depend on this tool altoghether without downloading it and compiling it yourself. So, in this current state, the tool is not even readily usable.

I've spent a few hours on the repository, breaking it into subprojects, clearing up and updating dependencies, build scripts and tests. Now I have more or less the same code (I may have added an obvious missing piece, too) splitted in four repos, with clean builds and passing test, and with current dependencies. What now?

The plan I had in mind was like this:

Add notes on the README about what I have done, clearly stating code history and original copyrights
Change organization to something I have control over, leaving the original package structure as is
Publish a 0.3 release, with the original name but in the new organization, so it's clear that the code is mostly the same, but doesn't come from the same author
Add comments in the original repo's issues pointing to my repositories

Any suggestions? would you do anything differently?

Atlassian sunsetting mercurial support in BitBucket

michelemauro — Fri, 23 Aug 2019 20:51:49 +0000

(I didn't expect to start writing here with a text like this. But since I'm looking for longer opinions that those that can be found on twitter, I thought it would be a good place to start, and a good topic to talk about.)

The headline came to me via whatsapp from an ex-colleague: Atlassian sunsetting mercurial support in BitBucket. That was really a hard hit.

For those who don't know, Mercurial was one of the first really distributed Distributed Version Control System that really took traction: it was started in 2005, and it is still heavily used: Mozilla, Vim and OpenJDK are some high-profile projects that host multiple years of development, and millions of lines of code in hg repositories.

I started using Mercurial before git ever became mainstream, and because I was working with some colleagues outside the main office: we needed to collaborate on the same sources and, in that setting, we couldn't reach our central CVS. The ease of use of passing around "boundles" of commits, the simple commands and the almost impossibility of losing history made it possible to work for many months without even a central server, just passing files via skype.

It was no match for what Git was at that time (early 2007): something Linus whipped up in a couple of weeks, not too stable, still optimized for the Linux use case and adventurous to use outside of it. Mercurial was already stable, well supported on windows, too, with a clear and well-thought model that was easy to understand and use.

Twelve years later, git is still making releases with new commands to clarify and simplify some use cases, while Mercurial releases are about technology updates and new features. You can easily find (and probably need) tons of tutorials on how to use git and how to understand its peculiar concepts (like of course the excellent one here on DEV); meanwhile, every colleague I exposed to mercurial never needed any special training nor never lost work because of a detached head or a push in the wrong branch, no matter its previous level of expertise.

Finally, in the last three-four years, the "GitOps" methods fueled the exponential growth of Git integrations, and we're now stuck in VHS land. Atlassian, of course, has a bottom line to keep in check and finally came to the conclusion that BitBucket is supporting one VCS too many, and the one used by "1% of the users" has to go. The irony of BitBucket being the first commercial solution for Mercurial is, of course, only adding sadness to this story.

The options that Atlassian proposes are really underwhelming: a yet-to-be automated conversion service, some self-hosted pointers (Heptapod and Kallithea seem to be the most interesting; but they are a far cry from a supported commercial service with more than 10 years of experience), or do-it-yourself. And don't expect to keep PRs, comments, issues, metadata: no export path for them, nor conversion of project structure. When Atlassian pulls the plug in mid-2020, they'll be gone.

That's a sad, sad turn of the story that will harm a really good project, a true Betamax of the VCS space.

I wish however to thank a lot the original BitBucket team, that in 2008 believed in Mercurial and started its journey. Atlassian, while can be understood as a business entity, is still struggling in executing major moves like these while minimizing bad publicity and juggling worse karma; meme writers will just have more things to poke fun at.

Of course, the main lesson here is, for the n-th time, be careful what you put on a cloud service. And you, what do you have on a cloud service? what part of the information about your projects (issues, discussions, decisions, permissions, people) will you be able to offload, reuse and recycle if your current provider pulls the plug on its service or part of it?