rubenv

If you feel entitled to be negative; please demonstrate that you are perfect and never make a mistake.

Be a human: mistakes and problems happen, that's a fact of life. What matters is how you act upon them.

I'm sure this may be interesting, but with such low contrast it's simply impossible to read.

Any chance this works together with Kubernetes?

Sticking to ASCII in this day and age is nice and fun if English is your mother tongue, but it's a big middle finger to the rest of the world. Please don't.

Server Sent Events and H2 Server Push serve completely different purposes, one is about application messages, the other about loading resources.

But it's obviously much easier to criticize if you don't actually dive deeper than the name of things.

Latency

Or in Go, with full databases: https://github.com/rubenv/pgtest/

I for one like not having things rushed in which then cannot be changed later on.

Does this mean Go is perfect? Not at all.

It just means I'd rather have generics late than fundamentally broken.

Or: "How on earth could this code possibly work?"

It's better.

For PostgreSQL and Go, here's a package to spin up a temp in-mem PostgreSQL: https://github.com/rubenv/pgtest/

In case anyone else has trouble: turns out this was a Bitwarden auto-fill problem (thanks for dropping by on Discord to figure it out).

Will get this one fixed ASAP.

Cool, didn't know there were iRacers on HN!

If anyone is interested, we're building a new (and hopefully) better platform to handle telemetry/race data over on https://garage61.net/

It's still super alpha so not much to see yet, but moving fast (the HN-way :-)).

Love to have a chat with any fellow iRacing HN users, we're on Discord: https://discord.gg/94XwwyCkCW

AMA related to iRacing / telemetry

It's a blessing when you want to start a new project while offline (e.g. on a plane or train). All your usual dependencies are already there, ready to use.

Not that it justifies any pain, just found it to be a pleasant side-effect.

Sometimes it's worthwhile to just give in and try something new, even if you don't like it. You might discover unexpected advantages. Then go back to what you prefer and apply those lessons there.

Everything would be much better if we all kept an open mind and learned from each-others experiences. It might not always be obvious, but things are usually a certain way for a good reason. Might not be the best or right reason in the long run, but there's always some lesson to be learned.

I recently spoke about the approach we use at Ticketmatic: https://rocketeer.be/articles/coreos-fest-2017/

Where are these hosted?

Much queries per second is fine, but I care about latency. Unless you're in AWS, it'll be hard to beat AWS RDS on that count.

Or for those who don't call it "golang":

https://www.indeed.com/jobtrends/q-scala-q-golang-q-go.html

> I somehow always prefer a software, where you do things intuitively without needing to first learn a shortcut for everything

That doesn't even apply for an IDE. As a vim user I always feel lost in those at first.

Any tool with a bit of power will require familiarization. You won't get the most out of that IDE unless you learn it.

A good time to dig up an old article of mine: https://rocketeer.be/blog/2015/05/google-photos/ (Google Photos - Can I get out?)

My biggest complaint still stands: no true API (which is what made flickr great).

Love Google Photos, add a real API and it'll be even better.

First and obvious remarks:

* This breaks inter-op with other projects under a different open-source license. So for anything that's a library or a package: don't use this.

* What happens when other people contribute? Do they also get a part of the income (how?), or is this an implicit copyright grant (like a CLA)?

I guess this needs work, but it's good to see efforts to make open-source a sustainable business (not sure if a license is the right way to do it though).

It's the same stuff that powers the playground: http://play.golang.org/

More info here: http://blog.golang.org/playground

Nothing but love otherwise! In case it wasn't clear: Photos looks fantastic. Add an API and it's perfect.

Note that all testing was done with the paid "Original" option.

I happily pay for things, but when I do I like to verify that it does what it says on the box.

I've uploaded that RAW file with the "Original" (paid) setting. It's ok when downloading in the web app, it seems to be compressed in the Google Drive view.

Author here: Note that I did select Original and it still seemed to compress the RAW file in Google Drive view. Single downloads do yield the original.

Sure, an opaque binary file is pointless.

But that's not what most logging systems that log to binary files offer. They give you specs (example: http://www.freedesktop.org/wiki/Software/systemd/journal-fil...) and tools.

Binary doesn't have to mean closed/opaque.

(Author here)

Nope, that's the old one for V2 (which isn't very good).

We're currently releasing the third generation of the Ticketmatic platform, where one of the big efforts is in improving the developer story.

That's not public yet, for which I apologise. There will be a beautiful developer program soon.

I didn't think that the article should wait on that. It's the idea that matters and didn't want any discussion to turn into a nitpicking over what we did right (and wrong).

This article mostly came out of a frustration with bad API documentation and I was hoping to inspire people to do (slightly) better.

Absolutely, tooling is a hugely important in making or breaking any programming language/framework.

In the end it all generalizes to "Your product is only as good as its experience".

Asked too soon, this seems to cover it: https://cloudvertical.com/cloud-costs#cloud_costs/index

Still: anyone know of this with historical graphs?

Main way to install is through "go get", but if there is sufficient interest in binary packages, I'll have a look at making those.

While I mainly use it as a library, it is also capable of standing on its own as a CLI tool, so you could use this in pretty much any context (read: not Go).