4 ms·

Ruby is a language, and maybe if you already know 10 languages then it's a very easy language to pick up, but... how do you expect to know where Ruby ends and R

by yebyen 8y ago

Ruby is a language, and maybe if you already know 10 languages then it's a very easy language to pick up, but... how do you expect to know where Ruby ends and Rails begins, if you never separate the two? I don't see this your way. Junior devs are immediately productive? What kind of fantasy land is this? Junior devs need to walk before they can run. Everyone should know enough Ruby to parse them some CSV, if that's going to be part of the stack. Then, they can pick up a Gem library for parsing CSV and never do that again. But having the experience of working around the edge cases and knowing enough core language features to know what parts are easy without any gems, is going to make you better able to spot "using the gem wrong," or even "the gem is doing it wrong" (which also totally happens!) In my company, CSV was something we needed to have as a core competency (customers sending us data files, and bad data files, all of the time, ETL pipeline shaping them up and making them loadable into our custom schema...) and there were just two of us devs, so nobody's got time for pair programming. You're honestly going to ask a junior developer to start with "rails new" and then somehow trust what they produced, putting it on the internet? A junior dev could easily become productive with a handful of gems too, and practically understand every part of what they did. That's the point. You don't keep all gems out of the picture forever, just long enough to learn what hard problems look like without having them solved for you. If I'm a hiring manager and you're my junior dev, I want to start by seeing how you think, and I want to see you thinking with first principles so I can tell you where you're going wrong. I'll help you figure out the hard parts if you're struggling with something. But I do want you to struggle with those parts a bit, and I want to see it. If 95% of the work is done for you by a gem, then I might as well let you ask Rubocop and Brakeman what else you're doing wrong, and there's probably no point in having me here at all.

busterarm 8y ago
I'm really confused by some of what you're saying. For one, CSV is part of the standard library. just "require 'csv'". No gems required. Two, nobody without a really good reason should try implementing their own CSV parse library. RFC4180 doesn't even remotely reflect reality. It's several hundred lines of code to do right (about ~700 in Ruby currently, down from a bit over 2000 in earlier implementations). I hope they're good at RegExp.
- yebyen 8y ago
  > just "require 'csv'". No gems required. Seven years ago, at the time I was starting the job I mentioned, this was not a thing. The gem was called 'fastercsv' and it was made a standard library in 1.9 – we were mostly working on 1.8.7 when I started, and 1.9.2 when I did the CSV implementation(s). It was a brand new standard library and it did not do all things for all people. Almost like they just picked a pretty good one off the shelf! It still does not do all things for all people... today, you also have other competing implementations, say 'smartercsv' with most recent commit activity 4 days ago. It's an implementation of CSV. If you know your CSV is pristine, you can parse it in a lot less than 700 lines. We had a utility that would output "pristine CSV" dumped out from whatever garbage the client sent us, in whatever Excel or other columnular format, and we had another utility that would only accept this "pristine" format. Sometimes things went wrong. More often than you expect maybe, and we'd fix them ... or sometimes we'd get the clients to fix their shitty files, and leave it the way we thought it should work. Depending on what you need to do with the CSV, or how many ways you're planning on handling CSV, one could argue that you will be better served by a minimal implementation that you know exactly what it does and does not do, because you told it what to do. If it's making a mistake, that's yours. You own it! That's another boon, when the quality of the data is not guaranteed. The standard library I remember has some great idiosyncrasies that you'll know if you've ever used it to work on bad CSV. So do all of the CSV libraries. I don't work on CSV anymore and my memory of it is not so good, so I can't tell you the war stories in perfect detail, but... suffice it to say there are several CSV libraries with different strengths and weaknesses. We mixed and matched parts that served the specific need we had at any given time and place, until I was a total CSV expert. It was not a perfect ecosystem, and 7 years ago `require 'csv'` was simply not a thing. You had to pick one off the shelf, or roll your own. I'm really not sure what's different today. (Probably not much! Parsing CSV is not a core competency of either Ruby core team, or Rails.) We had our reasons though, to be sure. The one I remember in particular was a bit that converted your CSV rows and columns and then turned them into arrays of hashes, or converted arrays of hashes into CSV, and then another piece that expected the hashes to be identically ordered. If you used all of the standard pieces, this worked great! I think it took multiple libraries to do this, actually, and some of them were not so standard. But wait... hash keys are not ordered at all, and that's a property of hashes that is standard and well known. But in some cases the hashes do come back with their keys in a particular, consistent order, and in a perfect walled-garden use of the particular CSV library configuration that was expected by the people that wrote this crap, yeah everything worked. Well, everything worked until you do get a CSV with an uneven number of columns in some of the rows. Like I said, CSV was supposed to be a core competency for us. We would not have been successful if we just picked one CSV library and stuck with it. Or, that CSV library would have got a lot of free labor from us, I'm not really sure which. I'm not sure which is worse, either. I don't do that anymore though.

by yebyen 8y ago

busterarm 8y ago

I'm really confused by some of what you're saying. For one, CSV is part of the standard library. just "require 'csv'". No gems required. Two, nobody without a really good reason should try implementing their own CSV parse library. RFC4180 doesn't even remotely reflect reality. It's several hundred lines of code to do right (about ~700 in Ruby currently, down from a bit over 2000 in earlier implementations). I hope they're good at RegExp.

yebyen 8y ago
> just "require 'csv'". No gems required. Seven years ago, at the time I was starting the job I mentioned, this was not a thing. The gem was called 'fastercsv' and it was made a standard library in 1.9 – we were mostly working on 1.8.7 when I started, and 1.9.2 when I did the CSV implementation(s). It was a brand new standard library and it did not do all things for all people. Almost like they just picked a pretty good one off the shelf! It still does not do all things for all people... today, you also have other competing implementations, say 'smartercsv' with most recent commit activity 4 days ago. It's an implementation of CSV. If you know your CSV is pristine, you can parse it in a lot less than 700 lines. We had a utility that would output "pristine CSV" dumped out from whatever garbage the client sent us, in whatever Excel or other columnular format, and we had another utility that would only accept this "pristine" format. Sometimes things went wrong. More often than you expect maybe, and we'd fix them ... or sometimes we'd get the clients to fix their shitty files, and leave it the way we thought it should work. Depending on what you need to do with the CSV, or how many ways you're planning on handling CSV, one could argue that you will be better served by a minimal implementation that you know exactly what it does and does not do, because you told it what to do. If it's making a mistake, that's yours. You own it! That's another boon, when the quality of the data is not guaranteed. The standard library I remember has some great idiosyncrasies that you'll know if you've ever used it to work on bad CSV. So do all of the CSV libraries. I don't work on CSV anymore and my memory of it is not so good, so I can't tell you the war stories in perfect detail, but... suffice it to say there are several CSV libraries with different strengths and weaknesses. We mixed and matched parts that served the specific need we had at any given time and place, until I was a total CSV expert. It was not a perfect ecosystem, and 7 years ago `require 'csv'` was simply not a thing. You had to pick one off the shelf, or roll your own. I'm really not sure what's different today. (Probably not much! Parsing CSV is not a core competency of either Ruby core team, or Rails.) We had our reasons though, to be sure. The one I remember in particular was a bit that converted your CSV rows and columns and then turned them into arrays of hashes, or converted arrays of hashes into CSV, and then another piece that expected the hashes to be identically ordered. If you used all of the standard pieces, this worked great! I think it took multiple libraries to do this, actually, and some of them were not so standard. But wait... hash keys are not ordered at all, and that's a property of hashes that is standard and well known. But in some cases the hashes do come back with their keys in a particular, consistent order, and in a perfect walled-garden use of the particular CSV library configuration that was expected by the people that wrote this crap, yeah everything worked. Well, everything worked until you do get a CSV with an uneven number of columns in some of the rows. Like I said, CSV was supposed to be a core competency for us. We would not have been successful if we just picked one CSV library and stuck with it. Or, that CSV library would have got a lot of free labor from us, I'm not really sure which. I'm not sure which is worse, either. I don't do that anymore though.