Skip to content

Instantly share code, notes, and snippets.

@JoshCheek
Created December 28, 2016 13:33
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save JoshCheek/64cee390516c0b224ecd2e611feb676b to your computer and use it in GitHub Desktop.
Save JoshCheek/64cee390516c0b224ecd2e611feb676b to your computer and use it in GitHub Desktop.
My env

If you're feeling exhausted from putting in that effort to figure it out, then I understand. If you're worried about my time, then don't sweat it, it's good for me to experience the difficulty users experience when I don't get things right.

Additionally, SiB is a way of approaching problem solving. If you develop the habit of using it, it's deeply effective and figuring out how to explore problems with SiB is good for your brain. Given that, it's best to establish the habit of using it to experiment as early as possible. Otherwise, you get it installed later, but you've developed a habit of irb or pry or running the tests. Then you don't take advantage of a situation where SiB would be very valuable.

As an example of why getting in the habit of using SiB is useful for your brain, it requires you to see that a hash in the middle of a rails controller, whose keys are user names and values are counts of something or other pulled out of the database... that's still just a hash, and you can experiment on a hash whose keys are symbols and values are integers, in SiB where feedback is rich and quick. Then you come to really understand how the hash works, and you translate your isolated knowledge back to the integrated Rails environment. To facilitate that, your ontology improves. when you get comfortable with it, you can answer in minutes something that you might have otherwise spent hours on, or more likely, not even bothered to try. So I think it's worth trying to develop the habit as early as possible. Here is a short example where I wound up using it like this for real.

Note I have a similar opinion about pry and testing (learning how to test effectively is particularly good for your brain, but it takes a lot more effort than SiB to become good at).

Just out of interest what is your ruby software/editor setup, and what would you suggest for a beginner/intermediate level?

I can't tell how experienced you are, so I'll explain what some things are that you might know. It's not intended to be condescending, rather its an attempt to be comprehensible to a range of experiences.

My computer is a 3-year old Macbook Air. I've been pretty happy with it, but I code pretty hard and it seems to be nearing the end of its life. Some of the new Windows machines look pretty good to me, so when I have to get a new one, I might give that a shot. Alternatively, if I get into more sysadmin/devops kind of stuff, I might try Linux. Alternatively, inertia may keep me on a Mac.

For my terminal I use iTerm2. A terminal is the proram that emulates the ancient hardware all these programs were written to run on -- on Windows, if you've ever seen a box pop up when you run a system command or use Ruby's backticks, it's that box. I'm really impressed with iTerm2, it's been good to me. I'm pretty sure it's Mac only, though.

For my shell, I use Fish, but I doubt it would work on Windows. Fortunately, I've heard really good things about Windows' PowerShell. And at some point, you could look into setting up a Unix environment in Windows, at which point Fish would be available. I'm not up to date, but I've hard Cygwin does this. Probably defer investing into it until you can identify specific value you expect to get or specific problems it addresses... there's no such thing as a perfect tool chain and if you wait to jump in, you'll wait forever. Do note that Fish is a pretty uncommon shell, so if you don't have helpful people around, or have a basic grasp of Unix and how shells work, then it might be better to go with something more common. Most Unix systems come with a shell called Bash, and there's a better version of Bash called Zsh. Either of those are fine, with a little customization, Bash can get you really far. Zsh would make sense if you're wanting more from your shell but fear the isolation of Fish. Its downside is primarily that being a superset of Bash, it still has many of Bash's flaws, and to really enjoy its strengths, you have to do a lot of configuration, which particularly disadvantages new people.

To manage all the different Rubies I work with, I use chruby, but it is very Unix-centric. Fortunately, you probably don't need to be able to switch between versions of Ruby for a while, and when you do, there is probably a good tool for it. My understanding is that this guy has done a lot of good work making Ruby more at home on Windows, so if you eventually need that ability, maybe see if he's got a blog or check his github repositories or ping him or something.

For version control, I use git. It's a really awesome tool, but its interface makes it harder to use than it should be. It's incredibly powerful, it's what allows me to collaborate with other people, and it's what gives me the confidence to be incredibly cavalier in my development style. Note that I also have a pretty defensive set of practices (eg I check every line of every file when I commit work, because I'm reasonably likely to have done something ridiculous in the middle of whatever file happened to be open at the time).

To host my code, I use github, github is thoroughly wonderful! I pay for a subscription even though I don't need the features, it's just a way to give them money because it's such an incredibly valuable service. Github lets me explore code very easily, contribute back to open source projects easily (people used to have to hunt for the code repository and then email patches to the author to get them merged added!) it lets me link people to specific sets of lines on specific commits of specific files, it lets me find discussions about issues with code I'm using, it lets me host all my code without worrying about maintaining a server or what happens if I lose my computer, it's the reason Windows support will come to SiB because it's what made it easy for others to send the pull request.

For testing, I use RSpec, but MiniTest is a good tool, too. I know and like the authors/maintainers of both of them. Minitest is intentionally small, in fact, it's small enough that I read through the codebase in a few hours when I had to teach an "advanced minitest" class. The upside of being small and simple is its easy to go in and figure out what's happening and how to accomplish your goal, the downside is it's missing some useful bells and whistles. Some of them can be added through plugins, though. RSpec has more bells and whistles than I use, and its codebase is somewhat formidable, but it was at the inception of "BDD" as a paradigm (don't sweat it for now if you don't know about it) so it makes it very natural to test in that manner. I find that important (code is often trying to drown you in details, so I use this style of testing to experience clarity about what is going on and why), and I also have a workflow that works well for me and uses a lot of RSpec's bells and whistles. They keep some really good docs up which is nice given the difficulty of the codebase (Minitest has docs, too, but I find it pretty easy to just look at the code).

CI is a computer that isn't mine and runs my tests to make sure they work outside my very specific environment. I use Travis CI for this, and I truly love Travis. It's prevented so many problems that I wouldn't have discovered until users hit them. Its downside is that its Unix only, so I just added AppVeyor to facilitate SiB on Windows. So far, AppVeyor seems really good, as well, eg it caught the same bug you hit when using specific_install, and it's how I'm going to be able to ultimately get and keep it working on Windows.

For my editor, I use like 4 different things and love/hate them all. I mostly use vim, but that's mostly just because I'm good at it and it's frustrating to be unproductive whenever I've tried other editors (eg emacs). Vim is reasonably good, but it comes from an archaic time, so to understand it, you have to learn some history. At the same time, to use Unix well, you're going to have to learn that history anyway. It's also got a fairly steep learning curve. If you want to use vim, you have to be committed. I think it does support the mouse, but I don't use that as a feature, so either mine doesn't or I turned it off. I also use Atom a lot, because when I was teaching, it's what we had the students use. As a consequence of that, it has the best SiB integration (eg on some editors, SiB will jump you to the top of the document every time you run it). I also use Atom a lot for Markdown, it's got a nice preview, good syntax highlighting, and some other features. I use TextMate a lot, but it doesn't work well on the latest Mac, TextMate2 does, so I've switched to using that. I think TextMate inspired a lot of these other editors like Sublime and Atom, I'm pretty sure they both use its language syntax files, because they're incredibly good. When I want to play with SiB, I switch to Atom or TextMate. For most people, there is little value in switching back and forth between 4 editors depending on the task.

I also use pry a lot. In fact, I made the video on the homepage (really old, I didn't even use Fish at that point). Pry lets you get into the context of some code that you're having difficulty understanding. Like SiB is an indispensable tool for me. I mostly use pry from within tests, which I suspect is an uncommon way to use it, but that's unfortunate, because it's very effective ie to explore the issue, you recreate it in a test, which allows you to trivially put yourself into that context which makes it easy to use pry effectively and means that you've got a test on the thing when you're done. You can get a good feel for how I use pry in this video, it's got almost no SiB because it's pretty much all integration.

For my browser, I mostly use Opera, but frequently use Chrome and Safari as well, and sometimes Firefox. This is mostly dictated by whether I'm scared that the number of tabs in the browser might crash the computer, so I switch to a different browser. It's stupid, I know >.<

I also tend to script / automate anything I do that's either frequent (and thus should needs to be as close to zero-cost as possible) or painful (which disinclines me to do if I don't improve it). A lot of that stuff is in my dotfiles, especially the bin directory, but is probably not of general interest.

Feels like that's most of it, if I missed something specific, let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment