|
ExcessBLarg! posted:If you can't think of a better way to differentiate the name of an interface and an implementing class other than "IFoo" or "FooImpl" or "MyFoo" (my favorite) then maybe you just need a class. Can you mock a concrete class in all of the commonly used mocking frameworks?
|
# ? Mar 20, 2017 22:25 |
|
|
# ? Jun 5, 2024 20:21 |
|
Well that's what they're for, right! Except static classes, those can be a problem but if you're doing DI you shouldn't be using them anyway
|
# ? Mar 20, 2017 22:59 |
|
baka kaba posted:Well that's what they're for, right! I'm not sure if you're replying to my post, but after some brief searching, it seems like you can only mock virtual methods (at least for most of the .NET mocking frameworks).
|
# ? Mar 20, 2017 23:33 |
|
Telerik's JustMock can mock static classes. But typically you mock a class when it represents some external dependency, and those really shouldn't be static classes.
|
# ? Mar 21, 2017 01:38 |
|
ExcessBLarg! posted:If you can't think of a better way to differentiate the name of an interface and an implementing class other than "IFoo" or "FooImpl" or "MyFoo" (my favorite) then maybe you just need a class. Embarrassingly, I just did this today. I created an interface and a dummy class when what I actually end up using is simply a partially-implemented class.
|
# ? Mar 21, 2017 01:51 |
|
ExcessBLarg! posted:If you can't think of a better way to differentiate the name of an interface and an implementing class other than "IFoo" or "FooImpl" or "MyFoo" (my favorite) then maybe you just need a class. Is it wrong that I don't mind this? You can describe which APIs are intentionally public by adding them to the interface, and not worry about public/private modifiers in the implementation. You can view the public APIs without scrolling through pages of implementation. You can comment the hell out of the interface and keep the clutter out of the implementation. Plus, you can easily mock the interface.
|
# ? Mar 21, 2017 02:19 |
|
Sedro posted:Is it wrong that I don't mind this? You can describe which APIs are intentionally public by adding them to the interface, and not worry about public/private modifiers in the implementation. You can view the public APIs without scrolling through pages of implementation. You can comment the hell out of the interface and keep the clutter out of the implementation. Plus, you can easily mock the interface. In C++-land there are also perfectly reasonable motivations behind "Impl" classes. Not having any private members and other implementation details in the public class header means that the user-facing class ABI won't change when you change the private details of the implementation, which helps with both compile times and compatibility. This is of course mostly the case because C++'s compilation model is a barely functioning dinosaur kludge, but still.
|
# ? Mar 21, 2017 03:56 |
|
Microsoft's really doubling down on this active event thing. I read through the article again and it seems like a squinty version of dispatch tables or strategy patterns? But with less coherency? Also, this dude is pretty loving insane.
|
# ? Mar 21, 2017 05:30 |
|
boo_radley posted:Microsoft's really doubling down on this active event thing. Active events is essentially the "stringly typed" anti-pattern rebadged as an actual design pattern (see StringlyTyped).
|
# ? Mar 21, 2017 12:01 |
|
I am not terribly familiar with EF, but I thought it did something similar with mapping dynamic objects. I don't know if any of the people at MS or that thread have ever heard the terms 'dynamic linq', or if I'm just misunderstanding something in his 'disrupt oop' speech. Or have ever used python, or js, or google analytics ......
|
# ? Mar 21, 2017 17:15 |
|
Sedro posted:Is it wrong that I don't mind this? Personally I don't like unnecessary duplication of information, and it's nice to keep all the details of a class in one place.
|
# ? Mar 21, 2017 18:26 |
boo_radley posted:Microsoft's really doubling down on this active event thing. It's like Javascript, but on purpose!
|
|
# ? Mar 21, 2017 20:00 |
|
boo_radley posted:Microsoft's really doubling down on this active event thing. This just has to be prep for April Fool's, right? ...right guys? .. ... .. right.?
|
# ? Mar 22, 2017 08:09 |
|
RandomBlue posted:This just has to be prep for April Fool's, right? ...right guys? .. ... .. right.? Search your heart; it already knows the answer.
|
# ? Mar 24, 2017 06:03 |
Working my first job in webdev and I wonder... is all webdev held together by spit, duct tape and sticks?
|
|
# ? Mar 24, 2017 17:38 |
|
Joda posted:Working my first job in webdev and I wonder... is all webdev held together by spit, duct tape and sticks? No: some is held together by even less!
|
# ? Mar 24, 2017 17:40 |
|
Joda posted:Working my first job in webdev and I wonder... is all webdev held together by spit, duct tape and sticks? If I've learned anything in consulting for fortune 500 companies, banks, and insurance companies for the past few years, it's this: EVERYTHING is held together by spit, duct tape, and sticks. You know what company's codebase is rife with SQL injection vulnerabilities? All of them.
|
# ? Mar 24, 2017 17:44 |
|
New Yorp New Yorp posted:If I've learned anything in consulting for fortune 500 companies, banks, and insurance companies for the past few years, it's this: This. I've come around from "well they probably would have their stuff together" to "what are they not telling.....".
|
# ? Mar 24, 2017 17:55 |
|
Joda posted:Working my first job in webdev and I wonder... is all webdev held together by spit, duct tape and sticks? What New Yorp is saying is no doubt true, but there's no denying webdev has historically been particularly bad, probably because of the lower barriers to entry, how easy it is to slap together something that mostly works, and the dynamic nature of the languages and technologies involved. Modern web frameworks should theoretically help matters. At least modern web apps aren't as tightly coupled to their backends as they used to be since people are now more used to creating decoupled APIs that the frontend consumes the same way a third party client would. But in practice I think the frameworks often lead to even more cargo cult programming than before, because the complexity of creating a website goes up massively once you start using something like Angular. So yes.
|
# ? Mar 24, 2017 19:44 |
|
This is why I laugh whenever someone talks about being up to par with "production code". I've seen the code in production.
|
# ? Mar 24, 2017 19:55 |
|
LOOK I AM A TURTLE posted:What New Yorp is saying is no doubt true, but there's no denying webdev has historically been particularly bad, probably because of the lower barriers to entry, how easy it is to slap together something that mostly works, and the dynamic nature of the languages and technologies involved. Don't forget the platforms being historically garbage. Needing, effectively, three different versions of your website, or just flat-out saying "this website is not compatible with $browser", used to be super-common. Hell, it may still be common in some limited capacity, but not to the scale I remember it being like back in the mid-2000s.
|
# ? Mar 24, 2017 20:39 |
|
TooMuchAbstraction posted:Don't forget the platforms being historically garbage. Needing, effectively, three different versions of your website, or just flat-out saying "this website is not compatible with $browser", used to be super-common. Hell, it may still be common in some limited capacity, but not to the scale I remember it being like back in the mid-2000s. Now, instead of Netscape or IE is Chrome. There are way too many websites out there that only work on chrome, using some non-standard feature of the browser. It's back to where we started, just different actors.
|
# ? Mar 24, 2017 21:01 |
|
Duck typing ownsge: all types are implicitly interfaces Hell yeah
|
# ? Mar 24, 2017 21:03 |
|
TooMuchAbstraction posted:Don't forget the platforms being historically garbage. Needing, effectively, three different versions of your website, or just flat-out saying "this website is not compatible with $browser", used to be super-common. Hell, it may still be common in some limited capacity, but not to the scale I remember it being like back in the mid-2000s. Volguus posted:Now, instead of Netscape or IE is Chrome. There are way too many websites out there that only work on chrome, using some non-standard feature of the browser. It's back to where we started, just different actors.
|
# ? Mar 24, 2017 21:39 |
|
LOOK I AM A TURTLE posted:What New Yorp is saying is no doubt true, but there's no denying webdev has historically been particularly bad, probably because of the lower barriers to entry, how easy it is to slap together something that mostly works, and the dynamic nature of the languages and technologies involved. I think it's made worse by the literal children guiding webdev throwing tantrums every time an adult asks them to maybe please look at decades of learned lessons and not insist on loving up everything the same way. See, for example, how hilariously stupid NPM is and how the entire concept is incompatible with mediocre-practice, much less best practice. We've got another month or so before some other tiny package that's used by literally everything in the javascript space gets broken/removed/rage-deleted and it shuts down half the fortune 500 companies because "deploy" means "download random poo poo from websites to production servers and hope it all makes it OK." Are we even to the point where it's random signed poo poo yet? Because for a while it was "download random unsigned poo poo from non-ssl webservers" and that's what processes the form you type your credit card into. Of course it hasn't. You can pin by shasum but no guarantee that the hash that NPM came up with is the same as the file uploaded by the author
|
# ? Mar 25, 2017 00:45 |
|
Speaking of which, I'd like to nominate the situation with AngularJS releases, compatibility breaks every 2-3 months and the policy of 6 months of support after release to a proper dumpster fire rank. I am so, so glad dodged that bullet by picking KnockoutJS instead.
|
# ? Mar 25, 2017 01:47 |
|
Volguus posted:Now, instead of Netscape or IE is Chrome. There are way too many websites out there that only work on chrome, using some non-standard feature of the browser. It's back to where we started, just different actors. This is infuriating. You know who doesn't use Chrome? The majority of users on the web, that's who.
|
# ? Mar 25, 2017 06:24 |
|
Joda posted:Working my first job in webdev and I wonder... is all webdev held together by spit, duct tape and sticks? Ooh, look at this fancy lord with his duct tape and sticks! (A lot of it is, yes, if not worse. It makes you appreciate a good dev house all that much more.)
|
# ? Mar 25, 2017 06:40 |
|
It's not so much duct tape and sticks but more like various paper kites carefully floating due to the heat generated by a dumpster fire.
|
# ? Mar 25, 2017 12:11 |
|
my code is a jenga tower of turds
|
# ? Mar 25, 2017 12:51 |
|
Harik posted:Are we even to the point where it's random signed poo poo yet? Because for a while it was "download random unsigned poo poo from non-ssl webservers" and that's what processes the form you type your credit card into. Of course it hasn't. You can pin by shasum but no guarantee that the hash that NPM came up with is the same as the file uploaded by the author Pinning to hash should be just as secure as a signature, albeit less flexible. Signatures don't get applied to entire files; they hash internally. Upgrading the hash is a separate issue. Unless it doesn't verify the hash or something?
|
# ? Mar 25, 2017 12:56 |
|
Dylan16807 posted:Unless it doesn't verify the hash or something? I have a guess on that ...
|
# ? Mar 25, 2017 13:03 |
|
the real coding horrors are the people who use npm without a proxy/replicated feed
|
# ? Mar 25, 2017 14:25 |
|
Joda posted:Working my first job in webdev and I wonder... is all webdev held together by spit, duct tape and sticks? Many times, you need to look at this and get the model the character field is attached to, so what you do is use the bespoke foreign key to get an object (this isn't the primary key of the object we're getting, of course), get a foreign key from THAT, then run a query on a third object with the word and the bespoke foreign key. This runs hundreds of thousands of times a day.
|
# ? Mar 25, 2017 14:28 |
|
Dylan16807 posted:Pinning to hash should be just as secure as a signature, albeit less flexible. Signatures don't get applied to entire files; they hash internally. How do you know that the hash you're looking at is legitimate?
|
# ? Mar 25, 2017 15:47 |
|
Simulated posted:This is infuriating. You know who doesn't use Chrome? The majority of users on the web, that's who. That's not really true anymore: I'm just using NetMarketShare because they have the nicest graphs without paying, but other market share tracking sites show the same thing - Chrome edging to a narrow majority in both normal and mobile browser share, as the primary beneficiary of the final collapse of IE on desktop/laptop and the ever shrinking popularity of iOS in mobile (particularly tablets, where iOS share has dropped significantly at the same time the tablet market's shrunk for 2 years straight).
|
# ? Mar 25, 2017 17:20 |
|
fishmech posted:That's not really true anymore: That still doesn't make it OK.
|
# ? Mar 25, 2017 17:52 |
|
Harik posted:I think it's made worse by the literal children guiding webdev throwing tantrums every time an adult asks them to maybe please look at decades of learned lessons and not insist on loving up everything the same way. So I used to work for this autocomplete company, called constructor.io. If you go to npmjs.com and type some poo poo in the autocomplete in the searchbar, you'll see "powered by constructor.io" right there in the lower right corner. I styled that thingy and did some weirdo poo poo with the integration, and talked a bit to some npm folks during that. While talking, I learned that NPM Incorporated 1. Is for-profit 2. Took VC money That tells you p. much what you need to know. Their crunchbase: https://www.crunchbase.com/organization/npm#/entity
|
# ? Mar 25, 2017 18:40 |
|
Hughlander posted:How do you know that the hash you're looking at is legitimate? How do you know the signature you're looking at is legitimate? Using http is stupid of course, and signatures are nicer than version pinning, but if you decide you like a version then a hash should be at least functional.
|
# ? Mar 26, 2017 01:46 |
|
|
# ? Jun 5, 2024 20:21 |
|
Volguus posted:Now, instead of Netscape or IE is Chrome. There are way too many websites out there that only work on chrome, using some non-standard feature of the browser. It's back to where we started, just different actors. The only browser that I've seen having compatibility issues are still IE and Edge, more Edge than IE10/11 now. You almost have to go out of your way to write stuff that doesn't work on Chrome, FF and Safari now. Here's a fun .NET issues I ran into recently, find the WTF?, it's pretty easy to spot. Not sure if this is just another .Net Core issue or if older framworks had this problem too. Path.Combine("C:\Some\SafeDir\", "test.txt") == C:\Some\SafeDir\test.txt Path.Combine("C:\Some\SafeDir\", "anotherDir", "test.txt") == C:\Some\SafeDir\anotherDir\test.txt Path.Combine("C:\Some\SafeDir\", "C:\Windows") == C:\Windows Path.Combine("C:\Some\SafeDir\", "/Windows") == C:\Windows Thanks assholes. The documentation even says if param2 starts with a root path param2 is what is returned, peroid. Someone actually made the design choice that this behavior was good and perfectly fine. Looks like it's actually been this way a long long time, since .Net 1.1: https://msdn.microsoft.com/en-us/library/fyy7a5kt(v=vs.71).aspx
|
# ? Mar 26, 2017 04:22 |