51–60 of 214 posts
Should maybe add security and privacy to that list, in this day and age. Not that it all needs to be implemented right away (depending on jurisdiction you're operating under) but having a plan for how to solve security and privacy considerations and working with that in mind from the start can make it a much less painful experience in the long run.
* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text.
I'd rather spend days doing the mind-numbing work when needed rather than slow down my development process and remove all enjoyment from it ad vitam aeternam because of i18n-ing on the fly.
* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
True, although at least on mobile I think this is a button press in the IDE. Maybe Javascript/non-mobile native apps have it harder.
[0]: https://developer.android.com/guide/topics/resources/string-...
Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…
YMMV but with the introduction of JSON/JSONB columns in Postgres, this becomes very easy to achieve without introducing multiple databases. In my experience, at some point relational data will be required in most projects, even if it was not a requirement in the first iterations. Obviously, constraints may apply that make NoSQL a sensible choice in some scenarios.
I've noticed this too.
My leading hypothesis is that projects start with simple data storage requirements which don't require much more than "flat file database + JSON", i.e. NoSQL, document database like Mongo etc. The fast and loose nature of these systems is nice to have at the start of a project too, compared to the work needed do SQL.
As the project evolves requirements start to appear which require combining data from 1 or more of these "flat files" or document collections. Then you discover that that your data is relational after all and these new "simple" queries you want are hard to do with your chosen (NoSQL) database.
In short: As an application evolves and its data grows, it tends to become more relational.
* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…
It is fairly small and trivial to add so please, if you foresee an event where systems have to support multiple languages and odds are you won't work on it yourself, prepare the damn codebase for it.
Earlier quoted context omitted.
So what would be an example of a software design principle?
Never write a function called destroyBaghdad(). Instead name it destroyCity and pass the target as a parameter.
> More generally, instead of a boolean flag, e.g. completed, a nullable timestamp of when the state was entered, completed_at, can be much more useful. In my experience, the timestamps should almost always be entered in addition to the flag. select * from data_journal where status = 'Loading' is much easier to write and understand than select * from data_journal where started_loading_at is not null and finished_loadi…
This sounds like you're opening yourself up to situations where you have rows in data_journal that have status='Loading' but which have started_loading_at=NULL, in violation of your data model. Your premise is slightly flawed in that your second example isn't actually difficult to write or understand as you claim. However, it could be argued that if the logic for selecting "loading" rows is repeated in multiple place…
Why not CHECK() it then? Or make ‘status’ GENERATED STORED or do a similar thing on triggers. The way that you suggested is also good, but it creates two names, one for update, another for select, which may confuse orms or developers.
* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
Refactor the code to support a requirement when the need arises.
> I'm essentially a believer in You Aren't Gonna Need It — the principle that you should add features to your software — including generality and abstraction YAGNI is not a principle. It is a contextual thumb rule. A codification of expert intuition. Exceptions to thumb rules are quite the norm. Conflating thumb rules with principles is a sign of sloppy thinking. Often engineers will misuse terminology thinking that…
In fact, the ultimate defining characteristic of a "principle" is that it has exceptions and should not be used as the "ultimate word of God".
Even in Physics, where most would think a "principle" means something "without exception", they are only ever currently without exception according to current evidence. There has been countless times where there has been a scientific principle only to be disproven later on.
Lastly, you link Sapir–Whorf, which, quite ironically, is considered a "principle" yet has had much criticism over time, which contradicts your own argument.
However, I will agree with you that one should always be careful of the language they use since it can affect how others view your thoughts, feelings, and intentions.
* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…
getStringForKey(key, language) {
return map[key]