Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
qsvui
Aug 23, 2003
some crazy thing
I have just started using Entity Framework 6 on this new app I'm working on. Is this a mistake?

Adbot
ADBOT LOVES YOU

Volguus
Mar 3, 2009

My Rhythmic Crotch posted:

The way I'd explain it is: if the ORM is writing your sql for you, what do you do when you have a performance problem? (Throw hardware at it, rather than tune or restructure!) Or requirements change and now you need to do something that probably should be done in sql, but don't know how? (Write a ton of crusty, slow application code rather than use a join!)

Knowing SQL is required when working with a relational database that "talks" SQL. Employing an ORM to write the SQL for you doesn't preclude one from knowing SQL. The two things are not related in the slightest. So, what do you do when the SQL generated by the ORM is not performant enough? You write native SQL, that's what you do.

Now, what do you do if you wanna be a programmer but you don't know how to write code? You pack your things and go home. That has nothing to do with ORM, UI Designers, or any other tool that programmers have created to help other programmers. Just because one can write ASM, doesn't mean that one should keep on writing ASM.

qsvui posted:

I have just started using Entity Framework 6 on this new app I'm working on. Is this a mistake?

As with anything: it depends. Most likely it'll be fine, don't worry about it. When yo have to worry, then "write native SQL".

Volguus fucked around with this message at 04:44 on Sep 14, 2018

champagne posting
Apr 5, 2006

YOU ARE A BRAIN
IN A BUNKER

My Rhythmic Crotch posted:

The way I'd explain it is: if the ORM is writing your sql for you, what do you do when you have a performance problem? (Throw hardware at it, rather than tune or restructure!) Or requirements change and now you need to do something that probably should be done in sql, but don't know how? (Write a ton of crusty, slow application code rather than use a join!)

Make everything a view :v:

Then make views of views and get weird problems with inheritance.

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

My Rhythmic Crotch posted:

The way I'd explain it is: if the ORM is writing your sql for you, what do you do when you have a performance problem? (Throw hardware at it, rather than tune or restructure!) Or requirements change and now you need to do something that probably should be done in sql, but don't know how? (Write a ton of crusty, slow application code rather than use a join!)

for performance tuning,
step 1 - does everything has the proper indexes? what's going on in the profiler?
step 2 - how many rows are being returned by the query, and how many are expected to return? Is the query really "slow" or is it just returning hundreds of megabytes of results and IO bound? Can we paginate the results (maxrows + offset)?
step 3 - is the data correctly modeled? did somebody gently caress something up with cardinality? do we need everything that is returned in the query?

orm by itself can't solve the above issues, a human being is going to have to make a judgement call there.

spiritual bypass
Feb 19, 2008

Grimey Drawer

My Rhythmic Crotch posted:

Write a ton of crusty, slow application code rather than use a join

but I heard joins are slow

Rubellavator
Aug 16, 2007

rt4 posted:

but I heard joins are slow

"Rewrite that query so it doesn't use outer joins, those are really slow" - guy who helped write the psuedo-orm I'm currently replacing

Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.
New Job is ASP.NET with Episerver sitting on top of that. I've been hired as a front end developer to come in and try to shoehorn react or angular on top of THAT and I've no idea how we're going to go about doing that. I mean I can see ways we might but honestly it's pretty silly. There's also no way I'm going to avoid learning ASP.NET which I don't mind too much considering that C# is an easy enough transition after spending 2 years in a typescript / angular environment and the rationalisation that ASP.NET makes makes sense to me.

Still. What the gently caress.

The Fool
Oct 16, 2003


Adding react or angular to ASP.NET shouldn't be a big deal.

Never heard of Episerver before, but just looking at their webpage gives me nightmares.

AskYourself
May 23, 2005
Donut is for Homer as Asking yourself is to ...
Regarding ORM and more specifically Entity Framework (because that's the ORM I know the most) :

Always have a SQL profiler open on your second monitor so that you can see the DB requests as you execute your code. This way you will learn how to build crappy queries and efficient queries
Batch operation are poo poo, if you have to update the value of one column for all your row then EF will will do one update per row which of course will suck. So you can either handcraft SQL queries or use something like https://www.nuget.org/api/v2/package/SqlBulkTools/4.5.0
You can import SQL Views, Stored proc and functions into your EF model so you can still benefit from your leet sql knowledge



Micro ORM like Dapper is pretty neat too.

Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

The Fool posted:

Adding react or angular to ASP.NET shouldn't be a big deal.

Never heard of Episerver before, but just looking at their webpage gives me nightmares.

Except EPISERVER is a CMS that wants control of the DOM

Volguus
Mar 3, 2009

Ape Fist posted:

Except EPISERVER is a CMS that wants control of the DOM

Ok angular and Episerver: fight. Whoever wins, stays.

Xik
Mar 10, 2011

Dinosaur Gum

Ape Fist posted:

New Job is ASP.NET with Episerver sitting on top of that. I've been hired as a front end developer to come in and try to shoehorn react or angular on top of THAT and I've no idea how we're going to go about doing that. I mean I can see ways we might but honestly it's pretty silly. There's also no way I'm going to avoid learning ASP.NET which I don't mind too much considering that C# is an easy enough transition after spending 2 years in a typescript / angular environment and the rationalisation that ASP.NET makes makes sense to me.

Still. What the gently caress.

Welcome to the pits of hell that is enterprise software development, let me one up you with a critical user facing app with:

Mixture of Vanilla JS, Knockout, Angular in different custom modules of a DNN CMS instance which has the server side components that call a mixture of web apis, WCF services, Biztalk endpoints, MS SQL instances (query or stored procs) and Oracle Web services, a layer to expose Oracle packages and procedures. Every level of this stack contains business logic seemingly implemented at random. Some components, such as DNN and Biztalk have been so heavily customized or have so many depreciated extensions to make it impossible to apply patches from vendor or perform upgrades.

Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.
You are a hiring manager whose also a dev. You can hire one of these people:

Person 1: Has a strong grasp of theory, understands software design concepts quickly, but spends an above average amount of time on stack because they tend to forget syntax things. As a result their code is sometimes untidy, an not ideally optimized.

Person 2: Is extremely good at syntactical recollection, writes clean and efficient code which compiles nicely most times through repetition, but absolutely can't grasp design structures or really any of the theory outside the 'local scope' of what he's working on.

fantastic in plastic
Jun 15, 2007

The Socialist Workers Party's newspaper proved to be a tough sell to downtown businessmen.
At least in the way the question's framed, I'd go with #1. There are linters and automatic optimization tools to hedge against those flaws and good software design can save untold hours of work.

(Though the real answer might be "it would be good to have someone who's actually good at something around here, hire either".)

CPColin
Sep 9, 2003

Big ol' smile.
Hire them both and make them sit together!

Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

CPColin posted:

Hire them both and make them sit together!

Good answer

ultrafilter
Aug 23, 2007

It's okay if you have any questions.


Both people are the right match somewhere. I'd hire the first one and make one of their performance goals to write cleaner code, but there are a lot of groups where the second person is a better match because they just need to churn out features as fast as possible to keep their customers happy.

Xarn
Jun 26, 2015

Ape Fist posted:

You are a hiring manager whose also a dev. You can hire one of these people:

Person 1: Has a strong grasp of theory, understands software design concepts quickly, but spends an above average amount of time on stack because they tend to forget syntax things. As a result their code is sometimes untidy, an not ideally optimized.

Person 2: Is extremely good at syntactical recollection, writes clean and efficient code which compiles nicely most times through repetition, but absolutely can't grasp design structures or really any of the theory outside the 'local scope' of what he's working on.

Is there a person 3 with managerial skills?

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...
Hire person 2 then make them lead architect because of how nice that code they wrote is

smackfu
Jun 7, 2004

Person 1’s code can be fixed during code review.

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

You are a hiring manager whose also a dev. You can hire one of these people:

Person 2: Is extremely good at syntactical recollection, writes clean and efficient code which compiles nicely most times through repetition, but absolutely can't grasp design structures or really any of the theory outside the 'local scope' of what he's working on.

I would never voluntarily hire a #2 but it's really difficult to know who those are before hiring them. Most of my day to day work is cleaning up after their messes.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Which of those can work in a team?

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.

Ape Fist posted:

You are a hiring manager whose also a dev. You can hire one of these people:

Person 1: Has a strong grasp of theory, understands software design concepts quickly, but spends an above average amount of time on stack because they tend to forget syntax things. As a result their code is sometimes untidy, an not ideally optimized.

Person 2: Is extremely good at syntactical recollection, writes clean and efficient code which compiles nicely most times through repetition, but absolutely can't grasp design structures or really any of the theory outside the 'local scope' of what he's working on.
I'm Person 1 already and I definitely don't need another one of me

Ghost of Reagan Past
Oct 7, 2003

rock and roll fun

Bongo Bill posted:

My belief is that relations are not objects, so if you're using an ORM to manage things in a way that lets you treat relations as objects, you'd better be getting some really powerful magic to make up for the pain you'll experience at the parts where things don't quite match up.
ORMs are good tools but they require that you be smart about your design, rather than treat it as just another object in your application. FOR INSTANCE, I work on a Django app where the Django ORM works 90% of the time, but people made some decisions years ago to do things that look extremely natural with Python + Django but result in some absolute hell in the database. ORMs make it easy to just write code and go, but you have to be aware.

This is all just good database design stuff, but if you're just a programmer with limited knowledge of SQL and databases, you're given a powerful weapon to shoot yourself in the foot.

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

ultrafilter posted:

Both people are the right match somewhere. I'd hire the first one and make one of their performance goals to write cleaner code, but there are a lot of groups where the second person is a better match because they just need to churn out features as fast as possible to keep their customers happy.

Maybe just to clarify, but here's why I don't like #2s:

1. Since #2's don't know what's going on in the system, they'll re-invent the wheel. Without guidance, they'll come up with their own data access layer, own localization, own UI frameworks. If you ever wonder why you have multiple places in the system that do the same thing, it's a #2's fault (this can be mitigated with code review)

2. #2's are usually not great at debugging problems in other people's code - if they're somehow forced to use code written by teams for whatever reason rather than doing their own thing, if there's a problem with that component, instead of either debugging the component or at least engaging the original developer, they'll either get stuck, or try to work around the problem themselves (which won't fix the problem for everyone else.)

3. Sometimes, developers get tasked with developing a component that's a stupid idea - e.g. if you're developing application software, why are you writing your own identity server or SSO server? If a #2 is tasked with creating a component, that component is going to exist, and they're going to write it, god dammit, regardless of whether or not an open source MIT licensed solution exists, or whether the original project was a loving stupid idea. Sometimes the winning move is to write no code (agile/scrum on paper take care of this by breaking down requirements into user stories that have user facing requirements, which tends to mitigate these kinds of mistakes) Oftentimes #2s solve these kinds of problems by writing a bunch of code that shouldn't exist and making the system itself depend on that code that shouldn't exist in the first place.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
#1 sounds like they'll wrote 100 lines that might need initial polish to solve a problem while #2 sounds like they'll write 1000 lines for the same thing. I'd rather wade through #1's code.

Then again, having to deal with somebody that went, "ugh, more objects" when explaining how to solve a problem before has made me very averse to those types of people.

Eggnogium
Jun 1, 2010

Never give an inch! Hnnnghhhhhh!
I dunno, “ugh, more objects” is basically my mantra when reading any mature Java/C# codebase.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Bruegels Fuckbooks posted:

Maybe just to clarify, but here's why I don't like #2s:

1. Since #2's don't know what's going on in the system, they'll re-invent the wheel. Without guidance, they'll come up with their own data access layer, own localization, own UI frameworks. If you ever wonder why you have multiple places in the system that do the same thing, it's a #2's fault (this can be mitigated with code review)

2. #2's are usually not great at debugging problems in other people's code - if they're somehow forced to use code written by teams for whatever reason rather than doing their own thing, if there's a problem with that component, instead of either debugging the component or at least engaging the original developer, they'll either get stuck, or try to work around the problem themselves (which won't fix the problem for everyone else.)

3. Sometimes, developers get tasked with developing a component that's a stupid idea - e.g. if you're developing application software, why are you writing your own identity server or SSO server? If a #2 is tasked with creating a component, that component is going to exist, and they're going to write it, god dammit, regardless of whether or not an open source MIT licensed solution exists, or whether the original project was a loving stupid idea. Sometimes the winning move is to write no code (agile/scrum on paper take care of this by breaking down requirements into user stories that have user facing requirements, which tends to mitigate these kinds of mistakes) Oftentimes #2s solve these kinds of problems by writing a bunch of code that shouldn't exist and making the system itself depend on that code that shouldn't exist in the first place.

You described 95% of the India based coders I worked or experienced.

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Keetron posted:

You described 95% of the India based coders I worked or experienced.

I've worked with a lot of off-shore developers. What I've found is that Indian developers will generally be pretty gun-shy about saying "no" or confrontation in general, and this is probably a function of the conditions of their employment. I would say most of them aren't true #2s because they will take the effort to understand the system and use existing apis, but they won't say no when morons tell them to implement something stupid (they are generally paid by the hour, so it makes perfect sense.)

Che Delilas
Nov 23, 2009
FREE TIBET WEED
Boy oh boy, my company has broken new ground today. Management here has a long proud history of having triple our capacity's worth of projects listed as "highest priority," resulting naturally in a lot of disappointed customers and somewhat high churn. To balance that out (at least, in terms of the stress that causes to devs), they have until now been very good about not pushing us directly to work extra hours for nothing and in general butts-in-seats has not been a performance metric. Today I hear the CEO has been using the phrase "we (read: you) might need to be willing to work some nights and weekends."

Sure we have a decade of technical debt brought about by only ever considering the immediate short-term consequences of all decisions. Let's double down on that by pressuring devs to design systems and write code when they're at their worst: tired and resentful from compromising their personal lives and health. THAT won't result in a ton of extra bugs and outages and monster tech debt, oh no. I don't know if anything will come of this, the CEO's always been a drum-beater, every month he says the same things, always some variant on "we really need to buckle down and dig deep" and other ostensibly motivational platitudes. This is the first time he's come right out and said "extra hours" though.

I'm not going do do anything differently. Either he's just taking a different tack with his motivation or he's really planning on putting direct pressure on us to work longer hours; it's not going to change the way I work, especially since this place has been violently allergic to cash bonuses for a long time so there's no incentive. What it might do is put enough extra pressure on me that I move on, and the company is going to lose more than they gain if they push me to that.

I know this reads as software_company.txt to some of you, it'll just be a shame if literally one of the biggest perks of this place goes out the window in yet another fit of shortsightedness. Ah well, we'll see.

ultrafilter
Aug 23, 2007

It's okay if you have any questions.


You either leave your company on a high note or stay long enough to see it become a shithole.

Captain Cappy
Aug 7, 2008

What are they gonna do, fire you and let you collect unemployment? Sounds great!

Che Delilas
Nov 23, 2009
FREE TIBET WEED

Captain Cappy posted:

What are they gonna do, fire you and let you collect unemployment? Sounds great!

They would be colossally stupid to do that, and I think if any of the management brought it up as an option they would be shouted down by the rest of them who actually know something about what I contribute. There is too much going on to lose the amount of institutional knowledge that I have that abruptly. No, I think the most they'd do would be to put a lot of pressure on me to sacrifice my personal life, and if that starts happening I'll just disengage and start shopping around.

fluppet
Feb 10, 2009

Che Delilas posted:

Today I hear the CEO has been using the phrase "we (read: you) might need to be willing to work some nights and weekends."
...

I know this reads as software_company.txt to some of you, it'll just be a shame if literally one of the biggest perks of this place goes out the window in yet another fit of shortsightedness. Ah well, we'll see.

Hate to point this out but not being made to work weekends should not be considered a perk let alone the biggest perk of the job
:sever:

Che Delilas
Nov 23, 2009
FREE TIBET WEED
Well, I meant more the correct attitude from the management that the measure of a dev does not have much of anything to do with spending AT LEAST FORTY SCHEDULED HOURS AT YOUR CHAIR ON TIME MONDAY THROUGH FRIDAY. Which, yes, should not be considered a perk it should be considered the way you treat a skilled professional by default. But it's not, at least not in this country, so companies that understand and practice it have a major advantage over the ones that don't. Call it what you will. My company has been very flexible and relaxed when it comes to working hours, and that I call a perk.

redleader
Aug 18, 2005

Engage according to operational parameters

Che Delilas posted:

if that starts happening I'll just disengage and start shopping around.

Start looking anyway. No point in waiting til it gets bad.

hailthefish
Oct 24, 2010

Regular blue-collar factory laborers fought and loving died for the 40 hour week and the 8 hour day.

And now it's p much dead lol :911:

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Che Delilas posted:

Well, I meant more the correct attitude from the management that the measure of a dev does not have much of anything to do with spending AT LEAST FORTY SCHEDULED HOURS AT YOUR CHAIR ON TIME MONDAY THROUGH FRIDAY. Which, yes, should not be considered a perk it should be considered the way you treat a skilled professional by default. But it's not, at least not in this country, so companies that understand and practice it have a major advantage over the ones that don't. Call it what you will. My company has been very flexible and relaxed when it comes to working hours, and that I call a perk.

Currently working at a client that understands that developer output is measured by features moving to production environments over a very long period of time (building maintainable code is considered important) and not by butt-in-chair-time. The pay is pretty good too. Did I mention a lenient WFH policy?
It compensates for a lot of the other stuff, such as working at a big bank and commuting three or four days a week.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

Che Delilas posted:

They would be colossally stupid to do that, and I think if any of the management brought it up as an option they would be shouted down by the rest of them who actually know something about what I contribute. There is too much going on to lose the amount of institutional knowledge that I have that abruptly. No, I think the most they'd do would be to put a lot of pressure on me to sacrifice my personal life, and if that starts happening I'll just disengage and start shopping around.

Wow, I'm sure a CEO that takes your refusal as a personal affront would never use your job as a way to settle a perceived slight and send a message. Why, that would be crazy!

Adbot
ADBOT LOVES YOU

Che Delilas
Nov 23, 2009
FREE TIBET WEED

Volmarias posted:

Wow, I'm sure a CEO that takes your refusal as a personal affront would never use your job as a way to settle a perceived slight and send a message. Why, that would be crazy!

Always a possibility, obviously. But based on the company culture and the managers here, I doubt it will happen, even if we ever do get to the point where he's "requiring" unpaid overtime. Regardless, I draw the line where I draw it; I won't be here long if we move in that direction, in any case.

redleader posted:

Start looking anyway. No point in waiting til it gets bad.

Yeah I keep an eyeball on the job sites, see if anything catches my fancy. Interviewed at a place a couple months ago and it didn't go anywhere. This is the kind of thing that causes me to put more energy into searching though, no doubt.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply