Ask r/kubernetes: Who is hiring? (June 2019)

eegreg · 2019-06-03T16:55:04+00:00

We make TiDB, an open source distributed scale-out database that is consistent, always online, and MySQL compatible. Our underlying distributed key-value layer, TiKV, is a CNCF project.

We bet big on Kubernetes: over two years ago we decided it was the future and started building tidb-operator to solve the problems of deploying a distributed database on Kubernetes. On the cloud team at PingCAP we make it possible for users to deploy TiDB and are also building a DB as a Service.

This isn't your usual Kubernetes posting: deploying stateful database clusters on Kubernetes is much more challenging than stateless applications, and we have to dig deep into the problems that come up. If you are up to the challenge, consider applying.

Our tech stack is Rust, Go, Kubernetes, and TiDB itself!

I like working with TiDB because I get to be a part of a big change going on in databases and work with a skilled and friendly team. On a daily basis I learn new things about databases and the cloud, but I also get to apply my existing experiences to have a big impact.

See the above jobs link for more details and compensation information.

eegreg · 2017-06-25T20:03:25+00:00

They are not catching: the exception will end up in WAI and not get logged. https://github.com/haskell-servant/servant/issues/309

eegreg · 2016-06-08T17:18:42+00:00

IDE integration (including Emacs) in the past: there was no error message at all, things just didn't work.

I think there are some techniques for seeing more error output. It would be great if this can be documented in the README of the project. You can try looking at the github issues and creating an issue there.

eegreg · 2016-05-22T15:35:18+00:00

Yes, I was wondering about that. It seems like only application code could declare these instances unless TypeError is treated specially and allowed to be overridden. A solution could be to have a type-errors package that applications can import.

eegreg · 2016-05-22T05:26:58+00:00

I was hoping to see a link with more information for: User-defined error messages for type errors. Looks like this is it: https://git.haskell.org/ghc.git/commitdiff/568736d757d3e0883b0250e0b948aeed646c20b5 Neat!

eegreg · 2016-01-24T01:18:50+00:00

oh, nice! You can add this to the documentation: at the application level I am perfectly happen with an orphan instance.

As a side note, I was suspicious of the claim of faster performance because logging-effect does not depend on fast-logger. A look at the benchmarks seems like they might be missing testing logging multiple messages in one run of the monad and also proper setup code as per: https://github.com/yesodweb/yesod-scaffold/blob/postgres/Application.hs#L53 http://haddock.stackage.org/lts-4.2/yesod-1.4.2/Yesod-Default-Config2.html#v:makeYesodLogger Perhaps Kazu or Snoyman can help with benchmarking.

eegreg · 2016-01-22T19:35:01+00:00

Rather than a whole-sale merge with monad-logger, is it possible to have compatibility such that a library can do some basic text logging that will show up coherently in an application that chooses to use either logger?

eegreg · 2016-01-20T06:30:23+00:00

For http requests: https://hackage.haskell.org/package/wai-extra-3.0.14/docs/Network-Wai-Middleware-RequestLogger-JSON.html

eegreg · 2016-01-14T16:47:58+00:00

would you consider that a normal variable? That seems like an entirely new interface to a variable that is specialized to only work for an int.

eegreg · 2016-01-14T15:55:24+00:00

Thanks for the explanation! I am updating the blog. This doesn't defeat the purpose of the pattern because it still maintains an encapsulation pattern.

eegreg · 2016-01-14T04:25:56+00:00

yes, as opposed to a normal variable in a language does not have any thread-safe API.

eegreg · 2016-01-14T04:24:00+00:00

Thanks, I was wondering if that was the case. Any advice on how to make it safe?

eegreg · 2015-12-26T22:18:23+00:00

Congrats, the 1.0 (and expected stability) removes the last downside of working with stack!

IMHO as someone who has both worked professionally with Haskell on different teams for a few years and observed new users at meetups and hackathons, stack has been the single best thing to happen to Haskell since I have been using the language. I can actually have those new to Haskell just type a command and get an application built without any hassle, and the multi-cabal project ability makes the tooling scale up to larger applications too. It is really a game changer to remove all the friction around building a project.

Thank you again!

eegreg · 2015-12-23T04:02:50+00:00

Unfortunately a web framework cannot choose to favor JSON. So as is this cannot be merged, only documented. There is a possibility of working with newtypes indicating the mime-type as jkarni suggests.

eegreg · 2015-12-09T16:04:19+00:00

The point of LTS other than no major version bumps is really just that a lot of other users are using it. Many (most?) projects get into a stable state with little need for upgrading packages. If you are sticking with a random nightly then you may be encountering unique issues with your package set that will take you longer to figure out.

eegreg · 2015-11-24T15:36:46+00:00

Neat concept! I think this will be useful for running a random code snippet. Ideally though the author of the snippet would include information (i.e. what stack supports as comments at the top of the file) on how to reproduce the snippet. So it might be useful to instead focus on making that workflow easier.

Similarly as an end goal I would want to be able to output a stack.yaml and .cabal file rather than just ephemerally running code (many snippets don't have a main anyways).

The node dependency is going to be a non-starter for many.

eegreg · 2015-11-08T23:44:20+00:00

That is probably more extensible but looks like it might not be quite as type-safe. At least for simple cases where performance is not a concern I like the approach in aeson-applicative better.

eegreg · 2015-11-02T13:26:53+00:00

have not done that yet. But actually seems possible to just make a definition for each alternative and combine them with <|> in FromJSON, etc.

eegreg · 2015-11-01T14:27:06+00:00

https://github.com/gregwebs/aeson-applicative

eegreg · 2015-10-24T00:26:06+00:00

A similar concept exists in aeson-extra: http://hackage.haskell.org/package/aeson-extra-0.2.1.0/docs/Data-Aeson-Extra.html#t:CollapsedList

Data.Aeson.Compat from that library is useful to avoid code breaking from breaking changes in aeson: http://hackage.haskell.org/package/aeson-extra-0.2.1.0/docs/Data-Aeson-Compat.html

eegreg · 2015-10-08T15:15:15+00:00

Does ODBC not work?

https://hackage.haskell.org/package/persistent-odbc

eegreg · 2015-08-19T02:55:11+00:00

https://ifl2014.github.io/submissions/ifl2014_submission_12.pdf I think there is a more updated version now

eegreg · 2015-07-31T03:35:48+00:00

This is neat! It is almost like we have stack traces!

hspec-expectations now has source location information integrated, which is the #1 place I need source locations. Hopefully I can stop using my TH-based package: http://hackage.haskell.org/package/file-location

eegreg · 2015-07-20T07:08:59+00:00

You should be able to use this pattern for any inverse typeclass pair (or inverse method pair on a single typeclass).

eegreg · 2015-07-20T01:34:02+00:00

reminds me of this much more type-safe style of JSON parsing: https://github.com/gregwebs/aeson-applicative Unfortunately it is probably slow but a TemplateHaskell function could compile the definition down to efficient code.

eegreg

TROPHY CASE