The Stack Overflow podcast is back! Listen to an interview with our new CEO.
201

Perfect is the enemy of good. Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount ...


110

Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable? The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time. You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And ...


38

XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have the problem which the technology is designed to solve. There are ...


35

You literally cannot prevent users from accessing and modifying content that you are sending them. You have no control over the browser, or which browser they use, or whether they are in fact downloading your source code via a browser. You are executing your code on another person's device. You should not and cannot assume anything about the integrity of ...


23

You can't. One of the fundamental rules of computing: you can't trust the client. Whatever clever scheme you think of, I can get round it if I am in control of the client.


18

Despite the enormous amount of money Facebook and Google have poured into marketing to convince you otherwise, front end frameworks exist for two primary reasons: First, offloading hardware/network demands to client-side operations by way of putting state and logic in the client Second, pertinent to the additional client logic necessary to support the first ...


8

Depends what you mean by "in Web". XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL. But XSLT isn't widely used client-side, that is, in the browser. It's usually used either ...


7

The best thing you can do to "future proof" your app is to follow best practices in the design of your system to maximize loose coupling and separation of concerns. There is no part of your app that is safe from becoming obsolete, but much you can do to isolate code that becomes obsolete for reason X from code that doesn't necessarily have to be impacted by ...


6

When you look at the most highly scalable web applications (or services) today, the problem wasn't ensuring enough threads that were available, but ensuring the whole system could handle the concurrent web connections required to service the endpoints. The biggest advancements in concurrent requests/second on one installation came from non-blocking I/O. ...


5

Above all else, "scrapping the thing and starting over" is never an option ... after all, didn't you say that you have "a half-dozen clients?" Have you yet paused to consider what they might think of your pronouncement, given that they are right now (presumably) "perfectly happy with your work?!" Here's an analogy that I like to use: "My job is to build ...


5

I would try to keep the TicTacToeGame completely UI agnostic. No observer, no publisher-subscriber inside that class. Only "business logic" (or call it "game-logic") inside that class, no mixed responsibilities which could lead to the complexity you scetched in your question. Instead, you could implement the turn-logic by utilizing your own event queue. I ...


5

Ask a human to do it with pixels and we call it a GUI: Graphic User Interface. Ask a human to do it with text and we call it a CLI: Command Line Interface. Ask a computer to do it with bytes and we call it an API: Application Program Interface. This is likely the mentality of your colleagues. And I'd agree with them with one qualification: It isn't ...


5

If you notice, most of these systems are setup in such a way that you're going to get some well known string input and have to produce some well known string output. At that point, they can take your code and run it as a plain old executable (in some highly disposable sandbox), testing via stdin and stdout while ignoring what language actually created the ...


4

When an inverse command doesn't exist for every command there are two fundamental ways of implementing undo: Reload the previous state Replay all commands but the last over the initial state For the second option to work the commands all need to be side effect free. That is, they should only be changing the state, nothing else. You can follow the command ...


4

"Too complex" is a common concern for new developers, but consider that this is a working solution for them right now. Working now beats better in six months, nine times out of nine. Also, as a new developer, please consider that re-implementing anything from scratch will take several times longer than you expect, is statistically unlikely to fulfil even the ...


4

There is no absolutely fool-proof technical way of ensuring that your product will not get used without a proper license. You can only take technical measures to make it harder. Based on that premise, the first question you should ask yourself is how likely it is that your customers would try to go against your license and get themselves potentially into ...


4

You can keep updated data in a memory cache (such as REDIS) on the server side that is flushed into the database less frequently. But the general rule of thumb for optimization is that you don't do it before you: clearly see that there is a performance problem, either by experience or by calculations based on hard data and reasonable assumptions about ...


3

I would go with the strategy pattern. class Player { async getNextMove() { throw new Error('not implemented'); }; } class AiPlayer extends Player { async getNextMove() { /* Your AI LOGIC*/ return 0; }; } class HumanPlayer extends Player { async getNextMove() { await /*deal with user input*/ }; } // ...


3

I started writing a comment about learning frameworks, but eventually it turned into something looking more like an answer, so here it is. Not knowing any frameworks seems like an issue. In basically any webdev job you will need to work with some framework. Learning another framework after you know one is not that big deal, but learning the first one may ...


3

Ensuring something is future proof is almost impossible. Checking that app is scalable is not too hard though. You just need to write some performance test for the app and see how many clients it can handle. Writing tests will definitely make your app more future proof because you will be able to gauge how app behaves after you implement more changes into it....


3

I'll assume that you are tracking occurred expenses (in the past) and not planned expenses (in the future). The approach of the expense generator is fine: keep track of all the recurring expenses in a collection (or a special table), sorted by date of the next occurence; every time the generator is executed, it shall go through the collection until it ...


3

I am flip-flopping back and forth between answering this question and closing it as primarily-opinion-based. So, here's my flip: In short, because XML makes a crappy programming language. Something with the semantics of XSLT but much better syntax would be a whole different matter, I think. There are some really cool Lisp-based XML-transformation languages, ...


3

Web design consists of two aspects: designing a site, and implementing it. You are used doing both together, but it can often be sensible to separate them. For example, you might use a wireframe to discuss requirements with a stakeholder, or to discuss user stories with other developers. Or you might want to have someone who understands design and UX design ...


3

Session storage is tab specific (i.e. not shared across tabs). So you can check session storage for a given key value, create it if it doesn't exist, and include it in any requests you send to your server. This will let both your server-side and client-side applications identify specific tabs.


3

Formal verification is very rarely used: the software system needs to be modelled in a formal system that requires skilled labour so formal verification is very expensive compared with other QA strategies. It is literally not worth it for many programs, in particular for things like web applications that sit on top of a huge stack of unverified software. ...


3

It took a couple of readthroughs to verify I had a good understanding of where you're coming from and what you're trying to do, and I think I get it. It sounds like you're in the middle of the foundational design phases of a large-scale practical research project, and are building out this system's base framework. It is very cool to see the amount of ...


3

It protects the legitimacy of the interaction between the user and the "original" website from malicious Javascript executed on the "other origin." Suppose I am logged into a super-secret admin portal A. I've finished doing my admin work, so I decide to go off browsing and find myself on dodgy website B. Dodgy website B executes some javascript that ...


3

You've correctly identified that there is a potential issue here if you ever want to replace parse-server with something else. The "solution" to this is, as you suggest, to ensure that all of your third party dependencies are wrapped with an adapter - then, if you ever need to switch out your dependency, you only need to rewrite the adapter. In practice, ...


3

The backend person might have omitted their valid justifications Back-end person claims that front-end should to have two calls. First to authenticate user (login process) with JWT response only then second to authorize to retrieve user permissions, role(s) and user data. At face value, there's little reason to split a single workload into two network ...


2

Why don't you want the code to be modified? Security? Trust? Trade Secret? Then don't send the code, get the client to send a request, and return a result. Maybe not a private or privileged result, just a done is sufficient for many UIs. Because slightly modified versions of your own code are hurting your bottom line? Use a code obscurer, name mangler, ...


Only top voted, non community-wiki answers of a minimum length are eligible