Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now
122

For smaller companies (it's not clear how big yours is), three environments (dev, stage, production) are common. Larger companies will often have a QA environment between dev and stage. These normally break down as follows: dev: Working code copy. Changes made by developers are deployed here so integration and features can be tested. This environment is ...


74

Bob Martin is clearly exaggerating to make his point more clear. But what is his point? Does he just want people to stop using SQL/Relational Databases because of SQLi attacks? To my understanding, in that blog post (your first link) Martin tries to convince people to stop using SQL, but not relational databases. These are two different things. SQL is ...


59

In short words, normal software would be the software made with individuals in mind, i.e. retail software or web applications targeting the general populace. Its success depends on how well it is received by users who in most part are offered a ready-made, 'standard issue' product. The development is an investment and the revenue comes from individual ...


57

Bob Martin's opinion is just that; one man's opinion. A programmer is expected to understand the system he is writing well enough to exercise reasonable care about its security and performance. That means that, if you're talking to a SQL database, you do what the Bobby Tables website says to do: you sanitize your input data. It means that you put your SQL ...


52

Let's talk about costs: You state that everything has been done in Java so far? Why change then? You might use parts of the old system or create a reusable domain model. Integration will be easier. The developers are probably used to Java, so why would you spend money to train them on .NET? There's no reason for this, as .NET has no outstanding advantage ...


49

I am uncertain how to best describe this approach when my recommendation is to continue with the existing technology stack, but implement fundamental shifts in the locations where code belongs. Service oriented architecture. You are proposing to redesign your system so that your business rules and your data are in the same place. That's effectively the ...


31

Personally, I've tried making one huge schema for all my entities on a fairly complex but small project(~300 tables) . We had an extremely normalized database (5th form normalization (I say that loosely)) with many "many to many" relationships and extreme referential integrity enforcement. We also used a "single instance per request" strategy which I'm not ...


29

REST is not CRUD. That "counterargument" is based on a fundamentally flawed understanding of what REST is. I haven't seen anything in your post that indicates your change would make your API any more or less RESTful.


24

One reason is security - if (haha! when) a hacker gains access to your front-end webserver, he gets access to everything it has access to. If you've placed your middle tier in the web server, then he has access to everything it has - ie your DB, and next thing you know, he's just run "select * from users" on your DB and taken it away from offline password ...


24

One more thing to keep in mind is the following... Not validating your business rules server side, means you implicitly trust anything that comes in, through say a POST request, is valid. Meaning that for example, while your angular application might check if the customer has a valid age range and ensures that legitimate users get the correct feedback, ...


22

Your attachment to .Net is scary for someone responsibe for architecture, perhaps you are best surrendering to a lead programming role. Given that a lot of the code base is already in Java, there will be years of business logic, refinements and bug fixes, the appetite to 'rewrite' from scratch is very dangerous.


20

Consider a company that has a few different departments: Software Development HR Accounting Can you come up with a user model that can expressively represent all those areas of business? Think of what the User entity could look like in each one. Perhaps it's split into three different entities: Developer Employee Payee The effort to instantiate a user in ...


18

There really isn't enough information, as per Thorbjørn's comments. Caching, when done wrong, can cause you & your users lots of grief. Make sure you need to worry about caching before over-complicating your application. So, in the absence of information that indicates you really need to cache, don't cache. [General rule of optimization: If you need ...


16

I can give you another example. Consider you have some ecommerce system. You would have products there, however products will be part of at least two different domains: Product catalog, where you keep your product description and all attributes Inventory, where you have product stock level If you have one bounded context for both domains, your solution can ...


15

How I Learned to Stop Worrying and Love the MS-Stack You can still run VB6 apps on windows 8. Retro-compatibility for good or bad has always been a trend in the MS ecosystem. You shouldn't worry about the survival of technologies like WPF / Silveright, and even winforms for that matter. On the other hand, you have to accept that for a long term project, ...


15

What is he actually saying? Is he saying replace SQL with No-SQL technologies? TL;DR: Yes (sort of) In a more recent talk than the one you linked to on basically the same topic he says: "The database is a detail. Why do we have databases?". He claims database came to be to make data access from spinning disks easier, but in the future "[...] there ...


14

Most applications will require some external configuration; you can hide this by making it dependent on magic variables, or by saving it to some internal location, but that won't remove the need. The goal is to recognize what should be external, and what can be internal. Only the internal parts can be tested. An application should not trust an external ...


13

I'll refer you to https://softwareengineering.stackexchange.com/questions/39371/what-are-the-factors-that-have-made-java-a-success-as-a-programming-language-in-e and What would you choose for your project between .NET and Java at this point in time? But in short, you don't find many financial institutions going with .NET for the core platform after its well ...


13

I am a bit surprised that a test environment is not present as well, as a location for code to go to before being promoted to staging. To answer the question: A stage environment should mirror the production environment as closely as possible. It is used for verification of deployment procedures - making sure that when code is production ready it can be ...


13

First, ensure that the code is partitioned in such a way that your data provider can be switched easily. We're talking interface segregation and the other SOLID principles here. Next you need to know the answer to the following: 1) Will the data change frequently? 2) Does the application poll your REST service frequently to get these updates? 3) Is the ...


13

Let me start by simple clarification: I don't have experience with such large database so the rest of my answer is not based on the real world example. So you have a BIG database and you want to use it with ORM / EF. I would go with the second choice. Here is my simple explanation why: Mapping adds complexity. There is no need to add complexity with ...


13

What you call single REST APIs might be called REST API's particular set of resources or resources. You also could look at it as a REST API's functionality. Such as any kind of software, the whole package is versioned/updated, not single functionalities or resources. Your question would make sense in the context where the REST API package's resources are ...


12

It depends on the widget. If the widget is rare and expensive (exactly 10 Ferraris), then the approach you're following is correct. Of course, you also need to account for inventory that's being returned but hasn't been restocked yet, inventory that's out for repair, etc. If the widget is a bit more common (5,000 wrenches) then the usual approach is to: ...


12

Service Providers, doing only one thing The core difference, which has widespread consequences of the project, is that with Microservices these Service Providers are independently deployable and scalable. This is great, because you can be more agile. If a service needs changed, you just change that one, none of its kin. If you want to try a new framework ...


12

Transactions A transaction wraps all of the required steps for a particular business operation and guarantees that either all of the steps succeed or they all rollback to the original state in the database before the transaction was started. Further Reading How are Cassandra transactions different from RDBMS transactions?


11

You need to widen your definition. From http://dictionary.reference.com: en·ter·prise  [en-ter-prahyz] noun a project undertaken or to be undertaken, especially one that is important or difficult or that requires boldness or energy: To keep the peace is a difficult enterprise. a plan for such a project. participation or engagement in such ...


11

Here's an even better approach: use content negotiation to version your API with the Content-Type and Accept headers: POST /api/accounts Accept: application/vnd.my-api.account.v1+json 201 Created Location: /api/accounts/285728 Content-Type: application/vnd.my-api.account.v1+json { ... account data here ... } To get a different version, merely ask for it ...


11

SQL is a detail. Knowledge of a detail should not spread. As SQL is used in more and more places in your code your code becomes more and more dependent on it. As you learn more and more SQL tricks you solve more and more problems using SQL. This means that switching to another API to persist involves more than just translating. You have to solve problems ...


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