orta

I've been using clickhouse for the last year for in-house analytics and found it a really pleasant experience, thanks for all the progress you've made

It's a reference to the name Stanley, 'stan' is the signature at the end of letters being read in the song

Dev here: Keytrace lets you verify other accounts like Keybase does (e.g. public proofs of identity) but doesn't orient the connection on GPG. Instead uses an atproto/bluesky account as the central source of identity, and stores everything in atproto.

So you could think of it as a simpler, de-centralized version of the Keybase identity proof system.

I'm linking my keytrace.dev: did:plc:t732otzqvkch7zz5d37537ry

Interesting project! Added it to my list of TypeScript derived languages: https://github.com/orta/awesome-typescript-derived-languages

This is a cool idea, I really enjoyed crashing at other companies offices for short periods - glad to see a company systematising that

OP here, luckily in this case, it means a more supported and vertically integrated alternative. Which does have less features, but actually gets bugs fixed and keeps up to date with the platform - so it's a net win overall IMO

That was a fun read, nice work

With Claude Code at least, all of the chats you've had are stored in jsonl files on your computer in ~/.claude - I made a little TUI for exploring these in https://github.com/orta/claude-code-to-adium

Personally, I'm less sold on tracking prompts as being valuable both for production cases (imo if a human should read it, a human should have wrote/fully edited it applies to commits/PRs/docs etc) and for vibe cases where the prompts are more transitory

Thanks yeah, your post hit the nail on the head so well I got to delete maybe a third of my notes for this!

This is an excellent insight

tsc's code is mostly the type-checker, you want to look for a "transpiler" here, so embedding either swc, esbuild, sucrase or the like to handle the process of converting for you. I've never heard of one written in C++ but that may exist.

There was some interesting work on standardising on "ESX" in the TC39 discourse that folks in the thread may want to follow: https://es.discourse.group/t/proposal-esx-as-core-js-feature...

Core docs: https://gist.github.com/WebReflection/2d64f34cf58daa812ec876...

Congrats on a great write-up. Sometimes trying to ship something at that sorta scale turns out to just not really make sense in a way that is hard to see at the beginning.

Another personal win is that you got a very thorough understanding of the people involved and how the outreach parts of the RFC process works. I've also had a few fail, but I've also had a few pass! Always easier to do the next time

The syntax is written like a bash shell variable, the idea (I assume) is that the actual job itself doesn't matter but the idea of it being something they do for work does (because contextually it means they have less decision power.) So, if it were me, saying I work for Puzzmo is about as useful as me saying I work for $DAYJOB in a sentence like that.

Good luck

Flutter web publicly launched with a NYT prototype https://verygood.ventures/success-stories/new-york-times

Puzzmo | Front-End | NYC | Full-time hybrid

puzzmo.com is a re-imagining of daily games websites which uses brings modern live-service systems to newspaper style puzzles.

We're a small 4 person dev team, looking to for a senior engineer with a focus on the front-end and happy to learn how to do some API work to get their ideas shipped. Not a games dev position.

- Tech: TypeScript (I used to work on it!) / React / Vite / Expo

- Us: https://www.theverge.com/23929222/puzzmo-newspaper-games-cro... and https://www.puzzmo.com/press

- Apply: We've closed out applications

I've done it pretty successfully ( https://artsy.github.io/blog/2019/04/29/how-did-artsy-become... ) and now regularly look back at prior source code and blogs as I work on something else but with similar patterns

I would say that getting to a point where this sort of thing is possible requires a huge amount of out-of-bounds culture and technical work though. Probably outside of the commitment range of folks who just want to work as an employee and not think about work outside of your paid hours

Cool! I think I'd be classed as deep Aphant like Loren (one of the paper's authors) but I also have an internal monologue.

I built Puzzmo.com on RedwoodJS, and have been working in Redwood everyday now for about 2.5 years. It's got a solid set of principles and it's gonna be cool to see where they take it with this simpler model for building sites.

( FWIW, they are right, Bun the _runtime_ can use the npm module Vite. https://github.com/oven-sh/bun/issues/250#issuecomment-16463... )

Good luck!

Perhaps it is LLM generated, as git says it is ~3 months old - but it links to a page on the TypeScript website which was removed a long time before that, https://www.typescriptlang.org/dt/search

You probably want MIT

I did a bit of a writeup on the gaps in soundness for TypeScript in the docs, https://www.typescriptlang.org/play?strictFunctionTypes=fals...

Here's hoping https://tc39.es/proposal-type-annotations/ solves this

Yep, it's just a repo of inter-linked markdown docs which you can view or edit on GitHub (or clone if you want to do some more involved editing.) You can definitely think of it as a wiki though as all engineers in the company would have write access.

I was working at Artsy while the OP was CTO (:wave:) and tried to help out a bunch on fostering a good attitude towards OSS - there's quite a few notes in both artsy/README and the blog

- (the making of artsy/README) https://artsy.github.io/blog/2018/08/21/OSS-by-Default-Docs/

- (OSSing our apps) https://artsy.github.io/blog/2019/04/29/how-did-artsy-become...

- (OPs writeup on the philosophy) https://code.dblock.org/2015/02/09/becoming-open-source-by-d...

- (the RFC process) https://artsy.github.io/blog/2019/04/11/on-an-rfcs-process/

Shame to see it happen, but an understandable decision - it's been a few years since I was writing native iOS code and AppCode really felt like a power-user tool in ways that Xcode couldn't.

AppCode team, you did such a great job IMO