  |
はてなキーワード: Mac OSとは
STBとはSetTopBoxの略称で、TVの地上放送や衛星放送をTVなどで視聴できるように変換する装置。
そして、スマートSTBとはインターネット放送に特化したSTBを指すことが多い。
代表的なものにAppleTVやAndroidTV、Fire TVなどがある。
つまり今回はAppleTVやAndroidTV、Fire TVを今更導入してみようぜ！って話。
「AppleTV？いやTVでYoutubeとか観れるだけだろ？パソコンで良くね？」という増田、君は概ね正しい。
しかしよく考えてみて欲しい。君のTVは何処に設置されているのか？を。
大抵の場合はゆったりリラックスできるリビングに設置されていて、ノートパソコンならまだしもデスクトップパソコンだと多くの場合はデスクなどの付近に設置されているはずだ。
デスクトップパソコンはデスクのそばにあるとゴロ寝で視聴することは難しいし、ノートパソコンだと迫力に欠けるのではないか？
スマートSTBはTVへ接続されることが前提であって、パソコンでの視聴に関する何だかモヤっとする部分を解消できるんだ。
最近のTVにはインターネットへの接続機能があってYoutubeくらいの視聴なら申し分なく可能であることが多い。
ただやはり格安のTVではそういった機能が省かれていたり、どうしても性能が控えめで操作の遅延が気になったりする。
更には、TVへ組み込まれたインターネット接続機能は非常にハードウェア更新が難しいことも欠点だ。
そうつまり、TVへ組み込まれたインターネット接続機能は古くなるんだ。
スマートSTBは外付けを前提としていて、性能や機能が古くなればスマートSTBを買い替えてハードウェア自体を更新することが可能なのは非常に大きい。
概ね正しいと言ったけれど、動画視聴はYoutubeだけでない。
Amazon Prime Video、Netflix、Hulu、dtv、AbemaTV、Twitch...多くの動画プラットフォームがスマートSTBへ既に進出しており、そしてこれからも増え続けることが期待できる。
更には大抵はDLNAに対応しているに加えて、Sambaサーバー・クライアントを機能を提供するアプリもあり、既存のメディア資産を簡単に有効活用することができる。
当然、音声コンテンツもあってSpotifyでの音楽や様々なアプリでPodcastも聴ける。
ゲームタイトルすら配信されており、Bluetoothゲームパッドなどを接続してゲームも出来る。
というわけで以下に様々なスマートSTBの傾向を書いておく。ちなみに以下にあるものを全部所有しています。
スマートSTBの代名詞、高次元でバランスの取れた買って失敗なしのスマートSTB。
スマートSTBは廉価なローエンドモデルから数万円クラスのハイエンドモデルまで様々あるが、AppleTVはハイエンドに位置し性能に関して全くの不足感がない。
AppleのデザインしたUIはわかりやすく、操作レスポンスもヌルヌルサクサクとストレスを感じさせない点が好印象。ローエンドモデルではこうはいかない。
現行世代では4K出力が可能で、今秋にリリース予定のtvOS12でDolby Atmosをサポート予定。
Apple製品らしくApple AirPlay、iTunes Videos、Apple Musicなどにも対応しており、macOSやiOSとの連携も得意。
欠点は悪い意味でApple製品らしくストアへ配信できるアプリに縛りがあり、例えばWebブラウザが存在しなかったり、その他にコアなことをやろうとしてもアプリが存在せず、解決するにも一般的なユーザーではハードルが高いというのが欠点。
ちなみにこういう方向の解決方法は自分でアプリをビルドすることなので、最低限macOSが必要というのもハードルの高さに繋がっている。
AppleTVの対抗馬、ローエンドからハイエンドまで玉石混淆であり狙い目はハイエンドモデル。
SONY製TVに搭載されていたり、レオパレスにLife StickというAndroidTVが標準提供されていたりするけれども、大抵はローエンド〜ミドルレンジモデルであまり良い印象を持たれない傾向のあるスマートSTB。
特にAppleTVを体感済みのユーザーからはボロクソに叩かれる傾向があり、その理由はローエンドモデルではそもそも積んでいるSoCの性能が低すぎて操作レスポンスが最悪なのだ。
ただこれはローエンドモデルの話であり、前述したとおりに狙い目はハイエンドモデル。4K出力対応と謳われている数万円クラスのAndroidTVが大抵それ。
ハイエンドモデルであればレスポンスの悪さはある程度解消され、重いゲームもサクサク動く。
AppleTVとは違い、AndroidOSらしくストアで提供されていないアプリも自己責任でインストール可能で、ストアにもWebブラウザが提供されていて多少コアな使い方もできる。
GoogleプラットフォームらしくChromecast、Play Music、Play Movie＆TVなどへ対応している。ちなみにマウスが必要だけどChromeブラウザやEvernoteなども動く。
Chromecastに対応しているのでGoogle HomeやGoogle Assistantからも操作できる。
ハイエンドAndroidTVでオススメはnVidia SHIELD AndroidTV、Xiaomi MiBox3など。
「えっ？AndroidTVとは何が違うの？」と思うかも知れないけど、AndroidTV Boxはスマートフォン・タブレット用のAndroidOSをSTB端末へインストールしたもの。
当然ながらストアもスマートフォン・タブレット用のものが表示され、UIはタブレット用となる。
その名称の紛らわしさもあり勘違いされ易いが、Googleが公式に承認した製品ではない。
利点は価格の安さ、内部ハードウェアもスマートフォン・タブレットと共通の場合が多くありハイエンドモデルが求めるなら搭載しているSoCにSnapdragon800番台を選べば良いというわかりやすさがある。
スマートフォン・タブレットと同じアプリが使えるという利点もあるが、スマートフォン・タブレット用のアプリはリモコンに多くある十字キーでの操作を想定していない場合も多くあるので、アプリをまともに使えるか？と言われると悩まざるえない。マウスとキーボードを用意したらリモコンのみよりはまともに使える。
大画面でスマホゲームをプレイしたいというような需要にマッチするかも？ただし日本製ゲームの多くは縦画面だ。どうしても日本製ゲームをプレイしたいならTVを縦設置しようｗ
ただ最大の注意点を言っておくと日本製ゲームというよりUnityで開発されたアプリの中にはタッチ操作に対応しているけどマウス操作(特にドラッグ＆ドロップ)に対応してないことがあるので注意だ。
ぶっちゃけ中身はAndroidOSなので基本的にできることはAndroidTV Boxと変わらない。Chromecast機能も使える。当然Amazon EchoやAmazon Alexaから操作できる。
Amazonらしくプライム系サービスをサポートしていてプライムビデオやプライムミュージックを楽しめる。
やはり最大の美点はプライム会員にありプライム会員だと安く買えたり前述のプライム系サービスを使えることだろう。
ただ最近はプライムビデオが他のプラットフォームに提供開始されたりしていて、プライムビデオ目的だけならFireTVじゃなくとも良いかもしれない。
Chromecast機能に特化したスマートSTB(って言って良いのかな？)。
VLC Media Playerあたりから自宅のメディアサーバーからChromecastへ飛ばすということも可能なので「TVでWebブラウジングしないしゲームとかしないし」という需要にマッチする。
Google HomeやGoogle Assistantからも操作できる。
何でも自分でDIYしたい人向けスマートSTB界のダークホース。
ハードウェアとしてのスマートSTBとは違い、KODIは自由度の高い万能なメディアプレーヤー・サーバーとして位置する。
このKODIを使わなくなったノートパソコンやRaspberry PiみたいなシングルボードコンピュータへインストールしてスマートSTBとして使うわけだ。
DLNAやSamba、FTPなどに対応しており既存のメディア資産を活かせるばかりか、プラグインによってYoutube、Netflix、Spotify、Twitch、Play Music、Podcastなど欧米系の主要サービスに対応。
更には外部機器は必要だけれどTVの地上放送などをPVRして視聴・録画まですることが可能など何でも出来てしまう自由かつ高機能さ。
プラグインを自作すると事実上何でもできてしまうためハードルの高さはあるけど最強のスマートSTBプラットフォームになっている。
他端末のKODI同士で連携し制御しあったり、Webブラウザ経由でのリモートコントロール、スマートフォン・タブレット端末用のリモコンアプリもリリースされており操作性も申し分ない。
もっと加えてしまえばKODIはAndroidOSやAppleTV(自前ビルド必須)、AndroidTVやAndroidTV Box、FireTV、FireTV Stick、Windows OS、mac OS、UNIX OS、Linux OSなどクロスプラットフォームへ提供されているので、既製品のスマートSTBを買うとKODIも使えてしまうのだ。すごい！
何も考えずにストレスなく使いたいよ！
多少ストレスあって良いけどAppleTVみたいな縛りは嫌だよ！
mac os high sierraでスキャンしたときに、OCRをするとページがバラバラになる問題について。
scansnap 1500Mのドライバページ http://scansnap.fujitsu.com/jp/downloads/model/s1500m-1.html
からドライバを落としてスキャンすると、scansnap managerは動くが、pdf makerがOCRを行うとページがバラバラになる。解決策を探したがはっきり書いているところ（というよりこのバグ自体ほとんど書かれていないのでじぶんだけなのかもしれない）がなかったので、ここに書く
解決策
実はS1500mのmac os high sierra用ドライバは別に用意されている。
http://faq.pfu.jp/faq/show/2126?site_domain=scansnap
ここに書いてある
1) ScanSnap Manager V6.3L50 をダウンロードしてインストールしてください。
2) 1)をインストール後、必要なOCRパックをダウンロードしてインストールしてください。
・OCR パック（アメリカおよびヨーロッパ） V1.0L10
3) 続けて、ScanSnap Manager V6.3L61アップデートをダウンロードして適用してください。
4) 続けて、ScanSnap Manager V6.3L70アップデートをダウンロードして適用してください。
でうまくいった。
Sublime Textの記事を書こうとしたところ、こんな記事があったのでmacユーザーとして書いてみます。
読んだ記事
http://diary.netank.net/entry/2017/06/07/202630
＝＝
>なぜコスパ最悪な"Mac"を使っているの？Windowsサイコーじゃん
>MacBook Proの価格を調べてみると、Appleストアで一番安いTouch BarとTouch IDなしの13インチモデルで税込15万4224円です。
>Intel Core i5（デュアルコア 2.3GHz）
>です。性能的には、Windowsのベーシックモデル（普及帯モデル）と同程度。
>皆さんが欲しいであろうTouch Bar（Fキーの部分がディスプレイ）と
>Touch ID（指紋認証）機能付きモデルはもっと高くて、税込214,704円～となりま>す。
>Intel Core i5（デュアルコア 3.1GHz）
>この性能でこの価格。あなたはどう思いますか？しかも、Macって家電量販店での値引きもほぼ不可能です。
⇨同感です。10年選手ですが、macのおかげで散財させられています。
>
>最新のMacBookProやMacBook無印には普通のUSB端子がありません。スマホなどでも使われ始めている小型のUSBタイプCにすべて置き換わってい
>USBタイプCから普通のUSBに変換するケーブルも売られていますが、わざわざ使うのが面倒です。USBタイプCを採用する機器も登場していますが、>需要が少ないためか滅茶苦茶高いです。
>Windows機であれば、超薄型なモデルでも従来のUSB端子が付いている場合がほとんど。
>普通のUSB端子を廃止するとか頭おかしいです。どう考えたって不便でしょ。
⇨同感です。それまで仲良くしてた仕様をいきなり切ったり困りものですよ。
>Macを使う人の多くが、本体デザインの美しさが理由じゃないでしょうか？確かにカッコよくて、美しいデザインであることは僕も否定しません。
>（最近では群馬でもMacBookをスタバで使う人が登場してます。恥ずかしくないのって思ってます。）
>重たくないですか？
>美しいアルミボディーを採用したためか、MacBookPro13インチで1.37kgもあります。Windowsノートなら、ほぼ同程度のスペックで1kgを切って
>いるモデルも沢山あります。13インチなのにモバイル向きではないのが残念すぎます。
>性能の低いMacBook無印なら0.92kgですが、性能のわりに価格が高いので個人的にありえない選択です。
>Windowsノートはデザインがカッコ悪いと批判するMacユーザーも多いですが、Windows機の良いところは種類が豊富なところです。
>デザイン優先のカッコいいモデルから、低価格で実用性重視のモデル、頑丈で軽量なモデルまで様々です。
>デザインが美しいWindows機なんていくらでもありますよ。ちゃんと探しましたか？
⇨同感です。macは美しいですが、確かにwinでもキレイなものはいくらでもありますよね。
>MacOSのすばらしさを主張する人もいますが、それはないですね。MACにできてWindowsにできないことなんてほぼないと思います。
>足りない機能はフリーソフトでいくらでも拡張できます。
>ソフトの豊富さではWindowsが圧勝です。MAC向けにしかなかった一部のプロ向けソフトも、現在ではウィンドウズ版もちゃんとあります。
⇨同感です。過去はそうだったかもしれませんが、winも同様に素晴らしいものを持っています。
>一部の業界を除いて、ほぼすべての会社のPCはWindowsです。あなたの会社のPCもWindowsだと思います。
>僕が製造業で仕事をしていたころは、自社や取引先を含めて、MACを使っている人なんて一人もいませんでした。全員Windowsです。
>どんなことでも同じですが、全く操作性の違うものを2つ併用して使うのは辛いです。会社はWindows、自宅はMACというのはイライラするはずです。
>実は僕も2年位前にMacBookProを使っていたことがあるのですが、やはり共通性という面で苦労しました。
>結局、会社に合わせる形でMacBookProは売却してWindows機を買いなおしました。
⇨同感です。二兎追うものは一兎をも得ずです。
>会社がWindowsなので、大学生は絶対にWindowsを選ぶべきです。会社に入ってから、「Windows触ったことありません」なんて
>就職後のことも考えれば、圧倒的にシェアが高いWindowsを選ぶべきだと僕は思います。
>まぁ、フリーランスとかデザイン業を目指しているのであれば、MACでも良いかもしれませんが。
⇨同感です。入社という未来があるのに今がよければという考えはもってのほかです。
>MACはウイルスに感染しにくいことを自慢する人も多いですが、それも間違いです。MAC向けのウイルスなんて大量に存在しています。
>Windowsよりユーザー数が少ないから、あまり話題にならないだけです。
>ちゃんと、MAC向けのウイルス対策ソフトだって売られてますよ。安全だという思い込みによって、セキュリティー意識が低下する方が怖いです。
>ちなみに、Windows10ならOS自体にウイルス対策機能が搭載されています。家庭利用なら別途ウイルス対策ソフトを入れなくてもウイルスに
⇨同感です。意識が低下して感染する可能性は大いにありますね。
>MACはソフトもハードもAppleが作っています。そのため、安定性が高いとか、ソフトの最適化が進んでいるとか、主張する人も多いです。
>でも、僕がMacBookProを使っていた時は、特別なソフトをインストールしていないにも関わらず、結構フリーズしてましたよ。
>頻繁に動作不良問題も発生しているので、大して安定しているとも言い難いと思います。
>そもそも、MAC OSって、BSD系UNIXベースなので、Appleが一からOSを作っているわけではないです。
>最近のWindowsはほぼブルースクリーンやフリーズが発生しないですし・・・MAC OSがWindowsより安定しているという主張は納得いきません。
⇨同感です。急な不調を訴えて働くなったりでは困りますよね。
>MACユーザーはよくWindowsのフォントが酷いとか、UIがダサいとか、批判します。でも、それって本当でしょうか？
>僕はWindowsのUIやフォントは好きですよ。むしろMACのようにデザイン重視ではなく、実用性も考慮しているので、使いやすいと思います。
>正直言って、Macのフォントは無駄にアンチエイリアスを利かせすぎていて、綺麗だけど見やすくはないと思うんですよね。
⇨同感です。外見だけでなく実用性も備えているべきですよね。
>たしかにMacのトラックパッドは使いやすいと思いますが、最近のWindows機もかなり改善されています。
>激安モデルはあまり良いさわり心地とは言えませんが、MACと同価格帯の高級機であれば、凄く使いやすいと思います。
>そもそも、僕はMacBookのような大きなトラックパッドが嫌いです。キーボード入力時に誤動作する可能性が高いので、僕はレッツノートの様な小型タイプが好みです。
⇨同感です。昔はそうだったかもしれませんが他を探せばいくらでもいいものはありますよね。
＝＝
winにはとても素晴らしいPCがたくさんあります、価格も申し分ない。
それに比べてmacはコスパ良くないですし急にフリーズだってします。さっきもしました。
本気で苛立つことだって1度や2度ではありません。
そう認めてもなお、どうしてmacを使い続けるのか。
それは。
そう言えば、Sublime Textは「恋に落ちるエディター」と呼ばれています。
よかった、最後に元々書きたいことが書けました。
GitHubの謎生物が気になり、せっかくなのでIT界隈の動物(?)を用いた名前やロゴの由来など調べてみた。
※追記あり：Gopherファンに襲われそうなので。ごめんねGopher君
Q.どうしてタコなのに8本足じゃないの？
A.なにも考えずに描いたからね！
もともとデザイナーはoctopussと呼んでいたが、いくら訂正してもGitHubの社員がoctocatと呼ぶため、octocatで落ち着いた。
octocatはあの生物種の名称であり、monalisaという名前は社員の娘が学校の課題で名付けたもの。
種類：ニシキヘビ
名前： -
イギリスのコメディ番組『空飛ぶモンティ・パイソン』より。
またPythonという英単語はニシキヘビを意味するため、マスコットとしてヘビが用いられる。
オライリーの本とかすごい表紙だよね。
種類：ゾウ
種類：ゾウ
名前：slonik
「動物のロゴにしたいなら、象なんてどうだい？アガサ・クリスティの小説にもある『象は忘れない』だ」
― PostgreSQL発足時のメーリスより
種類：ゾウ
名前： -
象は記憶力が非常に優れた動物のため。PostgreSQLと同じで、象の優れた能力にあやかっている。
種類：ヌー
名前： -
種類：キツネ
名前： -
もともとPhoenixという名前だったが、商標権を侵害していたので、公募でFirebirdという名前に決定。
しかし今度はDBに同じ名前があったので、Firefox（レッサーパンダの別名）に改名。
みなさん命名は慎重に。
種類：クジラ
『白鯨（Moby-Dick）』より。クジラを採用した理由はデザイン見れば納得。
種類：ペンギン
名前はタキシード（Tuxedo）を着ているように見えるから。
ロゴコンテストで決定されたが、他の作品を見ればなぜ選ばれたのかよくわかる。デザインって大事。
https://www.cs.earlham.edu/~jeremiah/linux-pix/linux-logo.html
種類：鳥
名前：ラリー・バード
名前はNBAのラリー・バード選手より。社員がファンだったらしい
ちなみに初期のTwitterのデザインはGitHubのデザイナーが手掛けたもの。すごいっすね。
種類：シーサー
名前： -
種類：イルカ
名前：Sakila
種類：ネコ
名前： -
オライリーの本に載ることを考慮して動物をマスコットにしようと考え、「自立した強かさ」を持つという意味でTomcat（雄猫の愛称）を採用。
しかし、猫はオライリーのUML本で使われてしまい、念願のTomcat本にはユキヒョウが使われたという…。
種類：Dogcow（イヌ＋ウシ）
名前：Clarus
昔々、Mac OSで用紙の向きや色を表示するために使用されていたらしい。
知らんわ。
種類：ウサギ
名前：Glenda
OSの名前である「Plan 9～」はエド・ウッドの『Plan 9 from Outer Space』に由来。
ウサギの名前であるGlendaはエド・ウッドの『グレンとグレンダ』に由来。
どんだけエド・ウッド好きなんだよ。
ニュージャージーのWFMUラジオで、Renee Frenchによって宣伝用のTシャツに描かれたのが、彼の初登場。
その後、Bell labsのメールシステムでアバターとして起用もされた。
(ちなみにReneeはBell labsのGlendaを描いた人。Glendaもアバターの一員だった)
そうして2009年、Goプロジェクトが発足し、ロゴを検討していたメンバーにReneeが無償で描いてあげたのが「Go gopher」である。
みんなGo Gopherと呼ぶので、特に固有の名前は無いらしい。
由来は下記サイトにありました。
https://blog.golang.org/gopher
検証したのはMBP2011, core i7/RAM16GB
設定画面のプロセッサー数をふやしたら、MBP本体のコア数の消費が増えるかと思いきや、複数コアをエミュレーションしているだけのよう。エミュレーションそのものにパワーを食われるのか、プロセッサー数の数値を増やすと体感があきらかに遅くなる。
ビデオメモリー割当量より、上記のプロセッサー数での影響のほうが大きい。1の状態のほうがスムーズ。
iPhoneが発売され、一般人に浸透した事によって、いわゆるApple"ニワカ"信者が巷にあふれる事になった。
奴らは一言目には「ジョブズ」といい、Appleストアをやたら神聖視する。
正直、鬱陶しい。そこで信仰度を試してやる事にした。
=================================================
Apple Iを持っている。
Lisa 1を持っている。
スパルタカスを定価で買った。(レシートもクリスタルも持っている)
So farを持っている。
Dyna Macを持っている。
jack hammerを持っている。
機能拡張フォルダを正確に説明し、コンフリクトが起きた場合は修正出来る。
=================================================
上記の物を持っていたり、即答出来た者だけが、信者だと思うなぁ。
個人的に一番簡単な信者判別法は"メールアドレスが@mac.comである。"だと思っているが、他に何か有れば追加よろしく〜
私は大学生の身分でありますが、先ほど、私の所属する大学の学生を称する電子メールが送付されました。
送信元ドメインは"gmail.com"で、内容は以下の様なものです（編者により行間削除および省略あり）
１件目
件名：(火曜3限)Facebookグループ「プログラミングノウハウ共有グループ@インターネット」へのご招待
お世話になります。慶應義塾大学環境情報学部3年の○○と申します。
火曜3限「インターネット」でいよいよ全員がプログラミングに取り組まなければならなくなりました。
今後実装を進めて行くわけですが、プログラミングには正直自信がない……という方も多いかと思います。
そこで、サンプルコードの改造ノウハウなどを共有するFacebookグループを立ち上げました。
是非、ご参加いただければ幸いです。
プログラミングはかじった程度ですが、私で答えられることであればいつでも対応したいと考えております。
あと、もしよろしければ友達申請させていただければ幸いです。
友達になればもっとリアルタイムでプログラミングの相談に乗れるかとおもいます！
皆で頑張りましょう。
２件目
件名：(火曜3限)"プログラミング学習でよくある失敗例"(インターネット)
(火曜3限)"プログラミング学習でよくある失敗例"(インターネット)
（編者後略：このあと100行以上、2000文字以上にわたってプログラミングのハウトゥ（というには非常に稚拙だが…）が書き連ねられる）
この「火曜３限インターネット」という授業の履修者に向けたであろうメール、私は確かに当該授業の履修者ではあるのですが
知人に聞いてみたところ、このメールは、当該授業の履修者に向けて送信されているうえ、「一部の履修者でない学生」にも送信されていました。
さて、このメールが、本当にこのメールに書かれている本人のメールであれば、「ある種意識の高い学生」が、授業の取りまとめを行う意図でメールを送ったということになります
（それだけでも不特定多数への広告メールに分類されうる要因は十分満たしていますが）
ですが、本当に怖いのは、「何者かが当該学生の身分を騙り、不特定多数の本学学生にメールを送っている」という事案だった場合です。
そういったものであった時のために、先ほど「日本データ通信協会」なる機関が設置する迷惑メール転送先アドレスに、通報を行いました。
迷惑メール相談センター｜情報提供のお願い｜JADAC.html http://www.dekyo.or.jp/soudan/ihan/
迷惑メール、スパムメールを止める方法を実行したら、業者がさらに進化した - NAVER まとめ http://matome.naver.jp/odai/2139098130927121201
これらの機関は、迷惑メールの根絶を目標に、迷惑メールの転送を要請しています。
手順はこれらのURLが示す通り、meiwaku@dekyo.or.jp に、元のメールを添付ファイルとして転送します。
Mac OS上、メーラーとしてThunderbirdを使用している場合には、メールを選択し、
サブクリックメニューから「形式を指定して転送」→「添付ファイル」とすればよいです。
今回メールを送信するに至った理由は、以下文面に書いてあるのでそちらを参照ください。
お世話になっております。慶應義塾大学＊年の＊＊＊＊と申します。
このたび、本学学生の氏名を騙り、Bccを用いて多数の学生に同報されているメールを受信しましたので
こちらにご報告致します。
こちらの内容によると、授業の履修者に向けたメールであるような内容でありますが、
現段階で当該授業を履修していない学生に対しても、送信が行われていることを確認しております。
本学の学生が取得しているメールアドレスは、アカウント名において「英字1文字＋数字5文字＋英字２文字」で構成されており、
総当りによるメール送信が行われているおそれがあります。また、件名への「※未承諾広告」の表示を確認できません。
メール本文中に本学学生のFacebook（SNSサービス）及びFacebook上で作られたウェブページへの誘導があります。
リンクされている学生と同じ氏名の学生が、実際に本学に在学しているようではあるのですが、私は当該学生との面識はなく、
こちらのfacebook個人アカウントやメールがある業者による営利のもの（つまり当該学生を騙ったダミーページ）であるかの判断がつきかねます。
facebookページ上、現段階で営利のサービスとのつながりは見受けられませんが、将来的に何らかのサービスへ誘導されることを懸念しております。
また、送信者が本学の学生でない場合に、本学の授業に関連する情報が記載されている件につきましては、
本学がインターネット上へのシラバスや、授業内での twitter発言の公開、また本学が授業ををitunes Uや、
ウェブサイト上で配信していることから、内容の推測ができたものではないかと考えております。
http://gc.sfc.keio.ac.jp/cgi/class/class_top.cgi?2014_26708
よって、こちらの電子メールが、特定電子メールの送信の適正化等に関する法律に定める
の可能性があると感じられ、以上の通りご報告いたします。
なお、ここで転送の理由とした「特定電子メール（迷惑メール）」ですが、
http://web-tan.forum.impressrd.jp/e/2009/07/28/5712
によると「SNSへの誘導」を含むメールはそのメールに該当しうる、と記載があります。
また私は、当該のメールに対して送信の容認をしていませんので、
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
1つ大きく勘違いしてるのは、製品を売ったらそれで終わり、なんてことはあり得ない。
特にあれだけの金額を出す製品ならその後のサポートってのは超重要。
勿論増田にいる皆様におきましてはサポートなんてどうでもいい、と思うかもしれないけど、
一般的にはボタン一個分からないだけでも教えろよ、っていう人もいくらでもいるので。
バグがあったらなおさんといかんし。
なので運用コスト、って意味では別に変わらん。(勿論、超一過性の昔のゲームみたいなものなら別だけど、そのへんも変わってきてるので)
そりゃそうだろ。オフィスやフォトショップがそっちに切り替えられるってのはその絶対的な信頼が大きいでしょう。
まあでも、今の時代、一発で売ってくれる物があったとしても、そんなものは1ヶ月もすれば廃れてしまう様な時代なんだから、
別にそんな事を気にするところではないと思うが。
むしろ、一発売りの場合、その後バグなどの修正をずっと無償で行っていかないといけないわけで。
あれこそ、巨大な力持った企業じゃないと出来ないことだと思うけど。
就活中の増田です。ものすごくイラついたので愚痴を投稿します。
このあいだ、志望企業の一つにESを提出したんですよ。なかなかにユニークなESで、書くのが結構楽しくてね。
おまけにこのどこの大手も手書きでES書かせるこのご時世に、Web提出ってもんだから、かなり好感を持っていたんですよ。
ノリノリでES書いて提出後、しばらく経ったら今度は、Webテストを受けなさいってメールが届いたんですよ。
だからメールに添付されてたURLクリックして、いざテストを始めようとしたんですね。
そしたら突然、テストページで、動作環境チェックっていうのが始まったんですよ。
待ってたら数秒後、あんたのChromeじゃ受けられませんよって画面が表示されたんですよ。
しゃーねーなと思ってブラウザSafariに変えて再度テストページにアクセスしてみたんですよ。
その理由がね、酷いんだよ。ほんとに酷い。
このままでは受検できません。
で、これが☓が出た項目ね。
推奨環境：
Mac OS X： 10.5.x, 10.6.x, 10.7.x, 10.8.x
Safari： 3.0, 3.1, 3.2, 4.0, 5.0, 5.1, 6.0
……。
今のMac OSの最新バージョンは10.9系だっつーの！！！！ Safariは7.0だっつーの！
要するに、最新のOSとブラウザにバージョンアップしていたら、Webテストを受けられないのだ。
でもOSなんてメジャーアップデートでもない場合、無意識にアラートの「はい」ボタンクリックして更新しちゃうのが普通だし、ブラウザに至っては勝手にアップデートするタイプなので対策のしようがない。
以上のことから類推するに、この企業はMac厨はお呼びでないってことっすね。御社の稼ぎ頭は自他共に認めるAppleファンなのにねぇ。
こんなゴミテストを採用してる企業の人事はマジでどうかしてるよ。
まぁ、愚痴っててもどうにもならないんで、実家か大学のWindows機使ってなんとかしますけどね……。
ユーザーエージェント？ っての偽装する方法あるんだろうけど、慣れないことして失敗したくないしね……。
追記：
トラバによると、SafariにはデフォルトでUA偽装機能ついてるらしくて無事受験できました。
http://blog.elliottkember.com/chromes-insane-password-security-strategy
http://news.mynavi.jp/news/2013/08/08/054/index.html
http://www.itmedia.co.jp/enterprise/articles/1308/08/news033.html
このニュースは取り上げるサイトによっては、Windowsで動作確認した記者がFirefoxと比較してどうのこうのと語ったり、ブコメもドヤ顔で「今まで知らなかったのか」「気付かなかった奴が騒いでる」って見方のブコメを散見するがそれも違和感を感じる。
そういう話じゃないんだよな。
Macでは、Chromeが正式版になってパスワード管理がキーチェーンと連結されて実装された当初、Chromeの設定画面からパスワードを確認する場合はキーチェーンが立ち上がる仕様だった（はず）。
（ベータ時代はパスワード関連の設定画面ではまだ開発中と表示されたはず。ただちょっとそのあたり、ベータが取れる前後は記憶が定かでない。なんせベータとの違いがよく分からない有様だったから。記憶違いだったら申し訳ない）
http://internet.watch.impress.co.jp/docs/news/20091209_334515.html
例えば、Mac OSのパスワード管理機能「キーチェーン」がGoogle Chromeに統合されたため1カ所でパスワードを管理でき、他のブラウザで入力したパスワードをGoogle Chromeで利用できる。
あくまでキーチェーンの扱いはSafariと同じだったし、この時はSafariからパスワードを直接インポートできなかったと記憶している。
ちなみに、ヘルプの記載でも現在もキーチェーンで保存してるとしてる。
https://support.google.com/chrome/answer/95606?hl=ja
Google Chrome では、さまざまなウェブサイトのユーザー名とパスワードを保存することができます。そのようなウェブサイトに次回アクセスすると、ブラウザによって自動的にログイン フィールドに入力されます。
これらのパスワードは、その他のブラウザのパスワードが保存されているのと同じシステムに保存されています。Mac の場合、Google Chrome はキーチェーンアクセスを使用してユーザーのログイン情報を保存します。
おそらくこの記載はキーチェーンとの連携ができるようになった当初のものだろう。この後ろにchromeアカウントの話を付け足したのか。
とにかく、MacOSのほぼ全てのブラウザがキーチェーンによるパスワード管理をやってて（キーチェーンはアクセスできるアプリケーションを管理でき、ブラウザ以外も依存している）、ここに委ねてる。
だからパスワードの確認はキーチェーンで行う理屈で、Chromeのベータが取れた当初はそうだったはず（私の記憶では）だし、そうでなくてもGoogleの説明を受けたMacユーザーはそういう認識だ。
ようするに、MacユーザーからするとSafari等のキーチェーンを利用するアプリケーションと同様の方法で管理してますよって言ってるのに、実態が違うじゃないかっていう指摘だ。
（たしかWindowsにおけるIEも同じようにシステムの管理だと思う。この話において、Mac/Windows対応であるFifefoxは例外なんだが、その管理と同等のレベルにしようという事で、それに倣ってマスターパスワードを装備している。ちなみにデフォルトじゃないという反論の意味がよく分からない。）
また、キーチェーンによるURLの認識方法がセキュリティ的に問題で、Chromeは違いますよっていう話があってもいいはずなんだけど、Googleの反論はそうでもないようだからそっちとは違うみたいだ。
思うに、Googleとしてはデータ上は平文保存してるのに画面上見えないだけって実態がセキュアじゃないとか本当は言いたいんだろうけど、しかし平文保存してるからこそSafariからパスが抜け、だからこそSafariからの移行組を確保しているからで、このことをおおっぴらに言うことはないと思う。
