No one is saying you can't drive, yet. Presuming that computers eventually are better than people at driving, can we as a society continue to allow humans to self-control death machines in close proximity to each other?
3,011 karma · joined March 13, 2008
Imagine that you ordered something from Amazon. You could choose from a bunch of different times, perhaps a dozen in a day, when the automated delivery truck would swing by your house. Your phone would make a noise, and you would go outside to grab your packages off the truck. It would be like an Automat (http://en.wikipedia.org/wiki/Automat) on wheels. You would somehow authenticate yourself and then grab your boxes from your assigned slots.
1. When paying full-fare, flights are fully refundable. Not sure when you are flying home? Just book a bunch of flights. Even with the restricted fares, you get 100% back in SWA credit which can be used for the same person for one year. I'm surprised they don't have a 24 hour cancellation policy as I'm sure they lose money when flight sell-out and last-minute, full fare passengers book on other airlines. Even a $20 fee would provide incentive to cancel redundant flights.
2. Frequent flier points can be used to book restricted fares as effectively fully refundable -- if you cancel, you get the points back. So, just book-up a bunch of segments before prices go up in case you need them. There might be a $2.50 (yes, under three dollars) fee associated, but it's immaterial.
3. If you "miss" your flight and get to the airport within two hours of its scheduled departure, you can fly standby on the next one. There's an incentive to book a mid-afternoon flight (usually less expensive than, say, a 6:00 PM one), "miss" that flight, and standby on the more expensive one.
All-in-all, I don't abuse the rules much. Mostly, the lack of any fees for missing my Monday morning flights makes me less interested in showing up at the airport too early. I'm simply surprised that SWA doesn't provide me with small incentives to change my behaviors in ways which would help them immensely. Conversely, their website seems to have a bunch of O(N) or worse algorithms w.r.t. number of trips taken -- a huge annoyance to their most valuable customers.
Hey, buy a bunch of switches, sensors, etc. from us which all conform to an open standard (Zigbee?). Then, buy our controller unit and install our iphone/android apps. It'll work after just a bit of monkey-see-monkey-do configuration. Yeah, you have to get a screwdriver out and figure which breaker is associated with each room, but it ain't rocket science. If we go away, you might eventually have to buy another controller, but your investment in switches, sensors, etc. and all your time spent with a screwdriver won't be for nothing -- competitors are likely to support the same stuff.
This is what I want, and I would gladly spend in excess of $1K for it. Maybe $2K? This would be a bargain compared to paying for a Control4 reseller to come to my house and sell me a turnkey solution.
I started reading about Zigbee and thought, "Hey, I'll just install Zigbee-controlled switches in the same boxes where my analog ones are today. Then, I'll use some automation appliance (like OpenRemote) to implement "turn off all basement lights" via a phone app" I got confused when trying to figure out what I would need to buy, which stuff could actually talk to other stuff, etc. and gave up.
I'd love to see a start-up sell semi-DIY kits for people like me. I'm fine with replacing switches, plugging in network devices, etc., but I really don't have the time to pick out appropriate hardware and make it all work together.
I had thought about using AspectJ to wrap interesting points in various APIs and then do "stuff". The obvious behavior is to restrict usage based on whitelists. However, it might also be interesting to run one's app in an access logging mode, especially when trying to wrap some controls around a previously unrestricted production application.
I want to define whitelists for each environment in which my app will run -- development, QA, production, etc. To which hosts may it connect? Where may it access files? What else might I wish to constrain as way of avoiding inadvertent dependencies? Particular queues/topics on messaging buses? Database schemas within a particular server (network restrictions are too coarse for this)? When asking this question, I'm not trying to protect myself from rogue developers with malevolent intentions -- I just want to avoid a scenario like the one described by the OP.
Recently, I started-up the Java app upon which I am currently working and watched its network behavior via Microsoft's Wireshark-esque network monitoring tool. It turns out that EHCache now asks one of Terracotta's servers for the most recent EHCache version number so that it can spit an out-of-date warning in the logs. Benign and useful, but I still had to spend a few minutes in the EHCache source to make sure that, if Terracotta's servers were down, our app would still start-up.
Should one do this at the OS level (jails, perhaps)? I'm not limiting this idea to just Java apps, but I'm really only an expert in the Java space.
I also argue that the whitelist would help codify inter-app dependencies in large IT environments. A few years ago, the large IT shop for which I worked did a disaster recovery drill where they literally deployed 10's of apps in an IBM-provided datacenter as a dry run. One thing they learned was that a particular production app was erroneously configured to log certain audit events to a server in a QA environment (which was not part of the disaster recovery plan for obvious reasons). Whitelists would have prevented this issue.
To make sure that these libraries did not attempt to talk servers outside my company's control, I had to dig through the code and implement "neutered" forms of schema look-up interfaces, etc. I can't recall exact details. The default behavior was promiscuity and presumption, and making sure that these libraries didn't strike-up conversations with random servers was not trivial or terribly well documented. So, I'm not surprised by the current state of affairs.
Perhaps it is sufficient to hire a cadre of instructors to teach basic courses? Such a decision historically has been vilified by faculty unions intent on ensuring that research professors with PhD's are not replaced by "lesser" means of instruction. Never mind that many faculty despise teaching introductory courses where much of the workload is administrative and their specialized knowledge is barely put to use.
What I don't understand is how U of F seemingly thinks it acceptable to imply to the public that it taking steps which eventually will make it incapable of teaching basic computer science to any of its students. Surely, U of F's PR department would be horrified to convey parallel messages regarding its math department. Maybe we are all missing some important facts?
This sums up my first thought when I read the headline. Perhaps the underlying societal problem is that many hold in contempt ideas too complex for sound bite summarization? So, changes in the ways we converse are merely a symptom of this underlying change? How many times have you watched a televised interview or sat in a meeting as someone was explaining an idea and become angered when the speaker was interrupted -- not to clarify, but to change the topic? I find myself saying in my head, "Let him speak!" I have no problem with others silencing some babbling fool, but to shut someone up simply because the idea at hand requires nuanced explanation severely limits the spectrum of ideas we ever will be able to consider.
Perhaps, much like when people don't stand up and say something when another makes a bigoted joke, those of us sitting silently are partially to blame? I often say, "I'd really like to hear more about what Suzy thinks!", but only "often" in that I do so much more frequently than others. What would it take in, say, a company (or even department) to establish via social proof that those opposing complex thought simply because it is complex are the unacceptable ones?
What we don't ever see are the absurdly optimistic justifications for really bad ideas. Cuecat? Iridium satellites? The supposed future ubiquity if the Segway? We only know about the flops which because big enough (or were hyped enough) to have gotten publicity. Have you ever seen the abysmal nature of business plans in a local business plan competition?
I almost included Webvan, but I'm not sure that it was an inherently bad idea -- just one which required high adoption levels to achieve positive cash flow. And, I didn't include things like pets.com which I suspect (without justification) were known by their inventors as bad-but-flip-able ideas.
The reason I prefer to work in non-declarative code land is that I usually must inject many service references into the translators. When converting an industry standard XML format into a company's internal domain model for quoting insurance policies, I had to employ a set of heuristics to create a valid policy from a set of coverage requirements which likely were ill-specified. For example, we didn't offer a $750 auto deductible. Should this be converted (with a note attached) to $500 or $1000? This decision varied by state, policy type, etc. We had a metamodel which I injected into the transformers at the points where such decisions were made.
That the source and/or target of a transformation are XML is a red herring, though. Most of my time is not spent on XML-ness itself but on solving fundamental impedance mismatch issues when converting between two different domain models, sets of assumptions, etc. Document formats don't matter for these problems although those formats with better surrounding toolsets certainly allow one to concentrate immediately on the part of the problem which is the hardest. I even prefer talking about these problems using terms like "model conversion" instead of "document translation" -- too many marketing folks have convinced IT managers that, through the magic of their overpriced ETL tools, "document conversion" problems are a trivial drag & drop matter.
One way I've thought of architecting these model transformations is through the invention of a few intermediate model definitions, each one becoming less source-like and more target-like. I think some stages of conversion are more compatible with declarative approaches. Perhaps attempting conversion in only a single pass has led me to throw the baby out with the bathwater w.r.t. declarative schemes?
For those of you who don't do corporate IT development, the sad reality is that a huge percentage of development effort is spent on data conversion/translation between systems. The ratio of glue:substance is highly skewed toward glue. Furthermore, the ratio gets worse as short-term benefits are prioritized over long-term ones, development is silo-ed between business groups, and data modeling takes a backseat to gettin' stuff "done".
Anyone seen any good schemes?
1. You can get your stuff RIGHT NOW 2. You supposedly can get customized help/advice
What can other companies do to hasten Best Buy's death? Amazon seems to be piecing together a distribution network for same day/next day delivery in dense urban markets (at least, as a Prime member shipping to Chicago, I was offered some sort of courier delivery for $4). Perhaps Walgreens, etc. could up their game and offer an intelligently stocked selection of need-it-now things like cables? They're open 24/7 in most markets and could probably deal with "only" a 100% mark-up. Certainly, the immediacy of purchasing a TV from Best Buy is important to some, but I suspect small accessories account for the majority of purchases which, if a day's lag time had not been an issue, would have been made online instead.
The help/advice need seems like a more interesting niche for start-ups. Hunch.com seems like the right sort of idea if applied to Amazon's offerings. Let's say my friend suggests that we do a Skype video chat. While I personally can read through product specifications, know various companies' reputations for providing driver support over time, etc., my parents would be lost. A good salesperson asks questions about a customer's needs which help filter down a huge set of potential products down to just a few. Imagine paying a trusted, independent, and knowledgeable person $10 for a ten minute chat along with an interactive Amazon browsing session. People like my parents would be delighted. Heck, I'd use such a service if I was shopping for, say, a kitchen faucet.
What else can be done?