tag:blogger.com,1999:blog-78858641572960803152023-11-15T14:14:02.052+00:00Lazy, impatient and hubristic"We will encourage you to develop the
three great virtues of a programmer"
-- LarryWallAnonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-7885864157296080315.post-18460122323109626342017-06-15T12:34:00.000+01:002017-06-15T13:50:58.108+01:00What will happen with Ethereum in 30 years?<div style="-en-clipboard: true;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="color: black; font-family: "arial" , "helvetica" , sans-serif; font-size: small; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><b>tl;dr</b>:</span></span></div>
<ul>
<li><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">We will continue to have a decentralized, global chain powered by ETH, but most of the economic activities using smart contracts will happen on “national" chains, which are regulated by governments and interconnected through gateways</span></span></li>
<li><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Each national chain will place different constraints on the activity according to the law of the land. E.g. a Chinese chain will have different constraints compared to UK’s chain, etc.</span></span></li>
<li><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Similar to trade area, we’ll see chains being consolidated amongst economic regions (EU, NAFTA, ASEAN, TTIP), and smaller countries will use the chain of regional players</span></span></li>
<li><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Crucially, the role of the judiciary and human intervention continues - smart contracts will have an interface to allow judiciary and regulators to intervene. Humans remain to be the ultimate arbiter of the contract system. </span></span></li>
<li><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">The biggest contribution of smart contract system will be the increase in efficiency to conduct economic activity, NOT the decentralized enforcement of contract system</span></span></li>
</ul>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<h2>
<span style="font-weight: bold;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Why the global (truly decentralized) chain can’t carry the bulk of economic activity</span></span></h2>
<h3>
<span style="font-weight: bold;"><span style="font-family: "arial" , "helvetica" , sans-serif;">We *like* human intervention</span></span></h3>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="orphans: 2; widows: 2;"> In short, we want human intervention, and the </span><span style="orphans: 2; widows: 2;">crux of decentralization in smart contract system is enforcement through lack of such interventions. Once the contract is signed, it’s mechanically executed, and parties cannot back out or change it. It’s an ultimate form of “your are on your own”. Forgot your private key? Tough luck because you’ll never see that money again. Somebody mislead you to sign a fraudulent contract? Well, tough luck - you shouldn't have made a mistake of signing it.</span></span></div>
<div>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> This mode of operation is simply unsuitable for the vast majority of daily economic activities (just count how many times you lost a cash card, or appealed to a redress scheme etc). It’s great not having to worry about losing a key to your entire net worth. It’s great that you have a remedy in case of injustice. Being able to retroactively intervene on contract execution is essential to the smooth functioning of the economy.</span></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> </span></span><span style="font-family: "arial" , "helvetica" , sans-serif;">Having these on a truly decentralized chain is not practical. Imagine we had a "hook" for smart contracts to allow governments to intervene - this would defeat the point of decentralization. </span><span style="font-family: "arial" , "helvetica" , sans-serif;">You might argue that blockchain *has* a way to retroactively intervene (<a href="https://qz.com/730004/everything-you-need-to-know-about-the-ethereum-hard-fork/">which has happened in Ethereum before to stop a "fraud"</a>). However, this mechanism is far from practical to handle day to day problems. First, it's supposed to be reserved for truly extraordinary situations, not for your daily grievances. Second, it's akin to a global </span><span style="font-family: "arial" , "helvetica" , sans-serif;">plebiscite where votes are weighted by the voters' asset. </span><span style="font-family: "arial" , "helvetica" , sans-serif;">I think history shows this isn’t the form of arbitration most people would prefer.</span></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="orphans: 2; widows: 2;"> Of course *some* economic activity are well suited for the de-centralized chain. For example</span>…</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<ul>
<li><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">If there is no alternative enforcement available anyways</span></span></li>
<li style="list-style: none;"><ul>
<li><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">E.g. if you are doing something illegal, and hence can’t call the police</span></span></li>
</ul>
</li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">The contract is so trivial that parties are willing to abandon it in case of issues</span></li>
<li style="list-style: none;"><ul>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">E.g. internet points</span></li>
</ul>
</li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Parties prefer the arbitration mechanism of the de-centralized chain</span></li>
<li style="list-style: none;"><ul>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">There will be a significant number, but I’d still think it would be a minority </span></li>
</ul>
</li>
</ul>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-weight: bold;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Not enough liquidity to read the world</span></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"> One of the most difficult question in smart contract system is how you "read" from the world, as in injecting what's going on in the real-world, into the contract system. Suppose I create a car insurance using smart contracts. Now an accident happens. You may have encoded all the rules precisely and neatly in the smart contract, but we still somehow have to let the contract know what happened in the real world - like the fact that the accident happend, in what situation etc.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"> Decentralized prediction markets like Augur is a theoretical solution to this. In this model, economic incentive is used to turn humans into sensors. Essentially, witnesses are invited to make money by offering what they see, and because they most probably lose money if they lie, they will tell the truth.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> This will work for things that can be observed by enough number of people - </span><span style="font-family: "arial" , "helvetica" , sans-serif;">like stock market indices, weather, election outcome etc. But it will not work for events that are too small (like a car accident</span>),<span style="font-family: "arial" , "helvetica" , sans-serif;"> because there won’t be enough witnesses (liquidity) that can be incentivised.</span></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"> Moreover (at least for the foreseeable future), these "reads" will have to involve a lot of interpretation. For example, did someone violate the non-compete clause in an employment contract? You could, of course, apply the same mechanism as Augur to this and basically hold jury trials, which is unsuited for a LOT of situations, especially so if only a low number of "sensors/juries" can participate.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"> For this reason, centralized institutions like the judiciary, banks, insurance companies, regulators etc. will most likely continue to be instrumental in the contract system, which again erodes the point of decentralization.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<h2>
<span style="font-weight: bold;"><span style="font-family: "arial" , "helvetica" , sans-serif;">What will be the point then?</span></span></h2>
<div>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> If the system isn’t decentralized, then what’s the point? Isn’t that what blockchain is about? Yes. But that said there is an additional, significant (IMO world changing) contribution that smart contract puts on the table. In essence, smart contract system is API on steroids (<a href="http://www.eshioji.co.uk/2016/06/yes-blockchain-is-going-to-change-world.html">my previous article on this</a>).</span></span></div>
<div>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> Today we are just starting to witness how APIs change the world - companies, banks and governments are opening up their functions through API, which allows third parties to innovate and build on them. The nature of smart contract will be similar, but far more drastic.</span></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif; orphans: 2; widows: 2;"> For example, imagine how moving works right now. You find a suitable flat. You get proof of income, scan it and send it to the agent. You exchange contract, notify the government, utility company etc. that you have changed your address, etc. etc.</span></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif; orphans: 2; widows: 2;"> There are services that help with this process, and some parts have even APIs available that could be used (e.g. setting up rent payment). If more parts of the process becomes available through APIs (for example obtaining credit report, reporting change of address to the government), these services will work better and more can be automated.</span></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="orphans: 2; widows: 2;"> This is already a big improvement, but smart contract can go further. For example, I can write software that analyses the contract - say my utility contracts, and suggest </span>optimization. I can easily create a variation of contract - e.g. I can ask a company to validate the level of income of my tenants (while not revealing other irrelevant parts of the contract), without having to phone them up. I can just ask the tenant to sign such a smart contract. I can also assign the contract easily - suppose I have the right to assign my tenancy to someone, subject to credit check. I just need to sign such a contract with the landlord at the beginning - once I initiate the assignment, the assignment will happen automatically if the credit check succeeds.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"> None of this is impossible without smart contracts, in the same way none of this is impossible without APIs either. But of course it makes it a hell of a lot easier, and this is crucial. API bring changes to the world by being a catalyst - it makes things happen that could have happened but didn't because it took too much energy to make it happen. Smart contract will be the same.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<!--?xml version="1.0" encoding="UTF-8"?-->
<br />
<div>
<h2>
<span style="font-weight: bold;"><span style="font-family: "arial" , "helvetica" , sans-serif;">So, how will the future look like then?</span></span></h2>
<div>
<h3>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Few, but not a single chain</span></span></h3>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> The biggest advantage of API was the fact that the internet connected everybody. Just imagine it were fragmented instead - it would be far less useful. This will be the same for Smart Contracts. However, it will take a long time until the legal framework can be converged. Unless that happens in 30 years, which is unlikely, each legal platform (like a nation or entities like EU) will have to have their own chain. </span></span><span style="font-family: "arial" , "helvetica" , sans-serif;">In the </span>meanwhile,<span style="font-family: "arial" , "helvetica" , sans-serif;"> the chains could be connected via gateways (APIs). </span></span></div>
<h3>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Every contract will have a "hook", allowing governments to intervene</span></span></h3>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> In order to allow government bodies (like the judiciary, redress schemes etc) to intervene efficiently, all contract will come with hooks that can be used for such interventions.</span></span><br />
<h3>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Government will provide a lot of the "reads" for the smart contract system</span></span></h3>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> There will be trusted endpoints where the government can provide correct reads of facts, just like it happens in today's society.</span></span><br />
<h3>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Cambrian Explosion of startups</span></span></h3>
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"> Smart contract will be the ultimate platform for startups. We will look back and say the rise of tech startup in the beginning of 21st century was only a small start. </span></span><br />
<span style="orphans: 2; widows: 2;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></span></div>
</div>
Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-79113862014297942942016-06-14T20:48:00.001+01:002016-06-14T20:56:11.877+01:00Yes, Blockchain Is Going To Change The WorldA recent Forbes article "<a href="http://www.forbes.com/sites/francescoppola/2016/06/13/blockchain-meh/#76f2b20943cc">Blockchain Is Not Going To Change The World</a>" motivated me to write why I think Blockchains will change the world, perhaps for a reason that's not commonly discussed.<br />
<b><br /></b>
<b>What the article gets right</b><br />
The article is quite right to point out that ledger based on blockchain doesn't actually solve things people have problem with. For example, a ledger based on private blockchain is really nothing more than a poor substitute for technologies the banks already have. Public blockchains like Bitcoin is a bit more interesting but I agree that it is unlikely to "change the world", at least alone.<br />
<br />
<b>What the article gets wrong</b><br />
The article doesn't address Smart Contracts, which is much more interesting than boring ledgers. The biggest difference is that we don't have anything like it right now. The ledger is boring because we already have ledgers. Smart Contracts are interesting because we don't have anything quite like it now.<br />
<br />
<b>Smart Contracts' little brother did change the world</b><br />
Before we talk about Smart Contract we should talk about APIs, because in my opinion Smart Contracts are essentially APIs on steroids. So what's API and how did it change the world? API itself is as ancient as programming languages. But we came to understand its true importance only recently: the ability to package services into building blocks and combining them to create new services. Amazon is a famous pioneer in this, who successfully went on to create an empire powered by APIs.<br />
<br />
The key concept of API is very simple; all it does is to break up your services and make them separately accessible to others through programming. There is nothing mysterious about it. But its transformation effect was enormous. 15 years ago, if I wanted to create a new service (let's say an e-commerce site), I had to do a lot by myself. Getting servers, configuring network, figuring how to analyse customer behaviour, taking payments... it was a formidable prospect.<br />
<br />
Now, I can do most of these things really easily thanks to APIs. I call Amazon's API to get servers and network in an instant. Mixpanel's API to analyse customer behaviour. Stripe's API for payment, and so forth. Creating a new e-commerce site is suddenly pretty trivial. We have to thank API for the recent explosion in app. economy and the startup economy, and bunch of other stuff.<br />
<br />
<b>Why is Smart Contract better than API?</b><br />
While APIs are pretty good at packaging services, it's still rather crude. For a starter, API designers have to anticipate how their services might get used and define how the API looks like. Good API designs are "generic", meaning that they can support many different, often unanticipated use cases, but a significant restriction is still there.<br />
<br />
For example, imagine you want to start a new business called "housing consultant". You give advice to prospective house buyers, and if they end up buying the house, you'll get commission. That's of course certainly possible with just APIs. I track which houses I recommended, periodically check if the clients ended up owning the house through API provided by the government. If they did, I charge them through a payment API. This is pretty easy, but I still need to have servers. I still need to manage the contracts between the client. What if instead, I could just write up a contract that executes itself. I tell my client, "I have a house that's just for you. If you sign this contract, I'll tell you which house. If you end up owning the house within 5 years, I'll charge you $10". Once the contract is signed I can forget about it. If the condition eventually happens, payment is automatically taken.<br />
<br />
Maybe one of my client wants to amend the contract; they want to change the condition to "if I end up owning the house for more than 3 years within the next 5 years". No problem, you can just change it a little bit and sign it. No need to worry about making notes, changing software etc. If it says so in the contract, you can be quite sure that it will be executed accordingly.<br />
<br />
Let's say you now want to expand your business into advising people on how to save energy; for every dollar saved compared to last year's bill, you get 1%. This is again certainly possible with APIs, but much easier if energy companies offered interaction through Smart Contracts instead. <br />
<br />
Let's say you now have bunch of these smart contracts that generates some income from various people, for various reasons, but you find out you are likely to die within a year. No problem, you can just securitise all these contracts and sell them. That itself is nothing new, with enough effort you can do this today. But it's for sure impractical for an individual to do it. With Smart Contract this will become practical, just like API made it possible for an individual to start a e-commerce site overnight.<br />
<br />
<b>Where does the trust come from?</b><br />
<div>
"Well how do contracts know when to execute themselves?" you might ask. The easiest is to use trustable "endpoint"s, like a "land registry smart contract", or a "land registry API" provided by a trust worthy party. For example, we just tell the contract to check an endpoint provided by a government, and if it detects the condition to execute itself. That doesn't sound very magical but we still gained a lot by being able to combine such endpoints in a manner that was not possible before.</div>
<div>
<br /></div>
<div>
There is also some interesting ideas to generate trust in a more unconventional manner. For example, would you trust Wikipedia as a trust worthy endpoint in your smart contract? Maybe not, somebody could inject false information into articles and trigger contracts fraudulently. </div>
<div>
<br /></div>
<div>
What if I make some adjustments... say I pick a very popular wikipedia article (like POTUS). And we say that the information has to be present in the article 80% of the time for one year before the contract is triggered. We are almost getting there, it'll be pretty hard to pull off this fraud. Extend this concept further and you can crowd source "truth".</div>
<div>
<br /></div>
<div>
</div>
<div>
<br /></div>
<div>
</div>
Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-89503584788730665642013-10-06T19:42:00.000+01:002014-08-21T16:04:45.191+01:00Why I don't like NutmegNutmeg is a startup that provides investment management for consumers. Basically, when you sign up with them, they'll ask you some questions to figure out your risk tolerance, timeframes for investments, how much you want to pay-in each month etc. They will then go and buy investments (stocks, bonds, REITs etc.) for you and manage your portfolio on behalf of you (i.e. they will buy/sell your assets on their discretion).<br />
<br />
They charge up to <b>1.0%</b> for this asset management piece depending on the amount of asset you have with them etc. This doesn't include the cost that the assets incur themselves which they say is on average about <b>0.3%</b>.<br />
<br />
So why don't I like it?<br />
<br />
<h3>
1.3% is WAY too expensive</h3>
Before I can explain why 1.3% is too expensive, I have to quickly touch on the two different investment strategies, <a href="http://en.wikipedia.org/wiki/Passive_management">Passive</a> and <a href="http://en.wikipedia.org/wiki/Active_management">Active</a>.<br />
<br />
Active strategy is what most of us usually think of investment strategies. In an active strategy, you'd sit down and think about what to buy. For example, you might go "Now that Ballmer is gone, I bet Microsoft will be way more successful in the future", and thus buy Miscrosoft stocks. Or you might go "I think Chinese stocks are way overvalued these days" and sell some Chinese stocks.<br />
<br />
The key here is that you are trying to predict the future and/or outsmart other investors. You predicted that Microsoft will do well and that's why you are buying their stocks. You think other investors are overvaluing Chinese stocks, and that's why you are selling them.<br />
<br />
This is obviously hard work and requires ample experience, and this is where companies like Nutmeg come in. They'll do this work for you, and in turn you pay them the 1.3% fee.<br />
<br />
In the world of Active investment strategy, 1.3% isn't necessarily expensive. The problem however, is that <b>if you are an average consumer, you won't need Active strategy</b>. There are people who disagree with this (usually fund managers, stock brokers etc.), but the evidences are overwhelming. A recent study by S&P for example, which examined 10,000 actively managed funds, found that 82% of them underperfom passive funds (<a href="http://www.forbes.com/sites/rickferri/2012/10/11/indexes-beat-active-funds-again-in-sp-study/">source</a>).<br />
<br />
Warren Buffet, the legendary investor has also stated:<br />
<br />
<blockquote class="tr_bq">
[...] <b>most investors are better off putting their money in low-cost index funds</b> [...] very low-cost index is going to beat a majority of the amateur-managed money or professionally-managed money [...] gross performance [of actively managed funds] may be reasonably decent, but the fees will eat up a significant percentage of the returns </blockquote>
(<a href="http://www.reuters.com/article/2007/05/07/berkshire-indexfunds-idUSN0628419820070507">source</a>)<br />
<br />
And put his money where is mouth is. He specified his personal portfolio after his death to be invested in low cost index funds (<a href="http://www.economist.com/news/briefing/21601500-books-and-music-investment-industry-being-squeezed-will-invest-food">source</a>).<br />
<br />
Really, there is very little reason for an average consumer to go with active investment.<br />
<h3>
Believe me, it's not hard to do investment yourself</h3>
A couple of people have told me "Well, but I don't want to spend any time thinking about my investments. I'd rather just pay 1.3%". They probably don't realize how big the impact of these costs are in the long term.<br />
<br />
<blockquote class="tr_bq">
[...] illustrates how strongly costs can affect long-term portfolio growth. It depicts the impact of expenses over a 30-year horizon in which a hypothetical portfolio with a starting value of $100,000 grows an average of 6% annually. In the low-cost scenario, the investor pays 0.25% of assets every year, whereas in the high-cost scenario, the investor pays 0.90%, or the approximate asset-weighted average expense ratio for U.S. stock funds [...] The potential <b>impact on the portfolio balances over three decades is striking</b>—a <b>difference of almost $100,000</b> (coincidentally, the portfolio's starting value) <b>between the low-cost and high-cost scenarios</b></blockquote>
<div>
(<a href="https://personal.vanguard.com/us/insights/investingtruths/investing-truth-about-cost">source</a>)</div>
<br />
Yep, they call 0.90% "high-cost scenario". 1.3% is <i>really</i> high, and it will cost you a lot.<br />
<br />
Asset allocation (i.e. deciding what to buy, what to sell) is very simple in Passive investment. Vanguard, an investment firm that pioneered Passive investment has generally good resources to start, for example this <a href="https://www.vanguard.co.uk/documents/portal/literature/asset-allocation-guide.pdf">guide</a>. Here is <a href="http://www.forbes.com/sites/rickferri/2013/05/23/three-simple-index-fund-portfolios/">another good starting point</a> from Forbes. These kinds of dead simple portfolio are the ones that "consistently outperforms most actively managed funds" as noted earlier. Once you decided on an asset allocation based on the return you want, the only thing left really is to find the cheapest mutual fund/ETF that tracks that asset class and buying it.<br />
<br />
If you are still too lazy to choose your own asset allocation, you can buy "balanced funds", which are mutual funds with pre-made, low-cost index asset allocation. <a href="https://personal.vanguard.com/us/funds/vanguard/all?reset=true&sort=name&sortorder=asc&assetclass=bal#upperTB=attrTBI&lowerTB=genTBI">Here</a> is a collection from Vanguard. Note the expense ratio. The lowest one has 0.1% while the highest one has 0.18%. Yeah, compare that with 1.3%.<br />
<br />
These "balanced fund"s have in general a very simple asset allocation, and hence it's easy to just copy the allocation. In fact, there is even a <a href="http://etfdb.com/tool/mutual-fund-to-etf/">tool for that online.</a> This will give you an even lower cost, but the downside is that you'll have to do <a href="http://en.wikipedia.org/wiki/Rebalancing_investments">asset rebalancing</a> yourself whereas "balanced fund"s will do that automatically for you.<br />
<br />
<br />
<br />
So yeah, that's why I don't like Nutmeg. The world needs more passive investment, not active.<br />
<br />
<br />
<br />
<h3>
</h3>
Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-83434653371693332522013-08-24T10:29:00.002+01:002013-08-24T10:29:16.723+01:00日本人ソフトウェアエンジニアのための、海外スタートアップ企業就職ガイド (職探し編)<span style="font-family: Arial; font-size: 13px;"> 僕は1年ほど前に、日本からイギリスのスタートアップに転職しました。海外スタートアップへの転職は簡単ではないですが、技術的に売れるものと、最低限の英語力があれば、あとは十分時間をかければいつかは成功するはずです。今回は、どういう風に職探しをすればよいかについて書いてみたいと思います。</span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<ul>
<li><span style="font-family: Arial; font-size: 13px;">米国以外もマークする</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">ソフトウェアエンジニアの場合、シリコンバレーに職が集中しているのでそこばかりマークしてしまいがちですが、<b>他の国にもポジションはあります</b>。数値で比較した訳ではないですが、イギリス、カナダ、オーストラリア、アイルランド、シンガポール、ドイツ、オランダ、スウェーデン、スイス、ルクセンブルグなどに職が多いようでした。</span></li>
<li><span style="font-family: Arial; font-size: 13px;">中国、インド、東欧など発展途上国にも職はありますが、給料が低いため<b>貯蓄が十分できなくなってしまう</b>場合が多く、日本でお金が必要になったり、帰国することになった場合に困ってしまうので正直あまりお勧めできません。ただし、中には特別光り輝いているスタートアップもあるので、そういうところに行くのであればアリじゃないかと思います。</span></li>
</ul>
</ul>
<div>
<span style="font-family: Arial; font-size: x-small;"><br /></span></div>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">日本市場をターゲットにしているスタートアップを探す</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">このパターンが結局一番成功しやすいです。そもそも相手企業も<b>ハナから日本から雇うつもりであることが多い</b>ので、通常ビザもスポンサーしてもらえますし、会社のお金で面接に呼んでもらえることが多いです(=そのついでに他企業の面接も受けられる)。技術面での要件も低くなります。</span><span style="font-family: Arial; font-size: 13px;">幹部への道も開けやすいので、キャリアアップの点からも良いです。</span></li>
</ul>
</ul>
<div>
<span style="font-family: Arial; font-size: x-small;"><br /></span></div>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">でも、日本に縁のないポジションも対象に入れる</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">日本に縁のある求人はそんなに多くないので、それにこだわっているとチャンスが少なくなってしまいます。<b>日本に縁のないポジションでも技術的なウリがあれば十分可能</b>なので、対象に入れるべきです。</span></li>
</ul>
</ul>
<div>
<span style="font-family: Arial; font-size: x-small;"><br /></span></div>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">日系企業の現地採用は注意する</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">日系企業への就職は一番ハードルが低いのですが、残念ながらあまり良いことがないのが現実です。僕は日系企業の本社から海外子会社に派遣されて仕事をしていた時期があるのですが、現地採用の日本人人材は基本給料が低く、出世の可能性もほぼない上、雇用の安定性もないことがほとんどです。しかも仕事の仕方などは全く日本企業と変わらない場合が少なくないので、せっかく海外就職したのに日本の企業で派遣社員として働くのと変わらない状況になってしまいます。それなら<b>日系企業の本社に就職して派遣された方が100倍いい</b>に決まっています。</span></li>
</ul>
</ul>
<div>
<span style="font-family: Arial; font-size: x-small;"><br /></span></div>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">転職エージェントにも当たる</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">多くの転職エージェントは現地に既にいないと相手にしてくれないのですが、日本に縁のあるポジションや、なかなか人材が見つからないポジションであれば興味を示してくれます。いっぱいあるので、いっぱい当たってみましょう。企業の情報や面接のアドバイスなどがもらえるので、ありがたい存在です。</span></li>
<li><span style="font-family: Arial; font-size: 13px;">ただし、<b>エージェントはあなたの味方ではなく、お金の味方</b>だということを忘れないでください!(笑)あまりマッチしたポジションでなくても取りあえずねじ込もうとするケースが少なくないですし、企業情報もいいことばかり挙げて悪い情報は出してくれないのが普通です。国の慣習によりますが、日本と違って安く売ってなんぼな場合もあるので、強引に給料を下げる交渉をしてくる場合もあります。どんなにエージェントが親切でも、早めに就職先企業と直接交渉する状況に持っていった方が良いでしょう。</span></li>
</ul>
</ul>
<div>
<span style="font-family: Arial; font-size: x-small;"><br /></span></div>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">国際的な就職活動で便利なツール</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;"><a href="http://indeed.com/">Indeed.com</a></span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">求人のメタ検索サイトです。一言で言えば<b>求人のグーグル</b>、「最強」です。各国版があります。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;"><a href="http://careers.stackoverflow.com/">StackOverflow Career</a></span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;"><b>良質なスタートアップ企業の求人が多い</b>です。また、StackOverflowでレピュテーションを貯めているとスカウトされる場合もあります。僕はこのサイトがきっかけで今の企業を見つけました。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;"><a href="http://monster.com/">Monster.com</a></span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">主にエンジニア向けの求人サイトです。これも各国版があります。<b>個人的にはあまりいけてないポジションが多かったような印象</b>があるのですが、僕の気のせいかもしれません。規模はでかいです。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;"><a href="https://angel.co/">AngelList</a></span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">主にスタートアップ企業の求人となります。StackOverflow Careerと違って広告を出すのがタダなので、<b>始まったばかりでお金のない小さなスタートアップの求人も出ています</b>。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;"><a href="http://www.glassdoor.com/">Glassdoor</a></span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">主に<b>給料水準を知るのに役に立ちます</b>。若いスタートアップの場合その企業自体の口コミが投稿されている事は少ないのですが、同じような職種・経験の人の給料水準が見れるので、とても有用です</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;"><a href="https://www.duedil.com/">Duedil</a></span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">会社についての公開情報を集めてきて見せてくれるサイトです。<b>会社として登録してさえあればなんらかの情報は見れる</b>ので(創立年、株主構成、資本構成など)、便利です。</span></li>
</ul>
</ul>
</ul>
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-87032973536012770402013-08-21T19:27:00.002+01:002013-08-21T19:27:59.189+01:00日本人ソフトウェアエンジニアのための、海外スタートアップ企業就職ガイド (準備編)<span style="font-family: Arial; font-size: 13px;"> 僕は1年ほど前に、日本からイギリスのスタートアップ企業に転職しました。海外スタートアップへの転職は簡単ではないですが、技術的に売れるものと、最低限の英語力があれば、あとは十分時間をかければ可能なはずです。今回は、日頃どういった準備をすべきかについて書いてみたいと思います。</span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<h3>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">関連性の高い学位を取る</span></li>
</ul>
</h3>
<ul>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">関連する学位を持っていると、ビザ取得や就職活動で圧倒的に有利です。情報系の修士以上が理想ですが、学士でも、また数理系(数学、電気工学、物理学など)の学位でも十分役に立ちます。ただ、実務経験を学位に代えられるケースもあるので、関連学位がないと不可能という訳ではありません(何を隠そう僕の学位も生物学でした)</span></li>
</ul>
</ul>
<h3>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">参入障壁の高い技術をウリとして育てる</span></li>
</ul>
</h3>
<ul>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">企業や国の立場に立って考えると、わざわざ外国から人を雇うには相当の理由が必要になります。一言で言うと、これらの「理由」は①給料が安い・仕事がきついため人が集まらない、②必要な技術を持った人が見つからない の2パターンに分けられます。①のコースは色々悲惨なので、絶対に②のコースを目指すべきです。</span></li>
<li><span style="font-family: Arial; font-size: 13px;">一番簡単なのは、技術的に難度が高くてニッチな技術を売りにすることです。例えば、生体認証、音声認識、航空管制、暗号技術など非常にニッチな分野は技術者が見つけにくいので、求人さえあれば内定もビザも下りやすいです。ただ、あまりニッチすぎると求人が少なくなるので、分散処理、並行処理、関数型言語、金融フロントなど「適度にニッチ」な分野が最もオッズが良いのではないかと思います。鍵は、難度が高い=参入障壁が高い事です。アジャイル、Webアプリ、クラウドなど敷居が低いウリは国内で十分見つかるので、海外からの就職は難しくなりがちです。</span></li>
<li><span style="font-family: Arial; font-size: 13px;">特におすすめなのは機械学習、人工知能、統計などのアナリティクス分野です。この分野は敷居が高い上需要が爆発しているので、スタートアップのみならずあらゆる分野の事業会社、コンサルティング会社などから引く手あまたで、ビザも内定も非常に取りやすいです。かつ給料水準も素晴らしく、幹部へのキャリアパスも開きやすいので、いいこと尽くめです。こっち系にいく選択肢があるのなら迷わず選ぶべき分野です。</span></li>
</ul>
</ul>
<h3>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">公開実績を貯める</span></li>
</ul>
</h3>
<ul>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">海外からの転職活動は会って話ができる時間が短いので、客観的に検証できる材料の比重が上がります。日本で日常生活を送りながら蓄積できるものもたくさんあるので、コツコツ取り組むといつか役に立つ日が来ることでしょう。効果が高い順に並べるとこんな感じです:</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">OSSプロジェクトのコミッターになる</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">「この有名なプロジェクトのこの部分をやりました、これがそのコードです」と示せればこんなに強力なアピールはありません。例え有名なプロジェクトでなくとも、あるいはコアな部分に関わっていなくとも、何かしら貢献したものがあれば十分アピールになります。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;">OSSを公開する</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">自分一人ででも、何かしらOSSやサービスを世に出していれば、雇う側としては実力を見極めやすいので強力なアピールになります。もちろんモチベーションが高いことの証明にもなります。メディアはなんでもよいのですが、GitHubにしとけば間違いはありません。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;">英語ブログを書く</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">誰も読まないブログでも構いません。日々の発見や思ったことを綴っているだけでプラスになります。雇う側としては英語力のチェックにもなります。後から英語化するのは面倒くさいので、最初から英語のブログプラットフォーム(Bloggerとか)を使うのがおすすめです。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;">StackOverflowでレピュテーションを集める</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">StackOverflowはプログラマ向けのQ&Aサイトです。業界では非常に有名で、ユーザ数を230万数え、有名なプログラマも数多く活動しています。ここで上位の評価を得ていると安心感がありますし、</span><span style="font-family: Arial; font-size: 13px;">回答の履歴から、その人の興味関心や開発に対する考え方、コミュニケーション能力を推し量ることもできます。目安としては数千くらいレピュテーションを貯めておければベストです。</span></li>
</ul>
<li><span style="font-family: Arial; font-size: 13px;">LinkedInでリコメンデーションを集める</span></li>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">非英語圏からエンジニアを雇う際、「英語でうまくコミュニケーションを取っていた」とか「欧米的な風土でうまくやっていた」といったリコメンデーションがついていれば、雇う側に安心感を与える事ができます。必死になって集める必要はないですが、誰か書いてくれそうな心当たりがあれば頼んでおいて損はないでしょう。</span></li>
</ul>
</ul>
</ul>
</ul>
<h3>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">英語を磨く</span></li>
</ul>
</h3>
<ul>
<ul>
<li><span style="font-family: Arial; font-size: 13px;">いろんなところで「英語ができなくても気持ちさえあれば大丈夫」とか言われていますが、僕は全くそう思いません。確かにエンジニアは営業やマーケティングに比べれば求められる英語要件は低いですが、そもそも面接で実績やスキルをアピールできなくてはいけませんし、「こいつは社内で十分コミュニケーションを取ってやっていけそう」と思ってもらわなくてはいけません。また、先々出世するためには、コミュニケーション力(事実上≒英語力)がより重要になっていきます。焦る必要はないですが、英語力向上に努めるべきなのは明らかです。</span></li>
<li><span style="font-family: Arial; font-size: 13px;">ちなみに、個人的に英文法の勉強はあまり有用でないと思います。細かい文法が間違っているから言いたいことが伝わらないということはあまりありません。語彙、単語の使い方についての理解、発音の問題で伝わらないことの方が遥かに多いです。ですので、これらの力を強化できるような学習をした方が良いような気がします。</span></li>
</ul>
</ul>
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />
<span style="font-family: Arial; font-size: 13px;"></span><br />Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-18638153748416115922013-08-17T14:01:00.003+01:002013-08-21T18:13:22.336+01:00海外就職のリアルな話 ここ最近、森山たつをさんを始めとするブロガーのお陰で海外就職が注目されているようなので、1年ほど前に海外就職した経験から、自分なりにリアルなところをお話ししてみたいと思います。<br />
<br />
<h3>
発展途上国は厳しい</h3>
森山さんは、「景気のいいところで仕事ができる」、「給料水準は低いが、物価が安いので高い生活レベルで暮らせる」など、主にアジアでの就職のメリットを説いています。確かにうなずける点はあるのですが、次のようなデメリットもあります:<br />
<br />
<ol>
<li>貯金力が低くなるため、日本でお金が必要になったり、帰国を強いられた場合に困る</li>
<li>育児に適した環境を整えにくい</li>
</ol>
<br />
まず、1について見ていきましょう。森山さんの記事には、「<a href="http://www.j-cast.com/kaisha/2012/09/06144723.html?p=all">物価が4分の1のジャカルタで、手取り16万円</a>」とあります。先進国での生活費をざっくり20万円と仮定すると、ジャカルタでの生活費は5万円となるので、月11万円貯金ができる計算となります。一方、先進国で手取り40万の仕事をすると、貯金は月20万円です。夫婦で共働きしたり、節約したりするとこの差はさらに広がります。例えば、ジャカルタで頑張って生活費を1万円に切り詰めたところで15万円しか貯金できませんが、先進国で生活費を10万円に切り詰めると、30万円貯金する事ができます。<br />
<br />
つまり、発展途上国で生活している分にはいいのですが、親の具合が悪くなるなど何かの事情で日本でお金が必要になったり、帰国せざるを得なくなると一転困窮してしまうおそれがあるのです。年金についてもしかりです。先進国で貯まった年金で発展途上国で暮らすのは容易ですが、発展途上国で貯めた年金で先進国で暮らすのは困難です。先進国にゆかりのある人が発展途上国で働くというのは、お金の面で非常にリスキーな選択なのです。<br />
<br />
次に、2について見ていきましょう。僕は日系メーカーの海外事業部で働いていたので、中国やインドで仕事をする機会が多くありました。特にインドには延べ半年くらい滞在し、いい思い出もたくさんあるし大好きな国なのですが、子供を育てるという視点から考えると選択肢から外さざるを得ないのです。<br />
<br />
まず、単純に空気が悪い。そんなもんどうにでもなるじゃないかと言われてしまいそうですが、水や食べ物はお金で解決できても、空気だけは避ける事ができません。インドにいた頃はよく散歩に出かけていたのですが、時間帯や場所が悪いと常時タバコをすっているようなもので、冗談抜きに息が苦しくなるほどです。国によって差はあれ、新興国の都市部である限りは、深刻な大気汚染を覚悟しなくてはいけません。<br />
<br />
また、なんだかんだ言っても教育環境も先進国の方が整えやすいです。これは好みもありますし、ちょっとキワドい意見になってしまいますが、発展途上国は社会・文化が先進国ほど進歩的でない傾向があります。例えば、インドでは未だ家柄や星座の一致をベースにしたお見合い婚が主流で、恋愛結婚は稀です。恋人ができて、結婚したいと思ってもできないことの方が普通なのです。女性の権利や、多様性の尊重、博物館・美術館やインターンシップの充実度など様々な面で、発展途上国の方が遅れている傾向があるというのが、残念ながら現実です。子供にはいろんな社会のあり方を経験してほしいので、発展途上国に触れる機会は持ってほしいなと思いますが、ぶっちゃけ欧米の進歩的な環境でのびのび育ってほしいというのが本音です。<br />
<br />
<h3>
本社からの海外赴任でないかぎり、日系企業は避けるべし</h3>
僕が勤めていた日系メーカーでは、海外赴任されるとそれはもう良い事尽くめでした。いろいろな手当がついて給料は上がるし、家はいいところに住めるし、海外にいる間は退職金の貯まり方が2倍になるし、現地法人ではポジションが1つ2つ上がるし、日本よりも仕事が楽な事が多いし、帰国すると昇進に有利だし、本当に海外赴任ほどおいしい話というのはそうありません。<br />
<br />
ところが現地採用というだけで状況は一変します。給料は低いし、昇進はまず望めません。海外赴任組からは「現地の人」と呼ばれさながら身分制度のようなものです。中でも現地採用された外国人は英語スキルなどを買われて要職についたり、本社に呼ばれて活躍する場合がありましたが、日本人は本社にたくさんつかえているので、重用される事はまずありません。その一方仕事ぶりは日本と変わらないので、日本の大企業に派遣で勤めているような状況になります。<br />
<br />
一方欧米系の企業であればそういった露骨な身分制度はありませんし、日本市場進出に関わる仕事などにつけば、社内で頼りにされ面白い仕事ができ、帰国した場合のキャリアも広がります。<br />
<br />
技術者であれば、日本に全く関係ない企業も十分選択肢となります。例えば、僕は今、日本に縁もゆかりも一切ない企業に勤めています。ロンドンやシリコンバレーなど国際化が進んでいる都市では技術者を各国から集めるのは普通になっているので、日本人だからと言って採用や昇進に不利になる事は通常ありません。給料も日本で技術職をやるより貰えることが多いですし、違った働き方や社風を経験でき得る物も多いでしょう。特にソフトウェア開発者の人には、是非日本に関係ない会社も選択肢に入れてほしいところです。<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-32207994701434974282013-07-06T16:39:00.002+01:002013-08-17T11:05:13.558+01:00A simplistic RedShift troubleshooting guide<span style="font-family: inherit;">Are you trying out RedShift, but not quite getting what you want? Confused why there are no INDEX statements? Here is a very quick troubleshooting guide. </span><span style="font-family: inherit; font-size: x-small;">Disclaimer: RedShift is still new and I haven't used it for that long yet. If you find something inaccurate in this article, please let me know. </span><br />
<span style="font-family: inherit; font-size: x-small;"><br /></span>
<br />
<h4>
<span style="font-family: inherit; font-size: large;"><u>Table of contents:</u></span></h4>
<ul>
<li><span style="font-family: inherit;"><u style="font-family: inherit;">Are you using it for something it wasn't built for?</u></span></li>
<li><span style="font-family: inherit;"><u style="font-family: inherit;"><span style="font-size: small;">Common design mistakes</span></u></span></li>
<li><u style="font-family: inherit;">Common confusions</u></li>
<li><span style="font-family: inherit;"><u><span style="font-size: small;">Stuff that you should do</span></u></span></li>
<li><u style="font-family: inherit;">Miscellaneous Notes</u></li>
</ul>
<u style="font-family: inherit;"><span style="font-size: large;"><br /></span></u>
<u style="font-family: inherit;"><span style="font-size: large;"><b>Are you using it for something it wasn't built for?</b></span></u><br />
<span style="font-family: inherit;">This is the most common way to get problems. If you answer <b>YES</b> to the following questions, you <b>might</b> be using RedShift for the <b>WRONG</b> problem.</span><br />
<ol>
<li><b>I'm using it for something non-analytics</b></li>
<ul>
<li>Yellow flag. RedShift isn't a replacement for "normal" relational DBs (aka "OLTP" DBs) like MySQL, Oracle etc. If you are directly writing to RedShift from your business applications, it's probably wrong.</li>
</ul>
<li><b>I don't do aggregation (SUM, COUNT etc.) or TopN (ORDER BY/LIMIT) queries</b></li>
<ul>
<li><span style="font-family: inherit;">RedShift is primarily good at scanning large number of rows. If you want to quickly fetch small number of records, you might get better result with other DBs that indexes these attributes.</span></li>
</ul>
<li><b>I'm looking for very short response time for reads (e.g. < 1 sec)</b></li>
<ul>
<li><span style="font-family: inherit;">RedShift is not optimised for "light"queries and tends to have longer response time compared to other DBs in this domain.</span></li>
</ul>
<li><b>I'm looking for very short response time for writes</b></li>
<ul>
<li><span style="font-family: inherit;">RedShift's latency & throughput for </span>trickle loading was very poor in our experiments. ATM I recommend periodically performing a bulk load. <span style="font-family: inherit;">(However, AWS claims it does do trickle loading well; let me know of your experiences!)</span></li>
</ul>
<li><b>I want to run custom functions on my data</b></li>
<ul>
<li>At the moment, you can't run arbitrary operations on your data in RedShift. If you want to scrub data, parse text, apply models etc. using non-SQL languages like Java, Python you can't use RedShift for that (hint: use EMR for that stage). </li>
</ul>
</ol>
<div>
<h3>
<u style="font-family: inherit;"><span style="font-size: large;">Common design mistakes</span></u></h3>
</div>
<ol>
<li><b>Writing directly from applications</b></li>
<ul>
<li><b><span style="font-weight: normal;">Directly writing from applications incurs high write latency. The most common way of loading data to RedShift is to periodically export your data to S3 and then use the COPY command. </span> </b></li>
</ul>
<li><b>Frequently modifying rows</b></li>
<ul>
<li><span style="font-family: inherit;">Addition of rows can be handled much better in RedShift. You should consider if representing your modifications as new rows (i.e. insert 'deleted' rows instead of actually deleting the original row) will work better.</span></li>
</ul>
<li><b>Choosing a bad DISTKEY</b> (we'll cover this in detail later)</li>
<ul>
<li>The most expensive queries in RedShift are those that do large re-distribution of data. This occurs when you join tables that use a different DISTKEYs.</li>
<li>Another common mistake is to choose a DISTKEY that causes a "data skew".</li>
</ul>
<li><b>Overly avoiding JOINs</b></li>
<ul>
<li>Joining large tables isn't something to be scared of if both tables use the join key as DISTKEY. If it makes things easier, don't be afraid of it.</li>
</ul>
<ul>
</ul>
</ol>
<div>
<h3>
<u style="font-family: inherit;"><span style="font-size: large;">Common confusions</span></u></h3>
</div>
<ol>
<li><b>Why do I have inconsistent data in my tables?! I had defined primary key/foreign key/unique constraints!</b></li>
<ul>
<li><b><span style="font-weight: normal;">RedShift uses them to optimise queries, but it does not enforce it. You need to enforce it yourself in the <a href="http://en.wikipedia.org/wiki/Extract,_transform,_load">ETL</a> process.</span></b></li>
</ul>
<li><b>OK, how do I create indexes?</b></li>
<ul>
<li>RedShift doesn't have the usual INDEXes you'll find in other RDBMS.</li>
<li>You have knobs to turn, though. DISTKEY and SORTKEY can be thought as indexes that you fiddle with. </li>
</ul>
</ol>
<h3>
<u><span style="font-size: large;">Stuff that you should do</span></u></h3>
<ol>
<li><b>Consider choosing DISTKEY</b></li>
<ul>
<li><b><span style="font-weight: normal;"><i>What is "DISTKEY" anyways?</i></span></b></li>
<ul>
<li><b><span style="font-weight: normal;">DISTKEY essentially decides which row goes to which node. For example, if you declare "<span style="font-family: Courier New, Courier, monospace;">user_id</span>" as DISTKEY, RedShift will do <span style="font-family: Courier New, Courier, monospace;">node_id = hash(user_id) % num_nodes</span> to choose the node to store that row. Well, it's not <i>THAT</i> simple, but you get the idea.</span></b></li>
</ul>
<li><i>Why does it matter?</i></li>
<ul>
<li>DISTKEY primarily matters when you do a join. Let's say a SQL statement <span style="font-family: Courier New, Courier, monospace;">SELECT * FROM User INNER JOIN Post ON (User.UserId = Post.UserId) WHERE Post.Type = 1 </span>is issued. If <span style="font-family: Courier New, Courier, monospace;">User</span> and <span style="font-family: Courier New, Courier, monospace;">Post</span> both used <span style="font-family: Courier New, Courier, monospace;">UserId</span> as DISTKEY, a RedShift node can just take the allocated shard, join them, filter them and send the (much smaller) contribution over the wire to be combined. However, if <span style="font-family: Courier New, Courier, monospace;">User</span> was distributed by <span style="font-family: Courier New, Courier, monospace;">UserId</span> and <span style="font-family: Courier New, Courier, monospace;">Post</span> was distributed by <span style="font-family: Courier New, Courier, monospace;">ArticleId</span>, <span style="font-family: Courier New, Courier, monospace;">Posts</span> that belong to <span style="font-family: Courier New, Courier, monospace;">Users</span> on a node will be on other nodes. Therefore the nodes have to ship the entire shard over the network to perform the join, which is expensive.</li>
</ul>
<li><b><span style="font-weight: normal;"><i>What should I do?</i></span></b></li>
<ul>
<li><b><span style="font-weight: normal;">If a table is large and you anticipate a join with another large table, then consider choosing the key that will be used for the join to be the DISTKEY. In other words, unless this is the case don't declare a DISTKEY (RedShift will distribute the rows evenly)</span></b></li>
</ul>
<li><i>What is "data skew"?</i></li>
<ul>
<li>Data skew is when data concentrates on small number of nodes due to a badly chosen DISTKEY. Imagine you have a huge user base which are predominantly located in US. If you use "<span style="font-family: Courier New, Courier, monospace;">country_code</span>" as DISTKEY, most of the data will end up on one node because most users will have the same <span style="font-family: Courier New, Courier, monospace;">counry_code</span> "US". This means that this one node will do most of the work while other nodes will remain idle, which is inefficient. Therefore, it's important to choose a DISTKEY that will result in an even(-ish) distribution among the nodes.</li>
</ul>
</ul>
<li><b>Consider "series table" to deal with writes to your tables</b></li>
<ul>
<li>A big part of RedShift's performance comes from the optimised data storage. When you newly load data into a table, its storage is neatly optimised. As you make modifications to the table, you start to disrupt this optimised state, a bit like "fragmenting your hard disk". That's why you have to perform ANALYZE/VACUUM time to time to correct this (a bit like doing a "defrag"). This can however become expensive at some point. This is where "series tables" helps. For example, you can create a "daily" table for each day and use UNION statement to provide a view that combines these tables. This way, you can perform ANALYZE/VACUUM only on the latest table as you load data & simply get rid of old tables to expire data rather than having to delete rows from a huge table and optimising it afterwards. This is also <a href="http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-time-series-tables.html">recommended in the RedShift documentation</a>.</li>
</ul>
<li><b>Use SORTKEY</b></li>
<ul>
<li>SORTKEY essentially defines how the data will be sorted in the storage.</li>
<li>This feature is useful to limit the amount of data that has to be scanned. For example, if I have a large table full of news paper articles over a century and want to find article published between 1980 - 1985 that mention "Tiger", it's useful to have articles sorted by <span style="font-family: Courier New, Courier, monospace;">published_date</span> on the storage, because that way I can limit the scanning on blocks that contain these dates.</li>
<li>They are also useful for joining if the key is also the DISTKEY because the query planner can skip a lot of work.</li>
<li>You *can* specify multiple SORTKEYs. When you specify <span style="font-family: Courier New, Courier, monospace;">SORTKEY(a, b)</span>, the data is effectively sorted as if with "<span style="font-family: Courier New, Courier, monospace;">ORDER BY (a, b)</span>. If cardinality of <span style="font-family: Courier New, Courier, monospace;">a</span> is high enough, filtering by <span style="font-family: Courier New, Courier, monospace;">a</span> is very effective, but having a second SORTKEY will make small sense, and vice versa. Therefore the utility of setting multiple SORTKEY is more difficult to judge. Start with a single SORTKEY and see how it goes.</li>
</ul>
<li><b>Consider replicating the table as a "JOIN INDEX" ala Teradata if you have more than one column you want to choose as DISTKEY</b></li>
<ul>
<li>You have more than one column you'd want to elect as DISTKEY but RedShift only lets you choose one. In such cases, you can simply create a replicated table that only differs in which key is declared as DISTKEY. This might seem like a poor idea, but it's essentially what Teradata (a similar technology to RedShift) does for its join index feature. You might be worried about maintaining the consistency between these tables, but because you are usually doing analytics & load data in bulk, it's usually not a problem.</li>
</ul>
</ol>
<h3>
<u><span style="font-size: large;">Miscellaneous Notes</span></u></h3>
<ol>
<li><b>Don't worry if your CPU utilisation is high</b></li>
<ul>
<li>Part of what makes these technologies powerful is the ability to exploit HW through efficient parallell processing, which means high CPU utilisation (spikes). Don't think you need to add nodes just because CPU utilisation sometimes hits 100%.</li>
<li>Don't focus on CPU and overlook other signs, like high network usage (which may indicate data re-distribution). </li>
</ul>
<li><b>Use WLM to counter resource hogging</b></li>
<ul>
<li><b><span style="font-weight: normal;">When queries are issued concurrently, resource hogging can become a problem. For example, if somebody issues 10 queries that take 1 hour each, another guy with a 5 min query can wait for a long time before he can get his query done. To prevent this kind of problem, consider using <a href="http://docs.aws.amazon.com/redshift/latest/dg/c_workload_mngmt_classification.html">WLM</a>.</span></b></li>
</ul>
</ol>
<br />
<br />
<br />
<b>Happy RedShift development! :)</b><br />
<span style="font-family: inherit;"><br /></span>
Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-50911674261989173582012-02-02T11:52:00.001+00:002012-08-18T14:25:19.192+01:00PACELCで理解するCAPの定理(2)第一回目は、CAPの定理をおさらいしました。今回は、いよいよ<a href="http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html" target="_blank">PACELC</a>について見ていきます。<br />
<br />
<br />
<br />
<i><strong>CAP定理の問題</strong></i><br />
<br />
Abadi氏は、CAPの定理には次のような問題があると言います。<br />
<br />
<blockquote>
CA型とCP型のシステムは、事実上区別できない。つまり、CAP定理では、あたかもCA, CP, APの計3種のシステムが存在するような印象を受けるが、実際にはCA/CP型とAP型の2種類しかない。</blockquote>
<br />
まずはこれについて考えてみましょう。CA型のシステムとは、ConsistentかつAvailableなシステムですが、Partitioningが起きたら、機能を失ってしまうシステムです。CP型のシステムとは、Consistentで、Partitioningが起きても機能を失わないが、その代わりAvailableではないシステムです。<br />
<br />
なんだか、確かに分かりにくいですね。よりCAP定理の定義に忠実に従って正確に書いてみましょう。<br />
<ol>
<li>CA型のシステムとは:<br />
<ul>
<li>Partitioningが起きない限り(=普段は)、ConsistentかつAvailableである</li>
<li>Partitioningが起きると、システムは機能を失う</li>
</ul>
<br />
</li>
<li>CP型のシステムとは:<br />
<ul>
<li>普段はConsistentである</li>
<li>Availableとは、「ノードがfailureしていないかぎり応答を返せること」なので、実は、普段(=Partitioningが起きていない時)はCP型のシステムもAvailableである</li>
<li>Partitioningが起きると、Availableではなくなるが、Consistentであり続ける</li>
</ul>
<br />
</li>
</ol>
まだ分かりにくいので、具体例で見ていきましょう。 <br />
<br />
2つのノードで同期的にレプリケーションを行っているリレーショナルDBを考えましょう。どのWriteも、両方のノードのディスクに書き終わらない限り完了しないという設定で組んでいるとします。もし2つのノード間で通信が途絶えてしまったら、両方のディスクに書けないのでシステムは機能を失ってしまいます。これが、CA型のシステムですね。 これではシステム全体の可用性が少なすぎるとしましょう(どちらかのノードが壊れるか、通信が途絶えるかするだけでシステムが停止するので)。そこで、「通信が途絶えたら、IPの若い(順番が)方が自分のディスクだけをつかってオペレーションを継続する」という約束をすることにしましょう。こうすれば、通信が途絶えてもIPの若いほうが生きてさえいればオペレーションを続けることができます。<br />
IPが古い方のノードは「failしていないのに応答できない(正確には『リクエストを実行できない』というエラー応答となるわけですが)」ことになり、「failしていないノードはリクエストに応答しなくてはならない」というAvailabilityの条件を満たさなくなります。<br />
もし、どうしてもAvailabilityを保持したかったとしたらどうでしょうか?その時は、レプリケーションを非同期にする必要があります。お互いのDBが、発生した変更をキューに貯めておいて、通信が復活したら相手に伝達します。 その間は、お互いDBの中身が違うので、Consistencyは守られません。<br />
つまり、<strong>事実上、CA型のシステムとCP型のシステムがあるわけではなく、Pが起きたときにCを選ぶか、Aを選ぶかという選択がある</strong>のです。<br />
ここまでが、「CA型とCP型のシステムは、事実上区別できない」とするAbadi氏の主張の説明です。Abadi氏はこの論理から、PACELCの"PAC"を提唱しています。「もしPが起きたら、AとCどちらを選びますか?」という意味です。 次に、残りの"ELC"について見てみましょう。先に説明しますと、ELCとは else Latency xor Consistencyです。PACから書くとこうなります。 <br />
<blockquote>
if P then Availability xor Consistency else Latency xor Consistency</blockquote>
日本語で書くとこうなりますね。 <br />
<blockquote>
もしネットワーク分断が起きたら、Availabilityを選びますか?それともConsistencyを選びますか? あと、ネットワーク分断が起きていない時は、Latencyを選びますか?それともConsistencyを選びますか?</blockquote>
Latencyという要素が急に入ってきましたが、これはなんでしょうか?これが、Abadi氏が主張するCAPの定理の2つ目の問題です: <br />
<blockquote>
CAPの定理は、LatencyとConsistencyのトレードオフを考慮していない。</blockquote>
PACだけに注目すると、じゃぁPが発生していないときはAvailabilityとConsistencyどっちも取れてハッピーハッピーになるはずなのですが、世のNoSQLデータベースは普段からConsistencyを犠牲にしています。<br />
どうしてそんなことをするかというと、Latency(≒レスポンスタイム)を短くする為です。例えば、負荷分散のために10台のリレーショナルDBをレプリケーションして使いたいとしましょう(みんな同じ中身)。Consistencyを達成するためには、Create/Update/Deleteを行う時は10台全てにリクエストを発行して、完了するまで待たなければいけませんが、そんなことをしたらLatencyはかなり悪くなってしまいます。2台選んでリクエストを完了し、後からこの2台が他のノードにリクエストを非同期で発行するのはどうでしょうか?これなら運悪く1台が死んでももう1台がいますから1台にだけ発行するのに比べると信頼性がアップしますし、10ノードに発行するのに比べれば、Latencyが改善します。Cassandraなどは、実際にこれに似たようなことをやっています。<br />
話が少し横にずれてしまいましたが、<strong>要するに、LatencyとConsistencyはトレードオフの関係にあり、システムはどちらかを選ぶ必要がある</strong>ということなのです(実際にはイチゼロじゃなくて、どちらをより優先するか連続的なスペクトルから選ぶ感じですが)。<br />
では、いくつか実例を見てまとめとしましょう。PCECシステム(if Partition then Consistency, else Consistency)はどんなシステムでしょうか?何回か例に出てきた、2つのノードが同期的にレプリケーションを行っているリレーショナルDBなどが考えられます。このシステムは、ネットワーク分断が発生すると、生きていてもリクエストを処理できないノードができてしまいます(if P then Availability喪失)。普段も、2ノードでWriteが完了しないとリクエストが完了しないので、Latencyも悪いです(elseの時、 Latency無し)。その代わり、普段はConsistencyが守られていますし( else Consistency)、Pが起きてもConsistencyを守り続けます。つまり、if P then Consistency (and not Availability), else Consistency (and not Latency)、よってPCECです。<br />
PAELシステムはどうでしょうか?これも前出てきたDNSが当てはまります。普段はそのDNSサーバのテーブルがアップデートされてさえいれば、他のDNSサーバがアップデートされているかなど考えずに応答を返すので、Latencyはいいです(else Latency)。DNSサーバ間で通信が途絶えて、同期が行えなくなっても各自応答は返し続けるので、if P then Availabilityとなっています。その代わり、要求を処理するDNSサーバによって結果が変わることがありえるので、Consistencyは失われています。<br />
他の組み合わせはどうでしょうか?Abadi氏は、PCELなシステムの例として<a href="http://www.slideshare.net/ydn/yahoo-scalable-storage-and-delivery-services" target="_blank">Yahoo!のPNUTS</a>を挙げています。PNUTSは、普段Latencyを得るため伝統的なリレーショナルDBなどに比べて弱いConsistencyを使っていますが、Pが発生すると、Availabilityを犠牲にしてでも、そのレベルのConsistencyを守り続けます。(Consistencyといっても様々なレベルがあるので、ここは分かりにくいですね。。)<br />
<br />
<br />
PAECシステムだと、普段はConsistencyを維持していますが、Pが起きるとAvailabilityを守るためにConsistencyを犠牲にし始めます。たまにConsistencyが破られる可能性があるというのは、Consistencyがないのに近いので、PAECなシステムが本当にあったとしたら、非常に使いにくそうですが、後からある程度のコストでコンフリクトを解消できるような局面では、あり得ない選択ではないかもしれません。<br />
<br />
<br />
以上、PACELCで理解するCAPの定理でした!
<br />
<br />Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-51607076852699148682012-02-02T11:52:00.000+00:002012-08-18T14:17:04.332+01:00PACELCで理解するCAPの定理(1)<a href="http://en.wikipedia.org/wiki/CAP_theorem" target="_blank">CAPの定理</a>が何故最近話題になっているかについての説明などは他サイトに任せることにして、このエントリではCAP定理の技術的な解説、および、CAP定理をより分かりやすく、かつ(簡単に言えば)より正確にした「PACELC定理」の解説を行います。<br />
<br />
PACELCの定理とは、<a href="http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html" target="_blank">エール大学のAbadi氏が提唱している</a>もので、CAPの定理のいわば発展形です。CAPの定理の「難しい版」と思われていることがあるようですが、そんな事はありません。むしろ、多くの学生がCAPの定理で苦労するのを見たAbadi氏が、学生に分かりやすく説明するために考えたものなので、CAPの定理をより分かりやすくしたものと言えます。ただ、それだけでなく、CAPの定理には入っていなかったLatency(≒レスポンス時間)の概念も合わせて捉えることで、より正確に分散データベースの特性を考えられるようになっています。<br />
<br />
ではまず、第一回目はCAPの定理をおさらいしましょう。 <br />
<br />
<blockquote>
<br />
<strong><em>CAPの定理</em></strong>:次の3つの特性を、全て同時に示す分散システムを実現することはできない。 <br />
<br />
<ol>
<li>Consistency(一貫性, C)</li>
<li>Availability(可用性, A)</li>
<li>Partition-tolerance(分断耐性, P)</li>
</ol>
<br />
すなわち、どのような方法をもってしても、ある時点でシステムが示すことができる特性は、C, A, Pのうち任意の2つまでである。 <br />
<br /></blockquote>
<br />
<i><strong>Consistencyとは</strong></i><br />
<br />
ここでは広義に使われており、<a href="http://en.wikipedia.org/wiki/ACID" target="_blank">ACID</a>のCと同義ではありません。説明をわかりやすくするため、ここでは単純な分散Hash mapを具体例として見ていきましょう。<br />
<br />
最も単純なConsistencyには、AtomicityとVisibilityがあります。Atomicityのうち、最も単純なのは、「全てのReadは、Write処理が完了する前の状態か、または完了した後の状態のいずれかしか見ることがない」という性質です。プログラミングで例えるなら、map.get(key)を呼んだら、値が返ってくるか返ってこないかの2択しかしかなく、「値が半分だけ」返ってくることが絶対にないということです。「半分だけ」値が返ってくるってどういうことよと言われてしまいそうですが、この例では例えば正しくメモリ上に書き込みが終わっていない値が返ってくることが想定できます。イメージとしては、本当は10100010が返されなければいけないのに、まだ書き込みが終わっていないために00000010が返ってしまう感じです。この単純なAtomicityが実現されているということは、これが起こることがないという保証があるということです。<span style="font-size: x-small;">※一般的にアトミックと言うとリレーショナルDBでいうAtomicityを考えると思いますが、今回の説明ではこの最低限のAtomicityで十分なので、単純化しています。</span><br />
<br />
<br />
<br />
Visibilityとは、全てのユーザ(例えばスレッド)が同じ状態を「見る」ことができることです。もう少し具体的に言うと、あるWriteが完了したなら、その後に発行されたReadは全て「最悪でも」このWriteの結果を返すという約束です。当たり前に聞こえますが、後述するように、パフォーマンスなどを考えて、「Writeが起こった直後は書いた人にしか見えないが、じわじわと他の人にも見えていくようにする」ことを許す場合があります。これがよく分散データベース("NoSQL")で言われる"<a href="http://en.wikipedia.org/wiki/Eventual_consistency" target="_blank">Eventual Consistency</a>"の一種です。すぐみんなが同じ状態を見れはしないけど、いずれは見ることができるようになる、という意味で"Eventual"なのですね。意図せずにこれを許してしまうのがVisibilityバグで、マルチスレッドプログラミングでよく起こるバグの一つです。<br />
<br />
ところで「最悪でも」ってなんやねんという話なのですが、これは、Write1→Read1→Write2の順にオペレーションが発行されたときに、Read1がWrite2の結果を見るのはOKということです。別にWrite2の結果が見えたほうがいいということではないので「最悪でも」という言い方は誤解を招くかもしれませんが、「少なくともWrite1までのアップデートを逃すことだけはNGにしましょうね」ということです。「Read1が、Write2ではなく、必ずWrite1の結果を受け取らなければいけない」というのはもう一つさらにきついレベルのConsistencyです。ここでは最低限のConsistencyについて考えたいので、よりゆるい、Write2の結果が返ってしまうことを許すvisibilityを考えます。<br />
<br />
<br />
<br />
「Writeの結果がすぐに全員に見える」のと、「ちょっと後に全員に見えるようになる」のと何か本質的な違いはあるのでしょうか?これについて考えるために、「同じ値(value)を許さない」Hash mapベースのアプリを考えてみましょう。どのスレッドも、一旦挿入したい(kx,vx)を挿入してしまってから(map.put(kx, vx))、map.values (v0 ... vx ... vn)を1つ1つイテレートしてvxと比べ、vx以外にvxと同じvyを発見したら、重複の疑いがあるケースとしてマークし、後で調査して削除するためにどこか(delete_list)に書き残します(次のinsert関数参照)。<br />
<br />
これをたくさんの(k,v)ペアに対して行い、最終的にユニーク、つまりどの値(value)も1回しか入っていないマップを得ることがアプリの目的です。<br />
<br />
<pre class="brush: python">
def insert(kx, vx):
map.put(kx, vx)
for ky, vy in map.values():
if vx == vy and ky != kx:
delete_list.add((kx,ky))
</pre>
<br />
<br />
さて、今まさに2つのスレッド(t1, t2)がそれぞれ(k1, v1), (k2, v1)を登録しようとしているとしましょう。同じv1なので、少なくとも1回重複疑いのアラートがあげられなければいけません(2回以上あがってしまうのはOK)。<br />
<br />
このHash mapは最低限のAtomicityしか備えていない設定ですので、put, removeはそれぞれアトミックですが、insert自体はアトミックではありません(これは、insert処理の途中の状態を、他のスレッドに見られたり、書き換えられたりする可能性がある、ということ)。なので、考えられる処理の順番としては、次の3つが考えられます(t1とt2を入れ替えたものは同じと考える。t1、t2それぞれの中ではput→readの順番は保たれる)。<br />
<br />
<ol>
<li><ol>
<li>t1のput(k1,v1)</li>
<li>t1のread(他のv1無し)</li>
<li>t2のput(k2,v1)</li>
<li><span style="color: blue;">t2のread(他のv1有り)</span></li>
</ol>
</li>
<li><ol>
<li>t1のput(k1,v1)</li>
<li>t2のput(k2,v1)</li>
<li><span style="color: blue;">t1のread(他のv1有り)</span></li>
<li><span style="color: blue;">t2のread(他のv1有り)</span></li>
</ol>
</li>
<li><ol>
<li>t1のput(k1,v1)</li>
<li>t2のput(k2,v1)</li>
<li><span style="color: blue;">t2のread(他のv1有り)</span></li>
<li><span style="color: blue;">t1のread(他のv1有り)</span></li>
</ol>
</li>
</ol>
<br />
これが、「すぐに結果が全員に見える」という保証がなかったらどうなるでしょうか?タイミングによってこういうことがあり得てしまいます。<br />
<br />
<ol>
<li><ol>
<li>t1のput(k1,v1)</li>
<li>t1のread(他のv1無し)</li>
<li>t2のput(k2,v1)</li>
<li>t2のread(<span style="color: red;">他のv1無し(まだ見えなかった)</span>)</li>
</ol>
</li>
<li><ol>
<li>t1のput(k1,v1)</li>
<li>t2のput(k2,v1)</li>
<li>t1のread(<span style="color: red;">他のv1無し(まだ見えなかった)</span>)</li>
<li>t2のread(<span style="color: red;">他のv1無し(まだ見えなかった)</span>)</li>
</ol>
</li>
<li><ol>
<li>t1のput(k1,v1)</li>
<li>t2のput(k2,v1)</li>
<li>t2のread(<span style="color: red;">他のv1無し(まだ見えなかった)</span>)</li>
<li>t1のread(<span style="color: red;">他のv1無し(まだ見えなかった)</span>)</li>
</ol>
</li>
</ol>
<br />
<small>正確には、先述のvisibilityの仮定から、ReadがWriteの結果を「先取り」してしまうことはあり得る。「アラートがあがらない保証がある」ではなく、あくまで「アラートが必ずあがる保証がない」ということに注意</small><br />
<br />
<br />
これで、visibilityがあるのとないのとでは本質な違いがあることが分かっていただけたかと思います。この違いは性能面でも顕著に現れます。visibilityを担保しなくてはいけない処理系は、visibilityを担保しなくても良い処理系に比べて性能が低くなります。CAPの定理を説明する上では、とりあえずこのようなVisibility(と最低限のatomicity)を備えたものを「Cのある分散DB」、備えていないものを「Cのない分散DB」と考えておけば良いです。<br />
<br />
<i><strong>Availabilityとは</strong></i><br />
<br />
Availabilityとは、「failしていないノードに発行した(発行できた)リクエストは、必ずレスポンスを返さなければならない」ということです。リクエストが発行できたなら、必ず結果が返ってこなければいけないということですね。<br />
<br />
<i><strong>Partition Toleranceとは</strong></i><br />
<br />
Partition Toleranceとは、分散システムにおいて、ノード間で通信ができなくなってもAvailabilityまたはConsistency(のどちらか1個)が保持されることです。「通信分断耐性」とでも訳せるでしょうか。分散システムなので当然複数のノード(サーバ)があるわけですが、これらノード間で通信ができなくなっても、システムが機能を維持できる特性のことです。機能といってもAvailabilityを保証するシステムもあれば、Consistencyを保証するシステムもあるので、「Pを備える」という言葉は、システムによって違う意味を持ちます。Availabilityを保証するシステムでは、ネットワークの分断が起きてもAvailabilityが保証され続けることを意味し、Consistencyを保証するシステムでは、ネットワークの分断が起きてもConsistencyが保証され続けることを意味します。<br />
<br />
<span style="font-size: x-small;">※正確な定義、CAPの定理の証明については<a href="http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf" target="_blank">Lynch & Gilbertの論文</a>を参照</span><br />
<br />
<strong><em>具体例</em></strong><br />
<br />
ちょっと分かりにくくなってきたかもしれないので、具体例で説明しましょう。例えば、DNSは典型的なAP型システムです。DNSでは、DNSサーバ1に問い合わせると「見つからない」というレスポンスが返ってくるが、DNSサーバ2に問い合わせるとちゃんとIPが返ってくる、ということが日頃起きています。そのうちどちらのサーバも最新に更新されていくわけですが、ラグがあったりして、少なくともある時点に着目したときに、問い合わせるサーバによって結果が異なることがあり得る、つまり、「全員が同じ状態を見るという保証がない」ため、Consistencyが破られていることになります。<br />
<br />
さて、ある日ルータの故障か何かでDNSサーバ1と2の間の通信が不能になったとします(Partitioningの発生)。DNSでいうPartition Toleranceとは、この状況でAvailabilityを保証し続けること、すなわち、DNSサーバ1へのリクエストも、DNSサーバ2へのリクエストも、必ずレスポンスが返ることを保証することです。DNSサーバ1,2の間で通信ができなくなったところで、更新が遅れるだけで、引き続きどちらのサーバに対してもRead/Writeは実行できるため、Availabilityは達成されていることになります。もし、通信ができないからと言って問い合わせやレコードの追加を拒否する状態になればPartition Toleranceが満たされていないことになります。<br />
<br />
<br />
逆にCP型のシステムにはどんなものがあるでしょうか?最も分かりやすいのは、2つのノードで同期的にレプリケーションを行っているリレーショナルDBです。どのWriteも、両方のノードのディスクに書き終わらない限り完了しないという設定で組んでいるとしましょう。もし2つのノード間で通信が途絶えてしまったら、両方のディスクに書けないのでシステムは機能を失ってしまいます。それでは不便なので、「通信が途絶えたら、IPの若い(順番が)方が自分のディスクだけをつかってオペレーションを継続する」という約束をすれば、通信が途絶えてもIPの若いほうが生きてさえいればオペレーションを続けることができます。しかし、IPが古い方のノードは「failしていないのに応答できない(正確には『リクエストを実行できない』というエラー応答となるわけですが)」ことになり、「failしていないノードはリクエストに応答しなくてはならない」というAvailabilityの条件を満たさなくなります。もし両方ともオペレーションを続けたら、Consistencyを保てなくなる点に注意してください。例えば、ノード1にWriteした結果が、ノード2からは見えないわけですので、こういう約束をしていなければシステムを止めなければいけなくなります。<br />
<br />
ノードが1つだけオペレーションを続けたときは、当然従来通りConsistencyが保たれます。<br />
<br />
CAPの定理に従えば、残るはAC型のシステムですが、これがCAP定理を理解しにくくしている原因の1つであるとAbadi氏は主張します。AC型のシステムとは、Partitioningが起きない限りはAvailableかつConsistentなシステムですが、CP型のシステムだって、Partitioningが起きない限りはAvailableなわけです。逆に、AC型のシステムだって、Partitioningが起きてしまったら結局Availabilityを失います。つまり、AC型のシステムと、CP型のシステムは、事実上同一なのです。CAPの定理では「3つのシステム」が作れると説明しますので、AC型のシステムとCP型のシステムは別物と考える人が多く、混乱を招いていると氏は主張します。<br />
<br />
<br />
と、とりあえず今日はここまでとして、次回はこれを踏まえてAbadi氏が提唱するPACELCについて解説していきたいと思います。Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-61971043016182425552012-02-02T09:52:00.051+00:002012-08-18T14:25:46.493+01:00Erlang、求人数の伸びしっかり近年脚光を浴びているとはいえ、まだまだ超マイナー言語状態のErlangですが、求人の伸び率では、python, PHPなどの最近伸びが大きいWeb系言語を抑えて高い伸びを示しています(以下グラフ)。Web系言語の中でもさらに新興のruby, groovyと並ぶ伸びです<br />
<div>
<br />
絶対数で見ると圧倒的に少ないので、その影響も多いのかもしれませんが、注目が集まっているのは間違いなさそうです。<br />
<div>
<br />
<br /></div>
フロントエンドでは、まだまだJavaが幅を効かせているものの、Python, Ruby, Groovyなどの動的スクリプト言語が好まれるようになってきています。そうなると、コンパイル言語であるJavaの牙城は、パフォーマンスが要求されるバックエンドとなりますが、Shared Mutable DataをコンカレンシモデルとするJavaでは、マルチスレッドプログラミングの難易度が高く、手がけることのできるプログラマは非常に少ないです。複数のサーバにまたがってアプリを置く場合にも、普通はそれを意識してプログラミングする必要が出てきます。</div>
<div>
<br /></div>
そこへ行くと、Erlangはコンカレンシのための言語、分散システムのための言語ですから、非常に魅力が出てきますが、関数型言語であるため、Java、C++などの手続き型言語のキャリアがほとんどである産業プログラマにはとっつきにくい言語といえます。複雑な計算や、文字処理などにも向いていない部分があり、様々な言語とミックスして使うのが前提という設計とはいえ、JavaやPythonに比較したときの既存ライブラリの少なさなんかもネックになってしまいそうです。<br />
<div>
<br /></div>
並行プログラミング・分散システムでの強みがErlangを押し上げるか?それともニッチ言語として特殊な層でのみ普及するか?あるいははたまたとっつきにくさが障害となって、マイナー言語のまま終わってしまうのか?どうなるかこれから注目です。<br />
<br />Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-58966771246395081132012-02-02T09:52:00.047+00:002012-02-02T09:52:57.076+00:00Erlang開発環境の構築(Erlide) 2011環境:Windows XP<br /><br/><strong>1.</strong> Erlangをインストール(Erlang/OTP 5.7.4 (R13B03)) <a href="http://www.erlang.org/download.html" target="_blank">link</a><br /><strong>EDIT:</strong>R13B03のウィンドウズ版デバッガにはバグがあるようで、VIstaで起動すると落ちてしまいます。なのでR14B01にアップデートしたところ、正常に使えています。<br /><br/><strong>2.</strong> erl5.7.4\binをPATHに追加。<br /><br/><strong>3.</strong>C++用 eclipseをダウンロード (eclipse-cpp-helios-SR1-win32) <a href="http://www.eclipse.org/downloads/" target="_blank">link</a><br /><strong>EDIT:</strong>SR1じゃなくてSR2でも正常に動くようです。<br /><br/><strong>4.1.1</strong> Help -> Eclipse Marketplace -> "erlide"を検索窓に入力して、"Go"<br /><strong>4.1.2</strong> 2011年2月現在、Erlide 0.9.0.201010010061109がインストールされ、正常に動きます。<br /><strong>4.2</strong> 指示に従い、インストール。インストール後再起動。<br /><strong>4.3.1</strong> Eclipse preferencesを開き、Installed Runtimes entryを選択。僕の場合は正常に自動検出できていましたが、できていない場合は多分手動でErlangランタイムを追加する必要があります。<br /><strong>4.3.2</strong> 手動でランタイムを追加した場合は、eclipseを再起動。<br /><br/><strong>5</strong> プロジェクトViewで右クリックして、"New Erlang Project”を選択(プロジェクト名は、helloなど)。<br /><br/><strong>6</strong> 作成された"src"ディレクトリにhello.erlを次の内容で作成<br /><br/><script type="syntaxhighlighter" class="brush:erlang" title="hello.erl"><br /><![CDATA[<br />-module(hello).<br />-compile(export_all).<br />%% Hello concurrent world!<br />hello() -><br />io:write("Hello Concurrent World\n").<br /><br/>]]><br /></script><br /><br/><strong>7.1</strong> Run configurationでErlang applicationを選択し、新規起動コンフィグレーションを作成(左上の「白紙」みたいな形をしているアイコン)<br /><strong>7.1</strong> アプリの名前を入力。(Hello-Concurrent-Worldなど)<br /><strong>7.2</strong> Erlangタブで、Requiredプロジェクトとしてhelloにチェック。<br /><strong>7.3</strong> ランタイムタブで、nodeネームロングを選択して、ノード名として"erlide"と入力。<br /><strong>7.4</strong> 適用をクリックして、実行。<br /><br/><strong>8</strong> コンソールビューが表示され、プロンプトが表示されるので、試しにhello:hello().を実行。<br /><br/>これ以降は、ソースをいじって保存(ctrl+s)すれば、自動的にコンパイル・反映され、コンソールから新しいコードをすぐに呼び出せます(改めてコンパイルしたり、コンソールを立ち上げたりすることは不要)。<br /><br/><br/><strong>UPDATE:</strong><br />Erlide付属のErlangコンソールはやや使いにくいうえに、ソースを変更しても反映されないことがたまにあるみたいなので、今はソースディレクトリでコマンドプロンプトからwerl(Windows版Erlang付属シェル)を別ウィンドウで動かして使っています。そんなにきれいじゃないしいちいちalt+tabでの切り替えが必要になってしまいますですが、tabキーでオートコンプリートできたり、コピーペーストが可能などerlide付属シェルよりも使いやすい感じです(コピペ不可と言うのは厳しいですよね)。<br /><br/><br/><a href="http://stackoverflow.com/questions/4272990/erlide-which-eclipse-which-packages/4374571#4374571" target="_blank">reference</a><br /><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-26967288132814830702012-02-02T09:52:00.045+00:002012-02-02T09:52:57.043+00:00科学的に「流行」を予測し、予防する方法(TED)僕は<a href="http://www.ted.com/" target="_blank">TED</a>が大好きで、podcastをipodに入れていつも移動中に見ているのですが、最近聞いた中で特にへぇ~とおもったのがあったので、紹介します。<br /><br /><strong>講演はこちら-><a href="http://www.ted.com/talks/nicholas_christakis_how_social_networks_predict_epidemics.html" target="_blank">Nicholas Christakis: How social networks predict epidemics</a><br /><br /></strong><br /><br />病気や流行、考え方などは、人から人へとつたって集団内に分散していきます。最近では、エジプトでのデモがありましたね。集団内のそれぞれの人は、思い思いに不満を持っていたはずですが、「デモをやろう」、「立ち上がろう」という「考え」が爆発的に広がることがなければ、人々が協調してデモに向かう現象はおこらなかったはずです。エジプトでは、FacebookやTwitterなどのいわゆるsocial netoworkサービスが、重要な媒体となったといわれていますね。<br /><br /><br /><br />演者のクリスタキス氏はこのような、集団内を、人を介してモノが伝わる現象を研究しています。特に講演では、ある大学のキャンパスでの風邪ウィルス感染の「流行」を従来よりも早く検出した実証実験を紹介しています。ここでは、FacebookやTwitterと違って、人と人とのつながりは物理的ですし、伝わるのは「病原菌」なのですが、対象とする事象が「人を介して伝わっていくもの」であるかぎり、応用が可能なのだそうです。<br /><br /><br /><br />氏の研究のミソは、「人と人のネットワークにおける「要所」をみつけて、そこでアンテナを立てる」ことです。お互いに情報をやり取りするノード(節、この場合は個人)がつながったネットワークでは、「ネットワークの端」よりも「ネットワークの中心」にいた方が情報が早くもたらされます。<br /><br /><br /><br />「ネットワークの中心」にいるノードは、要するに「友達がたくさんいる人と友達であるノード」です。どれだけ友達が多くても、その友達がすべて友達の少ない人であれば、そのノードは「端」になります。逆に、友達が普通の数でも、その友達の人たちが、たくさん友達のいる人ばかりであれば、そのノードは「中心」に位置します。<br /><br /><br /><br />これは、数学的に定量化することができ、こうして求めた「中心に近い」ノードを重点的にモニターしておけば、集団で何か情報なり行動が流行し始めとき、いち早くそれを知ることができます。氏は、「中心に近い」学生を幾人か選んで、彼らに定期的に健康状態を電話で報告してもらうなどしてモニタリングし、風邪の流行をいち早く知ることができることを確認しました。<br /><br /><br /><br /><br /><br />なんとこの方法は、検出だけでなく、流行の予防にも応用できるそうです。例えば、集団全体の30%にあたる「中心に近い」ノードに予防接種を実施すると、ランダムに集団全体の96%に予防接種を実施するのと同等の予防効果が得られるらしいことがわかりました。<br /><br /><br /><br />この方法の難しいところは、「中心に近い」ノードを見つけるには、ネットワークの「地図作り」が必要となり、これが非常に大変で難しいところなのですが、クリスタキス氏はこの問題を克服する面白い方法を見つけました。<br /><br /><br /><br />ランダムに集団内のノードを選び、それぞれのノードに友達を紹介してもらうと、その「友達」集団は、元のランダムに選んだ集団よりも、ネットワークの中心に近い集団となります。これは、ネットワークの中心に近いノードはたくさんのノードからコネクションがきているので、ランダムに紹介してもらうと、中心に近い人の方が名前が挙がりやすいからです。<br /><br /><br /><br />この方法を使うと、手間のかかるネットワークの「地図作り」をしなくても、流行を効果的に検出したり、予防したり、逆に流行を引き起こすことができるようになります。<br /><br /><br /><br />クリスタキス氏はマラリア流行国での「蚊帳」の流行を作り出すためなどに使えると話していましたが、政治やビジネスの世界ですごく注目されそうな研究ですね。少し恐ろしい気もしますが、かしこく利用すれば本当に応用範囲の広い、強力な技術だと思います。<br /><br /><br /><br /><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-17596806302505643582012-02-02T09:52:00.043+00:002012-02-02T09:52:56.997+00:00ErlideでEunitを使った開発をやってみる<a href="http://concurrency.seesaa.net/article/186723201.html" target="_blank">前の記事</a>で作成した開発環境で、テスト駆動開発を試しにやってみます。<br /><br/>といってもすごく単純です。とりあえず、Erlangをインストールしたディレクトリ下\erl5.7.4\lib\eunit-2.1.4\examplesにあるfib.erl をHelloWorldプロジェクトのsrcディレクトリにコピーして、試しにfib:test().を実行してみると、テストが実行されパスします。<br /><br/>自分で書いたソースでも試してみます:<br /><script type="syntaxhighlighter" class="brush:erlang" title="db.erl"><br /><![CDATA[<br />%%<br />%% Exercise from Cesarini, F. and Thompson, S. (2009)<br />%% "Erlang Programming" Exercise 3-4 (page 83)<br />%%<br />-module(db).<br />-export([new/0,destroy/0,write/3,delete/3,read/2,match/2]).<br /><br/>-include_lib("eunit/include/eunit.hrl").<br /><br/><br/>%%<br />%% API Functions<br />%%<br />new() -><br />[].<br /><br/>destroy() -><br />ok.<br /><br/>write(Key,Element,Db) -><br />case read(Key, Db) of<br />{error,_} -> [{Key,Element}|Db];<br />{ok,V} -> {error,{'already-present',V}}<br />end.<br /><br/>delete(Key,Element,Db) -><br />copy_on_delete(Key,Element,Db,[]).<br /><br/>read(_,[])-><br />{error,instance};<br />read(Key,[{Key,V}|_])-><br />{ok,V};<br />read(Key,[{_,_}|Tail])-><br />read(Key,Tail).<br /><br/>match(_,[]) -><br />[];<br />match(Value,[{Key,Value}|Tail]) -><br />[Key|match(Value,Tail)].<br /><br/>%%<br />%% Local Functions<br />%%<br />copy_on_delete(_,_,[],Acc) -><br />Acc;<br />copy_on_delete(Key,Element,[{Key,Element}|Tail],Acc) -><br />copy_on_delete(Key,Element,Tail,Acc);<br />copy_on_delete(_,_,[{K,V}],Acc) -><br />[{K,V}|Acc];<br />copy_on_delete(Key,Element,[{K,V}|Tail],Acc)-><br />copy_on_delete(Key,Element,Tail,[{K,V}|Acc]).<br /><br/>%%<br />%% Unit tests<br />%%<br />db_test() -><br />Db1 = db:write(test,test,[]),<br />?assertEqual([{test,test}],Db1),<br /><br/>Db2 = db:write(testo,test,Db1),<br />?assertEqual([{testo,test},{test,test}],Db2).<br /><br/>]]><br /></script><br /><br />ちょっと単体テストが中途半端ですが(^^;) db:test().を実行するとテストが流れます。とりあえずこれでテスト駆動でErlangを練習していく環境が整いました。<br /><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-59516010595918808382012-02-02T09:52:00.039+00:002012-02-02T09:52:56.905+00:00Stackoverflowが教えて!gooよりも何倍もクールな理由集まるエンジニアのレベルに絶対的な差がある、とりあえずstackoverflowの方がインターフェースがかっこいいなど目に付く明らかな差は当然のことながら、普段はあまり見えないところにも大きな差があります。<br /><br /><br /><br /><span style="font-size:x-small;">※IANAL(I am not a lawyer/僕は弁護士ではないので、間違っていたらすみません)<br /></span><br>とりあえず、著作権。Stackoverflowのコンテンツは<a href="http://creativecommons.org/licenses/by-sa/2.5/deed.ja" target="_blank">Creative Commons BY-SA</a>です。<a href="http://meta.stackoverflow.com/questions/13976/who-owns-the-copyright-to-sofu-content/14769#14769" target="_blank">サイト創始者の一人の考え方</a>としては、著作権は引き続きユーザにあるが、それをstackoverflowに「CC BY-SAとしてライセンスしている」ということらしいです(その割には、Stackoverflowのコンテンツはstackoverflow由来であることを表示することを求めているので、著作権がユーザだけに帰属するかどうかは曖昧ですが)。<br /><br /><br /><br />CC BY-SAは、オリジナルの著作権者を表示して、著作物をCC BY-SAでライセンスする限りは、商用利用も改変も構わないというライセンスです(商用利用の場合、売ってもいいけど、売った著作物を誰かにCC BY-SAで再配布(もしくは再販売!)されても文句は言えないということ)。<br /><br /><br /><br />まぁ非常にフェアなライセンスと言えるのではないかと思います。そのおかげでstackoverflowのコンテンツはwebのあちらこちらに転載されており、中にはサイトを丸ごとコピーしているようなサイトもありますが、オープンソースなどへの意識が高いプログラマコミュニティにとっては、こういうライセンスのほうが、愛着というか、コミュニティへの帰属意識が出ますよね。非常にかしこい選択だったのではないかと思います。<br /><br /><br /><br /><br /><br />一方でこちらは<a href="http://blog.goo.ne.jp/oshietegoo/c/4b0e32855788a6793ae45d0eeb59f1bc" target="_blank">教えて! gooの著作権規定</a>:<br />要約すると、「著作権はgoo側に帰属し、よってgoo側が例えばその内容を使って本を創って設けてもユーザに支払いなどは必要ないばかりか、名前の表示(attribution)なども一切必要ない」という内容です。<br /><br /><br /><br /><blockquote><br />��.投稿テキストの著作権等の帰属については以下の各号に定めるとおりとします。<br />��1)日本国著作権法第18条から第20条までにおいて定義される権利については、会員は、自らまたは第三者をして、当社、オウケイウェイヴ及び当社またはオウケイウェイヴの指定する第三者に対して行使せず、またはさせないものとします。<br />��2)日本国著作権法21条から第28条までにおいて定義される権利については、会員または第三者から譲渡され当社及びオウケイウェイヴに帰属します。<br />��3)第1号および第2号の対価として、当社及びオウケイウェイヴは、会員に対し、何らの支払も要しないものとします。<br /></blockquote><br /><br /><br />テキスト以外のマルチメディアコンテンツに関する規定は別にあり、こちらは基本的にはgoo側が欲しい権利をもらい、何か問題が発生したらユーザ側の責任となります(多分この点を考慮して、著作権はテキストと違ってユーザに帰属し、gooに無償ライセンスを付与する形にされています)。<br /><br /><br /><br />これじゃぁあんまり頑張ろうって気にならないですよね。まぁ誰もこんなもの読まないのでいいのかもしれませんが。こういうところ、未来のcollaborationの形に乗り遅れてるんじゃないのって思ってしまいます。<br /><br /><br /><br />ところで、seesaa blogはどうなっているかというと、こちらが<a href="http://kiyaku.seesaa.net/category/547790-1.html" target="_blank">規約</a>および<a href="http://info.seesaa.net/article/66823.html" target="_blank">規約付属の説明</a>です。<br /><br /><br /><br />要約すると、規約によれば著作権はユーザに帰属し、第三者に対する著作権の行使はなんら制限しないが、seesaaにはどう使ってもいい権利を付与してもらうという形態のようです。その理由については規約付属の説明に少しのっています。gooとは違って、seesaaが他の第三者に利用権を付与するようなことはできないみたいですね。<br /><br /><br /><br />この説明にはさらに、<blockquote>弊社がユーザー様の著作物を弊社のサービス以外の目的で利用する場合、ユーザー様の許諾を頂く必要があります。</blockquote>とありますが、「弊社のサービス」という言い方はかなりくくりが大きいので、本などの出版がこれに含まれるのかどうかはよくわかりませんね(本ってサービスなのかなぁ?)。<br /><br /><br /><br />弊ブログのコンテンツは、テキストは<a href="http://creativecommons.org/licenses/by-nc-sa/3.0/deed.ja" target="_blank">CC BY-NC-SA</a>、ソースコードは<a href="http://www.apache.org/licenses/LICENSE-2.0" target="_blank">Apache 2.0ライセンス</a>で公開しています(Apache 2.0は商用可能です)。弊ブログの場合、第三者がもし弊ブログのテキストコンテンツをつかって本を創って売ったら文句が言えますが、seesaaにそれをされた場合は文句は言えないかもしれない、ということのようです。<br /><br /><br /><br />ちなみに実はブログサービスには商用利用可のものと不可のものがあり、gooブログは商用不可、seesaaはOKです。ここもseesaaを選んだ理由の一つですね。gooはやっぱりNTTなので(?)色々なリスクを恐れて消極的というか、保守的な規約にしているのだと思うのですが、最近でた本、<a href="http://www.amazon.co.jp/Free-Smartest-Businesses-Something-Nothing/dp/190521149X/ref=sr_1_2?ie=UTF8&s=english-books&qid=1298341470&sr=1-2" target="_blank">Free</a>にも書いてあったように、これからは企業がcommunityとうまくcollaborationしていくことが一層重要になってくるように思います。<span style="color:#320000;">(gooの名誉のために書いておくと、商用利用不可なのはなにもgooだけじゃないですし、gooもblogについては、著作権はユーザに帰属するとしています)</span><br /><br /><br /><br />ユーザとしても、頑張ってユーザ・コミュニティの利益・権利を守ろうとしてくれている企業を応援したいですね。<br /><br /><br /><br /><br /><br/><br/><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-47781963639900764012012-02-02T09:52:00.037+00:002012-02-02T09:52:56.881+00:00原発事故を予言していた広瀬さんの最新記事<strong><a href="http://diamond.jp/articles/-/11514" target="_blank">記事</a></strong><br /></br><br />うーん、これを読むと、「事故」というよりは「必然」だったのか。。。</br><br />著者は大学時代応用科学を学んだ広瀬さんで、なるほど説得力があります。</br><br /></br><br /><blockquote>水素ガスの爆発限界は、最小値が4.2%であるから、この濃度になれば爆発する。</blockquote>というのは「おや?」と思いましたが、「爆発し得る」という意味か。</br><br /></br><br />一番恐ろしい記述は、<blockquote>4号機では建屋内の使用済み核燃料のプールが沸騰を始めたという。ここには、原子炉より多くの放射性物質が入っている。作業者が近づけない場所であるから処理はおそらく不能であろうと、15日の午後5時時点で、私は推測するが、この推測が間違ってくれるよう祈っている。福島第一原発の6基のうち、1基がメルトダウンすれば、そこには職員がいられなくなる。すべてを放棄して逃げ出すだろう。あとは連鎖的に事故が起こる。</blockquote>。</br><br /></br><br />たしかにヘリで冷却水を投下するとか検討されてたなぁ。。今は消防車で放水してるみたいですが、まともに近づけないというのはチェルノブイリを連想させます。</br><br /></br><br />敦賀原発・美浜原発も福島と同じく高経年原発だそうで、広瀬さんの指摘が事実ならば、廃炉にすべきなのかも。他に高経年原発がどれくらいあるのか分かりませんが、比較的原発依存度の高い日本は難しい選択を迫られそう。</br><br /></br><br />化石燃料の値段が上がっているなか、日本の経済は弱体化していますからね。日本国内の国債消化力が低下して金利が上がり始め、円安という流れになれば、円建の化石燃料価格はさらに上がり、非常に苦しいことになるかもしれません。かといって原発に依存する道をさらに進んでいっていいものか。。。</br><br /></br><br />技術的なブレイクスルーが起きてクリーンな代替エネルギーが出てきてくれればいいのですが。。</br><br /></br><br />うーん、日本の未来はどうなるのか。。</br><br /></br><br /><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-72690573512641402462012-02-02T09:52:00.035+00:002012-02-02T09:52:56.859+00:00Tail recursionとNon-tail recursionErlangには、C言語やJavaなどの手続き型言語でおなじみのループがありません(!)。その代わりに再帰で問題を解いていかなければいけないのですが、手続き型言語しかやったことがないとむずかしいですね。。</br><br /></br><br />まぁしょうもない問題もパズルみたいで、ある意味面白いのですが。今日は、Erlangプログラミングで最も重要な概念とも言えそうな再帰について勉強していきます。</br><br /></br><br /><span style="font-size:x-small;"><span<br />style="color:#653200;">※この投稿はstackoverflow.comからのマテリアルを使用しており、よってライセンスはいつもの<a<br />href="http://creativecommons.org/licenses/by-nc-sa/3.0/"<br />target="_blank">CC BY-NC-SA 3.0</a>ではなく<a<br />href="http://creativecommons.org/licenses/by-sa/2.5/"<br />target="_blank">CC BY-SA 2.5</a>です。<br /></span></span></br><br /></br><br /></br><br />Tail recursionとNon-tail recursionの違いは、ざっくり言うと、</br><br /></br><br />1) Non-Tail recursion:</br><br />次の関数呼び出しをした後も、元のスタックフレームが情報を保持していなければならないもの。</br><br />2) Tail recursion:</br><br />次の関数呼び出しを行ったら、元のスタックフレームが必要なくなるもの。</br><br /></br><br />取りあえず今のところ、例えばJavaではTail recursionだからといって元のスタックフレームを捨てる最適化(tail call<br />optimization)を行えず、折角必要なくなっているのにスタックフレームを捨てないので、そういう言語ではそれほど重要な違いではないのですが、Tail call<br />optimizationを行うErlangでは、Tail recursionはconstant memory space (=メモリの使用量のオーダがO(1))で実行できるのに対し、Non-tail<br />recursionはできないという根本的な違いが出てきます。</br><br /></br><br />Java出身の人間にわかりやすい言い方をすると、Non-tail<br />recursionではスタックオーバーフローによっていずれプロセスがお亡くなりになってしまいますが、Erlangでは、Tail<br />recursionだと、無限ループが可能になります。Javaであれば、Tail<br />recursionであろうがやはりスタックオーバーフローに陥りますが、これは、上で述べたとおり、JVMがErlangと違ってtail call<br />optimizationを行わないからです(詳しくは<a<br />href="http://stackoverflow.com/questions/105834/does-the-jvm-prevent-tail-call-optimizations"<br />target="_blank">こちら</a>)。</br><br /></br><br />Erlangでは、たくさんのプロセスがあたかもモノというか、会社の部署のようにコミュニケーションしながら働きます。一つ一つのプロセス(アクター)は、それぞれ独立していて、お互いいわばメールでしか干渉せず、基本的には部署ごとで働いているイメージです。このようなプログラミングモデルを<a href="http://en.wikipedia.org/wiki/Actor_model" target="_blank">アクターモデル</a>というのですが、このアクターを作るとき、実はこのtail recursionによる無限ループを使うのです。なので、これをマスターしないと、Erlangの一番のミソが使えないということになってしまいます。</br><br /></br><br />さて、例をあげて、tail recursionとNon-tail recursionの違いをより直感的に見ていきます<span style="font-size:x-small;">(<a<br />href="http://stackoverflow.com/questions/33923/what-is-tail-recursion"<br />target="_blank">USCのLorin氏の解説をもとにしています</a>)</span>。</br><br /></br><br />あるNを与えられたら、1からNまでを足し合わせる関数を考えます。</br><br /><blockquote> sum(5) = 1 + 2 + 3 + 4 + 5 = 15 </blockquote></br><br /></br><br />Non-tail recursionでは、このように書けます。</br><br /><script type="syntaxhighlighter" class="brush:python" title="snippet.py"><br /><![CDATA[<br />def recsum(x):<br />if x==1:<br />return x<br />else:<br />return x+recsum(x-1)<br />]]><br /></script><br /><br /></br><br />recsum(5)をコールした場合、計算は次のように実施されます:</br><br /><blockquote><br />recsum(5)</br><br />5+recsum(4)</br><br />5+(4+recsum(3))</br><br />5+(4+(3+recsum(2)))</br><br />5+(4+(3+(2+recsum(1))))</br><br />5+(4+(3+(2+1)))</br><br />15</br><br /></blockquote></br><br /></br><br />一番上のスタックフレームは、まだ 5 + recsum(x-1) の「5 + ?」の計算をしないといけないので、スタックフレームにあるものを一旦保存しなくてはいけませんね。</br><br /></br><br />それに対して、tail recursionでは次のように書けます:</br><br /><script type="syntaxhighlighter" class="brush:python" title="snippet.py"><br /><![CDATA[<br />def tailrecsum(x,running_total=0):<br />if x==0:<br />return running_total<br />else:<br />return tailrecsum(x-1,running_total+x)<br />]]><br /></script><br /><br /><span style="font-size:x-small;">※("def tailrecsum(x,running_total=0)" はpythonの書き方で、変数名=数値として関数を定義しておくと、tailrecsum(x)と書くと自動的にtailrecsum(x,0)を呼び出してくれます(デフォルト引数と言います)。<br /></span></br><br /></br><br />先程は計算の手順なんかを保存して置かなければいけませんでしたが、今回は"小計"を変数として渡していくので、その必要がなくなります。</br><br /></br><br />計算はこのように進んでいきます。</br><br /></br><br /><blockquote></br><br />tailrecsum(5,0)</br><br />tailrecsum(4,5)</br><br />tailrecsum(3,9)</br><br />tailrecsum(2,12)</br><br />tailrecsum(1,14)</br><br />tailrecsum(0,15)</br><br />15</br><br /></blockquote></br><br /></br><br />計算の手順がたまっていくのではなく、値がアップデートされながらバトンタッチされていくというこころが、tail recursionのミソです。</br><br /></br><br /><br/><br/>では、Erlangで書いてみましょう。<br /><script type="syntaxhighlighter" class="brush:erlang" title="snippet.erl"><br /><![CDATA[<br />%% Tail recursive<br />tailsum(List) -><br />tsum(List,0).<br />tsum([],Acc) -><br />Acc;<br />tsum([H|T],Acc) -><br />tsum(T,Acc + H).<br /><br/><br/>%% Non-tail recursive<br />sum([]) -><br />0;<br />sum([H|T]) -><br />H + sum(T).<br /><br/>]]><br /></script><br /><br /><br/>なんとなくNon-tail recursionの方がスマートですね。こう考える人は多いみたいで、「必要に迫られなければ、tail recursionは基本使わない」という人もいるようです。<br /><br/>昔はTail recursionの方がずっと早かったり、メモリ消費量がずっと小さかったりしていたらしいのですが、様々な最適化のおかげで、今は一概にどちらがよいとも言えなくなったそうです。<br /><br/>なので、「お好きな方で」やって、必要ならパフォーマンステストして比べなさいというのが最近のErlangのガイドラインのようです。<br /><br/><br/><a href="http://stackoverflow.com/questions/33923/what-is-tail-recursion" target="_blank">参考:http://stackoverflow.com/questions/33923/what-is-tail-recursion<br /></a><br /><br/><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-207516081218279282012-02-02T09:52:00.033+00:002012-02-02T09:52:56.830+00:00Python/Ruby, Java, Erlangの違いと、ファンクションプログラミングDynamic Typingで、関数がオブジェクトとして扱われるErlangは、PythonやRubyに似ているところもあります。一方でJavaはStatic Typingで、関数はオブジェクトとして扱われないので、そこは仲間外れと言えます。<br /><br/>同じく関数がオブジェクトとして扱われるといっても、Python/RubyのファンクションプログラミングとErlangのファンクションプログラミングでは色々大きな違いがあるのですが、今日はPython/Ruby, Erlangがサポートしていて、Javaがサポートしていないファンクションプログラミングの1つ、"Higher order functions"について見ていこうと思います。<br /><br/><br/><br/>[1, 9, 3, 5, 8, 4, 2]というリストがあったとして、ここから3以上のものを取り除きたいとしたら、Javaであればこんな感じで書くことが多いと思います。<br /><br/><script type="syntaxhighlighter" class="brush:java" title="snippet.java"><br /><![CDATA[<br />List<Integer> lessThan(List<Integer> source, Integer th){<br />List<Integer> ret = new ArrayList<Integer>();<br />for(Integer elem : source){<br />if(elem < th){<br />ret.add(elem);<br />}<br />}<br />return ret;<br />}<br />]]><br /></script><br /><br /><br/>さらに一般化してやりたいなぁという場合は、次のようなこともできるでしょう。かなり長くなってしまいますが、「必要なもの以外取り除く」という汎用的なfilter関数を定義し、「何が必要で何が必要ではないか」を決めるためのPredicateインターフェースを定義し、最後に、使う際に適切なPredicateの実装クラスを渡しています。まぁ、Comparatorの考え方と一緒ですね。<br /><script type="syntaxhighlighter" class="brush:java"><br /><![CDATA[<br /><br/>////<br /><T> List<T> filter(List<T> source, Predicate<T> p){<br />List<T> ret = new ArrayList<T>();<br />for(T elem : source){<br />if(p.apply(elem){<br />ret.add(elem);<br />}<br />}<br />return ret;<br />}<br /><br/>////<br /><br/>interface Predicate<T> {<br />boolean apply(T t);<br />}<br /><br/>////<br />public static void main(String[] args){<br />List<Integer> source = Arrays.asList(new Integer[]{1,2,3,4,5,6});<br /><br/>Predicate<Integer> p =<br />new Predicate<Integer>(){<br />public boolean apply(Integer subject){<br />return subject < 3;<br />}<br />};<br /><br/>List<Integer> filtered = filter(source, p);<br />}<br /><br/>]]><br /></script><br /><br /><br/>一番初めのコードではlessThanという名前にせざるを得ず、せいぜい「どの数字より小さいものを残すか」しか「パラメータ化(外だし)」できなかったのですが、無名関数を利用することで、データ型、およびビジネスロジックを外だしすることができ、filter関数をもっと自由に再利用できるようになったりました。<br /><br/>これを使って、例えばこんなことができます。<br /><br/><script type="syntaxhighlighter" class="brush:java"><br /><![CDATA[<br />public static void main(String[] args){<br />List<String> source =<br />Arrays.asList(new String[]{"AB","BC","AC"});<br /><br/>Predicate<String> p =<br />new Predicate<String>(){<br />public boolean apply(String subject){<br />return subject.startsWith("A");<br />}<br />};<br /><br/>List<Integer> filtered = filter(source, p);<br />}<br />]]><br /></script><br />よく見ると、Predicateクラスは単に関数を入れておくために存在していますね。つまり、これは、「関数がオブジェクトとして扱われない」Javaで、無理やり関数をオブジェクトとして扱う「裏技」です。なので、実はこの裏技を使えばJavaでもHigher order functionを使うことができます。<br /><br/>Erlang, Python, Rubyではそもそも関数自体を最初からオブジェクトとして使ってくれるので、同じことをする場合、クラスで「ラッピング」しなくても済みます。<br /><br/>では、同じことをErlangでやってみます。<br /><script type="syntaxhighlighter" class="brush:erlang" title="snippet.erl"><br /><![CDATA[<br />filter([],_) -><br />[];<br />filter([H|T],Func) -><br />case Func(H) of<br />true -> [H|filter(T,Func)];<br />false -> filter(T,Func)<br />end.<br /><br/>main() -><br />Func = fun(E) -> E < 3 end,<br />filter([1,2,3,4,5,6,7,8], Func).<br /><br/>]]><br /></script><br /><br />fun(E) -> E < 3 endが、無名関数であり、それがオブジェクトとして、Funcに代入され、filter関数の引数として渡されています。<br /><br/>こちらはPython。<br /><br/><script type="syntaxhighlighter" class="brush:python" title="snippet.py"><br /><![CDATA[<br />def myfilter(list, p):<br />ret = []<br />for elem in list:<br />if p(elem):<br />ret.append(elem)<br />return ret<br /><br/>if __name__ == "__main__":<br />source = [1,2,3,4,5]<br />p = lambda x: x < 3<br />filtered = myfilter([1,2,3,4,5], p)<br />]]><br /></script><br /><br /><br/>とりあえず、Python, Erlangの方が短いですね。まぁ、それはPythonとErlangがDynamic Typingで、JavaがStatic Typingだから、というところも大きいのですが。<br /><br/>Javaでもこういったファンクションプログラミングをしたいという人は多く、<a href="http://code.google.com/p/guava-libraries/" target="_blank">Google Guava</a>, <a href="http://functionaljava.org/" target="_blank">Functional Java</a>といった、Javaでのファンクションプログラミングをやりやすくしてくれるライブラリが人気になっています(特にGuavaは、もはやJavaプログラマ必須ではと言いたくなるほど秀逸)。<br /><br/><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-38056869812849803332012-02-02T09:52:00.031+00:002012-02-02T09:52:56.807+00:00クラウドビジネス図鑑ここ最近クラウドのお勉強をしてたので、今日はそのまとめをお送りしたいと思います。<br /><br /><br /><br />筆者は、要するにクラウドとはXaaS (X As A Service)のことだと考えています(厳密にはきっと色々違いがあるのでしょうが。。)。なので、クラウドビジネスを俯瞰するために、現在注目されているXaaSを見ていきます(各XaaSの定義は信用できる文献を引いているわけではなく、筆者が独断で決めている部分もあるので、ご注意を。特に、具体例で挙げているサービスには筆者が使ったことのないものも多く、ディスクリプションに間違いが含まれている可能性があります。ご指摘などあれば、コメントなどお願いします!)。リストは、サブカテゴリも含めて、全てできるだけソフトウェア開発技術でいう「下級」から「高級」*の順に並べています。また、サブカテゴリは全て筆者独自の定義なのでご注意を。<br /><br /><span style="font-size:x-small;">*:「下級・高級」の違いについては<a href="http://en.wikipedia.org/wiki/Abstraction_layer" target="_blank">こちら(英語)を参照</a>。要するに、よりHW・インフラストラクチャに近い方を下級、より抽象化されてビジネスロジックに近いものを高級としています。</span><br /><dl><br /><dt><strong>IaaS (Infrastructure As A Service)</strong></dt><br /><dd>基本的には、サーバ、ネットワーク機器、ストレージ機器の代替。土地・建物・ハードウェアなどを持たなくてよくなり、メンテナンス、システムアドミン業務も低減できる。ただし、低減できるとはいっても、実はかなりのメンテナンスタスクが必要になると言われており、引き続きインフラエンジニアリソースが必要である。<br /><ul><br /><li><strong>非サーバIaaS:</strong>ストレージ、ロードバランサなどサーバ以外のインフラストラクチャを借りれるサービス。アマゾンの<a href="http://aws.amazon.com/elasticloadbalancing/" target="_blank">Elastic Load Balancing (同社EC2専用)</a>、<a href="http://aws.amazon.com/ebs/" target="_blank">Elastic Block Storage (EBS)</a>などが代表。ちなみにAmazon EBSでは最近、大手ニュースアグリゲーションサイトRedditを含む複数大手サイトをダウンさせる障害が、数ヶ月間に複数回発生。少し悪評が立ってしまっている。</li><br /><li><strong>サーバIaaS:</strong>仮想サーバを時間課金などで「間貸し」してくれるサービス。OSを自分で入れるものもあるが、大体はメニューからOSを選んでインストール済みの仮想サーバをもらう。セキュリティパッチの適用や、LAMP環境などのプリインストールといった追加的なサービスを実施している事業者も多いよう。リソースは完全にオンデマンドではなく、あらかじめ指定したキャパシティ(ストレージ容量、RAM量、CPUリソースなど)を買っておいて、完全に使いきらなかった分は「残念でした」という料金形態が多い(完全にオンデマンドのサービスとしては、1トランザクションいくらという料金体系のDBサービスなどがある)。料金体系は月単位買いきり、起動時間分課金など様々なものがあるよう。代表例は<a href="http://aws.amazon.com/ec2/" target="_blank">Amazon EC2</a>、<a href="http://cloud.nifty.com/" target="_blank">Nifty Cloud</a>、<a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/pgmrk/entry/_ef_bc_91_e6_99_82_e9_96_93_ef_bc_91_ef_bc_90_e5_86_86_e3_81_ae_e3_83_91_e3_83_96_e3_83_aa_e3_83_83_e3_82_af_e3_82_af_e3_83_a9_e3_82_a6_e3_83_89_e7_92_b0_e5_a2_8318?lang=ja" target="_blank">IBMクラウド(IaaS)</a>など。</li><br /></ul><br /></dd><br /><dt><strong>PaaS (Platform As A Service)</strong></dt><br /><dd>OSと、DB、アプリケーションサーバなどのミドルウェアを借りて、その基盤に自作アプリを展開する方式。OS、アプリケーションサーバ、DBなど用意されるサービスについてはチューニング・セキュリティパッチの適用などを気にしなくてよくなる。そのため、インフラエンジニアリソースのいない組織でも開発が可能になってくる。スコープ(どこまでが利用者が行うことで、どこまでがプロバイダが行うことか)はXaaSの中でもっとも多彩と思われる。<br /><ul><br /><li><strong>オープン型:</strong>アプリケーションサーバ、ランタイム環境などが提供され、制限は存在するものの、比較的少なく、割と好きなようにアプリケーションを組める。代表例は<a href="http://developer.force.com/vmforce" target="_blank">vmForce</a>, <a href="http://www.heroku.com/" target="_blank">Heroku</a>, <a href="http://www.microsoft.com/windowsazure/" target="_blank">Azure</a>など。具体的には、バックグラウンドプロセス、スレッド、ソケットなどが利用できたり、任意のミドルウェアを展開して使えたり、2つ以上の開発プラットフォーム(例えばvmForceだとJython, JRuby, Groovy, Scala, Javaなどが使用できるはず)が使えたりする種類のもの。こういったサービスはDBも従来型のリレーショナルDBを用いることができるものが多い。</li><br /><li><strong>セミオープン型:</strong>比較的制限が多いが、その代わりメンテナンスコスト、ランニングコスト、初期コストが少なく、スケールアップが容易といった位置づけで提供されているサービス。バックグラウンドプロセス、スレッド、ソケットが使えなかったり、リクエストの実行時間に制限があったり、サービスに付属のDB以外は使えなかったりする制限がある。特にDBについてはリレーショナルDBでないことが多いよう。2つ以上の開発プラットフォームが使えるものもある。代表例は<a href="http://code.google.com/appengine/" target="_blank">Google App Engine</a>など。</li><br /><li><strong>クローズド型:</strong>比較的制限が多く、どちらかと言うと特定用途のアプリケーション開発に向いているもの。プラットフォーム独自の言語でしか開発できないものもある。代表例はSalesforce.comの<a href="http://www.salesforce.com/platform/" target="_blank">Force.com</a>。Force.comでは同社独自の言語であるApexを用いなければならず、オープンソースのライブラリやソフトウェアを展開するのはほぼ不可能。他にも一回のDBクエリで取得できる行数、一時に使用できるヒープメモリなどに細かい制限(governor limit)があり、自由度が低い傾向があるよう。そのため、多種多様なアプリを開発する総合的なプラットフォームとしては現状適していないという意見が多い。その代わり同社のCRMとの相性が良く、CRMを大幅にカスタマイズするような局面では非常に適していると見なされている。ただし、クラウドSIの先駆で米国のスタートアップ企業である<a href="http://www.appirio.com/jp/" target="_blank">Appirio社</a>などは、独自のノウハウを駆使して、force.com上でCRMに限らず様々なエンタープライズアプリを開発・展開しているとのこと。</li><br /><li><strong>MaaS (Middleware as a Service)型:</strong>DB、分散コンピューティング、モニタリングサービスなど、従来型のシステム開発では商用ミドルウェア、オープンソースミドルウェアを充てるもの。具体例には、データベースを提供しトランザクション毎課金などの料金体系が使えるSalesforceの<a href="http://www.database.com/" target="_blank">database.com</a>や、科学計算などのパラレルコンピューティングが主なユースケースである<a href="http://www.picloud.com/" target="_blank">PiCloud</a>などがある。PiCloudはバックエンドにAmazonのAWSを使用しているそうで、IaaSをMaaSにすることで付加価値を付して販売しているということになる。こういった「クラウドミドルウェア」が提供するサービスのコンシューマは、クライアントソフトウェア(PC上で動くデスクトップアプリケーション)、自社ホストの従来型バックエンド、PaaS上のアプリなど様々なパターンが考えられる。人によってはSaaSに含める人もいるのかもしれないが、SaaSにしては下級だと思うので、筆者はPaaSに分類している。</li><br /><li><strong>モバイルプラットフォーム型:</strong>AppleのApp Store、AndroidのAppstoreなどのスマートフォンアプリプラットフォーム、Gree、DeNAのSNSアプリプラットフォームなど。XaaSに含めない人もいるのでしょうが、クラウドと非常に密接に関連しているとは少なくとも言えそう。</li><br /><li><strong>マーケットプレース・ポータル型:</strong>大分毛色は違いますが、B2C型のSaaSを販売する経路(ポータル)だけを提供する形態のこと。ホスティングなどには関与しない。クラウドならではの利点が薄そうなのであまりピンと来ませんが、そういうビジネスをして「クラウドビジネス」と言っている会社もいるみたいなので。</li><br /><li><strong>デスクトッププラットフォーム型:</strong>Chromium/Ubuntu/Windowsなどのネットブック/PCプラットフォーム。Eclipseなどの「プラットフォーム型アプリ」も含めたいと思います。「全然クラウドじゃないじゃん」と言われてしまいそうですが、Ubuntuなんか<em>apt-get install</em>を使えばほとんどSaaS感覚でソフトが使えるようになります。ブラウザのChromeみたいに勝手にアップデートするソフトが増えてきて、かつOSもChromeと同じくらいシームレスにアップデートされるようになってくれば、割とSaaSに近くなってくるのではないでしょうか。以前から存在した<a href="http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html" target="_blank">Java Web Start</a>といったリッチクライアント技術もあります。XaaSに入れるのは間違いかもしれませんが、これからXaaSと「従来型ソフト」の境目ってあいまいになってくるんじゃないかと思うんです。この辺の示唆などは、次回考えてみたいと思います。関連のある試みとしては、<a href="http://www.appup.com/applications/index" target="_blank">Intelのネットブック向けアプリストア</a>があります。</li><br /></ul><br /></dd><br /><dt><strong>SaaS (Software As A Service)</strong></dt><br /><dd>従来ユーザがパッケージソフトを購入したり、カスタムアプリを開発して利用していたサービスを、月額などで課金して提供する形式(説明不要か(^^;))。<br /><ul><br /><li><strong>バックエンドサービス提供型:</strong>ビジネスインテリジェンス、コンテンツマネジメント、課題管理などの機能を、他のシステム(そして最終的にはUI)にインテグレーションすることを前提で、開発者向けのAPIとして提供するもの。B2Bだけではなく、以前はクリック証券が、個人投資家が自作のシステムトレードソフトウェア開発に利用出来るAPIを提供して話題になった。<a href="http://system-trading.jp/news/index.php?ID=57" target="_blank">クリック証券はこのAPIサービスを停止してしまった</a>ようだが、他の証券会社が引き続き似たAPIを提供しているよう。こういったAPIを使って個人の開発者が作成したシステムトレードソフトウェアを、さらに個人投資家に販売するといったビジネスも発生している。その他の具体例としては、科学計算などに使える<a href="http://www.wolframalpha.com/" target="_blank">WolframAlpha</a>、ビジネスインテリジェンスの<a href="http://www.sas.com/solutions/ondemand/index.html" target="_blank">SAS-on-Demand</a>など。</li><br /><li><strong>社内システム型:</strong>UIまで提供され、それを従業員などが直接利用する形態。APIなども合わせて提供され、これを使ってSIerが他システムと連携させた上で導入する場合も。基本的に零細~小企業は直接利用、中~大企業はSIerを使ってカスタマイズ・連携した上で導入するパターンが多いと思われる。具体例は、開発支援ソフトの<a href="http://www.fogcreek.com/fogbugz/" target="_blank">Fogbugz</a>、電子カルテの<a href="http://www.nec.co.jp/medsq/solution/sr/index.html" target="_blank">MegaOakSR for SaaS</a>, <a href="http://www.salesforce.com/jp/?ir=1" target="_blank">Salesforce CRM</a>、<a href="http://www.google.com/apps/intl/en/business/index.html" target="_blank">Google Apps</a>など。</li><br /><li><strong>B2C型:</strong>一般消費者向けに直接サービスを提供する方式。家計簿、投資管理、タスク管理、コンテンツ管理など。具体例はオンラインストレージの<a href="http://www.dropbox.com/" target="_blank">Dropbox</a>、投資管理ソフトの<a href="https://www.mint.com/" target="_blank">mint.com</a>、<a href="https://mail.google.com" target="_blank">Gmail</a>(個人向け)など。変わり種では、オンラインで画像処理ができる<a href="http://pixlr.com/" target="_blank">pixlr</a>も。</li><br /></ul><br /></dd><br /><dt><strong>DaaS (Data As A Service)</strong></dt><br /><dd>株式市場のデータ、音楽・写真などのデータをオンデマンドで売るサービス。iTunesやKindleも広義に解釈すれば含まれるんじゃないだろうか。ただし、基本的には他システムへのインテグレーションを前提にAPIを公開しているサービスを言うようだ。</dd><br /><dt><strong>DaaS (Desktop As A Service)</strong></dt><br /><dd>デスクトップをサービスとして提供するビジネスモデル。目的としては、色々なPCからでもいつも同じ環境にアクセスしたいという「利便性」と、デスクトップにデータを持ちたくないのでシンクライアントにしたいという「セキュリティ」の2つに分類できるのではと思う。<br /><ul><br /><li><strong>部分型:</strong>ブックマークの同期や、ファイルの同期を取るソフトウェアが提供され、共有PCなど他のPCを使っていても、あたかもいつも自分の「メインPC」を使っているかのような利便性が得られるもの。完全にメインPCと同じように使えないのならSaaSじゃないかという話もあるが、<a href="https://one.ubuntu.com/" target="_blank">Ubuntu One</a>などは完全な仮想デスクトップでなくても、SaaSをいくつか組み合わせてより仮想デスクトップに近い形にすることをコンセプトにしているようなので、そういうものは「セミDaaS」とでも言っていいのではと思う。</li><br /><li><strong>完全型:</strong>デスクトップ環境をリモートログイン感覚で、まるまるサービスで提供する形態。シンクライアントなど。<a href="http://jp.fujitsu.com/solutions/cloud/daas/" target="_blank">富士通のサービス例</a></li><br /></ul><br /></dd><br /><dt><strong>PaaS (Peripherals As A Service)</strong> ※筆者の勝手な造語</dt><br /><dd>Desktop As A Serviceでは、「どのHWからアクセスしても同じデスクトップに接続したい」というものだったが、これはあべこべに「同じデスクトップから、いろいろな周辺機器(HW)を使いたい」という要望に応えるサービス。<a href="http://itpro.nikkeibp.co.jp/article/NEWS/20110422/359739/?t1=" target="_blank">NECが、コンビニの複写機などで「クラウド越しで」プリントアウトできる仕組み</a>を開発しているそうで、そういったものはこれに含まれるのではと思う。他には写真を焼く機械や、CD/DVDなどの媒体を焼く周辺機器、カメラなどが想定できそう。<br /></dd><br /><dt><strong>RaaS (Real-life As A Service) </strong>※筆者の勝手な造語</dt><br /><dd>半分冗談ですが(^^;)個人的には「マネージド農業プラットフォーム」とかやってみたいですね(笑)オンデマンドで土地とか水とか肥料とか買えて。。好きな種をまいて収穫して送ってもらうとか。こないだGreeの人に言ってみたら「もうハコニワあるよ」なんて馬鹿にされてしまいましたが、バーチャルな庭じゃなくて、ガチでビニールハウスを運営してもらって、本物の種をまいて本物の野菜とかを栽培するサービスです。リアル釣りスタは人件費が途方もなくかかりそうなので無理そうですねw。他にも「マネージドお料理プラットフォーム」(レシピを送れば調理して送ってくれる)とか、夢は広がります。もうすでに存在しているものでいえば、オンライン英会話のスカイトークとか、オンライン家庭教師などがあります。そう考えると、このジャンルにも何か分類名を与えてもいいのではと思います。でも家庭教師とかそもそもサービスなんで、As A Serviceだと語呂がいまいちですが。。<br /></dd><br /><br/></dl><br /><br/><br/>。。。後からわかったのですが、米国標準技術局(NIST)がXaaSの定義を詳細にしているのだそうです。<a href="http://agilecat.wordpress.com/" target="_blank">ブログAgile Cat</a>が非常に<a href="http://agilecat.wordpress.com/2011/03/09/nist-%E3%81%AB%E3%82%88%E3%82%8B-saas%EF%BC%8Fpaas%EF%BC%8Fiaas-%E3%81%AE%E6%9C%80%E6%96%B0%E5%AE%9A%E7%BE%A9-jan-2011-cloud-cloudcomputing-jawsug-jazug-googlejp-cbajp-cloudjp/" target="_blank">詳細に紹介</a>しておられます。<br /><br /><br /><br />その他クラウドの定義などについて考察している記事:<br /><br /><a href="http://blog.pasonatech.co.jp/yokota/101/9124.html" target="_blank">お前の言っている「クラウドコンピューティング」とはなんですか?<br /></a><br /><br /><br/><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-1929185144422368792012-02-02T09:52:00.027+00:002012-02-02T09:52:56.773+00:00【お薦め洋書】 Unbroken: A World War II Story of Survival, Resilience, and Redemption第二次世界大戦から生還したアメリカ兵Louis Zamperiniの実体験を、著者のLaura Hillenbrandが、Louis Zamperini本人の全面的な支援を受けて、何年にもわたってありとあらゆる記録、証言を丹念に集め、書き上げた大作です。事実関係には本当に驚くほど細かく脚注がついており、根拠となっている資料・証言が丹念に示されています。<br /><br/>僕が今までに読んだ中で、文句なしで一番心動かされた本です。あまりに凄惨な戦争の現実。何度も何度も折れそうになるたび、立ち上がり戦うLouis。死んでいく仲間たち。残酷な日本人との出会い、やさしい日本人との出会い。アメリカで心を切り裂かれる想いでLouisを待っている家族との家族愛、再会、そして終戦後もLouisを苦しめる戦争の記憶。日本人としては複雑な気持ちになる作品ですが、本当に是非読んで欲しい作品です。<br /><br/>読み始めると先が気になって止まらず、久しぶりに本のせいで寝不足になりました。歩きながら、あるいは電車の中など、何度となく感動して涙してしまいました。読み終えた後は、平和であること、今ある幸せに対する感謝の気持ち、そして勇気と元気がじわじわ湧いてくる、そんな本です。<br /><iframe src="http://rcm.amazon.com/e/cm?lt1=_blank&bc1=FFFFFF&IS2=1&npa=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=lazyimpatandh-20&o=1&p=8&l=as1&m=amazon&f=ifr&ref=qf_sp_asin_til&asins=1400064163" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0" align="left"></iframe><br />【あらすじ】<br />貧しい家庭に生まれ、一旦は不良となったLouis Zamperiniが、家族のおかげで長距離走に出会い、少しづつ人生を立てなおしていきます。ついにはオリンピック選手にまでなり、ベルリンオリンピックに出場しますが、第二次世界大戦が始まり、今度は空軍の兵士として太平洋に送られます。<br /><br/>ある日、乗っていた爆撃機が太平洋に墜落。なんとか墜落を生き延び、漂流しながら救助を待ちますが。。。想像を絶する地獄の日々を経てようやくたどり着いたのは敵国日本の支配下にある島。<br /><br/>壮絶な捕虜生活から生還したLouisですが、戦争の記憶が彼を苦しめます。ある日、日本兵と取っ組み合って首を絞めあう悪夢を見るLouis。目が覚めたLouisは、自分が妊娠中の奥さんの首を締めていたことに気づきます。。。Louisは戦争の亡霊に打ち克つことができるのか。<br /><br/>できるだけ史実に基づいて忠実に描かれており、ドキュメンタリーとしてもすごく優れた本ですし、Louis氏自身が語った心の変化、キリスト教との関係性もすごく興味深いです。<br /><br/><a href="http://www.louiezamperini.com/" target="_blank">Louie Zamperiniのオフィシャルサイト</a><br /><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-38445912605256166762012-02-02T09:52:00.017+00:002012-02-02T09:52:56.659+00:00【お薦め洋書】(2冊) Free: The Future of a Radical Price と、 What's Mine Is Yours: The Rise of Collaborative Consumptionこれからのビジネスがどう変わっていくかを考える上で外せない2冊ではないかと思います。<br /><iframe src="http://rcm.amazon.com/e/cm?lt1=_blank&bc1=FFFFFF&IS2=1&npa=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=lazyimpatandh-20&o=1&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=B00342VEP6" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0" align="left"></iframe><br />��冊目は、最近急に世の中に増えてきた「無料」の商品・サービスについて考察したChris Anderson (Wired編集長)の著書、「Free: The Future of a Radical Price」。無料で採算が取れていることに納得できる商品・サービスもありますが、たまに一体どうやってお金を稼いでいるんだろうと不思議になってしまう無料の商品・サービスってありますよね。この本は、そういったビジネスの仕組みや、なぜそのようなビジネスが増えてきたのか、また、これからの「無料ビジネス」時代では、どのような点に注意しなければいけないかといった話題を扱っています。<br /><br/><br/><br/><br/>��冊目は、「これからの消費」に焦点を当てた一冊。弱冠33歳<span style="font-size:x-small;">(2011年現在・筆者による推定(^^;))</span>のRachel Botsmanが、オークションサイト、カーシェアリング、P2Pファイナンスなど最近話題になっているサービスについての考察や、様々な経営者・イノベーターとの交流を元に、「世界の消費活動が従来の『ハイパー消費』から、新たな『コラボ消費』へパラダイムシフトしつつある」と主張しています。<br /><iframe src="http://rcm.amazon.com/e/cm?lt1=_blank&bc1=FFFFFF&IS2=1&npa=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=lazyimpatandh-20&o=1&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=0061963542" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0" aligh="left"></iframe><br />少し前にもてはやされた「Web 2.0」と考え方は似ているのですが、新たに「サステイナビリティ」、「コミュニティ」という2つの視点が加えられており、非常に新鮮というか、目からウロコ感があります。ITに深く関わる話ではありますが、ITにとどまらずより大きな視点から論じられています。Web 2.0の進化系というか、あぁ、Web 2.0ってこういう大きな動きの一環だったのか、と感じられるような本です。<br /><br/>著者はさらに、「新たな」潮流であるこの「コラボ消費」が、実は近代以前の消費形態であった物々交換、村社会のいわば復興(「ルネッサンス」の方が適切か)であるとも論じており、非常に興味深いです。<br /><br/>本を読むのはめんどくさいという方は、とりあえず著者がコラボ消費について語っているTEDでの講演を聞いてみてもいいかも(末尾にエンベッドしてます。日本語字幕も出るはずなので試してみてください)。気づいたんですが、Chris Anderson / Rachel Botsmanの両方ともTED演者なんですよね。やっぱTED最高です。<br /><br/><!--copy and paste--><object width="446" height="326"><param name="movie" value="http://video.ted.com/assets/player/swf/EmbedPlayer.swf"></param><param name="allowFullScreen" value="true" /><param name="allowScriptAccess" value="always"/><param name="wmode" value="transparent"></param><param name="bgColor" value="#ffffff"></param> <param name="flashvars" value="vu=http://video.ted.com/talks/dynamic/RachelBotsman_2010X-medium.flv&su=http://images.ted.com/images/ted/tedindex/embed-posters/RachelBotsman-2010X.embed_thumbnail.jpg&vw=432&vh=240&ap=0&ti=1037&lang=eng&introDuration=15330&adDuration=4000&postAdDuration=830&adKeys=talk=rachel_botsman_the_case_for_collaborative_consumption;year=2010;theme=the_rise_of_collaboration;theme=a_taste_of_tedx;theme=new_on_ted_com;theme=not_business_as_usual;event=Not+Business+as+Usual;tag=Business;tag=Culture;tag=Technology;tag=collaboration;tag=communication;tag=consumerism;&preAdTag=tconf.ted/embed;tile=1;sz=512x288;" /><embed src="http://video.ted.com/assets/player/swf/EmbedPlayer.swf" pluginspace="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" wmode="transparent" bgColor="#ffffff" width="446" height="326" allowFullScreen="true" allowScriptAccess="always" flashvars="vu=http://video.ted.com/talks/dynamic/RachelBotsman_2010X-medium.flv&su=http://images.ted.com/images/ted/tedindex/embed-posters/RachelBotsman-2010X.embed_thumbnail.jpg&vw=432&vh=240&ap=0&ti=1037&lang=eng&introDuration=15330&adDuration=4000&postAdDuration=830&adKeys=talk=rachel_botsman_the_case_for_collaborative_consumption;year=2010;theme=the_rise_of_collaboration;theme=a_taste_of_tedx;theme=new_on_ted_com;theme=not_business_as_usual;event=Not+Business+as+Usual;tag=Business;tag=Culture;tag=Technology;tag=collaboration;tag=communication;tag=consumerism;"></embed></object><br /><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-29351496205128101762012-02-02T09:52:00.011+00:002012-02-02T09:52:56.600+00:00Servlet 3.0の「非同期」サポート -- 何がうれしいのか?<br /><br />マニアックすぎる話ですが(^^;)<br /><br /><br />ひとことで言うと、<strong>「これまでは、リクエスト処理時間が長めで、同時接続数が非常に多いサービスをJavaで作る場合はマニアックな方法を使うか、我慢して高いHWコストを払わなければいけなかったが、これからはプログラマが親しんだJavaEEを使ってHW効率のいい実装ができるようになった」</strong>ということになります。<br /><br /><br /><br />じゃぁ「リクエスト処理時間が長めで、同時接続数が非常に多い」って具体的にどんな基準よって話なのですが、僕の超独断と偏見に基づく、超ざっくりな基準はコレです:<br /><br /><br /><br /><ul><br /><li>ビジネスロジック(コンテナからリクエストを受け取ってから、レスポンスをコンテナに渡すまで)部の実行時間が、3-5秒以上</li><br /><li>実行時間が長くなる原因が、ビジネスロジック内で行うIO(ディスク・ネットワーク)</li><br /><li>ピーク同時接続数が500-1000以上</li><br /></ul><br /><br /><br /><br />一応経験に基づいた値ではありますが、当然こんな画一的な基準を提示するのは無謀と言ってもいいくらいなので、ご了承お願いいたします(^^;) さらに、新しいアプリか既存アプリかによって次のようなことを考える必要があります:<br /><br /><br /><br /><ul><br /><li>新しいアプリの場合<br/><br /><ul><br /><strong> <li>そもそもそういうリクエスト処理時間・同時接続数になるのは適切なのか?</li><br /><li>本当に、従来の方式で実装したら問題が出ると予測されるか?</li><br /><li>そもそも同期のインターフェースにすることは適切?メッセージキューなどの非同期型インターフェースの方が適切だということはないか?</li><br /><li>使えなくなってしまうフレームワークなどが出るが、それを補う案はあるか?</li><br /><li>JavaEEとはいえ、従来のプログラミングモデルとはかなり違ってしまうが、それにうまく適応できそうなチームか?</li><br /><li>枯れた技術から新しい技術へ移行する以上、安定性などの面でリスクがあるが、それを凌ぐメリットがあるか?</li></strong><br /><br/></ul><br /></li><br /><li>既存アプリの場合<br/><br /><ul><br /><li><strong>症状の原因は、本当にこの特定の並行性能問題か?</strong><br/><br /><ol><br /><li>Connection RefusedやRead timeout、異常に処理時間が長いなどの問題がクライアント側で確かに出ていて、サーバ側の問題に間違いない<br /><ul><br /><li>負荷バランサのせいだったりすることも。。</li><br /></ul><br /></li><br /><li>異常ではない<br /><ul><br /><li>外部のWebサービスなど外部のサービスに異常が生じて、異常にリクエスト処理時間が長くなっていることも</li><br /><li><br />インフラの異常ではない?サーバ仮想化を使っている場合、仮想マシンを上げすぎて性能が極端に低下しているなどということはないか?(実話(^^;)ネットワーク・DB・ストレージは?他のプロセスがサーバのリソースを圧迫していないか?<br /></li><br /><li><br />バグではない?クライアント側が異常にリクエストを繰り返しているということはないか?サーバ側のバグで余計な処理をしていたり、DB処理が無駄に長く掛かっていることはないか?メモリリークではないか?など<br /></li><br /></ul><br /></li><br /><li>ビジネスロジック部の実行時間が確かに長い<br /><ul><br /><li>コンテナによっては統計を出してくれるかも。プロファイラでスレッドの状況を見るのが一番良いでしょう。</li><br /><li>「ビジネスロジック部は短いが同時接続数が非常に多い」というシチュエーションなら、NIOコネクタの使用で解決される可能性も。最近のメジャーなコンテナならまず使えるはず</li><br /></ul><br /></li><br /><li>単にコンテナの設定が悪いわけではない<br /><ul><br /><li>ドキュメントを参考にチューニングしても症状が持続するかチェックする。実は誰かがデフォルトの設定に余計なことをして問題が起きていることも往々にしてある</li><br /></ul><br /></li><br /><li>スレッドリソースが確かにビジネスロジック部で浪費されている。具体的には、多くのWorkerスレッドがビジネスロジック内で待ち状態か?<br /><ul><br /><li>たくさんのWorkerスレッドが実行可能状態の場合は、コンテキストスイッチスラッシングが起きている可能性があり、むしろmax-threadsを下げると解決する可能性も</li><br /><li>これもコンテナによっては統計を出してくれるかもしれませんが、僕はスレッドダンプを打ち出して集計してます(^^;)</li><br /></ul><br /></li><br /><li>設計やデータ量・処理量などから考えて、多くのWorkerスレッドが待ち状態におかれるということが確かにありそうなことか?</li><br /></ol><br /></li><br /><li><strong>以下の選択肢を全て検討したが、ざっくりとした改造コストとテンビンにかけても、なお改造の方が良い可能性がある</strong><br /><ol><br /><li>もっといいハードウェアを買う<br /><ul><br /><li>最も容易だが、金がかかる上すぐに限界が訪れやすい</li><br /></ul><br /></li><br /><li>HWを足して、負荷バランスする</li><br /><ul><br /><li>まともな高可用性を備えたアプリなら簡単にできるはずだが、コストパフォーマンスがかなり悪くなる場合も。サーバは当然のことながら、負荷バランサでもコストがかかることがある</li><br /></ul><br /><li>他のところやビジネスロジックで最適化などを行い、Workerスレッドが待ちになる時間・リクエスト処理時間を減らす<br /><ul><li>どのくらい「贅肉」があるかによる。基本的に、アプリ・外部サービスが新しかったり、今回ほどの性能要件でテストされたことがなかったり、担当したチームの能力が低かった場合などは、「必要なインデックスが張られていない」などの「削ぎやすい贅肉」が見つかる可能性が高い。そうでない場合は効果の予測が困難</li></ul></li><br /></ol><br /><br/><li><strong>「新しいアプリ」編のチェック項目全て</strong></li><br /></ul><br /></li><br /></ul><br /><br /><br /><br />ここまで検討しても、なお「非同期処理」がベストの選択肢であると考えられるなら、真剣に検討してみる価値がありそうです。次回は、実際にServlet 3.0でのWebサービスを作ってみます(あくまで予定ですが(^^;))<br /><br /><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-61830767802534010312012-02-02T09:52:00.009+00:002012-02-02T09:52:56.576+00:00Eclipseが遅くて腹たってる人中心に、Intellijのススメどうやら日本語化されていないようなので日本で使っている人は少数派かもしれませんが、グーグルやRedHatのOSS開発者の間などで大人気、人気急上昇中の<a href="http://www.jetbrains.com/idea/" target="_blank">Intellij IDEA</a>というJava IDEがあります。<br /><br/>チェコの数学者が集まって作ったIDEで、有料版しかなかった頃から大変評判が良く、割と出来のよいeclipseが無料で誰でも使えるという市場環境にも関わらず大いに健闘していました。この会社は、.netの分野でもいくつか人気の高い開発ツールを出しています。本当にすごくいい噂を聞くIDEなので気にはなっていたのですが、貧乏の身なので試すこともできず...ご多分に漏れず僕もeclipseをずっと使っていました。<br /><br/>が、2009年にベンダが"Community Edition"型のビジネスモデルに移行。要するに、基本機能を備えた版が無料で使えることになったのです!しかもCommunity EditionはApacheライセンスのオープンソースに。太っ腹です。採算は、より高機能のUltimate Editionを販売することでとろうとしているようです(<span style="font-size:x-small;">※ちなみにOSSの開発に使う場合は、Ultimate Editionも無料とのことです</span>)。<br /><br/>てなわけで当時早速使ってみたのですが、結論から言うと、もう絶対離せません(笑) 最初はeclipseとの違いに戸惑うことも少なからずありましたが、<strong><span style="color:#CB0000;"><span style="font-size:large;">取りあえず速い</span></span></strong>。これホント重要。もうこれだけで頑張って乗り換えようという気になります(笑) 次に、Mavenとの連携がマジいい!今は改善されたのかもしれませんが、eclipseのmavenプラグインは大分不安定だったので、かなり違いを感じました。他のプラグイン・機能の類も概して非常に安定して動作し、性能も良いです。オートコンプリートもeclipseより若干かしこく、本当にサクサクプログラミングができます。<br /><br/>他にはリファクタリングがeclipseよりも高機能、なかなか良いコードの静的解析が標準装備されている、すごく高機能のコード変更履歴機能がついている、あたりが思いつく利点でしょうか。ただ、何よりも<span style="font-size:large;"><span style="color:#CB0000;"><strong>速い</strong></span></span>。これにつきます(少なくともeclipse galileo当時はかなりの差があった)。<br /><br/>eclipseに劣るところといえばプラグインの少なさですが、それでもIDEがオープンソース化される前から、プラグインを開発するためのAPIと、そのプラグインを公開するためのマーケットプレースのようなものが提供されていたので、そこそこの数のプラグインは提供されています。今回オープンソースになったので、さらにプラグイン開発の裾野が広がってくれそうです。<br /><br/>商売道具ですから、長年eclipseを使っていると移行の際のストレスはかなりありますが、それを我慢する価値アリです。<br /><br/><br/>とは言えeclipseほどたくさんの言語をサポートしているIDEはないので、今もpython, erlangの開発にはeclipseベースのIDEを使っています。特に、<a href="http://www.aptana.com/" target="_blank">Aptana</a>というところがWeb開発者向けの多言語対応型eclipseパッケージを提供してまして、これがWeb開発には本当に便利です。やっぱ、悪くはないですよね、eclipse。それでも、もっと速いIDEが欲しい。。。と思っている人は、是非Intellijを試してみてください。<br /><br/><br/><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-30528024501808779382012-02-02T09:52:00.005+00:002012-02-02T09:52:56.401+00:00世界は再び小さな村へ・・・ 匿名社会の終焉少し前に、カナダのバンクーバーで市民の一部などが暴徒化する事件がありました(<a href="http://photo.sankei.jp.msn.com/kodawari/data/2011/06/0616nhl/" target="_blank">記事</a>)。バンクーバーでそのような事件が起こったの事自体も驚きでしたが、もう一つ、非常に面白い社会現象が見られました。<br /><br/>reddit.com、facebook、youtubeなどのソーシャルメディアに、現場の写真・映像が次々と投稿され、違法行為に参加していた人々が次々と特定されていったのです。あるカナダのブログは、これらをまとめて、違法行為を働いていた人をいわば晒し者にする"Hall of Shame"キャンペーンを始めました(<a href="http://publicshamingeternus.wordpress.com/" target="_blank">ブログ</a>)。普通の大学生やスポーツ選手などが、違法行為の瞬間を捉えた写真や映像と共に、実名を掲載されています。誤認もあり得ますし、このようなことをすること自体は批判されるべきでしょう(警察などに情報提供するべき)。しかし、この出来事は、これからは「匿名」であることが、オンラインだけでなくオフラインでも難しくなっていることを示しています。<br /><br/>まだ実用化には至っていないものの、普通のスナップ写真から顔を特定し、顔認証で映っている人物を特定する研究が各地で進んでいます。、画像だけでなく、動画からリアルタイムで人物を探す技術の研究もされています。このような技術が実用化されるのは、時間の問題と言えるでしょう。<br /><br/>このような技術の発達で、世界は再び「ムラ社会」に回帰しようとしているのではないでしょうか。技術は新しいものですが、その技術がもたらす世界は、案外かつての田舎に近いものなのかもしれません。だとすれば、大都会に慣れた人は、新しい世界の秩序の中でどううまく生きて行くべきか、田舎に学ぶ必要があるかもしれませんね。<br /><br/>EDIT:カナダの警察に、<a href="http://www.cbc.ca/news/canada/british-columbia/story/2011/06/19/bc-stanley-cup-riot-charges.html" target="_blank">100万枚以上の写真と1000時間分以上の映像が寄せられ</a>、警察では<a href="http://www.straight.com/article-399779/vancouver/icbc-offers-facialrecognition-technology-vancouver-police%E2%80%99s-riot-investigation" target="_blank">顔認証技術も使用してこれらを解析</a>するとのことです。現在の顔認証技術ではどこまで有効かわかませんが、本当に象徴的な事件となりました。<br /><br/><br/>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-75246273345869391182011-09-01T10:26:00.000+01:002018-06-10T10:44:40.025+01:00Test<!-- Start of HubSpot Embed Code -->
<script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/4479359.js"></script>
<!-- End of HubSpot Embed Code -->
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/shell.js"></script>
<script>
hbspt.forms.create({
portalId: "4479359",
formId: "4d5a9649-72a4-4f38-88dd-cef4d07e0167"
});
</script>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.comtag:blogger.com,1999:blog-7885864157296080315.post-13031935270212430442010-06-10T10:42:00.000+01:002018-06-10T10:49:39.404+01:00Test form<iframe src="https://docs.google.com/forms/d/e/1FAIpQLSc5Irgzqe_Yc7ScysuyFe11BOIwHZ62-mj7WNpex9oPpsxQbQ/viewform?embedded=true" width="700" height="520" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>Anonymoushttp://www.blogger.com/profile/12381427424149021180noreply@blogger.com