ITビジネスの原理 / 尾原和啓
- 作者: 尾原和啓
- 出版社/メーカー: NHK出版
- 発売日: 2014/01/28
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (8件) を見る
タイトルの通り、IT(インターネット)ビジネスの原理について述べてある。まぁそうだよねってことから、なるほどってことまで。
本質は、時間的・空間的距離を超越したマッチング。
IT/インターネットというのはありとあらゆる歪みや偏りを(良くも悪くも)なくす方向に働くものなんだなぁと改めて思った。
ハイコンテクスト/ローコンテクストの話もおもしろかった。
さくっと読めるし、読んでおいて損なし。
暗号解読 下巻 / サイモンシン
- 作者: サイモンシン,青木薫
- 出版社/メーカー: 新潮社
- 発売日: 2007/06/28
- メディア: 文庫
- 購入: 23人 クリック: 70回
- この商品を含むブログ (159件) を見る
下巻。 第二次世界大戦後から、現代、そして未来の暗号まで。
線文字の話とか、最初興味ないなーと思って読み始めても、気付けばすぐ夢中になってる。その文章力に脱帽。
いま現在実際に使われている公開鍵暗号の話は普通に勉強になるし、現代人は誰しも読んでおいた方がいいように思える。もちろんこの辺の話も味気ないお勉強としてじゃなく、ドラマのあるエピソードとして語られている。イギリスGCHQの人たちのクールさには惚れ惚れする。
その他、暗号とプライバシーと犯罪といった避けて通れない難しい問題についても説明がある。
それから未来。原理的に解読不能な暗号。やばい。
ええ本読んだなあ、っていう大満足の読後感。
暗号解読〈上〉 / サイモンシン
- 作者: サイモンシン,青木薫
- 出版社/メーカー: 新潮社
- 発売日: 2007/06/28
- メディア: 文庫
- 購入: 30人 クリック: 216回
- この商品を含むブログ (233件) を見る
サイモン・シン 暗号解読 の上巻。古代から第二次世界大戦までの暗号の歴史。暗号が歴史においていかに重要な役割を果たしてきたかがわかる。ときに人の生き死にに関わり、戦争の勝敗にすら影響を与える。やばい。チューリングのエピソードは何度聞いても切なくなる。
RubyMineを使い始めた & RSpecが動かずハマった
RubyMineを使い始めた。
超いい感じな予感がするけど、試しに適当にプロジェクトを作ってみたら早速ハマった。ハマり名人。
RSpecが動かなかった。
事象
rspecをrunすると以下が出てエラーになる。
`require': cannot load such file -- teamcity/spec/runner/formatter/teamcity/formatter (LoadError)
- RubyMine で Rails+RSpec を使う時のヒント (teamcity/formatter関連のエラー解決) - Qiita
- ruby on rails - Running a spec in RubyMine results in "cannot load such file -- teamcity/spec/runner/formatter/teamcity/formatter (LoadError)" - Stack Overflow
- RubyMine - rspec すると `require': cannot load such file -- teamcity/spec/runner/formatter/teamcity/formatter - Qiita
- IntellJ IDEA(RubyMine) + Rails 4.1 + Rspec (spring)で cannot load such file -- teamcity/spec/runner/formatter/teamcity/formatter (LoadError) - フリーエンジニアライフ
これらによると、対策としては、
- RubyMineと別の環境で起動したspringを終了する
- 環境変数でロードパスを指定する
がある。
しかし、まず、springは起動してなかった。
環境変数はなんか対症療法の感じがしてあんまりやりたくないなーという感じだった。
対策
だいたい、RubyMine & Rails & RSpec でエラーが出て動かなければもっとたくさん情報があってもよさそうだけど、出てくるのは少しだけ。
なんかおかしい気がする。環境構築でミスったのかなと思って、まずRubyMineを再インストールしてみることにした。
brew caskでインストールしたので、brew cask uninstall rubymine
してbrew cask install rubymine
してみる。現象は変わらず。
今度はプロジェクトを作り直してみる。直った。
考察
原因は結局謎のままだけど、とりあえずプロジェクトの再作成で直った。
最初のプロジェクトの作成で何かミスっていたことになる。
あんまり関係なさそうなことも含めて、最初のプロジェクトでやったことで、原因として思い当たりそうなことを考えると、
- rspec-railsをインストールする前に、間違えてrspecをdevelopment,test環境でインストールした
- rails未インストールのバージョンのruby(rbenvを使用)を使った(RubyMineのダイアログでrailsをインストールした)
- zshに乗り換えた直後で、.zshrcにrbenvの初期化コマンドを書いてなかった
というぐらいだろうか。
今回はお試しプロジェクトだったから簡単に破棄して再作成ができたけど、ちゃんと作ってるプロジェクトで途中からこの事象が現れ出したら困りそう。
oh my zshのthemeをpowerlineにした
以下を参考にやってみた。
oh-my-zshでpowerlineを堪能する - Qiita
インストール
以下のリポジトリをcloneする。
jeremyFreeAgent/oh-my-zsh-powerline-theme
$ git clone https://github.com/jeremyFreeAgent/oh-my-zsh-powerline-theme.git
インストールスクリプトを実行してpowerline.zsh-theme
へのシンボリックリンクを.oh-my-zsh/themes/
に作成する。
$ cd oh-my-zsh-powerline-theme/ $ ./install_in_omz.sh
テーマの変更
.zshrc
を修正する。
ZSH_THEME="powerline"
フォントの変更
参考にしたページと同じく、Monaco使ってるので、Monaco for Powerline.otfを入れる。
Patched font Monaco for OSX Vim-Powerline
Monaco for Powerline.otfをダウンロードして/Library/Fonts
に入れる。
不具合対策
現時点(2015/6/14)では、oh-my-zsh-powerline-themeに不具合があるようで、コマンドの補完をしたときに、コマンドの最初の文字が、入力行の先頭に消せない文字としてゴミのように残ってしまう。また、それ以外にも補完時の挙動がいろいろおかしかったりする。
で、こういうissueが立てられている。
その中に、
In the meantime remove the line ZLE_RPROMPT_INDENT=0 from the file powerline.zsh-theme
というコメントがあるので、これに従ってpowerline.zsh-themeを修正した。
# ZLE_RPROMPT_INDENT=0
ZLE_RPROMPT_INDENT=0
をコメントアウトする。
これで.zshrc
を再読み込みすると、確かに挙動は直った。
暫定処置的な感じだけど、とりあえずこれでよさげ。
まとめ
手軽におしゃれ!
コマンドラインの作業を快適にするためにいろいろした
コマンドラインの作業を快適にするために、以下をやった。
ドットファイルをGitHubで管理する
VagrantやVPSとか、色々な環境で作業することが増えたので、なるべく簡単に環境のセットアップができるように、ドットファイルをGitHubで管理するようにした。
そもそもそんなにドットファイルを使いこなしてなくて、数も少ないし個々の記述量も少ないんだけど、それでも管理しといた方が楽そう。
以下を参考にした。情報があふれている。みんなこだわりがあるんだなあ。
- 最強の dotfiles 駆動開発と GitHub で管理する運用方法 - Qiita
- dotfilesを整理した - 1000ch.net
- iTerm2 + zsh + tmux + vim で快適な256色ターミナル環境を構築する - ( ꒪⌓꒪) ゆるよろ日記
- dotfilesをgithubで管理する! - 憧れ駆動開発
- ボク式dotfiles - ゆず日記
- イケてると思う dotfiles の管理方法 - KMC活動ブログ
- dotfilesをGitHubで管理,vimプラグインをNeoBundleで管理する方法メモ - Programming Log
かなりこだわって色んな設定をしているページから、比較的シンプルなものまである。
最初だしとりあえず管理ができればいいので、今回はとりあえず最低限のやつだけ。
やったのは以下。
$HOME/dotfiles
ディレクトリを作成- 管理対象のドットファイルを上記ディレクトリに
mv
- 各ドットファイルにシンボリックリンクを貼るスクリプトを作成
$HOME/dotfiles
をGitで管理、GitHubにpush
基本的には本当に最低限で迷いようがなかったんだけど、唯一どうしようかなと思ったのは、シンボリックリンクを貼るスクリプト(setup.sh)で、すでに同名のドットファイルが存在していた場合の処理。
とりあえず今回は上のいくつかのリンク先を参考に、すでにファイルが存在したら.dotファイルを作成するようにした(.bashrcが存在したら.bashrc.dotを作る)。
でも、例えば今後新しいドットファイルを追加して、再度setup.shを実行すると、これだと全部に.dotができてしまうので微妙かもな、と思ってる。
すでに存在するものがシンボリックリンクだったらパスするとかにするといいだろうか。
とりあえずこのまま運用してみて、良さそうな方法があれば切り替える。
iTerm2を導入する
Homebrew Caskを使ってインストールした。
$ brew cask install iterm2
フォント
Preferences -> Profiles -> Text でフォントとサイズを選ぶ。
13pt Monacoにした。
カラースキーム
ここで選ぶ。
mbadolato/iTerm2-Color-Schemes
プロジェクトごとZIPでダウンロードして解凍。中身のschemesフォルダにある*.itermcolorsがカラースキームの定義ファイルとなっている。
好きな定義ファイルを Preferences -> Profiles -> Colors -> Load Presets で Import したあとに選択するとテーマが変わる。
いっぱいいい感じのスキームがあって目移りしまくったけど、今回はTomorrow Night Eightiesをチョイスした。
あとは Preferences -> Profiles -> Window -> Transparency をいじってちょっと透明にしておくと結構いい感じになった。
zshを導入する
インストール
$ brew install zsh
パーミッションの問題でリンクが失敗したので、brew doctor
してみると、brew link
すればいいと知る。
$ sudo brew link zsh
うまくいった。
ログインシェルの変更
which zsh
してbrewで追加されたzshのパス(/usr/local/bin/zsh)を確認し、これを/etc/shellsの末尾に追加する。
# List of acceptable shells for chpass(1). # Ftpd will not allow users to connect who are not using # one of these shells. /bin/bash /bin/csh /bin/ksh /bin/sh /bin/tcsh /bin/zsh /usr/local/bin/zsh
以下を実行してログインシェルを変更する。
$ chsh -s /usr/local/bin/zsh
ターミナルを起動しなおすと、zsh初回起動時の設定画面になった。対話的に.zshrcの基本的な設定ができる。あとでoh-my-zshを入れたからここでの設定は意味なかった。
参考:Macの環境設定(3) zshを入れる - Qiita
oh-my-zshを入れる
公式の通り、以下でインストールできる。
curl -L https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh | sh
インストールが終わったら.zshrcを再読み込みする。
source .zshrc
これだけで勝手にカラフルになる。
参考:Mac OS X で zsh + oh-my-zsh の環境を作って一通り設定するまで - Qiita
テーマを変える
ここでスクリーンショットが見れる。
Themes · robbyrussell/oh-my-zsh Wiki
agnosterが気になったけど、設定が面倒そうだったのでとりあえずwedisagreeにした。
.zshrcのテーマの行を変える。
ZSH_THEME="wedisagree"
おしゃれでキュートでハッピーになった。
参考:ターミナルをカラフルでかわいくする - yulily100's blog
まとめ
だいぶいい感じになった。特に見た目が。というかまだあんまり使ってないから見た目以外の変化を感じづらい。
少しずつ使いつつ設定も自分好みに変えていけたらいいな。
そういえば動作が少し重い気がするのが微妙に気になる。一気に変えたから原因がiTerm2かzshかoh-my-zshかわからない。oh-my-zshが怪しいような気がする。要調査。
追記
少なくとも、エンターを押すごとに感じる毎行の重さの原因は、選んだoh-my-zshのテーマ(wedisagree)のようだ。デフォルトのテーマに戻したら感じなくなった。でもこのテーマは味気ない。いいバランスのやつないかな。。
Railsの勉強としてTwitterリストランキングサイトを作った
Twitter上のリストをメンバー数/購読者数順に表示するサイトを作った。
動作確認は、
でやった。
以下の目次に大々的に「敗因」とあるように、正直失敗だと思ってる。
そう思う理由は本文で詳しく書くとして、結果が失敗だったとしても過程で色々学べたのでまとめておく。特に今回は学ぶこと自体が大きな目的だったので、そういう意味では完成しただけで総合的には成功だと言えなくもない…!と思う。学んだことを活かして次の何かを作れればいい。
ということで以下目次と本文。
目次
- 何を作った?
- なぜ作った?
- 結果
- 敗因
- 使った技術
- 付け足したい機能(現時点でできていないこと)
- 今後の課題
- まとめ
何を作った?
Twitterリストのランキングサイト
上でも書いた通りだけど、Twitter上のリストをメンバー数/購読者数順に表示するサイトを作った。
リストごとに、リスト名、作成者、作成日、購読者数、メンバー数を並べて表示する。
そのためにリストを収集するbot
上記サイトを作るためにリストを定期的に自動収集するbotを作った。「bot」という呼び名でいいのかわからないけど、ここでは定期的・自動的に動作するスクリプトという意味で使ってる。
なぜ作った?
Railsの勉強
主にこれ。
3月いっぱいで某SIerを退職して、現在フルタイムで無職活動中なので、Web業界へ転職するために勉強として何か作ってみたいと思い、何かないかと考えた。
どうせ作るなら意味があるものがいいが、最初からあんまりレベルが高いものは挫折しそうなので、難易度のバランスが大事だった。
リスト探しの利便性向上
当初は、ランキングだけでなくもう少し総合的なリストのまとめサイトを作りたいという構想だった。ランキングだけでなく、検索機能やカテゴリ別まとめなども付けて、リストを探しやすくしたかった。
というのも、みんなが同じようなリストをそれぞれで作っているように思えたから。
「Rubyについてツイートしている人」「芸能人・有名人」「政府・公共系」とかのリストは、似たようなユーザを追加しているにも関わらず無数にある。
そこで、目的のリストをすぐに探せて、同じようなものを改めて作ることなく既存のものをフォローできるようにすれば効率的なのではないかと思った。
エンジニアの多くがフォローするリストとかがあれば一種のチャンネルのように機能するのではないかとも思った。その役割はすでにハッシュタグが担っているのかもしれないけど。
そして簡単にググってみたところ、そういうサービスは見当たらなそうだったので、これ幸いと作ってみることにした。
結果
失敗した。
失敗というか、あんまりいいものはできなかった(それを失敗と言うのか)
まず当たり前だけど、収集対象のリストが多すぎる。リストが多いのは想定していたけど、最初は「少数しかユーザを追加していないリストも全て収集する必要はない。大きなリストだけに絞って収集していけば問題ない」というノリだったけど、それでも多すぎた。
ここで「多い」というのは、もちろん絶対数も多いんだけど、TwitterのAPIのリミットに対して多いというのもある。全体的にリストに対するAPIのリミットは厳しく設定されている。
Rate Limits: Chart | Twitter Developers
ユーザの取得とかが180回/15分のリミットなのに対して、リスト関係は15回/15分になってる。
ということで、APIの制限に対して収集したいリスト数が多いというのはどうしようもないため、このリストのサービスが今後の機能追加などでよくなるものでもないと判断したので、残念ながら今回は失敗かなと思っている。
敗因
本当は、リストの多さやAPI制限について気付いた時点でやめるべきで、そもそも最初にその辺りまで調査してから着手すべきなのだろう。それをしなかったのが主な敗因なのかもしれない。
だけど今回は主目的がRailsの勉強だったこともあって、その辺を突っ切ってしまった。(まぁ他に作るものの案があれば乗り換えたのかもしれないけどなんにも思いつかなかった)
ということで、仮にリストのまとめを作らなきゃいけないこと前提(やめる選択肢はないこと前提)で、なぜそれがうまくいかなかったのかについて考えてみる。
Twitterがリストをあんまり推してない
APIの制限の厳しさからもわかるように、Twitterがリストの利用を推奨しているようにはあんまり見えない。公式Webでもリストは、プロフィールページの頻繁にチェックするには面倒な場所にあるし、iOSアプリなんて設定の歯車アイコンからアクセスするようになってる。
Twitter本体が推奨してないものを主体に据えたサービスはうまく行きづらいだろうと思う。
良いリストを作るインセンティブがない(?)
※この項目の結論は微妙です
みんなが良いリストを作りあって、「見てくれ!」っていう競争みたいなのがない。言わばリスト市場みたいなものが活性化していない。
それは良いリストを作ってシェアするインセンティブがないからかもしれない。
たとえ自分が作ったリストの購読者数が一万人を超えたとしても、購読者は別に作った本人をフォローするわけでもないし、あんまり旨味がないのかもしれない。
とここまで書いてから、まったくないこともないかもって思い始めた。
上で書いたのは言ってみれば、「人気テレビ番組のプロデューサーは、番組が人気になっても、本人が出演しているわけでもないから旨味がない」って言っているようなものだ。
人気のリストのメンバーを管理する権限を握っている影響力は大きいかもしれない。人気番組のキャスティングを握っていることの影響力が甚大なように。それを旨味とみなす人もいるかもしれない。
うーん、でもリスト市場が活性化しても購読者数万人規模のリストができるとは思えないので、やっぱり旨味はそんなにないかな。
言いたいことがよくわからなくなってきたけど、とにかく旨味がなければリストのまとめサイトができてもあんまり盛り上がらないのでは?と思う。
あんまり説明文が記載されてない
上でよくわからんことを書いたけれど、ここは至極具体的なことで、みんなあんまりリストの説明文を書いてない。
作ったサイトの、各リストの真ん中あたりは説明文のスペースなんだけれど、ここが空白のリストが多い。
説明文が空白だと、検索機能やカテゴリ分けはしづらいか、あるいは貧弱な機能になりそう。
使った技術
使った技術やサービスなどを、粒度やレイヤーに関わらず列挙してみる。
共通
サイト
- Rails
- RSpec
- Capybara
- HTML
- SCSS
- Bootstrap
- Webフォント(Google Fonts)
- JavaScript(非Coffee)
- jQuery
- Vagrant
- CentOS
- Nginx
- Unicorn
- Googleアナリティクス
bot
- OAuth
- ActiveRecord
- Cron
以下、いくつか詳細とか説明とか。
Ruby/Rails
これが主題だったにも関わらず、あんまりコードを書けなかった。
ご覧の通り、最終的にリストの一覧しかないので、lists#index
アクションしかない。モデルも、List
と、内部的に持ってるUser
の二つ。
ということで全然コードを書きたりない。
どちらかと言うと、botの方が書いたコードの量は多いけど、こっちも大したことない。
Railsを学ぶことを主題に据えている以上、サービスがあんまり良い出来にならなかったことより、こっちの方が失敗かもしれない。
ただRailsの全体像とかディレクトリ構成とかは結構イメージが掴めたと思うし、railsコマンドやrakeコマンドもよく使った。springやTurbolinksでハマったりもしたので、コード以外の部分は多く学べたと思う。
テスト
一応書いてみたものの、コードが少ないからテストもあんまり書いてない。
複雑なコードも書いてないのであんまりありがたみも感じられていない。
サーバ周り
とにかくRubyやRails本体よりもこっちの方が苦戦した。
一挙手一投足ハマるような感じで、だいぶ苦しんだ。ここに関しては、よくがんばったとちょっと自分を褒めたい。
しかしコマンドラインの操作にそんなに苦手意識はなかったんだけど、ここまでハマるとは。
あと、途中までHerokuだったのに最終的にさくらのVPSに乗り換えたのは、Heroku(ClearDB)無料枠ではDBの制限が厳しかったから。 Heroku Schedulerでbotを動かしていたんだけど、DBの制限にかかってエラーばかりになったので、こりゃダメだと思って乗り換えた。 正直botを動かす頻度とかは、あんまり感覚がわからなくて、あんまり迷惑をかけないよう余裕を持ってやってるつもりだったんだけど、ダメだった。
それならHeroku(ClearDB)の有料プランにしても良かったのかもしれないけど、料金プランが英語で複雑そうだったのでやめた。
PostgresではなくMySQLを使ったのは、より多く使われてそうだったから。 でも最近はPostgresが人気なのかな?って思うことも多いような気もする。。 まぁ今回のような場合、まったく大した処理してないし、どっちでも変わらないだろうけど。
JavaScript
やはり大した量は書いてないのと、JavaScriptの方が慣れているのでCoffeeScriptは使わなかった。
書いたのはTopへ戻るボタンと、Twitterボタンくらい。
Turbolinks対応でハマったけれど、Ruby/RailsによりはJSは比較的慣れているのであんまり苦しみはなかった。
Vagrant
途中から使い始めたので、Railsの開発環境としては使ってない。
付け足したい機能(現時点でできていないこと)
「結果」で書いた通り、機能追加によってより良くなるものでもないと思うので、ほぼモチベーションはないんだけど、今後追加するとしたらこれかな、というのを挙げる。
検索
当初は付ける予定だったやつ。
リストの説明文が思ったよりも少ないのであんまり効果的な検索はできないかもしれない。
でも現在ユーザの入力を受け取るフォームが一切ないので、付ければ勉強にはなりそう。
デザイン
ご覧の通り。シンプルと言えば聞こえはいいけど、ただ何もないだけ。ただコンテンツ自体が少ないので仕方ない部分もあると思うんだけどそんなことないのかな…?
一応がんばった部分としては、ロゴをWebフォントにしたことと、リストのメンバー数/購読者数周辺のデザインを良い感じ(だと自分では思っている)にしたこと。
デザイン自体は自分のやりたいことの上位ではないけど、でもユーザにまず見られるのはデザインなので、苦手なりにどこまでこだわるかは本当に悩ましい。
スマホ対応(レスポンシブデザイン)
今はスマホでもPCレイアウトのまま表示されるので、スマホ用の表示も対応したい。デザインをどこまで綺麗にするかは、上と同じで悩ましい。
FaceBookいいね対応
着手してみて諦めたっていうのはこれだけかもしれない。
厳密に言うといいねボタンのTurbolinks対応。
いいねボタンを普通に設置するだけならFaceBookのページからスニペットをコピペするだけなんだけど、TurbolinksによるAjaxの遷移に対応するためにはちゃんとAPIを見てコードを書かないといけなさそうでしかもアプリの登録とかが必要そうだった。
そんなことしなくても、いいねボタン関連のDOM要素を追加し直したりscriptを読み込み直したりして、初回表示と同じ状況を再現すればできるのでは?と思ったけどうまくいかなかった。
すでにモチベーションも下がりまくっていたし、「どうせ誰もいいねなんかしないだろう」というやさぐれた気持ちで諦めることにした。
今後の課題
コードをもっと書きたい
今回はいくらなんでも書き足りない。
サーバ周りの学習コストについてはこれからは(同じような構成にする限り)大きく減るはずなので、その分コードを書きたい。
そのためには適切な課題を設定しないといけないけど、それが難しいなあ。
そもそものサービス設計をちゃんとする
「サービス設計」と言うのかはわからないけど、根幹のコンセプトとかアイデアがちゃんとしていて、作ったら意味があると思えるものじゃないとモチベーションが維持できない。
yak shavingが多い
知的好奇心の旺盛さとも言えるので一概にすべてダメではないかもしれないけど、気の向くまま毛を刈ってたら進捗に影響する。思うようにプロジェクトが進まなければこれまたモチベーションに関わるので、やはりある程度は抑えるべき。結局モチベーションの維持が一番大切。
まとめ
うまくいかなかったことも含めて色々勉強になったと思う!
何か作って公開するっていうのは大変だけど楽しい。
あとそろそろ就活する。
最初は6月末まであそ…勉強するつもりだったけど、一人で勉強しててもあんまり効率よくないので、ちょっと前倒ししてそろそろ動く。フルタイム無職活動にもちょっと飽きてきた。
おすすめの求人サイトがあれば教えてください。今はForkwellがいいかなって思ってます。