For anyone interested in alternatives, we built a utility (creatively named git-gpg) with the same goal: end-to-end encrypted git. It works over ssh, is self-hosted, and requires no additional software on the shared server.
As the name suggests, it uses gpg to encrypt and decrypt the data.
Unlike git-encrypt and git-crypt, it doesn't use smudge/clean filters.
Instead, it uses a special command (`git-gpg push $remote`) to push changes to a local unencrypted mirror of the remote repository. It then encrypts any newly created git objects, and finally rsyncs the new objects to the remote repository. So the remote is just a directory of zipped, gpg-encrypted files.
It has worked well for me over the past two years, but I don't expect that it solves every edge case.
Feedback welcomed through issues and pull requests.
I'm sure it works well for you, and you might be aware - but just in case you aren't, that's what "git remotes" are all about - you can write a remote helper instead, and "git push gpg://...." instead of "git gpg push". That's how p4, mercurial, etc client bridges are implemented.
See [0] for more. Obviously, this might be overkill for your use case, but this is the "right" way to do it.
Senior Software Engineer at FiveStreet.com (a division of Move, Inc. / News Corp.)
Alexandria, VA / Northern Virginia / Washington, DC - Full Time - ONSITE
Are you a risk-averse engineer who yearns for a startup experience?
We are a recently acquired startup who has carved out an "intrapreneurial" working environment in our parent company. We have the autonomy, flexibility, and learning opportunities of a startup, but with the stability and budget of a large company.
Our team runs FiveStreet.com (http://www.fivestreet.com) and related micro-services within Move, Inc. We grew our active userbase by over 10x last year because we still act like a startup. We're on track to achieve this same level of growth in 2015.
If you join our 5-person team, you will gain experience in every part of planning, building, and operating a high-volume Rails app. Heroku, Twilio, and machine-learning experience a plus.
If you're intrigued, email rusty -at- fivestreet.com
FiveStreet.com (a division of Move, Inc.) - Northern Virginia / Washington, DC / Boston, MA / Remote - Full Time
Are you a risk-averse engineer who yearns for a startup experience?
We are a recently acquired startup who has carved out an "intrapraneurial" working environment in our parent company. We have the autonomy, flexibility, and learning opportunities of a startup, but with the stability and budget of a large company.
Our team runs FiveStreet.com (http://www.fivestreet.com) and related micro-services within Move, Inc. We grew our active userbase by over 10x last year because we still act like a startup. We're on track to achieve this same level of growth in 2015.
If you join our 5-person team, you will gain experience in every part of planning, building, and operating a high-volume Rails app. Heroku, Twilio, and machine-learning experience a plus.
If you're intrigued, email rusty -at- fivestreet.com
Excited to see these guys pushing boundaries; that's exactly what inspired Nitrogen in the first place.
My hat is off to the synrc.com team for their work on N20, as well as Jesse Gumm (https://github.com/choptastic) for his hard work maintaining and improving Nitrogen as project lead for the past two years.
Sometimes methods don't fit neatly into a specific model object. They may cut across multiple model objects, or call out to external libraries for logging and metrics.
When this happens, you can either have model objects that know too much about their surrounding environment, or you can put the code somewhere else.
In Rails, that "somewhere else" is usually a controller. But that's messy because now your application's logic is spread between a controller and multiple model objects.
Interactors are a way to clean that up. It allows you to put all of the code to accomplish a use case into one well-named place.
Good programming is about managing complexity. In practice, interactors have served us very well in managing complexity.
(Note: I work on the same code-base as the author of the article.)
do you find the Interactor pattern preferable to implementing a different re-use pattern for Controllers though? Why not use, for example, use Abstract Controllers and just include them as a Mixin to your Controllers.
e.g. CommentMixin would be an abstract controller class that is included in any controller that has an object that can be commented on.
Interactors are not always triggered by a user event. Many of our interactors are triggered by a scheduled job or some other system process that doesn't touch a controller.
Also, as the article describes, interactors are plain old ruby objects, so are straightforward to test. An Abstract Controller, being a Rails construct, would require you to jump through some Rails hoops to test.
FiveStreet is a fast growing, funded startup in Washington, DC.
Looking for a well-rounded software engineer to work alongside our CTO. We need a resilient generalist who can solve problems. You should expect to wear many hats (both technical and non-technical) and have an interest in learning about the residential real estate industry.
We're heavily influenced by Hacker News & Lean Startup.
Candidates in the Washington, DC metro area preferred.
Excellent suggestion, and something we're already considering for a future release.
Our current reasoning is that if you are only pulling back one or two objects, then an extra round trip probably isn't that bad. If you're pulling back many objects for processing, then you might be better off feeding the query results into a MapReduce job so that it runs in parallel across the cluster.
Saw Eric speak at a DC Lean Startup Circle meetup event... excellent presenter, highly recommend watching the video or seeing him in person if possible.
https://github.com/glassroom/git-gpg