-
var weAreConnected = Math.floor(Math.random() * 10) > 5; if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) }What? It’s difficult to take the article seriously after that. Seems like a purposely obfuscated example for saying:
var connected = Math.random() > 0.5; this.setState({isConnected: connected});And it’s not about not being fluent with JS either. This is just basic boolean stuff.
-
-
The connected variable isn’t reused anywhere either so couldn’t you just do this?
Yep, absolutely, in this simple case, i wouldn’t mind either way. But splitting the calculation into its own variable, even though the variable is not reused anywhere else, has some benefits:
Each line is does a one simpler thing: first determine whether we’re connected using a random value, and then set the component state to that.
The code is more debugger-friendly. You can easily tell the value of the
connectedvariable before setting the state by stepping between the two lines.
I’d use a ternary statement for setting the color too, but I know some people don’t like those.
Well,
ifs in JavaScript are not expressions, so i’d use?:too :) -
I’d use a ternary statement for setting the color too, but I know some people don’t like those.
Do you know why ternary statements would be frowned upon? I don’t like nested ternaries, but other than that I find them extremely useful and they aren’t really that hard to use…
-
-
The new do expression in the early parts of the standardization process will make this process much nicer if it makes it.
-
-
-
To me, any C code is clever, not clear.
-
-
-
-
You’re just too much of a hacker. Not everybody can write this kind of code.
-
-
@swifthand You’re completely correct re: never trust the client and such. I’m a big fan of this quote by thomas ptacek:
I am wary of software security advice that leads with “don’t trust user input”, or revolves around “validate user input”. That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to tstart by acknowledging that the verb “trust” is situational, and that in some circumstances virtually all user input is “trusted” somehow. You could phrase this less tactfully as “Validate user input? No shit? Now what?”
The security industry has banged the drum of sanitize everything and yet this stuff still slips by! And I’m in agreement with you that the majority of code bases aren’t written like the example I posted, however I’ve seen variations of that pattern in live code bases. Shitty code exists everywhere! Likely not written by those that read these types of posts on reddit / lobsters / et al.
-
Agreed. I am perplexed about
String#constantize’s docs not having a big warning about it being a possible code injection vector, instructing that the string should always be validated. Or at least being tagged as “insecure/unsafe” in some way.Skimming through the Rails docs, it seems that these security matters are not given the importance they should. Even ActiveRecord’s
whereonly says:Note that building your own string from user input may expose your application to injection attacks if not done properly. As an alternative, it is recommended to use one of the following methods.
-
Microservices make sense in some use cases:
I’m curious, when do you like to use micro services? Or you prefer 100% monolithic?
I’m not a microservices proponent; i agree with the article. But i don’t think that not going for a microservice architecture implies going 100% monolithic. You can have different services without going micro ;)
For instance, a common architecture for websites nowadays is having an API backend as one service/project/thing, and the webapp frontend as another service/project/thing. I think this kind of separation, without going to ridiculous lengths of separating every functionality into its own microservice, makes a lot of sense. And it’s not a 100% monolithic solution, as you have the freedom of making architectural changes to either the frontend or backend services (like change the language/framework it is written in) without affecting the other.
Yeah, there’s a big difference between a few sevices, and a few hundred services (uber style).
As patrickdlogan points out above, you don’t really have to choose, since it’s a false dichotomy. It’s only about the size and responsibilities of the service, and that metric is absolutely relative, in the context of the developing organization.
I second this. At my workplace there used to be two monolithic applications and they are getting converted into two microservices (billing and session management) and another big application (a backoffice app). It doesn’t have to be an all-or-nothing type of approach.