GE chose to leave Connecticut because of a tax increase on profits made in other states by corporate subsidiaries. They're not the only corporation in Connecticut that's unhappy about the tax. Anti-business or not, it's not exactly a draw for corporations with subsidiaries across the country. The money that Boston threw at them was to keep them from moving to New York.
My understanding is Kingdoms of Amalur was work in progress at Big Huge Games, 38 Studios acquired them and they modded the game to fit the world of Amalur. Which is supposed to tie into their next game.
The transaction is internal to the database. It's essentially a list of operations to perform, if something goes wrong it provides a list of things to reverse. If the db transaction fails, then there would need to be some code to handle rolling back operations outside of the database. I don't think db transactions were to fault in your situation.
I'm not sure I really get what you are trying to say. I know what a transaction is, and I know it wasn't the fault of transactions. It was the fault of our poor use of transactions, in the same monolithic transaction pattern that the OP appears to be advocating.
transaction-per-request is by far the best default pattern to use. If some particular methods have special needs, like needing to break up the operations into multiple transactions to deal with third-party communication, those are the exceptions.
The alternatives to transaction-per-request are autocommit, or explicit transactions required at all times. Autocommit is a terrible choice because now you've lost all atomicity and isolation for dependent operations (locking is also not much of an issue. If you're doing VB, then you're on SQL server, which has some of the worst locking behavior - turn on snapshot isolation to make it bearable). Explicit transactions required at all times is a terrible choice because now your app is littered with what is 90% of the time unnecessary boilerplate.
Why not the third (and in my experience most common) alternative? Autocommit but if you explicitly start a transaction then automcommit is turned off until that transaction has been committed.
If you have more than one statement, then autocommit is usually wrong, and what you usually want is transaction-per-request. If you have exactly one statement, then autocommit is exactly identical to transaction-per-request.
Also part of the transaction-per-request pattern is that the transaction is started when the first statement is invoked. So there's no overhead for zero-statement requests either.
It seemed you were arguing against using transactions by default because they didn't roll back a call to a web service. I meant to point out that the issue in your case seems less about db transactions and more about the code and error handling.
This seems to be the same issue as megaupload. A company outside the US, marketing a service that's illegal in the US to US citizens. Money paid for the service is then moved overseas. (I understand there may have been users in other countries, like megaupload)
While not something I necessarily agree with - I don't think this particular move indicates all .COMs are now threatened.
It indicates that anyone using a .COM domain must either: 1) Not do business with American customers. or 2) Be aware of every U.S. law to avoid allowing their American customers from breaking one of them.
But that is already an issue - whether or not you have a .com domain name. The domain name is just an asset and the government routinely seizes assets when filing criminal charges.
The US government has always had dominion over .coms (and .nets). Verisign manages .com's through a contract with the US Department of Commerce. That's where they get there authority.
If .com domains weren't considered to be USA based though then a USA citizen would be the one that was being charged for breaking the law wouldn't they?
Flip it around. Suppose someone is selling online under a Somali .so domain rather than a .com; the law should operate in the same way as long as the web servers themselves aren't located in USA.
Isn't it the assumption that any transaction with a .com is essentially under the purview of USA law that is at issue?
This just emphasises the need for .com to be considered neutral territory. It's only a redirection mechanism - USA can have and apply their laws to .co.us and of course any server that is based in USA.
It's not transactions with the .com that's at issue. It's the fact that a company operating a business the government considers illegal is making money in the US and moving it overseas.
It's all about the money. Not .COMs.
Running a gambling site on an .so domain and hosting the servers overseas while profiting in the US will still get you indicted. The government might not have the authority to shut off your internet presence but I'm sure they could turn off finances in the US. And certainly make travel to certain countries an issue.
Your second point makes it seem like there are so many laws that you have to be aware of to avoid getting your domain seized by the US. These latest busts have been for gambling and pirating, I bet the owners knew this was coming sooner or later.
Your second point makes it seem like there are so many laws that you have to be aware of to avoid getting your domain seized by the US.
Well yes, but in principle that's exactly right. Really think about this: in principle you need to know the entire legal code of the US and all of the ways that someone in the US might use your site to try to break that legal code, before you know whether you're safe. If you start operating the next version of CraigsList and people in the US start using it to sell fish which were caught in violation of U.S. law, it doesn't matter whether you realized it was happening at the time, whether those fish are legal in your country, or any such thing; the U.S. Fish and Wildlife Service could get a prosecutor to convince a judge to issue a takedown warrant for your domain.
What's that, you say? You just run a tasks-and-dates management web app? You'll ban users from the U.S. from logging in? That's not necessarily going to help. If your service gets used by some radical Muslims in some country that the U.S. happens to be bombing, they might take you down. Given the tempting targets, I guess you'd best be banning Iran from logging in, just in case the elite there find your app useful.
Bottom line is, in this case it's quite possible that the gambling enterprise that they were running was perfectly legal in their home country and happened to be illegal in one state in the U.S. -- and people in the U.S. were using it for its intended purpose illegally. So in the bigger picture, if you really think about it, the fact that you're not catching the US government's attention yet is no defense: in principle you need to know all of the things which are illegal in the U.S., and how users both inside and outside of the U.S. might use your site to do those things. Otherwise, you'd better move off of .com, to some domains run by a government which doesn't routinely steal them.
A little anecdote to support your story: Just this morning a US citizen using my appointment scheduling web service (based in Europe) got into trouble for selling English lessons to Iranian students (it wasn't intentional he sells English lessons to anyone, PayPal flagged the money transfers).
I spend a good part of this morning figuring out how to keep Iranians off of the scheduling calendar. I believe that world peace would be much better served with more Iranians learning English but I really do not want my business to get in trouble with the US over it. Sad really.
Megaupload hosted a bunch of its content on American servers located on American soil. It was my understanding that this was the justification for the takedown of that particular foreign company.
I believe all lithium-ion batteries have a low-voltage threshold that once crossed they can not be charged again. It's similar to a fuse - once tripped - there's no* getting around it. This protection is to guard against shorts in the internal circuitry. With the current technology there is no way around it.
decvax was DEC unix engineering groups vax on uucp/usenet. I believe it was the first system to move email in realtime. Microsoft must have been linked through this vax.
Seems like financial/quant computing would be a natural fit. The author mentions ocaml being well suited for general programming needs - Anyone using ocaml (or haskell/f#/etc.) for real production code?
Edit: should have mentioned this earlier for an example - xmonad is written in haskell
Several investment banks are using these languages in production (BarCap (F#) and Standard Chartered (Haskell) are the names that come immediately to mind).
And of course Minsky's employer, Jane Street Capital, writes everything in OCaml.
There are plenty of commercial users outside the financial sector too but those users tend to be smaller companies.
Whenever I see OCaml brought up, it is nearly always by Minsky. Is it that very few people use it in general? That it is particularly well suited to the problems a private hedge fund faces (oxymoron I know, but I don't know how else to describe Jane Street)? Or that Minsky just happens to be vocal in the internet circles I tend to gravitate toward?
Jane Street is a `prop shop' in the lingo of the industry.
You are right, OCaml doesn't see too much use outside of Jane Street, Citrix and a few others. I think the academics mostly left it in favour of Haskell. Also the owner of the OCaml project didn't embrace community development early on. It's more like a cathedral than a bazaar. They are signs showing to change, but it's probably already too late for mainstream popularity.
John Carmack mentioned OCaml and Haskell at the last QuakeCon (on the topics of game scripting and static analysis), citing performance and hiring issues: https://www.youtube.com/watch?v=4zgYG-_ha28 (1:10ish)
I'm not sure about the performance issue. If it stays within a reasonable (low single-digit) factor I think the hit is worth the quality guarantees you can get out of it. The hiring/education issue is probably the #1 reason so few attempts are made in this direction.
Wow, I had no idea haxe was still around. I looked at using it about 4-5 years ago and dismissed it as not ready for prime time, but that looks like a reasonably active community.
Honestly I'm quite surprised that it hasn't taken off more - the language itself is very nice and well-designed, and the way it handles multiple platforms is surprisingly elegant. The only real complaint I have with it is that the documentation is a bit disjointed.
