Like most of the posts on this and previous HFT discussions on/., this is wrong. Do most/.ers just make shit up like this?
"Alice wants to sell 1000 shares of Acme Corp. She places an sell order for 1000 shares at $25.00 on the exchange, but she also places a minimum bid of $23.90 on the sell order. This minimum bid what Alice is willing to accept should someone counter-offer but is suppose to be secret, only the sell price will be published."
This is complete rubbish.
First, get your terminology right. There is no bid on a sell order. It is called an "offer" or "ask", "asked" or "ask price".
Alice is offering to sell 1000 shares at $25. Period. This is called a limit order. There is no such thing as a "minimum bid", since there is no such thing as a "bid" on a sell order. Alice wants $25 or more. Her $25 limit is public, and goes into the order book. I should qualify that it is public in aggregate only. Nobody (other than Alice's broker) knows or can find out that it is Alice that is asking $25 for 1000 shares, and if somebody else is also asking $25 for 1500 shares, then the order book shown to the public will show 2500 shares offered at $25.
"Bob is looking for 1000 shares of Acme Corp. He wants to place it in his portfolio for long-term growth, but he thinks it is currently worth less. Bob places a general buy order at $24.40 on the exchange. For the sake of simplicity we will say that is his only price, though he too could have a maximum bid he is will to pay."
Again, this is complete rubbish.
I don't know what a "general buy order" is, and neither does anybody else, because it is not a term used in the industry. Perhaps you meant a "market order"? This is an order to buy at the current "market" price. There is no limit price specified. This means, simply, buy at the current offer price, regardless.
Again, your terminology is wrong. There is no "bid he is willing to pay". That is a nonsensical sentence. Bob is making an offer to buy at $24.40. (Or has placed a market order, which is my best guess as to what you mean by "general market order".)
"Eve places a bid at $24.99 for Alice's share, the exchange accepts, and then Eve immediately cancels the bid order."
Assumign the exchange matched Alice's share with Eve's buy order - too bad, Eve! You just bough them. You should have gotten your cancel in a few microseconds sooner.
"Eve has just learned that Alice is will to sell for less than the sell order posted"
I don't know how. Is Eve a mind-reader?
"Eve then continues placing bids on Alice's stock, $24.98, $24.97, $24.96, etc., each time immediately canceling the buy when the exchange accepts the bid."
It's impossible for Eve to place bids specifically for Alice's stock.
"Eve gets down to $23.89, at which point the exchange does not accept the bid for Alice's stock."
Of course, since it's impossible to bid specifically for Alice's stock.
This is wrong, as the exchange will acccept bids at any price and place them in the order book. (Actually, I beleive there have been some recent changes that prevent you now from placing bids well below the current market - such as.01 for a $100 stock. But as a practical matter, you can place a bid at any reasonable price.)
"On Wallstreet they call this "providing liquidity", anywhere else this would be considered insider trading and illegal. "
More nonsense. Insider tradiing is trading on information that has not been disseminated to the public. Say, your next-door neighbor is CEO of a company that has a serious flaw in a product that will result in a costly recall, and this has not yet been made public by the company, and he got to talking about it after a few at a back-yard barbecue. If you act on this by shorting the stock, you are guilty of insider trading. This has absolutely nothing to do with HFT.
FWIW, I was partner in a firm that did HFT from about 2000 to 2005. I wrote the software. My partner oversaw the trading and mopped-up the trades that we didn't trust the computer with. (Trades gone wrong.)
You can't cancel an order after it has been executed.
That is not to say that HFTs don't place orders that they then cancel after a short time. But if the order has already been executed, the cancellation will be rejected.
This was on the local TV news troubleshooter segment ("Turko Files") in San Diego a couple months ago.
An elderly woman had called because somebody called her to tell her that her computer had a virus, and he was with Microsoft and could help her remove it. But first she had to "renew" her anti-virus subscription.
Hehe, good timing... Good opportunity to pick some brains...
I happen to have an iOS app under development that uses XMPP for a specific use case. It primarily uses MUCs, and I want users to be anonymous, and don't want users to have to deal with sign-up. I haven't really given it much thought, beyond realizing that there are some pitfalls, and that I want to avoid them.
At the same time, I do want users devices to be uniquely-identified, because I realize that it will occasionally be necessary to ban users, and I don't wnat them just signing back up. I think the the cost of a new device is a reasonable deterrent to bad behaviour.;)
I'm using ejabberd for the server. The client is written on the Rhodes mobile platform (Ruby Rails-like embedded server, HTML/CSS/Javascript/jQuery Mobile for UI, and, yes, before you say anything, I actually get great near-native performance out of this. I've had to become an expert at getting performance out of JQM in the process... (This mostly involves using as little of JQM as possible...) The Ruby code and simple Ruby ORM over SQLite is blazing fast compared to JQM, BTW, it is absolutely not a bottleneck.
I'm using my own fork of XMPP4R ( https://github.com/watusi/xmpp4r ) that has some minor mods for Rhodes, as well as a BOSH module that actually works. (Yes, BOSH latency sucks. Hopefully, it will just be a fallback for getting through firewalls, but I am also concerned with connection drops on mobile devices being an annoyance in the MUCs. I don't really want to write my own connection manager for regular connections, since I have no Erlang experience...)
So, I'll be using standard XMPP, a standard server, SSL-encrypted messaging with perhaps a fallback to non-SSL for firewall issues. (Need to make sure user is aware when that happens, though.)
I do have two issues to solve that will take some server-side work. One seems fairly trivial: the app needs to be able to request creation of a MUC. The server will do a validity check against a list (MUCs aren't arbitrary, but I don't want to create them in advance. Imagine that the name of the MUC has to be a kind of fish) and create the MUC and give ownership to admin. (Yea, right now the app itself creates the MUC in demo, as the test server allows anybody to create one.)
The other is how to "bootstrap" the creation of ID/password, or some other authentication mechanism. All I really care about is:
1. I need to be sure that only my app is making the request for a new ID.
2. If at all possible, I need to be sure that the same device will always create the same ID. (So users can be banned when necessary.)
Basically, if you own the app - the real app and not a clone or jailbreak - you get to create one and only one ID per device. (Ok, maybe jailbreak too, because that will take away one reason for people poking around inside.)
The app is meant for casual and anonymous communication, but the thing is, you never know what applications people will find for it. (Actually, there are many scenarios for serious use.) So, I'd like to provide reasonable security.
I know I can't use a UDID, since Apple has banned their use. (And now it's a private API.) I am dubious on using any other hardware-related ID, because Apple might ban them in the future. I could use an Application UDID, but then the user just needs to delete and re-install the app to get a new ID.
For the problem of insuring that only my app can make a valid request to create a user, I figure I have to sign a message with some well-burried key. (Yea, yea, I know, that worked well for satellite receivers...)
The Ruby code is compiled to Ruby bytecode, so it won't be easy, but certainly not impossible to try to find it in code. (Of course, I wouldn't just code-in a simple constant.)
I'd love to hear some suggestions on how to do this the right way.
Don't know how successful this would be today, but I've seen it done maybe 10 years ago.
I think most drive failures are bearing failures. So, sometimes you can get it to spin-up by tapping, etc.
A co-worker couldn't get a drive going that way, so he just opened it up, and gave it a little push and it spun-up. He got his data off, and then left it running, to see how long it would last. It worked for a week in open-air before it finally failed. I don't remember now if it started getting errors or just physically stopped spinning. (It *was* a bearing failure in process, after all...)
Unfortuantely, it seems to be the default choice for tech-support forums. And it seems particularly poorly-suited for that task.
The bigget problem is not that it is way behind other forum software (it is) but the "cowboy" mentality of whoever pushes out a new version seemingly daily. It works one day, then it doesn't the next. Fortunately, with the daily release schedule, then it works again a few days later, but then it's different, and you have to figure out how to use it again.
Really, the only reason this was ever voted up from the firehose is because it was a darn good troll.
I love all the show-off posts trotting-out incredibly detailed and complex solutions that won't work.
There's no need to apologize. You provided a few mintues of great entertainment. It's what Slashdot is all about!
Sadly, it's not just entertaining - it's depressing - to see so many "experts" sucked-in by this. I think many of them actually think their solutions would be useful.
What your drug-lord client is asking is impossible.
You're only going to be able to look at unencrypted traffic. MOST messaging is encrypted. iMessage is encrypted. Even in-game messaging, like in Words with Friends, etc. if it isn't encrypted now will be in the future, becuase of public criticism in the press about apps that have unencrypted messaging. So, I think you will see most smart-phone apps go to encrypted-everything for communication to their back-end servers.
The only thing that will work is to jailbreak every device this -ahem- "family" owns with software that will record keystrokes, tap into the device's SSL API, etc. (Even the latter won't catch anything, since some apps using their own implement of OpenSSL, etc. bypassing internal API.)
But it's not worth being found strung-up from an overpass in some remote border town when this doesn't work.
There will be a person behind the disaster bar to give you a number. Another person will hand you a form to fill out. A disaster specialist will help you make your selection, but won't be able to retrive the disaster from stock. The stock-person will do that. Yet another will accept your fee payment, and another person will hand you your receipt. Then, somebody else will wrap your disaster up real nice for you.
If your an English-speaker, you will be referred to the Manager, who knows "hello", and all the numbers except for 'seven".
This one is also covered by a previous patent that Honeywell owns. It's the patent for the Magic-Stat. It was developed by an inventor in Ann Arbor, Michigan back in the 70's or 80's. Honeywell bought that patent years ago. I knew someone who knew the inventor, and had one myself. That was it's big claim to fame - the thermostat "learns" your space's thermal inertia so as to achieve the desired temperature at the desired time. It also had the same schedule learning concept i.e. just jump up and adjust the thermostat when you feel uncomfortable, and the thermostat will eventually figure it out.
When I saw the Nest thermostat I yawned, since I had these features 20 years ago, albiet without Internet connectivity.
This won't change a thing. The companies that are the worst offenders are already breaking the law, and don't care. They won't care any more if some new penalty is added. They fake caller ID and don't observe the Do Not Call List. Most of these aren't even legitimate marketing calls, but some kind of scam or another. They're breaking the law in so many ways it isn't even funny.
Fortunately, you can avoid these calls today by using a cell phone. For some reason, they do avoid making calls to cell phones. I imagine not because of the stronger laws, but because the cell phone companies (speculation, on my part) DO block these callers somehow.
I need to get rid of my home phone. I haven't used it in ages, and it just forwards to my cell. When my home phone rings, then I see an incoming call on my cell, I know it's just an annoying marketing call.
I once did a contract job for Conexant, devloping software to acquire and stuff test results into a database, format reports, etc. (for Docsis cable model qualification). Now I wish I'd never put that on my resume, because I get calls for "software test" all the time.
At Sony I got to see game testing. Now THAT was a three-ring circus! Signs posted about no sleeping in the halls, and no hats or sunglasses... Some of that testing actually is just playing unreleased games and recording your reactions to the game play.
I'm pretty good at "monkey testing" (pounding on a keyboard to try to make the software break) but I find writing test plans and test cases tedious. I've actually done monkey testing, and there are cases where it's appropriate.
Rails programmers, of course, all write their own tests. (Riiiiiiiiiight!)
There really is no way to know just what the term means, because it applies to such a wide variety of activities.
My brother and sister are both retired teachers (I am not).
While I beleive and hope that both of my siblings were "good teachers", both reached to top of their system's payscales by obtaining multiple advanced degrees - up to but not to exceed the number that will maximize pay - as early as possible. (Which affects total compensation including retirement.) My sister has 3 masters, brother has two masters and a PhD.
I have no idea whether or not that translates to "highly qualified". It does translate into "smart enough to know how the system works."
The Trojan Room Coffee Pot cam predates this by two years, though that was on a local network and didn't use a web browser. It didn't appear on the Internet until November, 1993.
The Netscape Fishcam shortly followed. I believe the first outdoor cam was at an antartic research station shortly after that.
Moving images were enabled by the "server-push" feature in Netscape's server and client. I'm assuming this used that technology, which of necessity would have pre-dated this claim. I would think the use case would be obvious.
Here's the trademark listing for Magic-Stat which was issued to QuadSix Corporation of Ann Arbor, Michigan filed in February, 1982, and subsequently assigned to Honeywell Corporation. One
(I realize the trademark has nothing to do with patents. Just using the trademark to help fix the date and origination of the "learning thermostat" idea.)
So, it looks like Nest took 30 year old technology and created a buzz by giving it a bit of Apple shine.
I actually had one of the original Magic-Stats, before it was sold under the Honeywell label. I was reasonably happy with it. The unique feature is that it would learn the inertia of your system, so that it would achieve the desired temperature at the time that you wanted. That, and the unique simplified user interface. e.g. you just set it to the desired temperature when it doesn't seem right, and it learns your pattern from that.
It just amazes me how much buzz these guys got over something that was invented 30 years prior.
I kinda saw this coming, but didn't grasp the implications, e.g. patent issue.
When I saw Nest, I chuckled at their claims that this was such a revolution. Why, the thermostat will learn your usage patterns by itself!
Scroll back like 30 years or so ago when I lived in Dertroit. A friend of a friend, I think in Ann Arbor, invented this thermostat call MagicStat. It learned your usage patterns all by itself. That's why was was unimpressed by Nest's claims. Yawn. Long, 30-year yawn.
Honeywell bought the MagicStat patents. I presume they've maintained those and taken out new ones throughout the years.
The best thing the guy could do is to be more like his father, George Romney. He was governor of Michigan when I was a child. He was a self-made auto executive before that. The family didn't come from money. In fact, they fled from a Mormon colony during the Mexican Revolution and "struggled during the Great Depression". (Yes, I cribbed that from Wikipedia...)
Before running for governor, George Romney was CEO of American Motors, the underdog of auto manufacturers. When George Romney ran for the office of governor, he released *7* years of tax returns. He became a popular Republican governor of a almost-exclusively Democratic state. I don't recall any "mormon" issue, but I was a little kid, and I think awareness of Mormonism was pretty low. Nobody knew what that was, or else didn't care.
I don't know why Mitt refuses to take after his father, who seemed - to me, at least - an honest and direct man.
I suppose the problem is - he CAN'T be like his father. George grew up in a Mormon colony in Mexico and in Salt Lake City during the depression. Mitt grew up in Bloomfield Hills, which is one of Earth's Reality-Free Zones.
It might or might not be riskier. But that has nothing to do with the reason plant workers don't do the work. Once you are "maxed-out" for a period, you can't be in an exposure environment for the rest of the period. That means they have to stick you in a desk job until the next period. There are only so many desk jobs that plant workers can do. They would have to hire a bunch more people and have them play Uno most of the time.
Instead, they hire contractors and pay a premium rate. The contractors do other types of work (or are supposed to do other types of work) once they are maxed-out, which can happen in a day or an hour.
The exposure limits are VERY conservative. Of course, nuclear workers are all susceptible to the potential for unforseen exposure. IMO, if exposure is within lesgislated limits, the risk is no greater than average for the entire population.
Yes, the U.S. now has mandatory centralized reporting. That hasn't always been the case. When I worked (as a programmer) in Health Physics at San Onofre in 1990-1992, centralized reporting was voluntary. Employees could opt in or out of the national system. If they opted-out, then the plant still tracked dosage, but did not report it to the national database. There was apparently some "back-channel" communication between plants, though, to try to prevent some of the more eggregious cases of jumping.
The temporary workers who move from plant to plant are called "jumpers".
There are regulated exposure limits per period, don't recall exactly, but like hour/day/week/month/year. Any worker that exceeds a limit can't work in an exposed environment for the rest of that period. I don't know what changes there have been since 1990, but at the time, temporay workers were often hired for high-exposure tasks. When they opted-out of the central system and (illegally) went to work at another plant, they "jumped".
Waiting for the first Big Content vs. Big Content YouTube war!
That is, when one Big Content company that has this agreement with YouTube declares war on another Big Content company that has the same agreement with YouTube, and they take down all of each other's content.
Wait a minute.... wouldn't we wind-up with YouTube as originally envisioned?
The only way to win this game is to not play at all...
What I called PowerBar above actually was called PowerFrames. I'd forgotten about the interstitials.... (PowerPages).
This was around the same time that Google first incorporated.
The client software worked reasonably well, given the state of embeddable browser controls at the time. Allegedly, there were serious issues with the back-end, and EDS insisted on taking that over.
I haven't really followed this area since. Has the question ever been settled as to whether software that inserts ads into content retrieved from the web violating the publisher's rights, or just acting as an agent of the user? I mean, it's legal to cut-apart a newspaper page, and paste it back together into a collage any way you want, right? (Assuming it is just for your own enjoyment...)
I designed the client software architecture for the above. It was an "interesting" experience. My favorite "death march" project ever!;) I got to meet David Bois...
The client was a wrapper around IE or Firefox, and attached a "PowerBar" to the top of the browser window. Due to the legal issues with EDS, they never got to dealing with any potential legal issues involving consumer privacy or publisher rights.
While I had some misgivings initially about working on this project, I found Dale very receptive about protecting consumer privacy. There were safeguards to insure that advertisers could only gain access to aggregate data, and this was a stated goal. And he went along 100% with my ideas about insuring that uploaded data was as transparent as possible - passed in the clear so that users could examine it and see just what was being sent, with only a small opaque digital signature. (Which still worried me. *I* knew there was nothing hidden in the signature, but how could the user prove it?)
Just discovering what programs are available is a huge problem outside of the conventional broadcast TV paradigm.
Set-top box program schedules stink. Nobody buys the TV Guide any more. Yea, there are third-party (and cable-company supplied) program schedule apps, but most of them stink too. (Anybody else try the useless Cox schedule guide on iPad?) If you're really into it, there are web sites that discuss shows ad-infinitum I'd imagine, but most people won't bother, and don't want to sift through the crap.
Finding on-demand programming is a hassle. You have to navigate with a horrible on-screen interface, and most people don't know what network a show they've heard about is on. So, they have to do a search, which is horribly painful. Click, click, click, click, there's ONE LETTER.
Program discovery is so bad that most people revert to "what's on?" and flip through the channels. Even if a show is marketed heavily, and you see a banner drug by an airplane and wonder what's up with the guy that thinks he sees a dog, how many people are going to bother to painfully type-in "W _ I _ L _ F _ R _ E _ D when they get home, and then go through the rigmarole to set the VCR?
The big problem is, there are so many choices that it takes major time to sift through them. You have to know what you are looking for, but how do you know what you are looking for in the first place? Sure, I can go to NetFlix and decide I want to see a Fellini film easily enough. (Though I'd be best served by going to the website and putting it in my Instant Queue than by navigating the horrible on-screen interface.) And, oh, BTW, they're going to have to mail me that Fellini film 90% of the time, so we're Not There Yet.
Now, if the marketing says or even implies it's a prime-time show on a major network - you might remember the time-slot and go surfing for it if it's around that time. Otherwise, it's pretty hit-and-miss.
Clearly, though, ultimately, scheduled programming (other than live events and breaking news) are inevitably going to go away. I think I think that's necessary to prepare the public is to change terminology. No more show times. They're release times.
Every show should be available on-demand in some form. Some people will still eagerly anticipate "release times", and gather in front of the set to be the first to watch a show, just as some go out to a theater to see a movie when it's first released.
Slashdot Mirror
Like most of the posts on this and previous HFT discussions on /., this is wrong. Do most /.ers just make shit up like this?
"Alice wants to sell 1000 shares of Acme Corp. She places an sell order for 1000 shares at $25.00 on the exchange, but she also places a minimum bid of $23.90 on the sell order. This minimum bid what Alice is willing to accept should someone counter-offer but is suppose to be secret, only the sell price will be published."
This is complete rubbish.
First, get your terminology right. There is no bid on a sell order. It is called an "offer" or "ask", "asked" or "ask price".
Alice is offering to sell 1000 shares at $25. Period. This is called a limit order. There is no such thing as a "minimum bid", since there is no such thing as a "bid" on a sell order. Alice wants $25 or more. Her $25 limit is public, and goes into the order book. I should qualify that it is public in aggregate only. Nobody (other than Alice's broker) knows or can find out that it is Alice that is asking $25 for 1000 shares, and if somebody else is also asking $25 for 1500 shares, then the order book shown to the public will show 2500 shares offered at $25.
"Bob is looking for 1000 shares of Acme Corp. He wants to place it in his portfolio for long-term growth, but he thinks it is currently worth less. Bob places a general buy order at $24.40 on the exchange. For the sake of simplicity we will say that is his only price, though he too could have a maximum bid he is will to pay."
Again, this is complete rubbish.
I don't know what a "general buy order" is, and neither does anybody else, because it is not a term used in the industry. Perhaps you meant a "market order"? This is an order to buy at the current "market" price. There is no limit price specified. This means, simply, buy at the current offer price, regardless.
Again, your terminology is wrong. There is no "bid he is willing to pay". That is a nonsensical sentence. Bob is making an offer to buy at $24.40. (Or has placed a market order, which is my best guess as to what you mean by "general market order".)
"Eve places a bid at $24.99 for Alice's share, the exchange accepts, and then Eve immediately cancels the bid order."
Assumign the exchange matched Alice's share with Eve's buy order - too bad, Eve! You just bough them. You should have gotten your cancel in a few microseconds sooner.
"Eve has just learned that Alice is will to sell for less than the sell order posted"
I don't know how. Is Eve a mind-reader?
"Eve then continues placing bids on Alice's stock, $24.98, $24.97, $24.96, etc., each time immediately canceling the buy when the exchange accepts the bid."
It's impossible for Eve to place bids specifically for Alice's stock.
"Eve gets down to $23.89, at which point the exchange does not accept the bid for Alice's stock."
Of course, since it's impossible to bid specifically for Alice's stock.
This is wrong, as the exchange will acccept bids at any price and place them in the order book. (Actually, I beleive there have been some recent changes that prevent you now from placing bids well below the current market - such as .01 for a $100 stock. But as a practical matter, you can place a bid at any reasonable price.)
"On Wallstreet they call this "providing liquidity", anywhere else this would be considered insider trading and illegal. "
More nonsense. Insider tradiing is trading on information that has not been disseminated to the public. Say, your next-door neighbor is CEO of a company that has a serious flaw in a product that will result in a costly recall, and this has not yet been made public by the company, and he got to talking about it after a few at a back-yard barbecue. If you act on this by shorting the stock, you are guilty of insider trading. This has absolutely nothing to do with HFT.
FWIW, I was partner in a firm that did HFT from about 2000 to 2005. I wrote the software. My partner oversaw the trading and mopped-up the trades that we didn't trust the computer with. (Trades gone wrong.)
Wrong.
You can't cancel an order after it has been executed.
That is not to say that HFTs don't place orders that they then cancel after a short time. But if the order has already been executed, the cancellation will be rejected.
This was on the local TV news troubleshooter segment ("Turko Files") in San Diego a couple months ago.
An elderly woman had called because somebody called her to tell her that her computer had a virus, and he was with Microsoft and could help her remove it. But first she had to "renew" her anti-virus subscription.
As Turko says:
"It's a scam!"
Hehe, good timing... Good opportunity to pick some brains...
I happen to have an iOS app under development that uses XMPP for a specific use case. It primarily uses MUCs, and I want users to be anonymous, and don't want users to have to deal with sign-up. I haven't really given it much thought, beyond realizing that there are some pitfalls, and that I want to avoid them.
At the same time, I do want users devices to be uniquely-identified, because I realize that it will occasionally be necessary to ban users, and I don't wnat them just signing back up. I think the the cost of a new device is a reasonable deterrent to bad behaviour. ;)
I'm using ejabberd for the server. The client is written on the Rhodes mobile platform (Ruby Rails-like embedded server, HTML/CSS/Javascript/jQuery Mobile for UI, and, yes, before you say anything, I actually get great near-native performance out of this. I've had to become an expert at getting performance out of JQM in the process... (This mostly involves using as little of JQM as possible...) The Ruby code and simple Ruby ORM over SQLite is blazing fast compared to JQM, BTW, it is absolutely not a bottleneck.
I'm using my own fork of XMPP4R ( https://github.com/watusi/xmpp4r ) that has some minor mods for Rhodes, as well as a BOSH module that actually works. (Yes, BOSH latency sucks. Hopefully, it will just be a fallback for getting through firewalls, but I am also concerned with connection drops on mobile devices being an annoyance in the MUCs. I don't really want to write my own connection manager for regular connections, since I have no Erlang experience...)
So, I'll be using standard XMPP, a standard server, SSL-encrypted messaging with perhaps a fallback to non-SSL for firewall issues. (Need to make sure user is aware when that happens, though.)
I do have two issues to solve that will take some server-side work. One seems fairly trivial: the app needs to be able to request creation of a MUC. The server will do a validity check against a list (MUCs aren't arbitrary, but I don't want to create them in advance. Imagine that the name of the MUC has to be a kind of fish) and create the MUC and give ownership to admin. (Yea, right now the app itself creates the MUC in demo, as the test server allows anybody to create one.)
The other is how to "bootstrap" the creation of ID/password, or some other authentication mechanism. All I really care about is:
1. I need to be sure that only my app is making the request for a new ID.
2. If at all possible, I need to be sure that the same device will always create the same ID. (So users can be banned when necessary.)
Basically, if you own the app - the real app and not a clone or jailbreak - you get to create one and only one ID per device. (Ok, maybe jailbreak too, because that will take away one reason for people poking around inside.)
The app is meant for casual and anonymous communication, but the thing is, you never know what applications people will find for it. (Actually, there are many scenarios for serious use.) So, I'd like to provide reasonable security.
I know I can't use a UDID, since Apple has banned their use. (And now it's a private API.) I am dubious on using any other hardware-related ID, because Apple might ban them in the future. I could use an Application UDID, but then the user just needs to delete and re-install the app to get a new ID.
For the problem of insuring that only my app can make a valid request to create a user, I figure I have to sign a message with some well-burried key. (Yea, yea, I know, that worked well for satellite receivers...)
The Ruby code is compiled to Ruby bytecode, so it won't be easy, but certainly not impossible to try to find it in code. (Of course, I wouldn't just code-in a simple constant.)
I'd love to hear some suggestions on how to do this the right way.
Don't know how successful this would be today, but I've seen it done maybe 10 years ago.
I think most drive failures are bearing failures. So, sometimes you can get it to spin-up by tapping, etc.
A co-worker couldn't get a drive going that way, so he just opened it up, and gave it a little push and it spun-up. He got his data off, and then left it running, to see how long it would last. It worked for a week in open-air before it finally failed. I don't remember now if it started getting errors or just physically stopped spinning. (It *was* a bearing failure in process, after all...)
Don't foist Google Groups on your users.
Unfortuantely, it seems to be the default choice for tech-support forums. And it seems particularly poorly-suited for that task.
The bigget problem is not that it is way behind other forum software (it is) but the "cowboy" mentality of whoever pushes out a new version seemingly daily. It works one day, then it doesn't the next. Fortunately, with the daily release schedule, then it works again a few days later, but then it's different, and you have to figure out how to use it again.
Al Gore also did not avert an internet meltdown in the 1980's.
Really, the only reason this was ever voted up from the firehose is because it was a darn good troll.
I love all the show-off posts trotting-out incredibly detailed and complex solutions that won't work.
There's no need to apologize. You provided a few mintues of great entertainment. It's what Slashdot is all about!
Sadly, it's not just entertaining - it's depressing - to see so many "experts" sucked-in by this. I think many of them actually think their solutions would be useful.
What your drug-lord client is asking is impossible.
You're only going to be able to look at unencrypted traffic. MOST messaging is encrypted. iMessage is encrypted. Even in-game messaging, like in Words with Friends, etc. if it isn't encrypted now will be in the future, becuase of public criticism in the press about apps that have unencrypted messaging. So, I think you will see most smart-phone apps go to encrypted-everything for communication to their back-end servers.
The only thing that will work is to jailbreak every device this -ahem- "family" owns with software that will record keystrokes, tap into the device's SSL API, etc. (Even the latter won't catch anything, since some apps using their own implement of OpenSSL, etc. bypassing internal API.)
But it's not worth being found strung-up from an overpass in some remote border town when this doesn't work.
Keep in mind, this is Brazil.
There will be a person behind the disaster bar to give you a number. Another person will hand you a form to fill out. A disaster specialist will help you make your selection, but won't be able to retrive the disaster from stock. The stock-person will do that. Yet another will accept your fee payment, and another person will hand you your receipt. Then, somebody else will wrap your disaster up real nice for you.
If your an English-speaker, you will be referred to the Manager, who knows "hello", and all the numbers except for 'seven".
This one is also covered by a previous patent that Honeywell owns. It's the patent for the Magic-Stat. It was developed by an inventor in Ann Arbor, Michigan back in the 70's or 80's. Honeywell bought that patent years ago. I knew someone who knew the inventor, and had one myself. That was it's big claim to fame - the thermostat "learns" your space's thermal inertia so as to achieve the desired temperature at the desired time. It also had the same schedule learning concept i.e. just jump up and adjust the thermostat when you feel uncomfortable, and the thermostat will eventually figure it out.
When I saw the Nest thermostat I yawned, since I had these features 20 years ago, albiet without Internet connectivity.
For an 11 year old? That's easy: Why's (poignant) Guide to Ruby
Just make sure you stock-up on chunky bacon.
(Multiple formats linked from the Wikipedia article)
http://en.wikipedia.org/wiki/Why's_(poignant)_Guide_to_Rubyhttp://en.wikipedia.org/wiki/Why's_(poignant)_Guide_to_Ruby
This won't change a thing. The companies that are the worst offenders are already breaking the law, and don't care. They won't care any more if some new penalty is added. They fake caller ID and don't observe the Do Not Call List. Most of these aren't even legitimate marketing calls, but some kind of scam or another. They're breaking the law in so many ways it isn't even funny.
Fortunately, you can avoid these calls today by using a cell phone. For some reason, they do avoid making calls to cell phones. I imagine not because of the stronger laws, but because the cell phone companies (speculation, on my part) DO block these callers somehow.
I need to get rid of my home phone. I haven't used it in ages, and it just forwards to my cell. When my home phone rings, then I see an incoming call on my cell, I know it's just an annoying marketing call.
Best answer so far!
I once did a contract job for Conexant, devloping software to acquire and stuff test results into a database, format reports, etc. (for Docsis cable model qualification). Now I wish I'd never put that on my resume, because I get calls for "software test" all the time.
At Sony I got to see game testing. Now THAT was a three-ring circus! Signs posted about no sleeping in the halls, and no hats or sunglasses... Some of that testing actually is just playing unreleased games and recording your reactions to the game play.
I'm pretty good at "monkey testing" (pounding on a keyboard to try to make the software break) but I find writing test plans and test cases tedious. I've actually done monkey testing, and there are cases where it's appropriate.
Rails programmers, of course, all write their own tests. (Riiiiiiiiiight!)
There really is no way to know just what the term means, because it applies to such a wide variety of activities.
My brother and sister are both retired teachers (I am not).
While I beleive and hope that both of my siblings were "good teachers", both reached to top of their system's payscales by obtaining multiple advanced degrees - up to but not to exceed the number that will maximize pay - as early as possible. (Which affects total compensation including retirement.) My sister has 3 masters, brother has two masters and a PhD.
I have no idea whether or not that translates to "highly qualified". It does translate into "smart enough to know how the system works."
The Trojan Room Coffee Pot cam predates this by two years, though that was on a local network and didn't use a web browser. It didn't appear on the Internet until November, 1993.
The Netscape Fishcam shortly followed. I believe the first outdoor cam was at an antartic research station shortly after that.
Moving images were enabled by the "server-push" feature in Netscape's server and client. I'm assuming this used that technology, which of necessity would have pre-dated this claim. I would think the use case would be obvious.
http://en.wikipedia.org/wiki/Trojan_Room_coffee_pot
Here's the trademark listing for Magic-Stat which was issued to QuadSix Corporation of Ann Arbor, Michigan filed in February, 1982, and subsequently assigned to Honeywell Corporation. One
http://tess2.uspto.gov/bin/showfield?f=doc&state=4008:kk95v8.3.2
(I realize the trademark has nothing to do with patents. Just using the trademark to help fix the date and origination of the "learning thermostat" idea.)
So, it looks like Nest took 30 year old technology and created a buzz by giving it a bit of Apple shine.
I actually had one of the original Magic-Stats, before it was sold under the Honeywell label. I was reasonably happy with it. The unique feature is that it would learn the inertia of your system, so that it would achieve the desired temperature at the time that you wanted. That, and the unique simplified user interface. e.g. you just set it to the desired temperature when it doesn't seem right, and it learns your pattern from that.
It just amazes me how much buzz these guys got over something that was invented 30 years prior.
I kinda saw this coming, but didn't grasp the implications, e.g. patent issue.
When I saw Nest, I chuckled at their claims that this was such a revolution. Why, the thermostat will learn your usage patterns by itself!
Scroll back like 30 years or so ago when I lived in Dertroit. A friend of a friend, I think in Ann Arbor, invented this thermostat call MagicStat. It learned your usage patterns all by itself. That's why was was unimpressed by Nest's claims. Yawn. Long, 30-year yawn.
Honeywell bought the MagicStat patents. I presume they've maintained those and taken out new ones throughout the years.
The best thing the guy could do is to be more like his father, George Romney. He was governor of Michigan when I was a child. He was a self-made auto executive before that. The family didn't come from money. In fact, they fled from a Mormon colony during the Mexican Revolution and "struggled during the Great Depression". (Yes, I cribbed that from Wikipedia...)
Before running for governor, George Romney was CEO of American Motors, the underdog of auto manufacturers. When George Romney ran for the office of governor, he released *7* years of tax returns. He became a popular Republican governor of a almost-exclusively Democratic state. I don't recall any "mormon" issue, but I was a little kid, and I think awareness of Mormonism was pretty low. Nobody knew what that was, or else didn't care.
I don't know why Mitt refuses to take after his father, who seemed - to me, at least - an honest and direct man.
I suppose the problem is - he CAN'T be like his father. George grew up in a Mormon colony in Mexico and in Salt Lake City during the depression. Mitt grew up in Bloomfield Hills, which is one of Earth's Reality-Free Zones.
It might or might not be riskier. But that has nothing to do with the reason plant workers don't do the work. Once you are "maxed-out" for a period, you can't be in an exposure environment for the rest of the period. That means they have to stick you in a desk job until the next period. There are only so many desk jobs that plant workers can do. They would have to hire a bunch more people and have them play Uno most of the time.
Instead, they hire contractors and pay a premium rate. The contractors do other types of work (or are supposed to do other types of work) once they are maxed-out, which can happen in a day or an hour.
The exposure limits are VERY conservative. Of course, nuclear workers are all susceptible to the potential for unforseen exposure. IMO, if exposure is within lesgislated limits, the risk is no greater than average for the entire population.
Yes, the U.S. now has mandatory centralized reporting. That hasn't always been the case. When I worked (as a programmer) in Health Physics at San Onofre in 1990-1992, centralized reporting was voluntary. Employees could opt in or out of the national system. If they opted-out, then the plant still tracked dosage, but did not report it to the national database. There was apparently some "back-channel" communication between plants, though, to try to prevent some of the more eggregious cases of jumping.
The temporary workers who move from plant to plant are called "jumpers".
There are regulated exposure limits per period, don't recall exactly, but like hour/day/week/month/year. Any worker that exceeds a limit can't work in an exposed environment for the rest of that period. I don't know what changes there have been since 1990, but at the time, temporay workers were often hired for high-exposure tasks. When they opted-out of the central system and (illegally) went to work at another plant, they "jumped".
Waiting for the first Big Content vs. Big Content YouTube war!
That is, when one Big Content company that has this agreement with YouTube declares war on another Big Content company that has the same agreement with YouTube, and they take down all of each other's content.
Wait a minute.... wouldn't we wind-up with YouTube as originally envisioned?
The only way to win this game is to not play at all...
A brief summary of PowerAgent:
http://www.thefreelibrary.com/PowerAgent+Introduces+First+Internet+'Infomediary'+to+Empower+and...-a019639599
What I called PowerBar above actually was called PowerFrames. I'd forgotten about the interstitials.... (PowerPages).
This was around the same time that Google first incorporated.
The client software worked reasonably well, given the state of embeddable browser controls at the time. Allegedly, there were serious issues with the back-end, and EDS insisted on taking that over.
I haven't really followed this area since. Has the question ever been settled as to whether software that inserts ads into content retrieved from the web violating the publisher's rights, or just acting as an agent of the user? I mean, it's legal to cut-apart a newspaper page, and paste it back together into a collage any way you want, right? (Assuming it is just for your own enjoyment...)
http://www.thefreelibrary.com/EDS+Provides+PowerAgent+With+Internet+Services+to+Support+One-To-One...-a019656177
http://money.cnn.com/magazines/fortune/fortune_archive/1998/04/13/240866/index.htm
I designed the client software architecture for the above. It was an "interesting" experience. My favorite "death march" project ever! ;) I got to meet David Bois...
The client was a wrapper around IE or Firefox, and attached a "PowerBar" to the top of the browser window. Due to the legal issues with EDS, they never got to dealing with any potential legal issues involving consumer privacy or publisher rights.
While I had some misgivings initially about working on this project, I found Dale very receptive about protecting consumer privacy. There were safeguards to insure that advertisers could only gain access to aggregate data, and this was a stated goal. And he went along 100% with my ideas about insuring that uploaded data was as transparent as possible - passed in the clear so that users could examine it and see just what was being sent, with only a small opaque digital signature. (Which still worried me. *I* knew there was nothing hidden in the signature, but how could the user prove it?)
Just discovering what programs are available is a huge problem outside of the conventional broadcast TV paradigm.
Set-top box program schedules stink. Nobody buys the TV Guide any more. Yea, there are third-party (and cable-company supplied) program schedule apps, but most of them stink too. (Anybody else try the useless Cox schedule guide on iPad?) If you're really into it, there are web sites that discuss shows ad-infinitum I'd imagine, but most people won't bother, and don't want to sift through the crap.
Finding on-demand programming is a hassle. You have to navigate with a horrible on-screen interface, and most people don't know what network a show they've heard about is on. So, they have to do a search, which is horribly painful. Click, click, click, click, there's ONE LETTER.
Program discovery is so bad that most people revert to "what's on?" and flip through the channels. Even if a show is marketed heavily, and you see a banner drug by an airplane and wonder what's up with the guy that thinks he sees a dog, how many people are going to bother to painfully type-in "W _ I _ L _ F _ R _ E _ D when they get home, and then go through the rigmarole to set the VCR?
The big problem is, there are so many choices that it takes major time to sift through them. You have to know what you are looking for, but how do you know what you are looking for in the first place? Sure, I can go to NetFlix and decide I want to see a Fellini film easily enough. (Though I'd be best served by going to the website and putting it in my Instant Queue than by navigating the horrible on-screen interface.) And, oh, BTW, they're going to have to mail me that Fellini film 90% of the time, so we're Not There Yet.
Now, if the marketing says or even implies it's a prime-time show on a major network - you might remember the time-slot and go surfing for it if it's around that time. Otherwise, it's pretty hit-and-miss.
Clearly, though, ultimately, scheduled programming (other than live events and breaking news) are inevitably going to go away. I think I think that's necessary to prepare the public is to change terminology. No more show times. They're release times.
Every show should be available on-demand in some form. Some people will still eagerly anticipate "release times", and gather in front of the set to be the first to watch a show, just as some go out to a theater to see a movie when it's first released.