  |
はてなキーワード: ウィジェットとは
DL販売をしろって話ではなくて、あくまでコミケ会場における頒布方式の話ね。
なんで紙媒体にこだわっているのだろう？
現地での同好の士どうしの触れ合いの場という意義を守るにしても
例えば、QRコードが印刷された紙片をブースで100円とかで売る。
「これをスキャンすればデータを落とせます。よかったら感想コメもください☆」
とかでよくない？
QRコードの内容は、本データが格納されたクラウドへアクセスする認証スクリプトに、
GETでユニークなシリアルコードが予め入力されるようなURI。
もちろん従来どおりの紙の本500円とかと併売してもいいし、
同人誌ならこれで救われる人もいると思うんだよね。
コード認証機能を提供するWeb APIだかウィジェットみたいなのを
出してくれたらスムーズだけど、そこらへんも同人開発者の力でいけそうでしょ。
データ置き場も自分のサイトじゃなく、準備会の指定するクラウドにしちゃえば楽。
データで買ったが紙の本も読みたいって人に関しては、
業者は印刷用データをDLできて、製本されたのが届く、みたいな
オプションサービスをどっかの業者が始めればいいだけじゃない？
サークル参加者にとっても、見本誌や試し読み用のを
これで身銭を切って印刷所課金した上に在庫リスク・不安を抱えなくても、
アプリからQRコードを多目に自宅のプリンタで印刷しとけばすむ。
ついでに見本誌もデータで納められるようになれば、
完全にデータだけ用意すればよくなる。
紙の本を否定するわけじゃないし、趣を考えると共存する方がいいけど、
積極的に電子化を取り入れたら、作る側にとっても読む側にとっても、
より便利で、よりフェアで、より可能性が広がると思うんだよね。
こんにちは。こちらはとある動画系のアダルトサイト管理人をやっている者です。
ちなみに昨日、XVIDEOSサムネイル画像取得ツールのことを書いた者でもあります。
http://anond.hatelabo.jp/20150730145212
今回はちょっと真面目にアクセスを上げる方法を書いてみたいと思います。
またWordPressと違ってやれることが少ないです。
立ち上げ当初は確かにWordPressよりも検索が来やすいですが、
PVが増えれば増えるほど機能が少なすぎてイライラすることになります。
アナリティクスを見て22時より0時のアクセスが減ったりしていませんか？
大体0時辺りが1日のアクセスのピークです。そこが落ちているようなら問題です。
サイトの表示速度を上げる為に高速なサーバーに移転することを検討しましょう。
ApacheならWordPressのキャッシュ系プラグインを導入しましょう。
あと簡単に使えるからといってプラグインを入れ過ぎないようにしましょう。
裏側で必要なプラグインだけに絞って、あとはテーマに自作しましょう。
ついでに思い切ってウィジェットもやめちゃいましょう。
重くなるしバックアップ取れないし良いことはありません。
ビッグワードでヒットさせたいからと言って無闇にワードを詰め込みすぎていませんか？
逆にスパム扱いされたらGoogleはもう戻ってきてくれません。
ワードを盛りすぎて意味不明な文章になっていないか確認しましょう。
相互依頼を受けた全てのサイトとリンクを貼ったり貼ってもらったりしていませんか？
悪質なサイトと相互リンクをしていたら低評価になってしまう可能性があります。
開設間もない頃はGoogleも大手サイトからもアクセスが来ないので、
アクセスを集めるにはアンテナサイトに登録するのが手っ取り早いので手を出しがちです。
しかしアンテナに依存してしまうと簡単には抜け出せなくなります。
しかも切られたら一巻の終わりです。ご臨終です。
アクトレをメインにすると直帰率が高くなってGoogleの評価が落ちるし、
SEOを主軸に据えると大量のサイトとのアクトレが難しくなります。
まさにあちらを立てればこちらが立たずです。
過度になり過ぎない数でのアクトレに留めてSEO主体で運営する方向性が良いと思っています。
記事タイトルと埋め込み動画、あと一言コメントを入れる程度の記事じゃコンテンツとしては弱いですよね？
例えば用語集を作ってみたり、女優の詳細なプロフィールを書いてみたりしてみましょう。
WordPressなら「固定ページ」を使えば通常の記事と分けられるので良いと思います。
またカスタム投稿タイプで管理人ブログをやってみるっていうのも面白いかもしれません。
とにかく「このサイトは使える！面白い！」とユーザーに思ってもらえるコンテンツを作りましょう。
何だかんだいってこれが速効性があって一番効果的だと思います。
まず何よりもGoogleにインデックスされる数が多くないとアクセスは集まりません。
そういうわけで、私も更新数を増やしてPVを上げた経緯があります。
でも更新作業が大変になったのでサムネイルを取得するツールを作りました。
昨日はXVIDEOSだけでしたので、xHamsterとFC2も用意しました。
※当サイトについてというページの「サムネイル自動取得ツール」のリンクで公開してます
アップローダー本体の動画ページURLをコピペすればサムネイルが複数取得できます。
ちなみにFC2は記事によってサムネイルの大きさが変わる仕様なのでご注意ください。
なので現状よりもっと記事数を増やせるはずなので頑張って更新してみてください。
正直、ヒットするかしないかは運によるところも大きいです。すみません。
結局、5sの32GBを買いました。ios７のままです。感情的な感想を残しておきます。
店頭では後ろにコードや機械がくっついていてよくわからなかったが、やはり小さい。
あと想像以上に軽い。イメージではもう少し重く、持ったら「落としたらパリーンって割れるんじゃないか」という不安に見舞われるのでは？ と危惧していた。しかし、実際持ってみると軽い。
GALAXYのラウンドな感じになれた手には角張って感じられる。でもアルミ仕上げのざらざら感がなかなかいい（Xperiaみたいな背面ガラスだと思ってた）
総合的にいうと、なんか、落としても割れなそうな感じ。（よい子は絶対にまねしてはいけない）
ブラウジングしてると、サファリの特性なのかiPhoneの特性なのか知らんが、スワイプがキュッキュキュッキュしてて好みが分かれると思う。自分はandroidの「勢いよくフリック（スワイプというよりフリック）したらめっちゃ流れる」感じのほうが好きだった。
ピンチ操作の感度はかなり良い。壁紙のサイズ調整をしたがこれandroidなら大きすぎや小さすぎになってムキーなってたと思う。
うんこだと思ってたらくさやだった。使う前は「絶対に無理」と思ってたけど「まあ使えないわけでもないしなあ」と。
カーソルがないのは本当に面倒だし、変換範囲を変えるのに手元でできないのは苦労。（入力だけなら片手でできるが、文字の選択は無理だった）
でも、明らかに別のキーも一緒に押してるのに、目的のキーが押せるのはすごい。なんなのあれ怖い。
戻るボタンがないのは最初戸惑う。そりゃこれ6プラスのサイズだったら困るわ。
指紋認証楽しい！ 楽！ 小指だけしか登録しない、とかだと、腕ごと切られない限り時間稼ぎできそう。
TouchIDが使えることを読み逃し、DropBOXを入れるまでに５回くらいパスワードを入力する羽目になりイライラ。今は指紋でできるようにしたけど、アプリをダウンロードするたびにやってる気がする。
NoteⅡ＝ホームアイコンまみれにもかかわらず、アプリは一覧から起動
というような状況だったので、正直自動で詰めて表示してくれたり、フォルダのタイトルつけてくれるのはとても楽。
前は大してウィジェットとか使ってなかったので、これで充分。
何もしなくても、新着メッセージがロック画面に表示されるのはありがたい。
ただ、ドックやフォルダの背景の透明度は２種類じゃなく微調整できるとよかったなあ。
ライトニングケーブルって、なんで端子根元のぎざぎざついてないんだろう。
みんなこぞってボールペンで補強してるけど、それでも断線しそう。
通話＆SMS専用。母親（ガラケー）との無料通話があるので解約不可。
データ通信専用。Xiプラスの割引を見込んで購入。２年間の割引が終わったらMVNOに切り替えようと思ってた
最近やってきた、会社支給のビジネススマホ。内線電話の代わりでもある。アプリダウンロード禁止という残念仕様。
丈夫だけどめっちゃ重い。
いや、正確にはNoteⅡを自宅専用にして、ファブレットじゃないスマホを買う、だ。
アプリのダウンロードが禁止されている以上、通話用携帯と会社スマホのみでの運用は考えられない。
しかしでかいNoteと重いTORQUEを一緒に持ち歩くのはキチガイである。
かといって通話用をスマホにする気はない。というかTORQUE（京セラ）の技術でさえこの音質なのかよ、ってレベルでびっくりした。
今は５インチが主流。TORQUEも5インチ。小さくても4.5インチが限界。NoteⅡと同じくらいのスペックを希望なので、そのスペックだとサイズがそれしかない
メリット：androidなので慣れている。カスタマイズが効く（スカイババアが使える）。
デメリット:docomoは解約予定なので、中古を買うしかない。
SIMフリーの5Sが安くなっている。今まで使ったことがないのだが、iPhoneを買うという選択肢はないか。サイズが小さく、アクセサリも充実している。
メリット：小さい。ケースがいっぱいある。手放すときに高く売れる？
デメリット：使ったことない。文字入力の感じがあまり好きでない（特に文字選択＆挿入）。カスタマイズ性が低い。docomoは解約予定なので、6を一括で買って売っ払い、SIMだけ使うという裏技が使えない
考えてみれば、ホームは全くいじってないし、ウィジェットももてあましているし、必要なカスタマイズって通知画面とバッテリー残量の画面下部表示くらい。
デフォルトのフィルターはあまり使えないから、abp_jp.txt( https://raw.githubusercontent.com/k2jp/abp-japanese-filters/master/abp_jp.txt )とabp_jp_element_hiding.txt( https://raw.githubusercontent.com/k2jp/abp-japanese-filters/master/abp_jp_element_hiding.txt )を追加するのをおすすめする。
トラッキング、ウェジェット、広告をある程度抑止できるChrome拡張。
Twitter、はてな関係のウィジェットだけブロックリストから外し、FBの(・∀・)ｲｲﾈ!!だけブチ殺せる粋なアドオン。
パソコンの広告は比較的簡単にブロックできるけど、モバイルは難しい。
率直に言えば、これから書く対処法は気休め程度にしかならない。
だから、僕らを操っている広告への"聖戦"にそれほど興味がない人は、ここから先のエントリーは読まなくていい。
広告、トラッキング、ウェジェットをブロックするiPhoneアプリ。脱獄不要。
前出の『Adblock Plus』のAndroid版。
以前はGoogle PlayにあったのだけどBANされてしまった。
今は有志が野良アプリをアップデートして聖戦を続けている( https://adblockplus.org/en/android-install )
無数に存在するWeb広告ブローカー一社一社に「Cookie勝手に見んなボケ氏ね」とリクエストすることもできる( http://matome.naver.jp/odai/2136295595828806701 )
大変。でも現状ではどうにもならない。電博が支配するマスとは違う。ステークホルダーがあまりにも多い。
実は私、無料Webメディアで食ってる。だからこんなエントリー書くのは自分の首しめることになる。
構わない。
もう疲れたんだよ。ユーザーの属性、トラフィックの解析、ページをどこまでスクロールしたかまで分析する。
FBがパラメータいじってユーザーもてあそんだことニュースになったけど、似たようなことはどこでもやってる。
広告と大量消費社会のワンセットは、資本主義社会にとって必要悪なのだと思う。システムを維持するには仕方がないことなのだろう。
でも、だからと言って唯々諾々と広告が命令する通り消費にふけこんで良いのだろうか。僕らは消費者である前に人間だ。なんとしても人間性だけは護持しなければならないと思うのは僕だけだろうか。
just doingは和訳すると「ひたすらそれをやりなさい」。という意味だ。つべこべ言わず、ごたくわ並べずにとにかくやりなさいという古くからの聖人が繰り言のようにつぶやいてきた言葉だ。
日本でも古くは只管打坐（しかんだざ）という言葉がある。只管というのは「ひたすら」という意味。打坐は、坐を打つ、つまり「座禅に打ち込む」なんだな。
今日こんな記事があったけど、日本もやっとこさアホみたいな努力厨が減ってきていい世の中に向かいつつあるのかなとホッとしたと同時に、
会社で「艦これ」プレイする人々 専用ウィジェットで「最小化」、テザリングで「ログ残さず」 | ニコニコニュース
http://news.nicovideo.jp/watch/nw1104289
古くからの日本の心が失われているようで寂しさもひとしおだったんだよね。変に真面目で凝り固まった部分がある一方で、やたらと無気力でマニュアル化された考え方しかできない指示待ち人間が増えていて複雑な気持ち。
人生生きているとそういう複雑な気持ちになることがあって多大な時間とお金を浪費していることに気づいたほうがよい。
偉い人の伝記とか読むと決まって苦しみを打ち消すように研究に没頭したと書いてあるでしょ？板挟みの中間管理職でも酒に逃げたりしない。打ち消すようにjust doing。
あれは脚色なんだろなと思ってたけどこの歳になって本当にその通りだなと思うわ。とにかくやるしかない。
我らがdankogaiも5年も前に「やる気を出すな。手足出せ」という名エントリを上梓しているが誠に先見の明と言うべきだろう。
分かってるとは思うが「俺はやってるんだぜ」とひけらかして自慢する人は全然just doingじゃないんだよ。当たり前のことをやってるという感覚じゃないとjust doingにはならない。別に偉いことでもなんでもなくて普通。
だからってやってない人が普通以下というわけでもない。比べちゃだめ。比べた途端にjustじゃなくて条件付き確率になるのよ。こういう時はこれくらいの確率で仕事できるけど、
そうじゃなくなったらがんばれるの君？って話になるわけだ。それがベイズ確率論。
結局のところしょーもない努力厨も無気力人間もどっちも条件付きという点でjustじゃない。ということが分かってもらえるかと思うんだけど、ここでつい我々現代人の悪いくせは、
どうしたらいいの？と考えてしまう。justはjustでもjustなシステムズはなーんだ？を見つけようとする。小学校のときに先生が理科の授業で「なぜ？を繰り返しましょうね～」と言ってたけど、
だいたい専門知識のない奴が「なぜ？」を連呼してもロクなことにはならないだろと子供心に思ったし大人になってその考えはいっそう強まるばかりだ。
我々現代人は西洋のデカルト的世界観を知らず知らずのうちになんだかんだ引きずっているから、つい社会面や政治面のニュースを見て「なぜ？」「どうしたら？」という形でどうしても方法序説を考えてしまうのが
悪いところで、そんなくだらないこと考える暇あったら自分のことやればいいのにと老婆心ながら指摘してしまう。
未来検索ブラジルのグニャラくんこと末永匡34歳会社員も社会のことなんて考える必要はありませんと明言している。ネットで声の大きなスポークスマンがそのように言ってくれるのは実に心強いことである。
この「まず自分」の精神はまさにjust doingそのものと言って良い。世の中エゴは悪いこととされていて、周りに気を遣うべきというマナーや、周りに合わせるよう押し寄せてくる同調圧力があるけど、
よく考えてほしいのは周りと自分を対置させて相容れないもののように扱っていること自体がデカルティズムの陥穽にドハマリしているということだ。
無意識に利他と利己は反対で、利他は大事だから、じゃけん利己はやめましょうね～とみんな当たり前のように思っているのがおかしいんだよね。
先回のエントリー( http://anond.hatelabo.jp/20140119132435 )はそこそこ好評だったようで、『Nexus5』でググるとトップページの上から2番目に表示されます(2014/01/24現在)。
Google先生のビッグデータをもってすれば、私を社会的に抹殺することは簡単ですが、メリケン人のデモクラシーとリバティーの精神はきっと私を赦してくれるはずです。赦してください。
前回までの話を三行でまとめると、
1. iPhone持ってるけどNexus5が欲しくなって衝動買いした。
3. Nexus5が文鎮になる。
です。
このGoogle製文鎮で何枚も『倹約』、『清貧』といった戒めの言葉を書きました。ちなみに給料日までの食費は弟(18歳)に借りました。
お習字にはもう飽きたので、今回は『文鎮化したNexus5をiPhoneライクな使える端末に変える』話を書きます。
以下、私がした具体的な作業を列挙します。
『既に持っているiPhoneと同じアプリをインストールする』という、既に結論が最初から決まっている会議と同じくらい有意義な作業をします。
Android用がリリースされていない、あるけどイマイチ使い勝手が良くないアプリは、代替物を頑張って探します。
私は『GoodReader』の代用品を見つけるのに苦労しました。というか、見つかりませんでした。Good〜を作ったヤツは天才だと思います。Good！
ニコ動プレイヤーは非公式アプリ( https://play.google.com/store/apps/details?id=net.binzume.android.nicoplayer&hl=ja )が良いです。
Google日本語入力は賢いです。ATOKに1,500円払う必要はないんじゃないかな。
有料アプリを買う時は、セブンイレブンで売っているGoogle Play ギフトカードを使うと良いでしょう。
Nexus7が当たるキャンペーン( http://vdpro.jp/google.seven/ )をやってます。もう要らないわ。
施策② 動作を軽快にする
バッググラウンドでメモリを喰っているタスクを減らす作業をします。
Zapper( https://play.google.com/store/apps/details?id=com.lookout.zapper&hl=ja )のようなタスクキラーアプリを使ってメモリを解放します。
必要に応じて各アプリの設定を変え、なるべくメモリを消費しないようにします。
とりわけ勝手に常駐したり、バックグラウンドで動き出す迷惑なタスクはぶった切っていきます。
これは諦めました。
あまりiPhone風の見た目にならなかったり、パソコンとデータをやりとりしたりと面倒です。
好事家は『Android ウィジェット iPhone風』でグーグル先生に相談してみてください。
Nexus5をiPhone化するために私がやったことは以上です。
他にも、Nexus5用クリアケースを魔改造して外観をiPhoneにするという考えが脳裏をよぎりましたが、既に結論が(ry くらい非生産的なので自制しました。
あとはカスROMでしょうか。カーネルに手を突っ込んで、本当に文鎮化したらテンション爆アゲ↑↑ですね。
上に書いたことをNexus5にしてあげると、多少は使える端末になります。
同じことをすれば、他のAndroid端末も利便性が向上するのではないでしょうか。
ただ、機種によっては『消せないゴミアプリがプリインストール』されていたり、『OSの更新をメーカーが真面目にやらない』といった困難があるようです。諦めましょう。
まぁ、一番良いのはiPhoneを使うことなんですけどね。誰か、私のNexus5買ってください。弟への借入金返済に充てます。
ネットストーカー並にすごいw
2011年6月まで、長きに渡り運営され、多くの人々に愛されていた超人気ブログ「ひろぶろ」が突然閉鎖となりました。ひろぶろはnejire氏が一人で運営していた個人ブログであり、閉鎖の理由に関しては未だ不透明なままです。
ところが、今年7月になり、同一ドメイン・同一名称・同一デザインの「ひろぶろ」の運営がはじまりました。
nejire氏が更新を再開したのかと勘違いしている方も多いようですが、こちらは当初「ひろぶろ3代目」と名乗っていたhineri氏が運営しているブログで、名称・ドメインは同一でも管理人は別人になります。
hineri氏のブログによると、初代ひろぶろであるnejire氏の許可はとっていないそうです。
この記事は3代目ひろぶろに関しての考察です。
さて、遡ること半年以上前、「２代目ひろぶろ」が事実上の閉鎖状態になりました。
これで本当に寂しくなるなあと思ったわけですが、それと同時に３代目を自分がやったらどうだろうか…？
ということについても考えるようになりました。
ちょうどその頃、私はドメインの重要性について勉強していたものですから、
初代ひろぶろのドメインが取れないのならどんなにがんばってもアクセスなど望めず、
それではひろぶろの復活にも成り得ないし、やってもしょうがないだろうと思い
「ひろぶろ」のドメインhiroburo.comが、2011年12月14日で期限が切れることをWHOISの情報で把握していた
2012年7月25日、長き交渉の末、初代ひろぶろのドメインをhineriが取得し、これをブログに設定し、ブログタイトルを「ひろぶろ」に戻す。
ひろぶろが閉鎖された事により、「辞めるくらいなら管理権を譲ってくれ！」
などと他所に書き込んでいる人も見受けられるが、
確かにその気持ちも分からんでもない。
僕はこの一件について、以前見たマット・デイモン、ベン・アフレック、ロビン・ウィリアムス出演の映画「グッド・ウィル・ハンティング」の中のセリフを思い出した。
お前は宝くじの当たり券を持っていて、それを現金化する勇気がないんだ。
お前以外の皆はその券を欲しいと思ってる。
それを無駄にするなんて俺は許せない。
昨日、人気サイトの「ひろぶろ」の閉鎖に関する記事を書いたら、
あと、ひろぶろのドメインについて、
他サイトのコメントにて、年末まで更新されているとのことだが、
これは更新されているというよりも、単にそこまで契約が残っているというだけに過ぎない。
・・・と思う。
最初に「ひろぶろの閉鎖」についての記事をアップした後、
当方のブログがグーグルのトップページに「ひろぶろ」と言う検索ワードで表示され、
それ故にかなりのアクセスもあった
正直に言えば、「その３」くらいから、上記の様な理由でひろぶろの閉鎖の事なんてどうでもよかった。
以下、仕方なくヤフーへ問い合わせた苦情の内容と、ヤフーからの返答。
＞当方で書いたブログの記事が、「ひろぶろ」という言葉で検索出来なくなっています。
＞これはあまりに不公平ではありませんか？
検索結果は適宜更新されており、ご希望のキーワードでの検索結果に、
「ひろぶろ」が閉鎖された時、ちょっとそのことに触れただけであれだけのアクセスがあるのだから、なんとなくその辺の事を利用しながらその｢ひろぶろ｣へのアクセスを流入させるべく似たようなサイトを作れば少なくともかなりのアクセスが望めるのではないか・・・？
初代nejire氏の許可なんて絶対取ってないと思うし、やっぱりその狡猾さというかアザとさに共感できないので、あえてこのページではリンクを貼らない
でだ、
３代目ってあるんだろうか･･･？と思って「３代目ひろぶろ」で検索してみると、
おおおおおおおおおおおおおおおおおおおおおお！！！！！！！！
凄ええええ！！
ほぼ初代のレイアウトで既に始まっていました。
サイト内を色々見てみたけど今度の３代目はプロっぽい感じもするし、かつての「ひろぶろ」を彷彿とさせるレイアウトのきめ細かさは かなりリスぺクト出来る。
今度の３代目ひろぶろは良さそうだ。
今回のはかなり信用できそうなので、このページにもリンクを貼らせてもらおうと思う。
えんたんぬ哲学の道では、自ら3代目ひろぶろを始めたのにもかかわらず、まるで知らない誰かが三代目を継承していたかのように書いているのも興味深いです。
現在のひろぶろの管理人hineri氏（＝エンタン氏）はもともと初代ひろぶろのファンであったものの、ひろぶろの閉鎖考察記事を書いたところ、急激なアクセス増加を体験。これにより本来の目的であるはずの初代ひろぶろの「ファンのためのブログ引継ぎ」が二の次となり、「アクセス数の引き継ぎ」が目的となっていったように思います。
もともと多数のブログを運営されており、アクセス集めに関し非常に興味をもっていたことは、運営しているブログからもうかがい知ることができます。
二代目に関して、nejire氏に許可を取っていないことを狡猾だ、あざといと自らの文章で言及していたのに、実際には二代目と同様nejire氏に許可をとらず、「3代目ひろぶろ」でスタートしていたブログ名も、ひろぶろのドメイン取得と共に「ひろぶろ」というオリジナルと同様の名前に変更してしまっているのは、なんとも皮肉な結果です。
2012年7月現在におけるAndroidとiOSの選択について自分が利点と思っている点をあげ、個人的主観を大いに含めた上で検討。
1万円以下で購入することも難しくはなかった(2-5月の新学期セールの場合)。学生の場合は維持費も安く、一括購入さえして
しまえば通信料定額であっても2000～3000円で維持することはなんら難しくない。社会人の場合でも、MNPキャンペーンなどを
併用すればそう負担とはならない。
iPhone3Gと3GS、iPhone4と4Sのそれぞれではおおよそ互換性が維持されている。次期iPhone5とその後継においてもこれは継続されうるであろう。
機種代そのものはほとんど0円で済ませることが可能である。ただし、機種代金補充のための
割引金の変動が大きく、ドコモに至っては1ヶ月単位で値段が大きく変動することがある。
なお、対するAUとSoftbankは比較的安定の傾向にある。そのため、時期さえ見極めを行えば、通信料自体も0円で済ませることも可能である。
簡単にwifiやbluetoothのオンオフを切り替えることができる。
端末もあり、多くのデベロッパーから様々なROMが提供されている。
自分に合わせたものを選択することができる。またsim freeで販売される機種もあり、海外からの購入も難しくはないので、日本のキャリアにとらわれない
選択も可能となっている。
現在JBしたiPhoneをDualsimにして運用しており、タブレットは今後出るであろうGalaxyNote10.1を買うつもりでいる。
iPadも購入したし、Androidスマホも5機種ほど買ってみたが、個人的に行き着いたのがだいたいこんな感じ。
GalaxyNoteについてはモノが上がっていないので、購入してiPadと比べてみるつもりである。
iOSとAndroidについては多くの比較がなされているが、実際に使ってみないと理解できないことも多い。
金銭が許すのであれば、いくつか購入して触って見ることをおすすめする。
第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 練習問題
この記事（http://www.drk7.jp/MT/archives/001769.html）が話題になっているので、自分も書いてみます。まずは自分の属性。
そもそもNexusSは国内で販売されてないので、NexusSとiPhone4のどちらがイイですか？と人に聞かれることは全くないですが、
NexusSの方が圧倒的によいと"私は思う"と（もし聞かれたら）答えます。今後の機種変も間違いなくGalaxy S2、3？、と買い続け
ていくと思います。一方で別の技術はもうわかったのでiPhone4は手放そうと思っており、iPhone5が出たら誰かに触らせてもらい
たいです。※NexusSは技適未通過端末なので、帰国前の使用感レポとなります
元記事に異論なし。音質は音楽聞かないから知らない。AndroidはiPhoneよりもっさりしてるし、落ちるし、電池減る。
Nexus Sの解像度はWVGA(800x480)とiPhone4(960x640)より劣るのに、画面自体が大きい分広く感じる。Nexus Sは4インチ、iPhone4
は3.5インチで、だいぶミスタイプが減った。Xperia arcは4.2インチなので確かに大きすぎるかも。Nexus Sはちょうど良い。
だいたい元記事通り。ランキングサイトを見て色々試すのが自分は楽しい。iPhoneでスクエニのゲーム買ったけど、結局スマホで
ゲームなんてやりにくいし放置。ゲームは3DSかPSPで良い。
で、大事なのはここから！速度・安定・電池を差し引いても自分がAndroidを選ぶ理由。
Androidアプリの良いところは、アプリ間の連携がシームレスなところ。写真とる→ギャラリー(iPhoneでいうアルバム)→共有から
直接twitterなどにうｐ、が可能。(http://www.gazo.cc/up/37699.jpg)iPhoneは写真とる→アルバムは移動出来るけど、うｐする
には各アプリを立ち上げないといけない。ブラウザもメニュー→共有で、そのページを色んな方法でシェアできる。アプリ連携し
すぎ。あとページ内検索とかも地味に便利。
他にも良いアプリとしてはIMEのSimeji。←→キーとソーシャルIMEが便利すぎ。iPhoneだとiとiの間にカーソル合わせるとかほぼ
無理。ツイートする時に少し戻りたいとかもよくあるので、←→は不可欠。ソーシャルIMEの効果は
(http://www.gazo.cc/up/37694.jpg)参照。スマホは数字・記号が混ざった入力がだるいので助かる。
GoogleMapは拡大・縮小した時にコンパスが元に戻らないのが良い。(ブラウザにもついてる)- +ボタン便利。本来はマルチタッチ
非対応端末用だけど、片手で縮小出来るのが十分便利。iPhoneだと縮小時に左手に持ち替えるとかよくやってた。他にマイマップ
とか様々なレイヤが重ねられる。Latitudeは友人0だから意味無いんだけど、mixiのAndroidアプリ(上の画像の)みたいな感じで4sq
iPhoneは他のアプリが起動すると投げっぱなしで戻れないし、1つのアプリ内でも戻れなくて迷子になることがよくある。
だいたい左上が「戻る」系ボタンがあることが多いけどそうでないアプリもあるし、左上とか遠くて画面を覆い隠してしまう。
今では「戻るボタンが無いなんて、ブラウザバック禁止でブラウザ見るぐらいストレスだろ…」と思っている。
色んなアプリの新着がステータスバーに表示される通知機能が死ぬほど便利。twitterにおける通知（とウィジェット）の良さはこ
れ(http://ran.private.coocan.jp/omusubi/log/2010/12/android-twicca-beta.html)あたりを参照。iPhoneにもPush通知はあるけ
どすぐ見なくて良いものを保留、とかが出来ない。強制的にアクティブになるのが鬱陶しい。インテントと組み合わさると最強で
、こんなこと(http://www.gazo.cc/up/37695.jpg)が出来る。
上のtwitterクライアントのエントリでもあるようにウィジェットが便利で、ホームから色々設定変更が出来る。自分は家帰ったら
NoLockウィジェットでロックオフしてすぐ操作出来るようにしてるし、布団でごろごろ使う時にはScreenFilterウィジェットで好
みの程度暗くする。あと計画停電があった時はホームに付箋メモ貼ってすぐ確認出来るようにしてた。この辺はiPhoneでもJBすれ
ば出来る範囲なのかな。
他にもFLASHが動くとか、NFCがついてるとか、電源ボタンがサイドについてて使いやすいとか、丸っこくて可愛いとか、Macがなく
てもアプリ作れるとか、色々良いところはある。代わりに先に述べた体感速度、OSの安定度、充電池の悪さの他に、フォントが変
元々NexusSはAndroidアプリ開発用にと買っただけで、予想以上に気に入ってしまったのは誤算。久しぶりにiPhone使ったら「戻れ
ない」「←→ない」「通知ない」が死活問題だし、最近Softbankの電波はさらに悪化したのか屋外ですら300～500Kbpsしか出てい
ないことも多く、人が多いと100Kbpsも出てない。（前は1Mbpsとか普通に出てたので、ここ最近何かあったのか、場所・時間帯に
"自分は" Nexus S ＞ iPhone4だが、我慢してiPhone4を使っている。iPhoneにはAndroidのようなワクワク感が無いのが残念だが、
カスタム面倒な人・初心者にはiPhoneを勧めているし、無難だとは思う。2.2か2.3以降のAndroidなら、用途や好みによってはオス
スメ。色々出来るから本当楽しい！アプリをアドオンで強化出来るとか感動したし！個人的には「iPhoneに貼る電子マネーシール
」「iPhoneでも音の組み合わせで決済」「iPhoneでFlash」「iPhoneで赤外線」とかにエネルギー使うのは勿体無いので、より自由
なAndroidが普及して技術が発展すると良いと思っている。
じゃあ何を使うべきか迷っている。Softbankは解約して本体売るつもり。回線はdocomoか、b-mobile+WiMaxか、auのEVO WiMax
(CDMA+WiMax)が良い気がしている。EVO WiMaxはかなり魅力的だけど、CDMA通信時の安定性が不安なのと、端末がHTC EVO一択にな
ってしまう。docomoの最新はXperia arcだけど、なんかぺりあってダサい感あるしGalaxy Sの方がNexus Sと似てて良さげ。ただ来
この記事（http://weekly.ascii.jp/elem/000/000/038/38214/）のように、SIMフリーの技適通過済みAndroid端末をデータ通信の
みで使うのが安いし早いのは魅力。でもIDEOSは小さいしスペックが…
この辺（http://gpad.tv/phone/docomo-sc02c-samsung-galaxy-s2/）を見るに、Galaxy S2の発売とレポを待つのが良いと思うので
、たぶんそうする。本当はすぐにでも変えたいので辛い。
