?

Log in

No account? Create an account
July 12th, 2001 - LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

July 12th, 2001

Infidelity.com [Jul. 12th, 2001|02:18 pm]
LiveJournal Development

lj_dev

[bradfitz]
The guys that run Infidelity.com (a site for women with cheating husbands) want a journal feature on their site and have talked with me several times about it.

I thought at first they wanted a full journal system, but it seems they want each woman to have their own private journal that nobody can read, including the other women. The owners say that many women keep their own journal to keep track of their husband's activities but fear he'll find it, so they want to keep it online instead.... at their site.

I told him I'm busy but somebody from lj_dev could probably do it and for less than $1,000 most likely.

Anybody interested? Is using LiveJournal for this way overkill?

I think martmart and halkeye could do this and get some money for their efforts they've been putting in LJ lately. Also, any changes necessary to customize the site for their needs can be rolled back into the main source so it's easier for future clients.

Thoughts?
link18 comments|post comment

Console [Jul. 12th, 2001|02:58 pm]
LiveJournal Development

lj_dev

[halkeye]
what does:
fetch() without execute()

error mean in regards to the console? i can't find that reference anywhere
link4 comments|post comment

S2 launch and Overrides [Jul. 12th, 2001|04:10 pm]
LiveJournal Development

lj_dev

[mart]

As Brad has noted, S2 is 'imminent' in an other-people-get-to-contribute way. Personally, I have bold visions for the launch of this big new feature, and I want to see it launch with loads of styles, all of the relevant documentation and everything ready for mass user-adoption.

As part of this, I do think that all of the current system styles should be revamped and made in S2, and if possible these new (identical to the user) versions should replace the current system styles transparently.

This wouldn't have been an issue if it hadn't been for the mass-adoption of Style Overrides by free and paid users alike. S2 is radically different to the current style system, and style overrides in their current form will have no place in the new system.

I am keen that we do 'automagically' convert all of the existing free accounts over to S2 styles so that the new funky customisation features become instantly available to them with no kludgy switchover procedures. In this case, then, the question remains... what do we do with the style overrides the free users are using currently?

An obvious solution is to convert them into S2. However, since I like everyone else haven't seen anything about S2 since the original taster docs Brad published months ago, I can't speak on the feasibility of that. It also creates an issue when the users later want to modify their overrides and find the interface has changed drastically.

A final, related point is existing styles. Ideas that have been explored include an S2 style which renders current-system styles (since S2 as it will work on LJ will be compiled into perl, this is doable), a script to do a one-time conversion of them all, or just running the two systems in parallel. Whichever of these is chosen, there does need to be a migration path from the old styles to S2 other than remaking the styles from scratch. This is complecated by the fact that S2 styles are layered, and thus work a lot differently to the current system which only has three conceptual 'layers' - style, colour theme, overrides.

This is basically a call for discussion on the subject. I'm interested in what others think and can come up with on the subject.

link11 comments|post comment

Directory status [Jul. 12th, 2001|08:53 pm]
LiveJournal Development

lj_dev

[bradfitz]
In the old directory code (you'll have to go find it in an old tarball), we cache directory seach sub-queries ... if you did a search for 21 year-old females in seattle, it'd do 3 searches, save each part, then join them (in perl... fast, since mysql sucked at it), then show it to the user.

On a subsequent load (paging) it was pretty fast... only had to do the join.

However, the table that stored the query results used to crash MySQL (and still might). Its schema was:

dsid INT (index)
userid INT

The new directory code had each sub-query function return a data structure representing what tables it needed to select from to get its information, then the caller would get all those datastructures and form a massive SQL query that did everything. I thought running this on a slave would be okay.

This second method then cached the final search results (limited to 1000 results).

Its schema was:

dsrid INT (index)
userids BLOB (comma-separated)

And also, as a key there was a md5(sql-query) ... so the SQL would be made everytime, but then it'd see if it knew the results already.

The directory code needs to be re-written to incorporate methods 1 & 2 together.... cache both the search parts and the final join. However, when storing the search parts, don't use the schema I originally used (although ideal) ... join it all together comma-separated and split it in perl land. Philosophy being: web server CPU cheap, db CPU expensive. Also, don't run into db crashing code... making so many damn rows makes MySQL do a ton of work maintaining indexes. So much so that they're very often behind so queries don't benefit anyway, especially given the rate of DELETE FROMs we do (while cleaning the tables up).

So... want to fix? :-)

----- Original Message -----
From: <dormando@rydia.net>
To: <bradfitz@bradfitz.com>
Sent: Thursday, July 12, 2001 11:19 PM
Subject: Stuff with the .. er, d thing..


> Hey,
>
> sigh, so, what did you have to do to the directory before you put it back
> up again? Adding duplock support and what else? I'll hack in the duplock
> support for you, if you want. just have to get it going so people will
> stop harassing us... I'd rather not see a "where's the directory!?"
> comment on an announcement of S2 or similar.
>
> hell, if it's not too much I'll fix the whole thing, I should be a lot
> busier than I am.
>
> well, maybe.
>
> -Alan
>
>
link3 comments|post comment

Image galleries [Jul. 12th, 2001|10:01 pm]
LiveJournal Development

lj_dev

[ntang]
hey all... try this link: test

If it works, that might not be a bad place to direct people. Fototime.com not only has a really nice free windows photo album tool, but it also has free web galleries. They even allow you to embed the pictures... (see inside the cut).

If, perchance, you can't see the image, post a comment. It seems like that url's a good one, but it might be a temporary one or something similar. Dunno.

Read more...Collapse )
link10 comments|post comment

(no subject) [Jul. 12th, 2001|11:05 pm]
LiveJournal Development

lj_dev

[thegreatdark]
Uhh, am I just dense or something?

Where's allpics.bml in the CVS? (browsing the web CVS thingy here)

I swear, it's not where it should be (can't find it at all)... someone tlel me I'm just not looking in the right place, or something?
link2 comments|post comment

(no subject) [Jul. 12th, 2001|11:50 pm]
LiveJournal Development

lj_dev

[thegreatdark]
[music |Pink Floyd - The Wall - Disc 1]

In the following code, is $u->{'userid'} actually just the username?

$sth = $dbh->prepare("SELECT picid, width, height FROM userpic WHERE userid=$u->{'userid'}");
$sth->execute;
link6 comments|post comment

navigation
[ viewing | July 12th, 2001 ]
[ go | Previous Day|Next Day ]