Marker is a new technology joint venture from 3 leading communications agencies. We’re an incubator building and launching force-multiplying software products for our clients and teams.
Our first product is Delve (https://delve.news) — a coverage monitoring, analysis, and insight toolkit to track and measure the entire online conversation about your business or industry.
Our product team is small and autonomous, but with the resources, expertise, and customer access of the global agencies we work with. We’re hiring an early engineer to join us on this journey; you’ll have a large impact on what we build, how we build it, and where we’re going next.
Our current technology stack includes Deno, React, and PostgreSQL. Bonus points for expertise in one or more of: distributed systems, RAG, web scraping, data visualization.
Contact: dylan (at) company domain. No recruiters or agencies, please.
This change happened right about August 15, 2017... which I know only because somehow I happened to notice at the right moment where the branding had been updated but the page <title> had not. Here's the bug report I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
For what it’s worth - we had to audit/list all licenses for OSS components & dependencies on at least 3 separate occasions during fundraising diligence processes. I would guess nobody read it too closely but GPL code would definitely have stuck out. I imagine bigger companies have this process pretty well structured.
Oh... um... I mean look, it's a bit controversial.
They document family trees, and then post-humorously baptize the dead so everyone's kin can get to heaven.
They mean well, and it's coming from a good place, but it's a little weird and it can be off-putting to know that they don't think any other religion's baptisms count so they have to do it over the LDS way. But look, they mean well.
But basically instead of just "Oh, we're just saying some prayers for your dead granny..." -- which I think everyone would be fine with, it's the Mormons saying, "Oh, we're saying some prayers for your dead granny... because without true Mormon salvation she'd be burning in hell forever."
The Mormons also have "stand-ins" that they baptize in place of the person. Usually kids. So a kid goes up and says, "I'm so-and-so, grandmother of such-and-such..." and then they get dunked in a tub. And it also serves to further indoctrinate the kids... who are re-baptized a bunch of times.
My view... all religions are nutty. Not sure where we draw a line on any of them. But I don't really care what people do in the privacy of their own temple, or what internet archives they want to spend their time transcribing. If it lets them sleep a bit better knowing my dead great grandmother is with her family in Heaven... that's great. Or at least, it's no going to hurt her any. (=
First, Latter-Day Saints believe that one needs to be baptized in order to enter into heaven (based on the teachings of Jesus Christ recorded in John 3:16). For this to come about for those who never had the opportunity to be baptized (let alone the countless individuals who never even heard of Jesus Christ while alive), they perform proxy baptisms on behalf of dead individuals. Obviously they don't baptize corpses; instead, they have a member of their faith baptized again, on behalf of an individual who has passed away.
To find out who of their family tree needs to be baptized, Latter-Day Saints perform tons of genealogical work, which includes indexing handwritten censuses into digital form. Hence the census sheets.
I spent the first couple years of my life in a small town in Ireland. Small enough that the houses had names, not numbers — my parents were Tolkien fans, and ours became "Lorien".
I'm told that letters were addressed simply, "Lorien, [town name]"
I’d often send postcards to “Grandma, 14130 [Village name]”. Based on my signature, the mailman would know which grandma to distribute it too. That’s what belonging to a land is like. Our kids probably won’t be able to say which country we are from.
I've seen a similar mistake in a rushed "feature flagging"/phased rollout system.
User IDs were random UUIDs. Let's say we want to release a feature to ~33% of users; we take the first 2 characters of the UUID, giving us 256 possible buckets, then say that everyone in the first 1/3 of that range gets the feature. So, 00XXX...-55XXX... IDs get it, and 56-FF do not. This works fine.
However, if we then release another feature to 10% of users - everyone from 00-1A gets it, 1B-FF do not. That first set now has both features, and 56-FF have none. It turns out you can't draw meaningful conclusions when some users get every new feature and some get none at all.
One easy way to avoid this problem is to give each feature its own independent space of “dice rolls” by hashing the user ids with feature-specific constants before interpreting them as dice rolls:
If you suspect some flag effects interact with each other (e.g. one flag increases button size by 10%, and the other decreases it by 10%) you can go one step further and define feature groups and hash by user-id + group-id and then assign non overlapping ranges to the flags.
Or you can cut and redistribute the non-performing changes, increase the distribution of the well-performing ones, and let evolution take care of disentangle correlated behavior.
But if need that kind of analysis for usability A/B testing, you most be doing something very wrong on a previous step.
Consistent hashing (or more generally weighted rendezvous hashing) provides pseudorandom allocations with minimal reallocations when parameters change. This is exactly the properties desired for rolling out feature flags gradually over an input space like user IDs. It is a special case of a consistent hash function, where the possible assignments are just two (weighted) buckets, corresponding to the feature flag's value of true/false.
A better way is to assign some internal salt to the feature at creation time and use that, that way you are not dependent on something external that user (the creator of the feature flag) could change.
I bear the scars of this design mistake from when I worked for a company that provided feature flagging.
It was not my initial mistake, but I drew the short straw trying to work around it.
Is there a more general term for tuple hashing? IE, math and theory around composition of hashes composed of concatenated (or otherwise combined) typed values?
> That first set now has both features, and 56-FF have none. It turns out you can't draw meaningful conclusions when some users get every new feature and some get none at all.
00—1A: have feature flags A and B
1B-55: have feature flag A only
56-FF: have no feature flag
So the actual gotcha here is that there is no cohort for "feature flag B only", right?
This setup can actually be desirable if feature B depends on feature A.
> So the actual gotcha here is that there is no cohort for "feature flag B only", right?
And that, as you add more tests, user 00 will always get the test treatment for every test. If you're running a lot of tests which introduce experimental features or changes to workflows, user 00 is probably going to find the site a lot more chaotic and hard to understand than user FF, and that will skew your test results.
> So the actual gotcha here is that there is no cohort for "feature flag B only", right?
Yep, exactly - by "that first set" I meant the 00-1A group, could have been clearer. Whatever the smallest rollout bucket is, that group is guaranteed to have every single feature.
This was quite a while ago, but I think the actual case we noticed this with was several features released to 50% of the userbase - so every single user either had all or none at once (unintentionally)
I'm pretty agnostic on cold emails as a strategy, but this article doesn't mention the specific sourcing method used here which I found a bit distasteful (but common) — scraping the HN "Who's hiring" thread:
Hey Dylan!
I'm Luke Hager with Molecule.dev, and I'm emailing you because I saw your post on HN. I've been looking around for companies like CALA who might be able to make good use of Molecule.dev. I see that you're using TypeScript, React, PostgreSQL, Node and other modern web/mobile tech.
At the very least this goes against the guidance in the monthly thread ("Readers: please only email if you are personally interested in the job")
I was (and still am) genuinely looking for work and to help companies build their products. My thought process was that if they're looking to hire an engineer, they're looking for someone to build their app, and I was offering a way to do that for them, faster.
CALA is the best way to design and produce fashion products. We're building web + mobile tools that turn dreams into reality. Our customers are some of the world's most creative designers — ranging from indie brands to major celebrities.
We're still a fairly small team (~30 people, ~8 on eng/product), so you'll have a huge impact on what we build and how we build it, and be a key part of the next phase of our growth. We place a very high value on design and product quality, and we're looking for product designers and full-stack engineers (TypeScript, node.js, React, Postgres) to continue this practice.
Please check out info on our open positions at https://jobs.wrk.xyz/cala . I'm the hiring manager for our open product/engineering roles, so feel free to email me directly with any questions: dylan@ca.la
CALA is the best way to design and produce fashion products. We're building web + mobile tools that turn dreams into reality. Our customers are some of the world's most creative designers — ranging from indie brands to major celebrities.
We're still a small team (~30 people, ~8 on eng/product) but growing quickly, and looking for experienced designers and engineers with a passion for building great products. You'll have a huge impact on what we build and how we build it, and be a key part of the next phase of our growth. We're currently hiring a product designer and a full-stack engineer (TypeScript, node.js, React, Postgres).
Please check out open positions and apply at https://jobs.wrk.xyz/cala . If you have any questions, just shoot me an email: dylan at ca.la.
Marker is a new technology joint venture from 3 leading communications agencies. We’re an incubator building and launching force-multiplying software products for our clients and teams.
Our first product is Delve (https://delve.news) — a coverage monitoring, analysis, and insight toolkit to track and measure the entire online conversation about your business or industry.
Our product team is small and autonomous, but with the resources, expertise, and customer access of the global agencies we work with. We’re hiring an early engineer to join us on this journey; you’ll have a large impact on what we build, how we build it, and where we’re going next.
Our current technology stack includes Deno, React, and PostgreSQL. Bonus points for expertise in one or more of: distributed systems, RAG, web scraping, data visualization.
Contact: dylan (at) company domain. No recruiters or agencies, please.