Just ran through this and quite enjoyed it. It's very different from "A Tour of Go". I really like how he creates a narrative out of test failures. It's by no means effective as a sole source for learning Go, but I'd recommend it to those who have completed the Tour as a way of getting more practice working with Go's various data types.
> What is the difference between the cask installation suggested in the link and the cask installation procedure suggested on the cask home page?
Two differences. One is that we moved to an org repo, so the first form is relying on the github redirect from the move. The other is that the second form relies on the semi-recently introduced "auto-tap" syntax in homebrew.
Functionally they will get you to the same place (we've got code to notice that your remote is pointing to the old repo location and update it), but the second form is newer and cooler. ;)
Hey there! This is a valid concern, but I don't think it's all that different from using Homebrew. The community maintains the cask definitions, and all pull requests are reviewed via the project team. There's a checksum verification feature built in, though we're still figuring out how to reconcile that with un-versioned download URLs [1].
At the end of the day, when you use any package management software, you are implicitly trusting the team that maintains said software. Perhaps it would be better for us to do our best to force users to make that trust more explicit? It's an interesting question - any suggestions you have would be more than welcome - feel free to open an issue to discuss! :)
Hiya - author here. Thanks for the feedback on this stuff! It's always good to hear where it's best to focus improvements.
I'm going to address a few of your points specifically.
> There are no upgrades, in many cases it doesn't work.
It's true that `brew cask upgrade` is not yet a thing. I would very much like it to be. I've been sort of avoiding work on the feature for fear of messing it up. But that's no reason to not try to make something work! :) Maybe I'll use this as an occasion to start digging in and getting my hands dirty.
> At the end of the day, it duplicates some of the Homebrew functionality - some non-GUI packages are getting into Cask, because possibly Homebrew doesn't want them - it's a bit confusing as well.
If the purpose of the project is not clear, that's definitely a problem. I'm not aware of many (any?) purely non-gui apps making it in to Cask. The `Homebrew/homebrew-binary` tap is the place for those. I'll go review our included Casks to make sure things are clear.
> I think efforts should be put into merging into Homebrew instead of keeping it separate.
I can understand this opinion, but I think we may actually end up going in the other direction. The places we share code with Homebrew have been the biggest problem areas for us. We are already 90% code independent from Homebrew, and I think moving Cask to its own world may benefit both the project and the users. But of course that's a conversation to have with the (amazing!) project team.
Alas there is not AFAIK. For all the research I've done on this, the only conclusion I've been able to draw is that the MAS is anti-automation (if not in intent, at least in its current design). :(
> I just want the applications to be copied to my install location and left alone.
If it's a use case that would be useful to people, this is a mode of operation I would definitely be willing to include in the project. Feel free to open an issue (or even better - a PR!) with the idea. :)
> Quite a few of the apps I use (iTerm2, ST3, Chrome, Adium, etc.) update themselves periodically. I wonder how Cask deals with that?
Sparkle-based self-updating apps will self-update in place. For apps like that, the current policy is to have a Cask version of 'latest', and letting the apps self update.
I've been doing this for some time and I've found it works out AOK. It's nice to be able to click the "Update & Relaunch" and know I'm not messing anything up. :)
In my experience, a day spent pairing, while generally a sort of intense experience, is also filled with little breaks. Your pair gets up to grab a drink; you check your email; somebody turns on a Katy Perry single and you spin around to join a team-wide argument about its merits; etc, etc. :)
While nearly 100% of your time is _dedicated_ to pairing, I'd say the percentage of time you both spend actively sitting at the computer working on a task is roughly equivalent to what you'd do as an individual. Which is to say, it varies. But it never really feels like you can't do side things; the vibe is very flexible and casual.
For deploys and emergencies, it's almost always a pair attacking the problem. Even if just one developer is doing most of the driving, the pair is still able to learn, catch typos, diagnose, etc.
Meetings can definitely end up splitting pairs, which becomes yet another incentive to try to minimize them.
I contributed. It's obviously a worthwhile cause, and their overall strategy seems sound. I also appreciate their efforts to bake the open source mentality into the project.
I hope they reach the goal and this gets big, because that's how it will be effective.
edit: following them on twitter turned up a couple of worthwhile articles: one on the economics of bike theft [1] and another review of locks performed by interviewing bike thieves [2]
> However, each tab I open I need to cd into the same directory.
As of tmux 1.7, this should be unnecessary. Every tab and split will open in the working directory of the current pane, and the behavior can be changed with the `default-path` option.
Come help us prove that a focus on great, usable software can win the LMS market.
We're not just building a better mousetrap; we are changing how teachers and students interact, whether in small groups or with tens of thousands of students in one course. Check out our online courses at http://canvas.net