Mac Book Proのスリープ時の運用方法

さて、最近Mac Book Proが壊れてしまいました。
運良く修理は終わったのですが表に出てきた症状の1つにスリープ時からの復帰が異常に遅いということ。
いつも作業途中の状態のまま蓋を占めてスリープさせるのですが、修理が終わった後もこの復帰が異常に遅い。

スリープ時に注意すること

色々試行錯誤していたのですがどうもSkypeとかWebブラウザとかを起動したままにするのが問題な気がしてきました。
どうも動作を見ていると、アプリケーションはスリープから復帰すると復帰処理を色々行っているように見えます。
特にネットワークを使うアプリケーションは色々重くなりがちな印象を受けます。
また、メモリを多く使いがちなアプリケーションも復帰処理が重いようです。
アプリケーションが1,2つ程度ならこれでも許せますが、ある程度多くのアプリケーションを起動したままスリープからの復帰を行うと、この復帰処理が重くなる原因のようです。


結局ターミナル以外のアプリケーションはターミナル以外は全て終了させてスリープさせるようにした所、復帰が快適になりました。
私はエンジニアですので最悪ターミナルさえ元のままであれば良いのです。screen使いなので最悪ターミナルが落ちても問題はないのですがw


ただこれだけだと復帰が軽くなっただけで結局元の作業状態に戻すのは結局重いのです。
例えば、Webブラウザの復帰処理。FirefoxGoogle Chromeあたりをメインに使っていますが、タブを復帰してくれるのは当たり前。
でもタブを多く開いているとタブを全部読み込むのが重い。FirefoxにはBarTabという使っていないタブを裏で読み込ませないというaddonがあった。
今はデフォルトでこの機能が備わっています。
で、Chromeにはこの機能がないようなので、Chrome版BartabのFooTabを入れています。これでWebブラウザの起動が重いという問題は解決。

重いプロセスの停止

次に、Macのデフォルトで裏で動くプロセスです。
大体ハードウェア、特にHDDにアクセスしているっぽいです。

mdworker

私はVimmerなのですが、Vimを使っている程度で急に重くなる現象があります。
Vim程度で重くなるはずがなく(よほど重いファイルを開いているとかでも無い限りですが...)、調た結果、原因はVimではなくSpotlightの検索用インデックスを作るプロセスが重いようです。


Spotlightなんて自分は使いませんので(find,grepで十分です)、以下のコマンドでまず停止します。

$ sudo mdutil -i off /


さらにこれをしても再起動を行うと起動するようです。ですので起動そのものを停止してやります。

$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.index.plist
$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.scan.plist
$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.spindump.plist

systemstats

どうやら、システムの状況を知るコマンドらしいのですが、使っていないのにいつの間にか起動していてすごく重い。
今から考えると、HDDとか一部のハードウェアが壊れたために暴走していたのかも知れませんが、とにかく重い。


まずはプロセスをkillします。

$ sudo pkill -kill systemstats


そして起動も抑止。

$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.systemstats.analysis.plist
$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.systemstats.daily.plist
$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.systemstatsd.plist

Linuxでもlocateの為に動くプロセスとかありますが、ここまで酷くはなりません。何より夜中に起動してさほど長くは動きませんし、ましてや暴走なんか見たことないです。
Macは正真正銘のUNIXですが、どうもLinuxに比べて動きが良く分からない所がありますね。

わたしの個人的なパスワード管理方法

最良のパスワード管理ソフトを求めて - WSJ.com を読んで。
こいうったアプリを使って管理するのは悪いとは言わないけど、アプリが公開終了したりすると目が当てられない。
あと、アプリが実際何をしているかもよくわからないし、古いエンジニアとしては中身も知っておきたい。特にこういう大事なデータを管理するものだと。


いまだとこういうアプリもありだけど、現実問題として一昔前にはこんなのないから結構考えた。
SQLiteのようなDBで管理するとかも考えたけどUnixエンジニアとしてはテキストファイルも怖い。いやかなり昔はテキストファイルで管理もしていたんですが、時間が経つにつれ怖くなってくる。
セキュリティは別にしてもテキストだと昔は良いフォーマットがなく、適当に書いていって後で分からなくなる。

結局グダグダになるのがいつものオチだったのですが、結局落ち着いた方法は

  • テキストファイルで書いていく
  • フォーマットはcsvjsonとかもありますがオーバスペックですし、csvなら1行1アカウントで分かりやすい
  • GPGで暗号化して管理。暗号前ファイルは当然削除しておく
  • パスワードはpwgenコマンドで作成

変にセキュリティを自前で考えたり、高度な事を考えても切りがないのでこのあたりで落ち着いています。
これならば、暗号化したパスワードファイルは持ち運べますので便利です。
スターパスワードがバレれば終わりですが、それはどのアプリを使っても同じなので考えても仕方ないです。

隙もありますが(暗号化解除したファイル見られたら終わりとか)、ほどほどの労力でそれなりのセキュリティが保てておすすめです。

クラウドソーシングは使わなくても面白い

久しぶりの記事です。
仕事が半端無く忙しい。そもそもあの部分がああだからとか色々毒を溜め込んでいます。
世の中の皆さんはGW楽しんでください。


さて話題のクラウドソーシングサイト、個人的には登録はしていますが、特に使ってません。
使っていない理由はいくつかあります。
普通に会社に雇われの身だということ、副業している暇がない、話題になったように内容が結構アレなこと。


多少なりとも仕事を経験して地雷を踏んだりすると(地雷しか無い気もするけど...)、色々勘というのが身につきます。
自分は特にこのあたりの勘を説明できる力が無いのですが、でもなんとなく分かる。
そして、そんな目で見ると結構アレなのは分かる。というか普通に考えてリアルを優先するはずなので訳あり案件が圧倒的に多いのが想像できます。
まあ、中にはプログラムを教えてくださいとか、作りたいものがあるけど経験ないし知り合いもいないとか、人が集まらなそうな組み込み系で真面目に募集していたり(そう見えるだけですが)、裏事情が面白そうな案件もあるけどね。


でも時間のある時は見ていて面白い。
何が面白いというと、地雷だからこそそこに一般的に解決できていないけど要望がある案件があるわけです。
ですので、市場の本当の要望(妄想かもですが)だったり、困っている特定の業界だったりがわかります。
自分で会社作ったり、フリーランスの人だったり、プライベートプロジェクトを作りたい的な人達は見ておいて損は無いと、自分は勝手に思っている。
ここからアイディアのきっかけになったりしないかなぁとかも思っています。
ですので、自分はうまく行けばこれだけで生きていけないかなぁという妄想を抱きつつ見ているわけです。
さらにはある程度知識があると、裏の事情も見えてきそうでそういうのも楽しい。多少不謹慎とか言われるかもですがw


特に落ちはありませんがこういう楽しみ方もあるよというお話でした。

今の時代に新人エンジニアは何を勉強すればいいのか?

特にこれと言った正解はないのですが、つらつら書いてみましょう。


弊社にも新人が入ってきたのですが、自分の時を思うと周辺技術がすごい違う。
自分がいる業界が自分の新人の頃と違うというのも原因ですが、大学で勉強するメインの言語ですら自分の時代はC、今はRubyなんて大学もあるようで大分違います。


そんな新人にCや下回りのマニアックな部分を勉強しろ、自分達年寄りがたどった道を歩け、とはとても言えない。
けれどImmutable InfrastructurとかDockerとかばかり触たり知っていても、いざという時は下側の知識が必要になってきます。
こんな知識多分99%以上は役に立たないけど、やっぱり必要だし知っていれば知らないよりよほどいい。


パターン1:それでもやっぱり勉強しろ
業界によっては勉強せざるを得ないという場合はあります。
それ以外でも勉強できるなら、したほうがよいです。やっぱりエンジニアの基礎知識ですし、かならず土台になって今後のエンジニア人生においてとても役に立つはず。
でも、めっちゃ大変だよ。ほとんど使う機会もないし。応用がすごく出来るのがいいところ。


パターン2:軽く抑えておく
情報処理だとかLinuxの教科書的な本を手に入れて軽く抑えておく。真面目に勉強しなくてもいいけど単語だけも頭の片隅にあれば何とかなりそう。
きちんと分かってなくても必要になればググればいいしね。遅延処理大事だよね。
あ、資格自体は無駄なので当然無視ですよ。
多分これのあたりが現実的かなぁ。Wikipedia眺めるだけでも面白いですよ。


パターン3:無視
多分これが現実で取られる対策だと思います。でも知識が穴だらけになるので、応用効かない気がする。


結局、このあたり楽しみながら要領よく乗り切るかどうかで淘汰されるかどうかに影響与えそうだなぁと感じます。
でも自然淘汰される人は少なくなってほしいなぁと思う

オブジェクトをそのままで送受信するPipe

IPCの中でもPipeはTCPとかのネットワーク系の基礎になったもので、結構使いやすくて個人的に好きな機能です。
特にスレッドを使うと、スレッド間通信用に多用します。
自分でリングバッファとか作るのも1つの手なのですが、自前でこういうの作るとブロッキングが出来なくsleepとかいれざるを得ないのでちょっと厄介なので特別な理由がない場合使いません。


さて、これを今回Rubyで使おうと思ったのですがRubyの場合IO#pipeで作りwrite/readを使うので文字列でしか通信できないのがネック。
送受信したいのはあくまでもRubyのオブジェクト。Cだと、どうせ同一プロセス内なので型を統一してポインタをwrite、readしたらキャストすればOKなのですがこの技が使えない。
http://docs.ruby-lang.org/ja/2.1.0/class/IO.html#S_PIPE
http://docs.ruby-lang.org/ja/2.1.0/class/IO.html#I_WRITE
http://docs.ruby-lang.org/ja/2.1.0/class/IO.html#I_READ


諦めるのも嫌だし仕方がないので、悩んだのですがMarshalを使うことにして動作するのを確認しました。
http://docs.ruby-lang.org/ja/2.1.0/class/Marshal.html

class ObjctPipe   
  def initialize  
    pipe = IO.pipe
    @rp = pipe[0]
    @wp = pipe[1]
  end

  def write(obj)
    objs = Marshal.dump(obj)

    len = objs.length
    lens = [len].pack('L!')
    @wp.syswrite(lens)

    @wp.syswrite(objs)
  end

  def read
    lens = @rp.sysread(8)
    len = lens.unpack('L!')[0]
    objs = @rp.sysread(len) 
    obj = Marshal.load(objs)
    return obj
  end
end


# 使い方はこうなります
pipe = ObjctPipe.new

# read側はスレッドで行う
Thread.new do
  while true
    obj = pipe.read
  end
end

# write側
while true
  # データを作成しておく
  pipe.write("なにかobject")
end


いくつかポイント

  • write側スレッドとread側スレッドで同じ'pipe'オブジェクトを使いますが、Mutexは使っていない
    • これは、実質同じデータにアクセスしないのでスレッド特有の問題は発生しないからです
  • 送信するobjectをMarshalしておく
    • 当然Marshalの制限がかかります
  • objectを送信する前にオブジェクトサイズを送る
    • サイズはpackで'unsigned long'にしておき、'オブジェクトサイズ'自体の大きさを固定しておく
    • これはread時のバッファやブロッキング動作が絡むからです
  • write/readではなくsyswrite/sysreadを使う
    • これは文字コードが絡んできてデータによってはwriteでエラーになるから


Rubyってobj.__id__でオブジェクトIDは作れるのですが、IDからオブジェクトの復活方法が分からないのでこの方法を取りました。
Marshalやpack/unpackが入るのでCに比べて無駄が多いのですが、まあ許容範囲内でしょう。
意外と便利に使えています。

会社での開発体制改善中

ここ5年程はWeb業界で働いていてWeb業界で現在2社目。
前職の最後の方ではそこそこ業界で有名になった企業。現職は上場している企業なわけですが、両方とも開発体制、手法がひどい。


端的に言えばいきあたりばったり開発です。
ディレクタに当たる人たちが、まともに仕様書を作れないから仕様書を作らない or 作っても要望書というか夢リストになるだけの書類しか作れない、でも自主的に勉強もしない。
そしてそういう人たちだけが出世する会社。
でもエンジニアはそれなりにスキルがある人たちが多いという現場なので、エンジニアが空気を読まされて、なんとか物をつくってリリースするという最悪な状況。
当然エンジニアの仕事もドキュメントは少なくというかほぼ存在しない、テストコードもほとんど書いていない。
最近はDevOpsとかも取り入れていますが、それはエンジニアだけの改善策であってディレクタが変わらない。
マジで最悪。


とはいっても、現在の職場の人たちはそれでも知りたいという気持ちはあって、エンジニアが勉強会を開くと参加もしてくれる。
最近だと会社のサービスを例に1からサーバ構成とか、Rails(うちはRailsが基本です)の仕組みを教える勉強会を開催すると参加はするし、質問ももらえる。
つまり、少なくとも現職勉強しないのではなくて、勉強方法が分からないのだと思う。意欲はあるのだから。


さて、最近自分は完全に新規のプロジェクトを担当している。しかも会社としては初のチャレンジ部分だ。
当然ながら仕様はきちんと決める必要があるし、テストも大事だ。エンジニアよりもディレクタの人数が多く、相変わらず夢物語も多い。
ここいらで何とかしたいし、何とかして良い効果がでれば開発手法も横展開したい。
で、どうするかだが、悩んだ結果大まかな部分はウォーターフォール型で開発すると宣言して、実際の開発ではスクラム開発を採用するという、かなり変則的な方法をとった。


ウォーターフォールとはいっても話は簡単で、はじめにきちんと仕様書をつくる。仕様書を作る段階では何回もチェックをいれて修正を行ってもらう。その次に開発を進めて、最後に一斉にテストだ。ウォーターフォールっぽい。
もちろんこれがきちんとしたウォーターフォールだとは思っていないが、目的はきちんと仕様書を書かせることにあってそのための方便として'ウォーターフォール'という言葉を使わせてもらった。
ここをきっちりしないと、開発が進まないので彼らからしたらかなり厳しい要求をした。仕様書はダメ出ししまくり上司だろうが関係なし。
結果出来たのは仕様書とは言えないが、仕様書になりかけの要望書と言ったところ。
前職合わせても、ここ数年のWeb業界で見たなかでは確実に良い出来でしょう。


でもこのままウォーターフォールで開発を行うとテスト段階でバグが出まくるし、そもそも開発時間が少ない。そこでスクラム開発の出番だ。
今回入ってもらうスクラムマスタに当たる人と相談して、時間がないので出来るだけスクラムそのもので余計な時間を取らないように相談した。また、がっちりスクラム開発の枠にはめてもいない。
結果、今回はこうなった。

  • 基本エンジニアのみにスクラム開発を適応させる
  • スプリントは1週間
  • ディリースクラム
  • 日報、これは少しから導入しているので継続中
  • KPT
  • 週末の振り返りなどのMTG
    • これだけはディレクタも参加する
  • ホワイトボードでタスク管理
    • 反対が多いのでPivotal Trackerなどのツールは使わない
  • エンジニア側では別途仕様書を作成する
  • Rdoc/YARD等で細かい部分のドキュメントを作成する
  • Rspec等でのテストコード作成
  • Jenkinsでの自動テストを実施する


まだまだ走りだしたプロジェクトだが、そこそこ前には進んでいると思う。
すでにいくつか良い意見ももらったり、効果も出てきていると思う。

  • 仕様書のレビューして修正という形は、しんどいが良い効果がある
  • ディリースクラムは横で聞いていたディレクタには悪くない印象
  • 作った物のレビューは良い反応


個人的にはアジャイルスクラム開発は両手を上げて賛成はしていない。
だって、OSSとかだとこんなことしなくても開発できているプロジェクトもあるし。そもそもこの業界にいてエンジニアではないにしろ勉強しない奴がいる事自体がおかしい。
もちろんテストコードを書いたり、Jenkinsでの自動テストとか好きな部分もあるのは確かだ。TDDは精神力を多大に浪費するのでしんどいけどw
良い結果が出始めている事なのは確かなので、開発の管理が出来ていないと悩んでいる方たちはこういうフレームワークをうまく取り入れれば良いとおもう。

謹賀新年

さて、年が明けました。


昨年はWebサービスを1つ作りましたが、結局先日中止しました。
http://khondalit.hatenablog.com/entry/2013/07/07/024922
仕事で忙しくなり結局停止。
時間がない中での複数人での開発は厳しいなぁというのが今の素直な気持ち。
ただ、仕事ではいくつもWebサイトを作って来ましたが、個人でも作るのは問題ないのを実感できたのが大きい。
ということで、今年の目標は真面目にWebサービスを1つは作ります。


あと、どこかで http://linuxc.info/ の更新も少しずつします。
ただ、仕事で新規プロジェクト(しかも結構無茶なの)を担当することになったので、今年前半は厳しいかもです。