Ruby
プログラミング言語Ruby買ってみた。イントロダクションから既に知見がある。
メソッドに別名を付けられる
class Sequence def length return 0 if @from > @to Integer((@to - @from)/@by) + 1 end alias size length # sizeはlengthの同義語 end
算術演算子や配列アクセス演算子をオーバーライドできる
class Sepuence def [] (index) # 略 end def + (offset) # 略 end end
文字列がmutable
文字列リテラルは一意なオブジェクトではないので注意。
str = 'abc' str[0] = 'x' puts str # => "xbc" str.freeze # 変更不可にする。[他のオブジェクトでも使用可能](http://ref.xaio.jp/ruby/classes/object/freeze)。 str[1] = 'y' # => RuntimeError: can't modify frozen String
動的性
Rubyにはクラスの定義すら切り替え可能な動的性がある。
class Foo < ( condition ? Bar : Baz ) # ... end
解析フェーズでは文法レベルでのチェックは行うが、この整合性はコンパイル時には検出されない可能性がある。実行時まで気付かないかもしれない。 Rubyではテストに必然性がある。他言語と比較してテストを書く、書きやすい文化はこの為かもしれない。
vim
IDE開発に慣れてきてたので、いまのところvimが手探り感すごい。 いろいろと学びつつメモしておきたい。
職場で学んだ快適なVim操作のためのtips - TIM Labs
"*p
逆にテキストをクリップボードにコピーしたい場合
"*y{motion}
Vagrant
Rubyまわりを見てると頻出なので基礎程度は学んでおきたいと思い、ドットインストールのVagrant講座を一通りやってみた。
# http://www.vagrantbox.es/ からBox(テンプレート)を取得する $ vagrant box add {title} {url} # 取得したBoxの一覧を確認 $ vagrant box list # 取得したBoxは以下にキャッシュされる $ ls ~/.vagrant.d/boxes => centoos64 ubuntu-VAGRANTSLASH-trusty64 # Boxを指定して環境の初期化。このコマンドでVangrantfileが作成される。 # Boxに対して複数の仮想環境を作成できるので 1:1ではない $ vagrant init {title} # 仮想環境の起動 $ vagrant up # 仮想環境への接続 $ vagrant ssh
起動・停止系
# 一時停止 $ vagrant suspend # 再開 $ vagrant resume # 停止 $ vagrant halt # 起動 $ vagrant up # 再起動。設定変更時などに使う $ vagrant reload # 仮想環境の削除 $ vagrant destroy
provisioning…仮想環境起動時に実行する処理。Chef / Puppetなど高度なツールを使うこともできるし、shellで記述することも可能。
# provisioningの設定変更を反映させる
$ vagrant provision
MongoDB
これもドットインストールで基本を学習。
環境準備は以下を参考に実施。
CentOS6.5にMongoDBをインストールする - Qiita
スキーマレス
あらかじめデータ構造の定義をしておく必要がない。
Database / Collection / Document の関係
ドットインストールより拝借。
Databaseの操作
# MongoDBの起動 # Databaseが存在しない場合は新規作成する # ただしコレクションが追加されない限りDBは保存されない $ mongo {database_name} # DBの一覧確認 > show dbs; admin (empty) local 0.078GB # DB切り替え > use mydb switched to db mydb # DB削除 > db.dropDatabase() { "dropped" : "mydb", "ok" : 1 }
Collectionの操作
# コレクション追加 > db.createCollection('users') { "ok" : 1 } # コレクション一覧の確認 > show collections system.indexes user # コレクション名の変更 > db.users.renameCollection('persons') { "ok" : 1 } # コレクション削除 > db.persons.drop() true
Documentの操作
# 追加 > db.users.insert({name: 'taguchi', score: 30}) WriteResult({ "nInserted" : 1 }) > db.users.insert({name: 'butcher', tags: ['web','mobile']}) WriteResult({ "nInserted" : 1 }) # 全件検索 > db.users.find() { "_id" : ObjectId("55e55f179d27c294038c669e"), "name" : "yo", "score" : 30 } { "_id" : ObjectId("55e55f3d9d27c294038c669f"), "name" : "butcher", "tags" : [ "web", "mobile" ] } # 個数を確認 > db.users.count() 2 # 全削除 > db.users.remove({}); WriteResult({ "nRemoved" : 2 })
# 条件を指定しての検索 # key,value検索 > db.users.find( { name: 'user-1' } ) # 正規表現 > db.users.find( { name: /user-[1-3]/ } ) # 比較演算 $gt $gte $lt $lte $ne > db.users.find( { score: { $gt: 30 } } ) # AND > db.users.find({ $and: [ { team: 'team-0' }, { score: { $lt: 50 } } ] }); # OR > db.users.find({ $or: [ { team: { $in: [ 'team-0', 'team-1' ] } }, { score: { $exists: true} } ] }); # DISTINCT > db.users.distinct('team') [ "team-0", "team-1", "team-2" ]
# 検索結果を加工 # 返す属性を指定 > db.find({}, { name: 1 }) # limit, skip(offset), sort > db.users.find({}, { name: 1, _id: 0}).skip(2).limit(3).sort({ score: 1 })
読んだもの
Web エンジニア 6 年 5 ヶ月やってたどり着いた価値観 - Born Too Late
素晴らしい振り返りで、ハッとさせられる気づきが幾つもある。 年齢で測るのもどうかと思うが、自分が2年後にここまで到れるだろうか。
コードを書け。それが履歴書だ。
まだまだ足りない。
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか - 未来のいつか/hyoshiokの日記
商用製品を使うメリットってなんだろうか。 サポートがある?上司への言い訳が効く?いろいろ便利なツールがある?性能がいい?機能が豊富?バグが少ない?安い?営業に接待してもらえる?責任をとらなくていい?モテる?かっこいい?情報が多い?すぐに使える?利用者が多い?
前職で担当していた開発・保守案件では商用製品をいくつか採用していて、考えていたことだ。
原因不明の障害が起きてログを見たら「要ベンダー問い合わせ」のエラーコード。 問い合わせようとしたらサポート時間外(これは資金投入の問題)。 ソースコードが手元に無いので原因も再発可能性も説明の仕様が無い。 責任の所在は開発元ベンダーか?
そして、そんな時に、顧客と商用製品開発元との間の橋渡しをするだけ(それしかできない)の自分はエンジニアだろうか?
企業にとってみれば、商用製品だろうがオープンソースだろうが経営的課題を解決できればどっちでもいい。その前提でいっても、多くのインターネットサービス企業はオープンソースを選択している。その事実をどう評価するか。 オープンソースを使いこなすことには、間違いなく優位性がある。そして、それはオープンソースを使いこなせないことにとてつもないハンディキャップをおっているという認識が必要である。 これは、単なる経済合理性の話である
上記のようなケースでエンジニアとして何もできなくても、ビジネスの話をしてうまく立ち回ることができたんだと思う。 いわゆる政治的なハードルを越えるのに割くコストを自分のなかで割り切れるのであれば…。
【前編】華麗なるキャリアの道程は、『ドワンゴ』から逃げ出したい一心から!? / 飲み会で探るエンジニアのホンネ #naoya_sushi 編
ドワンゴは大量退職に関する印象操作をやめろ - hiroki-uemuraのブログ
退職はセンシティブな情報だ。今まさに自分の身の回りの出来事なので気をつけたい。