How slow is Discourse on your mobile?
-
Really? I am the one forcing you guys to be on daily builds, when we have stable and beta channels? News to me...
It was actually news to us as well. Hopefully we'll move to stable now and the constant flame wars can finally die down.
-
The deeper issue is that you guys are updating too often IMO.
Hey - I tried not to. Guess what? Someone else updated instead. That lasted even less than my usual update cycle.
Stop fucking blaming us.
Put us on a stream that you feel is less buggy than what we're currently on and we'll stop moaning. (Actually I don't think that'll work)
Or at least stop blaming us. Which is what you just did.
</drunk>
-
Maybe we can all agree that being on daily updates is a profoundly bad idea for this community. The beta releases are much safer.
And we try not to touch anything around here unless it is urgent because...
-
-sigh-
i hate doing this. i really do. I've read pretty much everything here from before i became active and i've kept up to date on every thread here since i became active (my autoreader catches less than 5 posts every week) but...
/t/5405 is joining /t/3213 on my list of muted topics.
in fact they are the list...
hmm, i notice both threads got on that list as a direct result of @blakeyrat... maybe there's a pattern here.
or not because @codinghorror is also to blame for /t/5405 being added to that list.
can we please stop attacking people and star attacking the bugs? because it's getting really old, from both sides.
-
If we move to stable then the appropriateness of me posting Game Grumps Sonic 06 meltdown in Meta diminishes significantly.
https://www.youtube.com/watch?v=omLve_vezbA
</snark>I do take issue with:
@codinghorror said:For example -- the CSS font size bug (related to making global font sizes easier to adjust in 1.2 request) existed for all of 2 days. You would not have even experienced that bug at all had you updated with the numbered semi-weekly beta releases.
We MIGHT not have been bitten, and more likely the bug would have gone unnoticed until it hit the beta stream because it appears: code reviews don't happen and minimal testing if any is done before the changes are accepted/commited. The trade-off becomes, do you lose some developer agility and at least happy path test changes or just fire-and-forget and wait for users to find shit. Better yet, pay someone to do integration testing.
-
Nope, wrong, there was a meta topic about it already.
This is also covered by not having someone push daily updates here. Ain't us doing it.
-
You gave us a forum where if you type "3." in the edit window, you get "1." in the result. There is no way that's not a bug. An extremely, extremely obvious bug.
I eagerly await @codinghorror finding someone who will be upset if he fixes Discourse to number lists sanely, instead of the way it does now.
I'm not going to hold my breath, though.
-
The whole community is predicated on "ha ha, look how stupid everyone else is". Because it's too terrifying to realize we're that person too.
If you were here more often you'd realize we often spend just as much time making fun of our own bad code as we do everyone else's. No one is immune from calling out bad code here. We're equal-opportunity. Occasionally people take offense to it, but I can only think of two specific instances, you and then whoever that Lotus Notes guy was. We've also had a few show up and say "Wow, we didn't realize we were doing things that badly, thanks for letting us know and we're going to fix things now."
Heck, I've even submitted my own code to the sidebar before. Scrutiny is good. I try learn from it rather than acting toxic and accusing everyone else of being toxic.
I'll admit, my job may be why I find the lack of testing to be annoying. Testing is a huge part of my position, and if we don't test and pushed out releases with major bugs, it's possible airplanes could literally be falling out of the sky.
I see the "Firefox tiny font bug" and see a bug that could have been caught by simply loading the site, but instead someone figured it would all work out and simply clicked whatever button shoots it out to production websites not operated by CDCK. And that is 180° out-of-phase with the reality I live in.
Bugs are a fact of life in the software world, we all get that. Mistakes happen. We all love to laugh at them. But there are major bugs and minor bugs, and the amount of major bugs we get here is staggering, and as an outsider that indicates to me that your process is broken and needs overhaul. Somewhere along the line, major site-breaking bugs are being introduced and pushed into live use without being caught, and that's not cool.
-
This is also covered by not having someone push daily updates here. Ain't us doing it.
Who pushed the mother fucking update for someone else to fucking update it you incompetent shit? It was one of your fucking developers, who did not test the fucking code beyond automated testing. Yes, your group fucking did it.
Take some fucking responsibility. Jesus fuck, I admit my team has done similar shit. At least I will man up and say it fucking happened. I don't blame anyone else. Your team checked in broken, shitty, buggy-as-fuck code and someone else fucking pulled it. Take responsibility.
-
Yet again YOU GUYS ARE ON DAILY BLEEDING EDGE BUILDS. Ask yourself two questions:
-
What does it mean to be on the daily builds vs. weekly-ish beta or bi monthly stable releases? Which line do you expect to be buggier? Buggiest?
-
Why are you on daily builds?
Has zip to do with us. I don't touch anything here and have not in months because
-
-
Yet again YOU GUYS ARE ON DAILY BLEEDING EDGE BUILDS. Ask yourself two questions:
I would shit can people who regularly check in code that is broken at the most basic level. Hit the fucking skids. If you regularly do the shit that you guys do, you have no business writing code.
I get "bleeding edge". I don't get writing buggy code, checking it in and then blaming others for your mistakes. The bugs we regularly find should have never made it past a private repo. Hell, most of them never should have made it past localhost.
-
Take some fucking responsibility for choosing to be on daily builds. If you run canary and don't know what that means, that has nothing to do with me.
Hell yes there will be bugs. Everything ever made has bugs.
-
What does it mean to be on the daily builds vs. weekly-ish beta or bi monthly stable releases? Which line do you expect to be buggier? Buggiest?
Based upon what I have seen, I am with @PJH in believing that it doesn't fucking matter.
-
Yet again YOU GUYS ARE ON DAILY BLEEDING EDGE BUILDS.
I was not aware of this. All I know is we have this post-1.0 software with a revolving door of bugs, and that half a year after moving to Discourse a huge percentage of conversation here is about how buggy Discourse is.
If we're on daily builds we shouldn't be, this is a live production website and not a testers' playground. If we want to be a testers' playground that's actually fine by me, as long as it's clear that the site is going to be broken often and that bug reports will be taken seriously.
-
If you run canary and don't know what that means, that has nothing to do with me.
Why are these most basic of bugs ever making it in to a fucking public repo?? This shit should never make it past localhost. Period.
An occasional cock-up is absolutely forgivable. We get that. It is fucking constant. Do you not get that? Why is this shit making it past localhost??
-
Your beliefs are fascinating, but the facts say otherwise. Small font bug? Never would have seen it on the beta releases. Not at all. Ember 1.9 regressions? Ember 1.8 regressions? All stamped out well before the beta releases.
(yes the Ember 1.8 suggested topics malformed html "endless loading" mobile bug did slip through, and I regret that, but there are literally dozens to hundreds of additional small bugs you'd skip entirely on beta releases.)
-
Your beliefs are fascinating, but the facts say otherwise. Small font bug? Never would have seen it on the beta releases. Not at all. Ember 1.9 regressions? Ember 1.8 regressions? All stamped out well before the beta releases.
I care fuckall. Why did they ever make it past localhost? As you like to quote your own blog to reinforce your point, allow me to quote another one to illustrate mine.
Brian's 10 Rules for How to Write Cross-Platform Code
Introduction I've had a lot of success in my 20-year software engineering career with developing cross platform C and C++ code. At Backblaze, we just
Pay attention to rules #9 & #10. Especially #10. Fire lazy and/or incompetent developers. These bugs never should have made it in to a fucking public repo. Period.
-
I am sorry we can't live up to your standards of never making mistakes IN CANARY BUILDS. Of course that is kind of the point of canary, but maybe we have different definitions for those words.
-
Beyond that, you are a fucking PR nightmare. You should stay away from these forums as a matter of PR. You just are not cut out to communicate to a public that does not care for you or your product.
-
I know! I keep telling my team "stop making mistakes you morons!" and it never seems to take! I should fire them all, you're right. And hire you as a management consultant.
-
I am sorry we can't live up to your standards of never making mistakes IN CANARY BUILDS. Of course that is kind of the point of canary, but maybe we have different definitions for those words.
WHY ARE "CANARY BUILDS" PUBLIC???
-
hire you as a management consultant.
You could do worse. You would not like my demands though...
-
Yeah that's why you make the big bucks though.
-
I keep telling my team "stop making mistakes you morons!" and it never seems to take!
What you should be telling them is "stop committing broken shit to the repo" or "don't blindly commit without checking that your stupid css math isn't evaluating to 0.644 pixels"
-
It is a public open source project, you can build it any time. What do you mean, why is it public?
And as for canary, ask Chrome why they have a canary channel?
Chrome Canary Features For Developers - Google Chrome
Get on the bleeding edge of the web with Chrome Canary designed for experienced developers and updated nightly.
Isn't it obvious? You get the latest features faster, but more potential bugs. Kind of a worst case scenario for this community, though, since every bug is just more evidence how moronic those developers are compared to you.
-
Well yeah, in some browsers, in some conditions. I do wish we had team members more willing to run Firefox for diversity reasons but it's ... just not as good as Chrome. I have tried a few times and I always get pulled back due to various rough edges and deficiencies in Firefox. (It is also slower)
Anyway, you'd never have seen that bug on beta releases, which is more the point.
-
And as for canary, ask Chrome why they have a canary channel?
I am going to take a WAG that if a dev on that team commits obviously broken, shitty code, on a regular basis, they will be shown the door. I am also going to take a WAG that is not based on shit that was just checked in a few minutes ago without basic testing.
-
And I am going to take a WAG that there are a lot more bugs in Canary than Beta and Release.
So yet again, know what you are signing up for.
-
I do wish we had team members more willing to run Firefox for diversity reasons but it's ... just not as good as Chrome.
So what? You don't need to switch to it for your everyday use, just keep it installed so that when you make UI changes to your web application, you can ensure that it looks ok.
Google devs probably use Macs, but I'll bet dollars to donuts Chrome Canary at least gets opened on Windows before releasing to the public, and if they spot an issue like "our UI elements are half a pixel in size" they'd fix it before, not after releasing.
-
Remember, the font bug only showed up under certain circumstances in Firefox like "open as new tab". So simply loading the site in Firefox would have looked correct. (You can look up the relevant bug topic on meta if you don't believe me.)
So what you described did happen -- it was not so obvious.
But facts, who cares for those?
-
@Intercourse said:
I get "bleeding edge". I don't get writing buggy code, checking it in and then blaming others for your mistakes. The bugs we regularly find should have never made it past a private repo. Hell, most of them never should have made it past localhost.
That's never going to sink into Atwood's skull. His developers are perfect. It's the consumer's fault for assuming his public-facing repo contains a stable product.
Take some fucking responsibility for choosing to be on daily builds.
Are you implying that I made this choice? Or there was a vote?
I did not, and there was not. Stop making this claim.
Your beliefs are fascinating, but the facts say otherwise. Small font bug? Never would have seen it on the beta releases.
That's not the point. This point is: why did it hit any public-facing repo? Why are your developers checking-in broken shit? Why aren't you chewing them out for it?
I am sorry we can't live up to your standards of never making mistakes IN CANARY BUILDS. Of course that is kind of the point of canary, but maybe we have different definitions for those words.
If the point of that branch is to be buggy non-working, non-tested code, why the fuck is it accessible to the public? Why isn't it locked-away somewhere until your test procedures get run?
@Intercourse said:
WHY ARE "CANARY BUILDS" PUBLIC???
^- this. Exactly this.
It is a public open source project, you can build it any time. What do you mean, why is it public?
Right; but you chose to make that particular branch public. There's nothing in any open source license that requires that. Hell, you don't even have to have the code online if you don't want. That's your dumb decision, and your dumb decision alone.
And maybe, just maybe, maybe not pick a development methodology that results in a constant barrage of broken shit? This is exactly why people (like me) have a dislike of open source software-- who could like a development methodology whose major selling point is "give the public broken shit!" (They phrase it "release early, release often", but the intent is the same.)
I do wish we had team members more willing to run Firefox for diversity reasons but it's ... just not as good as Chrome.
"I do wish I had hired competent people who gave a shit about doing even the most rudimentary testing of this product, but hey, I'm Atwood and I don't give a shit myself! Whee!"
Remember, the font bug only showed up under certain circumstances in Firefox like "open as new tab". So simply loading the site in Firefox would have looked correct. (You can look up the relevant bug topic on meta if you don't believe me.)
So what you described did happen -- it was not so obvious.
But facts, who cares for those?
Ok speaking of facts: so you've confirmed your developer who checked that in did view the webpage in Firefox, but did not happen to trigger the bug?
Or are you just saying, "well my incompetent team didn't bother testing it, but hey even if they had done the bare minimum amount of testing Blakeyrat was proposing, they wouldn't have noticed this specific bug!"
Because one of those options is significantly better than the other.
-
I see the "Firefox tiny font bug" and see a bug that could have been caught by simply loading the site
I see someone typing this and ignoring the fact that it just isn't true.
Yet again, visit meta and read the bug topic there. Site loaded fine in Firefox. It was only at times like "open in new tab" that the font size bug was exposed. IN A CANARY BUILD INTENDED FOR THAT VERY PURPOSE. A bug that was then fixed within
2412 hours of being reported.I see a community that is more interested in burning strawmen in effigy than anything else.
-
I see someone typing this and ignoring the fact that it just isn't true.
Yet again, visit meta and read the bug topic there. Site loaded fine in Firefox. It was only at times like "open in new tab" that the font size bug was exposed.
Now you're just being pedantic. "Open in new tab" is normal workflow for a lot of the users here, me included. I encountered the bug literally 2 seconds after coming to the site.
-
No, I am not. The workflow for CSS changes of that magnitude is to open the site in each browser, click on some stuff. Why would anyone ever expect "open in new tab" to behave differently in rendering fonts?
-
I agree, font rendering behaving differently if you do "open in a new tab" is very unexpected.
I just assumed that "open in new tab" was what the majority of power users do, especially with forums, and until recently I had no reason to believe that wasn't the case. I typically open up 5 - 20 different topics as soon as I get here and then close them one-by-one as I get caught up.
No, I am not.
Yeah you were. I said the bug happened by loading the site in Firefox. You pointed out that that wasn't technically true because you had to open a topic too. That's pedantry.
-
No, that is not a common usage (it is a lot more work for one thing), nor would anyone have any rational reason to expect there would be any difference whatsoever in font rendering between clicking a link and opening that same link in a new tab.
Simply loading the homepage in Firefox and clicking around would have shown everything was normal. That is what we typically do for big CSS changes.
And no when someone says "did the site load for you" nobody assumes they meant "in a new tab" or how that could possibly make any difference.
-
No, that is not a common usage
Open in new tab is not common usage? Really? I do it all the time because this shitty software frequently does not do what it says it will...save my place in the thread. It works maybe half the time for me, so when a notification comes in I open that in a new tab so that I can be sure I can come back to where I was.
You have to be careful about that though. Unless you are running a Cray, it can bring your machine to a crawl. With...a website.
-
I for one find it highly humorous that you wrote:
[Quote]With my guest article, I was trying to inspire readers to take on the burden of reprogramming bad developers[/Quote]
Which is exactly what most of your critics here are trying to do with you and your team. Discourse development lacks several processes used in professional app dev which would help you build a better product. If you listened to some of the advice here, it might help you avoid some of your own wtfs.
-
it might help you avoid some of your own wtfs.
Yeah, but he still won't use a proper bug tracker. Just dogfooding and hammering a square peg in a round hole.
-
Discourse development lacks several processes used in professional app dev which would help you build a better product.
Let's try to rephrase this.
You are developing Discourse in an unprofessional way.
OK ... let me fly with this.
Who here works for a 5 person company that
- Are shipping a product on a daily cycle?
- Have an extensive regression and unit test suite?
- Practice continuous deployment?
Anyone?
Its easy and often necessary to jam a boat of process into a 100 person company, I know that in blakeyland there are magic unicorns that ensure no developer ever checks in a bug, using NASA style dual development teams working on the same code and communal beatings for every breakage. Also last I heard bug trackers don't fix bugs, the biggest annoyances you have here, tripple *, fast like reply, numbered lists are not things that fell through cracks, just things we have not had time to work on yet.
-
Yes; not (seemingly) doing code reviews, not having QA testers, blaming community for Administrator(s)? switching to nightly builds; yes, all of those are unprofessional development practices.
One of those is easily fixable, code shouldn't commit until another set of eyes has looked at the changes.
I don't stalk the Github repo so maybe you guys are reviewing shit before it commits, but I'm an end-user; I don't really give a damn. I just know shit breaks and lately it has been useability breaking, not annoying breaking.
In the case of the Firefox CSS "bug", yes; it is reasonable to not assume that changing CSS would result in odd behavior when "Open in new tab" happened. I consider that the same class of bug as "Service is marked for deletion" when an application tries to remove a Windows service but Task Manager is open. Turns out Task Manager grabs a handle to services so that's why it a service won't delete until you close taskmgr.exe Very much an edge case but when it isn't documented users blame the thing they last ran, not APIs, not technical mumbo-jumbo, the application they were running.
Whomever switched TDWTF to nightly builds needs to just fess up, and at the first oppurtunity that won't cause the forums to spew fireballs of death, we get switched off and updated to a stable version. I won't make any jokes about, "Discourse isn't stable on stable!" because in truth I've had near nil-issuses until the fucking Firefox CSS "bug". Right click -> open new tab is now an edge case, that is normal behavior for anyone who has used the internet for the last 20 years and doesn't trust hyperlinks in websites to not just refresh the current page. Every site is different and that is the only tried and true, "Won't lose where I'm at" measure a user can take.
Given you guys are running so lean, slowing down doesn't seem like a bad idea to me. DO code reviews. DO round-robin testing duty. DON'T let users switch to canary builds without giving them lots of warning. Again, I don't know how we got to that channel, but if the Discourse admin page doesn't yell scream and shout, "Are you SURE you want to do this?" when possibly changing to daily-builds; that should be a new feature.
If it was a config file/command line change then whoever did that KNEW what they were doing, can't stop determined users.
-
1. Are shipping a product on a daily cycle?
You should talk to these guys.2. Have an extensive regression and unit test suite?
You should talk to these guys.3. Practice continuous deployment?
You should talk to these guys.
-
I've had near nil-issuses until the fucking Firefox CSS "bug".
Let's see... did they fix...
*
Guess not.
However, there is a workaround:
3389dae361af79b04c9c8e7057f60cc6
It's a quine written in Markdown!
-
Are any of them active here?
-
-
not having QA testers
Cool, which developers do we fire to make room for the 2 minimum testers you just prescribed?
-
DO round-robin testing duty.
Don't fire anyone. 3 weeks code-monkey, one week test-monkey. If as an organization you'd rather shit-can developers and hire a full time tester, that's up to you guys.
-
Cool, which developers do we fire to make room for the 2 minimum testers you just prescribed?
Your lack of testers is not our problem, it's yours. Figure it the fuck out.
-
The armchair quarterbacking does get really tedious. It is tempting to say "so what software have YOU shipped that mattered to the world, ever" but that is the low road so I won't go there.
It is easy to criticize, and hell, half the criticisms here are flat out wrong, like "the site loads with tiny fonts in Firefox, you are incompetent because that wasn't caught before going into canary" and "numbered lists are broken because you are following the existing Markdown spec" and "there are so many ongoing bugs, this is proof that you suck and by the way we are on daily canary builds." At some level you guys are hard to hear because you don't just cry wolf, you scream it at a million decibels.
There are a handful of rational voices here, and you guys are very good at testing. As I have said many times before. So thanks for that. And testing is a reasonable way to contribute back to an open source project, provided it can be kept civil, and provided everyone knows they are signing up for daily builds here.
DON'T let users switch to canary builds without giving them lots of warning. Again, I don't know how we got to that channel, but if the Discourse admin page doesn't yell scream and shout, "Are you SURE you want to do this?" when possibly changing to daily-builds; that should be a new feature.
Updates are not automatic. Someone is pushing a button in their web browser for each and every single individual update that occurs.Ain't us because we go to great pains to never touch anything around here due to the Stripes quote I have posted twice already. (Except in case of emergencies, site is down, that weird no rendering issue, etc)
-
Someone is pushing a button in their web browser
Unfortunately, we don't know who.
Hey - I tried not to. Guess what? Someone else updated instead.
