(why write my own material when I can just republish things Atli says...)
"My biggest nightmare: pressing Send and noticing 'everyone@internet.com' in the TO list! (which would of course leave a copy of the email on every computer in the world)
;-)
On the nintendo wii you are represented by a character known as a Mii -- a little avatar that represents yourself. It has a cartoonish appearance, reminiscent of those WeeMee characters I've seen around.
Here's the clever bit:
This same avatar can be taken from one game to another, and even from one Wii console to another.
Extending this idea -- there could be a type of avatar that moves not only within nintendo consoles and games, but into games on PS3, Xbox live and other consoles.
Extending this extended idea -- there could be a type of avatar that moves not only within game consoles, but into MMORPG's (WoW) and applications like Second Life, Instant Messaging, Skype, online forums, chat groups and so on.
This has some surface similarity to the idea behind the Gravatar implementation (and the related Pavatar concept).
At a deeper level, it's probably more similar to the idea of an OpenID.
(What ever happened to OpenID, by the way? In February it was the Next Big Thing... 5 months later and I've hardly heard a peep about it)
If custom attributes can be added to an OpenID, then this could include avatar information, or even a set of different avatars.
Anyway, that's the million dollar idea for this morning. Go build it, fat head.
(btw, I'm not one of those wacky second life addicts [hat tip to "you know who you are" ;-) ] -- but I can see that this stuff is gaining traction quickly. Also I deliberately don't own any game consoles)
Here's some more nintendo Wii links:
(Okay this won't necessarily make any sense.
I've been thinking about three different but similar concepts.
They're all based on this template:
Separate your $x from your $y: how why and why not?
where $x and $y could be:
Let's start at the end: code and data. How are they separated?
First consider those three famous security holes: "buffer overflow,
sql injection and cross site scripting (i.e. xss.) They're all caused by
exploiting the blurry line between data and code.
So it's easy to jump to the conclusion that a blurry line between data and code is dangerous... we're only safe if we keep our data and our code separate.
But this is powerful magic: mingling code with data is powerful stuff! yes, it must be handled with care, but it must be handled.
Lisp is generally said to blur the line between data and code, because you can't interchange one into the other so easily. <rolls eyes... he's mentioning lisp again... here we go> chill winston! it will be okay!. But I don't see where this makes lisp so special. The whole von neumann processor architecture, is based on reading instructions and data from the same place.
Oh, here's a quote from Paul Snively that says it well:
So this incessant harping on data-as-code and code-as-data in Lisp merely obscures the fact that data is code and code is data in computing. That's the lesson of Lisp, but unfortunately it's gotten lost in the Lisp dogma.
This reminds me of something I heard at uni, and haven't thought about until now: There were apparently some early processor architectures in which data and instructions were kept in separate memory units. The 'instruction pointer' would be up to one place in the instruction memory, and the 'data pointer' would be up to a different place in the data memory. (Ah! It's called the Harvard Architecture, tanks agen, wikipedia)
This model died, and von neumann architecture won out. So, tody we have "instructions and data" in the same place, interchangeable and ultimately it's anybody's guess what makes for data and what makes for code.
You might say that code is 'whatever gets executed.' But, if code isn't yet executed it's still code, not just data. And just because code has been executed doesn't mean it stops being data. So I don't think there's a distinction between them at low levels. At higher levels, there can appear to be a distinction, but at the highest levels, the distinctions disappear again, lisp etc. Anyway, I'm lost in this paragraph: i'll move on to the next bit: the separation of business rules from everything else.
This is pretty much accepted dogma in the n-tier custom software world where I live. But it's impossible to enforce absolutely.
What exactly is a business rule? How and when does it differ from everything else in the solution?
i like this quote from wikipedia:
"There exists no definition of business logic in any programming language specification or API, nor in any academic research. However, usage of the term persists in trade publications..."
but be careful -- if you stop believing in the existence of 'business rules' you might vomit up the kool aid -- spit out the red pill, and do a Gunderloy ;-).
So what am i saying? have i become a business rules atheist?
Never -- i've just started to realise that there's some business rules that live in the presentation layer. There are some business rules that live in the database. And there are some things that aren't business rules that live in the business layer. It's all fluid, like Thermodynamics, baby
Pragmatism: that's the ticket!. Given a particular fact in our system, what is the likelihood of it changing: based on our own experience? and where can we place this fact so that it fulfills some optimum combination of:
Much to say -- but no motivation to share it (right now).
The final topic is separation of content and presentation... but right now the brain is overloaded. Discuss quietly amongst yourselves. Teacher has a headache.
I'm not a lawyer... but i'd like to wade in on contract law a little if i may ;-)
This entry, from Cem Kaner, "A first look at the proposed Principles of the Law of Software Contracts", was mentioned in Larkware today.
It includes this snippet of the proposed principles:
"a vendor who knows of a hidden material defect in its product
but sells the product without disclosing the defect
is liable to the customer for damage (including expenses)
caused by the defect."
(And Adam Goucher has more here.)
Legal stuff always raises more questions for me than it answers. And a bunch of questions jump out from the little that Cem has quoted.
F'rinstance, what about: a vendor who knows about a defect, but considered it immaterial? This happens all the time.
Or, more common still: a vendor who has an employee who momentarily knew about a limitation of the product, but didn't expect that that limitation would lead to a material defect?
You're writing some code, you choose to implement an algorithm in a particular way, which has a limitation.
You don't consider the limitation to be major, so you don't document it. But since you wrote the code, it's clearly evident that you did know about the limitation at the time you wrote the code.
The limitation isn't revealed by the sort of testing a 'reasonable' buyer would perform, and it isn't mentioned in documentation.
When put out in the field, the limitation causes some material defect in the behaviour of the software, that has massive consequences.
For example: the medical system you're writing didn't correctly handle the turkish letter "i"... hence a patient slipped through the system and died.
Go at it, legal geeks.
(Or can we adopt the Asmiov/Denny inspired "Laws of Software Development" instead?)
From Atli in the TimeSnapper forums, had to republish this one ;-) ...
I just bought myself a webcam and have experimented with programmatically taking snapshots - works pretty sweet - and I actually think it could make for a nice addition...
Later on, you could play back your year and exactly pinpoint the when and the why you went bald! (pretty sure it's related to a whacky debugging session )
wish I had this feature a few years backCheers
Atli
This is kind of embarrasing, but what the hell, i'll share it anyway.
While I'm generally messy, disorganised etc., I have created order in one particular part of my life: the 'master shopping list'.
this sounds like the nerdiest, most anal thing imaginable. People -- even nice people like other programmers -- think this is a freakish and terrible thing to use. Well, stick it Jack. The list works a treat!
what i've got is an excel spreadsheet that contains every item we buy from the grocery store. The spreadsheet is laid out in the exact same order that the products are located in the store.
this master list makes it much easier to prepare for a shopping trip, and makes it almost impossible to forget things when you're there.
The first problem this list solves is those rare items that you run out of much less often than you go shopping. it's so easy to forget that you're almost out of toothpaste, or deoderant.
the biggest benefit of this list was something quite unexpected. thanks to this list we now only need to go shopping once every 3 or 4 weeks. And when we do go, the trips are quick, and stress-free. (dairy products and fresh fruit n veg are a different, much faster, weekly, task)
The question is: do i want to take this nerdy list one step further? the next thing would be to add a "minimum shelf level" for each item, as well as a re-order level. For example, "reorder pizza bases if there's less than 2 remaining -- and restock them up to a level of 5." It's too nerdy... yet tempting.
but it doesn't end there... oh no. there's three more steps i can see beyond that.
I have this idea (i've mentioned before) where I fix barcode scanners in strategic places around the house.
Each time i throw something in the bin, i scan the barcode using a scanner next to the bin. [Forget RFID -- that's a different blog entry ;-)] The stock level is decremented. Magic. When I first collect the groceries, i scan them all -- incrementing the stock levels as I go.
Each scanner has a dedicated task, depending on its position. The one next to the bin for example only decrements stock. The one on the kitchen bench only increments stock. Usability is a no brainer. No buttons to press, no menu options to pore through. (Wait -- Perhaps I just scan my receipt from the grocery store -- and use OCR to find the SKU codes and increment all the stock levels).
Well the next step is to automatically fill out the shopping list, based on the consumption to date. But better than that -- I'd email the shopping list to the local grocery store.
No -- better still -- email a local delivery agent, whose job it is to source all the goods on the order, from whatever store will give the best prices. If they constantly receive such orders from households in their area, the delivery agent can optimise and amortise their deliveries, effectively solving the last mile problem.
But there's a step beyond that. Rather than giving the local delivery guy a monopoly on supply, the orders could go to an online exchange, where they are effectively auctioned off, automatically, to the lowest bidder. (Or where they are used as bids against inventories put up by various local businesses). The inventories of local suppliers, the requisitions of local consumers and the services of delivery agents, could all be brought together in one fluidic online marketplace.
Of course you don't want to have just one market place. You want a series of market places, which all compete to provide the best three-way matches between consumer, producer and supplier.
Hey, do you want a server farm with that bottle of milk?
See also... the 'domestic bits' series from secretGeek ;-)
Purchase TimeSnapper in the next five minutes and half the proceeds go to help fight diabetes. Last grains of sand trickling through the hourglass on this promo. After that, please donate directly.
(If you narrowly missed out -- just ask us and we'll still send on half your ticket price as a donation.)
Almost two weeks ago I announced that we'd be giving money to help cure diabetes, on your behalf.
The deal is that if you buy TimeSnapper, we'll give half the ticket price to help Team Hanselman (and the American Diabetes Association) Fight Diabetes.
A big thank you to those who have taken part already. There's been some great feedback and messages so far.
Our promotion is ending soon! If you wanted to take part, then you've got to hurry, there's less than 24 hours remaining!
(You'll still be able to make a direct donation, which will be tax deductible. But if you want some TimeSnapper power to go with that good feeling of giving -- purchase now!)
Joe Cooney was telling me about some Million Dollar Ideas of his, and they were nice. But since then I've been thinking about Big Problems. Really Big Problems -- and here's four of them, as an example.
If anyone can demonstrate, on a global scale, a working solution to one of the above problems, I'll give them a free license for TimeSnapper professional.
Sometimes all that the great thinkers need is a little encouragement. Go on sparky. Fire up the grey matter.
I didn't want to make this challenge too easy, so I left off these three other problems:
An old friend of mine is now a senior partner at a large global accounting firm. Apparently he bills his time at something like $600 an hour.
So when he had a BBQ on the week, I enjoyed asking him really detailed questions about what sort of things I could get tax deductions on. What are the specific laws about deducting laptops, computers, pdas and so on. Any answer he gave I'd grill him in detail to try and pick holes in his knowledge. Really helpful stuff, much appreciated.
After a few hours of this, during which time I'd drunk quite a bit of his beer, enjoyed a big meal he prepared, and sampled all sorts of expensive wines from his growing collection, he mentioned that his printer wasn't working. Could I take a quick look at it, it's probably something dead simple, he said.
Your printer? for god's sake. What the hell do you think I am? some kind of bloody 'technician'??
Boy some people are rude. Some friend he turned out to be.
(btw, the facts of this story have been altered for the sake of humour.)
secretGeek.net