language snark

[egypturnash]

"And, in all my experience, the source code for any project written in PHP is going to look like the racoons have gotten loose in the trash again." - Jacques Distler

(found while suggesting wikis for a project)

ps. I really want to like Instiki (what with having a weird soft spot for Markdown and Textile) but the whole five-levels-of-indirection that seems to be involved in getting it hooked to the public web is a giant "NO". I just discovered ZiddlyWiki which adds a Zope-based remote back-end to the very cute and fun TiddlyWiki; dunno how much of a pain Zope is to get running, though.

Comments

[neogeen.livejournal.com]

Man, what I wouldn't give for just a tad more technical knowledge.

I understand about 30% of what you are poking at here, but the rest is flying over my head [and I can't stop it]. X3

[shatterstripes.livejournal.com]

Hey, I dunno if I could actually marshall all the technical crap involved in getting some of this up and running either.

Mostly I just liked that snarky comment about how ugly and awkward PHP is. The rest is me parking links to cool wiki engines so I can find them again if I ever need to set one up again.

(Every time I've set up a wiki for something I've used a different back end, because my needs change, and because I want to fool around!)

[ultraken.livejournal.com]

It's not so much that PHP is intrinsically ugly and awkward; it looks a lot like C/C++ and is even object oriented. The big problem is that PHP encourages embedding blocks in an otherwise-normal HTML document. What happens is that you start with a static HTML document and then start adding little bits of PHP script here and there to make it dynamic. After a while, the document becomes an impenetrable mash-up of PHP script and HTML markup.

PHP doesn't force that particular paradigm, though, so it's easy to write PHP script that contains the HTML document instead of the other way around.

[shatterstripes.livejournal.com]

God yes. Delving into the innards of Gallery was a hell of mixed markup and PHP.

More and more I have the feeling that structure and objects and all that in PHP are like trying to do Good Programming Practice in a line-numbered BASIC - sure, you CAN do it, but the language doesn't go out of its way to make it easy. If I was going to write some big web-app I'd spend a week beforehand seriously, seriously evaluating other languages with robust web frameworks.

I tend to stick to pure HTML/ECMAScript.

[wolfwings.livejournal.com]

AJAX may be cliche, but with the newer XML 'request' framework in Javascript I see less and less reason for any sort of server-side dynamic-page framework. Servers to load static pages, another to handle database calls, you're done.

Re: I tend to stick to pure HTML/ECMAScript.

[shatterstripes.livejournal.com]

The two problems with that are people with Javascript turned off (anyone in a lot of corporate environments) and the fact that all-JS-based navigation tends to break easy permalinks.

( Here, for instance, is an old prototype of a Javascript-based portfolio site design. It was interesting, but there's no way to cut and paste a URL. You can sort of change the address bar via JS but it's ugly, with no way to cleanly turn on and off the browser's native load animation... )

Re: I tend to stick to pure HTML/ECMAScript.

[wolfwings.livejournal.com]

Huh, never had a problem making AJAX-like programs work with URL cut-and-paste, was kinda why I liked em' so much. They bookmark correctly, and the bog-standard forward-and-back buttons work too.

The actual code to update the address bar is remarkably clean though: window.location.hash = and you're done.

The old web-comic interface I was working on. (http://wolfwings.us/inverloch/comic.html)

I'm still pondering making language and wide/narrow-screen viewing a cookie, while leaving the page part of the URL, right now the entire browsing structure is in the URL though, and not even encoded to speak of.

Re: I tend to stick to pure HTML/ECMAScript.

[shatterstripes.livejournal.com]

I've played with location.hash but I always found it to be unaesthetic. Reveals too much of the underlying structure, somehow. It's not as bad as leaving your ?query=string&hanging=out&for=all&to=see but I prefer my URLs as clean as possible.

(she says, knowing full well that her current website URLs are full of ugly %-escaped characters - really gotta fix that sometime soon.)

[cargoweasel.livejournal.com]

Wikis are like blogs, a solved problem, you should only have to mess around with things like Zope if you want to. Plenty of hosted wikis exist with zero/minimal configuration.

Also, he's right about PHP, check out Ruby on Rails instead for nice, elegant code. :)

[shatterstripes.livejournal.com]

Well, yeah. I just like all the flippy active one-page-ness of TiddlyWiki but don't like the local-file-ness of it; this is a solution for that. I've set up UseMod and PMWiki wikis in the past.

Messing around with things like Zope might be something I do soon; I keep on having this urge to dump Singapore for a homebrew CMS I'd build from the ground up as an Artist's Portfolio Site*.

I dunno about elegant and RoR. I've played with it some and I couldn't figure out how to do stuff like install an existing package on the supposedly 'easy' Locomotive, never mind get far enough to think of getting it up and running on my host. The language and web framework may be elegant but I had to wade through too much awkward support crap and ran out of patience before I got my hands on much in the way of real-world code to fiddle with.

* Singapore, like every other image gallery, seems to be designed more for 'i dumped my digicam photos'; I've hacked in things like cross-linking sketches to final images, time-release images for when I get off my ass and do a comic, but it's such a pile of php-mess. It could be worse; I could still be using Gallery...

[cargoweasel.livejournal.com]

Locomotive is surprisingly a lot harder to work with than a 'true' Rails install, which is famously tricky to get rolling on OS X (despite OS X's huge popularity among RoR developers). It has to do with certain installed versions of Ruby on Tiger, which need to be overwritten. Once you get past that trickiness (darwinports makes it fairly easy) it's quite straightforward to fire up plugins and rails apps. A reasonably current version of Rails is going to be built into Leopard with zero configuration so that might take care of a lot of things. I feel your pain though, it took me a while to get rails to actually install and run locally but once I got past that initial hurdle it's been great.

[shatterstripes.livejournal.com]

So much for 'easy packages'. Although Locomotive came with a binary of a recent version of Ruby IIRC. I got Locomotive to the point of running but then trying to, like, unpack a downloaded .tgz of a couple random Rails apps and get it running to just putter around was a nightmare...

The correspondence between RoR lovers and OSX owners continues to be surprising to me, given how user-hostile getting the thing running is and how user-friendly OSX tries to be. On the other hand I've also always had this odd instinctual shying-away from Unixy package managers like fink and darwinports. No, I don't know why.

[chipotle.livejournal.com]

Zope is nine levels of evil. Instiki is only two or three. If you're willing to give people a funny URL and your web host allows people to connect to nonstandard ports, you don't actually have to do anything for Instiki to make it accessible -- otherwise, you do have to set up a proxy thing in the main web server's config file, which can range from "that was much easier than I thought" to "why don't you just shove a fondue fork up my nose" depending on circumstance.

Instiki's biggest problem is becoming the fact that nobody is really maintaining it, despite the occasional protest to the contrary. You could check out "Junebug Wiki" (http://www.junebugwiki.com/), which seems to be doing much the same thing -- including Textile support -- but without having Rails attached to it. Junebug requires the same sort of proxy as Instiki, although I think their minimalist "how to install" page is actually clearer than Instiki's. (If you can set up the wiki as a virtual host -- with its own domain -- life becomes much easier. I use Instiki for ESM's wiki, and "wiki.esmuck.net" is its virtual host.)

When I looked around last year, there weren't any wikis in PHP that used Textile or Markdown, although that may have changed by now.

[shatterstripes.livejournal.com]

I should note that I wrote the original post WITHOUT actually trying to, you know, do anything with Zope. It does definitely look like a big, heavy framework.

I've found that most of these OMGWEBTWODOTOH programming frameworks go up to the fondue fork level of annoyance. I like to try and play with them now and then but I tend to give up before getting to the point of actually being able to play with anyone else's code because there's sooooo damn much UNIX hell to wade through.

Wikis using something besides wiki markup is a relatively rare thing, in my experience. It's like web forums using anything besides that furshlugginer 'bbcode' markup* - there's just so much history in that domain. Doesn't matter what it's written in, it's going to use the standard markup for that domain.

* bbcode has always rubbed me the wrong way: it's [i]just[/i] enough like html to trip me up, constantly. especially the weird, inconsistent-between-boards handlings of [img] and [url]. If I ever run a forum attached to a project of mine, I will be picking it largely on the basis of HAVING TEXTILE/MARKDOWN PLUGINS THAT AREN'T TEN YEARS OF HATE TO INSTALL.

Instiki

[http://golem.ph.utexas.edu/~distler/blog/ (from livejournal.com)]

Like any Ruby-on-Rails application, Instiki requires something like FastCGI to get decent performance. If your webhost supports FastCGI, it's a modest configuration tweak, to get Instiki to run under your webhost's webserver.

If your webhost doesn't support FastCGI, then, yeah, you can use the built-in webserver and run Instiki on a high-numbered port (default is port 2500).

As to whether Instiki is still being developed... well ... I've seen more active projects.

There were a bunch of commits to the SVN trunk on January 14-19. Before that, the previous rash of commits were September 6-19, and before that, in May. As far as I can tell, there's one guy working on it (very much part-time) and he doesn't answer his emails.

On the other hand, it had the features I wanted, and I could hack on it (http://golem.ph.utexas.edu/~distler/code/instiki/svn/) to my heart's content.

Re: Instiki

[shatterstripes.livejournal.com]

Ultimately that last is what makes a tool attractive, isn't it? 90% or more of the features you want and code you can hack when you get a new idea. And after a certain point 'active' is not an issue; continuous developer activity after it's arguably done is how you end up with impossibly unwieldy tools.

I've never actually gotten a RoR app running; as noted in the comments above, for all its popularity among Powerbook-in-a-cafe types, getting a local OSX install running is a complex and frustrating beast. And I got spoilt by testing locally; I'm not about to try and develop on my remote host!

Trivial!

[http://golem.ph.utexas.edu/~distler/blog/ (from livejournal.com)]

I'm a MacOSX user, too. Instiki is trivial to install and run locally. I described the (minimal) prequisites in my post. (Well, OK, they're minimal if you have Fink installed. Maybe less so, if you have to install everything you need manually.)

Then you type ./instiki --daemon, and -- lo! -- you're running a Wiki on http://localhost:2500/.