-
If I find too many people adopting a certain software tool, I’d probably think it’s bad. It would require an in depth analysis to convince me otherwise, because the mechanics at work are well established.
The mechanics the author described, of a tool becoming popular just because of a feedback loop, don’t suggest that popular software is usually bad. Rather, they suggest merely that popular software is no better than randomly-picked software. If many people are adopting a certain software tool, that doesn’t mean it’s bad, that means it’s probably average.
In fact, it’s probably better than average. The article suggests that a tool’s popularity is purely a feedback loop, regardless of the tool’s quality. But when a tool grows in popularity, that can actually improve its quality. The project may draw more core contributors, who catch more bugs, or who bring expertise in competing software and apply it when designing changes to the tool.
The quality intrinsic to a tool is also not the only thing that matters (though of course it does matter). If two tools are basically identical, but one of them has a bigger community that can answer my questions better and that has already published plugins to integrate with the libraries I need, then the project with the bigger community is a better choice.
-
If two tools are basically identical, but one of them has a bigger community that can answer my questions better and that has already published plugins to integrate with the libraries I need, then the project with the bigger community is a better choice.
Wholeheartedly agree. Not to mention, some projects are started with the intent to collaborate (think open source, or even growing startups). If you want to get the most reach, you need to think about what languages/frameworks are popular so that you can maximize your chances for acquiring talent.
While I do agree that all languages and frameworks have their strengths and and you can’t label one as genuinely superior to another, making decisions based on community size isn’t a bad idea.
-
But when a tool grows in popularity, that can actually improve its quality. The project may draw more core contributors, who catch more bugs, or who bring expertise in competing software and apply it when designing changes to the tool.
It’s hard to tell if popularity improves the quality or not. I’ve been thinking a lot about it, and I hope I can write an analysis soon. You mentioned why popularity may increase the quality, but think about the inverse: what aspects of popularity can decrease the software quality? Sorry for the short reply and the lack of clarifications, I still need more time to wrap up my ideas on this subject.
-
-
Recently I’ve been lucky enough to avoid HTTP+JSON for the majority of my work. This has been great because there’s been no bullshit for me to worry about. No frameworks, no bloated libraries. Just straight up Ruby and essentially just concord and thrift in the Gemfile.
I’ve been working almost exclusively in Rails the last three years, doing string plumbing schlepping things in and out of various databases and markup languages. My list of preferred Ruby tools looks much the same as his: I’d add adamantium, equalizer, and maybe attestor (a nice idea that needs to not use exceptions for control flow). I have a hard time recommending FactoryGirl because I’ve seen it help teams accrue ever more technical debt once they’ve passed the point that they can’t even instantiate model objects in a unit test in a couple lines of code. Lotus and ROM are young but have some real potential.
I wonder if Rails would already have succumbed to sclerosis if it hadn’t been for merb, a competing web framework with a much nicer internal design that merged into Rails. Rails 3 looks a lot more like merb than it does Rails 2, it feels like Apple’s acquisition of NeXT where the little fish ate the big one. Maybe there’s the possibility of doing that again, though the Rails community has been really dismissive of efforts like Trailblazer to improve on the default MVC ball of mud.
It’s really encouraging to see folks like Adam Hawkins, Markus Schirp, and Piotr Solnica thinking along the same lines, though even as I’m preparing a RailsConf talk on this topic I wonder if it’s worth trying to make a little movement in Ruby or decamp to another toolchain.
-
There’s a Ruby minimalist counter-culture brewing, and I’m aware of companies hiring developers to work on projects with Cuba, a tiny microframework. I have lots of projects built with Cuba, Ohm, Shield, Mote, Scrivener, and many other small Ruby libraries that get the job done. I recently wrote a comment about small libraries in /r/ruby, I hope you find it interesting. I know many other developers who are in a similar search for lean software, and there’s definitely a way to build applications with simplicity in mind.
-
I’m mostly a bystander here, but I did have hopes, years ago, that the Merb merge would punt Rails in a less monolithic direction. I don’t use Rails, but it’s undeniably influential, and I want it to help developers be productive, both directly and by influence.
These hopes were pretty much dashed by later “features” like Turbolinks, which even Yehuda Katz, if I recall correctly, opposed enabling by default. There has been no move away from Active Record / Support. Rails didn’t internalize the lessons of Merb; it just ate it up and spit out its bones. I wish I could see it differently.
Keep fighting the good fight!
-
Rails is actually quite modular, even if it is not shipped like that. The problem of Rails is that it start with full stack and you need to remove to go lean, while other frameworks like Padrino encourage you to add on a lean basic stack.
I am under the impression that removing parts from a system competently is a lot harder then adding to a lean system. The first requires understanding upfront, the second requires you to understand during the task.
-
-
-
I released m4s2, the tool I use for building my website. It’s nothing fancy, just a makefile and a shell script. It uses the macro processor m4, hence the name. Even if it’s very plain, the fact that it uses m4 means it can be extended by the end users in many different ways.
I’m also working on ox, which is a template for building Cuba-based JSON APIs. It uses
makefor all commands, and the dependencies are installed inside the project directory. That makes it easy to try and very easy to remove if necessary.
Some of my tools were lacking in terms of documentation (they had only a README) and installing instructions (something like “compile it, copy it to your path”). I’m creating man pages and homebrew formulas to make them easier to install. They are listed here, each with a short explanation.
Oooh!
chenlooks really useful. I keep trying to useqmvfor that but it uses tabs to present two columns in my editor and expects 8-space tabs, whereas I only have 2-space tabs so the formatting is all weird. Just editing the name in-place and having the tool figure it out makes it much easier. Much thanks (both for authoring tool and posting about it)!Use
qmv -fdo(destination only format).Glad you find it useful! I wasn’t aware of
qmv, it looks like a very powerful tool, extremely configurable. I didn’t know renaming files was a pain point for me until a few days ago, when I read about Roamer and realized mass renaming with a text editor was a thing. Now I find myself usingchenmany times a day :-)