A replacement for email? Finally? Google seems to be on track to reinventing not only email, but the complete web-based communication experience.
http://wave.google.com/
Oh, and for all you Firefly fans, notice that Google is appropriating the show's nomenclature of "sending a wave".
http://wave.google.com/
Oh, and for all you Firefly fans, notice that Google is appropriating the show's nomenclature of "sending a wave".
I'll drop this into the Inter-ether-pool. Maybe someone else will be inspired. It's a note I made some time ago. What could be done with this notion?
Better business through ceremony
There are better ways than this, especially in Ruby on Rails, but here's a manual idea for managing database changes during development.
- All database change scripts be put in _db directory
- Three kinds of scripts:
- create_db.sql, which drops all existing database objects and creates the original schema.
- alter_db_yyyymmddThhmmss.sql, which changes the schema.
- update_db_yyyymmddThhmmss.sql, which changes the data.
- With this method, the entire schema can be recreated by running the scripts in order. (update_db is obviously a problem.)
- Scripts should run within transactions.
Everyone gets that I'm cleaning up files, right? Here are some notes I made about how computers should work. I don't think this is operating system-specific.
Windows is sort of moving in this direction, as is/has Linux. Mac might be pretty close--I'm not a Mac guy.
This came about because I think it's ridiculously difficult to restore a computer. It really should be as easy as 1) reinstall operating system, 2) copy program folders, 3) copy user folder(s).
Windows is sort of moving in this direction, as is/has Linux. Mac might be pretty close--I'm not a Mac guy.
This came about because I think it's ridiculously difficult to restore a computer. It really should be as easy as 1) reinstall operating system, 2) copy program folders, 3) copy user folder(s).
- Everything needed to run a program should be in a single directory, under a definitive top-level "programs" directory. The OS just searches this directory to display installed programs. The program's name, settings (per user) are all found in published ways. This is true even if the program is a service.
- The reason to keep all user settings with the program is to make transferring/reinstallation easier.
- All of the program's licenses are kept with the program. If a program is transferred to a new machine, the program can contain a public/private key method of knowing this and prompting for the installation code.
- All user data should be under a single "data" directory, per user. The tricky part is preventing--or at least discouraging--users from storing data elsewhere. Each user's data directory should have a Desktop folder, for example.
- In other words, there are three essentially separate areas that talk to each other: operating system, programs and user data.
Notes
-----
* It might be better if user-specific program settings are kept in the user's folder. Might make security easier.
* Windows sort of does this (user folders w/settings). But, they also keep settings in the registry, and in two user folders, and sometimes in INI files. Blech!
Yet more notes as I clean up my computer. My favorite is this one, and remains true.
Glancing over the rest of these, there are several I agree with, and some that I don't. A lot of my software methodology notions have been answered by Scrum. But not all. Not all. :-)
software projects
* estimating
* relate size to duration? How about size to price (regardless of cost/duration)? (small, med, big, huge)
* what are common elements?
* how much info is needed to make estimate?
* what info is needed to make estimate?
* estimate hours for cost and duration for schedule.
* tasks
* just a few (ten) top level deliverables/milestones
* estimate resource hours against tasks
* the more parts there are to a task, the less accurate the estimates for those parts have to be, as long as the task estimate is accurate.
* what about weekly Monday releases as tasks, with a supporting document (release features) for each task. This is easy to understand.
* confidence
* the biggest fear is that something will break
* when a client starts asking for documentation, they're losing confidence.
* however, when useful documentation is supplied as part of the project, confidence increases.
* clients like it when you seem prepared. They like it even better when you really are.
Eighty percent of project duration is getting agreement.
Glancing over the rest of these, there are several I agree with, and some that I don't. A lot of my software methodology notions have been answered by Scrum. But not all. Not all. :-)
software projects
* estimating
* relate size to duration? How about size to price (regardless of cost/duration)? (small, med, big, huge)
* what are common elements?
* how much info is needed to make estimate?
* what info is needed to make estimate?
* estimate hours for cost and duration for schedule.
* tasks
* just a few (ten) top level deliverables/milestones
* estimate resource hours against tasks
* the more parts there are to a task, the less accurate the estimates for those parts have to be, as long as the task estimate is accurate.
* what about weekly Monday releases as tasks, with a supporting document (release features) for each task. This is easy to understand.
* confidence
* the biggest fear is that something will break
* when a client starts asking for documentation, they're losing confidence.
* however, when useful documentation is supplied as part of the project, confidence increases.
* clients like it when you seem prepared. They like it even better when you really are.
Next
Search



