I'm not out of the woods yet. In fact, I'm not sure I'm even in them yet.
However, I'm learning about interesting python web techs. I'm sure you've run across WSGI? It's basically a really simple way for framing webapps so that you can pick them up and plonk them into different contexts? It's partially a PITA, but in some ways it's great.
Basically, I can write a WSGI app and then decide that I want it running as an SCGI app or a Fastcgi app or an AJP app, or a cherrypy app or whatever the hell I decide, so long as the framework just treats the app in the way specified in the WSGI. Kinda cool separation of concerns. Also, flup is a cool project - it's what I'm using for my scgi app for the project and it's rather cool. There's SFA by way of useful documentation, but I may actually want to step in to rectify that.
The big problem I have with WSGI and flup and all of that is the minor fact that environ["wsgi.input"] is a right pain to parse when you get post data. Incredible pain. That's where the wiki falls short, and I want to just get myself to the point of understanding it just enough that I can contribute meaningfully to the wiki.
Actually, ever find that? For private/non-public wikis (why I say private/non-public, I don't know... for some reason I feel there should be a delineation between private and non-public) I'm far more cavalier. In Sun, for the group wiki I'd fill it with what I thought was going on, and I'd document like a demon. But for a public wiki I'm far more reserved. In a way, it seems strange; if a project is public there are more contributors who will be around to correct mistakes and fine details, but I'm still more reluctant to wade in.
Yeah I've heard about WSGI, however the thing I'm working on is Zope, which is massively complicated and... 'javaish'. WSGI looks nice alright.
Re: wikis, I can totally understand that. I think there are a few fears at play. Firstly the fear that one'll accidentally reveal confidential data. Secondly the fear that one will say something not right and somehow it'll look bad for you/your organisation. Also with internal wikis, you know who's going to be looking at it, and you know who'll be reading it. You can be pretty confident that someone reading it is fairly techy. With public ones joe randomer might use it. This means you have to be more careful. The techy reader would be able to catch a mistake, joe randomer might not. No-one wants to give bad advise.
However, I'm learning about interesting python web techs. I'm sure you've run across WSGI? It's basically a really simple way for framing webapps so that you can pick them up and plonk them into different contexts? It's partially a PITA, but in some ways it's great.
Basically, I can write a WSGI app and then decide that I want it running as an SCGI app or a Fastcgi app or an AJP app, or a cherrypy app or whatever the hell I decide, so long as the framework just treats the app in the way specified in the WSGI. Kinda cool separation of concerns. Also, flup is a cool project - it's what I'm using for my scgi app for the project and it's rather cool. There's SFA by way of useful documentation, but I may actually want to step in to rectify that.
The big problem I have with WSGI and flup and all of that is the minor fact that environ["wsgi.input"] is a right pain to parse when you get post data. Incredible pain. That's where the wiki falls short, and I want to just get myself to the point of understanding it just enough that I can contribute meaningfully to the wiki.
Actually, ever find that? For private/non-public wikis (why I say private/non-public, I don't know... for some reason I feel there should be a delineation between private and non-public) I'm far more cavalier. In Sun, for the group wiki I'd fill it with what I thought was going on, and I'd document like a demon. But for a public wiki I'm far more reserved. In a way, it seems strange; if a project is public there are more contributors who will be around to correct mistakes and fine details, but I'm still more reluctant to wade in.
Reply
Re: wikis, I can totally understand that. I think there are a few fears at play. Firstly the fear that one'll accidentally reveal confidential data. Secondly the fear that one will say something not right and somehow it'll look bad for you/your organisation. Also with internal wikis, you know who's going to be looking at it, and you know who'll be reading it. You can be pretty confident that someone reading it is fairly techy. With public ones joe randomer might use it. This means you have to be more careful. The techy reader would be able to catch a mistake, joe randomer might not. No-one wants to give bad advise.
Reply
Leave a comment