Znurt @znurt

Okay all gentooligans ... I own znurt.org which is up for expiration soon, and I haven't used it in years. Is there anyone working on a #gentoo related project that would use it? I'm not looking to sell it, just donate to a good cause (dear @gentoo can you RT)

Here's a blast from the past: web.archive.org/web/2012062123…

I've been thinking about bringing znurt.org back online, but there's so much work to do. It's pretty difficult to get the importing work done in a *solid* manner, but git solves so many problems now. Any other #gentoo users out there, I'd love to get your opinion.

I bought larrythecow.com. I'm thinking about bringing back a planet feed for Gentoo users. #gentoo

Lots of cleanup today, though. github.com/beandog/znurt/…

Fortunately, there's only so many features the backend code can do, so it's easy to test against the database to see if I'm getting what I need or not.

That's one of the most difficult things working with legacy code -- you're afraid to rip out broken stuff because you have no idea how it'll affect everything else.

Same thing happened here for the updated code. It's pointed out some good stuff to be fixed. Sometimes there's a lot of going back and looking at parts that never worked in the first place, and me wondering if I ever used it.

A few years ago, I turned on E_NOTICE and E_STRICT as default in my code. I like it a lot because it quickly flushes out bugs that are oversights. Typos, especially. And it forces you to initialize variables in some cases, mostly arrays.

I've toyed with the idea of throwing some of the images on a CDN, but, money. :T

The biggest one for speeding stuff up though is making all the pages static. There's really no reason to have almost all of them be dynamic.

There's a couple of things I'm going to do for optimization though. After import, I'm going to do a copy of the database to an sqlite one that it can pound on, and leave the importing one alone.

The database structure itself hasn't changed at all for the tables. I've added a bunch of views that make importing simpler and more efficient. In theory, it should just work.

Rewriting everything up to importing ebuilds is done. I'm tempted to bring the site back online just so I can see how broken it is. It's getting close enough to where it has enough, though.

Still plugging away. A lot of the import scripts have been rewritten so that they're cleaner and faster. Schema has dropped a lot of data that I don't import anymore since it's never used, such as herds.

It still takes a long time to do a cold import on an empty database. Around 45 minutes or so. I don't recommend it.

I can tell now that two things happened: it really did emerge from a QA ebuild / tree foundation, and the backend overshot what users are going to need or want on the frontend. So I'm trimming away a bit.

I've gone through the import code base and cleaned it up a lot so it's easier to read, so that's good. It's less of a headache now. It's kind of crazy to see all the stuff it either does import or was intended to, but never uses or displays (herds, fex).

Found a new home for hosting, woot woot! Thanks to another generous Gentoo dev (we look out for each other, yo). I'm setting up the new server, it'll be some time.

Anomalies like this trip me up: fam-2.7.0_p17_p2.ebuild The p17_p2 part, the regexp expects only one patch level. Need to fix that. :)