evancordell

I used that imagery mostly because other preceding resources about Macaroons use macarons (there's even an unofficial logo[0] for macaroons that are actually macarons). But according to wikipedia[1], macarons are simply the French variety of macaroons.

If you ask me, French macarons are way better than the coconut kind.

[0]: http://macaroons.io/

[1]: https://en.wikipedia.org/wiki/Macaroon#France

We use microservices at my workplace with a team of 5 and have since the beginning. From reading HN it seems like we may be the only small team to have benefitted from the approach?

Some advantages that this article seems to ignore:

- Even with a small team, microservices allow us to make small iterative changes to services without touching other parts that are working as they should be.

- It's easier to find and patch bugs when they can be pinned down to a smaller codebase and fixed in isolation (most can be).

- Local development becomes easier - you can spin up just the services you need for the feature you're developing instead of the entire system.

- It's easier to get "up to speed" when you need to add a feature when you're working with small codebases (and often only need to touch one or two at a time).

- In our case we have three distinct sets of consumers: two fairly separate groups of end-users, and automated services (m2m). It's quite common for any issues we have to only affect one of those three sets of groups because they are largely isolated in different services.

That's not to say there haven't been some headaches, but I personally much prefer our service approach to a monolith. I really think the key is removing operational friction of working with services with tooling.

> If anything, I think the opposite of your statement is true. The further away from the standard you get in your exotic preference, the easier it is to compartmentalize that layout, the easier it will be to switch as needed.

This has been my experience as well - even with very muscle-memory intensive things like vim.

> the most durable key caps around

I see that they have a PBT doubleshot option now, but I have a WASD v1 with custom printed ABS keycaps that are almost completely blank now. Just pointing out that it definitely depends which of their keycap products you get.

> Exotic features like a split keyboard, matrix layout, and strange thumb controls are just annoying and non-standard.

To each their own. A split keyboard with thumb clusters has been the most comfortable typing situation for me (in addition to a negative tilt which doesn't get a ton of discussion - if the front of the keyboard is level with your wrists and tilts down away from you, your hands are left in a much more natural resting position)

I use an ergodox and recommend it highly. Massdrop has drops of the "ergodox infinity" from time to time, which is assembled except for the keys (you'll need to solder them in yourself, but that's a lot less work than building the original design)

It's almost vaporware at this point, but I'm still waiting for AcidFire's Axios[0], which is based on the ergodox design but with very carefully thought out improvements (adjustable thumb clusters and built in tenting being the main two)

[0]: https://geekhack.org/index.php?topic=44940.0

I've been evaluating the new Docker platform for a few months, and I definitely prefer it to anything else I've used. It fills a void that I was frustrated existed - there aren't, or at least weren't, any CI hosts that would take a repository with a docker-compose.yml file and let you run tests against the services defined therein. To be clear, Jet doesn't do this exactly, but it does let you define services with the same format as docker-compose.yml which I've found to be even more useful.

Currently we use a custom AMI (with docker and compose installed) running bamboo on bamboo's on-demand service, but we've been bitten a couple of times as Bamboo updates their protocols without notice and causes our agents to start failing. It's not an issue if you use their official AMIs, but maintaining your own is not as easy as you'd hope.

That said, I have had some problems with the support channels at CodeShip. I know I've just been a free user evaluating the service and am probably not a high priority, but my experience hasn't been positive.

After activating Docker builds for my account, I was unable to get a test build working. It turns out that this was because of an unusual bug with service names (if I named my service `web`, it would attempt to load up what looked like an internal codeship container instead of the one specified in my config), but I didn't know that at the time.

My first support request was simply ignored. After a couple more months I decided to try a build again, but the bug was still affecting me. My second support request was dismissed as a temporary problem with the docker build services ("running out of resources") which seemed unlikely given the circumstances.

Through trial and error I discovered the service naming issue and followed up on my support ticket to report it. No response to that, either.

All in all I came away thinking it was a pretty nice service with pretty lousy support.

I just watched a review yesterday that I thoroughly enjoyed: http://youtu.be/xH7nnPnc56Y

Made me very interested in playing it!

I've recently settled on a mostly-free self-hosting platform: Jekyll + Github Pages + Google Domains + Kloudsec.

Jekyll and Github Pages keeps the deployment simple and Google Domains has proven to be simple, cheap, and reliable. I tried Kloudsec out last week on a whim after seeing it on HN, and so far it's great - simple, free SSL with let's encrypt.

https://evancordell.com if interested. It needs a little more love before I'd really say I'm pleased with it, but I'm very happy with how cheap and easy it was to set up a personal blog with SSL.

> Recursion is great for algorithms that perform operations on data that can benefit from using a stack, FILO (First In Last Out). It can be faster than using loops and can make your code much simpler.

I can't think of a scenario where recursion results in a faster algorithm than an iterative form. Almost always recursion makes an algorithm simple to express and understand, while the iterative form is almost certainly more performant and the expense of a little more opacity.

I enjoyed reading all of the Go details even if I think that the takeaway should've been "write recursive algorithms in an iterative form if performance is a concern" (in Go).

I was slow to get into podcasts as well, but since I have a 1.5 hour commute I eventually became a big fan.

Something key for me was to find podcasts that don't "work better as articles" as you say. There are many tech related podcasts and I find most of them unlistenable.

Instead I found that more entertainment/comedy or seminar-like discussion works better in the podcast format. Maximumfun in particular has a lot of very high quality podcasts (with high production value, which tends to be a big factor in whether a podcast is listenable).

These are just my personal preferences, but one of these might "make sense" to you as a podcast if you give them a chance: The Adventure Zone, International Waters, Judge John Hodgman, My Brother My Brother and Me, The Partially Examined Life, Sawbones, Oh No Ross and Carrie, and of course Serial. For tech podcasts I only really like The Haskell Cast and occasionally a Changelog.

To me that seems an especially profound analysis. It aligns with my experience very well.

I can't figure out a good way to use Twitter. Follow celebrities? Seems cool at first but as much as I like Steven Fry's work, his hourly musings don't add much to my life. Coordinate with friends? Why wouldn't I just text? Keep up with news in areas that interest me? Hacker news and Reddit cover they pretty soundly, and it's much easier to read and participate in discussion. Perhaps professional networking is where it would shine, but emails and mailing lists feel like a better fit to me.

I keep an account because I hear it's good for building that "personal brand" that I think I'm supposed to build at some point.

There's a paper called "Capability Myths Demolished" that addresses this. There's an online version here[0], see "revoking access".

Personally I'm fascinated by ocap systems and am always looking for ways to employ them. There are some interesting "modern" applications (aside from a couple of research kernels) like CapnProto and Pony language. Macaroons come close but are more of a hybrid approach to authorization. (They don't out of the box prevent confused deputy or anything)

[0]: http://www.erights.org/elib/capability/duals/myths.html

w3 has some guidelines on capability urls: http://www.w3.org/TR/capability-urls/

I work as a developer in Baton Rouge but I live in New Orleans. (I commute and work remotely)

I'm not really active in the New Orleans "dev scene" but there is a small one as I understand it. There's a group that meets in the CBD for a weekly hack night - I went years ago and found it not to my tastes (mostly frontend javascript/css at the time) but I've been meaning to go back and check it out. There's also a NoFun (Nola functional programming) group I've been meaning to stop by, but they don't meet as frequently from what I can tell.

New Orleans is a really cool city that has a unique vibe. The food is excellent and varied, and there're some great bars and music. A lot of times it feels deceptively like a small town, and it's easy to forget that it's not the safest city.

Tulane is a beautiful campus and in a very nice part of uptown. (My wife and I both went there)

To sum up: City - Awesome, Dev Scene - Not as awesome, but I might just not be trying hard enough!

Something that I find interesting that not many people know about greater New Orleans is that there is a very large asian (especially Vietnamese) population. I go to the asian market across the river almost weekly, and you can get some of the best Bahn Mi in New Orleans. (This is largely because of the Catholic church aiding refugees during the Vietnam war - New Orleans has an interesting history!)

Happy to see some New Orleanians on HN!

I also went to lsmsa and had a great experience. Can't really say enough good things about it; it was such an amazing atmosphere compared to the public high school I attended before.

Thanks for the detailed comparison! Sounds like you are doing some really interesting things and sandstorm.

I've looked at Capnproto in the past but did not read through the documentation thoroughly enough to see the bits about capabilities (or the link to the pdf version of the same myths article I linked above!)

>For Sandstorm, we actually don't quite want that, because we want the document owner to be able to see how their document has been shared. So, to share a sturdy ref, we require you to restore it to a live ref and delegate that. The recipient can save a new sturdy ref tied to them.

@bascule alluded to this, but this can actually be very nicely modeled with macaroons! The idea would be to create a capability-granting macaroon but attach a "third party caveat" that asserts the grantee must be able to prove they are the "authenticatable identity". You end up with the same properties as the live/sturdy refs, if I understand properly.

Mostly it's just cool to see different implementations of capability-based access control.

Capability-based access control is fascinating. Here's an interesting article about capabilities vs. ACLs: http://www.erights.org/elib/capability/duals/myths.html

I'm also a fan of Macaroons for this purpose, which I was disappointed to see weren't being used here. But for an example of using macaroons as capabilities in practice, see: http://hackingdistributed.com/2014/11/23/macaroons-in-hyperd...

This is awesome! And it comes right as I've been getting my feet wet with Haskell (and property-based testing).

It was really easy to get up and running with a simple test: https://github.com/ecordell/pymacaroons/blob/property-tests/...

and I'm excited to use it in more places. Though I'll have to configure tox/travis not to run hypothesis tests on Python 2.6.

I've been working on getting a dev environment set up with docker over the weekend, and I finally have something I'm happy with.

I don't have a nice blog post to show you, but the basic idea is:

- Use the CoreOS Vagrantfile (+ extra files like user_data and any service unit files)

- Share your local directory with the vagrant box with config.vm.synced_folder (just uncomment a line in the Vagrantfile)

- set the DOCKER_HOST and FLEETCTL_TUNNEL env variables so that the local tools work transparently with the vagrant box.

- Then you have the option of running a docker image with -v and sharing the vagrant directory with the docker container, or

- You can dive into CoreOS stuff and write a unit file for your service, and that will share the directory with -v

Now local files sync into the docker container, and if the server is configured to reload on file changes you're good to go.