プログラミングをゼロから始める人のためのRubyプログラミング

目的

プログラミングの基礎を学ぶ

なぜRuby？

Ruby意外のしんどさを書いてく。

言語	しんどさ
Java	IDEなしに素のプログラミングをやらせるの辛い。IDE経由だと何しているかわかりにくい
PHP	Apache経由の動きだけになりがち。一番最初はレイヤーが浅い方がいい
Perl	もう情報が少ない（リファレンス／デリファレンス／UTF8フラグが無駄にしんどい）
Python	次点としてありだが、Python3が完全普及するまで待っていいのでは？
C	自分はここから入ったのでいいけど、業務では使ってないので遠回りがすぎる。core dumpは初心者には遠回りがすぎる。

ということで、ターミナル上で、標準入出力を使ったプログラミングの基礎を学ぶには、Rubyが「ちょうどいい」。

標準入出力にとことんこだわる

• 業務でも十分使える
• いきなりMVCフレームワークを使うと階層がわからず迷子になる
• Webフレームワークの環境構築で悩まなくていい
• 多言語言語でも通用する考えなので、OS／IOとプログラミング言語の階層構造が理解しやすい。

標準入出力をベースにしたプログラミングの試験はスタンダード

PaisaやAtCorderやCodeIQなどのサイトは標準入出力で答え合わせをしている。それくらい「スタンダード」

学習の順番

• Hello World
• 引数をもらって「こんにちは◯◯さん」と出力
• 標準入力をもらって「こんにちは◯◯さん」と出力
• 標準入力で入ってきた小文字アルファベットを大文字にして出力
• 標準入力で入ってきた数字を倍にして出力
• 標準入出力をつかって対話型じゃんけん

次に覚えるのはSQL

AcitveRecordをいきなり触らない。裏で流れているSQLを知らないで開発できるかっていうと、直接SQLつかう機会は多い。ゲームのディレクターはエンジニアでなくてもちょっとしたSQLは書ける。もはやエクセルみたいなもん。

次に覚えるのはHTML

• フォームヘルパーは使わない。まずはformタグを全部かく。
• GETとPOSTの違いをしる。
• input、select 、radio、checkbox、texture、hiddenを一通り手で作ってみる
• Webアプリケーションフレームワークとしてはシナトラでお勉強する。Railsは何してるか分からないので。

次に覚えるのはcurlコマンド

• フォームでPOSTしている内容を、curlコマンドで再現してみる。
• ここで、ブラウザのデベロッパーツールの使い方を覚える（copy as curl）
• curlのパラメーターを変えて、何をリクエストすると何が帰ってきているかを知る。

・・・・続く。そのうち書く。あとは、そもそものLinuxの使い方として、grepとかlessとかvimとかsshとかscpとかその辺は徐々に覚える。

Googleのレファレンスを見ると自ずと言語の主観的評価が決まる

例えばこれ

https://cloud.google.com/datastore/docs/concepts/transactions

言語別に同じ機能を実現するコードが書かれている。

これを見ると、言語の思想が現れる。

意外なのが、Go言語のきったなさ。try-catchがなく、エラーが戻り値として返ってくる。それが全てifで分岐されているので、ビジネスロジックとしての分岐と、例外の分岐が区別し難い。実装上同じでも、ソースコードは人が見るものなので、ロジックとしてどう分岐されているのかをよみとりたい。

例外の分岐がテスト対象なのかどうかってところもあって、ファイルの読み取りの例外って、言語使用上はありえても運用上ありえなかったりして、テストする意味がないというケースもある。

Googleのレファレンスでは、Rubyが登場したりしなかったりする。海外ではスクリプト言語のデフォルトがPythonになりつつある。もうそれは認めないと仕方ない。

Node.jsもいいんだけど、処理が上から流れるのではなく、コールバックで繋いでいくから、「読む順番」が分かりにくい。コールバックをインデントするもんだから、ネストがどんどん深くなって、こんなコードになる。奥に奥に処理が流れるのつらー。

      });
    });
  });
}

コールバック嵐になるのって、実装上がそうだから仕方ないのかも知れないのだけれど、それは実装上の話で、ソースコードは人間様が読むのだから、多次元で読まなくちゃ行けないのってつれーって思う。

いちいち }); が登場するのが、文字数増えてやだなーとか。瑣末だけど。

まとめとしては、Googleのレファレンスをみていると、結局JavaとPythonなのかなーって風にみえる。（Googleが標準で使ってるからそっちによるのも無理ないのかなー）

チャットの使用感比較

グループチャットの問題点

チャットはイイとして、グループチャットで未だにしっくりくるのがない。あれこれ比較しているので、そのメモ。 結論としては、検索機能が充実していて、グループチャットでの通知のレベル感がしっくり来るのがない。チャットでもスレッドが欲しくて、フォローしているスレッドだけ通知が強いというのが理想だなーって思う。

ただ、通知の重さをコントロールできるという一点に置いては、以下の選択肢の中では、Slackが一番まし。持続可能。

PCとスマホで両方でアクセスできるというのが大前提。 （随時更新メモ）

Skack

Slackいいところ

• チーム ＞ チャンネルという階層で、細かく分類できるので、観ようと思えば見れるという情報と、重めに通知が欲しいところと区別できる
• Bot作りやすい
• プログラムソースアップしたらシンタックスハイライトしてくれる

Slackダメなところ

• 検索すげー面倒
• デスクトップアプリ落ちがち
• ラベルが英語なので、プライベートでの友人とやりとりする空気じゃない
• チームが増え始めると、PCアプリとスマホアプリの両方にチームを登録するの億劫（で漏れていそう）

Skype

Skypeいいところ

• 通話もシームレスにできる
• たくさんの人がすでにアカウント持ってる
• 日本語ラベル

Skypeしんどいところ

• メンション有無で通知の重さが変わらないので通知ウザ過ぎ（仕事ではじきに使われなくなる）
• スマホアプリうっかり通話しがち

FaceBookメッセンジャー

FBメッセンジャーいいところ

• FaceBookのお友達からアカウントが見つかる
• PCでもFaceBookでやりとりできる（ブラウザで便利）
• 一時的に通知をとめるインターフェースが分かりやすい

FBメッセンジャーダメなところ

• やっぱり一度グループチャットになると、通知の重さがコントロールできなくて、他人の雑談も常に通知がくる

LINE

LINEいいところ

• スマホ持ってりゃほぼ100%に近いインストール率

LINEダメなところ

• PC版をインストールしてる人少ない（アカウント乗っ取り騒ぎもあって外部ログインを許可しない人も）
• プライベート過ぎて他の人に教えづらい（連絡取りづらい）
• 通知の重さコントロールできない

gmailチャット

gmailチャットいいところ

• gmailアカウント持ってる人やGoogleAppsを使ってる人は多いので使える人は多い

gmailチャットダメなところ

• グループチャットできるように見えない
• グループチャット始めてもエスケープ一発で消えて二度と開けない（再表示の導線深すぎ）
• Google+ハングアウトって名前になってみたり、Google+との関係性が分からない