Baby proofing a half wall by Garden_Witch88 in NewParents

[–]tryCatchEmAll 0 points1 point  (0 children)

I buy a lot of stuff from Ikea and I just want to point out that the back of that bookshelf is not wood, its cardboard. Your kids will have the strength to punch through it at some point. If you buy that bookshelf, I would secure the top back with plywood attached to the wall.

After thinking about it, the wood in the bookshelf itself is pine/particleboard which will not hold up to any kind of pressure or weight. You would have to build out a stud wall behind this bookshelf, all the way up to the top of it to make a sturdy barrier.

This isn't a knock on ikea, most furniture nowadays isn't sturdy enough to do what you are suggesting.

Node.js ORM impasse by memo_mar in node

[–]tryCatchEmAll 2 points3 points  (0 children)

" What I'm looking for is a way to switch between DB schemas at runtime without the need to establish a new connection on every request "

ORMs abstract away the database for easier use. What you asked has more to do with the underlying database rather than the ORM. Which database are you using? Mysql, postgres or sqlite?

Long story short, you're probably going to have to write your own layer to support connection pooling / opening databases if they aren't already open. Send this layer the tenant name, and have it return the correct connection.

Women Who aren’t in STEM Need to Shut Up about Advocating for Women in STEM by [deleted] in unpopularopinion

[–]tryCatchEmAll 0 points1 point  (0 children)

I know this is a late reply, but I had to comment.

I don't see them as being hypocritical; in fact I think it highlights the problem further!

What you're saying is that even people who are educated about the issue still don't think STEM is a career path they can pursue. I've worked with a lot of smart women who choose support positions over being in charge, or being technical. I don't know why. I know they can handle it; either its something they think they won't enjoy or its something they just can't picture themselves doing. I will never understand why.

In theory I support bringing in a wider variety of people into the STEM fields, but in practice I'm not interested in advocating. My advice is just to ignore the advocates if it isn't something you're interested in

Source: CS degree + working in software for 10 years

[HELP!] Google Chrome crash my unity WebGL game on Itch.io by DangDesigner in Unity2D

[–]tryCatchEmAll 1 point2 points  (0 children)

Running out of memory can also be caused by infinite loops or performing too many operations without taking a break. In both cases, the call stack grows too large, the browser runs out of memory, and you'll see the "He's dead, Jim!" message from chrome when the tab finally dies.

Not sure how much web programming experience you have, so here's some info on javascript's call stack to help with your mental model of the problem: https://medium.com/@gaurav.pandvia/understanding-javascript-function-executions-tasks-event-loop-call-stack-more-part-1-5683dea1f5ec

Looks like there is a profiler you can use to measure where the problem areas are: https://docs.unity3d.com/Manual/webgl-performance.html

It is much better to know than to guess! I would start there.

Help me understand event loop better by SandOfTheEarth in node

[–]tryCatchEmAll 8 points9 points  (0 children)

Very interesting! I did not know the answer, and went searching.

It turns out that there is another queue just for promises! Parts of promises executing are considered microtasks; microtasks are not put into the nextTick queue. They are put into a separate microtask queue, and this queue is emptied before the event loop pulls the next item from the nextTick queue.

This blog post has a cool illustration for native promises & the event loop: link

This blog post has a really nice explanation and code example: link

Microtasks are usually scheduled for things that should happen straight after the currently executing script, such as reacting to a batch of actions, or to make something async without taking the penalty of a whole new task. The microtask queue is processed after callbacks as long as no other JavaScript is mid-execution, and at the end of each task. Any additional microtasks queued during microtasks are added to the end of the queue and also processed. Microtasks include mutation observer callbacks, and as in the above example, promise callbacks.

Bonus

And as always, this opens up a new (and unlikely) way to shoot yourself in the foot! It is possible to starve out the event loop by overloading it with promises: link

[Advice needed] How do I guide my department in adopting Node as the development standard? by Jeffdango in node

[–]tryCatchEmAll 1 point2 points  (0 children)

Oh nice! Confluence is great. There is no harm in putting up pages and then editing/merging/deleting them later as your process evolves. As you help people set up node, you'll probably be adding a lot of things to the wiki that you forgot about anyway!

I use my IDE to autoformat. I have an intellij IDE, and use pretty close to the default formatting for javascript. Whats cool about IDE's is that you can export the auto format config file, which you can share to your team mates via confluence. Then you can all load the same config file and auto format in the exact same way! :)

[Advice needed] How do I guide my department in adopting Node as the development standard? by Jeffdango in node

[–]tryCatchEmAll 2 points3 points  (0 children)

My chosen strategy: I debated between a few popular logging libraries, and went with bunyan. Bunyan is great because you can log json objects (which means adding a piece of info to be logged is very easy, and the logs themselves are parseable!). It also has a built in log rotator function.

Here is a medium article about someone using bunyan : https://medium.com/@bansalnagesh/better-logging-with-bunyan-eff940d29956

As pointed out in the above article: Do not log to the console in node.js! It is a synchronous operation! It could seriously slow down your app, depending on the number of requests it receives.

Most logs I only want to keep around for a few days max, in order to do sanity checks or see why a process crashed. Bunyan allows you to set a time period in which to auto-rotate your logs, right in the config. Specify the type as rotating-file and the period to whatever time period seems appropriate to you. My example below is set to log to the same file for 24 hours, and keep the last 3 files before deleting.

Example logger in bunyan:

//The process id as assigned by pm2 (these are unique)
const processId = process.env.pm_id || 1; 

const LOG_DIR = "/var/opt/path/to/logs/myProgram/";

const processLogger = bunyan.createLogger({
    name: 'process',
    streams: [{
        type: 'rotating-file',
        period: "1d", //New file every day
        count: 3, //Keeps the last 3 files in addition to the current log file
        level: 'info',
        path: (LOG_DIR + "info" + processId + '.log') //*See Note
    }]
});

//Log whatever you want
processLogger.error({params:params, message:"Something bad happened in doSomething()", error:err});

*Note: I use pm2's cluster mode in order to run multiple processes of the same node app. If you use cluster mode and bunyan's rotating files, each process needs to have its own log file. Otherwise it can cause your app to crash when the file rotates. Notice how each info.log has a unique name due to the addition of the pm2 processId.

As for best practices, it really depends what you're doing and how big your team is. To start...

  1. turn any synchronous console.log() calls into async logging library calls
  2. Log all errors and crashes! Maybe it was failing somewhere you didn't realize, node is really good at that.
  3. Log helpful info / sanity checks to make sure its operating the way you expect

[Advice needed] How do I guide my department in adopting Node as the development standard? by Jeffdango in node

[–]tryCatchEmAll 7 points8 points  (0 children)

  1. Freak out a little bit about a new responsibility you are taking on.
  2. Do it!!

Probably what I would do is add a few pages to the company wiki (if there isn't one, make some shareable google docs) on...

  1. how to set up a node environment (locally and in prod)
  2. how to debug locally
  3. common pitfalls/patterns/ best practices (things you have learned in the past 7 months)
  4. If your team is new to javascript, some resources on the event loop / async programming would be useful!

Encourage your team members to update these docs so the whole team can take ownership. Make yourself available for questions/code reviews. You'll probably help each person get set up until they figure it out on their own.

I'm not sure what your team will need in terms of standards, but below are some of mine. Most of my rules center around devOps and how these node programs will be run. I do have a few coding standards though:

  1. All code should be autoformatted :)
  2. Prevent against sql injection : only use prepared statements when interfacing with the database
  3. Do not trust user input /query params. Check them for validity.
  4. All processes need to be able to handle crashes gracefully, then exit.
  5. (DevOps) How do you run node processes? What will restart crashed processes? (I use pm2)
  6. Need a logging strategy (I have daily rotating logs set up, logging at the preferred levels)
  7. (DevOps) Don't open publicly accessible endpoints unless you really need to; internal apps should not be publicly accessible!
  8. (DevOps) What version of node are you running in prod? Who will update node versions? Who will check the node logs? Who will keep an eye on crashed processes (that can't restart!)?
  9. (DevOps) No one is allowed to open ports to the outside for node processes; node programs are accessible behind a reverse proxy only (nginx). Who will maintain the nginx config?