MononcQc posted:

That's IEEE Standard 754 on floating points.

±∞ × 0 => NaN
±nonZero ÷ ±0 => ±∞

Not a javascript horror.

eschaton posted:

because you're not a loving idiot, that's why you want a normalized relational database

also at least some common "NoSQL" implementations turn out to be isomorphic to the relational algebra anyway, especially as used, just with worse performance and no ACID guarantees that a real relational database (even SQLite) can provide

there was a proof 5-6 years ago that I can't find now but I recall it being pretty straightforward

CRIP EATIN BREAD posted:

it also depended on weird compiler/linker behavior such as allowing duplicate symbols to be linked together (and randomly picking one of them to use in the compilation unit).

instead of making a library it just linked .o files in at random from all over the project or just copy/pasted functions randomly into other files.

GrumpyDoctor posted:

i have a terrible programmer question about testing (in c#). i am writing a plugin for other software. every api i interact with uses concrete objects. how do i fake objects for testing? for example, say i've got
a FiddleWithHostDocument(HostDocument doc) method, and i want to make sure that when it runs, it sets the HostDocument.IsModified flag on the document it's passed. i can't just mock out HostDocument, because it's sealed. the only thing i was able to think of (other than using one of those mocking frameworks that rewrites IL or whatever) was, for each host api class i care about, to create a corresponding wrapper interface and concrete implementation that forwards interface calls to wrapped actual host objects, and then have my logic only interact with the interfaces, but

GrumpyDoctor posted:

i have a terrible programmer question about testing (in c#). i am writing a plugin for other software. every api i interact with uses concrete objects. how do i fake objects for testing? for example, say i've got
a FiddleWithHostDocument(HostDocument doc) method, and i want to make sure that when it runs, it sets the HostDocument.IsModified flag on the document it's passed. i can't just mock out HostDocument, because it's sealed. the only thing i was able to think of (other than using one of those mocking frameworks that rewrites IL or whatever) was, for each host api class i care about, to create a corresponding wrapper interface and concrete implementation that forwards interface calls to wrapped actual host objects, and then have my logic only interact with the interfaces, but

GrumpyDoctor posted:

i have a terrible programmer question about testing (in c#). i am writing a plugin for other software. every api i interact with uses concrete objects. how do i fake objects for testing? for example, say i've got
a FiddleWithHostDocument(HostDocument doc) method, and i want to make sure that when it runs, it sets the HostDocument.IsModified flag on the document it's passed. i can't just mock out HostDocument, because it's sealed. the only thing i was able to think of (other than using one of those mocking frameworks that rewrites IL or whatever) was, for each host api class i care about, to create a corresponding wrapper interface and concrete implementation that forwards interface calls to wrapped actual host objects, and then have my logic only interact with the interfaces, but

Progressive JPEG posted:

i just know the java side of things but it looks like theres a couple mocking frameworks thatll let you mock sealed classes via some clr hooks so just use one of those imo

Progressive JPEG posted:

unit tests are v useful for making it apparent how your code could be structured differently (if only to make the tests feasible), but writing new code/hooks solely for tests to use is bad imo

AWWNAW posted:

the only lib I've used for this is Moq but there are some others like RhinoMocks

BiohazrD posted:

I'm curious as to what software this is

GrumpyDoctor posted:

ugh i was hoping this wasn't the answer


while this sounds great on paper i'm really unsatisfied with declaring all code that interacts with the host api fundamentally un-unit-testable and calling it a day


neither of those (nor nsubstitute, which i'm using right now) can mock non-virtual or -interface methods


rhinoceros 3d

the plugin api is largely sane and easy to work with, but it's clearly designed only to accomodate non-programmers. (i asked all their forums about why all of their api objects were IDisposable if none of their sample code actually treated them this way, and in response i got a link to the msdn page for IDisposable)

KidDynamite posted:

where can i learn more about schema-less databases? boss wants me to have real reason for wanting a normalized relational db even though we we need to emulate relationships in a schema-less db. i think he's pushing me to my limits and trying to make me learn some poo poo rather that just letting me get away with saying schema-less is bad so i can grow as a dev. i really appreciate it and don't want to let him down. also i would like to get to coding so the quicker all this poo poo is taken care off the better.

GrumpyDoctor posted:

ugh i was hoping this wasn't the answer


while this sounds great on paper i'm really unsatisfied with declaring all code that interacts with the host api fundamentally un-unit-testable and calling it a day


neither of those (nor nsubstitute, which i'm using right now) can mock non-virtual or -interface methods


rhinoceros 3d

the plugin api is largely sane and easy to work with, but it's clearly designed only to accomodate non-programmers. (i asked all their forums about why all of their api objects were IDisposable if none of their sample code actually treated them this way, and in response i got a link to the msdn page for IDisposable)

Finster Dexter posted:

you workin on some Rhino stuff? I have a personal project that my wife wants me to do involving calling some grasshopper components via c# code. I guess that's not Rhino, per se, but in my initial research the grasshopper components seem relatively sane to call from C#, despite some wackiness in providing input params to the component.

CRIP EATIN BREAD posted:

you failed the minute you used javascript

Arcsech posted:

first off, lets clarify some terms. non-relational databases are not synonymous with schemaless. they often overlap, but they arent the same - you can easily have a schema on a non-relational data store.

third, read about a few major non-relational databases in different categories: cassandra, neo4j, redis, and mongo. read about what use cases these are optimized for, and think about how those are different than what you'd be able to do easily in a relational database. some of them are optimized for speed at the cost of making your data and queries more structured, some for scaling out to multiple nodes, some for specific types of querying, and some for ease of use (generally for people who think sql is too hard). they provide different guarantees - for this, it's useful to read about the CAP theorem and ACID

unless you need the speed, or your data fits a pattern with a specific type of database built specifically for it (like graph databases), relational databases have a lot of advantages, such as flexibility of querying, automatic handling of certain conditions (delete cascades, etc), and ACID guarantees. if your use case doesnt fit what a nosql database is optimized for, you'll probably end up spending a bunch of time poorly reimplementing relational database functionality over the top of whatever you pick

its more complicated than just "nosql bad", but a lot of people who think they need nosql databases would indeed be better served by just using postgres instead

Flat Daddy posted:

had a programming take home test: read a file with rows of create/update commands and execute them following some business logic

was told to code however i want and don't overengineer. i just map()'d over lines to parse into an intermediate format and then used a reduce() to go line by line and update state.

i failed because there wasn't enough OOP !!!! this was javascript!!! i should have used visitor pattern i guess

Flat Daddy posted:

there wasn't enough OOP

YeOldeButchere posted:

this is pretty accurate. relational databases should be your default when choosing a database. and if they don't fit the bill, usually because of performance, fault-tolerance or scalability issues, then you can start looking around for other stuff. i say this as someone who does like the options that the various nosql offerings bring to the table (well, some of them in any case). but i like being able to do "BEGIN TRANSACTION" followed by feeding the query planner some monstrous jumble of statements followed by "COMMIT" more than i like having to carefully reason about ordering key-value operations started by a bunch of processes that may fail at any time on a database that's also composed of processes that may fail at any time, all of this under a model where defining "any time" is a bit more complicated than it might seem at first

i'm also gonna have to second reading about a bunch of databases in different categories as being the best way to get a grip on this stuff. usually that means looking at the documentation for a particular db and especially the "data model" section or whatever they've named the part where they tell you what the hell that thing is all about. looking at the api itself isn't particularly useful i've found. you're not going to do well in the nosql world if you don't like reading documentation and just want to write code

ironically enough, i think that the most useful thing for understanding nosql dbs for me was the book "readings in database systems (4th ed)". it's really a collection of historically significant or otherwise interesting journal articles and it was published in the mid-00s just before the nosql dbs started appearing, so it's pretty much 100% relational database stuff. but it made pretty clear to me the things that relational dbs provide, how they do that, and why that might sometimes get in your way and prompt you to look outside the relational world. it's also a good way to learn about db internals, which isn't a bad thing either if you're interested in that stuff and don't mind reading thick books

HoboMan posted:

u failed bcz u post here

This si breaking my brian:

code:

DateTime sunday = DateTime.Today.AddDays(Convert.ToDouble(0 - DateTime.Today.DayOfWeek));
 GotoDate.SelectedDate = sunday;
ShowSelectedDay((int)DateTime.Today.DayOfWeek);

Shaggar posted:

also a lot of the time when there poor performance in a relational db is bad design or missing indexes or sometimes bad query optimization and those things have varying levels of discoverability for new developers.

professor posted:

Imporant Note: your insertBefore method has a serious bug that broke our grading program.

AWWNAW posted:

no clue what the context is here but this might be clearer

code:

DateTime today = DateTime.Today
var daysSinceLastSunday = Convert.ToDouble(0 - today.DayOfWeek)
DateTime lastSunday = today.AddDays(numDaysTilSunday); // travel back in time to last sunday

GotoDate.SelectedDate = lastSunday;
ShowSelectedDay((int)today.DayOfWeek);

Flat Daddy posted:

...don't overengineer...

...there wasn't enough OOP...

MononcQc posted:

That's IEEE Standard 754 on floating points.

±∞ × 0 => NaN
±nonZero ÷ ±0 => ±∞

Not a javascript horror.

Bad Sneakers posted:

GrumpyDoctor posted:

lol what was the bug

Notorious QIG posted:

well then it's a loving stupid standard

BattleMaster posted:

maybe i just use C too much because i don't see what's wrong with null being 0

like maybe think about checking your pointers before you use them instead of using them and then checking the results, or not even checking and just hoping/praying it works