phinze

Hey author here - I'm super interested to see if this way of slicing up the design space resonates with anyone.

As someone who has been in and around distributed systems for many years now, I do feel like we're cresting into a new generation of system design that tries to take into account the lessons of the last one. This question of how we reduce centralization of risk while retaining our ability to distribute safety fixes is a rich one I think.

Just had DNS trouble from Chicago. Switched to openDNS.

This made me more excited about Elixir than anything else I've read about the language thus far.

The talk of "empathy" as a core value also reminded me of the focus of Ernie Miller's "Humane Development". http://erniemiller.org/2014/12/17/humane-development/

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! :)

[1] https://github.com/caskroom/homebrew-cask/issues/1021

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. :)

Amen to that! Our project is actually independent of the Homebrew team, but we very much model ourselves on the great work they're doing.

Done! http://phinze.github.io/rss.xml

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.

This is an interesting practice, thanks for sharing. I'm really curious about different sorts of hybrid approaches being used in the wild.

I'd be curious to hear how the day-to-day schedule ends up working out between developers, since the review process is synchronous in this case.

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]

[1] http://blog.priceonomics.com/post/30393216796/what-happens-t... [2] http://thesweethome.com/reviews/best-bike-lock/

> 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.

just added a cask for this so osx homebrew-cask users can check out the project with `brew cask install maratis`

https://github.com/phinze/homebrew-cask/pull/819

Instructure is hiring Software Engineers in Chicago, IL

http://www.instructure.com/jobs

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

We believe deeply in Free Software; our core product is published under AGPLv3: https://github.com/instructure/canvas-lms

Work at a place where you can know that with each problem you solve, you make the lives of students and teachers just a little bit better.

IMHO this is one of the few thoughtful, productive pieces I've read on the PyCon debacle. I appreciated his last line:

> Of course I'm just Tim Taylor, talking over the fence to Wilson. Women, do I have this right?

I too would love to hear reactions from both male and female members of the community on his thoughts.

Wow this is nicely done. I added a homebrew cask for it so it can be installed via `brew cask install anvil`. https://github.com/phinze/homebrew-cask/commit/aff3777759dfc...

Here are the contents of the two zip files that Sparrow provides at http://sprw.me/lgpl.php:

* mac.zip - https://gist.github.com/3196054

* iphone.zip - https://gist.github.com/3196057

In other words - not much at all. :(

Looks like there are release notes available here:

https://github.com/antirez/redis/blob/2.6/00-RELEASENOTES

And there's a 2.6 milestone here:

https://github.com/antirez/redis/issues?milestone=1&stat...