From github.com:

Important update

On April 24 we'll start using GitHub Copilot interaction data for AI model training unless you opt out. Review this update and manage your preferences in your GitHub account settings.

This is an exceptionally important announcement, though it's one I've been predicting for a while.

StackOverflow is dead, and the bots sucked up all of its knowledge, and GitHub repos' knowledge, and MSDN's knowledge, and...

And we wondered how AI would continue progressing if there was no reason to keep posting answers to the net "for free".

But it was obvious. Now each AI engine is storing (will soon be storing?) the answer to each question in its own StackOverflow, so to speak, but one tuned for AI, not humans. Every time you give Copilot the thumbs up or positive feedback (or some other way it figures you likely used its code), it's going to file that away as "The Right Answer for You". You have your own Jon Skeet in your workstation in exchange for your answers being in their own paywalled database. (Not that there's anything inherently wrong with wanting to make a buck.)

If all the best programmers use Claude going forward, guess where the best answers are going to come from?

Or, as it looks like Copilot wants to do, what if all the best answers are stored in Copilot's corpus? Then regardless of which model you use, the best answers (and autogenerated code) to the questions (and prompts that implicitly ask those questions) that used to go to StackOverflow will come from Copilot.

That's what's next, folk. Actually, that's what's now. All the knowledge that you helped build if you leave that setting on its default will be behind a paywall.

There's a great podcast with Nilay Patel and the CEO of Grammarly where Patel essentially asks: "Okay, [very not] cool, you're using my name and ostensibly my style. How much are you going to pay me for that?"

(Though I suppose the opposite is, "You're happily paying $10/mth for Copilot now. You think you could even sniff that magic without contributing your labor? You'd still be posting to StackOverflow, hoping someone would be kind enough to post something useful back, which used to be amazingly common, but when's the last time that's happened for you?" It's an interesting counterpoint.

Perhaps we should unionize before they alter the deal any further, like making it $75/mth. Or $175. Or more. Because they could.)

Every so often go out to the middle of the woods, turn off WiFi and cellular, and make sure you can still code. And then realize that's not really your job any more.

Labels: ai, business, coding, labor, stackoverflow

I mean, I already knew (if only based on the hard flattening of my own reputation graph) that StackOverlow was dead, but sheesh. Today I learned...

Prompt: how to mark xunit test as do not run but still allow test to be debugged

xUnit v3 introduces an [Explicit] property on the [Fact] and [Theory] attributes specifically for this purpose. Explicit tests are not run by default unless specifically requested via a runner command line switch or by an IDE gesture (like right-clicking and running an individual test).

... or, later...

Apply a Trait: Ensure your tests are decorated with the [Trait] attribute, for example:

[Trait("Category", "Integration")]

Enter Filter Syntax: In the search box at the top of the Test Explorer, type the exclusion filter using the following format:

-Trait:"Category [Integration]"

That second, in my case, does, in fact, work well.

Why bother with clicking into SO to search for a good answer when I can have a conversation with AI and prompt my way to perfection?

I posted to Mastodon a while back that anyone who thinks we ­aren't going to have humanoid robots sooner than later is missing the boat. Like different sized railroad gauges determining the size of the trains that use them, or that cars are roughly horse-buggy-sized, or that mobile homes are constrained by the width of our interstate lanes, or... or any other practical standard -- our world is largely human-sized! Not just that chair, but doors, tools, the things that tools work on (eg, nuts and bolts), the cabin of trucks/tractors/fire buckets, If you want to plug a multi-use device into something that can also be used by a human, you should have (among your stable) a humanish-sized model of your robot.

Same for LLMs! If you want "compute" to mesh well with humans, you need to create an interface that we already use if you're aiming for quick adoption. Keyboards & mice are good examples -- human hands are insanely dexterous if the keys and devices fit them. And poof, I have an 123 key (give or take) device to create code.

And so, no surprise, we quickly went from 0s and 1s to hex to assembler to coding languages that are decent compromises between written language and charted logic.

But that's for minutiae in code. If we want to describe at a higher level, we talk about it!

You get the point. Anyone who bet against LLMs better not use language themselves either, or they only have themselves to blame.

/soapbox

Labels: ai, language, llm, noteToSelf, stackoverflow, testing

Can StackOverflow leave nothing untouched? 🙄😉

Maybe some UXer can explain why arrows with circles around them are better than the old vote buttons with just arrows.

Has this been around for a while and I just missed them? 

Well, at least I now know it happened between now and 2020.

I worry that some UI changes are made just to keep people employed and busy. I'm sure there's a good argument or 15 to change it. I'm not sure they're always good reasons.

I still use a version of SourceTree on Windows from 2015 when I'm on Windows. There's nothing wrong with it. I prefer it. I had a coworker see it on a screenshare and say, "Where can I get that theme?" 

What if your redesign resources had been spent on anything else? How many sprints saved? How awesome would your app be? 

Again, not that a redesign is bad. In many markets, simply refreshing the page will drive sales. Just keep in mind the opportunity cost. I realize SourceTree's users are probably more "aged UI tolerant" than most (see my previous post where I admint to using kdiff3), but... 

How much better has SourceTree's core UX experience really gotten in the last six and a half years? What percentage of their storypoints went to it? Worth it? Idk. (But my guess is heck no. Also note that they've worked through several UI iterations since then. Remember when they used a diamond ring for Commit? And people liked it? /cringe twice. Brah culture much?)

In other SO news, I did hit 15k and can protect questions now. I expected to be more impressed when I hit it the way I was with 10k, but... not so much. It's cool, and I'm happy some answers continue to help folks, but I really need to find another semi-obscure but useful tag to sit on.

EDIT: Here's some description. There is a comment that this makes the page more accessible for the visually impaired. I'd like to know how. Does that mean I don't see the improvement? (no pun intended) Yeah, but that's the point of asking. Honestly, what's the improvement?

Maybe down/up/votes are clearer?

There's also a comment that the design doesn't really meet WCAG compliance after all. Apparently they didn't QA dark mode. 🤦

Labels: development, qa, sourcetree, stackoverflow, UI, UX

I mean, you said this...

Developers and technologists often want to learn about companies as they begin to evaluate opportunities in order to understand things like the company culture, the work/life balance, the social and environmental policies, the tech stack, and the learning and development opportunities companies offer. This is collectively referred to as “Employer Branding.”

If jobs aren't a part of that "branding and needs", why is your user base going to view that content? Why do I care about a company's work/life balance if I don't want to apply? I can tell you the only reason I ever access that content now is to see if I want to work at that company.

Labels: business, hats of money, money, stackoverflow

Here's a post I put onto the story posted at StackOverflow regarding its sale to Prosus. As of this morning, it's been a day or two and it still hasn't passed moderation. I mean, that's their right, but let's say it doesn't speak well for their willingness to listen. Makes you wonder how many more critical comments are in moderation limbo.

Once this acquisition is complete, we will have more resources and support to grow our public platform and paid products, and we can accelerate our global impact tremendously.

But what ways are you unable to impact the globe now? That is, shouldn't I substitute "impact" with "financial growth" to decode this sentence?

My guess is that StackOverflow is doing exactly what we appreciate it doing right now. That is, THE GROWTH IS OVER. I couldn't care less if you spin out opportunities based on the same codebase in some wholly owned subsidiary that chases cash, but within stackoverflow.com? I can't recall anything changing over the last almost 10 years that's a knock it out of the park, revolutionary advance. And I don't need one!

There are some interesting problems that could use solving at stackoverflow.com, certainly. How do you keep answers fresh when the answers to questions change over time, and old accepts are now objectively wrong? How do you manage moderation to ensure it's not tone deaf (or worse) at times? Maybe even, "How can I pay to get an answer to my question beyond simple point bounties?" That last one is the only one I can think of quickly that increases revenue (and only as a middle banker, not as the primary entity paid) and usefulness of the site.

But growth? What growth? Are the servers crumbling over the load? No. Are there too many low quality answers? Maybe, but it's been reasonably easy to get past the chaff. Do you need a better mobile app for countries with less infrastructure? Well, actually, yes. Yes you do. But beyond that...

Convince me this isn't about the money, or -- and I'll give you a softball here -- even primarily about the money. What is this "impact" primarily about that's not income?

Labels: fail, hats o' money, stackoverflow

So the title of the latest StackOverflow podcast (I'm not a listener; caught in the sidebar) is "One in four visitors to Stack Overflow copies code".

Wait. Wait... you're watching me that closely?

Our April Fools prank taught us there is more than a kernel of truth to the old joke about borrowing software smarts from Stack Overflow. Kyle Pollard explains how we built the software behind the joke, and Cassidy Williams explains how we built the actual keyboard.

Oh, it was just part of that joke where a pop-over would appear any time you hit Ctrl- or Command-C. I guess that's an interesting fringe benefit of it. (I'll try not to quibble that you don't know it was code being copied, but maybe they're sniffing that too.)

Except... there's no way I'm going to think it was just alive during the April Fools' Day prank.

And even if it was constrained to then, let this be a clear lesson of how closely websites are listening to you. I mean, we all already knew this, but it's an example of how seeing something in person is convincing in a way amorphous, theoretical knowledge isn't.

Not only can this sort of metric be taken, it is taken easily, and, if you saw that April Fools' popover, it was taken from you.

Did StackOverflow listen this closely when it was in version 1? No chance. No, really. No chance.

Does it and other mature sites listen to you this closely now? Of course they do. As do your apps. As does your OS. As does...

I may have mentioned this before, but I had a time a few years back when I was wearing a mechanical watch, had forgotten my phone (and, therefore, my wallet case), and was walking to the grocery store for lunch with a $20 bill in my pocket, thinking during the walk that, for the first time in likely years, I was performing something completely [well, okay, relatively] off the grid, nothing digital, nothing battery-powered, not even a grocery reward card, on my person.

Similiarly, it's rare that I read a paper book -- a true codex -- without thinking that I'm glad Amazon or Apple or whoever is behind Libby isn't tracking how quickly I read each page. Not that I mind being tracked for the most part, and I appreciate Libby telling me about how much time I likely have left in a book before my library loan is up, but it's nice sometimes to be walking to the store with nobody virtually watching.

Labels: privacy, stackoverflow

StackOverflow flashback... Not sure who wrote this comment, and it's a little strongly worded, but man, they're on the money. ;^)

• @samhocevar I can't believe you Little Bobby Tabled me. ;) If you're running text processed by client-side JavaScript on your database server without any safety checks, heaven help us all. ;^) Look, there shouldn't be anything any user can send from a client (eg, Postman) that gets past your server's security. And you should assume anything dangerous that could be sent from a client will be. That is, if you require 100% safety from client-side JavaScript code which is always user editable, and you think this function could open a security risk, you're playing in the wrong game. – ruffin Feb 19 '18 at 18:57  

I hope that makes sense. Sure, it's not bad to include some safety checks client-side, but they really are just niceties. Maybe you check a few things for your user's user input without a round trip to the server, but only after you've already put those same rules into your server's code.

(This, btw, is why Node is so intriguing. Write once with both sides in mind and you get client-side niceties for "free". Otherwise, if you push me to shoving, I'd say an mvp should only have input validation on the server [in ways that make it easy to return error packages to the client to display]. (And thus the * in the title... you can have it on the client, but it's not worth anything from the point of view of security.))

Honestly, this dev taking me to task by saying people can get formatUnicorn (read: client-side JavaScript code) to inject strings into (again) client-side variables... I mean, I can't even. WHY NOT JUST INPUT THE WACKY STRING TO BEGIN WITH? And to think that anything in JavaScript protects your server... Ugh. So many bad programmers loose these days. I'd like to think they're junior, but imagine that's a senior dev that forces juniors to protect against string injection in client code, maybe client code only. /shiver

Labels: development, security, software, SQL, stackoverflow

Ran into this question about diffing blocks of text on StackOverflow yesterday after KDiff3 and WinMerge both went crazy trying to diff a file where I'd simply mostly just grouped and, therefore, rearranged lots of methods. Seems like an easy issue, but as that question points out...

Is there a diff-like algorithm that handles moving block of lines? - Stack Overflow:

But it falls down when blocks of text are moved within the file.

Suppose you have the following two files, a.txt and b.txt (imagine that they're both hundreds of lines long rather than just 6):

a.txt   b.txt
-----   -----
1       4
2       5
3       6
4       1
5       2
6       3

diff a.txt b.txt shows this:

$ diff a.txt b.txt 
1,3d0
< 1
< 2
< 3
6a4,6
> 1
> 2
> 3

That really is painful, when it should be a reasonably easy process.

Now I've tried to write my own diff engine before in my usual bullheaded, straight-ahead style, not worrying about efficiency until after something's working. It's not easy. But what you can say is that if you take it as your primary mission to find block movements, it's a lot easier. Enter wikEd diff Online Tool - Cacycle, "The Only JavaScript Diff Library for Visual Inline Text Comparisons With Block Move Highlighting and Character/Word-Based Resolution".

Results are pretty good, both for the simplest case from the SO question, to real-world code.

(The green highlight is for grouping a block, but by default it ignores/doesn't highlight any moved blocks, which is nice when you're diffing code like I mentioned before...)

Now I have to resist the desire to put this into a full-fledged UWP app whose goal is to be a diff tool. There are smarter things to write on my own time. Please realize this, self.

Labels: diff, kidff3, stackoverflow

From Netscape Goes Bonkers – Joel on Software:

The sheer volume of bugs, it seems, proves that rewriting code from scratch does not make for a better code base, it makes it worse. Old code doesn’t rust, it gets better, as bugs are fixed.

Someone should tell that to StackOverflow.

Oh, I know, I know. This is design, you say, not code as such. But riddle me this, Batman: Was anyone not using SO because of the design?

I'm going to hazard a guess that the code behind that menubar/toolbar was heavily refactored too. Could be wrong. Hope I'm wrong. Idk. But in either event, I'm not sure the old site's design had rusted.

Labels: code, design, refactoring, stackoverflow

Sometimes I see complaints about sites like Fiverr, where graphic design folk complain about how the sites depreciate their own work. I'm usually not that sympathetic. What I'm looking for when I use Fiverr is something that really shouldn't take more than a few hours to do, at worst -- usually an app icon. And I want someone who can do that in an hour, rather than the hours on hours it'd take me to Gimp my way to inferior, but probably useable, results.

That's not the market of most graphic designers I see complaining. I was never in their potential market. If I ever have an app "take off", I might be. I might want a custom icon set, and better app icons that require some in-depth conversation and being on the same aesthetic page. Right now, not so much.

See, many of these folks won't even consider my "value proposal": I need a single app icon. Can you make that for me? Even at their normal rates, the overhead of getting a new customer spun up in a serious way often makes that a money-losing proposition. And who wants the wasted overhead getting on the same page with a customer just to make a single icon? Not only are they out of my budget when I'm tossing darts at the board and seeing what sticks, I'm not a big enough fish for them to care about.

But I got a sort of "turnabout is fair play" on StackOverflow Careers this morning. Check this out:

Wow. Just wow. I mean, that's less than $11 US per hour.

It's obvious this is for a programming sweat shop. One coder doesn't work 24 hours a day, seven days a week. They want a team. And cheap. Which means it's also pretty obvious to me, at least in my experience, that they aren't looking for great code, and will settle for code that seems to function, forget maintainability. Because even if you're willing to hire anyone semi-competent, as long as they're at this rate, you're not hiring someone competitive. I mean, good programmers can still find global, remote jobs that pay much better than this.

But let's also take a second to recognize that this is, in part -- at least as long as I'm working contracts remotely -- my competition. Wow. I'm not saying I couldn't make ends meet at $11 a hour, but that's sure nothing close to what I'm able to charge now. This is globalism. Like graphic designers looking at Fiverr, even though Powerfont Pty. Ltd. was never a potential customer (or employer) of mine, wow. That anyone had the gall to post such a low rate for a "senior" .NET MVC programmer is a body blow.

My biggest practical asset, it turns out, at least implicitly, may be my geography.

Labels: business, globalism, stackoverflow

My new favorite quote of Marc Gravell's from StackOverflow:

based on the SQL, all I can say is: both queries look horrible. I knew there was a reason I normally write my own TSQL... – Marc Gravell♦ Jun 15 '12 at 7:29

I understand having entities for editing and manipulation, but don't know why every read that's done a system that employs a conventional rdbms isn't done with native SQL.

Labels: entity framework, orm, SQL, stackoverflow

Yay?

I guess I could do something like add ESLint to the list of alternatives to JSLint on the JSLint tag wiki, but that's not that horribly exciting.

The next priv on SO is "Access to Moderator Tools", which actually is awfully powerful. I would've never thought I'd make it there, but with the way points from old answers keep coming in like dividends from old investments, I guess it could happen.

And I can't help myself. 5000 came from another JSLint answer -- one I posted yesterday. I'm always surprised at the amount of venom JSLint gets on SO. There's almost always a stupid an ill-advised comment about how horrible JSLint is, and how the asker should use ESLint or JSHint instead, for many questions with the JSLint tag. Yesterday's was no exception.

Within a few minutes of the question's posting, there's that second comment...

I'd strongly recommend finding an alternative to JSLint, and it's outright silly rules warning about perfectly valid JavaScript. Consider ESLint, JSCS, or even JSHint.

... and it's got four votes. So five people have complained about the topic of the question within a few minutes of its posting, and rewarded pretty inflammatory, off-topic speech. So I finally did it; I replied too harshly.

Good heavens. Sorry to vent on you on this question, but if it's a JSLint question, give a JSLint answer. I don't spam up the ESLint & JSHint questions with, "You really should take out all of your dimestore opinions about JavaScript and use a linter with strong opinions to more universally standardize your codebase." Commenting "your tool stink0rz" is like saying, "Stop using JavaScript. VBScript rulez!1!" It's just opinion. Crockford's rarely demonstrably wrong; often, folks who make these comments don't take the time to understand what he recommends or why.

The implicit VBScript comparison might have been too much. ;^) I'm sure JSHint & ESLint are good tools. I've followed both a bit and used JSHint for a while, and they're fine, if you want lots of room for customization... and intra-office debate.

Painfully, I replied twice, ending with, "Show me where JSLint "actively harms Javacript" & I'll show you someone who doesn't understand the lang," which I'd still stand behind, I think. You can disagree with JSLint, and it will, famously, hurt your feelings, but it's almost never wrong in any definitive way.

Okay, actually I ended with...

/sigh I'm ending this transmission. (The irony, of course, is that I think krillgar's found a bug in the new JSLint.)

Always makes a quick exchange more fun when you can drag in Thumb Wars.

Still, I just don't get it. Is there another tool that gets this much flame? Honestly, I really do believe one of JSLint's strengths is, as I've mentioned, that you precisely don't have to get together as a committee every time someone wants to change some minor piece of JavaScript coding style. Crockford's not dumb, and, again, his prescriptions (well, proscriptions) are very rarely, if ever, wrong. And if it's wrong, he'll fix the code quickly, as I've seen a number of times (and even been a part of once or twice).

Why is more opinion always better? I hate JSLint's whitespace rules, particularly with hanging lines and end parens, but say what you want, at least it's an ethos.

WARNING: Some NSFW language here:

Often, it's lazy to decide for yourself instead of figuring out why a convention suggested by an expert might be smart.

I'm also much happier looking at JSLint's code. Have you looked at ESLint's repo? I mean, nothing wrong with it, but it sure isn't a single file. Looks like it's a node-directed solution too. Why must tools become so complicated so quickly? (I know Nicholas wanted "a JavaScript tool with pluggable linting rules", but I'm not sure all the overhead is necessary.)

Anyhow, there's nothing wrong with JSLint. If it doesn't work for you, I'm sorry. But when a JSLint user has a JSLint question, give them a JSLint answer. If you've got to throw in a, "But I usually use ESLint or JSHint," that's fine, but answer the question first.

/rant

Labels: coding, gamification, JSLint, stackoverflow, style

Just in case it ever disappears from StackOverflow, I want to quickly capture my favorite Skeet comment from StackOverflow:

We might see some abuse. We might also see some much simpler code where we just want a tuple, basically. Not everything needs to be an object with complex behaviour. Sometimes "just the data" is the Right Thing. IMO, of course. – Jon Skeet Feb 10 '09 at 23:18

What I really like about Skeet's comment here is that he shows he's [likely] always considering the anti-pattern. Too many developers hear rules from people they respect and start spouting them as gospel without 1.) checking to see if they really are the best way to approach a problem, and 2.) without continually double-checking that decision when they run into new, real-world problems that challenge the rule.

Say what you will about returning anonymous types, there's an argument for it. I love to use anonymous types as return objects for controller actions, when it's appropriate and you don't need a viewmodel (or already have one to reuse (which is essentially the same thing)). I've also, on my personal projects, caught myself using Tuples with more frequency than I'd expect. Is there a case to use anonymous types further up the line? Perhaps! If there's a repository method that's always producing read-only data, perhaps!

It's not whether the answer's right. There often isn't a kneejerk Right Thing To Do. It's that you consider every reasonable answer before deciding on today's solution.

That is, stop the cargo culting. Your fellow coders will, eventually, thank you for it, because a deliberate culture makes everyone a better coder.

Labels: coding, Skeet, stackoverflow, style

Labels: stackoverflow

Take in the number. Multiply by significant digits after the decimal so that you can truncate to zero places with ~~. Divide that multiplier back out. Profit.

function truncator(numToTruncate, intDecimalPlaces) {    
    var numPower = Math.pow(10, intDecimalPlaces);
    return ~~(numToTruncate * numPower)/numPower;
}

Labels: javascript, noteToSelf, stackoverflow

After finding a new job, users contribute 25% less in reputation-generating activity on Stack Overflow. By contrast, they reduce their non-reputation-generating activity by only 8% after finding a new job. These findings suggest that users contribute to Stack Overflow in part because they perceive this as a way to improve future employment prospects.

Labels: stackoverflow

Labels: coding, goals, JSLint, stackoverflow, style

Labels: stackoverflow

Somebody replied to ​a comment I made back in 2012, and I came back for a look. Forty-three upticks! Who knew? Probably my most up-something-ed contribution to StackOverflow, and, since they weren't upvotes that fire off a notification, I had no idea.

Quick rant: I do hate when people copy answers and comments exactly, however -- see the guy from this year saying essentially the same thing I did in his comment tacked onto the question itself. I mean, it's not a lost rep thing in this case, so I can't really complain, but when that happens with answers (not just my own), it drives me crazy. I think my flags are both for folks that are rep farming by copying [much] earlier answers.

Anyhow, glad to know I've helped 43+ people squish their git commits. That's kinda neat. ;^)

Labels: git, stackoverflow

Labels: fail, stackoverflow