Stemma | Full-stack and Front-end engineers | Fully distributed (US and EU time zones) | Full-time | https://stemma.ai

Stemma is used by companies like Flexport, iRobot, Tempo, and many others, including public financial services organizations to help with discovering, understanding and trusting their data.

Data storage has been decentralized by cloud data warehouses like Snowflake or Redshift. Consumption by Looker or Tableau. Transformation by dbt and Airflow.

Organizations finally have the technical primitives they need to decentralize data consumption and transformation. But they run into a new brick wall: decentralizing understanding of what the data represents and how it actually maps to the real world.

Stemma helps solve that problem. We have strong initial traction but are still early stage: we're looking for curious engineers who are excited to rapidly iterate on new ideas with customers and build a product from the ground up. Every member of the Stemma team has the opportunity to meaningfully contribute to the direction of the product, business and the engineering culture.

We're funded by Sequoia. We're currently 12 people but are growing quickly.

I read every application sent to https://jobs.ashbyhq.com/stemma

Great question; I'm an engineer at Heap. This data model fit our needs at the time, however, you're absolutely right that these user rows do become quite cumbersome as they grow large.

> Well... generally this is solved via indices. An event log indexed by user ID would have the same effect. You get all the user info, and if you really need to grab historical or event data, it's there when necessary for parts of the app that actually need it.

Indeed! We're investigating a more traditional schema, as the topics of our more recent blog posts might suggest (http://blog.heapanalytics.com/speeding-up-postgresql-queries...).

While that's certainly true, the distribution of asteroids by size [1] suggests that increasing size by that much decreases the probability proportionally?

[1] http://www.aanda.org/articles/aa/full/2007/18/aa6046-06/img2...

Home prices are rising rapidly, but rent--even in central areas--is still quite reasonable for tenants.

Sure, why not.

Dry cast iron skillet, put in oven, heat to 500*F. Prep steak with olive oil and salt and pepper.

Take skillet out of oven, put on stove at high. Cook 30 seconds on each side. (total cook time on range: 1 minute)

Back in oven, 2 minutes each side. (total cook time in oven : 4 minutes)

Let rest 3 minutes.

There is only one important step missing from this. Let the steak sit out to become room temp. Try it just once and you will never look back.

careful - don't over heat the skillet. 500 is past olive oil's smoking point (especially the olive oil you are likely to have at home). Canola oil's smoking point is higher.

that being said, cast iron skillet is the way to go and is quite easy. just don't fill your place with smoke.

I would say +1 to this, but also add butter & onions :)

What kind of FPGA package were you previously using?

Many FPGA CPU simulators attempt to be cycle-accurate for the purpose of architecture development, where the emulator has the leeway of treating instructions as atomic units and abstracting the rest.

Would have to ask my colleague about the details, but yes it is cycle-accurate. It is running 50 or 80 MHz, so it is expected to run slower.

Even more interesting ethically considering a large portion of Mozilla's revenue comes from Google.

I was thinking the opposite. I'm glad he's charging for upgrades, and charging a decent price for something some developers use all day everyday. I hope this will enable him to continue developing ST.

I'm growing fairly dependent on plugins, though -- I hope the new API isn't too hard for plugin devs to upgrade. Although with most plugins hosted on Github these days, compat is just a pull request away.

So you don't think a ~640% pricing increase rather large? I'm not saying the software isn't worth $70. But relative to it's previous price, I think it's a pretty significant increase.

Edit: My mistake - I just can't read. It was an $11 increase in price.

It's increased BY 11$, not FROM 11$. Certainly not 640%.

it went from 59$ to 70$

In the example URL you gave, the content of the URL (base64): ({:project-id "505a125e44ae42e05a750c97", :object-instance "2", :object-type "0", :device-id "1234"} {:project-id "505a125e44ae42e05a750c97", :object-instance "1", :object-type "0", :device-id "1234"} {:project-id "505a125e44ae42e05a750c97", :object-instance "0", :object-type "0", :device-id "1234"})

seems like it would be better stored on the server in redis or something (or, at least if leaving it in the URL, a more compact deduplicated format might be worthwhile)

Yeah I'm still wondering if I should gzip to whole thing (I'm already base64 encoding anyway).

However the duplication overhead would only be really paying off with a large number of objects.

By the redis reference, I suppose you refer to a uniquely created key each time a user request a possible combination. Something like /short-url/abcd, where abcd would be a key matching {:project-id "505a125e44ae42e05a750c97"... ?

That's what I was thinking when talking about a shortening url scheme. It requires more work, but the final URL would indeed be more sexy.

Thank you for the input, I appreciate it!

Part of me wonders what would happen if someone where to Base64 encode something like

  ({:project-id {:conditions "true); DELETE FROM projects WHERE (true"}})

Nothing, it's not sql. It's a clojure map with all the necessary info to find the different components.

But nice reflex! ;-)

The unlabeled referral link here at the end praising his host bothers me a bit -- shouting praises for a good service is fine, but at least note that you are getting a kick back.

> Because I know I will get an angry email or two, just let me say this. I know that Cloudflare touts other features such as security, load balancing, and keeping your site up if your server is offline. I did not test or take any of these features into account. Their biggest sector is to people that want to speed their website up, so I took them to the task on just that claim.

If this is true and people really think that CDN = faster site, then it's a misunderstanding, perhaps perpetuated by malicious marketing by the CDNs themselves.

But putting a proxy in front of an unloaded site (hosted on a relatively fast server) is of course unnecessary.

Re-run the test using `ab2' instead of simple 3-hit tests, and that's when the CDN becomes more useful. Or perhaps host the site on an oversold bargain shared server and see how it fares.