3 ms·

Very interesting. This is kind of the opposite of the standard advice of "don't repeat yourself" and "don't reinvent the wheel". Both those pieces of advice m

Very interesting. This is kind of the opposite of the standard advice of "don't repeat yourself" and "don't reinvent the wheel". Both those pieces of advice make an awful lot of sense to me. But this is more advice in the style of an STD prevention campaign. "You aren't just sleeping with that gem, you're sleeping with every gem that gem ever slept with." Which, admittedly the blog author isn't taking quite to abstinence advocacy levels, but also rings kind of true. Reimplementing basic stuff across projects probably also keeps up your programming chops. The practice would help make the trivial stuff truly trivial for you. But what worries me about this advice is that there are some things that feel like they're trivial to implement but actually have quite a few subtleties and gotchas. In a language as dynamic as Ruby, you might even end up doing something awful (like letting your xml parser run arbitrary code). If the subtle bugs are located in gems, you only need to fix the gem to fix it all. But then again, how often do you own the gem? Even it's open source and you can fork it, the whole point of a gem is encapsulation. You shouldn't have to be thinking about its inner workings. Some gems really can carry big risks with them. I don't feel like I have answers to these questions right now. Just worth thinking about.

Manfred 14y ago
> But what worries me about this advice is that there are some things that feel like they're trivial to implement […] It's up to the developer to make that call. For things like OpenSSL or concurrency libraries it seems an easy choice. You will definitely save time and effort using a library for that. For things like pagination a few scopes with a view helper might cause less problems than a gem in the long run.
nirvdrum 14y ago
This is going to sound extreme, but I did measure it. Roughly 30% of my time was spent just managing dependency updates for quite some time. That, to me, felt absurdly high. But, the problem was transitive dependencies and their changing APIs. E.g., the redis-rb gem decided it was going to change its API. I guess that's fine, but I didn't use the redis-rb gem directly anywhere in my code. I did use a half dozen libraries that used redis-rb, half of which that immediately switched to the new API, half of which did not. The kicker was the new gem also had a hard requirement on a brand new version of redis, so you couldn't update the gem without also updating redis. So, naturally, not all gems wanted to update to the new gem immediately. This was a manufactured situation that was 100% avoidable. Semantic versioning doesn't help at all in this case. Namespacing your API does. But, that aside, I now found myself having to submit pull requests for libs using redis-rb when I had never used the gem myself. I certainly didn't save any time and the whole thing felt like a gigantic waste of effort. More recently, I went through this when multi_json changed its API. And the other common situation is gemspec's inability to say gem Y provides the API for gem X or to override version numbers you know to work (much like maven allows). So, a lot of problems that should be simple to solve become matters of wrangling multiple parties to agree on compromises. Since actively pruning my dependency graph and only very selectively growing it, my time spent managing dependencies is mostly negligible.
alloy 14y ago
> This is kind of the opposite of the standard advice of "don't repeat yourself" and "don't reinvent the wheel". Both those pieces of advice make an awful lot of sense to me. It’s not about re-implementing everything per project, it’s a reminder to think about all of the code you pull into your project. We use some third-party gems, we have our own gems, but as a rule these should all provide the minimum necessary and not try to solve all higher-level use-cases. Because these types of libs, that do come with the proverbial kitchen-sink, tend to bring in functionality that you won’t be using but are still very much opportunities for bugs. > You shouldn't have to be thinking about its inner workings. Some gems really can carry big risks with them. Some might indeed carry big risks, which is why it’s good to know your code and that is made significantly easier with less code. However, you should be thinking about their inner workings. Especially, but not limited to, open-source code which all (afaik) provide no warranty whatsoever. So when you pull it in, directly or indirectly, you are responsible.

Manfred 14y ago

> But what worries me about this advice is that there are some things that feel like they're trivial to implement […] It's up to the developer to make that call. For things like OpenSSL or concurrency libraries it seems an easy choice. You will definitely save time and effort using a library for that. For things like pagination a few scopes with a view helper might cause less problems than a gem in the long run.

nirvdrum 14y ago

This is going to sound extreme, but I did measure it. Roughly 30% of my time was spent just managing dependency updates for quite some time. That, to me, felt absurdly high. But, the problem was transitive dependencies and their changing APIs. E.g., the redis-rb gem decided it was going to change its API. I guess that's fine, but I didn't use the redis-rb gem directly anywhere in my code. I did use a half dozen libraries that used redis-rb, half of which that immediately switched to the new API, half of which did not. The kicker was the new gem also had a hard requirement on a brand new version of redis, so you couldn't update the gem without also updating redis. So, naturally, not all gems wanted to update to the new gem immediately. This was a manufactured situation that was 100% avoidable. Semantic versioning doesn't help at all in this case. Namespacing your API does. But, that aside, I now found myself having to submit pull requests for libs using redis-rb when I had never used the gem myself. I certainly didn't save any time and the whole thing felt like a gigantic waste of effort. More recently, I went through this when multi_json changed its API. And the other common situation is gemspec's inability to say gem Y provides the API for gem X or to override version numbers you know to work (much like maven allows). So, a lot of problems that should be simple to solve become matters of wrangling multiple parties to agree on compromises. Since actively pruning my dependency graph and only very selectively growing it, my time spent managing dependencies is mostly negligible.

alloy 14y ago

> This is kind of the opposite of the standard advice of "don't repeat yourself" and "don't reinvent the wheel". Both those pieces of advice make an awful lot of sense to me. It’s not about re-implementing everything per project, it’s a reminder to think about all of the code you pull into your project. We use some third-party gems, we have our own gems, but as a rule these should all provide the minimum necessary and not try to solve all higher-level use-cases. Because these types of libs, that do come with the proverbial kitchen-sink, tend to bring in functionality that you won’t be using but are still very much opportunities for bugs. > You shouldn't have to be thinking about its inner workings. Some gems really can carry big risks with them. Some might indeed carry big risks, which is why it’s good to know your code and that is made significantly easier with less code. However, you should be thinking about their inner workings. Especially, but not limited to, open-source code which all (afaik) provide no warranty whatsoever. So when you pull it in, directly or indirectly, you are responsible.