cortesi

My pleasure! Sortvis is down at the moment, but will be back up soon. I've been swallowed up in other projects, but I have a perpetual new year's resolution to write more blog posts. Keep an eye out in the next few months. :)

It looks like we've traveled a similar path. The precursor to binvis is scurve, a (slow, dodgy) command-line tool to do basically what dump2png does:

https://github.com/cortesi/scurve

I have a blazing fast command-line version of binvis in Rust that I plan to release in the next month or so. I really need make some time to turn back to this.

This is lovely. An interesting thing to think about here is the layout of the sequential time-series data. This visualisation breaks the sequence out into columns, which means that squares that are close to each other in the sequence don't cluster visually.

I've played with using space-filling curves for this to visualise binaries:

https://binvis.io/

You can play around on there with the scan layout (similar to the Netflix layout) and compare it to the Hilbert curve. You can click and drag to select regions in both (similar to the video for this visualisation).

There are tradeoffs - the Hilbert layout is not intuitive, and you have to play around to select regions accurately. On the other hand, the clustering lets you visually pick hotspots in much greater detail, e.g.:

https://binvis.io/#/view/examples/tcpview.exe.bin?colors=ent...

I've found it useful to be able to toggle between both scanning and clustered layouts, and plan to explore some more interaction paradigms when I get time to turn back to the project.

Sure - in my case this would be a load balancer on Google Cloud configured through a Kubernetes ingress. All the public paths available on the Auth microservice would have to be listed explicitly. You have to be very sure in this scenario that only the public URLs are reachable.

I see the motivation for sending user passwords straight to AuthN, but I do wonder if on balance the dangers of correctly configuring a shared public/private service don't outweigh the dangers of relaying the password through your front-end (which has to be able to access private endpoints on the AuthN service anyway). If you really didn't want your front-end to touch passwords, you could have a tiny sidecar service that only exposes the public endpoints and speaks GRPC to AuthN.

Anyway, this is well into debatable "matter of opinion" territory, and I don't want to waste your time. Thanks for publishing AuthN - I'll keep a close watch as you progress.

Good stuff.

I have one other bit of feedback on the architecture, and I realise that this one might be too different from where AuthN is currently. I see that there are a small number of API endpoints that you've marked "public" that users are meant to be able to reach. In practice, the user's POSTs would always be terminated upstream from the AuthN server itself, either at a gateway or by just relaying the requests through from the front-end servers themselves. A service that's part public/part private is much more perilous than a service that is one or the other. All things considered, these public endpoints seem like a very minor convenience to the integrator. I would just make the AuthN API private, and ask users to implement the public endpoints themselves by making requests to the AuthN API.

If you DID make all endpoints private, you're no longer tied to HTTP, and you have a nice opportunity to use GRPC instead. I've recently started rolling it out in my own services, and it's unexpectedly great considering the track-record of similar ideas. It's very performant, pleasant to work with, has a mature ecosystem of surrounding tools, and you get client API implementations in a wide range of languages for "free" (or at least at a cut price).

It looks like the /stats endpoint consults the Redis database and returns processed data. If we're aggregating metrics externally, it would be more idiomatic for this to be totally stateless and just expose hot metrics - it's the aggregator's job to store and process the data. This can be quite painless using something like the Go Prometheus library.

Being tied to Redis is also not great. For instance, it looks like everything apart from the metrics could comfortably live in Google Cloud Storage if you had a backend for it. Cloud Storage really isn't an appropriate place to put frequently updated counters, though. So if I deployed AuthN, I would want to be able to ditch Redis.

I should stress, though, that these are quibbles. I think AuthN looks very nice, and the quibbles are cropping up because I'm trying to figure out if I can use it. :)

This looks pretty reasonable! I would love to see a Cloud Storage backend. A minor quibble is that I think that managing your own metrics in Redis is probably not the simplest or most flexible approach - instead, you should consider exposing a /metrics endpoint that can be ingested by the user's monitoring tool of choice (Prometheus/InfluxDB/etc).

Glad you like it! I have a long list of features planned for binvis, and word width is one of them. I'm a bit busy at the moment, but will make more time for the project soon.

Something we'll be focusing on in the next release cycle is much better export and import to/from other formats. We already have pretty good HAR support, and that's going to get much better soon. I don't know if the SAZ format is well-documented... but Fiddler is an excellent tool and we'd like to be able to work alongside it. I'd certainly merge SAZ support if, say, I woke up tomorrow morning to a PR implementing it.

It probably has to do with psychology more than anything. My mental model of this sort of development (if you'll permit me to be a bit florid) is of an eternal pilgrimage of small incremental improvements, without any fixed destination or many real landmarks along the way. The TODO list for mitmproxy has never grown shorter (and never will), so I just never reached a point where declaring a 1.0 was obviously right. I realise this is eccentric, doesn't reflect the maturity of the project, and is probably not the way my co-maintainers think about this, hence the change.

For much the same reason, I'd like to de-emphasise major version increments as flag-fall events. Incrementing the major version inline with our development cadence makes sense from that perspective.

The console interface will always remain a first-class interface. We plan to bring mitmweb up to feature parity with the console, after which we'll make sure that neither tool has capabilities the other doesn't. I'm super excited about the new possibilities the web interface opens up for the project (watch this space), but the command-line tool is wired into my fingers. :)

Here's my anecdote. I had painful but not debilitating RSI-like symptoms for a couple of years. For me, fixing this came down to a set of fairly simple things: the Kinesis Advantage keyboard mentioned in the article, setting a timer to force myself to take rest breaks, focusing on posture when working. At least in my case, the issue seems entirely mechanical, and I'm sceptical of psychological and emotional explanations like Sarno's.

A bunch of other excellent similar projects have been linked here, and here's mine - a general purpose tool that lets you put together flexible responses to file system change:

https://github.com/cortesi/modd

The use case here is deep and interesting, and I don't know of any tool that gets it 100% right. HN is often quick to grumble about reinventing the wheel, but where there is no clearly correct solution I think we should encourage experimentation.

Modd is my opinionated take: it differs from other tools by trying to have a "proper" configuration language in which you can embed shell commands, by separating prep commands (that run and complete) and daemons (that run, but might need to be restarted on change), and by being completely agnostic about languages, test methodologies and other specificities of external tools.

I've been playing with this sort of idea on the HTC Vive, and I strongly believe that this is the future. Unfortunately, none of the available VR devices have anywhere near the resolution needed for this to be a workable proposition. Give it another 5 years or so.

I use both Sublime and Atom, and have switched over to Atom as my daily driver. While there's a small responsiveness difference, it's not enough to bother me for most use cases.

This is no different from any other business. You can be fined for operating a hairdressing salon without a license. This doesn't mean we've "partially decriminalised" hairdressing.

Well, I can't speak for the New Statesman, but that's just not what decriminalisation means. Here:

https://en.wikipedia.org/wiki/Decriminalization

I think people are just not using the terms in the precise and somewhat pedantic way we're doing here. :) I think New Zealanders are pretty familiar with the legal situation here, so making the distinction clear at all times is just less important.

You have this the wrong way round. Legalisation _does_ involve bringing something into the same set of regulations that applies to everything else, and that's a good thing. However, when we speak of "decriminalising" something, we usually mean removing criminal penalties for something that can still be against the law, and can still result in fines and other penalties. This means that the industry remains underground, which is usually worse for all involved. See the links I gave upthread for citations and the NZ context.

Decriminalisation usually means that some criminal penalties are removed, but an activity is still not "legal". Fines may still apply, and decriminalisation is usually partial (i.e. possession of drugs may be decriminalised, though you can still be fined, but dealing may still be fully criminalised).

Legalisation means going the whole hog - removing all fines and criminal penalties. This usually also means bringing an activity in the mainstream by, for example, taxing it like any other activity, or making it subject to workplace safety regulation. This is what New Zealand did with prostitution.

Wikipedia explains this reasonably well:

https://en.wikipedia.org/wiki/Decriminalization

https://en.wikipedia.org/wiki/Legalization

That's not correct - prostitution is fully legal here in New Zealand. Sex workers are covered by sex-work specific occupational health and safety regulations, pay taxes on their income, have government-mandated workplace conditions, can get insurance against workplace injury, etc. It really is "just another job", apart from societal stigma (which is gradually declining too).

See:

https://en.wikipedia.org/wiki/Prostitution_in_New_Zealand

http://www.business.govt.nz/worksafe/information-guidance/al...

I'm making a bit of a habit of chipping in on Atom performance complaints with a counterpoint. I've now used Atom as my primary editor for more than a year, and I have no complaints about the performance. This could be because I'm using OSX on recent hardware - I've noticed that my friends using Linux desktops seem to have more issues than I do.

Heh, I know what you mean. BTW, directly following that link from here gets you to jwz's wee joke about HN. You'll need to copy the link and paste it in a new tab to see the article.

Neat! The idea of putting the build commands into the code as a comment is very interesting.

Great to hear. :) Modd was born because because I was trying to figure out how to add the ability to do a build step before livereload in devd. It soon became clear that quite a different type of tool was needed to do this well, and after a few iterations I settled on the current design for modd.

Just chiming in to say that this agrees with my experience completely. I also shifted from Sublime to Atom about 18 months ago, and have no regrets. Atom improves at a steady clip, and the package ecosystem is great. Despite the sniffy negativity here on HN, I've never had trouble with Atom performance or stability. I do still use Vim on the console for some things, and that will probably never change, but Atom is has become my "daily driver" code editor.

I've been using Atom full-time for about a year, after switching from Sublime. I'm happy with it as an editor, and like the momentum behind the plugins ecosystem. Performance has been completely adequate, and I've seen none of the issues that always seem to crop up whenever Atom is mentioned on HN. There may be a platform difference - I use it on OSX, but friends of mine on Linux have been less satisfied.

I do still resort to vim on the command-line for some things, but as a "daily driver" code editor, Atom has been excellent.

Well, first, I think it's perfectly fine to have multiple takes on the same problem space. This is how we progress - people try different things, and we gradually figure out what works. Live-server does a specific set of things, and devd is a different take on a slightly wider set of things, and I think that's just dandy. The overlap is far from precise, and I think there's enough room for both devd and live-server (and for the many other tools that do similar things).

Second, not everything is node. Devd has lots of uses outside of node and even outside of front-end development.

Third, I probably wouldn't have written it if I didn't believe that devd did at least some things better than the current tools (at least for some people). You should try it - maybe you'll like it, and if you don't then that's fine too. As you say - to each their own. ;)

I'm moving in a similar direction for similar reasons - but by shifting functionality out of the node ecosystem altogether. I recently released devd, a small, dev-focused HTTP server with build-in livereload which has taken the place of gulp livereload and node-based dev servers for many of my projects (https://github.com/cortesi/devd).

I'm now working on the next step. It's not quite ready to be announced yet, but I'm cooking up modd, a similarly focused tool for monitoring the file system and responding to changes (https://github.com/cortesi/modd). Modd has already supplanted gulp entirely for many of my use cases, and has replaced supervisor and a bunch of other tools to boot. Many of the actions triggered by modd for front-end projects are precisely invocations of npm scripts as described in the article. A few more features (desktop notifications with Growl/notify, and script access to the list of changed files), and modd will be ready for me to ask for public feedback.

Both modd and devd are small, single-purpose tools written in Go, released as statically compiled binaries with no external dependencies. I've tried to make them tight and focused, and if I get it right, they will hopefully be a refreshing change after gulp and grunt.

This matches my experience with react-router. I use it in a few side projects, and I have the feeling that there's been a lot of "design-thrash" - every new release seems to bring a new interface and new ways of doing things, without much real benefit.