  |
はてなキーワード: 記法とは
３２歳、営業職です。
プログラムとかなんもわからんちんなのですが、アプリを作りたいと思いたちアプリを
作ってみました。
とりあえず、アプリのランキングを見ていると、エロ系がやっぱり強いと思って、エロは正義！の名の下に
簡単にアプリを作るために、まずは簡単に作れるフレームワークを探す所から始まります。
フレームワークってなんですか？
それはね、なんだかわからないけど、簡単につくれるようになるものなんですよ。
詳しくは、
外人「システムを作るときに、よく利用する機能とか、構造とか、予めあると便利だろ？
俺が作っといてやったよHAHAHAHAHA」
っていう感じのものだそうです。
プログラミングなんてわからんちんだけど、HTMLくらいは作れるよ！
そんなあなたにPhoneGap(http://phonegap.com/)ということで、
とりあえずPhoneGapを使って見ることに。
でも、実際使ってサンプルを作ったりしてみると、動くは動くんだけど、
色々やろうとすると、Web上にあるドキュメントが古いのか、PhoneGapが最近になって
突如バージョンがあがったせいか、書いてる通りにやってみてもできない。
とりあえずiPhone Developer登録は既に完了していたので、Xcodeをつかってやるぜ！
俺は赤の扉を選ぶぜ！と思ったがはてさてどうすりゃいいのか。
HTMLをプロジェクトに追加するのはドラッグ＆ドロップすれば完了だ。
その際にダイアログが出てくるので、"Create folder references for any added folders" を選択しておくと
元々のフォルダ構造とかが失われずそのまま追加できるのでいいぞ。
ほんでもって、UIViewControllerというのを作成する。
IBOutlet で UIWebView を利用するためのオブジェクト変数を用意しておいて、InterfaceBuilderから接続をする。
Files's Owner とかを右クリックして出てきた変数名と画面上についかしたUIWebViewをマウスでつなぎあわせれば
接続できるぞ。なんて簡単なんだ。
一番最初に行われる初期化の処理は viewDidLoad にでも書いておけばいいらしいのでここに書く。
UIWebViewはURLの書式になっていないと開けないようなので、それを調べることから始まる。
アプリ内に追加したリソースファイルは、アプリのデータに内皮されるらしい。
アプリが展開されるフォルダというのは、デバイスにより様々なのだが、そこから内皮されている
ファイルを取得するための処理というのがあるのでそれを利用する。
NSString *html_path = [[NSBundle mainBundle] pathForResource:@"index" ofType:@"html" inDirectory@"web"];
これでwebフォルダ内にあるindex.htmlファイルの絶対パスを教えてくれるというわけだ。
あとはこれを読みこませればOK。
[web loadRequest:[NSURLRequest requestWithURL:[NSURL fileURLWithPath:html_path]]];
NSURL というのがURL書式を記述するためのオブジェクトだと思っていただきたい。
ここではローカルファイルのパスを拾うため、 fileURLWithPath とするのがポイントだ。
file://nantarakantara/index.html みたいな書式になるんでしょうね。
なんだか色々理由はあるみたいなんですが、そうですかだめですか。
善は急げで、AndroidSDKとEclipseというものをダウンロード。
昔は色々設定が必要だったが、いまは開けば即使えるようになったらしい。便利便利。
こっちの場合も同じようなやつがあるんでしょう、ほらったWebViewこれを使えばいいらしい。
XCodeのときは、いかにもアプリの画面を作れば完成って感じだったけど、Androidの場合は
Layoutファイルというのを使わないといけないみたい。なんかこれはHTMLみたいな記法だな。。
どうなってんだかよくわかんないですけど、Layoutを作成して、WebViewを配置、
Androidの場合は、assetフォルダというのをつくってあげて、そこにHTMLファイルを
置けばいいらしいですよ。なるほどね。
WebViewでの開き方は、assetフォルダを直接開けばいいだけらしい。いえーい！
layoutに配置したWebViewをオブジェクト変数に呼び出して、、、
webView.loadUrl("file:///android_asset/web/index.html");
ひらいたーおっけーーーーーーー。
だけども、リンクを開くとブラウザが開いてしまうなあ。どうすればいいのこれは。
調べてみるとこうすればいいらしい。
webView.setWebViewClient(new WebViewClient(){
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
return false;
}
});
これで無事、WebView内で画面遷移するようになりました。
やっほー
そんで、なんとかつくりあげて、申請・・・
とかないんですね、公開したら公開されましたｗ
ていう感じで始めてつくってみたんで
よかったらダウンロードしてみて下さい！
https://play.google.com/store/apps/details?id=ff.appgroup.app001_hrenai
「プロテクトかけたアルゴリズムを実装したバージョンに差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。
動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアのリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。
だから、リバースエンジニアリングではいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。
この場合も同様だ。TwitterのGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。
OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。
HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))
ここで
である。
まずはこのあたりから攻めようと思った。SHA-1の計算にはいくつか特徴的な定数が使われるので、そこからSHA-1の計算に使われているであろう関数444190を特定する。この関数のエントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザで認証」ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。
CPU Disasm Address Hex dump Command Comments 00401311 |. 33F6 xor esi, esi 00401313 | 8D8C24 A40000 /lea ecx, [local.54] 0040131A |. 394C24 14 |cmp dword ptr ss:[local.90], ecx 0040131E |. 75 0E |jne short 0040132E 00401320 |. 3BF5 |cmp esi, ebp 00401322 |. 73 29 |jae short 0040134D 00401324 |. 0FB68434 A400 |movzx eax, byte ptr ss:[esi+esp+0A4] 0040132C |. EB 21 |jmp short 0040134F 0040132E | 3BF5 |cmp esi, ebp 00401330 |. 73 1B |jae short 0040134D 00401332 |. 8B5424 18 |mov edx, dword ptr ss:[local.89] 00401336 |. 52 |push edx ; /Arg1 = [LOCAL.89] 00401337 |. 8D8C24 FC0000 |lea ecx, [local.33] ; | 0040133E |. 8BD6 |mov edx, esi ; | 00401340 |. E8 CB4D0000 |call 00406110 ; \mofooter.00406110 00401345 |. 83C4 04 |add esp, 4 00401348 |. 0FB6C0 |movzx eax, al 0040134B |. EB 02 |jmp short 0040134F 0040134D | 33C0 |xor eax, eax 0040134F | 34 5C |xor al, 5C 00401351 |. 888434 B80000 |mov byte ptr ss:[esi+esp+0B8], al 00401358 |. 83C6 01 |add esi, 1 0040135B |. 83FE 40 |cmp esi, 40 0040135E |.^ 72 B3 \jb short 00401313 00401360 |. 895C24 3C mov dword ptr ss:[local.80], ebx
0040134F | 34 5C |xor al, 5C
が注意を引く。もしかしてこれはopadとのxorではないか?
00401351 |. 888434 B80000 |mov byte ptr ss:[esi+esp+0B8], al
はxorした結果を格納している。
先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。
Hex dump 64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F| 18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E| 05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C| 5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|
あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。
はてなは増田のスーパーpre記法で半角の＜＞が含まれていると投稿が出来ないのを早く直してください。
もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。
CPU Disasm Address Hex dump Command Comments 00401324 |. 8D4424 20 |lea eax, [local.102] 00401328 |. 50 |push eax ; /Arg1 = 00401329 |. E8 623A0400 |call 00444D90 ; \mofooter.00444D90
ここでeaxが指すメモリーを見ると以下のようになっている。
01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10| F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00| 40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57| 61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63| 79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36| 36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|
スワイプだけでフォルダー内の全ファイルを閲覧。すべてのファイルが横に並んでいる。[[参考:m>notes]]のように。
縦にファイルをつなげる。これはファイルのグループ化。これも[[参考:m>notes]]。親となるファイルに独自記法が書かれていればつながる。親子管理用のデータは持たない。（Dropboxなどで他端末にコピー、デスクトップアプリで開いた時に有効になるように相対パスでファイル指定）UI上は記法ではなくファイル選択（親を開いて子を選択・子を開いて親を選択。選択肢にはファイル名によるフィルタリングをしたい。できればファイル内容の全文検索でも。UIは統合できるはず）親を子にすれば子が孫になるように。見た目はリスト、でもデータ構造はツリー。
設定項目に「ホームフォルダー」。その外にも出られる。制限しない。戻れることが大事。
自動命名・自動保存。ファイル名がどうしても付けられないなら適当なファイル名で適当なところに残す。開きやすければいい。
アンドゥ。「キーロガーと併用して」で済ませるのもあり。
起動時のビュー（最小化から復帰した時除く）は設定可能。ビュー別にホームアイコンを作成することも可能に。
モーダルダイアログ排除。またはダイアログ外タップで閉じられるように。
アプリにカーソルキー不要。大きく表示するビューを用意。ダブルタップや長押しで切り替え。文字を打つときには戻るように。でもこれはAndroidに任せるべき。
カーソル位置が分かりにくい上に意図しない位置へ行くのでアンダーライン必須。でもアンダーラインよりも背景色を行ごと変更したほうが分かりやすい。背景に横罫画像も使える。
検索とキーワードハイライトを統合。検索キーワードは検索のたびに追加。検索キーワードの目次生成。置き換えでも追加。置き換えた箇所が強調表示になる。自動的に追加されるハイライトの色はモノトーン。追加されるたびに古い強調表示は弱くなる。操作で別の色に変更できればいい。強調箇所は独自形式のデータにするしかない。どうせ他のアプリでは再生できないのでこのアプリ専用データ。
[[ファイル名（拡張子不要）]]でリンク。最初の「.」以降不要。あってもいい。それで重複が発生したらタップ時にリスト表示。選ばせる。
自動リンク。同一フォルダー内のファイル、ファイルのあるフォルダーからの相対パス、ホームフォルダーからの相対パス、絶対パスに。
ファイルを集めて一冊の本に。リンクを応用、見出し（正規表現で定義）へのリンクを自動生成して1つのファイルに書き出し。1フォルダー内のファイルだけでいい。そのファイルの冒頭には「本」ファイル用の見出しを入れる。その見出しだけの本を作れば本の本、同じプログラムで本の本の本の本も生成可能。設定項目が増えそうなので不要。
1. のあとで改行すると 2. が生成されるような。
タブストップ調整。タブ文字1つで表組み。LTSVが崩れのない表になるような。
スクロールバーには目次を表示したい。ドラッグ中に半透明で画面の右側だけを使って表示するとか。
RIGHT:[[:t/App]]
----
エロが好きです。
ボクはDMM.R18のヘビーユーザーなのですが、どうしても自分の好みの中だけで、グルグル回ってしまい、
世の中にAVは山ほどあるはずなのに、知らないなんてもったいない！もっとたくさんのエロに出会いたいという思いがあって日々悶々としていました。。
そんな中、AVというのは毎日の気分によってオナニーしたい見たいものが違うわけだから（例えば毎日食べたいおかずが違うように）、
今の自分の気分を簡単に答えれば、それに対してオススメのAV動画を紹介してくれるというサービスはどうだろう？とモヤモヤと考えていました。
ある日、会社の人に相談したら、それ「いいね！」ということになって、「そういえばDMMのAPIってのが公開されたから、それ使ってできるんじゃね？」ってことになり、
本格的にサービス開発を行うことになりました。
そしてこの度無事リリースすることができました。
「今夜のおかず」
３つの質問に YES / NO で答えるだけで、今のあなたに最適なアダルト動画を紹介するサービスです。
・フレームワーク：express（node.jsのフレームワーク）
・クライアント：jQuery、CoffeeScript、SCSS
・ビルドツール：grunt
node.jsは少し趣味でやった程度で、今回やってセッション管理やルーティング周りが勉強になりました。
データベースにはMySQLを使っています。node.jsならばmongoDBというイメージが強いですが、質問をランダムに表示する機能で、
mongoDBは現時点で正式な機能としてはランダム検索が出来なかったので、MySQLを選びました。
あと、CoffeeScriptやSCSSはJavaScriptやCSSの記法を簡単にしてくれるやつで、慣れてしまうと離れられません。
あとはTwitter Bootstrap。これなしでは生きていられません。
スマホでもなるべく早く結果ページまでたどり着けるようにしたつもりです。
オススメの動画が表示された後に、今日はこの動画の気分じゃない！と思ったときはチェンジボタンにより、同じ条件で他の動画にチェンジ！できます。
質問からやり直したいときは、さいしょから！ボタンで他の質問からやり直せます。
一刻一秒を争うエロビ探しですのでパフォーマンスには気を配りました。
最初はサーバーサイドでHTMLテンプレートを使わずに完全にREST API化して進めていましたが、
最初の表示までの若干のライムラグとSEO対策の為、最初の質問だけnode.jsでHTMLテンプレートを使用して組み立てています。
また、シンプルなサイトなのでライブラリはjQueryのみ使用し、concat/minify化はgruntのタスクとして登録しています。gzip化はNginxで行なっています。
我らがDMM様への敬意を払い、白ベース＋ポイントで赤のシンプルなデザインにしています。
・CSS（SCSS）が初めてだったので、微調整するのが大変でした。
・質問のパターンを考えるのと、紹介する動画が偏りすぎないようにするのが難しかったです。（これはまだ要調整）
・質問に対するおすすめ動画の精度をもっとあげていく。 （ユーザーの癖を把握して、機械学習とかできればいいかなと）
・おすすめ動画を表示した後に、その商品を誰かにつぶやいたり。
今回、同じ会社に勤めるエンジニア3人が約2ヶ月で作成しました。
実験的なサービスでもありますので、今後も色々と機能追加をしていくつもりです。
http://anond.hatelabo.jp/20121221113518の個別ページに遷移すると、Twitterの引用がより豪華になっていたのでまとめる。
結局のところ、blockquote記法でTwitterを引用するのは増田でも有効だったよ、というだけのお話。はてな記法では使えないよ。
注意としては、増田タイムライン上では表示されないということと、ツイート本文にはない文字でもリンクくっつけるカタチで使えるから、タイムライン上と個別ページでのツイート表示で文字が違ったりすると面倒になるかもよ、ということ。まあ、秘匿という意味でできないこともないね。続きは個別ページで！みたいに。
仕事をしない専業主婦は、パートでもなんでも仕事をして社会人になってください。数値の意味がわかるようになるしかありませんから。不確かな気分で子どもを不安にさせてはいけません。2011年4月20日
なんだかもうイケメンとかどうでもよくなってきた。外見の良さばっかり気にする年齢でもないし。 普通にちゃんと働いてて、少しは趣味も持ってて、私にもまわりにも優しくて、たくさん愛情をくれて、イケメンだったらそれでいい。2011年7月17日
こういう人間のクズに煽られてブックマークをつけているはてなの連中も、人間のクズ集団だ。近藤淳也氏は、はてながこういう衆愚メディアになった現実を直視して、もう廃業した方がいい。2011年3月17日
もし僕が歴史教科書の巻頭言を書くなら「我が国は、建国から2671年の歴史を持つ、現存する国家の中で世界最古の国家である。しかも、民間人が戦争の攻撃対象になったことはなく、悠久の平和のなかで比類なき文化を築いてきた。君たちには、夢と志を持つ日本の歴史を学んでもらおう」2011年2月10日
甘ったれるな。有権者なら自分で調べろ。都議に失礼じゃないか。 RT @rotakoro 都議会本会議を開催していることすら、広く都民に知らしめていないのによく言える。 RT @inosenaoki:傍聴席を見上げるとガラガラ。よくそれでいろんなことを言うねえ･･2010年12月9日
男が家の外に出たら、すべて仕事だ、ということをわからない女がいるのは実に寂しいことだ。古いと言われようが何と言われようがそう思う。だから忘年会を「仕事」が理由で欠席する奴はサイテーの男だ。忘年会なんて仕事中の仕事だろ。世の中には「仕事」よりも大切なものがあることをわかっていない。2010年12月9日
http://anond.hatelabo.jp/20120917013417 の続き。
前回は、使ってるモジュールしか書かなかったんで、具体的な使い方を、
my $condition = SQL::Maker::Condition->new; $condition->add('colom1' => "$value1"); # colum1 = $value1 $condition->add('colom2',{'like' => "%$value2%"}); # colum2 like '%$value1%' $condition->add('colom3',{'between' => ["$value3","$value4"]}); # colom3 between $value3 and $value4 my $q = SQL::Maker::Select->new(driver => 'XXXXX'); # XXXXXは、MySQL等の指定をする # where句に条件を設定 $q->set_where($condition); # where句を抽出。select項目やテーブルの指定を全くしてないので、$sql_conditionには # "FROM WHERE (colum1 = ?) and (colom2 like ?) and (colom3 between ? and ?)" という文字列がセット my $sql_condition = $q->as_sql(); # "FROM" を消して、WHERE句だけにする $sql_condition =~ s/FROM//; # 設定した条件の配列 my @binds = $q->bind; # SQLの読み込み（条件部分をのぞく） open my $fh, "<", "./sql.txt"; my $sql = do{ local $/; <$fh>}; close $fh; # 生成したWHERE句とソート順をSQLに追加 $sql = $sql.$sql_condition; # コネクションを取得 my $conection = DBI->connect($datasource) or die ( 'could not connect' ); my $sth = $conection->prepare($sql); # 条件に値を埋め込む for(my $i = 0; $i<= $#binds; $i++){ $sth->bind_param($i+1,$binds[$i]); } # SQLの実行 $sth->execute;
という形でやってます。
（増田だとpre記法でも「＜」「＞」が正しく変換されないんで、読み替えてください。
やろうと思えば、select項目や読み込むテーブルもPGの中で指定して組み立てることも
出来るんだけど、そこまでやると面倒くさいし、そこまで動的にコントロールする必要が
当サイトでは無かったんで、条件部分のみ動的に変更できるようにしてます。
動的SQLをperlで作ろうと思っている人の参考になれば幸いです。
参考
http://search.cpan.org/~chiba/SQL-Maker/lib/SQL/Maker/Select.pm
http://search.cpan.org/~chiba/SQL-Maker/lib/SQL/Maker/Condition.pm
かなりの長文になってしまった。まず１．から３．でとりあえずの経緯。４がちょっと長すぎる注釈というか補足資料。
かつてはたしか「アルファブロガー（死語）」にも選ばれたはず。現在はTwitterが主戦場。フォロワーは1万人を超える。俗に言う「軍事クラスタ」の一般人の中では、その知名度と攻撃性、「面倒くささ」においてトップクラス。２ちゃんねる国防板には、彼について語る専用スレ「オブイェクトスレ」まである大立者だ。
ツイッターやブログ、mixiで彼に突然説教され、一字一句をあげつらわれ、訂正を強要され・・・不愉快な思いをした人は数知れず。往時に比べ数は減ったものの、未だ熱狂的なシンパも存在する。彼らはJSFのことを本気で「魔王」だと思っている。
しかし、彼の知識は一見豊富に見えるが、実は付け焼刃だ、との声は昔から多かった。しかし、彼に反論しても、多数の「信者」の反発・突撃がその声をかき消した。また「軍事クラスタ」の有識者は、そういう面倒を恐れて沈黙を守り、結果としてJSFらの増長に手を貸した。
そして、決定的に彼が馬脚を現したのが、3.11原発事故だ。彼は核兵器や原子炉にも造詣が深いと自称していたのだが・・・知る人ぞ知るJSFの致命的失言「メルトダウンとかおきるわけないでしょう」については後ほど。※■1
JSFは以前から、Twitter上でオスプレイを徹底的に擁護していた。「欠陥機呼ばわりは許さない」のが基本。※■2 軍事知識が乏しそうな一般人相手に「教育的指導」するのが彼の日課というか生き甲斐と化していた。
↓
今年4月、モロッコでオスプレイ墜落2人死亡。Twitter上でもオスプレイ批判が増える。それでも必死に擁護し続けるJSF。あまりに必死すぎて、次第に論理構成が粗雑になっていく。これは彼の昔からの癖だ。
↓
そして先月、彼はこう高らかに宣言した。
JSF (ω・っ ＼з @obiekt_JP
@twinseagull あ、ブログも今度の週末には書くから。Togetterはその前の簡易纒めね。オスプレイがマンハッタン上空を飛んでる動画と中国リャン国防相が搭乗した事と事故率の計算と環境影響評価書と、特集コーナーも付ける。最近流れてるデマにも全部ツッコミ入れるよ。 #普天間 2012年6月12日 https://twitter.com/obiekt_JP/status/212550559088132096
↓
ところがその2日後、フロリダでまた墜落。ついに一般メディアにまで延焼。ヘタすると日米関係に影響しかねない雲行きに。
↓
今や完全なアンチスレとなったオブイェクトスレなど一部では「『魔王』様、週末すぎたけど約束の記事は？ｗ」と揶揄する声。私は「JSFの手口からしてブログの内容は想像がつく。恐らくこう書くだろう」と、あらかじめスレにいくつか書き込んでおいた。アンチスレなので、JSFは当然それを読んではいない。
↓
そして7/11未明、JSFが満を持して？ほぼ1カ月遅れでブログを連続UP。だが、内容はやはりTwitter発言の繰り返し。新味ゼロ。内容スカスカ。それに、私が「多分彼は（論拠になってないが）論拠として貼るだろう」と予想した動画をそのまんま貼ってるのだから笑える。
↓
で、スレの該当URLを付けてブログにコメントしようとしたが、何度やっても弾かれる。httpをttpにしてもダメ。分量を減らしてもダメ。そこで、リンク先などのURLをかなり削除したらすんなり投稿できた。http://obiekt.seesaa.net/article/280176542.htmlコメント2.～4.がその私の投稿。
この件を明確にするため、さらにコメント5-7を投稿。なお、スレの元URLはhttp://engawa.2ch.net/test/read.cgi/war/1337359150/880-883 （あと数日で落ちるはず）これを細工して、やっと投稿できた。
↓
ちょうどこのころ、JSF本人が私の投稿に気付いたようだ。私のコメント2-7のうち5-7を削除。間一髪の差で魚拓は取れなかったが、スクリーンショットは撮った。現在のコメント欄と比較してほしい。http://www1.axfc.net/uploader/Img/so/145757.jpg http://www1.axfc.net/uploader/Img/so/145759.jpg
いちおう、削除されたコメント5.～7.を以下に示す（一部改行を詰めた）。
（5.）
>>4.の続きというか・・・
ブログ主は、おそらく、「某スレ」のURL関係でNGワードを設定しているらしい。
何度やっても、分量を削ってもダメだった。
こういう姑息なことはやめようよ。
ちなみにもう一度言っておくが、上記の書き込みは7/1のもの。「その17」の880-883。
で、ブログ主はその予想通りのエントリを仕立ててしまったということだ。
Posted by 名無しОбъект at 2012年07月11日 01:29:32
（6.）
>>5.の続き。
この状態なら貼れるかな？
http://eng●awa.2ch.net/test/read.cgi/wa●r/1337●359150/880-883
なお、このスレはもう950を超えているので、あと数日で落ちると思われる。
Posted by 名無しОбъект at 2012年07月11日 01:37:26
（7.）
>>6.の続き。
やっぱり。自分にとって都合の悪いスレは、URLごとNGワードに登録ですか。
これはちょっとどうなの？
↓
そしてAM2時ごろ、再度書き込みを試みたが、すでに私はアク禁にされていた。同時にUPされた他のエントリ※■3 にも書き込みたかったが、もうそれも不可能になった。
その意味では、私のコメント7は消されるだろう、とは思っていた。「どうせ削除されるだろうが、他人の目に触れずとも、本人が一度目にし、少しでも反省してくれれば」との思いで書いた。
http://obiekt.seesaa.net/article/120144841.html http://obiekt.seesaa.net/article/133736708.html http://obiekt.seesaa.net/article/167737856.html 「基本ルールは一つだけ。記事題材と無関係な話をしない事」「記事違い投稿でなければ異論反論であろうと削除はありません」
私のコメント5-6は、2-4と一体で、出所及び作成日を明らかにするため不可欠だ。よって彼の管理ポリシーには抵触しない。余計な文も混じってはいるが、そもそも、まさかスレのURLがNG対象とは思っていなかった。URLが弾かれてしまう以上、やむなくURLを分断して投稿した。それすら消してしまうのは明白な隠蔽行為だ。
http://obiekt.seesaa.net/article/136573066.htmlのコメントNo.216以降を参照。今はどうなのか、私には確かめる術がない）
ならば、「風圧の問題はどの機種のヘリコプターでも起こりえます」の表現は明らかにおかしい。直ちに訂正すべきだ。例えば、ライト級のロビンソンR22が、オスプレイのように太い樹木の幹をヘシ折るとでも言いたいのか？
「風圧の問題はどの機種でも起こり得るが、その危険性・影響は機種によって大きく違う。円板荷重の大きい大型機ほど危険」が正しい。で、オスプレイのダウンウォッシュは、物理法則・実測値のいずれも、明らかに現用ヘリの中で最大級だ。
さらに、CH-47のスマトラでの事案を引き合いに出しているが、これとて、オスプレイならもっと酷いことになるだけの話だ。
あ、もし訂正するなら、訂正履歴が分かるようにね。以前、私が、彼のブログエントリで明らかにおかしい点を指摘したら、
＞メルトダウンとかおきるわけないでしょう
＞馬鹿は黙ってろ
＞核物理学を知らずに騒いでる人の頭の方がお天気です
こういう修羅場でこそ、その人物の本当の人間性が見えてくるものだ。改めて見直しても、その粗忽さ、無知、無駄な攻撃性・・・酷すぎる。正常性バイアスとチェリーピッキングの塊だ。
そもそも、「十日以上放置しない限り心配は要らない」の30分後に「メルトダウンとかおきるわけないでしょう」とは何なんだ。他にもツッコミ所満載だが、長くなるのでもう止めておく。
こういう活動を彼は日々たゆまず行っている。この情熱はいったいどこから来るのか。特徴は、ほとんどの人が日頃互いにフォローしているとは思えない人ばかりなこと。恐らく「オスプレイ」でエゴサーチし、獲物を探しているのだろう。そして「また論破した！」という快感に酔っているのだろう。
https://twitter.com/obiekt_jp/status/166908488235237376
https://twitter.com/obiekt_jp/status/177219528068050946
https://twitter.com/obiekt_jp/status/177212460149907456
https://twitter.com/obiekt_jp/status/177240511546011649
https://twitter.com/obiekt_jp/status/177372378593099777
https://twitter.com/obiekt_jp/status/177362314981416960
https://twitter.com/obiekt_JP/status/205656428755693568
https://twitter.com/obiekt_JP/status/210503539691241472
もうアク禁で書き込めないので、ついでに寸評しておく。
①『オスプレイのモロッコとフロリダの事故』http://obiekt.seesaa.net/article/280173146.html
「事故率は…若干悪い程度」と認めたのは一応評価しよう。まだオスプレイは累積飛行時間が少ないので、事故が起こる度に数値が大きく跳ね上がる。
そんなことすら考慮せず、上記にもあるように「ここ10年の海兵隊機で最も安全！」などと浮かれていたわけだ。
フロリダでの事故の直後、お仲間のdragoner_jp氏が珍しく苦言を呈した。名指しこそしていないが、JSFに遠慮して何も言わないのが通例の軍事クラスタでは異例のことだった。
前々から言っているけどさ、オスプレイの事故率云々で安全、と言う事にはあまり意味がないんだよ。バートルより安全だとしても、落ちる時は落ちるんだから、事故率ばかり言っていると、事故多発した時に言い逃れできなくなるんよhttps://twitter.com/dragoner_JP/status/213153265238540289
参考値を絶対の指標として用いると、後で痛い目見るよhttps://twitter.com/dragoner_JP/status/213154138761084928
それと、ブログのリンク先の英文にあるが、「ヘリモードでは、後続機は先行機の250ft以内及び後方5時～7時方向に入ってはならない」と書いてある。つまり、75m以上離れなければならない。ろくに編隊飛行すらできないということだ。それほどオスプレイのダウンウォッシュが強烈だ、ということの一つの証明でもある。
また、これは、操縦士に厳密に守らせるのは非常に難しそうだ。先行機が急に速度を落とすなど、いくらでもありそうなシチュエーションだ。「操縦士に改めて教育しました」だけでは、また似たような事故が起きるだろう。
②『FAAとオートローテーション』http://obiekt.seesaa.net/article/280181863.html
これもJSFが日頃さんざん言っていることだが、理屈として成立してない。オブイェクトスレでは5月時点で終わってる話。
http://engawa.2ch.net/test/read.cgi/war/1337359150/222
222 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2012/05/29(火) 00:39:27.62 ID:co9DeStc
@sawada0515 @KarinDog そもそもパワードリフト機（ティルトローター機）にオートローテーション機能は必要無いとFAAが裁定を下すんじゃないかな。これからアグスタウェストランドAW609（民間型ティルトローター）が形式証明を取るから、それで分かる。 #普天間https://twitter.com/obiekt_JP/status/207022478852235264
オスプレイがFAAを取得してないのは民間市場にはオスプレイの技術から派生したAW609を投入する予定だったから。AW609はパワードリフト機（ティルトローター機）としてもうすぐFAAを取得する予定なので、FAA取得云々という難癖付けはもう出来ませんよ。#普天間 #futenma https://twitter.com/obiekt_JP/status/207073470469775361
FAAはそもそもパワードリフト機にオートローテーション機能を要求してないんじゃないかな？ オートローテーションの有無をFAAに絡めてオスプレイを批判する行為は、オスプレイの兄弟機AW609のFAA取得で否定されると思う。 #普天間 #futenma https://twitter.com/obiekt_JP/status/207074400359559169
近い将来、アグスタウェストランドAW609が民間用パワードリフト機としてFAAを取得する。→AW609の飛行特性はオートローテーション機能を含めV-22オスプレイと同一である。→FAAはパワードリフト機を市街地で使って良いとお墨付きを与える事になる。#普天間 #futenma https://twitter.com/obiekt_JP/status/207093339948982272
・・・普天間タグまでつけて、何度も何度も同じことを言ってるけど・・・
そのAW609って、開発開始の1996年からもう16年。初飛行2003年からでももう9年経ってるが、未だ実用化できず。
しかも、そのFAA取得「目標」は2015年から2016年ｗ まだまるまる3年先の話だし、さらに遅れる可能性もある。
普通の商業用航空機なら、初飛行から1年でFAAを取得するのも珍しくないのに。
それだけティルトローターは色々とややこしいということだ。
それに、JSFは「AW609がFAAを取得すれば、イコールV-22の安全性の証明になる」的なことを平気で言ってるが、
これまたアホとしか言いようがない。
だいたい、AW609の最大離陸重量は8t弱。オスプレイは3倍以上の27t級（VTOL時は22t）。
エンジンも機体規模も全く違う。共通点は「ティルトローターである」ということだけ。
言うまでもないが、FAAライセンスは、各機種それぞれの安全性を総合的に審査して与えるもの。
JSFの脳内世界では「1機種が取得したら他のティルトローターも全部安全！」そんな理屈が通るらしいｗ
たとえAW609が取得しても、まったく機体規模・空力特性・重量・エンジンの違うオスプレイまで証明されるわけではない。こんな単純な話を、なぜ「軍事クラスタ」の連中が放置しているのか不思議でならない。
それに、例の円板荷重で言えば、AW609も依然高いが、オスプレイよりは低く、CH-53並みの77kg/m2程度で納まっている。オスプレイではできないとされるオートローテーションが、AW609ではできる可能性もある。
③『未亡人製造機と呼ばれていないオスプレイ』http://obiekt.seesaa.net/article/280184121.html
まあ、「Osprey widowmaker」で検索し、1年以内を指定すると確かに数は少ない。そういうファクトをつければ、多少は説得力が増すと思うよ。また、それ以前に、どう呼ばれようが、本当に安全性に自信があるなら泰然自若と構えていればいい。
あと、NY上空を数回飛んだぐらいで自慢・満足してもらっては困る（追記：イベントで飛ぶのは年に数回。一方、24機が配備され、全てが平日に1回づつ飛ぶとすると年におよそ6000回飛ぶことになる。全く次元の違う話）。
NYのように、沖縄の人に笑顔で試乗してもらう日が来ればいいのだが。そのための日米当局の努力は明らかに足りていないし、JSFの努力は、向いている方向が逆。
④『オスプレイ事故映像の真相』http://obiekt.seesaa.net/article/280226111.html
この映像を使うのは卑怯だ！と言いたい気持ちは分かる。が、問題は、そのジャイロ配線の誤接続を防ぐ具体的な再発防止措置が取られたかどうか。ただ「教育しました」だけではヒューマンエラーは根絶できない。コネクタ形状の工夫で物理的に誤接続を防ぐ、など。それに触れないようでは片手落ち。整備ミスだろうが操縦ミスだろうが構造的欠陥だろうが、事故は事故。（追記：このジャイロ配線については、たしか対策が取られたように記憶する。しかし、繰り返すが、それに触れないようでは記事として意味がない）
むしろ沖縄の人たちの神経を逆なでし、事態を複雑にしている点で米軍にとっては「有害」とすら言える。
http://obiekt.seesaa.net/article/150581500.html のコメントNo.96とNo.144。内容を詳しく説明すると長くなるのでぶっちゃけて言えば、JSFは、他人に『お前はこんな有名な史実も知らないのか？ｗ』といつものようにケンカを売っていた。で、私は『君こそWW1とWW2の潜水艦戦史もろくに知らないじゃないか。それに、撃沈うんぬんの事実関係もおかしい』と書いた。で、JSFはこそこそと該当部分を書き換え・消去した、と。
あと、コメント96以降の、信者たちの「俺も知りませんでしたが何か？」と開き直る様もぜひご覧あれ。
（7/12夜：数カ所補足・追記した。また、引用記法や強調表示などを見直した）
（7/14夜追記：続編？を書いた「【アク禁】オブイェクトJSF氏の言い訳が大津市教育委員会並みに酷い件」http://anond.hatelabo.jp/20120715020655 ）
スマートポインタは、ここで言われている アドレスの参照指定としてのポインタじゃないよ。単なるコンテナ。名前にポインタってついてるからといって、いわゆるポインタじゃない。分類的にはコンテナ。
std::tr1::smart_ptr＜std::vector＜char＞ ＞ hako(new std::vector＜char＞);
の３種類があった時に string型も ポインタを代入しているが、 ポインタとは呼ばないだろ。コンテナと呼ぶ。
記法上 new を呼び出すが、 それが嫌なら、そういうコンストラクタ書いてもいいしな。
str++ とか str-- str+n という記法＝アドレス参照 ができるが
スマートポインタは そういう使い方はしない。 あくまでも指定されたオブジェクトを管理するだけ。
たいていの使い方をする場合に、参照カウンタの増減なんて手動ではしないから。（というか、ポインタがわからない奴がするな コピコン使え という設計方針でいいとおもう）
パスポートの記入要項を調べると、ヘボン式ローマ字のつづり方についても説明があるね。
日本人にも英米の人にもある程度規則性が理解できる範囲で、話し言葉(発音)をアルファベットで表記するのがヘボン式のローマ字。ちょこちょこ細部の違う記法がいろいろあるけれど、一番なじみがあるのは多分パスポートのお作法。
もともと英米の人は日本人ほど長音を意識しないので「さと」でも「さとー」でも「sato」で済ませちゃうんだけど、日本人にとっては居心地が悪いので「satoh」と書いたりする。
「oh」と書いときゃあっちのひとでも「オー！」とか読んでくれそうだからな。
一方、書き文字(かな)と一対一で対応するアルファベット記法が訓令式のローマ字。
これはヘボン式と違って規格化が進んでてブレがないし、五十音表ともよく合致する。
発音の再現については劣るし、こいつで文章を書くとダサく見えるが、ローマ字入力でキーボードをたたくと無意識のうちに訓令式になったりする。
http://anond.hatelabo.jp/20120513135708
私も二行目で主張しているとおり、違うと推して調べたわけです。そしてこれって別に「新たか」でも問題ないんじゃないか、と思い至ったわけです。
サンプル数が圧倒的に足りず、お遊戯話と聞き流していただければ幸いです。
ですが、制約を掛ければかなり妥当性を持たせることもできるような気はします。例えば上文中の「推して」に関わるすべての「オして」と訓読みする語は単一の漢字で表しても問題ないと思います。文中でも書きましたが、同音類義な語を念頭に置いています。
極端に、暴力的に、かつ誤解を招くことを承知で言えば、その単一の漢字は、カタカナで代表させてもいいとさえ思っています。
字義どおり遡れば、それぞれの語の違いは際立ってくるでしょうが、それぞれの読みには共通するところがあるだろうと思っています。もちろん思ってるだけなので、確たる根拠はありませんが。
ドリル式の丸暗記法は私が編や旁、及びその読みから未知の字の意味、発音を推測、体系化させていった方法とは異なるところで、私も好むところではありません。もっとも、私が好きで採用した方法も推測に依存する不安定な方法ですし、幼い頃の物覚えのいい柔軟なときにやったことであって、大人に薦められる方法でもありません。
なんだか方向違いの返事ですね。
http://anond.hatelabo.jp/20120513140645
お前の苗字が仮に鈴木だったとして、他人から「お前の名前を『酢好き』って書いても別にいいよね？」と言われても受け入れられるのか。
受け入れられません。それは同音異義です。
当然、同音異義と同音類義の違いはどこだよ、と思われるでしょうが、距離の問題です。完全な区別は不可能です。それを承知で主張しているのです。
http://anond.hatelabo.jp/20120513212005
極端な話、そうですね。ただ、音読みに関しては諦めてます。訓読みはまだ捨てきれてないです。
以降、妄想
「ツる」という語は「釣る」「吊る」「攣る」「痙る」などあるわけですが、これらをひとつの漢字で代表させたい、ということです。もっと押し進めれば、漢字テストなんかはこういう基準で代表された漢字を書けばマルにしてもいいのではないか、と考えています。
「足が攣る」と書けばもちろんマルですが、「足が釣る」でもいい、というわけです。
「カく」という語は「書く」「描く」「欠く」「掻く」などあるわけですが、これらから共通の意味を抽出しようとすると、「欠く」が難しい。それ以外は割と容易。
これらの動作は本質的に物体を欠損させているわけだけど、前者2つはその行為から先の美的価値が強い。差異に大きな役割が与えられている。これらを単一語でまとめ上げるのは私でも抵抗がある。けど、まとめ上げられてしまえばあとは慣れの問題かな、とも思える。
「タめる」という語には「貯める」「溜める」「矯める」などがある。前者2つは一つで表せそうだが、「矯める」は難しい。超越的に解釈すれば、前者2つの動作は本質的にもとに戻る、正される意味があるのかもしれない（貯蓄はいいこと的な思想）が、私はそこまでぶっ飛んだ意味を受け入れることはできないので、無理。
仮にこの主張を受け入れたとして、
「死す」と「資す」は割と関連がつく。定性的な死と定量的な死。何かに費やすということは自身の身を削ることであり、幾らか死ぬ。
そうすると、「削ぐ」と「殺ぐ」にも関連が見えてきそうな。
「舐める」は舌で味見するとか甘く見てんじゃねーよ的な意味とかがあるが、これはかなり近いと思う。要は「食べる＝殴り合い」ということなのだろうか。とすると、「食べる＝セックス」という意味を先に持ってきて「デートやナンパ＝舐める」とすることはできなくもない。街角でいちゃつくリア充に「舐めんじゃねーよ！」とか。いっそ「舐めるなよ？爆ぜるぞ（お前らが）」とか
はデコとかトツとか読むけど、「デコる」って「凸る」でも割と行けそうな気がする（というか行けてるのか凸メールって言うもんな）。あと、「突進」とか「特区」とか、「凸」みたいなイメージ、なくもない。
要約：Tumblrは日記帳としてもソーシャルなブクマとしても使えるので、ダイアリーとブックマークを止めてTumblr一本にすると捗ります。
なります。
はてなダイアリーで個人的に便利だと思っていたのは次の4点です。
このあたりは Tumblr にしてもだいたい大丈夫というか、むしろよくなります。
ブクマ的ポストと区別して整理したい人は、タグ（「日記帳」など）をつけると便利です。
真面目に付け加えておくと、やはり少し違うものが貼られる、上がってくるという感じはあります。
やってみて肌に合わない思った人は、Twitterのほうがいいかもしれません。
ブックマークでは「あとで読む」な使い方もしばしばやりますが、その感覚でTumblrをやると
「クォート無しでリブログするとはけしからん」と偉い人から言われたりします。
慣れてくると自然に、リンクだけのリブログが物足りなくなります。
結論から言うと、
移行するというのがおすすめです。
このご時世何が起こるか分からないのでエクスポートはできるうちにしておきましょう。次のページを参考にしてください。
過去のエントリを全部Tumblrにインポートしたいという人は、頑張ってくださいというしかないです。
どうしてもやりたければTumblr APIを使うか、どこかでツールを探してくればできると思いますが、
面倒だし、実際インポートできても大した実益はなさそうなので、私は諦めました。
インポートできても結局、誰も新しい方を見にはきません。
最近の検索エンジンは賢いので、コピーだと認識して相手にしてくれません。
そもそも種類の違うサービスなので、インポートしないほうが後腐れなくていいんじゃないでしょうか。
まだアカウント持ってなければ作りましょう。
Markdown は GitHub とかでも使えるグローバルスタンダードな感じですし、慣れればはてな記法と大差ないのでこの機会に覚えましょう。
http://blog.2310.net/archives/6
いままでTumblr使ってなかった人は、まずは誰かフォローしないと寂しいと思います。
はてなーの皆様におかれましては、まずは http://otsune.tumblr.com をフォローしてそこから芋づる式に増やしたり、
http://mao.s151.xrea.com/tumbrowser/text.html でこれはというリブログをしている人をフォローするのがおすすめです。
公式ブックマークレット http://www.tumblr.com/goodies をとりあえず使ってみましょう。
Tumblrの検索性ははてブやはてなダイアリーと大差ない（＝いまいち）ので、
ifttt を経由した Evernote への自動保存を設定しておくと便利です。
さらにヘビーに使う方には、Tumblr の代名詞とも言える秒間10リブログな廃人ツール、
Tombloo (for Firefox) と taberareloo (for Google Chrome) もあります。
お好みでどうぞ。
現在、まとめブログの主の引用元である２ちゃんねるニュース速報板、およびニュース速報（VIP）板で
ブログへの引用を禁止している、ニュース速報（嫌儲）、天国板への移住が進行中
それにあわせて、コピペ爆撃等で前板はほとんど機能停止状態に。
背景には複数人での投稿や法人化して金儲けを続けるまとめブログを毛嫌いする人が増え続けたことと、
年末年始に発覚した、ステマ疑惑、一部運営との癒着疑惑が火をつけた
http://hayabusa.2ch.net/test/read.cgi/news4vip/1326140120/
【2:860】なにが起きてるか分かってない奴は来い俺が詳しく説明してやる
beチェック
1 名前：以下、名無しにかわりましてVIPがお送りします 2012/01/10(火) 05:15:20.97 ID:pDS9BceP0
長くなるけどそこは仕方ないぜ？
元々2chでは自分たちの書き込みを（著作権がないとはいえ）勝手に転載して金儲けをするアフィブログを嫌う下地があった
2012年年明け早々アニメ制作会社シャフトの公式サイトの通販商品になぜか
アフィブログやらおん用のアフィリエイトが仕込まれていることが発覚。
やらおんがシャフトのアニメを絶賛する記事を乗せていたことからステルスマーケティング（ステマ）だと祭りになる。
↓
シャフトは公式でコピペしてそのまま貼り付けてしまったミスだったと釈明。
しかし、やらおんでは問題となった商品は一度も扱われていなかったとが発覚。
コピペしようがないと火に油を注ぐ結果に。
↓
シャフトやらおんスレがパート化。しかしなぜかスレが削除されるなど
↓
このあたりでステマ連呼厨が発生。のちの経過からおそらく工作員が
ν速民にステマを飽きさせるためにやったことであると予想される。
↓
「ステマ」「効いてる効いてる」「よほど都合が悪いようだな」などと書き込まれるようになる。
6 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:18:28.39 ID:pDS9BceP0
アフィを踏ませるように誘導することをamazonが禁止していることを逆手にとり、
名前欄やレス内に「広告をクリックしてください」という内容の文章を仕込むという画期的なアフィ殺しが生み出される。
これによりアフィブロガーは転載する際いちいち書き込み内容を一つ一つ編集しなければいけない事態となった。
↓
ν速を巡回先から外すものや編集するのがめんどくさいと言いだすアフィブロガーが多数出現。
ν速ではまともな書き込みが激減。また名前欄が「アフィ駆け出し」、「ステマニア」などに変更され
↓
運用家族＝忍者とアフィブログvipper速報がつながっていたことが発覚。さらに祭りに。
↓
ν速のスレには以前にもましてステマアフィクリックお願いコピペが貼られ
まともな書き込みがほぼ消滅し、スレ立て数は以前の1/3ほどに落ち込む。
が、なぜか板がまともに機能していないにもかかわらず、スレは普通に立てられ続けると言う謎現象が現在も続いている。
↓
18 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:22:34.29 ID:pDS9BceP0
1月9日、大手アフィブログハムスター速報の記事を完全にパクった
アフィ無しサイトハムスタ一（いち）速報つくったったｗｗｗｗｗｗｗｗｗスレが立つ。
日ごろから問題の多いハム速を恨んでいたvipper達により祭りになる。
この時集まったvipperがのちの移民祭りにそのまま移行している。
↓
名前欄を変えられるのはまずいとVIPでもアフィがいやなら嫌儲板へ行けと連呼する工作員が出現。
vipperもν速に習いマジで移民することになってしまう。さすがにν速民と同じ場所へ行くわけにもいかないので、
↓
1月10日0時天国移民祭り発生。同時にVIP焦土化作戦と称しVIPに焼け野原スレが乱立される。
数回に分けて乱立が行われるも水遁を食らうものが続出し勢いが落ちる。
↓
危機感を募らせたアフィブロガーがFOXに嫌儲を転載可能にしてくれと
必死のお願いをするも「頭おかしいんじゃない？」「いやどす」と一蹴。
嫌儲ではν速民お得意の手のひら返しでFOX絶賛レスが多数発生する。←今ここ
大体こんな流れ
リアルタイムで参加したわけじゃないとこもちょくちょくあるから
微妙に間違ってるとこもあるかも知れんが
20 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:24:18.53 ID:ibU0ACgp0
焦土作戦の詳細教えて
22 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:24:42.27 ID:ksqJpU0n0
よって俺には無関係だな
23 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:24:46.68 ID:1oxYNt9UO
24 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:25:39.90 ID:BKjxJE7wO
アフィてなんだよ
36 ：以下、名無しにかわりましてVIPがお送りします：2012/01/10(火) 05:31:39.29 ID:pDS9BceP0
みんなで天国板に移民した上でクソスレ乱立させてVIPを機能しなくしようぜって作戦
22
はてぶでも人気のまとめブログ
現在はアニメ板やニュース速報＋ 、過去ログで記事を書いてるがすでに飛び火の火の粉が
これからどうなる
、
読みやすく記法かえた
下の記事もおすすめ
http://anond.hatelabo.jp/20120110101235
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
