  |
はてなキーワード: FLAGとは
「韓国人も個人は反日じゃない」みたいな擁護も、戦犯旗キャンペーンとか見るとむなしくなる。
これやって韓国のイメージが良くなるの？って思うけど、もう日本に対するディスカウントキャンペーンそれ自体が目的化してしまっている。
全体としては普通に好きになりようが無い。個々人で友達はいてもね。
Can you fix this image to another?
This image looks like Rising Sun flag,which is as similar as War Criminals' https://t.co/8Aq24y0OJI you know what I'm saying? pic.twitter.com/PDWZXC1YxF— 동후 이 Idong Lee (@idonghu13) 2018年12月5日
765ASシンデレラのコロムビア、ミリオンSideMのランティスとレコード会社が分かれているせいで3シリーズ以上の楽曲に関わっている人ってそんなに多くないんじゃないか、ということでテーマ曲以外のシャニマス(ランティス)楽曲情報が出る前に調べてみた。
作詞・作曲家。シャニマスのテーマ曲でアイマス4シリーズ目。ただし765ASはぷちますのみなのでコロムビア楽曲は無し。
| ぷち | 「Princess Snow White」「ドキッ♥ラブアトラクション」「ねがいひとつ」(全て作編曲)など |
|---|---|
| ミリ | 「Blue Symphony」「Just be myself!!」「FAKE SELF×TRUE SELF」(全て作編曲)など |
| SideM | 「BRAND NEW FIELD」「スマイル・エンゲージ」「VICTORY BELIEVER」(全て作編曲) |
| シャニ | 「Spread the Wings!!」(作編曲) |
| 他代表曲 | 「SUPER∞STREAM」(IS)「ユメ語るよりユメ歌おう」(ラ!サンシャイン!!/共に作編曲)など |
作曲家。アイマスでは主にシンデレラ楽曲に多く携わっている。同じ事務所の作詞家・磯谷佳江、アレンジャー・玉木千尋とタッグを組んだ曲が多い。
| 765AS | 「おとなのはじまり」「We just started」(共に作曲)「コーヒー1杯のイマージュ」(作編曲) |
|---|---|
| デレ | 「OωOver!!」「純情Midnight伝説」「モーレツ★世直しギルティ!」(全て作曲)など |
| ミリ | 「ビギナーズ☆ストライク」(作曲) |
| SideM | 「Sweep Your Gloom」「…掲げよう、偽りなき自分を。」「PRECIOUS TONE」(全て作曲) |
| 他代表曲 | 「Tinkling Smile」(ヤマノススメ)「Ring Ring Rainbow!!」(城下町のダンデライオン/共に作曲)など |
アレンジャー。たまに作詞曲も手掛ける。アイマス参加は全て小野貴光楽曲のアレンジだが、765AS楽曲には関わっていない。
| デレ | 小野貴光と担当パート(編曲)以外同一なので省略 |
|---|---|
| ミリ | 同上 |
| SideM | 同上 |
| 他代表曲 | 「Butter-Fly ～tri.Version～」(デジモンtri.)「白く咲く花」(小倉唯/共に編曲)など |
作詞・作曲家、バンナム社員。本家とデレではだいたいぶっとんだ曲担当。ミリではサウンドディレクターを務め、歴代のテーマソングを手掛けている。
| 765AS | 「待ち受けプリンス」(作詞・作編曲)「ザ・ライブ革命でSHOW!」「ToP!!!!!!!!!!!!!」(共に作編曲)など |
|---|---|
| デレ | 「あんずのうた」「おねだりShall We～?」「みんなのきもち」(全て作詞・作編曲)など |
| ミリ | 「Thank You!」「Welcome!!」(共に作編曲)「Brand New Theater!」(作曲)など |
| 他代表曲 | 「ミーナのおやしき」(太鼓の達人/作詞・作編曲)「マオウのショウタイム」(太鼓の達人/歌唱・作詞・作編曲)など |
作詞家、元バンナム社員。退社後もアイマス楽曲に関わっている。アイマス以外では「オノダヒロユキ」名義で活動。
| 765AS | 「ポジティブ!」「relations」「Do-Dai」など |
|---|---|
| デレ | 「熱血乙女A」「Dreaming of you」 |
| ミリ | 「合言葉はスタートアップ!」「Growing Storm!」 |
| 他代表曲 | 「ブライトファンタジー」(プリパラ)「薄紅デイトリッパー」(アイカツ!)など |
作詞・作曲家、バンナム社員。多くのナムコ、バンナム作品に関わる。
| 765AS | 「静かな夜に願いを…」「Happy!」(共に作詞) |
|---|---|
| デレ | 「恋のHamburg♪」(作詞曲) |
| SideM | 「DRIVE A LIVE」(作詞曲)「Beyond The Dream」(作詞) |
| 他代表曲 | 「Stepping Wind」(風のクロノア2)「おもちでマンボ」(太鼓の達人/共に作曲)など |
作詞・作曲家。近年は「輪るピングドラム」「おそ松さん」など劇伴方面での活躍も多い。
| 765AS | 「風花」(作詞・作編曲)「KisS」(作編曲)「マリオネットの心」(作曲)など |
|---|---|
| デレ | 「To my darling…」(編曲)「lilac time」(作詞・作編曲)など |
| ミリ | 「POKER POKER」(作編曲) |
| 他代表曲 | 「Love Power」(おとボク)「ブックマーク ア・ヘッド」(ストライクウィッチーズ/共に作編曲)など |
| 765AS | 「太陽のジェラシー」「蒼い鳥」「約束」など |
|---|---|
| デレ | 「Star!!」「Shine!!」「M@GIC☆」など |
| ミリ | 「Snow White」「永遠の花」「地球儀にない国」 |
| 他代表曲 | 「魔訶不思議アドベンチャー!」(ドラゴンボール)「そのままの君でいて」(パトレイバー)など |
| 765AS | 「9:02pm(REM@STER-B)」「GO MY WAY!!(REM@STER-B)」(共に編曲)「咲きませ!!乙女塾」(作編曲) |
|---|---|
| デレ | 「私色ギフト」「流れ星キセキ」「生存本能ヴァルキュリア」(全て作編曲)など |
| ミリ | 「ふわりずむ」(作編曲) |
| 他代表曲 | 「めざせポケモンマスター」(ポケモン)「Butter-Fly」(デジモン/共に編曲)など |
作曲家。主にシンデレラ曲担当。佐久間まゆ役の牧野由依は音大時代の友人。
| 765AS | 「久遠の河」「贈る言葉」(※共にカバー曲/編曲) |
|---|---|
| デレ | 「エヴリデイドリーム」「メッセージ」「Shine!!」(全て作編曲)など |
| SideM | 「DRIVE A LIVE」(編曲) |
| 他代表曲 | 「Reset」(サクラダリセット/作編曲)「ギュンとラブソング」(SUPER LOVER 2/編曲)など |
| ゼノ | 「残酷よ希望となれ」(歌唱) |
|---|---|
| ミリ | 「FAKE SELF×TRUE SELF」「創造は始まりの風を連れて」「FairyTaleじゃいられない」(全て作詞)など |
| SideM | 「HIGH JUMP NO LIMIT」「夢色VOYAGER」「MOON NIGHTのせいにして」(全て作詞)など |
| 他代表曲 | 「SECRET NIGHT」(アイナナ)「PLEASURE FLAG」(ドリフェス!/共に作詞)など、他歌手としても多数 |
学習してから３日目ぐらいだけど連続３日でやったとは言っていない。
他のプログラミング言語と違ってチュートリアルの内容が足りないってこともなさそうだし、Golangのチュートリアルだけは繰り返しやったほうが良さそう。
今からGolangを学ぶならGoogleのリポジトリにあるパッケージ管理にdepを使うほうが安心する。
まだ公式ツールじゃないけど将来なるかもしれないしならないかもしれない。
Googleのことだからgxuiみたいに更新されなくなる危険もあるよな・・・・
でもプロジェクトを新規作成するときにrails new helloに相当するコマンドがないので不便。
スケルトン生成ツールが別途必要だけどフォルダ作るだけだからbatファイル用意するだけで良さそう。
あとGOPATHの設定もか。今のところは手動でやってるけどそのうちbatファイルにしたい。
でもやりたいことができないのがつらい。
cursesぐらいは標準で出来て欲しいよ。
だから他の言語ではいらないのにGolangではそんなことでもライブラリを探してきてインストールしないといけない。
Goglandだとそのままでも十分だけどVimの場合はvim-goを入れるのが良い。
勉強会に参加するときは軽量ノートを持っていくので動作が軽いVimがいい。
でもryzen搭載ノートが来たらIDEに乗り換えるかもしれない。
cliってライブラリもあるみたいだけど標準機能のflagだけで十分便利。
今の所もあんまりコマンドラインツールに興味ないので難しいことはしない。
やりたいことをぐぐってコピペしてる程度なのでdeferとかgo funcとかグローバル変数とか基礎的な部分はまだ知らない。
インストールが楽だけどWindows作ったらMacでも動くかは謎。
MacのハードウェアにしかMacのOSインストールできないライセンスだからWindows PCにMacインストールできないからapple嫌い。
あのレインボーカラーは、LGBT活動家であることを示す意味合いがあるんですよ。
https://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%A4%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%95%E3%83%A9%E3%83%83%E3%82%B0_(LGBT)
レインボーフラッグ (英語: rainbow flag, pride flag, LGBT pride flag, gay pride flag) はレズビアン、ゲイ、バイセクシャル、
トランスジェンダー (LGBT) の尊厳と LGBTの社会運動を象徴する旗。1970年代から使用された。
フラッグに使われた色は LGBTコミュニティの多様性を表し、LGBT の権利パレードの一種ゲイ・パレード（プライド・パレード）でしばしば見られる。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
俺も前カンマ派だな。
大体末尾に新たなカラムを追加するってケースが多いけど、前カンマ式が行の追加で済むのに対し、後カンマは末尾の行にカンマ追加＋新行追加しなきゃいけないんだよね。
SELECT ID ,NAME ,ADDRESS ,TEL ,MEMO -- 2013-11-09 ADD ,FLAG -- 2014-11-09 ADD FROM CUSTOMER WHERE TEL LIKE '03%'
SELECT ID, NAME, ADDRESS, TEL, -- 2013-11-09 FIX MEMO, -- 2013-11-09 ADD -- 2014-11-09 FIX FLAG -- 2014-11-09 ADD FROM CUSTOMER WHERE TEL LIKE '03%'
PHP最新版がようやく正式に発表されましたね。新機能等について調べてみたので流行に敏感な人はぜひ今のうちから勉強しておきましょう。
「?>」を積極的に使うことにより、余計なホワイトスペースを混入させてしまう問題がありました。
これは厄介で非常に根が深い問題でしたが、ようやく根本解決として廃止されました。素晴らしいですね。
今後「?>」を使うとコンパイルエラーとなるので注意が必要です。
昨今抽象化抽象化と特に意味もわからず言葉だけ連呼する人間が増えてきました。しかし新PHP時代における抽象化はもはや人間が理解しなくてもできるようになります。
$class = abstract { $人間 = array('name' => 'yamada', 'age' => 20); $佐藤 = array('age' => 20); $動物->name = '花子'; $動物->type = '犬'; function move ($a) { $a->position++; } }; $class->move();
このような処理が、自動で抽象化され再利用できるようになります。もちろんクラス抽象化だけでなく、手続きやデータ構造であっても適切に自動で抽象化されます。
またcatch文を繋げる事で抽象化に失敗した場合を検出することが可能です。
php実行時オプションに強力な型チェックオプション(-compile)が追加されました。
$ php -compile example.php
そのスクリプトにおける全ての処理パターンを実行し、全ての型のチェックを自動で行います。その際、外部に影響を与えるような処理(ファイルへの保存等)は型チェックのみを行い無視されます。
この強力な機能のおかげでもはや静的言語の利点といわれていたコンパイル時の型チェックを軽く超えました。
動的言語でありながら、考えられる全ての型の引数、例外系を全ての関数の組み合わせで網羅的にチェックします（しかもチェック時間は長くても0.数秒という驚異的なチェック能力です！）
これが今回の目玉機能でしょう。
theworld {
// 止まった時間の中を動けるのは$dioだけ
$dio->foo();
$dio->bar();
};
$dioという特殊変数が用意されているのでその変数を使って処理をすることができます。
用途としては非常に重たい処理をさせるのがいいでしょう。実時間0秒で実行することが可能となります。
ただし9秒までしか止められないので注意が必要です。ですが回避策として以下のようにすれば追加で5秒止めることも可能です。
theworld {
$dio->foo();
$dio->bar();
}
starplatinum {
// 9秒過ぎた時点でこちらへ
$jotaro->foo();
};
名前空間(namespace)が非推奨になりました。これを使用するとE_NAMESPACE_YEN_ARIEHENという警告が発生します。
非推奨となった理由ですが明確にはされていません。大人の事情ってやつでしょう。
ただ噂レベルでは、やはりというか区切り文字の「\」がありえへんという声が多かったからではないか？と一部囁かれています。
mandomキーワードが非推奨になりました。mandomはきっかり6秒戻すという機能ですが、逆に言うと6秒きっかりしか戻せないので扱いづらいという問題がありました。
また以下のような処理を書いた場合に$flagがバグ等で常に真になるケースにおいて無限ループとなり、非常に危険だという問題もあります。
// 何かしらの処理・・・ if ( $flag ) { mandom; }
このようにPHP初心者がmandom使って無限ループをさせてしまう事案が後を絶たず、なかなか現実時間が進まないという問題が発生したため、廃止予定となります。
$mail = google_search_exec("メール送信するやつ",2); $mail("user@example.com");
第一引数は検索ワード。PHPというワードは自動で含まれるので指定する必要はありません。
第二引数は検索結果一覧の指定位置。2だと上から二つ目の検索結果のURLのコード小片を使うという意味になります。
また第三引数にはコールバック関数を指定することによりコード小片にフィルターをかけることも可能です。
このような処理がたった2行で書けるというのがPHPの利点ですね。
日本語名の関数が新たに追加されました。これは非常に便利な関数です。
$code = 写経(" $a = 1 + 2; print $a; ");
引数に与えられたコード片を写経します。戻り値に写経結果が返ってくるのでそれを利用するだけです。簡単ですね。
この関数が呼ばれると一瞬処理が止まったように見えますが、実際には自動補完で動作が完了している状態になります。
for($i=0;$i<10000;$i++) {
if ( $i % 2 == 0 ) {
chronostasis();
}
// 何かしらの処理・・・
}
素晴らしい機能ですね。今後はこれ無しじゃプログラムできなさそうです。
用途ですが、言わずもがな今流行の真契約プログラミング用ですね。アサートの代わりに使うとよいです。
function foo ($a) {
pc_explosion(!is_null($a),'$aはNULLはダメー！');
// 何かしらの処理・・・
}
テストコードを実行する場合はPCの周囲に人が居ないか気をつけてから実行させましょう。
個人的に良いなと思ったのはpc_explosion関数ですかね。約束事を守らないプログラマーなんぞ爆死しちゃえばいいんです。僕を含めて（お
プログラムはclassに記述します。たとえばSampleという名前のclassを作る場合、Sample.csファイル内に次のように書きます。(C#の場合、ファイル名とクラス名は同一でなくても良い。複数のクラスを書いても良い)
public class Sample { }
プログラムはclass内のMainメソッドの先頭から実行されます。Mainメソッドは次のように書きます。
public class Sample { public static void Main( String[] args ) { // 処理を書く } }
Console.WriteLine( "Hello world" );
コメントです。
// 一行コメント /* 複数行コメント */
// 変数 int num;
データ型です。C#のデータ型には値型と参照型とがあります。以下は値型のデータ型です。
// int(整数)型 int num; // char(文字)型 char c; // float(単精度浮動小数点)型 float val; // double(倍精度浮動小数点)型 double val; // bool(論理)型 bool flag; // DateTime(日付)型 DateTime date;
以下は参照型のデータ型です。
// String型 String s; // 配列型 String[] array;
プログラムをコンパイルするには、コマンドラインで以下のようにします。
csc Sample.cs
プログラムを実行するには、コマンドラインで以下のようにします。
Sample.exe
mono ./Sample.exe
int、float、double型の変数に数値を代入できます。int型には整数だけ代入できます。float、double型には整数でも小数でも代入できます。
int i = 2; int i = 100000000; float num = 1.234f; double num = 1.234;
四則演算です。
num = 1 + 1; num = 1 - 1; num = 1 * 2; num = 1 / 2;
商の求め方です。割る数と割られる数が両方とも整数の場合、計算結果の小数点以下が切り捨てられます。
num = 1 / 2; // 0
割る数と割られる数のどちらかが小数の場合、計算結果の小数点以下が切り捨てられません。
num = 1.0 / 2; // 0.5 num = 1 / 2.0; // 0.5 num = 1.0 / 2.0; // 0.5
余りの求め方です。
// 余り mod = 4 % 2
インクリメントとデクリメントです。
// インクリメント ++i; // デクリメント --i;
String str = "abc";
// 結合 String join = "aaa" + "bbb"; // 分割 String[] record = "aaa,bbb,ccc".Split( "," ); // 長さ int length = "abcdef".Length(); // 切り出し "abcd".Substring( 0, 2 ) // abc // 検索 int result = "abcd".IndexOf( "cd" ) // 見つかった場合はその位置、見つからなかった場合は-1が返る
配列です。
// 配列の宣言 int[] array;
配列の生成です。配列の生成時には要素数を指定するか、初期データを指定します。
int[] array; // 要素数を指定して配列を生成 array = new int[5]; // 初期データを指定して配列を生成 array = new int[] { 1, 2, 3 }; // 宣言と同時に配列を生成 int[] array2 = new int[5];
配列の要素の参照と代入です。
// 要素の参照 array[0] array[1] // 要素の代入 array[0] = 1; array[1] = 2;
array_num = array.Length;
int[] from = new int[] { 1, 2, 3 };
int[] to = new int[5];
from.CopyTo(to, 0);
if文です。
if ( 条件 )
{
}
if ～ else文です。
if ( 条件 )
{
}
else
{
}
if ～ else if文です。
if ( 条件 )
{
}
else if ( 条件 )
{
}
while文です。
int i = 0; while ( i < 5 ) { // 処理 ++i; }
for文です。
for ( int i = 0; i < 5; ++i ) { // 処理 }
int[] fields = new int[] { 1, 2, 3 }; foreach (int field in fields) { // 処理 }
C#では関数をメソッドと言います。メソッドを作るには次のようにします。戻り値を返却するにはreturn文を使います。
static int sum( int num1, int num2 )
{
int total;
total = num1 + num2;
return total;
}
ファイル入出力です。ファイル入出力を行うには、プログラムの先頭に以下を記述します。
using System.IO;
以下がファイル入力の雛形になります。ファイルのオープンや読み込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamReader reader = null; try { reader = new StreamReader(filename); String line; while ((line = reader.ReadLine()) != null) { } } catch (IOException e) { // エラー処理: } finally { if (reader != null) { try { reader.Close(); } catch (IOException e) { } } }
またはC#ではusing ステートメントと言うものがあり、この様にも書ける
String filename = "text.txt"; using (StreamReader reader = new StreamReader(filename)) { try { String line; while ((line = reader.ReadLine()) != null) { // 読み込んだ行を処理 } } catch (IOException e) { // エラー処理: } }
usingをつかうとCloseがなくなったことからわかるようにusing(){}を抜けるときに自動的にDisposeメソッドを呼び出し、オブジェクトを廃棄する。その分コードがスッキリするが、使いにくい場面もあるので考えて使うこと。
以下がファイル出力の雛形になります。ファイルのオープンや書き込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamWriter writer = null; try { writer = new StreamWriter(filename)); writer.WriteLine("abc"); writer.WriteLine("def"); writer.WriteLine("fgh"); } catch (IOException e) { // エラー処理: } finally { if (writer != null) { writer.Close(); } }
こちらもusingを使って書ける。が、割愛する。
C#でよく出てくる知っておいたほうがよい文法の一覧です。
繰り返し文の途中で抜けるにはbreak文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { break; // 条件を満たす場合、for文を抜ける。 } }
残りの部分処理をスキップし、次の繰り返しに進むにはcontinue文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { continue; // 条件を満たす場合、残りの部分処理をスキップし、次の繰り返しに進む。 } }
例外を投げるにはthrow文を使用します。
throw new Exception( "Error messsage" );
try { // 例外が発生する可能性のある処理 } catch ( Exception e ) { // 例外発生時の処理 }
やー。面倒でした。
古い情報だと Outlook Express を経由しろと書いてあるので、後継であるらしいWindows Live Mail を経由して（Windows Live Mail からエクスポートする方法で）
Outlook に移行したのだが、どういうわけか宛名が文字列として移行されてしまい、xxx@example.com というメールアドレスの移行ができなかったんです。
で eml → msg もしくは pst 形式への変換ソフトを探すのですが、無料のものが見つからなくてあんまり情報もありませんでした。が、ありましたよ！お兄さん。
====
MAPI data collection and parsing tool. Supports property tag lookup, error translation, smart view processing, rule tables, ACL tables, contents tables, and MAPI<->MIME conversion. MrMAPI currently knows: 3916 property tags 801 dispids 35 types 58 guids 148 errors 27 smart view parsers Usage: MrMAPI -? MrMAPI [-Search] [-Dispids] [-Number] [-Type <type>] <property number>|<property name> MrMAPI -Guids MrMAPI -Error <error> MrMAPI -ParserType <type> -Input <input file> [-Binary] [-Output <output file>] MrMAPI -Flag <flag value> [-Dispids] [-Number] <property number>|<property name> MrMAPI -Rules [-Profile <profile>] [-Folder <folder>] MrMAPI -Acl [-Profile <profile>] [-Folder <folder>] MrMAPI [-Contents | -HiddenContents] [-Profile <profile>] [-Folder <folder>] [-Output <output directory>] [-Subject <subject>] [-MessageClass <message class>] [-MSG] [-List] MrMAPI -ChildFolders [-Profile <profile>] [-Folder <folder>] MrMAPI -XML -Input <path to input file> -Output <path to output file> MrMAPI -FID [fid] [-MID [mid]] [-Profile <profile>] MrMAPI -MAPI | -MIME -Input <path to input file> -Output <path to output file> [-CCSFFlags <conversion flags>] [-RFC822] [-Wrap <Decimal number of characters>] [-Encoding <Decimal number indicating encoding>] [-AddressBook] [-Unicode] [-Charset CodePage CharSetType CharSetApplyType] All switches may be shortened if the intended switch is unambiguous. For example, -T may be used instead of -Type. Help: -? Display expanded help. Property Tag Lookup: -S (or -Search) Perform substring search. With no parameters prints all known properties. -D (or -Dispids) Search dispids. -N (or -Number) Number is in decimal. Ignored for non-numbers. -T (or -Type) Print information on specified type. With no parameters prints list of known types. When combined with -S, restrict output to given type. -G (or -Guids) Display list of known guids. Flag Lookup: -Fl (or -Flag) Look up flags for specified property. May be combined with -D and -N switches, but all flag values must be in hex. Error Parsing: -E (or -Error) Map an error code to its name and vice versa. May be combined with -S and -N switches. Smart View Parsing: -P (or -ParserType) Parser type (number). See list below for supported parsers. -B (or -Binary) Input file is binary. Default is hex encoded text. Rules Table: -R (or -Rules) Output rules table. Profile optional. ACL Table: -A (or -Acl) Output ACL table. Profile optional. Contents Table: -C (or -Contents) Output contents table. May be combined with -H. Profile optional. -H (or -HiddenContents) Output associated contents table. May be combined with -C. Profile optional -Su (or -Subject) Subject of messages to output. -Me (or -MessageClass) Message class of messages to output. -Ms (or -MSG) Output as .MSG instead of XML. -L (or -List) List details to screen and do not output files. Child Folders: -Chi (or -ChildFolders) Display child folders of selected folder. MSG File Properties -X (or -XML) Output properties of an MSG file as XML. MID/FID Lookup -Fi (or -FID) Folder ID (FID) to search for. If -FID is specified without a FID, search/display all folders -Mid (or -MID) Message ID (MID) to search for. If -MID is specified without a MID, display all messages in folders specified by the FID parameter. MAPI <-> MIME Conversion: -Ma (or -MAPI) Convert an EML file to MAPI format (MSG file). -Mi (or -MIME) Convert an MSG file to MIME format (EML file). -I (or -Input) Indicates the input file for conversion, either a MIME-formatted EML file or an MSG file. -O (or -Output) Indicates the output file for the convertion. -Cc (or -CCSFFlags) Indicates specific flags to pass to the converter. Available values (these may be OR'ed together): MIME -> MAPI: CCSF_SMTP: 0x02 CCSF_INCLUDE_BCC: 0x20 CCSF_USE_RTF: 0x80 MAPI -> MIME: CCSF_NOHEADERS: 0x0004 CCSF_USE_TNEF: 0x0010 CCSF_8BITHEADERS: 0x0040 CCSF_PLAIN_TEXT_ONLY: 0x1000 CCSF_NO_MSGID: 0x4000 CCSF_EMBEDDED_MESSAGE: 0x8000 -Rf (or -RFC822) (MAPI->MIME only) Indicates the EML should be generated in RFC822 format. If not present, RFC1521 is used instead. -W (or -Wrap) (MAPI->MIME only) Indicates the maximum number of characters in each line in the generated EML. Default value is 74. A value of 0 indicates no wrapping. -En (or -Encoding) (MAPI->MIME only) Indicates the encoding type to use. Supported values are: 1 - Base64 2 - UUENCODE 3 - Quoted-Printable 4 - 7bit (DEFAULT) 5 - 8bit -Ad (or -AddressBook) Pass MAPI Address Book into converter. Profile optional. -U (or -Unicode) (MIME->MAPI only) The resulting MSG file should be unicode. -Ch (or -Charset) (MIME->MAPI only) Character set - three required parameters: CodePage - common values (others supported) 1252 - CP_USASCII - Indicates the USASCII character set, Windows code page 1252 1200 - CP_UNICODE - Indicates the Unicode character set, Windows code page 1200 50932 - CP_JAUTODETECT - Indicates Japanese auto-detect (50932) 50949 - CP_KAUTODETECT - Indicates Korean auto-detect (50949) 50221 - CP_ISO2022JPESC - Indicates the Internet character set ISO-2022-JP-ESC 50222 - CP_ISO2022JPSIO - Indicates the Internet character set ISO-2022-JP-SIO CharSetType - supported values (see CHARSETTYPE) 0 - CHARSET_BODY 1 - CHARSET_HEADER 2 - CHARSET_WEB CharSetApplyType - supported values (see CSETAPPLYTYPE) 0 - CSET_APPLY_UNTAGGED 1 - CSET_APPLY_ALL 2 - CSET_APPLY_TAG_ALL Universal Options: -I (or -Input) Input file. -O (or -Output) Output file or directory. -F (or -Folder) Folder to scan. Default is Inbox. See list below for supported folders. Folders may also be specified by path: "Top of Information Store\Calendar" Path may be preceeded by entry IDs for special folders using @ notation: "@PR_IPM_SUBTREE_ENTRYID\Calendar" MrMAPI's special folder constants may also be used: "@12\Calendar" "@1" -Pr (or -Profile) Profile for MAPILogonEx. -M (or -MoreProperties) More properties. Tries harder to get stream properties. May take longer. -No (or -NoAddins) No Addins. Don't load any add-ins. -On (or -Online) Online mode. Bypass cached mode. -V (or -Verbose) Verbose. Turn on all debug output. Smart View Parsers: 1 Additional Ren Entry IDs Ex 2 Appointment Recurrence Pattern 3 Conversation Index 4 Entry Id 5 Entry List 6 Extended Folder Flags 7 Extended Rule Condition 8 Flat Entry List 9 Folder User Fields Stream 10 Global Object Id 11 Property 12 Property Definition Stream 13 Recipient Row Stream 14 Recurrence Pattern 15 Report Tag 16 Restriction 17 Rule Condition 18 Search Folder Definition 19 Security Descriptor 20 SID 21 Task Assigners 22 Time Zone 23 Time Zone Definition 24 Web View Persistence Object Stream 25 Nickname Cache 26 Encode Entry ID 27 Decode Entry ID Folders: 1 Calendar 2 Contacts 3 Journal 4 Notes 5 Tasks 6 Reminders 7 Drafts 8 Sent Items 9 Outbox 10 Deleted Items 11 Finder 12 IPM_SUBTREE 13 Inbox 14 Local Freebusy 15 Conflicts 16 Sync Issues 17 Local Failures 18 Server Failures 19 Junk E-mail Examples: MrMAPI PR_DISPLAY_NAME MrMAPI 0x3001001e MrMAPI 3001001e MrMAPI 3001 MrMAPI -n 12289 MrMAPI -t PT_LONG MrMAPI -t 3102 MrMAPI -t MrMAPI -s display MrMAPI -s display -t PT_LONG MrMAPI -t 102 -s display MrMAPI -d dispidReminderTime MrMAPI -d 0x8502 MrMAPI -d -s reminder MrMAPI -d -n 34050 MrMAPI -p 17 -i webview.txt -o parsed.txt
http://anond.hatelabo.jp/20070508170219
もっと上手いやり方があるんだろうなぁ。
$i3=1; $i5=1; $flag=0; for($n=1;$n＜101;$n++){ if($i3==3 ＆＆ $i5==5){ echo "FizzBuzz￥n"; $i3=1; $i5=1; }else{ if($i3==3){ echo "Fizz￥n"; $i3=1; $flag=1; }else{ $i3++; } if($i5==5){ echo "Buzz￥n"; $i5=1; $flag = 1; }else{ $i5++; } if($flag==0){ echo $n."￥n"; } $flag = 0; } }
※一部全角化（＆￥＜）
http://1-byte.jp/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer/
良いPHPerだって？そんなものは丸めてゴミ箱にでも捨ててしまった方が資源の再利用になる分いくらかマシだ。
つまり俺たちがしなくちゃならないことは「より良いPHPerにならないため」に何ができるかってことなのさ。
それじゃ、始めよう。
?>なんて使っちゃいけない。そう俺たちはBAD PHPer。
無駄なホワイトスペースの出力に悩まされるくらいなら対称性なんて丸めてゴミ箱にでも捨てた方がまだマシだ。非対称性こそが賛美。
require_once("config.php");
未だにこんなことやってるやつがいるのかいベイベー。絶対にダメだ。この一行を見たら俺は悶絶する。
ダメだ、早く何とかしないと。
大抵このconfig.phpの中身はこうなっている。見て絶望だ。
$hoge_path = ''; if (!LOCAL) { define('FOO_FLAG', 1); if (HONBAN) { define('HOGE_FLAG', 1); } else if (TEST) { define('HOGE_FLAG', 2); } } else { $hoge_path = '/local'; define('FOO_FLAG', 2); define('HOGE_FLAG', 3); } define('HOGE_URL', $hoge_path.'/hoge/');
こういうのが延々と続くわけだ。もういやだ。もう見たくない。
本番環境とテスト環境でどういう値の違いがあるのか、ローカル環境だとどうなるのか、まったく把握できる気がしない。
なまじPHPな設定ファイルのせいで、処理をついつい書いてしまう。そしてどんどん複雑になってしまう。
やはり設定データは基本的にYAML等のデータしか定義できない形式のもので用意すべきだ。そして環境ごとに設定ファイルを分けるべきである。
そうすることで何にどういう違いがあるのかすぐにわかるし、diffすれば一度にすべて把握することができる。
# 本番環境設定ファイル foo_flag: 1 hoge_flag: 1 hoge_url: '/hoge/'
# テスト環境設定ファイル foo_flag: 1 hoge_flag: 2 hoge_url: '/hoge/'
# ローカル環境設定ファイル foo_flag: 2 hoge_flag: 3 hoge_url: '/local/hoge/'
// ここで後の処理のためにhogeメソッドを呼び出しておく $q->foo(); // $a['foo']はここに来る時点で真のはず // 2010-03-10 判定がおかしいので修正 // 2010-06-21 やっぱり値が入ってる方が正しい if ( !isset($hoge[0]) ) { }
コメントは保守されない。そう、それは真実。こんなコメントを発見したら即効削除しよう。コメントは基本信じるな。
俺たちにちょっとしたヒントと大きな損害を与えてくれる、それがコメントの役割なのだ。
わかる。いいたい事はとてもわかる。俺たちはしばしばインデントにスペースを使うはずだ。一方でIDEのしっかりした言語ではタブも使うことがある。しかし悪いことに、両者を混同しているプログラマも一定数いるのだ。
タブを画面上で認識しにくいエディタが世の中には存在する（何とは言わないが）
そして画面上で認識しにくいことを理由にタブを気にしないプログラマがいる。
この二つの条件が重なると、タブとスペースの交じり合ったインデントが完成する。もうぐちゃぐちゃだ。これは永遠に続く戦いだ。
私たちが勝利を掴むためにできることなどせいぜい、常にスペースしか使わない。タブを見つけたらその都度スペースに変換する。そういった地道な活動が明日へとつながるのだ。
われわれがプログラムをするとき、何に一番時間がかかってるか。実は変数の命名なのである。ここで拘り過ぎて時間をかけ過ぎては何も進まない。
御託はイイからさっさと書け、だ。しかしとはいっても変数名は重要。日頃からどういうときにどんな名前を使うかを決めておくといい。
そして変数名に型はまったく必要ない。型宣言のないPHPにおいて、型の変数名をつけること自体ナンセンスだ。
$iNumber = 'aaa';
になんの意味もない。コメントを信じるなでも言ったが、これはプログラマを混乱させるだけの害悪なものだ。
変数を使う前に初期化するのは、警告を出さないという意味でも良い癖だ。しかし具体的にどこでやるかが問題だ。
$foo = null; $foo = $q->foo();
こんな初期化に意味はない。よくあるのはやはり、if文で値を振り分けるケースだろう
$foo = null; if ( $hoge ) { $foo = 1; } else if ( $bar ) { $foo = 2; }
このときの初期化はとても有効だ。もしnullの初期化を忘れたまま$fooを使うと警告が出るが、ちゃんと初期化してるので出ない。基本中の基本だ。
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; return $bReturn; }(中略)
もし、何かしらの理由で、あなたの書いたif文が間違っていたら？
この書き方をしていれば、間違った値に対して、常にfalseが返る。
私たちが、PHPでsensitiveなデータを取り扱うなら、正しいデータが入力されるまでは、動かないコードを書くべきだ。
trueとfalseの条件がいまいち明確ではないが、本当に動かないコードを書けというのであれば以下のようにすべきだ
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; else if ($i == 1) $bReturn = false; else throw new Exception("bad status! $i"); return $bReturn; }
中途半端にfalseを返して生存させる必要性はまったくない。今すぐ死ね！
連想配列のキーを指定する場合だけ定数と間違わないようにクオートで囲まなければならない。そして逆に定数を使いたい場合はクオートで囲ってはいけない。
更に後世のプログラマが処理を見たときに、定数が使いたかったのか、文字列が使いたかったのかを明確にしたい場合はconstantを使うと良い。
// 定数のFOOを使うよということが明確になる print $a[constant('FOO')];
もし、文字列を変数の値と一緒に出力するとき、PHPではコンマの代わりにprintfを使うことが使える。
printf( “Hello, my name is %s“, $sName);
以下の代わりに上記のコードを使う。
echo “Hello, my name is “, $sName;
出力すべき変数が増えれば増えるほど、有効になっていく。とにかく迷ったならば、printfを使え、だ。
三項演算子はとても有効だ。しかし優先順位に難があるせいで、三項演算子をネストしようとすると以下のようなコードになってしまう
$n = (($i == 1) ? 2 : (($i == 2) ? 3 :$i));
括弧だらけで読みにくいったらありゃしない。三項演算子を使うなら一回まで。約束守れないやつは丸めてゴミ箱にでも捨てちまえ。
if ( $flag ) { }
仕様をちゃんと把握しているなら真偽値のチェックなどこれで十分。
もし事前にbool型だというのが確定してるのなら「$flag === true」を使えばいい。
インクリメント、デクリメント演算子は前に付くか後ろに付くかで意味が変わるので慣れるまでは非常にややこしい。
わけがわからなくなるくらいなら初めから使わないほうが良い。見極められないなら使うな。それがPHPerなのだ。
文句なしだ。これは文句がない。
他にも色々あるので覚えておこう
$a %= 1; $a &= 1; $a |= 1; $a ^= 1; $a <<= 1; $a >>= 1;
てっとり早く画面に表示する際にpreはよく使うが、デザインの関係上画面の文字が見えないときがある。
なのでdivを使って以下のようにしとくと便利だろう。
function p($var) {
echo "<div align='left' style='background-color:white;color:black;'><pre>";
print_r($var);
echo "</pre></div>";
}
君らが通常作るアプリケーションなんぞに、定数なんぞ必要ない。いいか、もう一度言う、お前ら程度のもんが、定数使おう何ぞ、おこがましいわ！
大丈夫。なんでもかんでも定数にする必要はない。結局設定ファイルに定数をずらずら作りまくってわけがわからなくなってるパターンが多い。
貴様みたいなもんに、定数は制御できん。いいか設定ファイルはYAML等のデータで持つようにし、その連想配列のデータ構造を一つ持ってるだけで定数の変わりになる。
このメリットに比べれば、定数だと書き換えられなくて良いという利点などこの歯のカスほどのものだ。そんなものは丸めてゴミ箱へ捨ててしまうといい。
認識を改めろ。俺たちはより良いPHPerにならないために努力している。
class Request { private $parameters; private $method; function __construct () { $this->method = $_SERVER['REQUEST_METHOD']; if ( strtoupper($this->method) === 'POST' ) { $this->parameters = $_POST; } else { $this->parameters = $_GET; } } function param ($key) { return isset($this->parameters[$key]) ? $this->parameters[$key] : null; } }
これだけでもいい。たったこれだけでもとても便利だ。ここから拡張してGETやPOSTを明示的に取るメソッドとかも作ってみるといい。自分の手を動かすのだ！
例が良くない。こんなのは引数が20個ある関数から、setを20回呼ぶオブジェクトに変わっただけではないか。
そもそもこの20個の引数とはなんなのか。何かのデータ構造なんであれば連想配列にして引数一つとして渡すべきだし、それぞれまったく異なる用途の変数なのであればWindowsプログラミングじゃあるまいし、20個も引数取る時点で設計が間違えている。
何がいいたいか。別に関数でもオブジェクトでもどっちでもいいということだ。
そんなことで悩んでる暇があったら設計を見直せ。
スキあらば自分自身を返せ。スキあらばオブジェクトを返せ。配列はArrayObjectのARRAY_AS_PROPSで返せ。
ひたすらメソッドチェイン。来る日も来る日もメソッドチェイン。とにかくメソッドチェインを使い続けろ。そこに未来はある。
どんなコードも繰り返すな。もし、少しでも同じコードを書いていたなら、それは関数に置き換えてしまえ。
・・・と、いうのはやめなさい。
一見同じように見えた処理でも前後の流れでまったく違うものということが往々にしてある。
まとめ方にも問題があるケースもある。何でもかんでも関数化すると、関数が膨大に増えていく。君は見たことがあるだろうか。common.phpやfunction.phpの恐ろしさを。
確かに細かく関数化はされているが、適切に関数化していないのである。結合度が非常に高い。なんでもかんでも盲目的にまとめれば良いという話ではないのだ！
あまりに極度に意識しすぎると、プログラムそのものができなくなる。そういう状態に陥る。
気を抜いて。そう気を抜いて。所詮あなたのコードなんてすぐに消えてなくなるよ。きっともっと偉い人が作り直すよ。だからまずは思うが侭にやるといい。
結合度を減らすというのは非常に難しい。何度も何度も失敗し続けて、ようやくここは分けた方が良かったんだなと気付く。次に活かそうと心に決める。そしてまた同じ過ちを繰り返していくわけだ。
まずは実装することだ。これが一番の早道だ。まずはがっつり結合した関数をあえて作るといい。何も考えずに作ろう。
そしてその後に、一部分使いまわしたいとおもうことがあるはずだ。その時に関数に切り出そう。それを繰り返すといい。そのうち初めから分けた方が良いと気付く。
何事も経験が必要である！経験を積まないプログラマは丸めてゴミ箱に捨ててしまえ。
さて、先の例で言うならば、私ならadd_result_outputという関数を作ってしまうだろう。だって、addとresultを連続して呼ぶのはめんどくさいんだもん。一連の流れをいつも使うのなら、その流れをやってくれる関数を作ればいいじゃないか。
function add_result_output ($iVar, $iVar2) { $r = add($iVar, $iVar2); echo result($r); }
もっと言えばクラス化してしまってもいいかもしれない。どんな感じになるかは君の手を動かして確認しよう！
このTipsはとてもわかりにくく、ニッチ過ぎる部分も多いかもしれない。
あくまでも「より良いPHPerにならないための20Tips」なのだ。
君はこの記事を鵜呑みにしてはならない。PHPをPHPと見抜けないPHPerはPHPを使うのは難しい。
もし、あなたがPHPプログラマなら、公式のPHPドキュメントはあなたのケツの穴を拭くための紙になるだろう。
私は、それぞれのセクションを眺めて、各関数でどんなことが出来るかなんぞ、歯クソのゴミ程に役に立たないとおもっている。動けばいい。はは。
あなたは、PHPで用意された既製関数で多くのことが実現できることに、（俺の仕事を減らすなと）驚くはずだ。
この記事があなたの役に立たない事を。
ふざけんな！
(1/3から) http://anond.hatelabo.jp/20090723033558
佐野：で、小田さん、ぼくね、オフコース時代からの曲、それから小田さんのソロ時代の曲、ずっと聞かせていただいて、ぼくなりに、あ、この詩はいいな、と思ったものを一曲選びまして、ね、スポークンワード・バージョン、メロディーなしでその詩をリーディングするっていうのを試してみたんです。
（小田和正の「the flag」（アルバム『個人主義』収録）の背景の説明）
佐野：どうですか？
小田：いやあ、人の詩みたいな。ちょっと自分が書いたっていう感じがしなかったですね。不思議なもんで。
佐野：そうですか。
佐野：そんなことないですよ。
小田：いやほんとに。
佐野：ぼくらつねに言葉に音楽がついているので、音楽と言葉を切り離すっていうのは普段はしないわけでね。こうして第三者が、ぼくのような他人が、詩だけ切り取って作者に見せるっていうのは、なかなか勇気のあることだったんです。しかられるんじゃないかって。
小田：いえいえいえ、すばらしかったです。てめえの詩が、ねえ、はなはだ横柄だけど、いやあ上手に読まれましたねえ（笑）
（会場笑）
佐野：ぼくね、もうものすごく聞きたいことなんだけど…、ソングライターを志したきっかけは、なんだったのか。
小田：そもそもは音楽が好きだったっていう。自分が曲をかくようにななるなんて思わなかったわけですからね。それでも音楽やりたいっていう。たぶんその、音楽がほんっとに好きだったんですね。
小田：それはもう数限りなくいるから…。絞れないですね。出会った音楽全て、っていう。
佐野：小田さんの世代だと…、ごく一般的ですけど、ビートルズ？
（ビートルズ「A Hard Day's Night」）
佐野：はい。
小田：ビートルズはねえ、もう何回も…、だからもうビートルズはもういいか、みたいな。今更ビートルズっていう…、おれらにはいつまでたってもビートルズがいるのね。すごいなと思うね。
小田：古典だね。すごくシンプルだし。シンプルだけどよく聞くとタダのシンプルじゃない。おれはビートルズを聞くと必ず思うことは、もちろん力はあったと思うけど、若者が中心となったっていうかなんかのグルーヴみたいのが、なんかの現象でうわーっとなってあそこに集まっちゃったんじゃないかなっていう気がするんだよね。
佐野：60年代の中盤。テレビメディアなんかが一般的になりましたから、あのビートルズの持っている楽しいグルーヴが、一気にこうメディアを通じて、全世界に広まって。
小田：その、力以上っていっちゃうとちょっと語弊があるけど、その以上のものがどんどんできちゃったんじゃないかっていう。しか思えないような曲がいっぱいあるもんね。
佐野：あー
佐野：でもやっぱり最初にかいた曲ってことで、何気ない愛着のようなものがるんじゃないですか？
小田：いや、それはね、その、どうやってかいていいかわかんないし、手がかりを何かに求めるしかないんじゃないかなって…。それで、ぼくはもうしつこく日記を書いていたんですよ。何年間ももう。休まずにかいて。そこになんかヒントはないかなっておもって。そうしてこうやって探しているうちに、ちょっと手がかりがあったんで、あこれいいんじゃないの、って。
小田：その後もなんか日記にネタが、って、でもそれ一曲だけだったですね（笑）
小田：「やってみようぜ」ってのが好きなんですね。
佐野：例えば、歌詞の中で何回ももう繰り返して、どうしても使ってしまう言葉、なんていうのは、ないですか？
小田：それはもうね、とっても風好きなんですよ。風がどうしたとか。
小田：風、多いですね（笑）風好きなんですよ風ね。風好きだから、「また風かよ」って言われても、ほんと平気なんだけども、まあやっぱりいろいろなんでもかんでもでてきてもあれだなと思って…。ほんとは全部風でもいいんだわ（笑）
（会場笑）
佐野：ずいぶんロマンティックですね。
小田：ちっちゃいときはほんとに野球の選手になりたかったですね。
佐野：どこのファンでした？
小田：ジャイアンツでしたね、やっぱり。でも、足もそんな速くないし、遠投もたいした事ないし。なんといってもやっぱりいちばん、挫折したいちばん大きな理由は硬式の野球部がなかった、っていうのが。軟式しかやったことがなかったんで、これじゃだめだろうなあ、と。
小田：音楽やっても、その、いつまでにかかなくちゃみたいなのがあるともうほんとに辛くて。まあみんなそうだと思うんですけどね。
佐野：締め切りでしょ？ ぼくもヤですね。
小田：ね。連載をかかえている漫画家っていうのはね、ぼくはね、いっつも漫画見てて思うんだけど、この人毎週大変だなーと思って。
佐野：でも、小田さんは、いついつまでにかいてくださいって言われれば必ず約束を守る、って。
佐野：そう聞いています。
小田：ぼくはね、期限とか守らなかったことないですね。
佐野：すばらしい。
小田：守る方ですか？
佐野：ぼくはね…
（会場笑）
佐野：（笑）ぼくはね、締め切りがあるとどうしてもそれがプレシャーになっちゃって、逆にこう、なんかね、集中できなくなってしまって。だから、できたら渡すから、って。
（会場笑）
小田：そうすると、でも、ねえ、組み立てようがないよねえ。
小田：じゃあその、詩なり曲、作り上げて、自分としちゃイマイチだなーと思いつつも出さざるをえない、だから出した、みたいなのはある？
佐野：ない。
小田：あ、ない？
佐野：アルバムの中で、12曲入れようって、で16曲くらい録って。で、アルバムに全部入れたいって言われても、この4曲は気に食わないのでアウトテイクにします、って、自分の入れたい曲だけを入れる。
小田：えらいね。
佐野：うん…。でも、後になって聞くと、そのアウトテイクになった曲がよかったりして、なんで入れなかったんだろうって。
小田：あぁー。
佐野：でも、そうだね、約束は…最初っからあんまり取りつけない。
小田：そうだよね。
佐野：はい。
（会場笑）