Kinda, I guess we all can agree it’s more typical to deserialize into POJO where theres is no such thing as missing field. Otherwise why would you choose Java if you don’t use types. This great precondition for various stupid hacks to achieve „patching” resources, like blank strings or negative numbers for positive-only fields or even Optional as a field.

You talking about those forcefully recruited after being blackmailed into accepting Russian passport or those who already had it before 2014 and were sent there after? Yes, sure, there are people who genuinely wanted those regions to be part of Russia. As there are Russians fighting on Ukraine’s side. Following your logic Ukraine or other “high moral” party should’ve run “special military operation” to help Russian Freedom Legion to overthrow Putin. Why not mentioning Crimea’s tatars in Russian army? Is it coz they were repressed, their property was taken and they were forcefully moved out of their native lands? Why their ethnicity is not that important? Can’t absorb Russian identity nationalism to the degree they blindly follow their tsar? Or better tell us if Russia is so pro-ethnicity independence then why Russia taking down those Dagestan rebels? Or not giving Siberia’s people independence? “That’s all western propaganda” you’ll say. Don’t bother.

I’m join my neighbor in request to you to fuck ff. Don’t make me mad and keep “your” imperialistic opinion for Russian Empire fan meetup. The only anecdote here is you

Agree. I find “get started” usually is the best way to give an example of “entry point” to API. After that API documentation should get anyone covered for most of the cases. If API is big then it probably has primary and secondary set of features. Secondary then can be covered as tutorials.

How about SQL in PostgreSql? query: select array_length(Array[]::text[], 1) Output: null

Dont get me wrong JS is still awful

Top ten comments do not mention typo. What a hell is going on. It’s Lenuks, not Linux

My colleague was working on migrating around dozens of batch jobs written in Java. All jobs had JPA/Hibernate but people which were writing those jobs didn’t understand abstraction and encapsulation. It end-up as vendor locked as you can imagine. Procedures, reading cursors, Oracle specific functions, metadata, logic spread between Java and PL/Sql, all the fun stuff, you know. So it took around one year of work to migrate to Postgres. And that’s with support of DBA who was helping with rewriting most complicated queries and procs. So yeah, don’t worry about that DBMS specific features.

Don’t get me wrong, though. Efforts spent on making design decisions should be proportional to potential size/complexity growth of the software. If you building todo list , how many different queries you might have in fairly pessimistic scenarios? Maybe couple dozens. Don’t bother with JPQL or HQL. If you expect your app to grow significantly. I’d do as much as possible to avoid my colleague’s fate.

Please, can you give an example of such code snippets? I’m wondering what people consider reusable in different projects.

To me, generated code should not be committed at all. Again, I know nothing about this stack but code generators can have different behavior on different machines due to versions, flags and even OS. To deliver consistent results they should run in consistent env. It’s build time concern which CI/CD should take care of.

I didn’t get do you do integrations besides of your DB.

To me architecture sounds good anyway. I’m not GO dev but it looks like stack is your main problem not architecture itself. Multiple models is great long term approach which makes sure you are not leaking implementation details of your persistence/3rd party services to your client. You have layer of mappers where you can enrich model in optimal way and at the same time you can accommodate whatever client request/payload quirks you may need. Yes it’s sometimes annoying to add one field and pass it across all layers but it’s the price and software development is all about balance and compromises. I worked in projects that didn’t follow this architecture and any kind of change in DB/3rd party were cascading through entire application so end up changing hundreds of files instead of couple of models and few mappers

You may have issues with this architecture if you invoke services directly one from another for complex use cases. This can couple things together. If that’s what’s happening think if can apply Facade. Try using/reusing more trivial and focused services in Facade to make sure that for example Order service does not depend on Client service. Leave it to ClientOrderFacade.

weekend = dayOfWeek > 5

I like (no) how everyone knows this is about everybody’s mental health but you can only push things these days if iT iS aBoUt cHilDrEn or other touchy topic. Apparently adults can’t have mental health issues I guess, otherwise how will they do their jobs for cents

Thank you. This actually gives perspective on radiation level better than Rads

Good I’m staying away from both

First of all, what you are doing is integration via DB. Unless that was conscious, I would avoid using this approach. System is much easier to manage when DB/schema used at most by one app. You have two ways to achieve it, move towards micro-services or monolith. Yes monolith is still great for some use cases.

If we talking about your current system state every app should do changes in most backward compatible way. It worst cases it will lead to duplications. Let’s say if you want to change table X because there is such need for app A and at the same time app B uses this table. Instead of modifying X you create table Y that satisfies needs of A and make sure that data written into Y as well as into X to maintain B.

I love waterfall as an developer, I’m using agile now and we have incomplete, conflicting designs every sprint, or spills which affect our metrics, where in waterfall you can workout all the details and have full vision of product and better design with less reworks.

Not to mock you. My point is that methodology is not import when team consists from responsible professionals

“But I’ve told to users that we will deploy this feature tomorrow”

It’s called replica :)