zphds

In a high-stress environment, try to sleep well and eat healthy. Sleep is important!

oooh, as a software engineer, too low... too low...

In our defense we do not have hundreds of millions of years of test driven development. :P

Same here. I had the same problem especially when dealing with problems that required me to go back and (un)learn stuff from scratch.

I found that the greatest barrier to deal with seemingly hard concepts was getting the right intuition on what "might" be happening under the hood. For me, this is absolutely crucial even if my intuition about a "thing" might not be completely correct.

As someone who didn't go to a classroom to be taught a lot of the basics, I dive in head-first to read papers, I mean a lot of papers, to help build this mental model EVEN though I don't understand everything in it, but it lets you pick up patterns for solving similar problems you might be having.

For things you don't understand, you can always fit in these gaps in your mental model as you dig deeper into the abstraction cake and repeat the whole "intuition" building loop.

I find that the same also applies to Math and other domains which build on a bunch of primitives that has to be really well known to be able to reason in higher abstractions.

I feel software is no different... dig deep enough, there will be a hashmap of some sort.

`uncomplicate` libraries are awesome. Thanks so much for all this write up and putting out one of my favorite pieces of open source code.

It's just so easy to rapidly iterate when it comes to doing experiments on the GPU with Clojure and these abstractions. It just feels right

I had to deal with similar memory corruption problems but I could just piggy back on Clojure's concurrency primitives to keep this under control without pulling my hair out with all the ugly boiler plate and having that sweet sweet repl on the side.

`(with-release...)`? Oh yes! Please.

<end-rant> The sad part, like all Clojure code I have written in the past, I am having a more social problem of convincing people in my team to use tools like these to make their lives easier, especially when you can quantify the productivity gained. People now see me as the lone crazy lisp guy in the corner and is making me question a lot of absurdities in the software industry. </end-rant>

I really dig the line protocol. Pretty simple.

Any HA features? Sharding to look out in 2.0? Or is the general idea to set streaming relays of influxdb tsm's and treat HA as an L7 proxy routing problem (shadow metric traffic using envoy for example). How do people handle this in their production setups. Curious to know.

It would be cool if the query engine could talk to multiple shards spanning multiple machines for dealing with high cardinality series.

Same here! Trawling around forums and mailing lists to try and get Beryl working on my old desktop with a cheap-ass SiS integrated motherboard was quite a learning experience. Dead-ends all around.

Also learned what hardware acceleration was all about and that my motherboard's VGA chip specifically didn't support it. The first thing I did after saving up for a new laptop was install gentoo+beryl+gnome on it and rotate my desktop cube in all its hardware accelerated glory. Fun times!

Yesterday, as I was taking a left turn with my motorcycle on a big intersection with flashing red signals, I couldn't help but wonder if I'd be able to communicate with self driving cars that it's my turn. It was chaotic and required some level of consensus among the vehicles involved.

How does Timescale solve the problem of retention. In InfluxDB, old data is thrown out at every tick as the retention window continuously rolls. In the world of Postgres, wouldn't this mean an explicit cron-like DELETE of rows all the time?

Here's another similar library for Clojure. https://github.com/overtone/overtone

Recommend this talk that made Music 'click' for me. Also fun if you are trying to read GEB and generate cannons. https://www.youtube.com/watch?v=Mfsnlbd-4xQ

Haha! Thanks Mickey! Was a fun summer.

Mickey was my mentor and didn't get a chance to directly work with Sean and Harold. My project was to build APIs in Vala to control the hardware (volume, screen brightness, etc) through DBus. Was a great learning experience but could see the ominous signs towards the end of my summer.

Got a device to hack on and the fact that I could SSH into a phone and have a shell to goof around was exciting back then. Android was just announced IIRC and getting it work on Freerunner was so much fun.

As a Google Summer of Code student way back in 2008 for Openmoko, this brought a lot of memories :).

Here's my understanding. Please correct me if I am wrong. Visualizing your program as a tree of values that are borrowed, owned, mutated through variables helps in reasoning about the borrow checker

When a variable owning a value goes out of scope all the children goes with it. Remember in rust, there can only be one owner to a value (Rc and Arc variables lets you have multiple owners but that's for special cases). Therefore, if you're passing a variable to a function you should either

1.) transfer ownership to the function being called.

2.) have the function being called borrow the value through references. Since this doesn't transfer any ownership you can have multiple references to the same value. The value and its children (think of a Vec<Animal>) are taken down from the tree it belongs when the variable owning this value goes out of scope.

That's the cool thing that does rust does. The compiler knows when to free things just by following this one rule. A value should have only one owner. The responsibility of managing memory is now taken by the compiler instead. Hence no dangling pointers or segmentation fault unless you use `unsafe` blocks where this assurance isn't valid anymore.

Visualize your program to be manipulating these multiple trees made up of diverse types.

Note that keeping them separate has a benefit that when your 'Visualization' portal is down, your 'Alerting' systems are unaffected (and vice versa).

Collectd, telegraf. etc, can be configured to send the same metrics to your favorite TSDB and Alerting system (like riemann) in parallel.

Great work! Including a way to set grace periods will be really useful to prevent flapping on the metrics. ex, 'Alert When CPU > 95% for 10m'

"Don't do that"

try!() is a macro. Hence all it does is take a given expression and expand the whole thing into a if-error-then-return block. I guess you say that it's an explicit return under the hood.

It's worth mentioning that try! is a macro that basically takes that expr and turns it to something similar to your go example.

We do this with telegraf + influxdb. It has support for tags in measurements where we add the release version among other metadata which we can then visualize in grafana with a simple group by in the query.

You can also shove in multiple related metrics as part of the same measurement.

https://docs.influxdata.com/influxdb/v0.13/write_protocols/l...

'Pair Debugging' in my experience, is much more effective than Pair programming.

And the constant "No, no that line"... Ugh!

> To clarify, we don't think of these specs as URLs

That makes it a lot clearer. :). Looking forward to take noms for a spin soon.

But isn't `<database>/<dataset>` more or less similar to `<database>::<dataset>`? The only difference is the choice of a delimiter to disambiguate between a database and a dataset. For me, the first scheme is much more familiar.

Going through the SDK docs, why was a scheme like 'http://localhost:8000::people' chosen instead of the plain old 'http://localhost:8000/people'? Are there any benefits? If yes, curious to know what they are.

It definitely complements TPP. For me, Pragmatic Programmer was a better bed time book.

Add visualizations to DOM changes as well and you have a 'living' tree. ;)

We've been using riemann and it's wonderful. There's a little bit of learning curve as the configurations are just clojure code, but since it's all code you can build whatever you want on top of it if you know some Clojure. The DSL is well thought of and we ended up writing a REST API on top of riemann to make our monitoring stack self-serviced for all the internal users.

Radiolab did an awesome puppet-show/episode on this topic.

[1]: https://www.youtube.com/watch?v=ZYoqtBEzuiQ

Had to write a plugin to Elasticsearch recently. Was like a fun little hike into the source code without the documentation. On one hand, it could have been helpful. But on the other, I couldn't have learned a few internals of how ES works.

Didn't know about this. Thanks for the link.

Not the OP, but w.r.t. [1] vendored dependencies are especially helpful if you happen to deploy the software on premise where you might not have full system access and in some cases, no internet or also strict policies on what can be installed.