ロックとチュウーハイとこりんがるな日々

日々のインプットした事をアウトプットする場所

2014年 マネジメントについて考えをまとめておく

マネジメントについての考え方をまとめておきます 以下の事を前提としています

  1. WEBを活用したビジネスを展開している
  2. マネジメントの対象はSE/PGと商品開発に関わるチーム
  3. 受託開発ではなく商品を自社で開発しビジネスを行っている会社でのマネジメント

基本的にはマネジメントをしたくないので、マネジメントをしなくても良いようにマネジメントを行って います

基本的には自主的に動いてほしいのです しかしベンチャーで働いているにもかかわらず自主的には動かない人がほとんどです(※僕が見てきた範囲での話ですが) たぶんこれが現実です

そういった中で日々行っているマネジメントでまずは大事にしている事を以下に書きます

  1. 強制しない事
  2. 環境を整える事
  3. アウトプットする事
  4. 続ける忍耐力
  5. マネージャーはホスト、PG/SEはお客様
  6. 八方美人になる

1. 強制しない事

強制的に従わせる事はものすごく簡単な事なんですね、でも自主的に動いてほしいという事と強制するという事は真逆 の行為です、まれに強制的にルールを作る事はありますが基本的には強制はしません

2. 環境を整える

良いツールがあるとします、あれ使いましょうよ!!ではなく聞くまえに環境を用意して試せる場所を用意してしまう ルールなんかの場合はひな形を用意して話し合いがし易い環境を前もって用意します

なにをやるにも一番めんどくさい最初の一歩となるものを用意してあげる事

3. アウトプットする事

アウトプットできる雰囲気を作る為に自分がアウトプットしまくる、強制しない事にも通ずる事ですが強制しない事を 前提にした場合、日々アウトプットしていく事でこうしたほうがいいよ的な事を小出しにして植え付けて行く

また技術的な事などは朝会の時にさり気なく小出しにしていっています

4. 続ける忍耐力

1 〜 3を続ける忍耐力は必要です、強制的にやったほうがましやけど少しづつ植え付けて行くことで文化が根付いていく と信じる心が必要かと思います

5. マネージャーはホスト、PG/SEはお客様

技術系のマネジメントの場合は実際に手を動かすPG/SEはお客様、マネージャーはホスト、いかに気持ちよくコードを 書いてもらえるかを考えて尽くしまくる事が大事

とにかく雑用を行わせない1つの事に集中してもらう環境をつくる

6. 八方美人になる

PG / SEにはクセの強い人が多いので空気を読んで個々に対応していく、自主的に動く事が苦手な人もいる 誰かに指示を出してもらう事でパフォーマンスを発揮する人のいる事を理解しておく事


1日の半分ぐらいがこういった作業で終わってしまいます、なやみは自分がどんどんコードを書けなくなっている事 と今の会社では僕が一番コードを書くのがうまいという事

※実際には大した腕ではないです、勉強会とかにいくといつも自分の腕のなさに愕然としてしまいます

マネジメントの方法については日々情報収集をして考え方を改めていこうと思っていますが今のところこんな感じで 考えています

でわであ

ruby on rails の1人勉強会を開催

第1回

今までは主にPHPを使って開発を行ってきました、巷でrailsについてよく聞いたり見たりするので 勉強も兼ねて前に購入したRuby on Rails チュートリアルを見ながら何か作ってみます

今日は環境構築です

僕はchefを使っているのでローカル環境にrubyの環境がありますので、rubyのinstallは今回書きません rubyはrbenvを使って構築しています

※ tmux とrbenvを併用している場合の注意点

tmux を起動してrubyのバージョンが切り替わって以内現象が発生しました、どうやらパスの問題らしいので 先にここを解決します zshを使っているので.zshrcに以下の記述を追加する

export PATH=$HOME/.rbenv/shims:$PATH

記述する場所が問題で、rubyのパスが書かれているより前に記述します これでtmuxを使ってもrbenvで切り替えたrubyが使えます

  1. railsのinstall

    Ruby on Rails チュートリアルに添って以下のコマンドを実行する

     gem install rails --version 4.0.5
    

    少し長いですが待ちます 完了したら、以下のコマンドでrailsのバージョンを確認

     rails -v
     Rails 4.0.5
    

    上記が表示されればinstallは完了です

  2. 初めてのprojectを作る

    適当なディレクトリに移動して以下のコマンドを実行する

     rails new [project name]
    
  3. とりあえず起動してみる

    rails new で出来たディレクトリに移動する

     rails server
     => Booting WEBrick
     => Rails 4.0.5 application starting in development on http://0.0.0.0:3000
     => Run `rails server -h` for more startup options
     => Ctrl-C to shutdown server
     [2014-06-17 07:52:51] INFO  WEBrick 1.3.1
     [2014-06-17 07:52:51] INFO  ruby 2.0.0 (2013-05-14) [x86_64-darwin12.3.0]
     [2014-06-17 07:52:51] INFO  WEBrick::HTTPServer#start: pid=3013 port=3000
    

    localhostの3000番が起動するのでブラウザからアクセスする

    rails server

次はこの環境をvagrant でさくっと扱えるようにしてみたいと思います

今日は時間が来たのでここまでです、ではでは

vagrant体験入門に参加しました

vagrant 体験入門に参加しました

ハンズオン形式の勉強会は初めて参加しましたがめっちゃ楽しいですね!!

もくもくと作業をしている場から講師をして頂いた新原さんを通じて会話が生まれて、横にすわっている 方との会話に繋がっていく様はすごくいい場やなーーっと思いました

もちろん会話がメインではないので質問や会話のあとはまたもくもく手を動かします

vargant 体験入門の内容自体は一応業務の開発環境で使っているので知ってる事の方が多かったですが 人にしゃべる事で自分が理解している事が理解できていなかった事に気付かされたり、また知らない事も ありました

知らなかった事

  • vagrant init box名を入れれる事

      vagrant init [box名]
    

    と指定してコマンドを実行するとVagrantfileに指定したbox名が記述されている、知りませんでした 毎回vagrant initしてvagrantfile開いて編集していました

    新原さんも言ってましたが公式のdocumentを読みましょー、書いてましたTT

  • Provisioningにshellを使う

    僕は今までProvisioningにchefを使っていました、ちょっとした開発環境を作るのでもchefを使って ました、apacheいれて少し確認したいなーって時にはかなりめんどくさいなーーって感じていました 勉強会でshellを使って見たらそのめんどくささは解消されました

    いままで通りproductionの開発にはchefを使おうと思いますが、ちょっとしたものを構築する時はshell を使うように切り替えました

  • Provisioningにdockerが入った事

    これはマジでと思いました、ホンマにDocumentを読もうと思った瞬間でもありますTT Docker本格的に触ってみるかーと思いました

まとめ

2014年にはいってなにかとバタバタして勉強会に来れなかったので、久しぶりに参加してすごく楽しかったです もう少し色々な方と話せればなーっと思いましたがそれは自分の課題ですね

ハンズオンの勉強会ははじてやったけどもくもく手を動かしてわからない所は質問して共有してまたもくもく手を 動かすっていう場所はすごく楽しかった

普段の会社では出来ない事なのでこれからも時間があればどんどんと参加しようと思います

ありがとう御座いました

Git 戻す系の処理を自分の理解の為にまとめてみた

先週Gitでファイルを巻き戻す時にどうするのかを聞かれてうまく説明できなかったので以下に自分がちゃんと 理解していないかを痛感したので自分の為にまとめてみる事にしました

※Gitのinstallや基本的な操作についてはふれません

Gitは以下の3つのファイルの状態を持っています

  • ワーキングツリー

    現在のファイルの状態

  • インデックス

    addした時点のファイルの状態

  • HEAD

    commitした時点の状態

Gitが上記の3つのファイルの状態を持っている事をふまえて一連の流れを書きます

  1. git init

    適当なディレクトリを作成しそのディレクトリ内で以下のコマンドを発行する

     $ git init
    

    この時点のGitの状態

  2. ファイルを作成する

     $ vim index.html
     <!DOCTYPE HTML>
     <html lang="jp">
     <head>
     <meta charset="UTF-8">
     <title></title>
     </head>
     <body>
     </body>
     </html>
    

    この時点のGitの状態

    ファイルが作成されたのでワーキングツリーの位置が進みます

  3. add する

     $ git add index.html
    

    この時点のGitの状態

    インデックスの位置が進みます

  4. commit する

     $ git commit -m "first commit"
     [master (root-commit) 9d3f252] first commit
      1 file changed, 9 insertions(+)
      create mode 100644 index.html
    

    この時点のGitの状態

基本的にはpushしてリモートリポジトリに追加して一連の流れとしてはOKかと思います

次はファイルを巻き戻す方法を以下に書いていきたいと思います

修正しているファイルの修正箇所を取り消す

  1. index.htmlを編集する

    ワーキングツリーのファイルを修正したのワーキングツリーが1つ進む

  2. 修正している箇所を取り消す

    ワーキングツリーを戻す

     $ git checkout index.html
    

addを取り消す

  1. index.htmlを修正、add(インデックスに登録する)

  2. addを取り消す

    • addだけ取り消す

        $ git reset HEAD
      

      この状態になる

    • ワーキングツリーの変更も取り消す

        $ git reset --hard HEAD
      

      この状態になる

commit を取り消す

  1. index.htmlを修正して、add, commitをする

  2. commit を取り消す

    • commit だけを直前に戻す

        $ git reset --soft HEAD^
      

      この状態になる

    • commitとaddを直前に戻す

        $ git reset HEAD^
      

    • ワーキングツリーも含めて直前に戻す

        $ git reset --hard HEAD^
      

まとめ

  • HEAD, HEAD^

    • HEAD

      最新のcommitの位置

    • HEAD^

      一つ前のcommitの位置

    ※commit IDを指定して戻す事も可能

      $ git reser [commit id]
    
  • --soft, option無し, --hard

    • --soft

      HEADを操作する

    • option無し

      HEAD, indexを操作する

    • --hard

      HEAD, index, ワーキングツリーを操作する

だいぶ頭を整理できましたようするに

git reset [なにを戻すかを指定する] [どの位置まで戻すかを指定する]  

って感じですか、間違ってたら教えて下さい

でわでわ

参考にした記事

Qiita git-resetは結局何を戻すのか

murankの日記 git reset についてもまとめてみる

vagrant1.5.1にアップデートしたらvagrantがうんともすんとも言わなくなったのを解決してみる

とりあえずなにもできない状態、vagrant up、initもできない唯一確認できたのは vagrant -vで確実にバージョン は上がっている事だけは確認できた

$ エラー内容

$ vagrant up
Vagrant failed to initialize at a very early stage:

The plugins failed to load properly. The error message given is
shown below.

undefined method `[]' for nil:NilClass

plugins がなんたらかんたら言うてるのでとりあえず以下のコマンドを実行

$ vagrant plugin
Vagrant is upgrading some internal state for the latest version.
Please do not quit Vagrant at this time. While upgrading, Vagrant
will need to copy all your boxes, so it will use a considerable
amount of disk space. After it is done upgrading, the temporary disk
space will be freed.

/Users/box406/.vagrant.d/gems/gems/vagrant-vbguest-0.9.0/lib/vagrant-vbguest/vagrant_compat.rb:8:in `<top (required)>': undefined method `[]' for nil:NilClass (NoMethodError)
  from /Users/box406/.vagrant.d/gems/gems/vagrant-vbguest-0.9.0/lib/vagrant-vbguest.rb:11:in `require'
  from /Users/box406/.vagrant.d/gems/gems/vagrant-vbguest-0.9.0/lib/vagrant-vbguest.rb:11:in `<top (required)>'
  from /Users/box406/.vagrant.d/Vagrantfile:7:in `require'
  from /Users/box406/.vagrant.d/Vagrantfile:7:in `block in <top (required)>'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/config/v2/loader.rb:37:in `call'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/config/v2/loader.rb:37:in `load'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/config/loader.rb:104:in `block (2 levels) in load'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/config/loader.rb:98:in `each'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/config/loader.rb:98:in `block in load'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/config/loader.rb:95:in `each'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/config/loader.rb:95:in `load'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/vagrantfile.rb:28:in `initialize'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/environment.rb:486:in `new'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/environment.rb:486:in `vagrantfile'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/environment.rb:317:in `host'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/environment.rb:168:in `block in action_runner'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/runner.rb:36:in `call'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/runner.rb:36:in `run'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/environment.rb:304:in `hook'
  from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/environment.rb:148:in `initialize'
  from /Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.5.1/bin/vagrant:149:in `new'
  from /Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.5.1/bin/vagrant:149:in `<main>'

vagrant-vbguestのバージョンが古いのかなと思い以下のページを参考にしてpluginのアップデートを行った

参考ページ : Vagrant1.2.2から1.3.2にあげたらvagrant-vbguestが動作しない

$ アップデートの手順

  1. グローバルのVagrantfileを編集

     $ vim ~/.vagrant.d/Vagrantfile
    

    以下をコメントアウトする

     - require 'vagrant-vbguest' unless defined? config.vbguest
     - config.vbguest.auto_update = false
     + #require 'vagrant-vbguest' unless defined? config.vbguest
     + #config.vbguest.auto_update = false
    
  2. pluginをアップデート

     $ vagrant plugin update vagrant-vbguest
    

    僕の場合は以下のpluginがアップデートされました

     Updating plugins: vagrant-vbguest. This may take a few minutes...
     Updated 'sahara' to version '0.0.16'!
     Updated 'vagrant-vbguest' to version '0.10.0'!
    
  3. グローバルのVagrantfileを編集

     $ vim ~/.vagrant.d/Vagrantfile
    

    以下をコメントアウトとる

     - #require 'vagrant-vbguest' unless defined? config.vbguest
     - #config.vbguest.auto_update = false
     + require 'vagrant-vbguest' unless defined? config.vbguest
     + config.vbguest.auto_update = false
    

アップデート後はvagrant up, initともに正常に動作しています

しかしvagrantをアップデートするたびに絶対に一度動かなくなっているさくっとアップデートはできないものか・・・・

でもこれでvagrant shareが試せるぜーーーー

でわでわ

rsyncをcronで実行する場合にpasswordを聞かれて時の対処を考えてみた

$ rsyncをcronで実行する場合にpasswordを聞かれて時の対処を考えてみた

rsyncの「--password-file」 optionはremote側にも設定が必要な為、今回は断念しました 変わりにexpectを使ってshell scriptを書きました、それをcronで実行する形にしました

  • expectをinstall

    今回はcentos6.4を使っているので、yumコマンドでinstall

      yum install expect
    

    今はサーバの構築にchefを使っているので上記のcommandに相当するrecipeを書いています

      package "expect" do
        action :install
      end
    
  • shell script

    expectを使って以下のbackup scriptを作る

      #!/bin/sh
      PASSWORD="remote server password"
      expect -c "
      spawn rsync -av /sync/directory/pass/ [remote user]@[remote host]:/remote/sync/directory/
      expect backup@111.222.333.444's\ password:\
      sleep 1
      send \"${PASSWORD}\r\"
      expect eof
      "
    

    汎用的に作る意味もなかったのでベタ書き

上記をcronに設定してsyncするだけ

rebuild.fmを聞いて改めて情報共有について考えたみた

rebuild.fm epsode32 を聞きました

感情の共有の話はめちゃくちゃ共感した、反射的にtweetもしたけど自分の頭の中の整理も込めてまとめておく

まず僕の会社では現在情報の共有ツールにwikiを使っている wikiを使っているのは得に意味もなく情報の共有といえばwikiだろみたいな感じで導入しました

しかしこれが良くなかった、なぜかっていうと共有するべき情報の温度が伝わってこない(←ここが整理できた点) 僕が考える上で共有したい情報は2種類ある

  • 無感情な情報
  • 感情的な情報

「無感情の情報」は例えばサーバリストとか社員のメールアドレスリストなどがあると思う、そういったドキュメント はただそこに書かれている情報だけが必要であってそこに書いた人もしくは見た人の感情はむしろいらない こういった情報を管理する場合はwikiとかで十分だとおもう

「感情的な情報」は例えばサーバ移行時、作業ログ、技術的なドキュメントなどがあるかと思います、こういったドキュメントは 書いた人以外が見た時にその時の感情というか熱みたいなものが伝わってくる必要がある気がする、それに対して feedbackを送れるようになっている必要があるとおもう、言葉としてあるのかわからないが Social Document的な要素が 必要だと思っている、だれがどんなツッコミを入れているのか、誰がどんな事を書いているのか、書いてる人、突っ込んでいる 人、の顔が見えるようにする事が「感情的な情報」、「Social Document」にはすごく重要なんだと思いました

どんなtoolを使うのかって事でも悩んでいるが今一番有力なのは内製する事、qiita teamなんかはすごく良く出来ていて かつ今の僕の要件に対して全てを満たしている気がするが、ちょっとした事に対して自分でコントロールできないのは やっぱり厳しい、ツール合わせてスタイルを変化させていく事が必要だと思うが、それだとどこかで譲れない事が出てきて 少しのストレスが生じた場合、それがどんどんたまって最後には崩壊してしまうような気がする、今までのパターンがそう でした(これは僕がコントロールできてないだけかもしれないけど・・・)

あとオープンソースのtoolを使う事が考えられるけど、僕の観測範囲が狭いのかもしれないがqiita teamのようなossは存在 しなかった またossを使った場合は自分の要件にフィットしない事がほとんどかと思う、上に書いているのと同じで要件に対してフィット しないtoolを使っている場合、どこかでストレスがたまって、最後には崩壊してします気がします ※もちろん要件がばっちりでtoolが業務にフィットする場合ossはすごく良いと思います、弊社でも色々使っています

って事で内製しようかと思います

思ってる事をだーーーっと書きました、文章がまとまってないのはいつもの事です

情報の共有については改めて考える機会をくれた rebuild.fm , @naoya_itoさん, @miyagawaさんにはもっっさ感謝です

あーーざっす