tjholowaychuk

I'm fine :) just taking a much needed break from software

Compared to Elastic's Cloud offering Apex Logs would be roughly half the cost. I forgot to mention in the post that it's 100% serverless, so there's nothing to maintain and no need to resize clusters as you grow.

Kibana definitely has the edge right now when it comes to charting, but I would say if you're just looking for a simple and clean logging solution Apex Logs would be a nicer experience. If you try it out definitely let me know if you have any feedback!

How so? It's just a basic marketing site, nothing newsworthy at all

I installed Hey to check it out and it’s useless from the app itself, it’s not too surprising they don’t want bad UX.

yeah absolutely nothing new here

They've been doing this for ages, it's nothing new haha

I'm good, I like to actually have data when a customer reports an issue... or you know, figure out why a system fails haha.

Also, Sentry is logging, it just groups by a fingerprint.

I suppose it depends, but throwing out node and migrating everything to Go was one of the better choices we made at Segment, before the platform grew too large.

Personally I think css utils are better suited for layout related stuff, acting more like layout primitives (hbox, vbox) etc since those tend to be pretty ad-hoc.

As far as concrete UI components go, I'm not sure this technique is any better, especially since you often need pretty ad-hoc styling with pseudos etc.

I think if CSS had built-in mixin support you could have the best of both worlds pretty easily, still crossing my fingers we get that some day, would be nice to drop all these build systems.

Or just don’t be a huge noob and create a real business, without privileged funding.

Facebook pays for this kind of stuff? Why not spend the time incorporating a decent language instead of trying to fix the fragmented hot mess that is js

There's inherent value in supporting something with money though, it's likely to actually stick around and improve, rather than some hacky OSS project that will die in a few months.

Yeah $250 is nothing if you're building a real product, fuck these cheap developers.

Great job, this looks awesome! I wish something polished like this was around when I started my stuff. I'm not sure how I feel about Tailwind being almost 1mb of CSS :D, but it's probably worth all the time you save, especially for apps the size isn't such a big deal.

Haven't used many AWS services have you? :D hahah

These days I think most people deploy static sites to a CDN, they get you such great performance I can't imagine not using a CDN, my site loads in 10ms in London for example.

You can definitely do that, but I find this appealing for development, just write some routes as you normally would and the templates all re-render etc, no need for watching file changes and re-compiling. But you're right, if you have a 404 template for example you have to `curl ... > build/404.html` which is a bit lame.

Yeah it doesn't work if you're relying on JS for interactions and layout, but wget's crawling technique works great if you're happy with using server-side rendering for content.

Just go to the VCs, they're pretty dumb, they'll throw millions at just about anything with a lot of GitHub stars these days.

GitHub stars will pay your rent if you sell out the hype to a VC instead of building a real company. I can definitely name a few startups that have almost no product, certainly not technically challenging or particularly well built ones, but they've made many millions in VC funding solely from GH star hype.This industry is a bit of a joke that way, but it works.

Which can be solved with a snippet bound to `e`.

I'd rather have nice command output, that could use a lot more love than this try() stuff, and maybe ditching the weird go.mod format it doesn't really add value—if anything it hurts because you can't manipulate those files with regular codecs.

When it comes to error context it would be nice to facilitate structured logging, rather than arbitrarily formatted strings.

Anyone know if this is what CloudWatch Insights uses? If so, it doesn't even come close to competing with Elasticsearch performance (with a tiny cluster), it seemed quite slow.

Dozens of emails / notifications, people pinging / bothering you on multiple platforms, multiple emails, etc.

It's stupid to blindly trust someone's code, regardless of who they are of if they are the current maintainer, that is not how you build secure software.

If you want to start some organization which vets people for maintainers go for it, but don't expect maintainers to do it, I can guarantee you that thousands of maintainers do not. You're responsible for what ends up on your servers.

Ah sometimes you get people asking to use a name such as my "log" pkg in npm, but bumping from 2.0 to 3.0 so that dependencies aren't messed up. Assuming the person has no bad intentions I think it's a perfectly reasonable request.

I ignored this particular request via email a few times, because I just really don't want to spend time dealing with Node stuff. You then get a request from NPM support asking the same thing, so I agreed to it, that's all it takes to get access to a package really.

I think from now on I'm just going to tell people to come up with a different name, this wouldn't be a problem if the names were scoped by default.

Easy for people who have zero packages and no pressure to say. Don't contribute to OSS and you have no problems.

If these huge companies profiting off OSS work actually contributed financially and with time, maybe maintainers would happily remain maintaining.

Not to blame them NPM, they're great people, but I often get requests from random people going through NPM support to use an existing name (saying they will bump major).

The centralized naming scheme is to blame here, it normalizes these "cute" names and users have demanded these since day one. They could/should have probably been scoped from the beginning, or people should just stop trying to capture fancy names.

I get tired of receiving emails about those kinds of things personally, you try to just ignore them, sometimes their request sounds reasonable but still, can those people be trusted, who knows.

Semver seems like a huge problem here, blindly pulling in changes is just asking for a lot trouble, intentional or not.

I'd also say NPM's centralized naming structure is also problematic, people don't want to update 1000's of modules to some new latest version of X which was forked and is now maintained, so it's handed off like this.

It has improved in some ways but it's still incredibly fragmented, maybe more so with CSS-in-JS, TS, Flow, etc. Especially with the potential of languages like Elm, Rust, Go and others via WASM, it's going to be very hard to justify JS IMO—unless you understand the tradeoffs and still just prefer JS as a language then that's cool, the others aren't perfect either.

Do you guys find CloudWatch logs too slow? Even on very small apps I find searching the past few days takes minutes (5-10m), but I'm using "structured" JSON logs as well.