Aha! I knew I had some Ruby stuff around somewhere. Here's a Ruby Markov chain. It's pretty compact though, I don't know how far along you are with data structures and stuff.
Is there really no way to find out if an eventListener exists already in Javascript? I have a bit of code that adds an eventListener to the window, but if the page is navigated around then the thing gets added more than once and fired more than once.
I know you can do getEventListeners() in chrome console, but I need a way to do that in the code.
If you're the one adding it then just make sure it only gets added once? Put an actual condition on it, or go to ref counting if you need to sometimes remove it.
Is there really no way to find out if an eventListener exists already in Javascript? I have a bit of code that adds an eventListener to the window, but if the page is navigated around then the thing gets added more than once and fired more than once.
I know you can do getEventListeners() in chrome console, but I need a way to do that in the code.
If you're the one adding it then just make sure it only gets added once? Put an actual condition on it, or go to ref counting if you need to sometimes remove it.
Yeah that's what I ended up doing. Seems a little crazy that I can't count the number of eventListeners on the window or element.
Is there really no way to find out if an eventListener exists already in Javascript? I have a bit of code that adds an eventListener to the window, but if the page is navigated around then the thing gets added more than once and fired more than once.
I know you can do getEventListeners() in chrome console, but I need a way to do that in the code.
If you're the one adding it then just make sure it only gets added once? Put an actual condition on it, or go to ref counting if you need to sometimes remove it.
Yeah that's what I ended up doing. Seems a little crazy that I can't count the number of eventListeners on the window or element.
That's an implementation detail that you really shouldn't be mucking with, though.
As Saeris says, you probably had an issue only because you were defining the function every time, instead of having one function value and then adding that as a listener each time (which should be a no-op then).
When dealing with listeners, define the function once so you can keep track of it, adding it without duplication and also being able to remove it if you wished.
If it's for some reason tied to say a button, and you need to attach something to the window for it, but you don't want it always around but only when you mount the button, then you gotta be careful and use ref counting. Start the counter at 0 as a component class level var, so that when you mount an instance you increase it by 1, and when you unmount you decrease it by 1. When it goes from 0 to 1, addEventListener, and when it goes from 1 to 0, removeEventListener.
The reason you can't just add/remove on mount/unmount is that you could have mount of instance A, it adds, mount instance B, it adds, now unmount instance A and leave B. Unmount on A will remove the listener, but B still needs it.
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
You shouldn't look for idiomatic answer there, main concern is use case. There is no point to pass explicit reference unless you need to modify the argument or have a HUUUUUUUUUGE struct(even then I'd say rather not).
Your instinct is correct, you very rarely want to allow mutability of method arguments and in general it would be a symptom rather than a solution.
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
You shouldn't look for idiomatic answer there, main concern is use case. There is no point to pass explicit reference unless you need to modify the argument or have a HUUUUUUUUUGE struct(even then I'd say rather not).
Your instinct is correct, you very rarely want to allow mutability of method arguments and in general it would be a symptom rather than a solution.
Hm, ok. So I should generally prefer the behavior of the Bar struct over the BarWithPointer (from the link above) and just be ok with the fact that the Foo object on my bar instance will not actually be the one I passed into the setter, it will just have the same values, and likewise with the getter - I'll get back a Bar with the same values, but not the actual same object.
All of this is very interesting to me. I love learning how to really use a language and learn how it works and how people expect it to work inside and out. Go's point of convergence for OOP, FP, old school C, C++, and Python makes for some very interesting choices and options to me.
I think that specific point would hold true in any modern language, not just Go. We've come to terms that the price to pay for immutability guarantees is worth paying 99% of the time, so anything you can do to make your code easier to reason about and your data safer is a plus.
I think that specific point would hold true in any modern language, not just Go. We've come to terms that the price to pay for immutability guarantees is worth paying 99% of the time, so anything you can do to make your code easier to reason about and your data safer is a plus.
Yeah, makes sense. Coming from an OO heavy background - tons of Python, years of Perl before that, the old Java heavy CS curriculum, etc. while I have a love and appreciation for FP stuff, it's pretty deeply ingrained in my assumptions these days that if it's not a simple data type then it's a reference/pointer.
Very cool to see that go is taking a different approach and while you can code in that very traditional OO way, handling everything by value is generally going to be preferred. I'll have to go look at my real code now to make sure I'm doing that. I flip flopped several times... forgot where I landed on it.
Next up for me is restructuring for better testing. My first whack at go stuff was very pythonic and while it worked generally for the simplicity of what I was doing, it still falls apart at tests due to lack of monkey patching to handle stuff like intercepting http requests. I'm really enjoying figuring all of this stuff out. I love working with new (to me) languages which do things differently.
I have 1-n tabs in a CollectionView, dynamically generated by content retrieved from a server. Think "sections", but their names and contents are arbitrary from my POV.
What strategy would you think is best for applying identifiers? I can't name them "a thing specifically", since I don't know what they are at any given point, and I don't know how many there are either, so this is dynamically generated for sure. I can't name them based on the values received, since the IDs are what I use to target an element in a test, and thus I kind of need to know the name of it ahead of time.
Section1, Section2, etcetc? Something I'm not thinking of?
Edit: Suggesting a mock will just make me cry. I know. TRUST me I know. That doesn't get what's "wanted" in this case, and can't be done without reasonably-significant rewrite of the host app. (I do not live "inside" the app sandbox; no access to internals, so everything would need to be via launch arguments, environment variables, etc. Not 'cause the dudes who made it are doofuses. They ain't.)
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
Using value semantics is almost always better even when you think it might not be. As zeeny says, immutability is winning.
It's also important to note that even in cases where it seems like there'd be a performance advantage to passing a struct by reference, you should probably resist the temptation. A decent compiler will handle it for you. If a function takes a struct argument that's so big that passing it on the stack is a performance win, the compiler should just generate the function such that the struct argument really gets passed as a const reference.
Likewise, passing structs by reference precludes some possible optimizations. Compilers can splat the contents of a struct value across one or more registers (even SIMD registers in some cases). That won't happen, though, if the callee utilizes a struct argument by reference. A reference is really just an address and to have an address, a value has to actually be somewhere in memory.
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
Using value semantics is almost always better even when you think it might not be. As zeeny says, immutability is winning.
It's also important to note that even in cases where it seems like there'd be a performance advantage to passing a struct by reference, you should probably resist the temptation. A decent compiler will handle it for you. If a function takes a struct argument that's so big that passing it on the stack is a performance win, the compiler should just generate the function such that the struct argument really gets passed as a const reference.
Likewise, passing structs by reference precludes some possible optimizations. Compilers can splat the contents of a struct value across one or more registers (even SIMD registers in some cases). That won't happen, though, if the callee utilizes a struct argument by reference. A reference is really just an address and to have an address, a value has to actually be somewhere in memory.
Just to confirm, the go compiler is one of those "decent compilers" and does hidden optimizations on pass by value, I just didn't feel we should be going there and tried to handle the question in a more general way, but you are absolutely correct and way more detailed than my response.
Edit: Things are slightly more interesting if we consider passing values on channels(and between goroutines), then there are actual optimization possibilities.
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
Using value semantics is almost always better even when you think it might not be. As zeeny says, immutability is winning.
It's also important to note that even in cases where it seems like there'd be a performance advantage to passing a struct by reference, you should probably resist the temptation. A decent compiler will handle it for you. If a function takes a struct argument that's so big that passing it on the stack is a performance win, the compiler should just generate the function such that the struct argument really gets passed as a const reference.
Likewise, passing structs by reference precludes some possible optimizations. Compilers can splat the contents of a struct value across one or more registers (even SIMD registers in some cases). That won't happen, though, if the callee utilizes a struct argument by reference. A reference is really just an address and to have an address, a value has to actually be somewhere in memory.
By the same logic though, a decent compiler may very well be able to detect non-modification and pass a referenced struct in registers if that actually improves anything
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
Using value semantics is almost always better even when you think it might not be. As zeeny says, immutability is winning.
It's also important to note that even in cases where it seems like there'd be a performance advantage to passing a struct by reference, you should probably resist the temptation. A decent compiler will handle it for you. If a function takes a struct argument that's so big that passing it on the stack is a performance win, the compiler should just generate the function such that the struct argument really gets passed as a const reference.
Likewise, passing structs by reference precludes some possible optimizations. Compilers can splat the contents of a struct value across one or more registers (even SIMD registers in some cases). That won't happen, though, if the callee utilizes a struct argument by reference. A reference is really just an address and to have an address, a value has to actually be somewhere in memory.
By the same logic though, a decent compiler may very well be able to detect non-modification and pass a referenced struct in registers if that actually improves anything
This is indeed true. TIL it's an optimization technique known as argument promotion.
And for C/C++, at least, I was wrong about the compiler optimizing big struct values to be passed by reference. Apparently, there are a lot of semantic gotchas and not necessarily a clear performance advantage to doing so. I was thinking about how large return values can be optimized and assumed the same logic could be applied to arguments as well.
Ok go people, is there a generally idiomatic, preferred way of doing this? Just a struct where one of the members is another struct (not struct embedding). Is it preferred to take the stereotypical OO approach on this and have the member struct be accessed and passed around as a pointer/reference or would it generally be expected to take a more functional approach and be passing that around by value?
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
Using value semantics is almost always better even when you think it might not be. As zeeny says, immutability is winning.
It's also important to note that even in cases where it seems like there'd be a performance advantage to passing a struct by reference, you should probably resist the temptation. A decent compiler will handle it for you. If a function takes a struct argument that's so big that passing it on the stack is a performance win, the compiler should just generate the function such that the struct argument really gets passed as a const reference.
Likewise, passing structs by reference precludes some possible optimizations. Compilers can splat the contents of a struct value across one or more registers (even SIMD registers in some cases). That won't happen, though, if the callee utilizes a struct argument by reference. A reference is really just an address and to have an address, a value has to actually be somewhere in memory.
Just to confirm, the go compiler is one of those "decent compilers" and does hidden optimizations on pass by value, I just didn't feel we should be going there and tried to handle the question in a more general way, but you are absolutely correct and way more detailed than my response.
Edit: Things are slightly more interesting if we consider passing values on channels(and between goroutines), then there are actual optimization possibilities.
Oh, I appreciate it. Those are the sorts of things I like to know. Writing code that works is easy. The interesting stuff comes from truly understanding a language and how its works internally.
it still falls apart at tests due to lack of monkey patching to handle stuff like intercepting http requests.
There's the net/http/httptest package that's neat.
There's a billion ways to test requests, but this is how I do it. This is just a simple test to check that a /status page exists.
func (s *HandlerSuite) TestStatusPage() {
request := httptest.NewRequest(http.MethodGet, "/status", nil)
writer := httptest.NewRecorder()
s.endpoint.Router.ServeHTTP(writer, request)
actual := writer.Result()
assert.Equal(s.T(), http.StatusOK, actual.StatusCode, "should return Status OK")
}
the s.endpoint.Router is a gorilla/mux router, but it implements the standard http handler interface. I use Testify for its suite/assert packages.
The nil on the httptest.NewRequest is where the reader for the body would go if you're doing a POST.
I've looked at httptest. Definitely useful, but I still need to structure things a bit different. For instance what got me in this case was a testing method on a struct, which calls a function, which then calls an external API. In go what I need to do is pass the url, or a client with a configured base url or whatever, into that method so that an httptest server can handle it and return a response instead. And then really, at some point, I'll be writing a test for the function which calls the method I'm currently testing... it seems a bit far aways to be worrying about dependency injection and doing dependency injection for every single function called, just so that I can easily write tests, does not seem like the correct answer.
Passing in a dependency to make that http request into Foo() feels wrong and obj does not really need to be injected into Foo() for any reason other than writing the test case.
In python I would use some combination of mock and HTTPretty or Responses. Mock is used to monkey patch any old method or function, so when I'm too far out I can easily monkey patch somewhere inside to just never make the http call and just return what I expect earlier. HTTPretty and Responses are libraries which specifically monkey patch the various http clients in python, so you just tell give them a url regex, a request type, etc. and when the http client sees those it returns your preconfigured response. No need to worry about dependency injection unless it's useful to the actual application outside of writing test cases. Plus it even works if it's a 3rd party lib which I cannot (or do not) want to change and doesn't allow me to configure the url in any manner, etc.
It's no big deal, in the end it will be a good thing. It just takes thinking about my program structure a bit differently and will take a few whacks at it until I get it right and some extra time cleaning up after myself until it becomes habit.
Launched my new system into production this week, which is a field services program... think "Salesforce Lite". Central database server, two-way communication with remote handhelds (iPads)
high data yields in both directions, multiple megabytes per communication in some cases
The big trick in this kind of system is fault tolerance. In other words, when the iPad inevitably fucks up (bad cell coverage, crash during sync, thrown into a moat of alligators, etc), how do you
A) Prevent database corruption Make the iPad attempt to self heal indefinitely
C) Given B, conserve data use as much as possible both locally and over the network... in other words, I can't just clone the database to iPad, I have to be clever about what the iPad knows at any given time, because I'm trying to hit a certain sync time target on undefined network conditions
I basically white boarded this entire process, and with limited budget and as the only full time employee of my company, could not test any of my theories fully. Only the most basic lab staged conditions
First day of beta testing, no issues at all.
Second day, second to last operation, mysterious sync error, presenting itself in a way that even I didn't expect. Half of a block of data was sent, but not the other half. An hour ago it looked like a potential failure, and I started contemplating all of the insane code I was going to have to write to attempt a rescue of data which I theorized was not deleted, but potentially dis-associated from the rest of the data tree
30 minutes later, iPad returns to signal, immediately belches out all data, complete and intact
time for scotch
Jasconius on
+9
LuvTheMonkeyHigh Sierra SerenadeRegistered Userregular
Oh, I know they all have their methods but mongo has been pretty successful in the "eventual consistency" category for the teams I've worked with. Not a lot of love for dynamodb
I'm looking for advice on how to handle a table for inventory in an RDBMS (I use Postgres).
The company in question has over 5000 types of part numbers. There needs to be a table in the database that tracks how much inventory is currently available. New inventory arrives on a regular basis and must be added to the table.
Should I keep an individual row per unit of inventory, or should I be storing summarized data? (i.e. A row with a quantity of 5, versus 5 individual rows).
Summarizing the data yields a smaller table, but I feel keeping the grain of the table down to 1 row = 1 unit of inventory might allow for easier manipulation later using aggregation or other analysis functions. It would also keep the option to distinguish an individual piece of inventory though I'm not sure why I would need to do that since inventory is fungible. I've also heard bad things about pre-summarizing data.
You're mixing inventory with stock. You have 5000 items of inventory with X many in stock
The way we did it at my old e-commerce company was we created records in a virtual stock table, linked to the inventory through FK, when stock was booked into the warehouse. It would have a bitmask flag set to "available". As it was added to an order and parts allocation ran it would be assigned to a specific order. As it was picked it would then be marked as "left the building".
Available stock counts were simple queries against the virtual stock table, and everything was linked back to orders so you could see exactly where things were going. As you said, stock is fungible so you don't want to know exactly what piece was assigned to which orders just that you have X many and in the past you have sold Y.
The one about the fucking space hairdresser and the cowboy. He's got a tinfoil pal and a pedal bin
Really depends on the quantities involved. Getting thousands of bearings at a time? Summarized. Specific stock of parts with serial or batch numbers? Individual rows. It really all depends on the kind of metrics you want available. Single rows will ultimately allow for way more stock analysis, and summary views would be a snap to setup
0
GnomeTankWhat the what?Portland, OregonRegistered Userregular
You must be playing in the whale league, since Amazon, Twitter, Facebook, Netflix and Google all use flavors of NoSQL database for their highest traffic systems.
I've said it before: nosql is the "I think I have schemaless data but really I don't know what my schema is" of databases in 90% of situations I've seen.
There are some specific exceptions (graph databases have some pretty interesting use cases, and some people really do have high volume data that they don't care very much about), but I think if you find yourself wanting something like Mongo you're best off thinking real hard about your dataset. Also, if what you want is a key value store, maybe give postgres a thought.
So I can steal my neighbor's wifi, but my own is pwned. Sweet.
I know that was a joke, but this attack doesn't allow an attacker to steal keys or authenticate, just listen in and modify, so you can't steal your neighbor's wifi.
Posts
I'd favor moving the `addEventListener` call to somewhere that it'll only run once. But, if you can't do that, you could instead just declare the event listener function a single time. Then, calls to `addEventListener` with the same function will be silently ignored, per the spec: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#Multiple_identical_event_listeners
Yeah that's what I ended up doing. Seems a little crazy that I can't count the number of eventListeners on the window or element.
That's an implementation detail that you really shouldn't be mucking with, though.
As Saeris says, you probably had an issue only because you were defining the function every time, instead of having one function value and then adding that as a listener each time (which should be a no-op then).
When dealing with listeners, define the function once so you can keep track of it, adding it without duplication and also being able to remove it if you wished.
If it's for some reason tied to say a button, and you need to attach something to the window for it, but you don't want it always around but only when you mount the button, then you gotta be careful and use ref counting. Start the counter at 0 as a component class level var, so that when you mount an instance you increase it by 1, and when you unmount you decrease it by 1. When it goes from 0 to 1, addEventListener, and when it goes from 1 to 0, removeEventListener.
The reason you can't just add/remove on mount/unmount is that you could have mount of instance A, it adds, mount instance B, it adds, now unmount instance A and leave B. Unmount on A will remove the listener, but B still needs it.
Coming from an OO heavy background the former feels more correct and more likely to be what is wanted most of the time. Does that perhaps change depending on if you are using getters and setters vs just exposing the members? The non-pointer version feels weird, particularly in getting a new, different struct back from the getter. If you are just exposing the members then the pointer feels like it just overcomplicates things as you can easily just get a pointer to it if you need already.
https://play.golang.org/p/BZm203SBH1
Watch the output... "Wait a second..."
Intermittent failure? Intermittent bug! Neener neener I was right!
You shouldn't look for idiomatic answer there, main concern is use case. There is no point to pass explicit reference unless you need to modify the argument or have a HUUUUUUUUUGE struct(even then I'd say rather not).
Your instinct is correct, you very rarely want to allow mutability of method arguments and in general it would be a symptom rather than a solution.
Hm, ok. So I should generally prefer the behavior of the Bar struct over the BarWithPointer (from the link above) and just be ok with the fact that the Foo object on my bar instance will not actually be the one I passed into the setter, it will just have the same values, and likewise with the getter - I'll get back a Bar with the same values, but not the actual same object.
All of this is very interesting to me. I love learning how to really use a language and learn how it works and how people expect it to work inside and out. Go's point of convergence for OOP, FP, old school C, C++, and Python makes for some very interesting choices and options to me.
Yeah, makes sense. Coming from an OO heavy background - tons of Python, years of Perl before that, the old Java heavy CS curriculum, etc. while I have a love and appreciation for FP stuff, it's pretty deeply ingrained in my assumptions these days that if it's not a simple data type then it's a reference/pointer.
Very cool to see that go is taking a different approach and while you can code in that very traditional OO way, handling everything by value is generally going to be preferred. I'll have to go look at my real code now to make sure I'm doing that. I flip flopped several times... forgot where I landed on it.
Next up for me is restructuring for better testing. My first whack at go stuff was very pythonic and while it worked generally for the simplicity of what I was doing, it still falls apart at tests due to lack of monkey patching to handle stuff like intercepting http requests. I'm really enjoying figuring all of this stuff out. I love working with new (to me) languages which do things differently.
I have 1-n tabs in a CollectionView, dynamically generated by content retrieved from a server. Think "sections", but their names and contents are arbitrary from my POV.
What strategy would you think is best for applying identifiers? I can't name them "a thing specifically", since I don't know what they are at any given point, and I don't know how many there are either, so this is dynamically generated for sure. I can't name them based on the values received, since the IDs are what I use to target an element in a test, and thus I kind of need to know the name of it ahead of time.
Section1, Section2, etcetc? Something I'm not thinking of?
Edit: Suggesting a mock will just make me cry. I know. TRUST me I know. That doesn't get what's "wanted" in this case, and can't be done without reasonably-significant rewrite of the host app. (I do not live "inside" the app sandbox; no access to internals, so everything would need to be via launch arguments, environment variables, etc. Not 'cause the dudes who made it are doofuses. They ain't.)
There's the net/http/httptest package that's neat.
There's a billion ways to test requests, but this is how I do it. This is just a simple test to check that a /status page exists.
func (s *HandlerSuite) TestStatusPage() { request := httptest.NewRequest(http.MethodGet, "/status", nil) writer := httptest.NewRecorder() s.endpoint.Router.ServeHTTP(writer, request) actual := writer.Result() assert.Equal(s.T(), http.StatusOK, actual.StatusCode, "should return Status OK") }the s.endpoint.Router is a gorilla/mux router, but it implements the standard http handler interface. I use Testify for its suite/assert packages.
The nil on the httptest.NewRequest is where the reader for the body would go if you're doing a POST.
Using value semantics is almost always better even when you think it might not be. As zeeny says, immutability is winning.
It's also important to note that even in cases where it seems like there'd be a performance advantage to passing a struct by reference, you should probably resist the temptation. A decent compiler will handle it for you. If a function takes a struct argument that's so big that passing it on the stack is a performance win, the compiler should just generate the function such that the struct argument really gets passed as a const reference.
Likewise, passing structs by reference precludes some possible optimizations. Compilers can splat the contents of a struct value across one or more registers (even SIMD registers in some cases). That won't happen, though, if the callee utilizes a struct argument by reference. A reference is really just an address and to have an address, a value has to actually be somewhere in memory.
Just to confirm, the go compiler is one of those "decent compilers" and does hidden optimizations on pass by value, I just didn't feel we should be going there and tried to handle the question in a more general way, but you are absolutely correct and way more detailed than my response.
Edit: Things are slightly more interesting if we consider passing values on channels(and between goroutines), then there are actual optimization possibilities.
By the same logic though, a decent compiler may very well be able to detect non-modification and pass a referenced struct in registers if that actually improves anything
This is indeed true. TIL it's an optimization technique known as argument promotion.
And for C/C++, at least, I was wrong about the compiler optimizing big struct values to be passed by reference. Apparently, there are a lot of semantic gotchas and not necessarily a clear performance advantage to doing so. I was thinking about how large return values can be optimized and assumed the same logic could be applied to arguments as well.
Oh, I appreciate it. Those are the sorts of things I like to know. Writing code that works is easy. The interesting stuff comes from truly understanding a language and how its works internally.
I've looked at httptest. Definitely useful, but I still need to structure things a bit different. For instance what got me in this case was a testing method on a struct, which calls a function, which then calls an external API. In go what I need to do is pass the url, or a client with a configured base url or whatever, into that method so that an httptest server can handle it and return a response instead. And then really, at some point, I'll be writing a test for the function which calls the method I'm currently testing... it seems a bit far aways to be worrying about dependency injection and doing dependency injection for every single function called, just so that I can easily write tests, does not seem like the correct answer.
ie. TestingCaseForFoo() -> Foo() -> calls obj.SomeMethod() ->calls AnotherFunc() -> makes http request
Passing in a dependency to make that http request into Foo() feels wrong and obj does not really need to be injected into Foo() for any reason other than writing the test case.
In python I would use some combination of mock and HTTPretty or Responses. Mock is used to monkey patch any old method or function, so when I'm too far out I can easily monkey patch somewhere inside to just never make the http call and just return what I expect earlier. HTTPretty and Responses are libraries which specifically monkey patch the various http clients in python, so you just tell give them a url regex, a request type, etc. and when the http client sees those it returns your preconfigured response. No need to worry about dependency injection unless it's useful to the actual application outside of writing test cases. Plus it even works if it's a 3rd party lib which I cannot (or do not) want to change and doesn't allow me to configure the url in any manner, etc.
It's no big deal, in the end it will be a good thing. It just takes thinking about my program structure a bit differently and will take a few whacks at it until I get it right and some extra time cleaning up after myself until it becomes habit.
Other, more special times, when you try to alter an element's property, you crash the entire IDE.
Launched my new system into production this week, which is a field services program... think "Salesforce Lite". Central database server, two-way communication with remote handhelds (iPads)
high data yields in both directions, multiple megabytes per communication in some cases
The big trick in this kind of system is fault tolerance. In other words, when the iPad inevitably fucks up (bad cell coverage, crash during sync, thrown into a moat of alligators, etc), how do you
A) Prevent database corruption
C) Given B, conserve data use as much as possible both locally and over the network... in other words, I can't just clone the database to iPad, I have to be clever about what the iPad knows at any given time, because I'm trying to hit a certain sync time target on undefined network conditions
I basically white boarded this entire process, and with limited budget and as the only full time employee of my company, could not test any of my theories fully. Only the most basic lab staged conditions
First day of beta testing, no issues at all.
Second day, second to last operation, mysterious sync error, presenting itself in a way that even I didn't expect. Half of a block of data was sent, but not the other half. An hour ago it looked like a potential failure, and I started contemplating all of the insane code I was going to have to write to attempt a rescue of data which I theorized was not deleted, but potentially dis-associated from the rest of the data tree
30 minutes later, iPad returns to signal, immediately belches out all data, complete and intact
time for scotch
yeah basically. anyone who drives a truck and turns a wrench
I play in the big leagues
Most of the NoSQL is not similar to Mongo, but way better. Go figure!
The company in question has over 5000 types of part numbers. There needs to be a table in the database that tracks how much inventory is currently available. New inventory arrives on a regular basis and must be added to the table.
Should I keep an individual row per unit of inventory, or should I be storing summarized data? (i.e. A row with a quantity of 5, versus 5 individual rows).
Summarizing the data yields a smaller table, but I feel keeping the grain of the table down to 1 row = 1 unit of inventory might allow for easier manipulation later using aggregation or other analysis functions. It would also keep the option to distinguish an individual piece of inventory though I'm not sure why I would need to do that since inventory is fungible. I've also heard bad things about pre-summarizing data.
The way we did it at my old e-commerce company was we created records in a virtual stock table, linked to the inventory through FK, when stock was booked into the warehouse. It would have a bitmask flag set to "available". As it was added to an order and parts allocation ran it would be assigned to a specific order. As it was picked it would then be marked as "left the building".
Available stock counts were simple queries against the virtual stock table, and everything was linked back to orders so you could see exactly where things were going. As you said, stock is fungible so you don't want to know exactly what piece was assigned to which orders just that you have X many and in the past you have sold Y.
You must be playing in the whale league, since Amazon, Twitter, Facebook, Netflix and Google all use flavors of NoSQL database for their highest traffic systems.
I think a lot of people try to use NoSQL as a relational database and that's not really a great way to do it.
Most other NoSQL is sensible.
There are some specific exceptions (graph databases have some pretty interesting use cases, and some people really do have high volume data that they don't care very much about), but I think if you find yourself wanting something like Mongo you're best off thinking real hard about your dataset. Also, if what you want is a key value store, maybe give postgres a thought.
So now this service will totally attempt to recreate its queue in the burning ruins of whatever annihilated RabbitMQ.
So I can steal my neighbor's wifi, but my own is pwned. Sweet.
I know that was a joke, but this attack doesn't allow an attacker to steal keys or authenticate, just listen in and modify, so you can't steal your neighbor's wifi.
only if you have unlimited capital and a legion of PhD level computer scientists to prop it up and keep it patched though