Increase maintainability and improve code state

[DannyBen]

Well.

I know this gem is not actively maintained, and without the recent communications I had with @soveran, I would have assumed it is nearly abandoned (which would be a shame).

However, I would like to offer my help in increasing maintainability and improving the state of the code, so that - maybe - other people (or the people already here) can contribute more easily and keep it alive.

Thee are the things that I think should be done, for starters:

• Disable the empty Projects tab in GitHub Settings.
• Split the long ohm.rb file into separate files, one for each class / module, as is normally accepted.
• Port tests from cutest to rspec (assuming there is no particular reason for needing the isolation that cutest provides).
• Configure proper Rubocop rules and fix the code smells / style issues accordingly.
• Housekeeping on the "internal" gems, like nest and stal.
• Try to reduce dependency on gems that fell out of maintenance, like redic (or bring them to life as well.... :).
• Release a new fresh version

I marked the things I can help with. About the rest, will see how it goes, maybe I can grab a couple of the remaining tasks as well.

Let me know if there is interest in any of the above. If not, I understand as well.

[soveran]

I've just disabled the Projects tab ✓

I like the idea of incorporating the changes in your PR and releasing a new version. I think it will be very useful as it will signal how this gem can still be used. We have some kind of software development philosophy that consists on trying our best to build software that remains stable with as little human intervention as possible. That is why you will see most of the gems were created by us (@cyx, @djanowski, and me), and that's why the pattern of low maintenance is seen across projects. I guess at this point some of our decisions can be relaxed: for example, we've always disliked bundler and we don't use it in our projects, but it's true that our stance makes it very difficult for others to contribute because they would need to learn our way of developing and testing. Something very useful we could do is to change all those gems so that they use a Gemfile instead, in line with what you did with Ohm. Adding CI was also a very nice addition and we can replicate it all over the place. I (personally) would leave the file layout as is, as well as the reliance on cutest, nest, stal, and redic. I still like them a lot, both in terms of how they are designed and in terms of their usefulness. An update (Gemfile + CI) will bring them to life.

I'd love to hear from @cyx and @djanowski about this proposal. I'm very glad you appeared and I'm happy we can include some best practices as a result.

[DannyBen]

Oh cool.

I love ideas that create a "low maintenance" gem. Being a Ruby developer for several years, I can say that some gems are making me very frustrated with the amount of breaking changes they make in my lifetime.

Bundler

As for not using Bundler - I did not realize that this was by choice. I thought that back then (2016 judging by the last release of most of them), bundler was not "stable". This comes to explain why I switched to bundler without asking first.

I am guessing we can agree that for Ruby development today, there is nothing else other than bundler, and that (arguably) - it does a decent job today.

RSpec

Same as bundler, I think RSpec has become the top dog in Ruby testing. This is what I believe people expect to find in a test suite.
After developing 50+ gems, all with rspec, plus several rails projects - I am convinced that rspec should be the go-to testing tool, unless there are very compelling reasons to the contrary.

Stal / Nest / Redic

Lets differentiate between internal gems and redic (which I understand is external, out of your control?).

For the internal gems - I absolutely agree - no need to change them, perhaps just do the housekeeping and release a fresh one if needed - even if just to signal "alive".

For the Redic gem (again, assuming you have no control over it) - it will remain a weak spot, until it is maintained or replaced.

In my view, all dependencies of a gem should be in a "still maintained" state - as much as possible.

File structure

Having a single file define all its modules and classes goes against best practices. I cannot think of a reason to want all the modules jumbled up in the same file. Your code, your rules - but this one is an easy change with only positive side effects.

Next steps

I am not sure of the bottom line at this stage (if there is any) - but if you want me to start working on any of these things, including providing housekeeping (CI + Gemfile) to the other two internal repos, I can do that - let me know.

[soveran]

Very quick message because I'm bussy with other things, but just to clarify that redic is in our control too! I promise a longer reply for later today or tomorrow. Thanks!

[Budding888]

您好，您的邮件已收到，我会尽快给您回复，谢谢！

[Uduru0522]

I have nothing to do with this project; why am I getting a notification mail?

[DannyBen]

A spammer mentioned you in a post.

[Uduru0522]

Roger, thanks for clarifying.

[moonglum]

I think one thing that's important to note here is that ohm is part of a tiny "ecosystem" of libraries. I would refer to them as #lesscode – at least that's what the IRC channel was called back in the day if I recall it correctly.

There is the "Redis" part of the ecosystem that consists of libraries enabling you to use Redis as your main (or only) database:

• soveran/ohm, obviously
• soveran/ost as a queue
• elcuervo/minuteman for analytics
• soveran/finist for state machines
• The supporting libraries for them: Stal, Nest, Nido, Redic.

Then there is the Web part of the ecosystem:

• soveran/cuba as a routing library (a fork from leahneukirchen/rum, also forked to jeremyevans/roda)
• soveran/syro and its dependency soveran/seg as a rethought Cuba
  • We tried to write a new version of Cuba based on syro under the name tynn, but ended that effort in 2015 due to backwards compatability concerns
  • and reverse routing with moonglum/shigeru
• soveran/mote as a template engine
• soveran/scrivener for validation
• soveran/basica for authentication
  • or: cyx/armor and cyx/shield
• cyx/malone for mailing

and the tooling libraries:

• djanowski/cutest as the testing library
• cyx/dep for dependency tracking
• soveran/gs for gemsets

Parts of the ecosystem were also ported to Crystal

[Budding888]

您好，您的邮件已收到，我会尽快给您回复，谢谢！

[DannyBen]

I think one thing that's important to note here is that ohm is part of a tiny "ecosystem" of libraries.

Interesting. I did not know it is that intricate.

I am assuming you mention this as a reason why updates to any single component are to be treated delicately?

Since maintainers of long standing gems "lose steam" eventually, and since redis is a foundational element in some systems, I think that it is important to keep up with recent standards and practices, even if it is its own internal ecosystem. Even as an ecosystem, it is a part of a larger ecosystem.

Having standardized CI, specs, and gem management is a prerequisite for more people being able to contribute.

Of course everything I just said is less relevant if there is a sufficient amount of active and enthusiastic maintainers to this ecosystem, that are well versed in its inner workings and they prefer to keep it as it is now.

[moonglum]

Having standardized CI, specs, and gem management is a prerequisite for more people being able to contribute.

I totally agree. My main point is: The contributors of those libraries are mostly the same group. So, you need buy in from this group. Otherwise, you will lose the core contributors. My guess would be, that transitioning to GitHub Actions and adjusting the file structure will get buy in from the group. Bundler, I'm not so sure, as outlined by soveran above. RSpec will be very hard to argue, as it is a pretty complex tool which does not fit the philosophy. I'd rather suggest thinking about MiniTest as it is less complex and part of the standard library.