Reputation
729
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
3 9
Newest
 Student
Impact
~19k people reached

  • 0 posts edited
  • 1 helpful flag
  • 27 votes cast
2d
comment System for scheduling parallel tasks/callbacks
Thanks for the reply! My intent wasn't to even worry about keeping track of sub-second logic in such a system. I was trying to use an example of a larger event that might be timed in seconds, being able to somewhat intermix with longer-term events that might last minutes or hours. I agree that having separate queues to keep track of the different granularities makes sense.
2d
awarded  Student
May
3
revised System for scheduling parallel tasks/callbacks
added 582 characters in body; edited title
May
3
awarded  Informed
May
3
comment System for scheduling parallel tasks/callbacks
Also, let me know if this is not the right place for this, or if my question is written poorly. Just down voting isn't going to help me out here ;) I know way more about SO than I do about this site.
May
3
revised System for scheduling parallel tasks/callbacks
added 12 characters in body
May
3
comment System for scheduling parallel tasks/callbacks
@RubberDuck Looking quickly at the SignalR page, it looks like it solves the push notifications, but I'm not sure if it does much to solve the timed workflow part of the job. The timed workflow part is what I'm most interested in solving, and the pipe to RPC back to the client is less important to me. That page mentions service bus, though that looks like a server-side messaging protocol to allow IPC between disconnected services, rather than a task/workflow scheduler.
May
3
asked System for scheduling parallel tasks/callbacks
Nov
17
comment How can I create Assert.AreEqual(myobject,somevariable) a test in TDD before writing production code?
I guess it's not so sarcastic after all. I must have felt snarky that day, even though looking back on it now I see nothing snarky. I've since then come across solutions involving use of the dynamic keyword and a factory function to return your class under test. This allows you to compile and run your test suite, even though methods or whole classes might be missing, and treat binding errors as runtime errors instead of compile time. This lets you write all the tests first, even before writing a single piece of code. There is a minor abstraction cost in your tests, so it is subject to taste.
Oct
28
awarded  Yearling
Mar
1
comment TDD - is it just about unit tests?
I think the intention of this post is correct, but I can see an outcome of the advice to be to test less ("your tests need to be written better"). This would not be ideal. I think the last paragraph deserves a little expansion. Testing internal behaviors is good. But maybe the OP's internal abstractions are poor/brittle and don't allow a refactor without major reshaping of the code. In such a case, throwing out the tests and writing new ones makes perfect sense. The old tests still provided value because they showed the internal code's behavior wasn't well defined/high level enough.
Mar
1
comment TDD - is it just about unit tests?
I'd be wary of relying too heavily on SQLite. Different DBs have different requirements and what works on one DB may break badly on another DB. Also, the more complex the object, the more mocking is likely to help reduce the brittleness of your unit tests, and increase your ability to understand them later. It sounds to me like you're assuming people will implement their own mocks. I'd suggest in most cases to use a mock object framework, and use a stateless or less stateful mocking style wherever possible.
Feb
3
revised Difference between Idiom and Design Pattern?
C++ templates aren't the template pattern.
Oct
28
awarded  Yearling
Jul
21
comment Should one check for null if he does not expect null?
@Kyralessa: I know how Nullable<T> works, and it does not solve the problem the way you think it does.
Jul
20
comment Should one check for null if he does not expect null?
@Kyralessa: Returning Nullable<T> doesn't solve the null ambiguity problem (did the parse fail or succeed? Was the contents of the string empty? Was the input null?). The TryParse idiom solves this, letting you know whether you have a working object or not. The logic to determine if the parse succeeded or not belongs in the parse method, not the method that uses the result of the parse. You're going to have to check if the parse succeeded anyhow, you might as well have that be returned out-of-band from the output.
May
21
comment Should one check for null if he does not expect null?
@Shahbaz: The clarification that you're talking about cases that give a silent failure when a null value is passed makes more sense. But your first Warcraft example seems to advocate that functionality (where no exception is thrown), and your second example seems to imply that throwing an exception would cause the problem. Your clarification in comments makes more sense. Maybe it would help if you edit the answer to clear up the confusion.
May
21
comment Should one check for null if he does not expect null?
@Shahbaz: The point is that "throw an exception" and "crash" should have identical behavior with respect to that transaction, and with respect to a re-submitted version of the transaction. If they don't identical behavior, then your transaction isn't atomic/idempotent enough.
May
21
comment Should one check for null if he does not expect null?
@Shahbaz: "Now crash in the beginning of transaction may not be bad, but in the middle can be catastrophic" - if this is true that this would be catastrophic, then you didn't design your transactional semantics correctly. A "crash" (exception being thrown) in the middle is exactly what you want to have happen, so the transaction will be rolled back and none of it will be committed. Checking for null and throwing your own exception should be identical to a null reference exception in this respect. It is a silent non-abort you need to avoid, so you should check for null, then throw.
May
21
comment Should one check for null if he does not expect null?
I'd go with failing fast and early even in production unless you can somehow log and report the error (without relying too much on savvy users). Hiding your deployed bugs from users is one thing - hiding them from yourself is dangerous. Also allowing the user to live with subtle bugs can erode their confidence in your application. Sometimes it is better to bite the bullet and let them know there was a bug and that you fixed it quickly.