My blog has been renamed to reflect a continued technological theme, but not completely programming related on every post. Enjoy.
Monday, February 27, 2006
I caught wind of InnoScript's Porcupine realease, today. They seemed to have done something pretty spiffy, even though most of the work is done by XUL. It says it works on IE, as well as Mozilla browsers, but I'm not sure how that works if its a XUL-based system.
The whole time I looked around in the demo, I kept thinking to myself how things like that could be done in Athena, and what is there to support it today and what is missing that needs put in. The Divmod-guys didn't seem opposed to that sort of thing.
at 8:23 PM
Sunday, February 26, 2006
Friday, February 17, 2006
RSS, Atom, and Feeds, oh my! All terms that get tossed around lately more often than Dick Cheney hunting jokes on the Daily Show. In a world of increasing information overload, feeds and aggregation are the emerging solution to tackling the problem of "How do I deal with all this stuff I could know?"
Like any new technology, feed syndication is not without its problems and limitations, and I would like to bring up a limitation today: the Web is more than a source of content, its a collection of interfactions with that content, and feeds only syndicate the content, ignoring the interaction.
Where is the syndication of interactivity to various web services? To begin with, how about letting my news reader include all the commentary to the article and allowing me to comment myself, without going to the original website? As long as I'm getting new recipes every day, why can't I just as easily (and, from the same place) submit my own? The web was always meant as a two-way medium (the original web browser allowed you to edit and repost pages you had access to), so if RSS is the evolution of the web, it needs to bring interaction along with the content.
at 8:55 PM
Wednesday, February 15, 2006
Since I have begun a career as a "professional web developer", I've thought that maybe I should come up with a personal web project for myself. I usually prefer non-web work for my own stuff, but the challenge to do really good things in the limitations of a webpage is pretty cool. So, what should I do? I've thought of some ideas, but I'm not sure which would be the best...
- A virtual pet website, with actual interactivity with your pets, who will be driven by similated biochemestry and artificial neural networks, much like Creatures.
- A web-based Python IDE, designed to be used by other applications or stand-alone.
- An artificial neural network development suite as a webapp.
- A waste-my-time website full of different web-based games you can play with other users anonymously (ie, no registration. just go and have fun.)
at 10:06 PM
Sunday, February 12, 2006
Slashdot | One In Two PCs Won't Run Vista's Interface
But 100% of the OEMs' systems built specifically for Vista will run it just fine, and who cares about anything else? Joe-user doesn't upgrade windows, he buys a new computer. If you upgrade your OS yourself, you're going to have a better graphics card, anyway, most likely.
Another thing I am tired of hearing about is claims of "Aero will burn through my electric bill" and "Vista will kill my CPU with its fancy GUI!", because it is all FUD. Moving more of the GUI processing off of the CPU will improve overall system performance, user productivity, and there is nothing forcing a hardware-based GUI to keep a frantic framerate like any game.
Slashdot, you found me some great things, when I didn't know any better. Now, you're mostly a source of things for me to get angry about and try to correct.
at 9:51 PM
Saturday, February 11, 2006
Brett Cannon: Clarifications on LINQ: "Calvin Spealman set me straight on the true importance of LINQ."
Well, what an interesting start to an article in my news reader. Yes, I am Calvin Spealman. Brett goes on to talk about some details of this, mostly repeating and rephrasing what I set him straight on (his words, not mine), in reguards to LINQ.
Although we can not, at this time, get the AST for any expressions or blocks prior to compilation, I don't expect or see how or why we would reach this at Python 2.6, either. Firstly, I don't see how python would no to not-compile anything without some special "this is meant to be used just for its AST" syntax. Secondly, I doubt it would be any cheaper to generate the AST without compiling it into bytecode, after factoring in the time it might take to figure out if you need to do so or not. The most likely and efficient way will probably be the most obvious, in this case: pass a function object, built with def or lambda, but expressions by themselves (ie, not lambdas) will be pretty unusable. Anything else would require some kind of mechanism to know that a parameter expects AST, and that would break the python function model. So, barring anything along the lines of function decorators that say "parameter 3 gets the expression's AST" and hooks in the function call mechanism to catch this sort of thing, I don't see the direction of the Python 2.6 comment. Besides, anything along those lines seems like it would pose some serious security risks.
Am I misunderstanding the statement?
at 10:26 PM
Wednesday, February 01, 2006
I am not a core Nevow developer, but am only a developer who uses it. I do talk a lot with the developers, and try to keep up with what is going on there. So, I do know a bit about what is going on, and where things are supposed to go. I know that contexts (a type of object passed around that gives access to the current tag being rendered, remembers adapters between interfaces, and does other stuff that isn't so good) is supposed to go away, eventually, at some point, somehow. There is little talk of how, when, and that sort of solid thinking on the subject.
So, for the heck of it, I'll propose a plan of action, and this is it.
Fork it, so that all the refactoring can be done and if anyone needs a backward compatible Nevow, it can still be around for them. There is already xmantissa and xquotient, so it wouldn't be a stretch to add xnevow. My other favorite is to just say that Athena is the new Nevow (see Step #2)
Pull everything out of the fork that Athena doesn't need, so things can be focused. Refactor so that there is no difference between Page and LivePage, and you can just make any page become live. At this point, things can start to change and context can be factored out entirely. New flatteners would be needed, of course, but those should be more or less straight forward to adapt.
Expand the templating system to be smart enough to handle both server- and client-side work. I recommend a nevow:insert directive that defines sub-templates to fill and insert the resulting node at some place, which could replace nevow:pattern and also carry over for used in live pages on the client. While we're at it, add in some good widgets to start with, like containers and tabs and such.
Create a fake nevow module that can map existing API calls to the new stuff that would be in xnevow/athena. This would allow for easier transitions to the new system.
I might try and convince the usefulness of this to an employeer and see if some of my project time can be spent sprucing up athena in such a way, depending on just how much this would take to be really useful, or just usable. Then I could contribue something useful, and get some moneys.
at 7:26 PM
- ► 2012 (19)
- ► 2011 (19)
- ► 2010 (32)
- ► 2008 (28)
- ► 2007 (113)
- ▼ February (8)