|
I liked Windows 7 and would have preferred that MS had continued in that direction.
But if you HAVE to use Windows 8, then "yes" - Windows 8.1 is better than Windows 8. Marginally perhaps, but still so much that I would say: Don't install Windows 8, but if you must, use Windows 8.1
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
I think 8.1 is better because they've fixed the desktop so it's actually usable again (without third party tools like Classic Shell), haven't they? The one-app-at-a-time Metro UI is just totally terrible for a computer environment, as it has been since 8.0, but if you boot to desktop you never have to see that (as long as you fix a few file extension associations that open up there like PDF ... grr).
|
|
|
|
|
|
WOW !!!  
In code we trust !
|
|
|
|
|
A ghost writer no doubt....
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
|
|
|
|
|
|
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
Interesting! 
But did you notice under his profile, he is being shown as a "Member since Thursday, January 2, 2014 (6 months)", but if you look at his reputation graph, it's showing the rep points since 2009. 
Whether I think I can, or think I can't, I am always bloody right!
|
|
|
|
|
No I didn't. Shall I call the police or something?
Regards,
Rob Philpott.
|
|
|
|
|
Just now. After you gave the link. 
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
It's a feature. 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
|
Sandeep Singh Shekhawat wrote: You are always right!!
Please, tell my wife! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
He is most definitely a Legend Author. Especially with his 0 upon 0 amounts of articles he wrote
Wow! I must say I think I am short 20K author points by the look of it 
Loading signature...
. . . Please Wait . . .
|
|
|
|
|
It seems to me that it is "enterprisey" to write layer of abstract code.
In fact I am often criticized as "not liking layers"
So first I'd like to say what I thing about architecture then ask my question
A crux of contention is:
=======================
I would argue writing layered code is not an end of its own (at least not reasonably).
I would argue an end of its own is (simple maintainable code, i.e.) probably be these few properties:
- modular (people can work on their bit independently)
- dependencies flow down (top level use low level, low level do NOT use top level)
- simplest / unobtrusive as possible shell / architecture to glue stuff together
this *might be* layered / interfaced too but this is not the purpose...
What I often see and I wonder how prevalent and wonder how common it is
=======================================================================
Layered / interfaced as hell code which takes weeks to understand to solve problem as simple as adding 1 + 2.
Is that a common pattern? I suspect it is!  
|
|
|
|
|
Super Lloyd wrote: is not an end of its own
Correct.
Super Lloyd wrote: Is that a common pattern?
Not in my experience. But it depends on the how big a project it is too. I have written only one application with more than a Data Access Layer beneath the application.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I always keep my UI layer and any DB layer separate - it is simpler to just ram code accessing the DB directly from a View, but so totally unmaintainable beyond trivial examples that I just don't do it. I also almost always have a 'service' layer which stitches the two together, rather than calling the Db later from the UI layer.
Other than that, I tend to be fairly flexible on layers depending on the project.
I agree about the over-complexity introduced sometimes - my logic is that a well written and modular project can be expanded into more abstract layers, should that be necessary, quite easily if it is easily maintainable and modular in the first place - and building abstraction on abstraction just because it makes some intrinsic sense to a developer, in my experience, slows development and can increase bugs as new developers don't understand how it hangs together - and nobody ever spends the time to train newbies!
Quote: Super Lloyd wrote: simplest / unobtrusive as possible shell / architecture to glue stuff together
That's the one that gets me most. When someone uses some framework or other (especially if they use something and then modify it, and don't document anything) I have often found that the use of the framework has been chosen without much knowledge - so the developers learn on the job, invent work-arounds, until the whole thing is a bit of a mess, nobody really understands how it is meant to work, and new devs coming into the project don't have a cat in hell's chance of being productive for weeks.
Still, I'm an old fart, so what do I know?
PooperPig - Coming Soon
|
|
|
|
|
I usually keep some sort of scheme like in these two excellent articles 
1. Building a Framework - Part I (DAL)[^]
2. Building a framework - Part II (Utilities)[^]
although that can differ a bit from project to project. My major concerns regarding this, is code separation. It forces me to keep things simple. It also allows me to reuse things, which is handy when you're working on multiple applications.
|
|
|
|
|
What? Something like this?[^]
Regards, Stewart
|
|
|
|
|
Yeah!....
|
|
|
|
|
Layering can be essential to avoid spaghetti and headaches.
Imagine a collection of diagnostic tests written into a prototype, then re-written into a CRM wizard.
Then keep adding new tests, and testing would require rewriting the prototype and the wizard each time.
Or- write each test into a dll, referenced in the prototype and wizard by simple xml.
Adding new tests means just extending or altering the xml and a little wizard interface adjustment.
|
|
|
|
|
Simon O'Riordan from UK wrote: Adding new tests means just extending or altering the xml and a little wizard interface adjustment.
Which is only true if in fact there is a prototype and wizard.
If there is only one or the other then there is no benefit.
Problems arise when developers (plural) or developer (singular) decide that even though there is one instance that in some mythical future there might be more. (And I want to emphasize that they do this without even a glimmer that such a possibility exists.) And thus conclude and require that extra layers be added to support this mythical functionality.
|
|
|
|
|
My principles(I do REAL software in an ENGINEERING company - you've probably heard of that) are rolling out new extension requirements regularly. Now I know you want the five pound argument, but unfortunately you are not paying my bills.
|
|
|
|
|
Simon O'Riordan from UK wrote: My principles(I do REAL software in an ENGINEERING company - you've probably heard of that)
And management of your phone at least at one time was written by me.
And a very good chance that if you used a credit card in the US in the not too distant past then you had a transaction processed by software I wrote.
So now that both of us have proven that we are actual business professionals - my point stands.
If you have extensions being regularly rolled out then you
1. Do in fact have multiple examples already.
2. Probably do in fact have an idea of new instances in the future that will require more flexibility in your design.
Those two factors however are exactly what I said some developers do NOT have. Yet they insist on inserting the same flexibility and of course they will be paid for that time even in cases where it will never be used.
And in point of fact I know of specific example where at least one developer (could have been more) added a complex feature into an API and after several major versions of the software there was NO use of the feature. (This by the way was an API and not a UI toggle that no one bothered pushing.) And when I queried business analysts with years of experience in the industry they could not come up with any idea at all why this feature would ever be used.
Actually for that feature the reason I figured out it wasn't used was because it in fact was coded wrong. It would not have worked if used. Which is why I went looking for the answer for why it existed in the first place.
|
|
|
|
|
Ah, cool. Yes, I was stateside 2008. Kudos, mate. I am looking after operating systems and various other stuff on a tall stack for the Equator robotic gauge. The company was founded by the ex-chief designer of Rolls-Royce Aero Engines specially to do metrology.
Look us up on the web; 'Renishaw'.
The gauge is a beauty; it uses the 'comparator' method to be extremely repeatable rather than absolutely accurate. Ideal for volume production where the product changes frequently.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
