876 karma · joined March 12, 2012
They've not been humble, indie, or a bundle for a long time.
Par for the course. Similar disingenuous commercialization is rampant through the games industry: see what Valve has done to Steam, and what major publishers have done to their titles vis monetization.
Unfortunately the games industry is floating in too much money for another crash to clean house.
Garbled circuits don't scale.
I assume you're using a jsonb column, and going horizontal?
I'm thinking of implementing a similar system – though not using Go.
(In fact, I'm writing a GenStage consumer right now.)
Most often I see TDD used as a couch for a really bad type system.
As a starting point, I would recommend reading Google's paper on their project "Dapper." [1] It's essentially the core of most distributed tracing systems. At least those I've encountered.
There's a lot of tooling out there that take their cues from Dapper. I've recently been looking into integrating OpenZipkin[2] with our systems. I see at as a more viable alternative (no tie in!) to Yet Another Propriety Thing in AWS (YAPTA). There's other as well, like AppDash.
Recently there has been a push towards an open-standard for the collection side called OpenTracing[3]. I came across it when investigating LightStep[4]. Ideally that means no vendor lock-in, which of course has lots of knock-on effects.
If you know of any, I'd love to be pointed in the direction of _different_ and not just divergent techniques.
[1]: http://static.googleusercontent.com/media/research.google.co...
[2]: http://zipkin.io
[4]: http://lightstep.com - Impressive team behind this.
There's https://sourcing.io, but it's rather neglected.
Recently, I was running a hiring campaign to grow our team. It sucked. Most of my workflow to identify talent and to manage outreach could have been automated. I also did research on competitors and other companies to figure out how to position our job ads.
What I really needed was:
1. A central, searchable database that aggregated as much data as possible about the talent out there;
2. a central, searchable database that aggregated as much data as possible about other positions out there;
3. a tool that used the aforementioned databases to automatically identify and suggest fixes to my weaknesses;
4. finally, a tool that automated outreach.
On #1 and #2, tell me who's out there. Tell me who has interesting profiles. Tell me who I am within N-degrees of. Based on who gets hired, tell me who is hot. Tell me who's looking for work via Hacker News. I don't mind searching for this myself, but I need a crap tonne of data points to filter on. I did this manually (repurposing our database at Walter) to yank out ~20 outbounds that made the most sense.For #3, tell me how to improve my job ad based on what works. I had to rely on my intuition, and the feedback of my peers. It generated a lot of inbounds (~50 per position), but it also took a lot of time. Help me find relevant job boards.
For #4, give me a central place to manage 80% of my outreach. Post to the variety of job boards. When I fill the position, help me fan out let downs and schedule calls, and cancel the job ads.
Most importantly, do all the above without turning it into a enterprisey nightmare. That's the hardest part.
Oh, and don't take inspiration from AngelList's offerings. They suck. If they spent another 12 months working on data, they would eliminate a lot of the noise.
/rant
I could go on and on about all the crazy pains I dealt with. I hated it. I budgeted ~2 weeks (knowing I had intense focus). It took about ~4 weeks. 5 if you count closing. It should be at most 14 days to closing.
I really like pragmatic books like this; do you have anything in a similar vein? Specifically, I'm looking for a book focused on the practical application of fluid mechanics (not just plumbing). I know how daunting a subject it is, but that doesn't deter me from learning just enough to be dangerous.
I've been eyeing Granger's "Fluid Mechanics" (and most of the Dover collection in fact.) [1] It's more academic, so I would like to pair it with something more practical.
It helped me a lot to be explained quaternions starting from the complex plane. More specifically, by constructively inspecting their properties. There's a great interactive article that gets the pedagogy of teaching such a complex concept (pun definitely intended). Unfortunately, I can't seem to dig it up.
I recall the author's blog using all kinds of CSS and/or WebGL trickery to make 3d backgrounds – anyone know which blog I'm referring to?
Here's the slides: http://www.erlang-factory.com/static/upload/media/1434153406...
Snide aside, it's not this mystical technical panacea. As for community... it has had a large upswell of Rails developers... for better and for worse.
That said, I've had a wonderful experience with all the places I've used Elixir in production or soon to be in production.
You can always throw the NIFs onto other nodes. You can also write ports that are glorified external processes.
Other times, you just need low-latency and high throughput. In that case, you expect failure and design accordingly.
I implore anyone interested in Erlang or its surrounding languages, to read its source code. [2] More specifically, the BEAM. I'll warn you that it's very 80's hackeresque, but in a good way. Incredibly pragmatic. The way they achieve their world-class scheduling? Tip: not via a perfect theoretical design cooked up in some comp-sci lab. [3] If you've been following game engine design within the last 9 years or so, you'll probably have a good idea of how they do it. [4][5]
[1]: https://medium.com/@jlouis666/erlang-dirty-scheduler-overhea...
[2]: https://github.com/erlang/otp/tree/maint/erts/emulator/beam
[3]: https://hamidreza-s.github.io/erlang/scheduling/real-time/pr...
[4]: http://blog.molecular-matters.com/2012/04/05/building-a-load...
[5]: There's a hell of a lot of depth to this problem domain. Charles Bloom's guiding principles for Oodle are spot, and well worth a look.