|
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!
|
|
|
|
|
Mark_Wallace wrote: 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.
Absolutely!
Marc
|
|
|
|
|
Your first test seems weird and unnecessary...
If you decide to overwrite the ToString method (maybe for debugging purposes) your test will fail, while it wouldn't actually fail any business requirement (unless you actually use ToString in your business, but I can advice against that).
Besides, you're using a strong typed language so if you change the type your code wouldn't even compile (let alone run that test)!
If you really want to check the type check it using typeof so that your test doesn't break if you even only rename your class.
In fact, you're testing if a constructor actually constructs, if it wouldn't you'd have bigger problems than that one unit test (because C# just broke)! 
Test only what is important for your business cases. The statistics on the array are important, because you can't have a customer get a wrong average or count of his invoices (or whatever it is you're doing). Testing whether a class has a certain name is not important (save, maybe, for some edge-cases with reflection).
TheOnlyRealTodd wrote: 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.
Yes, you should test them.
Test your public methods like you don't know the implementation. In fact, you're testing now to prevent your code from accidentally breaking in the future. Testing it lets you change your implementation in the future without worrying you'll break anything.
Be sure to test with null and empty arrays and rounding errors in your average (especially since it's a floating point type)
I also agree with Marc by the way. Your tests are there for your code and not the other way around. TDD does switch it around though.
I've worked on a project where every method was public so it was testable... Not quite how it should work. It only prevented us from changing implementation details because tests, that didn't affect business requirements, would break.
Good luck with your testing adventures. I still find testing a very difficult subject!
|
|
|
|
|
I spent some time learning it, and then discarded it as being useless for my requirements.
All it did was triple the amount of time it took to develop anything, as I'd simply be writing code to the same requirements twice and then debugging it twice.
Sure, it helps if the requirements are set, but most of the time I have little idea what the final product will look like because the boss doesn't know what he wants either. Sure, I could make a prototype, but if I do that, the boss says 'looks okay, tweak that and that and you're done - I'll expect that by Friday then?'
It also helps when the cost of failure is high. eg. a bank or publicly available software. The cost if my software doesn't work for a few hours? Pretty much nothing unless it screws up so badly as to corrupt the database.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
