They're pre-tax.

Not sure if you're talking about my comment from before, but I was talking about the employer costs (directly related to the salary) that they have to pay to the Government above what they pay the employer directly.

Im starting to learn vim, and damn stuff like % to check matching parenthesis just pumps me up.

That way leads to the dark side

Is there a sublime like text editor for windows?

Doh! Never mind...

Article about sleep linked in latest Hacker Newsletter

I imagine our profession is one that involves a lot of this delusion. Unless you guys get the right amount of sleep (I sometimes do, sometimes don't).

I frequently get less than seven hours of sleep (20% caused by work, 80% by young kid) and I can definitely feel it when I've gone 6 or less hours multiple nights in a row. Focus is worse. Feeling crappy. And so on.

That was my life until I found doxepin. 6 hours sleep max, sometimes less. And all the crappy feelings and stress levels that go along with it.

It's amazing how fast I feel it, and how steep the degradation can be. I envy those people who need 6 hours or less for full functioning.

Dumb question but lets say I'm allowing user generated links and need to turn them into anchors when they pass regex. Do I put rel="noopener noreferrer nofollow" on them? Anything else I need to do?

That seems good.

By regex, I assume you are checking the link yourself? Or are you using something like this: https://www.npmjs.com/package/valid-url

You probably are going to want to sanitize the **** out of them, to prevent XSS attacks (I mean, I guess that depends on what you do with the links. Anything user-generated that will be shown to someone else has to be prevented from executing JS)

React, unless you're dumb enough to use the incredibly named "dangerouslySetInnerHTML" method, will sanitize just on its own. I'm just going to split(' ') and see if each word starts with "https://mysitehere.io" and if so turn it into an anchor.

Sounds like this might be relevant? http://soapbox.github.io/linkifyjs/ (or this which I'm using as it was the first thing I found, but is specifically for React)

I've been thinking about implementing a backgammon game + server, just for fun and developing skills. I want an html5 frontend and probably a Go backend. I want it to look minimalistic and clean like lichess.

I'm trying to decide what tech stack I should use for the frontend. I think its possible to render the game client in css (e.g. https://codepen.io/AdventureBear/pen/wBNaBP) but I'm not sure how beneficial that is vs using the canvas or going further and using something like phaser.io. I'd love to fit react into this somehow. Any suggestions?

I'm also wondering whether the server should be a restful api, or websocket based. Probably the latter, but I've never done any socket servers, so maybe start with a simple poll every 5 seconds server.

This would be trivial with react + socketio (and node). Probably fine with Go too as I think it has a good socket implementation and you probably don't care about auth/dbs. If you go sockets don't poll just use emit/on pub/sub but its essentially faster http/rest without callbacks.

So we just finished the first part of an ongoing project. As part of that, I validated everything that got passed through in every api method. The goal was to try and catch invalid data, headers, etc before it was posted to the api. What that means is that every api wrapper method that i wrote needs to be wrapped in a try->catch. I feel it should be standard practice to try and catch invalid requests before they become invalid requests. I haven't had any luck in convincing the other people in my team (UI) to do the same. Am I asking them to do something that is unrealistic or does this seem like something they should be doing as well. To date, they pass w/e to the api and let it determine if a request is valid.

Bit of an overly general question, but typically requests should be validated on both ends. Passing a request to the server for validation produces lag which gives a poor user experience and makes your app or whatever look 10 years old.

Also, doing validation with try/catch blocks is generally bad practice, a bad request is not an erroneous program state and thus should not throw an exception (Edit: Of course it should return an error response, but that doesn't mean it should throw an exception internally on the server). You should have try/catches and exception handling but it's for when something happens that was unforeseen at the time the code was written. Bad requests are forseeable.

You don't really explain why it is bad practice actually.

Tell them to stop being lazy.

Client side verification is industry standard. It offers the frontend dev the chance to package the error in a nice way that is useful for the customer, guides them to a UI-specific solution, and is a lot more performant in the UX.

Server side verification is basically a firewall to protect your data from being corrupted from bad input. It's errors should be consumed by engineers/automatic processes to diagnose problems, not be part of the UX flow.

Its much slower (1000x+) than using control flow statements and makes your code less readable.

Its also generally considered a category error. An exception is exactly that, something exceptional and outside your control. However, the border between what is inside/outside your control can be blurry.

Metrics would be helpful. For instance show me an example where it actually makes your application/program execute 1000+ times slower.

Link to the objective standard for readable code would be helpful. Also be aware that code executing faster can be less readable in my opinion. In other words readable code and algorithm/program speed are not necessarily complementary.

Again this doesn't explain why it is bad practice.

I'll drop the whole thing if this is just an opinion that people hold or something like a Robert Martin has stated it is bad practice.

Im not writing a thesis here, so no I wont do all that work. This is just my opinion based on knowledge ive gathered throughout the years.

Sent from my Nexus 5 using Tapatalk

Of course it can, and it often is.

But in the case of exceptions, you get slower code that is less readable. A lose/lose.

This depends on the platform/language but either way, this isn't always possible since the library you're using may throw exceptions even in relatively predictable situations and the logic for detecting this condition is not possible to implement in the client code or otherwise duplicative. I think what you're saying applies more for exception handling where the error occurs vs exception handling far away from where the error occurs. But even then, in situations where option/maybe types are not idiomatic or where multiple libraries you're using throw exceptions, it may be much easier to handle these different cases with a single error handler closer to where you need to report or log the error than in various places where the error may happen. It's hard to generalize because the expected level of robustness is so wildly different from one use case to another. If you're writing a service that is expected to serve billions of requests every day or a client app that needs to be deployed to millions of users without expectation of centralized logging, that's different from when you're writing some internal web app that has 10 active users.