|
Roku. Keep it simple.
Amazon.com: Roku
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Well, technically, you can use a desktop computer to cast to the Chromecast. It's just a pain if they're not close to each other.
I made the mistake of getting a Chromecast and setting up a Netflix subscription at the weekend. "I'll just test it out by watching the first episode of 'Stranger Things'." Eight episodes later...
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I think any one of these will do the job.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
|
When you are in a big team, and the code is subject to constant spec changes then well crafted, good performing, lean and mean code is subject to update to messy after thought trash code in the middle that progressively makes the whole code bloatier and slower.
Now little apart code review can be done against bloatier code. Hell when a developer that has no clue about the project get pulled in to quickly add a new feature in 2 hours or less (time is money you know) mess creep is to be expected...
However... At the very least the developer will make sure his code doesn't throw exception!
And now I came up with an idea on how to make sure that performance degradation doesn't creep in unexpectedly!
I wrap every must be quick code in a class TimeCriticalBlock : IDisposable which automatically break if code get slower than acceptable (creation parameter).
This way, if the code slow down more than acceptable... the developer got an automatic reminder by the system while debugging! 
Quite happy when I came up with that idea! 
modified 17-Jan-17 19:09pm.
|
|
|
|
|
What you really need is to provide every developer with an IoT device that measures their performance. Then management can sit back and watch the performance degrade as each new patch is made, all on a pretty web-socket / SignalR enabled realtime website. And while you're at it, the integrated build process can run Visual Studio's code analysis.
Degrading performance.
Increasing complexity.
Marc
|
|
|
|
|
Yes IoT SignalR powered performance metric is the way forward! 
Need more buzzwords though! 
|
|
|
|
|
Super Lloyd wrote: Need more buzzwords though!
How about "IoT data acquisition with real time distributed cloud big data document persistence and browser aware critical metrics for empowering performant management decision making."
Marc
|
|
|
|
|
You know what? I typed out an equally long buzzword phrase. But this just wins. I have failed you senpai  You should be in marketing if you aren't already (possibly amusing considering I did marketing for about 3.5 years).
|
|
|
|
|
Yup that should do it 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Exacerbating the debacle again Marc?
Software Zen: delete this;
|
|
|
|
|
Sounds interesting; I look forward to the article, and seeing how you do the timing.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
The article hey?
Might do a tips and trick! 
Meanwhile here are the relevant classes for your information:
public class TimedBlock : IDisposable
{
Stopwatch stopwatch;
public TimedBlock([CallerMemberName] string name = null)
{
Name = name;
stopwatch = new Stopwatch();
stopwatch.Start();
}
public string Name { get; set; }
public TimeSpan Elapsed { get { return stopwatch.Elapsed; } }
public virtual void Dispose()
{
stopwatch.Stop();
Trace.WriteLine($"TimedBlock({Name}, {Elapsed})");
}
}
public class TimeCriticalBlock : TimedBlock
{
TimeSpan max;
public TimeCriticalBlock(TimeSpan max, [CallerMemberName] string name = null)
: base(name)
{
this.max = max;
}
public override void Dispose()
{
base.Dispose();
if (Elapsed > max)
{
var msg = $"code too slow, {Name} took {Elapsed}.";
Trace.Error(msg);
#if DEBUG
if (Debugger.IsAttached)
Debugger.Break();
#endif
}
}
}
|
|
|
|
|
It might be a good idea to convert both of them into struct's to avoid allocation/GC for each call. This would remove the overhead almost completely (well, for `TimeCriticalBlock` at least, `TimedBlock` writes on each dispose).
Also (as others have pointed out), the overhead of writing to the console is also not negligible (it's surprisingly slow, not to mention multithreaded access when you start getting lock contention), using a logging library combined with baretail (or something) might be a better idea. More performant, configurable, able to store logs history for months. Also doesn't lose all logs in case of a crash.
modified 18-Jan-17 7:58am.
|
|
|
|
|
this is a good idea...
though generally speaking this overhead would be minimum compare to what it measure business process (with database access, business model, etc...)
|
|
|
|
|
Very interesting.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Thanks! 
Just posted a link to the very simple classes that do that right above!
The Lounge
|
|
|
|
|
I've seen stuff like that and I don't like it.
First of all, it obscures code.
It's really very annoying to have your code littered with new TimeCriticalBlock(something => { ...}) (or probably something like that).
Then comes logging, which is even more clutter.
I've seen code that was about 50% diagnostics... And the diagnostics usually didn't even matter (I've never needed it)!
Add to that that everything works fine in our own environment, but the customer refuses to invest in a decent server... So in production everything in twice as slow.
All those kinds of tests would pass in development and fail in production.
And the last thing I want when my code isn't up to speed anyway... Is for it to break as well! That's really adding insult to injury 
Perhaps it would be a nice idea if the code was inserted at compile time (code weaving?) and then stored metrics somewhere and gave the team a warning (email or something) when the code was slower than could be expected on production.
|
|
|
|
|
First the aesthetics aspect.
Apparently you would prefer some kind of (so called) aspect oriented programming over a simple using statement, why not, whatever rocks your boat man!
On a "where to put your effort kind of things" aspect is a well known .NET programming technique since at least 2003 (see Aspect-Oriented Programming ) which has failed to garner much of any success or enthusiasm since then... As far as I am concerned it is not even worth wasting time trying to use.
I understand your preferences are different, maybe use GitHub - Fody , seem to be easy to put into practice...
As for the rest why would you pass a callback in the constructor? I am curious as to what were you thinking?
For the record here is the implementation I am currently using:
The Lounge
Finally all those "tests" (more like debug time code break) are only meant to valid that your code is performant, as you can see on my implementation, whether it runs slow or not on production has little to no effect and is, in theory, completely irrelevant.
The idea is to attract and awake the developer attention, much like an exception would.
|
|
|
|
|
Ah, didn't see your implementation yet.
The using statement certainly makes it better than what I've seen, although using a callback means you can also log any input and output parameters (which is what the code I came across also did).
I'm not a fan of AOP, it caused me more trouble than added benefit.
I am curious though, why not put the timing in a unit test?
That way you can test your code for speed without actually touching your code, but your build will still break.
Of course you won't have the benefit of the log statement in production (but how often do you check that, really?).
|
|
|
|
|
In fact putting the speed test in a unit test would be a very good idea!
Unfortunately in the companies I have been working so far, unit test haven't been a very popular approach.
Not that they dislike them mind you!
More like they usually fall into disrepair... And on-going new revised specifications put a lot of pressure on maintaining existing ones.
I did write some for the low level utilities I created which are still valid (I am often the go to guy for low level utilities) but most of the few high level business model integration tests I have been writing so far have almost all been deprecated by too many model and specifications changes....
|
|
|
|
|
As for the logs... our acceptance server run as a console app for now, as we are constantly monitoring its output!
Granted there is way too much output, but it's still readable! 
Log are also in a file.. But it's easier to read in the console (just click on it) and easier to update the server (just stop, copy files, and restart)
|
|
|
|
|
Super Lloyd wrote: Log are also in a file.. But it's easier to read in the console (just click on it) and easier to update the server (just stop, copy files, and restart)
Under *nix there is the command tail and graphical or non graphical derivatives; under Windows there are similar utilities (my favourite is baretail). They allow you to "follow" files as they're written and the graphical utilities often have an integrated filtering system to automatically format strings that match a certain criteria (e.g you can put on red background all the strings containing the word "error").
CALL APOGEE, SAY AARDWOLF
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"Go ahead, make my day"
|
|
|
|
|
yeah tail is good..
but it's not like using the console here is a no brainer here! 
|
|
|
|
|
Sander Rossel wrote: The using statement certainly makes it better
Hi, Sandor,
I'm curious: I don't see any use of 'using in the code; are you referring to the use of the '#if DEBUG' compiler directive ?
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
