codebeaker

I'll probably be down-voted to hell, but whats with all the redirects that make "back"ing out of the site back to HN so painful, I counted three redirects before I landed on the final page, and had to long-click my back button to avoid the obnoxious redirect trap. Looks like your tracking (I assume) might drive people away.

The name makes it sound like they're using unsound environmental practices, and shipping out boards full of who-knows-what.

I came here to say this. Especially when the name doesn't quite roll off the tongue. Inconvenient, and I didn't bother messing with the URL after clicking the blog's title image (which is just the product name…) and the link in the footer.

My first observation is that in most of the apps I've worked on keys are composed by constructs such as `t :"something_#{from_the_context}"`, which I assume this tool will miss. I'd much rather see a tool that tracked i18n hits in a k/v store, and used that in addition to the static analysis.

Don't let this discourage you, your work looks great (props on the correctly tabulated output!) - but it would never work for me in what I think is a reasonable usecase :(

As the author of Capistrano, we leant on Rake a great deal in the new version, Jim was amazing in helping us through some of the weirder parts of the integration, and always happy to discuss the pros and cons of our planned approaches. I hope that the community can select someone to replace him. He's done great work for the community.

Trello, that tool my company has been successfully using for software development for years, which already supports vimish (forgive me!) movement and edit keybindings?

I'm not seeing the point here, Trello is excellent, and already great for software teams.

Sorry to hear about your father. These medical and technological advances should serve to make us realise that whatever the state of the politico-economic world, we live in pretty amazing times. I hope that the curiosity of humans, and our drive to learn beats out the system in the long run.

It certainly doesn't help that no matter where I seem to go on their site, I always come back to the video. I couldn't find the demo, or any screenshots of what it looked like, or what components it contained. So much for good design.

It's possible that if you have packages that understand flags (config package, with flags in init(), for example) that if you include it after the testing package, or before. One of them won't accept flags. (because flag.Parse() has already been called)

Great catch, thanks - we're not pushing the homepage too hard yet :) so my pride isn't too badly hurt. Rolling a replacement soon!

From someone who's betting the farm on writing a web application in Go (https://www.harrow.io/).

We've chosen Go for two really significant reasons: a) to reduce attack surface area and b) to enable us to distribute binaries to customers who want an enterprise/firewall install inside their own network.

Speaking about surface area, we've reduced the amount of framework code in stack (rails, gems, etc are all off the table) to zero, and we've reduced the app paths to a few tens of lines of code, in most cases.

Whenever one trades off a framework "to make things more secure" one has to be sceptical, there's a massive scope to introduce SQL injection, XSS and other nasties. In Go, in our case this is fairly limited. So take that reason with a pinch of salt if you aren't building a VERY well defined app with VERY small and skilled team. I don't expect this to scale well.

The second part is also a niche value, whilst it will have some benefits for us running our hosted version of Harrow, it'll have more profound benefits when we can sell binary installations to customers.

Finally, learning how to build applications in an API centric manner, without the crutch that is Rails has been interesting, and has made us all better programmers, we have a more interesting architecture now, and are making better use of our tools (we're leaning heavily on PostgreSQL, triggers, stored procs, LISTEN/NOTIFY etc) and we have a faster system.

On the flip side of things, timing attacks are now really something we have to be mindful of. For instance the login endpoint returns "404 Not Found" regardless of whether it's an incorrect password, or the account doesn't exist. Except, interestingly we're using bcrypt (we're switching to pdbfk2 before the public launch) we need to look up the user before we can hash and verify the password. Meaning we respond in < 1ms when the user is not found and 4ms when the user is found, but the password is incorrect. (and 4ms when the password is valid). This also applies to a lesser extent in responding with "404 Not Found" when trying to snoop on someone else's project/logs/build/etc. The same way they Github does. But it's less critical there as there isn't the artificially long password hash comparison step.

All told the decision to build in Go has made the development of the project slower, but has in my mind at least lead to a better quality of software, with things that don't typically show up in Rails/et al projects (foreign key constraints, triggers in the DB).

Of course all these tools are sharp weapons if handled incorrectly, and testing triggers/functions in the database can be a nightmare from a unit/functional testing point of view.

We've avoided technology proliferation (the entire stack is Go, and PostgreSQL, with worker nodes which rely on LXC). The entire application uses three packages not taken from the Go standard library. (db driver and bcrypt library)

Ohh, and our test suite compiles, and runs (all of it.) in less than three seconds. That hasn't hurt much, either.

Thanks for taking the time arnehormann, I assumed it would be split into packages at least. But I'd much rather see simple extensions that add setup/teardown, and maybe something that demonstrates how to replace the Test_main function (whatever it's called) for modifying output, probably it's all in here somewhere! Thanks!

Whilst this looks really neat, given the relative immaturity of testing frameworks in Go, I'd have preferred to have seen something to solve part of these problems individually.

Big, complex frameworks such as this are anti-Go. This is bringing notifications, a new DSL, file watching, and whatever else.

I haven't reviewed the code, but it seems a shame somehow to lock some useful features up, with some fancy stuff which isn't opt-in-or-opt-outable.

Props to the authors, it definitely looks cool, but I can't help but think this, and the "Cucumber for Go" posted a few weeks ago have missed the point.

There's decently documented reasons why the Go testing package is the way it is, for a number of reasons (of varying validity). I tend to trust the core team of a language (at least until we've exhausted all the capabilities of the the stdlib and std tools)

> Since 1Password 4 it is possible to have multiple vaults - one of which I share with my colleagues via Dropbox. That way, everyone has access to the passwords if they know the master password for the vault AND have access to the shared Dropbox.

My co-founder and I switched to that today, rather than me being the "gatekeeper", feels much better. I'm a dev, he's a marketing guy, and it works perfectly for us. 1Password is the best $35/head (With volume discounts available) you can spend to keep things safe and secure.

We're building something similar for https://harrow.io/ which acts as the secret store, it's a Redis API compatible database with a strong auditing layer, and baked in crypto, it requires a single key to start and unlock the server, but we didn't know how to split the key to keep the secrets out of a single dev's hands. Now that we do, we'll build something based on the SSS algorithm and YubiKeys (which we use for all other tokens)

For what it's worth this is a decent approach for naïve applications such as a contact form or similar.

This doesn't really work when you get into the kind of validations that are really important in web applications with multiple users, the canonical example that springs to mind is email uniqueness validation.

If one lets the database err out with a constraint violation, and bubble the panic (thus 5XX) up to the browser, that'd be a terrible user experience.

As such I have the concept of domain errors in my application, they have the structure `map[string]string`, and are related to a domain object (User, Message, Project, etc). The package is `myapp/domain/errors`, and `domainError.ValidationError` is a concept shared by my persistence layer, as well as http handling layer, when a given entity is to be persisted, the backend might return a `domainError.ValidationError`, or there may be a legitimate (connection lost, for example) error, so they are handled through a late call to infer the `err.(type)`, and switch modes based on whether it's a validation error, something more fundamental, or simply nil.

Separating the notion of a validationError to something that can be propagated through your own microframework scales much better than this ad-hoc mechanism. That said, the OP is right that this works in this case.

I have no affiliation to the site linked, actually it was the first result that wasn't about.com.

Following some of my comments on the “Meals/Feels” thread (https://news.ycombinator.com/item?id=6601091) earlier in the month, a number of people contacted me mentioning that they also had these symptoms, but had never put things together.

Showing up for work at 8:30 and being useless, frustrated and unable to focus by 10:00, probably that bagel you ate for breakfast.

I just wanted to put out a link in a place where people might run into it, that might just improve your quality of life!

Whilst I can't stand by suggestions to go to a caveman diet, I can stand by advice to experiment with your food, and be aware that being short tempered, unable to focus, and a menace to your team might be related to something as innocuous as your daily bread.

I might also add that I didn't realise that always being in a negative mood, having no drive to proceed with life, having no ambition, not sleeping well, etc seem like the characteristic "early 20s" mood that most people "go through"… I didn't recognise until after I became healthy what healthy really feels like.

Now I run 15-20 miles per week, I'm 30Kg lighter than when I had allergies, and since my diagnosis I've had the drive to found my own agency business and (almost) get a SAAS platform out of the door.

Meat, rice, fish and salad (without dressing… vinegar and dairy based are pretty much all you find anywhere; I eat a lot of olive oils and citrus juice)

Nothing indian (all creamy, milky), very few asian recipes (i.e no sushi, I'm intolerant of the green stuff they roll it in), anything with coconut milk is a decent start.

Most "egg replacement" for baking contains stuff that I just can't eat, so anything baked is out of the question.

I was fortunate when I moved to Germany, my company's recommended doctor was the only one I could find who spoke english, and he was a sports physiotherapy specialist with a side training in homeopathy; for all that I believe it's quack science, the holistic approach to "maybe you have bad skin because there's something wrong somewhere else" was a valuable insight.

My health insurance paid the first €200 in blood testing (€50 basic panel, 150 wide panel), having established that there's no "cure", they won't insure the condition any further, but that's OK.

As someone who suffered for 7 years being treated for dermatitis when I had chronic undiagnosed IgE (https://en.wikipedia.org/wiki/Immunoglobulin_E) issues, this looks perfect.

The effects of my intolerances as they are referred to is that whenever I ingest anything containing (almost 160+ other things) eggs, dairy, cereals, fructose, vinegars, anything with Soy/Tofu, apple skin, tomato skin, yeast, and over ripe bananas I have serious mood changes, not to mention GI issues, and suffer with dermatitis on my face and arms. It is also characterised by bloody boils deep in the skin in fatty (I'm 70Kg, 183cm and 13% body fat, so that's relative) areas of my body.

This went undiagnosed for so long, that I never counted on a cure, and, in fact there isn't a cure, my body has become allergic to those foods for some reason, and eventually it may be that my immune response subsides, and I can once again enjoy them.

(Note about how thrilled I was to hear about Soylent, and then how dismayed that they decided to hone in on the cheapest possible recipe, at the expense of the "Pea" protein variant which might have been suitable for me)

I think the meals/feels app could make a difference to any hackers who take the time to use it.

For anyone else, who thinks they may have allergies/intolerances similar to mine, beware that topical allergy testing won't catch it, but a focused blood panel for IgE response might. As far as typical reaction times go, GI disorder can set in anything from instantly, to 24 hours later, and the effects on my mood, and skin, etc have lead time of anything from 24-100 hours, and a recovery time of as much as three weeks.

Tom's article is a really great run down of all the awesome things that we built.

Tom `seenmyfate` Clements has been helping to support me over the last three months when I've been very burned out, and has really taken my vision for v3 and made it reality where I wouldn't have been able to. He'll always be around taking care of Capistrano as his company grants him some 20% free time to work on it, I trust him implicitly, and he already has deploy and unregulated commit access.

Tom, if you are on HN, you're the only reason this project has been able to come as far as it has. Thank you.

Regarding Harrow [1] bretthopper, I absolutely am, and this is where I want to focus my work, and to be able to build a company around deployment best practices and Capistrano.

Regardless of frameworks, and of technologies and platforms, I believe if I can take the load off myself with Capistrano, by turning it into the open source component of a best-practice company, and build teams of passionate, skilled support engineers, then I'll be where I want to be.

Unfortunatley Harrow would suffer if I give up on Capistrano, as part of the promise of Harrow as a SaaS is that it's all guaranteed to stay compatible, and work as we've all come to expect, just with improved workflow, etc...

([1] http://www.harrow.io, please excuse the missing graphic placeholder I've not updated the landing page in some time as I've been focusing on building the product, and the landing page performs really well without that graphic in place)

There's a number of problems, but foremost is that there's no good way to "roll back" assets, and there's no concept of keeping assets that might be used by old versions of pages cached in CDNs, when they have been replaced by newer assets. This is a problem of the manifest system, and of the `assets` directory always representing the current newest state, not the collective state since the beginning of time. Maintaining state from the beginning of time would bring it's own problems, thus many of the workarounds about tracking old, and new assets are time consuming and sub optimal, and unfortunatley people need them. There's a cap task which touches `mtimes` of all referenced assets, which can typically take 5 minutes to complete. It's naïve, and stupid, but it's the only solution (that we could come up with) to a real asset pipeline problem.

I'm also of the opinion that compiling assets in production as a part of your deployment process is insane, there's so much magic in the Rails asset pipeline that it's not uncommon to turn up bugs where tables don't exist, and the rails app can't initialize, or some javascript runtime environment isn't found which can leave your deployment in a broken state.

I'm firmly of the opinion that assets should be compiled and checked in, but then of course you run into problems with rails serving those in development mode, rather than the development files.

All these issues are fixable, but they're all indicative of tools that aren't quite mature yet, and as Capistrano sits on the boundary of where these problems come to light, it seems to fall to us to deal with it, and to educate people on what they ought to be doing.

Education is no problem, I really believe that the de-facto standardisation of Rails-like deploys (i.e timestamped releases, with common linked directories, and a symlink to the current active timestamp) is an excellent result for knowing what to expect in an environment where there's hundreds of ways to get Rails apps running, but it's still not as smooth a process as it could be.

I'm familiar with at least one project that's been re-written in Scala and Java because the previous version was prohibitively difficult to deploy as it was in RoR. (GrayLog2, to namedrop them)

As I wrote in the mailing list post, it'll be made mainstream this week, as I think it's a general improvement in all areas, at least it's faster, easier to debug, looks and works better, and has better out of the box compatibility with Rails (3 and 4).

The motivation behind the rewrite was in order to bring the project to a state where people who weren't intimately familiar with the internals would be able to contribute.

The rewrite is a ground-up re-think, but it's leaning on the best of what the open source community has come up with in the last 5 years, and leaning heavily on all the best practices we've learned as a community.

The rewrite was also a way for me to say "this isn't a rails tool anymore" (of course, those of us who knew Capistrano well could always cut out the core railsisms and use it for deploying pretty much anything). And a way to say "look, this tool isn't magic, it's an orchestration tool that glues together some other libraries".

Part of the rewrite was to split things into components, so that when people have a version that works for them, bug fixing changes to rvm or rbenv, or other extensions don't have to risk breaking the core functionality. Stability through modularity.

A way for me to pay my envisaged debt to society for the good things that being the custodian of such a widely used project has brought me.

Many of the v2 releases were broken as I tried to let two people help me with maintainer ship, and both of them went a little nuts accepting pull requests, and a lot of things got merged that probably weren't quite upto scratch, or caused subtle problems, which is a huge problem of Capistrano.

I'm grateful to both of them for their bravery, and willingness to try and help, but maintaining it has been such a hard task. A balance between maintaining compatibility, and not breaking people's production environments, and pushing the tool forwards, and improving it.

I'm the OP of the mailing list post, and have maintained Capistrano for the last 5 years. I'm passionate about providing great open source tools, my business and reputation are built on Capistrano and I don't want to give it up, but it's destroying me.

Whilst we're bashing them for IP theft, can anyone tell me why they're using the Github Octocat logo for their “Freedom” point? It doesn't appear to link to Github?

I happen to know (no time to look up the patent number now, sorry) that this is covered by a US, and EU patent. A friend of mine lost more than €30,000 to being sued by a firm that already holds the rights to this.

I hope he figures it out before they start trolling him. My friend's “invention” also covered a product on beer-mats and serviettes that would change colour under the same circumstances, unfortunately the patent he was facing down was so broadly written that it covered basically anything that could be used to detect daterape drugs in a drink by indicating it somehow.

Surely the patent could have been battled, but he wasn't in the financial position to do so.

Actually I believe the containers are implemented with something similar to http://lxc.sourceforge.net/ which is more akin to a process level chroot, and kernel resource limits. This also the same technology that fundamentally underpins Docker and some other similar super-lightweight virtualisation technologies. With lxc and buildroot, for example it's trivial to create a self-contained 20Mb image for running a PostgreSQL server. With all the security guarantees [sic] that would be provided by paravirtualisation.