確率論の小話 (2)
先日書いたベイズ統計と古典統計の違いについてのシミュレーションプログラムを作成したので掲載します
カードのクラスを定義
class Card attr_reader :suite attr_reader :rank def initialize(suite, rank) @suite = suite @rank = rank end def is_dia? @suite == 'dia' end end
52枚のカードの集合（デッキ）を定義
class Deck def initialize @deck = [] end def add(card) @deck << card end def shuffle! @deck.shuffle! end def draw @deck.pop() end end
ゲームの一連の流れをクラスに定義
class Game @@suites = ['spade', 'heart', 'dia', 'club'] @@ranks = [1..13] attr_accessor :card_in_box def initialize @deck = Deck.new @@suites.each do |s| @@ranks.each do |r| card = Card.new(s, r) @deck.add(card) end end @deck.shuffle! @card_in_box = @deck.draw end def draw_three_cards 3.times.map{|n| @deck.draw} end end
シミュレーションの実行
# 箱にダイヤが含まれる単純な確率 games = 1000 count = 0 games.times do |g| game = Game.new card_in_box = game.card_in_box if card_in_box.is_dia? count += 1 end end printf("Frequency principle : \t%.4f", count.quo(games)) rest_games = games count = 0 while rest_games > 0 do game = Game.new three_cards = game.draw_three_cards # 引いた3枚のカードが全てダイヤの時 if three_cards.all?{ |card| card.is_dia? } limit -= 1 # 箱に入っているカードもダイヤかどうか if box_in_card.is_dia? count += 1 end end end printf("Bayes principle : \t%.4", count.quo(games))
AngularJSでグローバルに利用できるモデルを定義
多くのサイトで紹介されているAngularJSのモデル定義方法は、HTML内にngModelとして以下のように宣言する。
<div ng-controller="ExampleController"> <form name="userForm"> Name: <input type="text" name="userName" ng-model="user.name" ng-model-options="{ getterSetter: true }" /> </form> <pre>user.name = <span ng-bind="user.name()"></span></pre> </div>
Factoryクラスの定義
リアルタイムなモデルの値変更をする場合はこれでよいが、ユーザーモデルのように、複数のコントローラで使用されるモデルが存在するならFactoryクラスを定義するのがよい。
angular('myModule').factory('User', function () { /** * コンストラクター */ function User (name) { this.name = name; } /** * ゲッターメソッド */ User.prototype.getName = function () { return this.name; } /** * セッターメソッド */ User.prototype.setName = function (name) { this.name = name; } return User; });
Factoryクラスの使用
コントローラー内でモデルを使用するなら以下のように書く
var injector = angular.injector(['myModule', 'ng']); var User = injector.get('User'); app.controller('UserCtrl', ['$scope', function($scope) { var username = $scope.name; var user = new User(username); }]);
確率論の小話
7年前に2chで話題になった、確率に関する問題（早稲田の入試問題？）の解説にいいものが見当たらなかったので、自分なりにまとめてみる。
問) ジョーカーを除いたトランプ５２枚の中から１枚のカードを抜き出し、 表を見ないで箱の中にしまった。 そして、残りのカードをよく切ってから３枚抜き出したところ、 ３枚ともダイアであった。 このとき、箱の中のカードがダイヤである確率はいくらか。
現代の確率論について
そもそも現代の確率の考え方は、
- 無限に実験 (厳密には試行という) を重ねて、その結果から導出する頻度主義
- ある仮説をたて、その仮説が起こる確率を計算し、その後観測を行い、得られた観測結果から仮説の起こる確率を更新するベイズ主義
の２つが主流である
頻度主義からの考察
1の考え方と言うのは、(実際には不可能だが) 何度も試行を繰り返すことができることに対して確率を割り当てることであり、今回のトランプ問題も何度も試行を繰り返せるものだと考えれば、この頻度主義にそって確率を計算すればよい。
したがって、トランプのカードを取り出して箱に入れるという作業を何度も繰り返せば、総数52枚のカードから総数12枚あるダイヤのカードが取り出される確率に一致するため、13/52 = 1/4 という計算になる。(不安な方は、実際に実験してみればよい)
ベイズ主義からの考察
この問題の結果を大きく分けるのは、「3枚のダイヤが出た」というデータをどのように扱うかである。もしこのデータを考慮して確率を求めるなら、ベイズ主義が上手く当てはまる。
ベイズ主義による確率は以下の公式によって計算される。
p( H | D ) = p( H ) × p( D | H ) ÷ p( D )
HHypothes : ある仮説DData : 観測データ
p( H | D )というのは、Dというデータを得られたときにHという仮説が起こる確率であり、今回は
H→ 箱の中身はダイヤであるD→ ダイヤを3枚引いた
と適応できる。ここで右辺の3つの項について解説すると
p( H )→ ダイヤを3枚引いたことは無視して、Hが起こる確率。(事前確率)p( D | H )→ もし箱の中身はダイヤだったら、その後ダイヤを3枚引く確率はどのくらいとなるか 。(尤度)p( D )→ どのような仮説を立てたかに関係なく、ダイヤを3枚引く確率。(正規化定数)
となる。実際にこの3項目を計算すると、
p( H )52枚のカードから13枚あるダイヤが取り出される確率なので1/4p( D | H )箱の中身がダイヤなら、残り総数51枚のカードの中からダイヤが余り12枚中3枚取り出される確率は、(12 3) / (51 3) = 44/4165
ただし、(n m) = n! / { (n-m)! × m! } とする。
p( D )箱の中身に関係なく、ダイヤが3枚出る確率は、(13 3) / (52 3) = 11/850
長くなったが以上より、p( H | D ) = 1/4 × 44/4165 ÷ 11/850 = 10/49 となる( ≒ 0.20 < 1/4 )
つまり、「3枚もダイヤが出たため、箱にまでダイヤが入ってることは珍しいことになり、頻度主義の確率よりも低い確率と計算された。」と解釈できる。
ではどちらを採択すべきか
頻度主義は「実験 (試行)」を繰り返すことにより計算できるため、客観的に説明することができる。例えば今回の問題も、1000兆回くりかえせば必ず確率は1/4になるため、「ほら、4回中1回はダイヤになるでしょ？」と証明できるわけだ。
対するベイズ主義からの視点で考えると、今回はあくまで「ダイヤが3枚出てきた」という唯一の観測結果だけで考察しているため、今後実験を繰り返して確率が1/4だったといわれても関係ないのである。
まとめると、
- 頻度主義は「客観的で証明可能」な確率を導き出し、
- ベイズ主義は「主観的で現在所有しているデータのみで計算可能」な確率を導き出す。
今回の問題は、どちらの主義も採択可能なため、問題文中で非常に繊細な状況解説が必要となる。
例えば、「問題のような実験を繰り返しており、最終的にどのような確率になりうるか」といえば頻度主義を採択し、「カジノで有り金を全部かけてカードゲームをしている」のならばベイズ主義を採択すべきである。
個人的な意見
ここからはあくまで個人的な意見になるが、今回の問題は大学の入試試験で出題されたものであるため、以下のように大学の視点に立って主義選択をするのが大学生という身分として健全な思考なのかもしれない。
国公立大学の入試国民に公表できる客観的な考え方が望まれているため、頻度主義を利用する。私立大学の入試私(ワタクシ)の視点、つまり主観的な考え方が望ましいため、ベイズ主義を採択する。
追記
では頻度主義とベイズ主義では違う確率になるのかというと、実は「最終的」には一致する。
今回は「ダイヤが3枚出た」というデータのみでベイズ確率を計算したため頻度主義とは異なる結果になったが、3枚のダイヤをもとに戻してもう一度3枚引いてみて、例えば「クラブが2枚、ハートが1枚出た」というデータが得られたならば、ベイズの公式にそって確率を更新し、このようにデータをとって確率を更新する作業をずっと繰り返せば、結果は1/4に収まるのである。
したがって頻度主義とベイズ主義での確率は「最終的」には一致するため、ベイズ確率は「頻度主義で行われるたくさんの試行の過程の中で、一時的に算出される確率」と考えるのが望ましい。つまり、頻度主義とベイズ主義は相反するものではなく、頻度主義を分けてみるとベイズ主義が隠れているといった解釈をするのが良いと思う。
Heroku + Rails Tutorial (Qiitaの記事の流し)
Qiitaで作成した記事をこちらでも紹介させていただこうと思います。
元記事
はじめに
AWSを使ってWebサービスを作る人が僕の周りにも増えてきましたが、AWSは自由度が高く、初心者にはかなり扱いにくいと思います。
HerokuはAWSにホスティングされたサービスなので、AWSと似たような使い方が出来ます。 なので、いきなりAWSでRailsなどのプログラムを動かすよりも、一度Herokuで運営して経験値をためてみるとよいかと思います。
そこで、Herokuやアドオンを使ったプロジェクト作成手順の一連の流れを大雑把に覚えてみましょう。 (今回は、アジャイル開発を意識して記事を作成しました)
ここで紹介する内容は、AWSで同じことをやるときもAWSのサービスを上手く使えば、ほとんど同様に開発することが出来ます。
なお、Railsのインストール、Herokuのコマンドラインツールなどの導入方法などはRails Tutorialにすべて記載されているので、こちらを参考にしてください。
1. Railsプロジェクトの作成
まずは、Railsの新規プロジェクトを作成します。 HerokuのデータベースはPostgreSQLがデフォルトですが、アドオンを使ってMySQLに変更できます。
$ rails new [APP_NAME] -d mysql
2. Herokuの初期セットアップ
このセクションでは、Herokuアプリを新規作成して、データベースをデフォルトのPostgreSQLからMySQLに変更する手順を説明します。
Railsプロジェクトを作成したら、Herokuのアプリを作成して、HerokuにMySQLのアドオン「 ClearDB MySQL 」を追加してみましょう [HEROKU_APP_NAME]に入れた名前が、サービスのURLの一部になります。（後から管理画面で変更出来ます）
$ heroku create [HEROKU_APP_NAME] $ heroku addons:add cleardb --app [HEROKU_APP_NAME]
clearDBについては、アドオンを追加してもデフォルトのデータベースはPostgreSQLのままです。なので、Herokuの環境設定を変更して、デフォルトのデータベースをMySQLにしてあげましょう。
$ heroku config | grep CLEARDB_DATABASE_URL -> CLEARDB_DATABASE_URL => mysql://adffdadf2341:adf4234@us-cdbr-east.cleardb.com/heroku_db?reconnect=true -> ClearDBのURLが表示されるので、mysql://..... をDATABAE_URLにセットする $ heroku config:set DATABASE_URL='mysql://adffdadf2341:adf4234@us-cdbr-east.cleardb.com/heroku_db?reconnect=true' -> これで、デフォルトのデータベースがMySQLになった
RailsでMySQLをデータベースとして作成するとMySQL2がインストールされますが、HerokuでMySQLを使うためにはMySQLをインストールしないといけません。
# mysql for heroku production gem 'mysql'
もし、ローカル環境ではSQLite3を使いたい方は、GemファイルにSQLite3を追加して、config/databases.ymlを変更してあげましょう。
# sqlite3 database for localhost gem 'sqlite3'
development: adapter: sqlite3 database: db/development.sqlite3 pool: 5 timeout: 5000 test: adapter: sqlite3 database: db/test.sqlite3 pool: 5 timeout: 5000
あとはbundle installしてあげればOKです。
章の最後に、herokuにデプロイしてみましょう。
$ git add . $ git commit -m "initial commit" $ git push heroku master
3. 開発環境を整える
このセクションでは、Githubにリポジトリを作成し、ステージング環境用のブランチをGitに追加し、最後にHerokuのステージング環境をGitのステージング・ブランチに対応するように設定する方法を説明します。
さて、一通りHerokuのセットアップが終わりましたが、実際にHeroku上で運営する際に一番怖いのが、「 変更を本番環境にデプロイしたら動かなくなった！ 」というケースです。
実際にHerokuから離れていく人の多くは、このような悩みからでしょう。 しかし、Herokuでは「 ステージング環境 」を作ることが出来ます。
ステージング環境とは、本番用のサーバーと同じ環境で動かしてみて、不具合が無いかをテストするための環境です。
つまり、ステージング環境で予め修正したRailsプログラムの動作を確認しておけば、本番環境でサーバーがストップしてしまう危険性を格段に減らせます。
ステージング環境の作成
それでは、ステージング環境用のHerokuアプリを新しく作ってみましょう。
$ heroku create [STAGING_APP_NAME]
例えば[HEROKU_APP_NAME]が「foo-app」だとすれば、[STAGING_APP_NAME]は「staging-foo-app」とかでいいと思います。
gitにステージング環境のブランチを追加する
ここで、herokuにデプロイされたプログラムは、gitの production というブランチの環境を元に展開されます。 (database.ymlにもproductionって項目ありますよね)
なので、ステージング環境にアプリをデプロイしても、本番環境用のアドオンにアクセスされてしまったりします。そうなると、ステージング環境で色々テストしていると、本番環境に影響が及ぼされる危険性があります。
従って、ステージング環境にデプロイされたら、gitのstagingというブランチの環境にデプロイされるように設定します。 (ここからの設定はちょっと面倒ですが、一度設定すると運営時にプログラムの修正をデプロイや動作確認を行うのが非常に楽になります)
まずは、gitのコマンド打つのが面倒なので、SourceTreeでブランチの管理をしましょう。
私はよくSourceTreeを使ってgitの管理をしていますが、ステージング環境のブランチの作成手順までここに書くと長くなってしまうので、別の記事にまとめました。こちらを参考にしてください。
さて、上記記事では「develop, staging, master」のブランチが作成されましたが、これらのブランチの使い分けは以下のようになります。
| develop branch | staging branch | master branch |
|---|---|---|
| ローカルでの開発用 | 本番にデプロイする前のステージング環境用 | 本番環境用 |
従って開発の流れとしては、 「ローカル環境で開発したものはdevelopでpush」->「本番前の動作確認用にstagingでpush」->「動作確認が済めばmasterにpush」 といった感じになります。
基本的に開発の殆どは develop ブランチで行うと思います。不用意にstagingやmasterブランチでpushしないようにしましょう。
Rails + Herokuにstaging環境を設定する
gitのブランチにstagingを追加したので、railsやHerokuの方にもstaging環境を設定していきましょう。
このセクションのはじめに作ったステージング用のHerokuアプリの設定を変更します。
$ heroku config:set RACK_ENV=staging RAILS_ENV=staging
これで、ステージング用のHerokuアプリにpushしたら、stagingブランチの内容が適応されるようになりました。
最後に、Railsアプリの設定もstagingに対応させてあげましょう。
# 追加 staging: adapter: mysql2 encoding: utf8 database: latte-art_production pool: 5 username: root password: socket: /tmp/mysql.sock
SampleApp::Application.configure do # 環境設定を色々 # 基本的にproductionと同じでよい # ただし、環境変数などはstaging用に設定します # 例えばRedisのURLを設定するときはproductionと別のものをstagingで用意するので、staging用のredisのURLを設定します ENV["REDISTOGO_URL"] = 'xxxxxxx-xxxxxxx' end
以上でステージング環境の設定は終了です。
4. 継続的インテグレーション (CI: Countinuous Integration)の環境設定
このセクションでは、Githubにpushしたら自動的にHerokuにGithubのコードがデプロイされるように設定する方法を説明します。
stagingとmasterブランチをherokuとgitに設定しましたが、毎回GithubとHerokuにpushするのは大変です。
さらに、herokuにpushしても、以下のコマンドを実行しないとデータベースが展開されないので、コマンドを打つまでの間はサーバーが停止状態になってしまいます。
$ heroku run rake db:migrate --app [HEROKU_APP_NAME]
そこで、 Githubにpushされたら、自動的にHerokuにもpushしてrake db:migrateまでしてくれるサービス を利用してみましょう。
このようなデプロイを自動化することを、 継続的インテグレーション(CI) といいます。
私が使ってるCIのサービスでオススメなのが、「 Codeship 」です。
Codeshipは、Herokuのアドオンとしても提供されており、Githubにpushすると自動的にHerokuにデプロイしてくれます。
さらに、さきほど作成したstagingやmasterブランチをpushすると、どのブランチがpushされたか自動で認識し、ブランチ毎に別々のHerokuアプリにデプロイしてくれます。
このCodeshipの設定も長くなるため、別の記事にまとめました。 こちらの記事を参考に設定してください。
設定が終われば、SourceTreeで stagingにpush -> [STAGING_APP_NAME]に、masterにpush -> [HEROKU_APP_NAME]に自動的に適応されるようになると思います。
長くなりましたので、最後に開発の流れをおさらいします。
- developブランチで開発、commit & push
- stagingブランチから developをpull & push
- stagingで動作確認ができたら、masterブランチから stagingをpull & push
あとは待ってるだけで自動的にHerokuにデプロイされます。
5. モニタリングツールの導入
このセクションでは、運営時にHerokuのサーバーを監視するサービスの導入方法を説明します。
最後に、運営時に必要となるであろうツールの導入方法を紹介します。
ステージングや本番環境で上手く動作しているように見えても、実際に長期運営していると、思いもよらない不具合が発生することは必ずあります。
従って、日頃からモニタリングツールを使用して、アプリケーションの動作を監視し、不具合が発生すればすぐに原因を突き止めて改善していく必要があります。
私が特におすすめするモニタリングサービスは、 「New Relic, Papertrail, Rollbar」 です。
1. New Relic
New Relicを使えば、毎日どのくらいのユーザーがアクセスしているのか、エラーが発生した時間帯はいつ頃か、などの総合的な監視が出来ます。
機能はかなり豊富なので、この記事では紹介しきれませんが、とりあえず導入方法を説明するので是非使ってみてください。
まずは、HerokuにNew Relicのアドオンを追加します
$ heroku add ons:add newrelic --app [HEROKU_APP_NAME]
Herokuのダッシュボードにアクセスすると、アプリにアドオンが追加されているのが確認できます。
New Relicのアドオンをクリックすると、New Relicのサイトまでアクセス出来ます。
すると、数段階でNew Relicを設定する方法のページが出てくるので、ナビゲーションに従って設定してください。 (確か、環境の選択 -> keyの作成 -> yamlファイルのダウンロード -> Railsのフォルダに設置 -> Railsデプロイ って流れで設定できるはず)
あとは、数分待ってNew Relicにアクセスすると、PV数などのグラフが表示されていることが確認できます。
2. Papertrail
papertrailは、ログ情報を一定期間保存してくれるサービスです。New Relicだけではどうしてもわかりにくい不具合が発生した時は、papertrailのログ情報を見てあげると、解決策が見えてくるかもしれません。
また、大量のログを手作業で確認するのは大変なので、日付などを検索して、必要なログを見つけることも出来ます。
アドオンの導入方法は今までと同じで、設定自体も特にすることが無いので、Papertrailについては自分で触りながら試してみてください
$ heroku addons:add papertrail --app [HEROKU_APP_NAME]
3. Rollbar
ここまで2つのモニタリングツールを紹介しましたが、不具合が起こった時にすぐに気づくためには通知してもらわないといけません。
Rollbarは、Herokuで不具合が発生して、サーバーがダウンしたりした時に、メール等で通知してくれるサービスです。
デフォルトの設定では、Herokuに登録されたメールアドレスに通費が来るはずです。
アドオンの導入は、これまでと同じです。
$ heroku addons:add roll bar --app [HEROKU_APP_NAME]
最後に
いかがだったでしょうか？ ここで紹介したアドオンやサービスは、基本的にすべて無料で使用することが出来ます。従って、これからRailsを使ってWebサービスを作る際には、いきなりAWSに手を出さずに一度Herokuを使ってサービスを運営してみるのもいろしいかと思います。
誤字・誤謬、もっとよい方法論等があれば参考にさせていただきたいので、コメントよろしくお願いします。
RのWebフレームワーク「Shiny」を高速で体験する
RStudioでのグラフィックス作成に慣れてきて、次はサーバーサイドのRを書こうと思い公式ページを覗いてみると、RStudio IDE、RStudio Serverに加えて「Shiny」というRをWeb上で動かすためのフレームワークが登場してることを知り、チュートリアルをひと通り勉強したので、この記事でShinyの利便性について少しだけ触れてみようと思います。
1. Shinyをインストールする
この記事は、RStudio IDEがあなたのパソコンにインストールされていることを前提に記述しています。
もしRStudioが入っていない場合は、こちらのR公式サイトからDownloadしてください。インストール後に細かい設定はいりません。すぐに試してみましょう！
RStudioのコンソールから以下のコマンドを入力してインストールします
install.packages("shiny")
インストールが完了したら、ライブラリを読み込みましょう
library("shiny")
2. サンプルアプリを起動する
Shinyには、ライブラリのインストール時にサンプルアプリケーションが幾つか付属しており、コマンドを入力することによって簡単にサンプルを実行することができます。今回は3つのアプリケーションを起動して、Shinyを使ってどのようなWebアプリケーションを作ることができるのか見て行きましょう。
ライブラリを読み込んだら、すぐにサンプルを動かすことができます。以下では、サンプル起動のコマンドと、アプリケーションの画面、どんなアプリかの説明かをセットで紹介します。
(i) Example 1
- コマンド
runExample("01_hello")
- 実行画面
- 説明
こちらのアプリケーションは、左にあるスライダーで設定した値だけ乱数を発生させ、それを左のヒストグラムに表示するものです。中心極限定理によって乱数が正規分布に収束していく様子がわかります。
ちなみにコマンドを実行すると、自動的にブラウザが立ち上がってアプリケーションの画面が見れると思いますが、もし自動的にブラウザが立ち上がらない場合は、自分でhttp://localhost:7850/にアクセスしてみてください。
また、アプリケーションを終了するには、RStudioのコンソールに戻って
キーを押して終了してください。
(ii) Example 2
- コマンド
runExample("02_text")
- 実行画面
- 説明
Example1ではデータをヒストグラムによって可視化しましたが、このアプリケーションでは3種類のデータテーブル、そして代表値を表示してくれます。表示するのは一般的な代表値で、上から「最小値、第一四分位点、中央値、平均値、第三四分位点、最大値」になります。
代表値としては、他にも「歪度、尖度」などもありますが、ここでは表示されていません。他の代表値を追加されたい方は、ぜひshinyの具体的なプログラム方法を学んでみてください。（びっくりするほど簡単、簡潔に書けます）
(iii) Example 3
- コマンド
runExample("03_reactivity")
- 実行画面
- 説明
先ほどのサンプルとの変更点はほとんど無いのですが、左の入力画面の一番上に、タイトルを入力するためのテキストフィールドがあります。このアプリケーションでは、テキストフィールドに文字を入力すると、即座に右の画面に適応される様子を実証しています。
つまり、Shinyは非同期なアプリケーションを作成可能で、何度もHTTPリクエストを処理しなくてもよく、Webアプリケーションをサーバー上で運営するのが簡単であることが分かります。
3. まとめ
いかがでしたでしょうか？ 今回はサンプル・アプリケーションしか紹介しませんでしたが、実際に自分で同様のWebアプリケーションを作成する際も、shinyを使えばとても簡単にできます。
以下のリンクにチュートリアルが掲載されているので、shinyを気に入られた方はぜひ勉強してみてください！
現代のプログラマが習得しておくべき4つの技術
2014年もプログラマとして成長していくためにいろいろな行動を起こしていく際、自身にとっても初心者のプログラマにとっても身につけておくべきだと思う技術をまとめてみました。
1. Markdown
理系大学生なら、文章を作成するためにLatexのコマンドを利用して文章を整形していきますが、日常的にWeb上で文章を作成するにはLatexは少し面倒です。Markdownを使うことによって、Latexと同等まではいきませんが、整形された文章を作成していくことができます。
2. Git
チーム開発をする際に、メンバーのプログラムを共有するのによく使用されますが、個人的にも有効に使用できます。ある時点のプログラムに新しくソースを追加したら動かなくなった、という事態はプログラマなら誰もが経験されていると思いますが、Gitで管理しておけば、追加や変更をする前のプログラムに戻すことも可能です。
学習方法
あなたが今作ってるプログラム、本などを読みながら勉強用に作っているプログラムを、今すぐGitにぶち込みましょう。また、チーム開発をしている方なら、無料のGitクラウドサービスを利用してみましょう。現在無料で利用できる主要なGit用のサービスは以下の3つです。
3. HTML
文章を書いて多くの人に共有することは、プログラマやハッカーにとって非常に大切なことです。HTMLは先述のMarkdownと用法は似ているのですが、自分の伝えたい文章を綺麗に整形して、読者に見やすくする配慮はとても大切です。HTMLでWebページを作って、あなたの考えていることを公開してみましょう。
学習方法
私の場合、初めてHTMLを書いたのが中学生のころで、『はじめてのHTML』みたいな本を見ながらひたすら筋トレや運動方法のまとめページを作成していました。HTMLはMarkdown同様、ひたすら書いて覚えるものだと思いますので、『初めてのHTML』みたいな本を1冊買ってきて、本の内容をそのまま練習してみましょう。最近ではWeb上でHTMLをかきながら学べるサービスも増えてきています。
Code Academyは、私が大学生になって初めての夏休みに、毎日練習していたサイトなのでおすすめします。
Learn to code | Codecademy
4. Shell
UnixやLinuxのコマンドを使いこなすことは、開発や学習を効率的に行う上でも重要なってきます。
先述のGitやHTMLを使う際にも、必ずいくつかシェルのコマンドを入力するはずです。そこで、「あれ？ こういう時はどんなコマンドを入力したらよかったんだろう？」なんて考えていると、作業効率や学習効率がとても悪くなってしまいます。コンピュータを使っていろんなものを作ったり活用したりするためにも、シェルコマンドはきちんと使いこなせるようになりましょう。
学習方法
これもひたすらコマンドを入力していけば覚えられます。ただし、HTMLやMarkdownと違って視覚的に楽しめる要素が少なく、何かモノが作成できるわけでもないので退屈に感じてしまうかもしれません。私がコマンドを楽しく覚えれたのは、サーバーをセットアップして、ホームページを公開できるようにひたすらコマンドを入力していた時です。プログラムやWebページなどは、最近なら優秀なIDEを利用して、面倒なコマンドを打つ必要もなくなりましたが、Linuxで作るサーバーは昔から変わらずコマンドを腐るほど打たなければなりません。さらに、コマンドを入力していく中で、Linuxのディレクトリ構造やネットワークの仕組みなども自然と学習していけるので、サーバーを自分の手で作っていくことは非常に有効な学習方法だと思います。
