|
The pickup in the camera is not curved, therefore making the viewing screen curved can only introduce distortion into the image.
I have never seen a believable justification for curved screens.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
I have a Samsung 78JS9500 and I absolutely love it. This was the TV I wanted from a specs perspective and it only comes curved, so that's what I got. We have it set up so that the sofa is directly in front of it, and the oversized chair (where I normally plop down) is at approximately a 45-degree angle to it. There is no distortion or picture degradation whatsoever at that angle. Once you start watching it, after a few days you don't even realize there's a curve. This TV is simply amazing.
One thing to keep in mind about the JS-series (2015 models) vs the KS-series (2016 models)... the KS9500 is NOT the equivalent of the JS9500. The JS9500 is a fully backlit TV where the KS9500 is only edge backlit. You have to step up to the KS9800 to get a full backlight in the 2016 model. That's why I stuck with the JS9500 versus the KS series. Plus when I bought mine, the JS9500 was $6300 and the KS9800 was almost $10K.
|
|
|
|
|
Thanks,
I also note from the specs that the J/K appear to be the model year? and the S/U is SUHD and UHD.
I will have to have a more detailed look at the specs, but the Samsung SUHDs I have seen in the shops look absolutely stunning picture colour/depth/sharpness.
I haven't seen the price over here yet in Qatar for the xxKS9800, but the 78KS9500 is 40,000QR (~11KUSD), the 85JU7000 is the same price and the 78JU7500 is 23,000 (~6KUSD)
|
|
|
|
|
IMHO, the curved screen is a way to limit the physical viewing angle on a screen so that they can use a screen that was produced with reduced viewing angles. Kind of a "It's not a bug, it's a feature" kind of thing.
|
|
|
|
|
I own a 2015 65" Samsung SUHD Flat screen and am very happy with my purchase. I also looked at the curved screen and it didn't look right to me. Curved might be interesting once screens are much larger (over 100"-120"), something like IMAX. But even then mostly likely I would go with Flat still.
|
|
|
|
|
|
One thing I've noticed about the curved screen is that at least some part of it will have glare. I can generally arrange a flat screen such that light sources in the room will not have glare in my normal seating locations. The curved screen will always have some part of it that is at the correct angle for the lights or windows to glare off it. You can see this in the store displays too.
|
|
|
|
|
|
Hey guys. I've really been enjoying mobile and IoT development, but seeming as the only developer jobs in my area focus on Sharepoint, I figured I'd pick up Sharepoint development.
Does anyone have experience with developing for Sharepoint? Also, I'm not a big enterprise company and was wondering if there was a way I could get a free or cheap Sharepoint instance for development.
Also, is Sharepoint development a deadend field? Like will I not be able to get a job doing it in a few years
i cri evry tiem
modified 21-Oct-16 20:44pm.
|
|
|
|
|
|
Vincent Maverick Durano wrote: My Verdict On The Future of SharePoint[^] "Some of you may be getting fatigued and frustrated by all the changes, but I for one am actually excited about this one. The new approach is 100% JavaScript"
Aaaaarrrrgggghhhhhh!!!!!
<runs, screaming, for the hills>
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: The new approach is 100% JavaScript" Thank the great Ghu I don't work in the web stack, I'm the guy in mobility chair chasing you!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
That's happy making.
On the one occasion where I was dumb enough to volunteer to do JS support for our SharePoint, the system mysteriously gutted my script after a week of operation.
We'll see. Until it doesn't suck to work with as a dev I'll sit it out.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
It's a pretty damned sweet JavaScript API/SDK.
|
|
|
|
|
Wrong forum.
You're looking for this one[^] .
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The Office 365 dev program includes 5 installs of office, and a sharepoint instance.
Seems like you get the first year free currently (I'm paying something like a 100€/year for the privilege, which is about the price of an office license). Office Dev Center - Office 365 Developer Program[^]
Development is limited to the new "javascript only" model, and standard sharepoint functionality.
|
|
|
|
|
I work in the Microsoft Project Server space. Project Server is based upon SharePoint so alot of what I do is on SharePoint.
It can suck ALOT. But it isn't any worse than alot of other platforms.
I read the post about being javascript. Kinda, sort of. jQuery really which is js. But slightly better.
Can you setup a place to work. Sure Azure has some free online sharePoint things you can do. You can even install and setup your own farm. But that came with my MSDN so not sure how much that was. Company paid for it.
There aren't alot of people willing to put up with the pain. But then again it does pay the bills. Biggest future issue I see with Sharepoint is the whole move to completely cloud based systems. So you have no access to the servers at all. There have been quite a few times in our instance where SP just wouldn't suffice when you need to do something special so we had to write a .net Web app to run the application. IE more records than SP can handle(5000 doesn't take long to get over that) etc...
Pays the bills and should be around for another 10-15 years I think. But who knows.
To err is human to really mess up you need a computer
|
|
|
|
|
You need an Office 365 Developer account. SharePoint has paid my bills for almost a decade.
Idaho Edokpayi
|
|
|
|
|
I was doing SharePoint development in my last job (SP 2010 and SP 2013). The development environment consists of Visual Studio (2010 or 2013 or 2015), SQL Express (2012+) and SharePoint Foundation (2010 or 2013) (it's free).
Setting all this up correctly is no easy task. But you can find help for that online - e.g. Building the Ultimate SharePoint 2010 Development Environment[^]. SP 2013 setup is very similar.
I have no experience with SharePoint 2016 and I don't know how to setup development for that as MicroSoft is no longer offering the free Foundation for that version.
SharePoint will be with for a long time I think.
|
|
|
|
|
I believe being able to make the SharePoint "option" available makes one more valuable.
In the last couple of weeks I showed a professional accountant who thought he needed his own "cloud server" and a family law practitioner with a "hopeless" CMS how to address their "document management" needs using a basic SharePoint Online subscription (about $5 per month). Includes mobile access.
You may never need to "develop" in SharePoint, but knowing what comes out-of-the-box (and how to make use of it) can make it a strong alternative solution bid to any bespoke CMS. One can be up and running in literally hours; particularly for those already familiar with the concepts of "documents, lists and folders".
Being able to show the "little people" that they can play just as well as the "big corporations" via cloud services is a market that is yet to be exploited, IMO. Education.
|
|
|
|
|
SharePoint is the software from Microsoft and this will live very long live, now this is part of Office365 and there are a lot of companies who has on-prem SharePoint =)
|
|
|
|
|
I'm just now trying to adopt my thinking to Test Driven Development mode and I'm finding strange, inconsistent, and bizarre things happening in my thought processes and code in some ways as well. Is this pretty normal when you first try to learn TDD?
For example, I find myself writing a lot of tests and then realizing afterwards "Hey, that could/should have been broken down into 2 separate unit tests" or maybe vice-versa.
I'm not really sure what/if there is a gold-standard on how much a unit test should be broken down. Another thing is sometimes I question whether I am wasting my time on a specific test. So for example, say I have some simple code like this:
public class IntegerStats
{
public int MaxValue { get; private set; }
public int MinValue { get; private set; }
public int NumberOfElements { get; private set; }
public double AverageValue { get; private set; }
public IntegerStats(int[] inputArray)
{
MaxValue = inputArray.Max();
MinValue = inputArray.Min();
AverageValue = inputArray.Average();
NumberOfElements = inputArray.Length;
}
}
My first two unit tests look like this:
[Test]
public void ProvideArrayReturnsIntStatsObject()
{
int[] testArray = {1, 5, 254783, 98, 4793, 67};
IntegerStats intStats = new IntegerStats(testArray);
Assert.IsTrue(intStats.GetType().ToString().Contains("IntegerStats"));
}
[Test]
public void Length5ArrayLengthIs5()
{
var result = new IntegerStats(new int[]{5,4,8,9,4});
Assert.AreEqual(result.NumberOfElements,5);
}
However, should I be passing multiple arrays in to this one test or should I make several array length tests of different lengths? How do I know if the method is adequately tested?
My next plans were to continue testing the other properties... But then I was questioning whether I should even be testing these methods since they are using built-in provided standard library algorithms rather than my own custom algorithms in the first place.
Also, I had first started out with a test checking whether all of the stats were accurate in one big test but then I realized that's not really a unit test since it could/should have been broken down more.
Any advice/resources on this would be super helpful. The thing is, I've done plenty of reading about "What unit testing is" but putting it into practice for me has been quite different.
|
|
|
|
|
TheOnlyRealTodd wrote: Any advice/resources on this would be super helpful. You posted a lot of code in the Lounge.
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
TheOnlyRealTodd wrote: and I'm finding strange, inconsistent, and bizarre things happening in my thought processes and code in some ways as well. Is this pretty normal when you first try to learn TDD?
Yes. TDD is for the birds, but even they didn't first write tests to figure out if wings could support them, and then developed their wings.
In other words, TDD is ridiculous, because it requires that you write code to test something you haven't written yet.
The mindset for writing tests is orthogonal to writing the code you are going to test. When you do the latter, you're thinking about abstraction, decoupling, performance, optimal structures, and, here's the clincher, you're thinking about how to structure the code so it can be tested.
When you're writing the tests, you're thinking about edge cases, parameter validation, exceptions trapping, whether the business logic is correct, and here's the clincher, you're thinking about how to ensure that all code paths are actually exercised.
Now I ask you, how can you test that all code paths are actually tested when you haven't written the code?!?!?!
So of course TDD is a mind f***. It's a different process, and it's usually a BAD process. Of course there are cases where you can write the tests first, but certainly in my experience, anything other than a very isolated piece of business logic, it doesn't make sense. The main result of TDD ends up being that you've written a bunch of useless tests, and even worse, you've written code to meet the structure imposed by the test. That might work fine for play languages, but is usually a bad idea for professional languages. (I'll leave the reader to figure out what I mean by play vs. professional.)
So what should TDD be then, you might ask? Well, it should be a concept of what needs to be tested - is it algorithm correctness, is it performance, is it multithreaded support, is it worth testing? Then write the code with the idea in mind of what you are wanting to test, so that the code is testable, then write the tests.
We'll let the voters decide whether they agree or not. And if they don't, well, the voting is rigged!!!
(Oh, and great question BTW. I love a good opportunity to emote on the idiotic ideas this industry has created.)
Marc
modified 21-Oct-16 20:41pm.
|
|
|
|
|
TDD is extremely good for two things:
0. Getting loose cannon devs on track.
We all know and have to deal with such guys, but it's not hard to write tests with premises like "This is the name of the output module, and these are the expected outputs from it".
-- You know your inputs
-- You don't care what the processes are; that's where you rely on other developers
-- You know the outputs That Have To Result.
So write tests for it.
What TDD does is get that clear in everyone's mind, so flying off in weird and unwanted directions is less likely to happen.
1. Forcing specs
For me, this is their primary function. Even "produce working code" is secondary.
Put it this way: It's a way of introducing specs when the f***ing lazy management team hasn't provided them -- with the added bonus that the f***ing lazy management team has to sign off on it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|