|
I can't think of any time that they've forced an OS-level upgrade on people. Sure, they've made it so you couldn't get any work done without upgrading (from 9 to X), and crammed truly, phenomenally stupid app upgrades on people. But I don't know if they've ever done some of the stuff the Windows team has been doing lately.
It's been such an "own goal" on their part. They really should just be showing people 10 more - it's a pretty good upgrade. It shouldn't need to be forced on people.
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: it's a pretty good upgrade
Not when you're on 7 
|
|
|
|
|
True enough, I can't think of a compelling reason to upgrade from 7. I was on WEight, so there were fixes needed 
TTFN - Kent
|
|
|
|
|
When I say that Github captures the zeitgeist of the programmer world of the 2010s, I am thus saying that Github is at the absolute core of the software development universe. Because people *really* like resolving merge conflicts
|
|
|
|
|
|
|
Not my world for sure...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
While I've never taken advantage of the feature, others have touted the greatness of being able to work with branches while disconnected.
Pull requests are useful, especially in open source projects, where 99% of the contributions are things you want to reject rather than having automatically folded into the branch.
GitFlow is the technical "solution" to the technical problem that Git created -- how to work in a disconnected, multi-branch-verse project. And it itself is a nightmare. I've seen developers create a branch for a single line of code, issue a pull request, accept the request, merge it into the main branch, and then delete the working branch.
I think this comes from the fact that Linux users start suffering psychotic episodes if they don't do something on the command line at regular frequency. It's like a drug, and the withdrawal causes all sorts of howling agony and shouting like "I will never use an IDE" (yes, I have actually heard that.)
Marc
|
|
|
|
|
I've found that many of git features exists to overcome issues created by git.
|
|
|
|
|
Joe Woodbury wrote: I've found that many of git features exists to overcome issues created by git.
Quite so!
Marc
|
|
|
|
|
I did a git pull and now I have a detached head.
Typical Monday.
|
|
|
|
|
That sounds painful. Perhaps a couple of aspirin (but don't call me in the morning!).
'PLAN' is NOT one of those four-letter words.
'When money talks, nobody listens to the customer anymore.'
|
|
|
|
|
Quote: At the time Github first started attracting notice, centralized version control schemes were the standard, and when you were somewhere the source control server wasn’t, things could get painful. I remember using a tool called Rational Clear Case that was setup in such a way that it took me most of the morning to commit a few files to source control if I was working from home. As bad as that sounds, it could be worse — if you were on a plane or somewhere without internet access, you wouldn’t be able to work at all, unless you had planned ahead of time to acquire an “offline” version of the code.
The first part of that actually sounds a lot like my experiance using CC from in the same office as the server. Holy elephant was CC slow.
OTOH working offline only required manually marking the file as writable in the file system. It's exclusive checkout model could make it a PITA if someone else grabbed a file you were working on while you were out; but one of you would end up swearing just as much if you were both online at the time. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
The IDC has gone about collecting some figures that tell us the top 10 skills for occupations available in the United States. Because the code always works on the PowerPoint slide
|
|
|
|
|
So, writing a letter using Word became a task so complicated, that you need proficiency?
We may step back to the pen...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Is it really true that static types reduce over-all bug density? Types deemed extraneous
|
|
|
|
|
Someone wrote: Is it really true that static types reduce over-all bug density?
No, it's diligence on the part of the developers(s) that does that.
|
|
|
|
|
TDD can effectively cut your shipping bug density in half
TDD is an artifact of using non-static, dynamically typed scripting languages, because you can't tell if the code will even run unless you, well, run it. What non-static, dynamically typed languages have done is created a whole new class of bugs, specifically type error bugs, that don't exist in statically typed languages because they are compiler errors, not runtime "bugs."
Granted, TDD, has other merits, but one thing that you will not see in a statically typed language are unit tests to verify that the code "simply runs", which is the first, if not the most predominant, form of unit test you'll see in non-static, dynamically typed scripted languages. Unless the person writing the unit test doesn't know what they are doing, or, more than likely, come to languages like C# from Python/Ruby/Javascript experience.
From my personal experience with Ruby, Python, and Javascript is that I waste considerably more time either writing unit tests or being a human unit test, and then fixing stupid type and syntax errors, than I ever have when I writing C, C#, C++, Pascal, or even assembly language code.
Marc
|
|
|
|
|
I absolutely disagree. While essential in dynamically typed languages, TDD is still a useful discipline in statically typed languages. Its saved my arse many times - especially detecting that changes in the code base have had unintended side effects.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: TDD is still a useful discipline in statically typed languages.
I didn't intend to disagree with the benefits of TDD in statically typed languages, though it seems it came across that way. 
Marc
|
|
|
|
|
The "bug density graph" (how did they came up with it btw?) seems wrong... How did they came up with it?
And "53.62" "density" for C++.. what does that even mean?
However complicated I think C++ can be, I don't believe well maintained big open source project (say KDE) has 1 bug every 2 lines (53.62 "density"), that's ludicrous!
I know I have way more bug in my Javascript code than in my C# code for example (we could substitute C# for java in the graph< I suppose)
And many C++ error would be pointer problem I presume, which has nothing to do with strong typing...
|
|
|
|
|
|
tanks for the finding!
and confirmation of the foolishness of this ludicrous article! 
|
|
|
|
|
“A developer’s job is to build — build it fast and build it right.” Let's go back to kLoC, it's so useful
|
|
|
|
|
Kent Sharkey wrote: kLoC, it's so useful
The
frack
it
is
.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
It's sourced in the original 
) is considered a reasonable repo; and ones where a sane minimum size repo is a major application or library is far larger.