xb95
in
lj_feedback
questions and answers, continued
Hello, everybody. I thought I'd take a moment to answer some more development related questions as well as some other random things. I hope you have as much fun reading these as I did writing them. :-)
archangelbeth: Why is there no shttp page for logging in?
It's not really necessary, actually. The login page protects your password before submitting it to the site. Your password never gets sent in plain text, it's always obscured. (For the curious, we use an MD5 hash of the password.)
However, we do provide HTTPS functionality for login -- it's just not linked anywhere. You can go directly to it though. Bookmark it!
butter_mint: Why did the link to find a random LJ user go away?
The random user system was horribly outdated and only showed users that were years old. Until it's been updated, I don't imagine it'll be linked from the front page again. (However, you can always use My LJ's random user feature.)
ctakahara: Will LiveJournal ever implement an XML-RPC protocol besides its own and the aging Blogger protocol?
We support the Atom API which is where most sites are (hopefully) moving. I can't say I've seen any hard plans in either direction, but it's pretty safe to say that we would not consider implementing yet another protocol. (Although patches to fix/update our support of existing protocols will always be welcome.)
evil_1_2: What kind of testing do you do for new features to gain assurances that it will scale correctly when used by the full LJ comunity?
Scaling features is a mix of art and science. We do not have a staging area that can simulate the load of the entire userbase, but we've developed methods to ensure new features get rolled out successfully.
First, just about every new feature has a kill switch. System administrators and select senior engineers have access to the machines that run the site and are able to immediately turn off parts of the site. For example, the entire ESN system can be shut off at the flick of the switch. Same with tags.
Second, new features tend to go through tiered releases if we expect them to add new unknown load to the system. First to staff, then to permanent members, paid, early adopters, plus, and finally all of the basic users. This helps us identify problems of scale before they become too big of a problem.
Third, and perhaps most importantly, code review! Big features go through several sets of eyes. All of our engineers are very good at what they do, but everybody misses something from time to time. By ensuring that senior engineers review anything questionable (and most things not) before they go live, we help to cut off any problems before they manifest themselves on the site.
maguspsu: Do you guys plan on ever developing your own LiveJournal client? Maybe something available to pay members?
No plans that I know of. We're always happy to link to new and interesting clients on the downloads page, though.
rog: What happened to the lj development community? No bugtracker, no patch submission process, I want to help, but can't!
The fact of the matter is that since the acquisition there hasn't been a priority on spending developer time maintaining the community and working with volunteers. All of the engineers have their time booked pretty solid working on in-house projects, leaving very little time for such tasks.
If you're interested in submitting patches, your best bet is to use
lj_dev any questions. We try to help as much as possible, so between us and the technically minded users in the community, you should be able to get started helping. The bug tracker is still available, too, but we don't link it from such high volume areas.
goodnightlady: When will there be an opt-out option for the track it function on my journal?
There are no plans for an opt-out of ESN for your content. Anything that ESN allows you to do can already be done by someone sitting and hitting refresh over and over. With ESN they don't have to wear out the refresh button -- that means we reduce load on the servers which is always a good thing!
herminia: With paid accounts (+ extra userpics), it would be really nice if you could exchange extra storage space for more userpics. Would that be possible? And do you guys eat dinner with your elbows on the table? ;-)
Userpics take up far more system resources than an image in your ScrapBook. They appear in dropdowns frequently and show up so many places on the site, it's not an even comparison. The tools for userpic management are also not designed to work with as many userpics as we have now - the interfaces would positively crumble under 1000 userpics. Because of these and other reasons they've always been kept separate and I don't see that changing any time soon.
(And, my elbows go anywhere they please. Although if I'm at a fancy restaurant I tend to watch what other people are doing so I don't stick out too much.)
millieweasley: Why is it that you get so few userpictures at LJ in comparison to other blogg-sites? Wouldn't it be reasonable that you got for example, 15 for a free account, 30 for plus account holders and 100 for paid users?
We're always looking to make sure that users (regardless of account type) have as many userpics and features as is practical. We have recently (well, relatively) doubled the amount of userpics accounts get as well as introduced loyalty userpics for some account types.
The truth is, userpics are one of the LJ features that demand the most resources on the system. Other services that use LiveJournal's open source platform don't usually have as many users, so the resource demand for serving more userpics isn't as high. And of course, they don't have as many costs since we do all the core development for the software they're using.
So, while we're always looking for ways we can add more userpics for everybody, we're also hoping to find more ways to make them useful. Userpics are a large part of such upcoming features as LJ Talk, though, so stay tuned!
supersat: any plans for /singles/?
Why, Karl, are you looking? ;-)
But seriously, no - I've heard no plans. Some suggestions to chop the feature entirely, but it's almost too good to kill. A great source of amusement, etc.
...
Well, that's it for now. We've got more answer filled goodness coming right at you over the next few days, stay tuned.
archangelbeth: Why is there no shttp page for logging in?
It's not really necessary, actually. The login page protects your password before submitting it to the site. Your password never gets sent in plain text, it's always obscured. (For the curious, we use an MD5 hash of the password.)
However, we do provide HTTPS functionality for login -- it's just not linked anywhere. You can go directly to it though. Bookmark it!
butter_mint: Why did the link to find a random LJ user go away?
The random user system was horribly outdated and only showed users that were years old. Until it's been updated, I don't imagine it'll be linked from the front page again. (However, you can always use My LJ's random user feature.)
ctakahara: Will LiveJournal ever implement an XML-RPC protocol besides its own and the aging Blogger protocol?
We support the Atom API which is where most sites are (hopefully) moving. I can't say I've seen any hard plans in either direction, but it's pretty safe to say that we would not consider implementing yet another protocol. (Although patches to fix/update our support of existing protocols will always be welcome.)
evil_1_2: What kind of testing do you do for new features to gain assurances that it will scale correctly when used by the full LJ comunity?
Scaling features is a mix of art and science. We do not have a staging area that can simulate the load of the entire userbase, but we've developed methods to ensure new features get rolled out successfully.
First, just about every new feature has a kill switch. System administrators and select senior engineers have access to the machines that run the site and are able to immediately turn off parts of the site. For example, the entire ESN system can be shut off at the flick of the switch. Same with tags.
Second, new features tend to go through tiered releases if we expect them to add new unknown load to the system. First to staff, then to permanent members, paid, early adopters, plus, and finally all of the basic users. This helps us identify problems of scale before they become too big of a problem.
Third, and perhaps most importantly, code review! Big features go through several sets of eyes. All of our engineers are very good at what they do, but everybody misses something from time to time. By ensuring that senior engineers review anything questionable (and most things not) before they go live, we help to cut off any problems before they manifest themselves on the site.
maguspsu: Do you guys plan on ever developing your own LiveJournal client? Maybe something available to pay members?
No plans that I know of. We're always happy to link to new and interesting clients on the downloads page, though.
rog: What happened to the lj development community? No bugtracker, no patch submission process, I want to help, but can't!
The fact of the matter is that since the acquisition there hasn't been a priority on spending developer time maintaining the community and working with volunteers. All of the engineers have their time booked pretty solid working on in-house projects, leaving very little time for such tasks.
If you're interested in submitting patches, your best bet is to use
lj_dev any questions. We try to help as much as possible, so between us and the technically minded users in the community, you should be able to get started helping. The bug tracker is still available, too, but we don't link it from such high volume areas.
goodnightlady: When will there be an opt-out option for the track it function on my journal?
There are no plans for an opt-out of ESN for your content. Anything that ESN allows you to do can already be done by someone sitting and hitting refresh over and over. With ESN they don't have to wear out the refresh button -- that means we reduce load on the servers which is always a good thing!
herminia: With paid accounts (+ extra userpics), it would be really nice if you could exchange extra storage space for more userpics. Would that be possible? And do you guys eat dinner with your elbows on the table? ;-)
Userpics take up far more system resources than an image in your ScrapBook. They appear in dropdowns frequently and show up so many places on the site, it's not an even comparison. The tools for userpic management are also not designed to work with as many userpics as we have now - the interfaces would positively crumble under 1000 userpics. Because of these and other reasons they've always been kept separate and I don't see that changing any time soon.
(And, my elbows go anywhere they please. Although if I'm at a fancy restaurant I tend to watch what other people are doing so I don't stick out too much.)
millieweasley: Why is it that you get so few userpictures at LJ in comparison to other blogg-sites? Wouldn't it be reasonable that you got for example, 15 for a free account, 30 for plus account holders and 100 for paid users?
We're always looking to make sure that users (regardless of account type) have as many userpics and features as is practical. We have recently (well, relatively) doubled the amount of userpics accounts get as well as introduced loyalty userpics for some account types.
The truth is, userpics are one of the LJ features that demand the most resources on the system. Other services that use LiveJournal's open source platform don't usually have as many users, so the resource demand for serving more userpics isn't as high. And of course, they don't have as many costs since we do all the core development for the software they're using.
So, while we're always looking for ways we can add more userpics for everybody, we're also hoping to find more ways to make them useful. Userpics are a large part of such upcoming features as LJ Talk, though, so stay tuned!
supersat: any plans for /singles/?
Why, Karl, are you looking? ;-)
But seriously, no - I've heard no plans. Some suggestions to chop the feature entirely, but it's almost too good to kill. A great source of amusement, etc.
...
Well, that's it for now. We've got more answer filled goodness coming right at you over the next few days, stay tuned.