2014年を振り返ってみる。

2014年も終わりなので、今年1年を振り返りたいと思います。

2014年にやったこと

ちなみに、2014年頭に立てた目標は「アウトプットの機会を増やす」でした。

2014年の目標 - toshimana's diary

ブログを始めた

今年は本格的にブログを始めました。
文字による表現が難しいことに気付かされました。

ブログに書きたいことのイメージがあっても、それを文字で表現することがとても難しい。
元々簡単とは思っていなかったけど、
実際にやってみて、こんなに難しいのか、と気付くことができました。

文字による表現力はブログ以外でも必要になるので、
これからもブログは続けていきたいと思いました。

作りたい物を作れるようになった

C++を使ってプログラミングをすることが多いですが、
今年はGUIを作るため、Qtを覚えました。
色々なツールを作れるように、プログラミングによるもの作りにやっと手が届くようになりました。
まだまだ、運用の面など、実用的なものを作れるだけの知識、技能がないので、精進が必要なところです。

勉強会で初めて発表した

「JAZUG仙台 - JAZUG4周年を祝う会 in 仙台」にてAzure Machine Learningについて
発表させていただきました。
それまで機械学習について、ほとんど理解がなかったのに、
それで発表することになっておりました。*1

20140920 jazug ml from Toshiyuki Manabe

20140920 jazug ml

ランニングを始めた

夏ごろからランニングを始めました。*2
ランニングは情報も多いし、自分のペースで進められるので、
普段運動しない自分には始めやすかったです。
高校時代まではある程度運動していたのですが、走り始めは全然走れなくてビックリしました。
とりあえず、今年は20Kmは走れるようになったので、
翌年は距離をもう少し伸ばすか、走るペースを上げられるようにしたいと思います。*3

振り返り

KPTにしたがって見ると、KPは以下のようになります。

Keep

今年始めたブログやプログラムでのモノづくりは自分の表現力を鍛えるためにも、
これからも続けたいと思います。
勉強会での発表も、翌年の発表は1つ決まっています。機械学習以外でも機会があれば狙っていきたいですね。
ランニングも来年も継続していきたいと思います。*4

Problem

活動できたことについては、それほど問題がなかったと思います。
しかし、活動できなかった時期が今年は多かったかと思います。
もう少しコンスタントに結果を出せるようにしたいです。

まとめ

大した成果を残せなかった1年かと思ったけど、
振り返ってみると、結構動きがあったことに驚いてます。
来年も新しいことに常々挑戦していきたいですね。

それでは、良いお年を！

*1:だいたい、@nnasakiのせい

*2:痩せるためです。

*3:走っているのは痩せるためです。

*4:今年中に目標体重に満たなかったため

TDDへの不満とその対応について考えてみた。

「Code Retreat in Sendai」に参加してきたのですが、その時に、TDDに対して感じた問題点とそれへの対応策について考えてみました。

2014/12/13(土)「Code Retreat in Sendai」に参加しました。 - toshimana's diary

※今回はGUIを持たないものを想定してます。GUIテスト自動化は、難しい。

TDDへの不満

「テストを同時に書くために処理が書きあがるまでの時間は増えるが、バグが少なくなるために総開発時間は短くなる」ことがTDDの主張と理解しています。
そのために、どうもアジャイル的ではないのではないか、と思うところがあります。

末端側からの実装を優先するため、変更に弱い

上記TDDの主張は、設計が適切に行われていることや、開発の途中で変更が起こらない場合に成り立つ、と感じています。
TDDはレッド・グリーン・リファクタリングのサイクルを回すため、小さいところ(末端側)から開発を始めがちです。
TDDで時間をかけたことにより末端側のソースコードが充実していることで、上流側の変更が、既に実装済みの末端側のコードを活用する方向に引っ張られること、また、それにより、不適切な設計になるのでは、と危険を感じます。
そのため、TDDはウォーターフォール開発に向いていて、アジャイル的ではない、と感じています。

TDDのテストは品質保証を目的としていない

TDDのテストは開発者のテストのためであり、品質保証のテストとは別物、というのがよく言われる話です。
開発者のテストが、そのまま品質保証のテストになりえないのは同意です。
しかし、品質保証のテストを使ってTDDをすればいいのではないか、と思っています。
(品質保証のテストと開発者のテストの違いを明確に理解できていないからの発言かもですけど。)

LazyTDD(仮)

TDDよりも上流側からシステムを作れるような工夫を検討してみました。
ここでは仮にLazyTDDとしたいと思います。
TDDが先行評価っぽいイメージを受けたので、Haskellの遅延評価っぽいTDDができないか、と考えてみました。
できる限り、品質保証に使えるテスト、壊れにくいテストの作成を作ることを優先し、品質保証に使えない、壊れやすいテストの作成を可能な限り抑制することを目的としています。

１．最も上流側のテスト(受け入れテストやシステムテストレベルのテスト)を書く。

実現したい機能の動作が確認できるレベルのテストを真っ先に用意します。

２．コードを書く。

必要な処理は可能な限り関数化する。関数はインターフェースのみの実装とする。
この時点では設計としてのコード実装の意味合いが強い。

３．作成した関数のコードを書く。

この際、必要であれば、その関数のためのテストを書く。
必要な場合として、例えば、

• その関数をテストする際に、同じレベルに存在する関数との問題の切り分けが困難と感じたとき
• 上流のテストでは、実行に時間がかかり過ぎるとき

テストを実装するときは、末端側のテストは上流のテストでカバーされる範囲でなければならない。
上流側に影響が表れないのなら、その機能(テスト)は不要だと考えている。

４．３で作成したテストをテストするときは、１のテストを一時的に無効化する。

３で書いたテストがグリーンになった時に、再度１のテストを有効化する。

５．１～４を繰り返す。

まとめ

TDDはプログラマが意図したものを作れる素晴らしい技術だと思います。
しかし、その分、プログラマが必要なもの、顧客が欲しいものに、プログラマが目を向け続けないと、異なる方向に進んでしまう技術とも思いました。
LazyTDD(仮)は私が適当に考えたものなので、同じような技術とかご存じの方がいらしたら教えてください。

関数型プログラミングとオブジェクト指向について思うこと

大学時代に関数型言語を扱っていたため、私は関数型プログラミングが大好きです。
そのため、現代のプログラミングの標準であるオブジェクト指向プログラミング(以下、OOP)にあまり興味が湧いてきませんでした
しかし、2014年はGUIプログラミングに手を伸ばした過程で、OOPと関数型プログラミングの棲み分けについて思うところがありました。今回はそれを書き留めてみようと思います。

関数型プログラミング

「関数型プログラミング」の言葉の意味はwikipediaを見てください。関数型プログラミングにおける“関数”は、数学の“関数”です。
http://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E8%A8%80%E8%AA%9E

関数型プログラミングの魅力

非関数型の言語を使う方でも分かりやすい魅力として、「副作用のない関数」を扱うスタイルが挙げられます。
副作用のない関数によりプログラムを組み上げることにより、「扱う状態を少なくする」ことと「実行順序に依存しない処理を書ける」ことで、バグを少なくすることができます。

扱う状態を少なくする

副作用のない関数によってプログラムを組み立てる関数型プログラミングでは、オブジェクト指向と比較して、状態の重要性が小さいです。
扱う状態数が多くなるほど、その管理が難しくなります。状態の管理を誤るとプログラムになることから、プログラムの状態を少なくすることはバグを少なくすることに繋がる、と言えます。

実行順序に依存しない処理を書ける

Haskellで遅延評価が実現できるように、関数型プログラミングでは「どのような順序で処理するか」はあまり重要視されていません。
オブジェクト指向(というよりも手続き型言語)では、状態を処理する順序によって、得られる結果が変わる場合があるため、本来不要な実行順序の制約が処理に付与される場合があります。そのため、必要以上に実行順序の制約が入りやすくなり、処理の組換えなどが困難になる傾向にある、と思われます。
関数型プログラミングでよく使われる副作用のない関数は、入力が等しいなら得られる結果も等しいことが保障されます。そのため、処理の組換え、部品化が容易です。また、実行順序にとらわれない処理が明確になるため、並行化できる領域も抽出しやすくなります。

オブジェクト指向が関数型プログラミングよりも優れている点

以下は私の感覚です。

オブジェクト指向が得意とする領域は、以下のような点が挙げられる、と考えています。
・状態を扱う必要がある領域
・実行順序を制御する必要がある領域
これは、画面(GUI)制御やデバイス制御がこれにあたります。

実世界に近い部分(人が触る部分(=GUI)や機械が触る部分(=デバイス制御))はオブジェクト指向プログラミングが向いている領域と考えています。実世界における個々の状態を、オブジェクトの状態として容易に表現できます。
対して、状態を管理する必要がない領域はできる限り論理的に、数学的に記載することで、バグを少なくできます。関数型プログラミングはビジネスロジックを記載することに向いていると考えます。
Separated Presentationにおける、プレゼンテーションロジックはオブジェクト指向(+手続き型プログラミング)で、ビジネスロジックは関数型プログラミングで記載すると良いのでは、と考えています。

まとめ

オブジェクト指向だけでも、どんなアプリケーションでも作ることができます。しかし、オブジェクト指向では万物がオブジェクトであれば、それを管理しするプログラマは神でなければならないのか、とも思います。
全てのオブジェクトを一切のミスなく管理するには、まさに神のような能力が必要になると思います。しかし、それは多くの人には困難です。
現実世界における科学の如く、関数型プログラミングはプログラムの世界をより抽象化し、人間に扱いやすくできると考えています。
オブジェクト指向、手続き型、関数型プログラミングが得手不得手があるので、どれか一つを覚えれば十分、ではなく適材適所に扱えることが必要なのだと思いました。

2014/12/13(土)「Code Retreat in Sendai」に参加しました。

プログラマ向けイベント「CodeRetreat」が仙台で初開催とのことなので、行ってきました。

CodeRetreatは「コンウェイのライフゲーム」をテーマに、
主にペアプログラミング、TDDの学習を行うイベントです。

1回45分のセッションを6回行う、なかなかハードなイベントです。
セッション後には毎回コードを削除して、次ははじめから行ったり、
セッションごとにペアや使用する言語を変えて行うため、
新しい考え方に触れることができます。

セッションごとのテーマ

セッションごとにテーマが設定されており、
同じライフゲームを記述するにも、毎回悩まされました。

Session1.特に制約なし
Session2.テストコードとプロダクトコードの入力者を分ける。
Session3.5分ごとに入力者を交代する。(後に、2分ごとに変更)
Session4.プリミティブな値の使用禁止。
Session5.if文,Switch文使用禁止。for文,while文使用禁止。
Session6.変数はすべてimmutableにする。

関数型言語を使って

使う言語に特に制約がなかったため、Haskellの使用を提案したら、
意外と周りの食いつきが良かったです。
割と適当な説明ばかりしていたと思うので、
皆さんに十分に関数型言語の魅力を伝えられなかったと大いに反省しています。

あと、Session4~6のテーマはオブジェクト指向開発に合わせたテーマでしたね。
関数型言語では、再帰関数を積極的に使う文化があるため、Session5のfor, while文使用禁止はほとんど影響ありません。
Session6の「変数すべてimmutable」については、Haskellの場合、デフォルトで変数がimmutableなので、普段通りにコードを書けます。mutableな変数を扱う方が大変です。

オブジェクト指向派の方との意見のギャップは良い刺激になりました。
オブジェクト指向的な設計がどのようなものなのか、
他の人の話を聞いて、普段とは違う考え方に触れられました。

テストの粒度

TDDの初手として、
今回のテーマで最も上流となる(と思っている)テストから書き始めました。
ライフゲームの初期状態を受けとり、
次の状態を返す関数のテストを書きました。
しかしそれだと、テストの粒度が大きすぎて、
テストが通るまでに時間がかかり過ぎる、と指摘を頂きました。

確かに、「このテストでは粒度が大きすぎて、そのテストが通った時点でほぼ実装が完了している」と思いました。
ですが、「粒度を細かくした時の、分割が妥当であることをどのように保障するのか」という疑問が浮かびました。

TDDの基本として「プロダクトコードを書く前にテストコードを書く」というものがあります。
しかし、この前提として、「設計が十分にされていること」があるのではないか、と思いました。

HaskellにおけるTDD

Haskellだと、TDDに設計フェーズをプラスして、サイクルを回せるのでは、と考えてます。
ここの考えはまだ試作です。

Haskellの場合、「型を基づく設計」が可能です。
関数を定義する際に、実装をundefinedにして、型のみを定義することができます。

そのため、以下のような手順によって「設計⇒テスト⇒実装」のサイクルが回せるのではないか、と考えています。
１．作成したい関数の型を定義する。
２．１の関数を実行するときのテストを用意する。（テストは失敗する）
３．１の実装を記載する。必要であれば、新しい関数を型のみ定義する。
４．３で定義した関数のテストを用意する。(テストは失敗する)
５．２のテストを無効化（コメントアウト）する。
６．３の実装を記載する。
７．４のテストが通ったなら、５で無効化したテストを有効化する。

まとめ

いざ、書いてみたら、全然考えがまとまっていないことがよく分かりました。
「オブジェクト指向と関数型の違い」や「関数型言語とTDD」は興味深いところなので、
一度整理してみたい話です。

あまり、CodeRetreatの参加レポートっぽくはありませんでしたが、
お題となった「コンウェイのライフゲーム」のHaskellコードをイベント後に作成してみました。
TDDでの開発ではないので、テストが若干おろそか気味。

toshimana/lifegame · GitHub

Code Retreatでは、思考をpanic zoneに持っていくことで普段より多くの学びを得ることを目的としていますが、イベントが終わった今がまさにpanic zoneに陥ってます。
このpanic状態をうまく解決して、よりよい開発ができるようになりたいです。

2014/11/28(金)「ソフトウェアテスト勉強会～PictMasterを使い倒す！～」に参加してきました。

今回は組み合わせテストの組み合わせを算出してくれるツール「PictMaster」の使い方を学んできました。
PictMasterは組み合わせテスト技法である「オールペア法」を用いるMicrosoft製のツール「PICT」をEXCELでラップしたツールです。

PictMaster プロジェクト日本語トップページ - SourceForge.JP

PICTはとても使えるツールですが、コマンドラインツールなので、初心者にはとっつき辛いです。
PictMasterはExcel経由でPICTが扱えるようになるので、初心者も使いやすいツールになってます。

なぜ、組み合わせテスト技法が必要か？

ラーメンを例にして考えてみます。*1

あるラーメン店では、以下のようなラーメンの味付け、素材を利用者が選ぶことができます。

スープ　　：みそ、塩、しょうゆ、とんこつ
麺　　　　：細麺、中太麺、太麺
ゆで方　　：バリカタ、カタ、ヤワ、バリヤワ
トッピング：チャーシュー、ゆで卵、紅しょうが、すりおろしにんにく、なし

その時の作れるラーメンのパターンは4*3*4*5で240通りになります。
流石にそれを全て試すのは、とても時間とお金がかかって大変です。

オールペア法

ラーメンの例でをオールペア法を使うと組み合わせ数を大幅に減らすことができます。
2因子の組み合わせ網羅の場合、22通りまで減らすことができます。

「因子」とは、スープや麺などの項目名を指します。
また、みそや塩など、因子の要素のことを「水準」といいます。

2因子の組み合わせ網羅とは、
任意の2因子で得られる組み合わせが
必ず1度は組み合わせ表に存在する、ということを指します。

例えば、「スープ：みそ、麺：細麺」や
「ゆで方：バリヤワ、トッピング：なし」など
2因子で好きな組み合わせを作ったとして、
それが必ず組み合わせ表に存在します。

スープ	麺	ゆで方	トッピング
みそ	細麺	バリカタ	チャーシュー
塩	中太麺	バリカタ	ゆで卵
しょうゆ	細麺	カタ	ゆで卵
塩	太麺	ヤワ	チャーシュー
とんこつ	細麺	ヤワ	紅しょうが
しょうゆ	中太麺	バリヤワ	チャーシュー
みそ	中太麺	カタ	すりおろしにんにく
みそ	太麺	バリヤワ	なし
しょうゆ	太麺	バリカタ	紅しょうが
塩	細麺	バリヤワ	すりおろしにんにく
とんこつ	太麺	カタ	チャーシュー
とんこつ	中太麺	バリカタ	なし
みそ	中太麺	ヤワ	紅しょうが
しょうゆ	太麺	ヤワ	すりおろしにんにく
塩	細麺	カタ	なし
とんこつ	太麺	バリヤワ	ゆで卵
みそ	細麺	ヤワ	ゆで卵
塩	細麺	カタ	紅しょうが
とんこつ	中太麺	バリカタ	すりおろしにんにく
しょうゆ	細麺	ヤワ	なし
しょうゆ	中太麺	バリヤワ	紅しょうが

PICT-Masterのその他の機能

結果表や制約条件を用いた組み合わせ表を作成することもできます。

結果表を使う

例えば、PictMasterで単純に組み合わせ表を作った時に、
それぞれの組み合わせでシステムがどのような結果を返すのが適切かは
別途検討しないと行けません。

この結果表を使えば、「ある条件を満たした組み合わせの場合は、こういう結果を返す」
というルールを記載することができます。

制約条件を使う

例えば、「ある条件が真のときは、XXXを選ぶことができない」といった、
組み合わせの中で特殊なケースを想定する必要があることがあります。

PictMasterでは、その制約条件のルールを記載でき、
制約条件を考慮した組み合わせ表を作ることができます。

実際に制約条件に基づいた組み合わせ表を見てみると、
とても人の手で作れるものではない、ということがよく分かります…

制約条件を使うときの考慮点

“制約条件を記述するのがめんどくさいから、
制約条件なく組み合わせ表を作っていらない組み合わせを削除しよう”とすると、
組み合わせ網羅を壊すことになります。

ある組み合わせでは、着目している以外の因子の組み合わせも含まれているので、
不用意な組み合わせの削除は手法が保障する網羅性に穴をあけるので、注意が必要です。

オールペア法において、因子の増加と水準の増加では、どちらが組み合わせ数の増加に影響を与えるか。

結論は、“基本的に、因子の増加よりも水準の増加の方が組み合わせ数の増加に影響を与える”です。

総組み合わせの場合は水準より因子の増加の方が組み合わせ数の増加に影響を与えるため、
パッとは分からない問題でした。

とりあえずの理解としては、オールペア法は因子が多いケースに効果的、という感じで良いでしょうか？

CIT-BACH

PictMaster v6.0から、PICTの他にCIT-BACHというアルゴリズムに対応しています。
CIT-BACHは最小の組み合わせ数を求めることに適している、とのこと。
PICTは(恐らく)乱択アルゴリズムが含まれていて、複雑な制約条件などが含まれる場合、
最小の組み合わせ数が求まらない場合があるが、
CIT-BACHは最小の組み合わせ数を求めるように処理を行う、という話を聞きました。

まとめ

PictMasterは以前にも勉強会でやったことがありましたが、
今回は前回よりも面白く感じました。
当時よりもテスト関係の知識が増えたこともあり、
実業務にどうつなげられるか、などを考えながら話を聞いていたのが
前回との違いかな、と感じつつ、
楽しく学ぶことができました。

*1:勉強会と同じ例を使っています

2014/11/21(金)「Scrumな人材育成―プロダクト開発に必要な人材像や育成方法」に参加してきました。

すくすくスクラム仙台が開催するイベントに参加してきました。
私のScrumに対する理解は、
「アジャイルの方法論の一つで、良いソフトウェアプロダクトを
作るための考え方」程度でしたが、
その認識が改まっただけでも、参加した価値がある勉強会でした。

良いプロダクトを作るために必要な要件

人を採用の際に重視する能力と、
良いプロダクトを作れる人が持っている能力に
ギャップがある、ということを
ワーク形式で学びました。

例えば、良いプロダクトを作るためには
「リスクについて話し合える環境を作れる」能力が必要ですが、
採用の際にその能力は評価されにくい、ということがあります。

良いプロダクトを作るために必要な能力は、
採用の時点で見極めることが難しいです。*1
"測ることが難しいのであれば、組織として培っていく必要があるよね、
そのためにScrumは有効だよね"という話だと考えています。

シチュエーショナル・リーダーシップ

「シチュエーショナル・リーダーシップ」とは
人の状態を「技術の習得具合」と「モチベーション」の二軸のグラフで表現して、
その人の状態に応じて、マネジメントを変える必要がある、という考え方です。

例えば、技術が未熟で仕事に対するモチベーションが低い人に対しては、
細かいやり方まで丁寧に教える「コーチング」が有効だったり、
技術力があるけど、仕事に対するモチベーションが低い人に対しては、
対話によって相手の気づきを促す「メンタリング」が有効、という感じです。

その人の状況に合わせたマネジメントをしないと適切な効果が望めない、という
考え方です。
「技術の習得具合」は立場の変化によって急激に下がる*2ことがあり、
「モチベーション」はその人のプライベートによって揺れ動くこともあります。
そのため、その人の状況を的確に判断してマネジメントをする必要がある、というのは
今回の新しい気づきでした。

また、シチュエーショナル・リーダーシップが対人だけでなく、
対組織などにも有効な考え方であるという点が、
実感が湧かないまでも面白いと思いました。

まとめ

Scrumやリーンを学んでみると、
その手法が本当に価値のあるものを作るために考えられている、
と実感します。

Scrumは方法論ですが、
その方法を実践していく過程で、
価値のあるものを作れる人材、組織が
育っていくのだな、と思いました。

*1:「採用クソが！」という話ではない

*2:例えば、技術者が管理職になったら求められる技術が変化するため

AzureMachineLearningで使えるデータを見てみた。

Azure Machine Learning では、
サンプルで使えるデータセット(Saved Datasets)が公開されています。

お試しで使えるので、どんなものがあるかを整理してみました。
(2014/11/20時点)

データ数や項目数がデータによって大きな差があることが、今回の整理で分かりました。
これらを使って、近々遊んでみようと思います。

以下のフォーマットで並べてます。

ID	Dataset<データセット名>	Row<データ数>	Columns<項目数>	item1	item2...
1	Adult Census Income Binary Classification Dataset	32561	15	age	workclass	fnlwgt	education	education-num	marital-status	occupation	relationship	race	sex	capital-gain	capital-loss	hours-per-week	native-country	income
2	Airport Codes Dataset	365	4	airport_id	city	state	name
3	Automobile price data(Raw)	205	26	symboling	normalized-losses	make	fuel-type	aspiration	num-of-doors	body-style	drive-wheels	engine-location	wheel-base	length	width	height	curb-weight	engine-type	num-of-cylinders	engine-size	fuel-system	bore	stroke	compression-ratio	horsepower	peak-rpm	city-mpg	highway-mpg	price
4	Bike Rental UCI dataset	17379	17	instant	dteday	season	yr	mnth	hr	holiday	weekday	workingday	weathersit	temp	atemp	hum	windspeed	casual	register	cnt
5	Bill Gates RGB Image	25600	5	X	Y	R	G	B
6	Blood donation data	748	5	Recency	Frequency	Monetary	Time	Class
7	Book Reviews from Amazon	10000	2	Col1	Col2
8	Breast Cancer data	683	10	Class	age	menopause	tumor-size	inv-nodes	node-caps	deg-malig	breast	breast-quad	irradiat
9	Breast Canser Features	102294	118	Col1	…
10	Breast Cancer Info	102294	12	Col1	…
11	CRM Appetency Labels Shared	50000	1	Col1
12	CRM Churn Labels Shared	50000	1	Col1
13	CRM Dataset Shared	50000	230	Var1	…
14	CRM Upselling Labels Shared	50000	1	Col1
15	Energy Efficiency Regression data	768	10	Relative Compactness	Surface Area	Wall Area	Roof Area	Overall Height	Orientation	Glazing Area	Glazing Area Distribution	Heating Load	Cooling Load
16	Flight Delays Data	2719418	14	Year	Month	DayofMonth	DayOfWeek	Carrier	OriginAirportID	DestAirportID	CRSDepTime	DepDelay	DepDel15	CRSArrTime	ArrDelay	ArrDel15	Cancelled
17	Flight on-time performance(Raw)	504397	18	Year	Quarter	Month	DayofMonth	DayOfWeek	Carrier	OriginAirportID	DestAirportID	CRSDepTime	DepTimeBlk	DepDelay	DepDel15	CRSArrTime	ArrTimeBlk	ArrDelay	ArrDel15	Cancelled	Diverted
18	Forest fires data	517	13	X	Y	month	day	FFMC	DMC	DC	ISI	temp	RH	wind	rain	area
19	German Credit Card UCI dataset	1000	21	Col1	…
20	IMDB Movie Titles	16614	2	MovieID	MovieName
21	Iris Two Class Data	100	5	Class	sepal-length	sepal-width	petal-length	petal-width
22	Movie Ratings	227472	4	UserID	MovieID	Rating	Timestamp
23	Movie Tweets	170285	8	Scraping Time	Tweet ID	User ID	Movie ID	Rating	Retweet Count	Favorite Count	Time Zone
24	MPG data for various automobiles	392	9	MPG	Cyl	Displacement	Horsepower	Weight	Acceleration	Year	CountryCode	Model
25	Named Entity Recognition Sample Articles	2	1	Col1
26	Pima Indians Diabetes Binary Classification dataset	768	9	Number of times pregnant	Plasma glucose concentration a 2 hours in an oral glucose tolerance test	Diastolic blood pressure(mmHg)	Triceps skin fold thickness(mm)	2-Hour serum insulin(muU/ml)	Body mass index(weight in kg/(height in m)^2)	Diabetes pedigree function	Age(years)	Class variable(0 or 1)
27	Restaurant customer data	138	19	userID	latitude	longitude	smoker	drink_level	dress_preference	ambience	transport	marital_status	hijos	birth_year	interest	personality	religion	activity	color	weight	budget	height
28	Restaurant feature data	130	21	placeID	latitude	longitude	the_geom_meter	name	address	city	state	country	fax	zip	alcohol	smoking_area	dress_code	accessibility	price	url	Rambience	franchise	area	other_services
29	Restaurant ratings	1161	3	userID	placeID	rating
30	Sample Named Entity Recognition Articles	-	-	cannot visualize
31	Steel Annealing multi-class dataset	798	39	family	product-type	steel	carbon	hardness	temper_rolling	condition	formability	strength	non-ageing	surface-finish	surface-quality	enamelability	bc	bf	bt	bw/me	bl	m	chrom	phos	cbond	marvi	exptl	ferro	corr	blue/bright/varn/clean	lustre	jurofm	s	p	shape	thick	width	len	oil	bore	packing	classes
32	Telescope data	19020	11	fLength	fWidth	fSize	fConc	fConcl	fAsym	fM3Long	fM3Trans	fAlpha	fDist	Class
33	Time series Dataset	126	2	time	N1725
34	Weather Dataset	406516	26	AirportID	Year	Month	Day	Time	TimeZone	SkyCondition	Visibility	WeatherType	DryBulbFarenheit	DryBulbCelsius	WetBulbFarenheit	WetBulbCelsius	DewPointFarenheit	DewPointCelsius	RelativeHumidity	WindSpeed	WindDirection	ValueForWindCharacter	StationPressure	PressureTendency	PressureChange	SeaLevelPressure	RecodeType	HourlyPrecip	Altimeter
35	Wikipedia SP 500 Dataset	466	3	Title	Category	Text

表のうまい書き方が分からない…