 |
You scored as Deacon Frost. Yeah you are the take no prisoners it’s my way no matter what you have to do vamp surrounded by lots of hot chock vampires
|
Whose your Vampire personality? (images)
created with QuizFarm.com
Archive for August, 2005
I just got finished building, testing and launching a simple application for a client of ours using the PEAR package DB::DataObject. I also used the Form_Builder class that’s based on DB::DataObject, but it’s not very well documented, and doesn’t really have a complete API.
I have to say, that has been the fastest development time I’ve ever had for a database application from scratch. 9.5 hours, including the administrative functions, bug testing, and bug fixing, is all it took. It isn’t pretty, and could use some color, but that wasn’t my goal - it was to build a functioning web-based file manager from scratch, and I did it.
Why, you might ask, does a web-based filemanager need a database for anything other than authentication? Simple - I needed to be able to track all of the files, and have a method of assuring that the data was preserved properly - regardless of platform.
Here’s how it works:
Each time a file is uploaded, the application generates a UUID, and saves the file with a filename OF the UUID. It then stores into the database the UUID (as a primary key), the original file name, the current path (for future expansion), the mimetype, the user ID of the uploader, and other logging information. When someone retrieves a file, it takes the UUID from the URI and pulls the information from the database, opens the file for reading, and puts out a couple of Content-based HTTP headers before streaming out the data. The end user gets a save dialog (if their browser accepts the “disposition” data), with the correct, original, filename. The user never knows where the file is stored, and could not possibly guess the filename based on the UUID. This allows for privately exchanging files through this system, the only time the filename appears is when the Content HTTP headers come across the wire.
Yes, I’m using it. Yes I like it. But dammit, people, it’s JUST another IM service!
It’s convenient as I don’t have to make an account, and I can make as many “identities” as I have GMail invites. Which is to say, a lot.
By the way, if you need a GMail invite, let me know in a comment.
For those of who have any idea what RSS is, this is neat! For those who don’t, well.. I can attempt to explain.
RSS is a protocol for extracting “news” from a particular source using a language called XML (eXtensible Markup Language). XML is very similar to HTML, in the sense that it “describes” the data. It doesn’t, however, have any means of making the text appear different.
Anyways, an RSS aggregator is a program that will hit the RSS “feed” of several websites, and pull it up into a single page to view. Slashdot is, essentially, a news aggregator, and has several RSS feeds you can choose from. You can do all sorts of neat things with RSS feeds, as they’re written in XML, which the newer “HTML” is based upon. You can easily convert it into a block of HTML and have it spit back out as part of a web page. It’s how I got the posts from BEFORE I set up this weblog (from truth.mygamefactory.org) to appear in the blog. It pulled the information using RSS from the Truth website.
What happens when you combine this with AJAX? Well, it may not seem like a lot, but it allows for some really neat things. AJAX, as you may or may not know, allows a webpage to be a “gateway” to server-side instructions, but without reloading the page. That is, it gets around the “stateless” limitation on HTTP, and allows you to click a checkbox, and bam! A whole new page appears. Basically, what this aggregator does, is it keeps all of the actual operations of checking the news sites, database interaction and the like “behind” the page you’re cliking on. This means the view pane just adjusts when you click on a different site or article, retrieving the information directly. What’s REALLY cool about this takes some thinking to wrap my head around: I can read all the web-pages I like that support RSS all from one place. If there’s something new posted to the site, I’ll see it in the RSS feed almost immediately. I can then play around with how it looks and never have to worry about that site’s clunky or difficult to navigate interface again! I still read their content, and they know it, but I can instead enjoy the experience how I want to enjoy it.
After writing a response to a comment left by Adrian from the Django Project, I got to thinking, and decided to try the mod_python method of hosting a Django application.
It appears that the problem isn’t necessarily with Django, but python is missing something. I’m still new to python, so it could have been my gaff.
I’ll have to research this some more.
Update: I updated via SVN today, and that opened up a whole new can of worms. The model structure has changed, breaking it in another way. After further research, Hugo let me know that Django will NOT work on mod_python 2.x on Apache 1, it needs mod_python 3+ and Apache 2. I’m still not seeing this in the documentation, but I could just be missing it.
Today I spent several (read: about 4) hours working with and toying with a neat little web application framework called Django. It’s very much like working with Ruby on Rails, but a little bit more intuitive.
The downside is the documentation is only slightly poorer than Ruby on Rails’ documentation, which is to say, not very good. The tutorial helped quite a bit with the basics, but even that does not work “out of the box“.
I’ll keep working on it, as I’m interested to see if I can whip up an AJAX implementation for it, making data entry web applications easy to put together.
That’s right, in a matter of a few hours, I can build you a character database, fanboy!
I like both online games I’m currently playing in, but I know I’m spending too much time online, playing them. I don’t want to give either of them up. I really like Liz’s game so far, even if I’ve had little time to dedicate to it. And John’s game, well.. What’s NOT to like about it?
On the other hand, my character hardly needs to be around in John’s game… Liz’s game is in the other end of the spectrum. If I’m not there on game nights, I miss way too much.
Conundrums.
Well, I’ve created my first AJAX application (with a few bits of help from formassembly.com), and it works beautifully. I can’t wait until WordPress starts implementing it. That would make for some interesting ways to extend it, that’s for certain.
Hmm…
Base:
Polymer (or something) board, about 2 cm thick, preferably dark or black opaque. 2 meters wide by 1.125 meters tall (16:9 aspect ratio). Preferably non-conductive – but something conductive could prove useful for additional applications.
One side (front) is covered with several rows of OED strips made by the “forest†process developed by UTDallas.
On the opposite side is several rows strips, but specially made by a process based on the UTDallas process. (See below).
Each edge of the “screen†is covered by an end-cap that contains thousands of nano-machines. These manage connections between the screen, and whatever functionality can be provided by special modules attached to the end-cap. That means there is about 6.25 meters of “real estate†that can be used for various modular functions. The modules would either access the back panel, front panel, or both.
When a module is attached to the end cap, it will take some time for the nano-machines to “read†the programming information “broadcast†by the module, but once they do so, they will begin connecting the many thousands (millions?) of nanotubes to their appropriate locations (front and/or back).
Back-side process:
The creation of the backside strips would need modifications to the UTDallas method. The drum would need an array (like a print-head) of nano-machines that will place “end pointsâ€, “y-junctions†and many other necessary modifications to the nanotubes as they come out. These modifications will be sent via software to the “printerâ€, so as to make:
- An array of memory (potentially in the terabytes per meter?)
- An array of processors (SMP, all the same kind “patternâ€, with a few of the nano-tubes dedicated to inter-processor communication)
- Multiple different processors
- One large processor (multiple k-bit in complexity?) that can be software-driven to emulate several virtual machines)
- An array of solar collectors for powering the device
The first four can be combined to create a consumer electronics device with the ability to have modules attached for gaming, computing, large scientific calculations, business functions, tele-conferencing, broadband internet access, wireless networking, home management systems, etc.
Modules:
The modules could use current consumer technology attached to the endcaps of the “screenâ€. What this means is, you could plug in, for example, a “Television†module, that would include a basic cable receiver, HDTV receiver, digital and/or RCA inputs, power input (for the receivers), and a remote control module. The consumer would remove a dummy plate from the appropriate place on the outer frame of the “screen†that covers the endcaps. The module would replace the gap in the outer frame, and after a few minutes of “synchingâ€, the television functionality would be available. The remote control module would be attached to the stub remote control that the device would come with, adding the functionality to control the television.
The synching process would probably use something similar to Bluetooth to communicate with the nano-engines to explain what connections it needs, and where. The module would be programmed to only go in one, maybe two, places and work. Therefore, the nano-engines would need to be on a peer-to-peer network to communicate with a base processing module to figure out if the device is in the right place or not. After the end-points of the module is found by the nano-engines, and it’s confirmed that it’s located properly, the nano-engines get to work establishing the connections. It may even be possible to make this visible to the end user – that is, the module will noticeably shift further “into†the endcap as the nano-engines pull the endcap open, and pull the module closer, literally by the nanotubes. Once it’s attached, forcibly pulling the module out will be VERY difficult with the number of nanotubes attached to each other. There should be, however, a process for removal of a module for later “upgradesâ€.
Other module examples:
- Parallel processing manager (cluster) for scientific processing and extremely detailed 3D renderings
- Multiple processor (128, 256, 512)-bit gaming system(s)
- DVD Player
- UMD disc player
- VGA converter to use the screen as a standard PC monitor
- Broadband internet access with built-in kiosk-type operating system (Knoppix?)
- Video-phone (built-in camera and microphone or Bluetooth headset) that can be used over POTS, ISDN, or broadband internet access.
- Wireless household manager – would manage Bluetooth networks, automated home modules and the like from the screen, with on-screen help.
- One complete system using the entire backplane to emulate all the functionality, or to create, effectively, a supercomputer.
- Linking module to link multiple screens together (special case, this would attach to two screens)
- Linking module to link two back-planes together (again, special case, this would attach the two backplanes together for more memory/processing power)
- Linking module to link front and back
All the modules should integrate with each other, so they should either communicate with the same protocols (IPv6?) and/or run the same basic operating system.
The modules might never even hit the consumer market – one could build the base platform in mass production, and then ship them to other manufacturing plants to add on the different modules, and in turn ship them to stores or consumers directly.
Consumers could order customized systems with all the functions they want/need.
The screens would be cheap to make, especially if the backend is made as a solar-collector or simply blank, meaning all sorts of companies could buy the screens, cheaply, in bulk, and make their own devices out of them.
The screen size, by the way, is not set in stone. Several different-sized screens could be made, and the process could be used to make specific devices, as well, such as a 6-inch screen that has a hard drive attached to it – a hand-held movie screen that can store 20 or more DVD quality full length movies. The only PC-board in the device would be the hard-drive’s management board, and probably a small piece to attach the drive to the nanotube-based processor (on the back-side of the screen).
Research:
http://www.sciam.com/article.cfm?articleID=000093C3-E0C8-12FC-A0C883414B7F0102
http://www.utdallas.edu/news/archive/2005/carbon-nanotube-sheets.html
http://www.azonano.com/news.asp?newsID=677
http://www.plausiblefutures.com/cparticle79052-6987a.html
http://www.sc.doe.gov/bes/reports/files/SEU_rpt.pdf
http://www.ansatus.com/