coxley

8 ms·

31.
by coxley 3y ago
+1 This puts the focus on writing content vs. spending unlimited time in the setup.
32.
by coxley 3y ago
Caveat: I had a _very_ brief stint there. My take was that — like many companies — it takes more people than you expect to untangle a Python 2.7 monolith. They also seemed to move somewhat slow and steady by design.
33.
by coxley 3y ago
Custom collection daemon or other type of agent.
34.
by coxley 3y ago
Subject aside, this is a very pleasant website design. Love the simplicity and subtle animations/transitions.
35.
by coxley 3y ago
Yeah, they're fundamentally solving different problems. I was confused to see it benchmarking against them in the first place. The number of items isn't the best metric alone, making it harder to demonstrate in a benchmark. I&#x27
36.
by coxley 3y ago
Oh whoops, sorry I forgot to check!
37.
DaedalOS – Desktop environment in the browser(dustinbrett.com)
387 points by coxley 3y ago|133 comments
38.
by coxley 3y ago
I’m super impressed by how smooth it is on mobile. Winamp is a nice touch. Creator says it took three years on the side to build: https://www.reddit.com/r/react/s/JZRRdq1Qv3
39.
by coxley 3y ago
Sorry if I missed it, but does Otter do anything special to limit GC-impact when caching lots of references? That's the main selling point for bigcache and freecache.
40.
by coxley 3y ago
Not exactly a project, but I was very active in IRC between 2009-2017. I stuck mostly to Linux and network engineering channels. I contributed to open source projects, answered questions, and asked plenty of my own. One day I helped someone
41.
by coxley 3y ago
Right? There are gold nuggets in many of this style of "manifesto". It just takes a handful of people treating it as dogma to stink them up.
42.
by coxley 3y ago
Agreed. Some things they suggest aren't actually possible with their SDKs. For example, you cannot define a histogram's buckets near where you define the histogram. You have to give the global exporter (or w/e the type is) a
43.
by coxley 3y ago
> # Developers > Sorry, there are no developers to subscribe to currently. If you actually want adoption, more needs done than posting the thing you built and suggesting people use it. Building effective, self-sufficient marketplaces
44.
by coxley 3y ago
No one can hide from strace!
45.
by coxley 3y ago
The iteration loop is MUCH faster using tools like Figma for design. Most places use consistent patterns for padding, space, etc. But a lot of things need adjusted visually for polish. Tweaking things in devtools is fine for quick things, b
46.
by coxley 3y ago
Whoa, this is very nice! I'm going to buy when I kickstart some upcoming web work. The price won't be for everyone — but you don't need everyone. :)
47.
by coxley 3y ago
YAML hell. It's very difficult to have standard, company (or org) wide "templates" for creating resources. And I don't mean literal templates. In my ideal world, everything would be defined within Starlark. And we could
48.
by coxley 3y ago
"Make each program do one thing well" The philosophy surrounding these tools wouldn't lend well to each implementing that. Fortunately `pv` exists, is perfect for this use-case, and included in many distributions. :)
49.
by coxley 3y ago
Yes, it's neat. But you can play with the tool(s) without it being the only topic you consume day-in, day-out. Missing HN submissions about it won't leave me/you/anyone a barbarian. :)
50.
by coxley 4y ago
I mean, OCI and containerd exist. You can have "Docker" containers without the Docker just fine. Just need to replace the user tooling, which I assume podman does? (never used it)
51.
by coxley 4y ago
> And apparently even Facebook has abandoned react for anything but internal projects I... what? Do you have a source or speculating to create fear of future support? I'm nearly certain this is untrue.
52.
by coxley 4y ago
Haha, damn dude. Did your step-dad use vim?
53.
by coxley 4y ago
> How would one go about building a rest [service.] At Meta, you wouldn't. Everything is Thrift. For WWW, you'll have more graphql. Meta also has a shit ton of libs to make service development easier than exists publicly.
54.
by coxley 4y ago
Go is the go-to for many teams, especially CLIs. Unfortunately there are strong opinions held by high influence on Rust vs. Go instead of Rust + Go. To the point of finger pointing any chance they could with "see??" Many have left
55.
by coxley 4y ago
I... What? It's not Facebook. Even the examples of the post include non-Meta. It's not "some work". It's how we conceptualize time moving linearly, and that logic encoded on software. People just want a reason to di
56.
by coxley 4y ago
Mercurial solves a lot of the UX problems. Maybe if Meta open-sources the API-compliant rust rewrite, we'll have the scaling sorted too. Commits are automatically "branches" off trunk. You typically do 1:1, commit:PR. As you
57.
by coxley 4y ago
Two recommendations: * On Writing Well * Google's free, self-guided technical writing courses Using these, you should get much better at refining your writing. Write naturally, then go back and edit when rereading according to the your
58.
by coxley 4y ago
This isn't alarming. We freeze IC3/4 hiring almost yearly when there's a large number of offers extended to interns. Meta has issues, but this feels like sensationalism.
59.
by coxley 4y ago
+1. Used Go, Python, React, etc extensively for years at Facebook. The massive Go projects were easiest to extend, operate, and on-board people to. Rust vs Go discussions are pretty silly. More folks should think of Rust + Go. There are a l
60.
by coxley 5y ago
This article also underestimates how quickly you can move with the resources of a large company. DB management and scaling? Another team takes care of that and offers an easy to use service. Large pool of server resources to experiment with

More ›