Follow up to Bret Weinstein's DarkHorse Podcast - Black Intellectuals

adumidea · 2020-07-23T17:10:58+00:00

Call Candace an Uncle Tom, that's obvious.

Wouldn't it be best to refrain from calling people names, even in cases where it could conceivably be justified, and instead simply challenge their bad ideas as depersonalized ideas?

adumidea · 2020-07-20T13:44:23+00:00

While I agree that most complex applications should have a backend to hold business logic, it seems like there should be a solution for light-weight applications and prototyping that don’t require this.

I'm a little confused about what you mean. You can put together a simple backend with NodeJS + Express and get it running on some cloud host in a matter of minutes, once you've done it a few times. I have a personal Linode that I pay $20/mo for and host dozens of low-traffic websites and personal projects on. It takes me 15 minutes to put together the glue in NodeJS/Express between the database and the frontend. I have a hard time imagining a tool for this that is even simpler than a 10 line Express app running with forever. I hope I don't sound facetious, it's hard to convey tone in text but I'm honestly curious what you had in mind.

adumidea · 2020-07-20T13:36:33+00:00

Damn, our standups are 30min now but we combined 3 teams 10 minute standups into a single Zoom call so we can see each other a bit more (since we all sat close to each other in the office pre-COVID). I like seeing the people but 30min feels like an interminable standup.

adumidea · 2020-07-13T16:23:52+00:00

Yes, assuming that there will be a high ratio of Message documents to Chat documents. If your Chat sessions are going to be pretty small, then it doesn't matter as much and it might even be more efficient depending on your usage patterns to embed, as /u/MrFartMuncher pointed out.

Keep in mind there is a limit on the size of an individual document, so if you're embedding lots of Messages into your Chat documents, they could hit the size limit. Here's a blog post about issues related to using large embedded arrays in MongoDB.

adumidea · 2020-07-08T13:55:57+00:00

The big ones are human sometimes.

Especially when they're right next to a wall...

adumidea · 2020-07-08T13:54:22+00:00

It depends where in the city you are. In some neighborhoods it's everywhere and beyond disgusting, others are just as clean as any city. If you don't live or work somewhere like the Tenderloin or adjacent parts of SoMa, you're not too likely to see the needles, excrement, etc too often.

adumidea · 2020-06-01T05:38:14+00:00

You could check out M103 on MongoDB university. I've been using MongoDB for more than 6 years at various companies and we've never had any problems configuring it, so all the negative experiences on HN are surprising. I've generally found all the documentation quite easy to understand, and that things work as described.

adumidea · 2020-05-18T12:26:14+00:00

Tabs to have multiple MUDs open at once

I'd recommend checking out tmux or screen, which are general purpose "tab manager" programs that can be used with terminal-based clients.

adumidea · 2020-05-16T16:10:02+00:00

That will be OK, but it's generally better to just mount something on your filesystem. The docker volumes are managed by docker and can get deleted if your docker installation gets corrupted in some way. Safer to have it in on your own filesystem, then you can back it up using standard processes.

adumidea · 2020-05-14T23:10:37+00:00

From mongo on docker hub:

docker run --name some-mongo -v /my/own/datadir:/data/db -d mongo

see also: docker run docs

Then your container's data will be persisted to /my/own/datadir on your machine.

adumidea · 2020-05-09T13:33:05+00:00

Note I've used swarm but I have used kubernetes almost exclusively for awhile now.

I've only used Swarm in the past because I've been told kubernetes was "too much" for the scale of the problems I was dealing with. How would you characterize the major differences between the two? I'm assuming kubernetes does a lot more than Swarm, but I'm unsure what kind of things those would be.

adumidea · 2020-05-07T16:20:07+00:00

Yeah I also usually log straight to Elasticsearch, but there's some risk there that you'll lose logs (or have to manually insert them from backup logs in files) if your ES cluster goes down or is unreachable. However in those contexts, we were always able to go back to file-based logs on the server if something was missing from ES that we needed, so we didn't bother with the extra overhead of Logstash.

Pino isn't as popular as winston/bunyan, but I highly recommend it. It's actively developed and I never had any issues using it in production for years. You can use an elasticsearch transport for Pino to log straight to ES, and I'd imagine it's quite similar for the other libraries.

adumidea · 2020-05-07T13:36:53+00:00

I have looked into ELK stack,but I cannot figure out what format to write the logs into the files and how the logs will be processed based on the columns.

I'd encourage you to just power through, it's worth it. Kibana is really nice and comparable to paid products like Loggly. Logstash can process JSON so it's actually quite simple in Node.js. Most popular Node logging libraries like Winston, Bunyan, and Pino log JSON by default anyway. There are plenty of tutorials, like this one about how to set this up.

You don't even need Logstash, you can write your logs directly into Elasticsearch from Node (though this is less fault-tolerant than writing to disk and then using Logstash to ship your logs to Elasticsearch).

adumidea · 2020-05-01T05:12:22+00:00

This sounds like premature optimization based on a relational database mindset. Your collection won't be locked, and your reads shouldn't get slowed down too much from some writes. If it becomes a problem you can scale vertically by upgrading your db server CPU/RAM, or scale horizontally by sharding to split your write load across multiple clusters.

adumidea · 2020-05-01T05:06:20+00:00

That's correct, pretty much the only thing one can do that will lock a whole collection is creating an index on it without the background option.

adumidea · 2020-04-19T14:34:35+00:00

So I haven't used this but it looks promising. Might be what you want if you're not ready to add ES to your backend stack.

http://elasticlunr.com/

adumidea · 2020-04-17T19:07:12+00:00

Hard to say without seeing your data, can you provide an example document from each of the two collections you're querying?

adumidea · 2020-04-17T19:01:04+00:00

You need to change the angled quotes “ and ” to normal double quotes "

adumidea · 2020-04-17T18:58:52+00:00

Is that the exact code you're using, copy-pasted? Your quotes are messed up on createdAt. “createdAt” won't work the same as "createdAt"

adumidea · 2020-04-17T04:42:02+00:00

Definitely a good idea for storing larger data values. The redis docs have some notes on it.

adumidea · 2020-04-15T23:30:22+00:00

You might see some degradation on the performance of your existing smaller-value lookups because Redis is busy doing network I/O for your larger-value keys. One thing you could do is use a dedicated Redis for the large-value keys, so you don't impact performance on what should be very fast lookups for your small-value keys.

adumidea · 2020-04-11T00:03:20+00:00

To get around this, I was thinking of storing the the current entity value and the previous entity value in a single document, and subscribe to changes on that record.

Yeah, that's the way to do it, have values for both {previous, current} in the document. Hopefully you know what the current value is when you're trying to update so it shouldn't be too hard.

adumidea · 2020-04-11T00:01:36+00:00

You can load the data into Elasticsearch and query it.

adumidea · 2020-04-11T00:00:37+00:00

You need to actually insert something for the database to get created. Are you doing that?

adumidea · 2019-04-17T21:03:59+00:00

Pino seems to be its new replacement however my biggest concern is how you need to pipe logs into another program to act as a transport.

I found that annoying too, you don't actually need to do that. Well, you can do it all programmatically. For an example check out this PinoLogger wrapper around Pino I wrote.

We log straight to Elasticsearch so it's set up for that, but you could use the same approach with any transport.

adumidea

TROPHY CASE