SoylentNews is people
SoylentNews
Martyb here once again with today's update on our site's update. I apologize that this is not as well written as my prior updates as exhaustion and outside issues are demanding of my time. I ask you to please bear with me.
Quick Recap: As you may recall, our servers were getting melted trying to serve up highly-commented stories. Further, this made for an unacceptably long delay between the time one would request a story and when it would finally get returned for display. Our devs have implemented alternative display modes, "Threaded-TOS" and "Threaded-TNG" which use a much more efficient means of processing comments and getting them to you. These changes went "live" on Saturday, February 25.
Like anything new, we expected there would be issues. We very much appreciate your patience as we tried to work through these as they were reported. And did you ever let us know!
Paulej72 (aka PJ) and TheMightyBuzzard (TMB) have been laboring mightily to keep up with the issues that have been reported as well as a few they found independently. Similarly, as their fixes have gone live, our community has had to deal with a changing landscape of "what happens when I do this?" To add to this, comments being such a major part of the site's purpose, there are "knobs" in several places where users can customize which comments are presented to them and how they appear. The permutations are many and wide-raging. As bug fixes have been made, the impact of changing these has had different effects over time.
I've been astounded at how much the community has been supportive of our efforts, how well problems have been described and isolated, and how quickly the devs have been able to fix bugs as they have been noted. Even more impressive was the discussion in our last update story on possible alternative means of implementing the <spoiler> tag. I'm proud to be part of this community — you rock!
Stories: While all this activity has been happening, stories have still been posted to our site for your reading and commenting pleasure. We are working with a reduced editorial staff at the moment. Us long-timers have been posting as we can, but I would like to personally thanks our new editors fnord666 and charon for their heroic efforts getting stories posted, and takyon for his continued efforts at providing well-written stories. I have noticed submissions from new folks as well, and the heartens me immensely! (Note: I hesitate to call out people in particular for fear I will overlook someone; any omission is purely my fault and I would appreciate being called out on it if I have failed to list your contribution.)
Plans: This development blitz has, however, come at a cost. For those who were with this site at its inception, there was a "day of rest" imposed on the developers who had worked basically non-stop trying to get our site up and somewhat stable. I have suggested a similar break to our dev staff. Recall we are all volunteers doing this in our spare time. PJ has plans coming up and will be unavailable on Friday and Saturday. From what I've seen, TMB is well nigh a crispy critter at this point and most certainly needs a break. And, quite frankly, I've put a lot of personal stuff on hold while working on this update and could use a break, as well. In short, we are tired.
So, PJ is around for a bit (in his free time while at work) for today and TMB is getting a well-deserved breather. NCommander is nearing burnout has been tied up with an outside project that demands his full attention and has been unable to help much. I'll poke in from time to time, but I really need some time off, too.
What I ask from the community is that we do something similar. Step back for a moment. Look at the forest and not just the trees. Play around with the different display Modes. Try setting a different "Breakthrough" and/or "Threshold". Things should be much more stable today, so that will make it easier to gain a "mental model" of what does what.
The other thing I would ask is for the community to pull together and try to address issues together. Someone posts an issue about struggling with having to click on all the little chevrons? Inquire about their user preference settings, and suggest a different value for Threshold/Breakthrough. My sense is that some are more adept at using the new features and they can help others to get a better understanding of how things work. With those issues addressed, we can more clearly identify and isolate underlying problems and focus our energies more productively.
tl;dr We're not done yet, we truly appreciate your patience and forbearance during this transition, we need a break, and you guys rock in helping others in the community understand and use the new stuff. As always, keep our toes to the fire — we are here for you — let us catch our breath and we'll be better able to move forward.
Continuation of:
Site Update 17_2
Comments Redux
Site Update: The Next Episode
Site Update - We're Getting There!
(Score: 1, Insightful) by Anonymous Coward on Thursday March 02 2017, @04:08PM (8 children)
If people keep insisting on No JavaScript then no wonder it takes forever to load up Stories WITH Hundreds of Comments instead of loading them asynchronously from separate micro-services.
(Score: 3, Insightful) by The Mighty Buzzard on Thursday March 02 2017, @04:39PM (1 child)
S'working out pretty well, all in all. Just because some people can't write efficient server-side code doesn't mean it can't or shouldn't be done.
My rights don't end where your fear begins.
(Score: 3, Insightful) by edIII on Thursday March 02 2017, @07:56PM
That, and what the fuck is the difference between a page that loads 10% within 1 sec, 100% within 7 secs, and a page that loads in 7 seconds? All of that javascript is still going to take the same amount of time to load. If it wasn't fast enough, the scroll will jerk around or you will see spinning wheels for comments.
Don't get me wrong, I'm a fan of javascript/html5 too, but this site is working *just fine* without it. That, and I really like having a place I can go to without worrying about putting on a condom. The worst you ever did was to include PiWik I think, and that wasn't 3rd party.
Plus, you guys have done amazing things on the backend in the last few years refactoring all of that old code which was higher priority.
We may argue about politics, but the people here know how to come together and run a site. Well. Very appreciative of all the hard work of you and the staff members.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by Aiwendil on Thursday March 02 2017, @04:45PM
Works better since we only have zero to two redraws (loading css, and maybe loading charset).
Also, since main reason for disliking JS is due to it being a huge resource hog (security is second) we can simply just load the page in a background tab and have a nice mostly-non-interactive page waiting for us when we've finished with the earlier tabs.
(Now I actually allow js on soylent - but that is due to them keeping it sane (i.e.: minimal and only on specific userrequests))
Seriously - I never even noticed the slowdown due to often having multiple minutes between loading and reading.
(Score: 3, Insightful) by mechanicjay on Thursday March 02 2017, @05:12PM (2 children)
To each his own I guess.
I actually really dislike sites that do a continuous load of new content as you scroll down for the following reason: When you reload the page and try to find something that was towards the bottom of wherever you left off -- good f'ing luck. Now you're wasting 5 minutes of scrolling and loading to hopefully find what you were looking for rather than just being able to do a find in the page.
Philosophically, I agree with TMB, server side performance is something a lot of folks who build whiz-bang front-ends don't pay attention to (in my experience because they don't understand it). Leveraging the power of an RDBMS is key to this. I've, seen (and fixed) applications where basically a "Select *" is passed to php, or even worse the js in your browser, is left to sort it all out. In many cases the micro-service paradigm of only getting exactly what you need when you need, while potentially more data efficient can also be a band-aid over poor back-end design. Also in a situation where you're making hundreds, or hell, even dozens of web service calls, the round-trip time for each call really starts to add up and negatively impact the user-experience.
Of course that's just one luddite web-infrastructure engineer's opinion, YMMV
My VMS box beat up your Windows box.
(Score: 2) by tangomargarine on Thursday March 02 2017, @05:49PM
RDBMS
RMS-DB anagrams to that. This needs to be a thing :)
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 4, Insightful) by Marand on Friday March 03 2017, @12:40AM
When you reload the page and try to find something that was towards the bottom of wherever you left off -- good f'ing luck. Now you're wasting 5 minutes of scrolling and loading to hopefully find what you were looking for rather than just being able to do a find in the page.
I absolutely loathe that design for the same reason. It ends up wasting both my time and my bandwidth, and I usually just go "fuck this" and don't bother. It also means you can't leave it for later and pick up where you left off, because the next time you open the browser it's back at the start. Or if, like me, you use addons to automatically unload idle tabs, it resets back to top when the tab goes active again...
Plus, they tend to be made with an assumption that the dynamic loading will never fail, so when it inevitably does, the only "fix" is to reload and start over. For example, Slashdot has become incredibly obnoxious about this with the threshold slider because I'm on a high-latency connection right now. I'll change the threshold, the little "working" spinner shows up, and then more often than not it times out and just leaves everything half-loaded with no fix except to reload and try again, because apparently they have something misconfigured and it makes high-latency connections time out constantly. Whatever they did, I have something like a 30% failure rate on loading anything there, so even if the page itself loads, changing the threshold tends to fail. (No other site I visit has this problem, so I lay the blame on them.)
Dynamic loading also breaks browser navigation (back/forward) and pagination. So, yeah, it's just annoying all around.
(Score: 2, Funny) by Anonymous Coward on Thursday March 02 2017, @05:46PM (1 child)
loading them asynchronously from separate micro-services.
I just came. Did you actualize it with a virtualized Ruby cloud server farm for maximum synergy and optimality?
(Score: 1) by purple_cobra on Thursday March 02 2017, @11:36PM
BINGO!