HN user

grumblestumble

606 karma

[ my public key: https://keybase.io/davidgee; my proof: https://keybase.io/davidgee/sigs/y0tA1m9d1h-D-rz4L29HQms1fHnFz31BC-eu1mhrnRM ]

Posts0
Comments188
View on HN
No posts found.

On the "not much else" note, it's worth pointing out that the kids these days are putting out some amazing work that lives up to the precedent set by BoC and Aphex. Skee Mask in particular is really great, and I think Four Tet's work is sometimes a little under-appreciated because he likes to make things very accessible and incorporate more commercial elements into his work. I really think his Sixteen Oceans album is a companion piece to Tomorrow's Harvest in disguise.

I'm generally perceived as a pretty funny guy, I joke around with both my reports and those I report to, and, yes, even with customers all the time. I've found that I don't need to diminish others to do this, there's plenty of other crap to joke about, like the quality of our products, how long it takes to get stuff done, the UX of the tools we share, dumb programming trends. It's easy to laugh without it being at the expense of others.

A lot of the conversation from the "no politics at work" crowd here is centered around "these folks were wasting company time and losing productivity protesting this". That entirely misses the point. The loss of productivity around this issue is entirely on the leadership team. They let this fester - they were complicit in allowing this dumb-ass list to be circulated around the company for years, and when it became an issue, they refused to take any action on it.

I was wondering how this would go down where I currently work, because people here rarely discuss politics at all. Then I realized that making fun of customer names - and we work with large enterprise customers across the globe - would be shut down in a personal conversation with anyone I work with, and circulating a list like this would just never happen. The way to keep politics out of work is to keep your work environment professional.

This wasn't employees pontificating on the merits of BLM or party politics in Basecamp channels, this was direct response to dumb shit the company was allowing certain people to get away with. DHH's blog post where he got into the details was still basically tittering at "lol Bigbuttson is a funny name", and it's deplorable.

There's a whole ecosystem around using React for static site development now, this is exactly what Gatsby is if I'm not mistaken. Use React as a more powerful templating system for authoring content, but generate most of it out as static HTML/CSS, while still having the capability for individual components to have interactivity / data fetching post load.

Also, I think this is what's going on with NextJS and React's server-side-components stuff. Having solved client-side webapps, the world has now turned to reinventing Cold Fusion...

Welcome to capitalism... If what you're building is solving a valuable problem, and you don't build it fast enough, someone else will build it quicker and shittier but still solve the problem. You're getting shit slow apps because you use them when they're delivered to you.

I think the team behind this is somewhat trivializing this change by saying that a UI table library "has no business being in charge of your UI". Is the expectation is that the following are all bespoke, easy-to-implement features that application teams should rewrite from scratch and maintain internally, and should not be considered when looking at a library to deal with rendering tabular data in an application?

* Support for virtualized rows/columns * Support for fixed headers * Support for frozen columns * Support for resizable columns * Support for re-ordering columns * Dealing with page / container resizing. * Support for context menus in the context of all of the above * Support for master/detail views * Support for tree data

My take is that the inverse is true. Structure/Pagination/sorting/filtering of data sets is pretty trivial and in most cases the out-of-the-box functionality that libs provide for these is insufficient and ends up being overwritten anyway. The above list is exactly what I'm looking to outsource when looking at a grid library.

Laptop displays are unfortunately limited to the "good enough" solution of additive light. We're stuck with it because it works well enough, so it's not important to sink tons of money and research in bringing e-ink style displays up to par. As a result, "light mode" means bombarding your eyes with... light. This is not good. Dark pixels are pixels that emit less light. This is much better for your eyes.

If you're on OSX and not using the "default for display" resolution, that may be the cause of the issue. Don't have the bugzilla handy, but I stumbled across it at one point and confirmed that that was the culprit for me. Unfortunately, I'm unwilling to use default display res, so I'm hoping that gets fixed soon. Would love to standardize on Firefox for my every day browsing.

I actually experienced this with a rental car in South Africa. I drove for 10+ seconds with the engine revving at full blast with the car in neutral and no mat impacting the pedal. Both feet completely removed from any pedal, using the handbrake to decelerate and pull onto the verge. The floor mat thing is total deflection by Toyota. The only thing that reset the accelerator was turning the ignition off.

We use Verdaccio and I can't imagine any serious dev shop not using some kind of proxy / private registry for NPM packages. It's really simple to set up and has served us well, aside from minor hiccups.

Chiming in here. I would absolutely love to switch to Firefox for a host of reasons, ranging from "I don't want to use Google products" to "I love the tabs". Unfortunately, it's completely unusable for my workflow on a 2015 Macbook Pro with 16G RAM. I keep a variety of tabs pinned (JIRA, Zeplin, Gitlab, Jenkins, Invision, etc) and it seems as if they continue to hog a disproportionate amount of resources even when in the background, which is not an issue on Chrome.

Actually, this is incorrect. You're abusing map here. The purpose of map is to map an existing array onto a new array. You're using map here to mutate properties on nodes in the original array, and creating a new Array, which has the length of the initial array, where each value is the return value of `node.style.background = 'yellow';`

forEach is much more indicative of what you're actually doing here, which is running through an iterable and mutating properties on each node.

Simple rule of thumb: if you're not using the results of `map`, you shouldn't be using it.

I think it really boils down to a perception issue. I think more people would be happy paying a flat fee for a language package then deal with the angst of "wasted" money paying for languages that some users don't leverage. The package as it currently stands would "work" if I could assign languages to users and have that reflect back up to pricing, but that's cumbersome to manage from a customer perspective and sounds pretty painful to implement from the provider perspective.

It may be useful to consider a baseline two-language deal, as Javascript + one server side language covers a huge amount of use cases.

That said, you cover 2 out of 3 of the following scenarios pretty well with the existing model, I just happen to fall into the third, which is probably the smallest sector for you guys anyway:

1 - Small startups, probably standardized on one or two languages, 8-10 people 2 - Larger orgs (200+) where the cost is negligible compared to revenue. 3 - Medium-sized, microservice/squad based orgs, with heterogenous language support but focused within teams.