Ruby on Railsの作者であるDHHは、2012年に投稿されたブログポストの中では5つの技術書を紹介しています。タイトルは『The five programming books that meant most to me』。

The five programming books that meant most to me: http://t.co/u0RKkEU7

— DHH (@dhh) December 26, 2012

日本語でいうと「私がもっとも参考になった技術書 5選」といったところでしょうか？
どのような本を選んだのかと、その本に関するエピソードや読み方？のようなものを書いていきます。

5つの本は以下になります。名著と呼ばれるものが並んでいますね。

• ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集
• リファクタリング 既存のコードを安全に改善する
• エンタープライズ アプリケーションアーキテクチャパターン
• エリック・エヴァンスのドメイン駆動設計
• ライト、ついてますか―問題発見の人間学

ちなみにどの順番に読むべき？というtwitterの質問にも答えています。
...

>> Continue Reading

randomにテストが落ちてしまう

どんな種類のテストでもrandomにテストは落ちてしまうことがあります。
Ruby on Railsを利用している場合にもっともこのような不安定なテスト (flaky test) になりがちなのは、Capybaraを利用したsystem test/system specではないでしょうか。
私がrandomに落ちるテストと戦った中で得た経験をここに記しておきます。

基本的に自前で sleep はしなくて良い

ページ遷移の直後や描画された直後にclick_linkやclick_buttonなどを実行すると、ブラウザの描画よりもブラウザを操作するテストの実行が早く走ってしまいrandom落ちを引き起こします。
そういうときの解決策として sleep 0.5 などとして、テストの実行を止めるアイデアを思いつくでしょう。

しかし、capybaraは Capbypara.default_max_timeout までは、対象のコンテンツを探してくれるメソッドが用意されています。
ですので、基本的に自前でsleepする必要はありません。

例をいくつか挙げておきます。

click_link '次へ' # ここでrandom落ちしたら

within '.some_dom' do # 次への親要素を探すまで待たせる
  click_link '次へ'
end

find('.next').click # 次へのリンクを探してからクリックする

expect(page).to have_content 'some content' # 画面遷移の直後の場合は expect も有効です
click_link '次へ'

within / find で超えられない壁

find('.some_dom').click # .next_domが表示される
find('.next_dom').click

...

>> Continue Reading

別に問題じゃなさそうなことに問題って名前をつけたのは公式で用意してくれているバッチインターフェースが二つあって、いつも迷っちゃうからだ。

$ rails foo:bar:baz

のようにコマンドを作れるのがrake taskです。
これは普通にrails db:migrateやrails g scaffold Fooのようにいろいろなところで開発者が使うからおなじみのコマンドです。

もう一つのインターフェースが、rails runnerと呼ばれるやつで、こちらは引数に自由にruby(しかもrailsの資産をつかった)のコードを書くことができる。

普通にバッチを書くならどっちでも問題ない

基本的にどっちを使っても問題はありません。しかしrails runnerを作るときはインターフェースを自分で考える必要があります。以前言及した記事としては app/batches 配下にバッチフレームワークのようなものを作り、 rails runner FooBatch.run のように書くものでした。

自前のバッチフレームワークのようなものが必要なのはひょっとしたら過去の時代の話かもしれません。例えばkuroko2やjenkins、rundeckのようなcron replacementと呼ばれるツール群を使えば、共通処理で書いていた排他制御やロギングなどをそちらに任せることができます。そしてkuroko2やjenkinsの先ではrailsの入ったdockerを実行させるようなことも簡単にできます。
また、dockerの話を続けるとk8sのcronojobを使えばGKEやAKSのサポートの上で、kuroko2で得ていた問題を吸収することができます。

rails runner と rake task のどちらを使おうとも、結局バッチを実行するツールが実行するインターフェースはdocker runのようなものだったりするわけです。

そもそもバッチっていつ書く？というもう一つの問題

...

>> Continue Reading

GitHub が新たに開発した GitHub用のCLIツールがめっさ便利なので、勢いあまって記事を書いたのですが、塩漬けにしていたので、とりあえず公開。
もう速報性はなくなってしまったけれど、便利に使っています。便利。

cli/cli： GitHub’s official command line tool
これね。

hubコマンドクッソ便利(でした)

$ git push origin feature-bransh

したあとは、そのまま

$ hub pull-request -o

とするのが手癖として根付いています。

hubコマンドに対する不満

手癖になってはいるのけれど、解決できていない問題がありました。
それはPull Requestをdraftで生成できないことです。

ですので、DraftのPull Requestを作りたい場合は $ hub browse を使ってブランチを表示。その後、ブラウザ上でPull Requestを作成していました。

$ gh pr create -w という革命

$ gh pr create -w

これを使えば今までやりたかったPull Requestの作成が簡単になるだけではなく、全てをdraftで作ってから細かい点をブラウザ上で修正するというワークフローがやりやすくなりました。

見た目を伴う修正の場合は、スクリーンショットをPull Requestのdescriptionの項目に貼ったりしますので、この辺りも便利です。

$ gh pr create -df を使えば完全に作業途中のpull requestを一時保存するのにも使えます。

gh コマンド便利

hubコマンドは手癖になってしまっているので、とりあえず今から $ brew uninstall hub を実行します！！！

>> Continue Reading

オンラインコミュニティnoraneeresのメンバーと一緒に、愛媛県八幡浜市に行ってリモートワークをしてきました。

リモートワークで場所を変えるというテクニック

...

>> Continue Reading

はい。 #しがないラジオmeetup 4 - connpass に参加してまいりました。
(そういえばpodcastの話はあんまりしなかったな〜)

しがないラジオmeetupとは

『しがないラジオ』というpodcastを一回でも聞いたことがある人が参加できるmeetupです。podcast好き率高めですが、エンジニアとかそういう縛りは特にありません。
今回は公募枠LT5枠とスポンサーLT1枠、パーソナリティのお二人のLT2枠と、懇親会という内容でした。

エージェント完全脱出マニュアルというタイトルでLTしてきました

見事、公募枠のLTに当選し登壇してきました。
最近、登壇とかやってなかったし、LTにしては10分と割と枠があったので、緊張感もあり楽しめました。

https://t.co/xe5qimyWVu

— すぎちゃん🎙🎧💻 (@koheiSG) December 17, 2019

なんだか、見境のなくあやかりまくったスライドが気がついたらできてました。ごめんなさいmm

10分のLTにスライドは40枚。
緊張と早口で大阪弁全開でまくしたて立ったぜ。
...

>> Continue Reading

流しのRails業でチームの中で共有したtipsをちょっとずつブログにも書いていくぞという。気持ち。
ちょっと初心者向けの話題のように思うかもしれないけれど、私もなんども苦しんだことなので。

$ rails g scaffold Book name:string price:integer

scaffoldでこのように生成したとしよう。
そうすると、BooksController#create は以下のように生成される。

# POST /books
# POST /books.json
def create
  @book = Book.new(book_params)

  respond_to do |format|
    if @book.save
      format.html { redirect_to @book, notice: 'Book was successfully created.' }
      format.json { render :show, status: :created, location: @book }
    else
      format.html { render :new }
      format.json { render json: @book.errors, status: :unprocessable_entity }
    end
  end
end

もう少し簡易化してみましょう。

# POST /books
def create
  @book = Book.new(book_params)

   if @book.save
     redirect_to @book, notice: 'Book was successfully created.'
   else
    render :new
  end
end

respond_toを排除し、HTMLしか返さないようにしてみました。...

>> Continue Reading

プロジェクト管理ツールBasecampの最高技術責任者、デイヴィッド・ハンソンさんの仕事術 | ライフハッカー［日本版］

iA writerを知ったのも、この記事だった。
自分のタスク管理のやり方を見直そうとなんとなく調べていたら、こんな記事を見つけた。
確か、以前にも読んだことがある内容だったんだけれど、iA writerもタスク管理の方法も試せていなかった

DHHという憧れの人物のタスク管理が響かないタイミングもあるんだな。本当に人生はタイミングですね。

記事で印象に残ったこと

私はほとんどのことにNoと言っています。そうすれば、自分で本気で選んだ少数のことにだけに、完全にコミットできます。
余計なことは人生から取り除けば時間はたっぷりあるはず。

明日はいくつかNoと言えるようにしたい。

メールのInboxを空にすることには執着しています。

僕はメールはほとんど見ないけれど、DHHのGTDの基本はメールになっているよう。
また、slackは本当に有害だと思うので、どうにかしたい。
あとはtwitterを読まないということも大事だよなぁ。フォローを減らすなりリストしか見ないなり情報を減らす必要がありそう。

一般的に私がトラッキングするのは、自分のコントロールが及ばないことに関してだけ

私の場合はomnifocusを整理する必要がある。
自分のタスクもかなりトラッキングしてしまっていて、この辺の使い方をマスターする必要がある。小さなチーム大きな仕事ではTodoListは11個までにしようっていってた気がする。
GTD的にいうとnext actionは11個までで良さそうだ。

DHHマニアとして

RailsやBasecampの記事をひたすら漁ってる自分としては、日本語で読める記事が意外なところにあって見落としていた。DHHリンク集を作ろうかな(笑

>> Continue Reading

iA writer というソフトを知ってますか？？

このソフトはめっちゃいいです。このソフトが刺さる人は下記のランディングページの動画を見ただけで釘付けになって、とっさにダウンロードしてしまうはずです。

iA Writer： The Benchmark of Markdown Writing Apps

iA Writer updates for the public betas of iOS 13 and Mac OS Catalina are available. Some small bug fixes, too. Update and enjoy. Tell us over mail ([email protected]) if you find something funny. https://t.co/rOOtgFcqyG pic.twitter.com/j1WbnZnD6A

— iA Writer: The Writing Experience. (@iAWriter) August 12, 2019

何がいいって、書けば書くほど集中できます。
これをweb上で体験させるのはそう簡単ではないよなと諦めの境地に行けるような気分になります。

これに近い書き味のものにDropbox Papperがあります。
ただ、やはりブラウザの限界といったところでしょうか、iA writerがうたっているfocusという部分に多少の不足を感じてしまいます。

iA writerがあれば文章を書くのが楽しくなる

...

>> Continue Reading

現在フリーランスのエンジニアをしています。
常駐仕事、リモート仕事、請負仕事を同時並行的にやっています。

技術力の壁を突破するためには、自分でできる事業より大きな事業にコミットしたいので、正社員でサービスの成長にコミットする仕事を探しています。#Twitter転職 pic.twitter.com/Z7aMcjTxPT

— すぎちゃん@noracast (@koheiSG) January 25, 2019

転職活動をすることを表明しましたが、
今現在自分が壁と考えていることを書きます。

権限の壁

私の経験上AWSの管理者権限をフリーランスエンジニアとして、任されることは少ないです。
AWSのサービスをフル活用して貢献するためには、
AWSやインフラに精通し、社外だとしてもこの人間に権限を委譲した方が生産性が高いと認定された場合に限ります。

こういった権限はAWSだけではなく様々な重要な意思決定に絡んできます。

組織の壁

フリーランスのエンジニアが組織構造に対して助言することはあっても、
そこに対する意思決定までのプロセスが常に公開されていることは少ないです。
ある程度の規模の会社で経営経験があり、経営者に対してのアドバイスを求められる場合にのみ、
それらが委譲されるでしょう。

お金の壁

フリーランスはお客さんの事業へのお金の決裁権は通常は一切持ちません。...

>> Continue Reading

rails 界隈では Sider の普及に伴い rubocop を業務で使っている方も増えてきたのではないでしょうか？
しかしながら、一度荒れ果てた荒野にrubocopを放っても成果はほとんど上がらないことでしょう。
必要なのは、すべてのコードを綺麗にするぞ！という高尚な志ではなく、現実を少し改善すれば、それでOKという意識低い気持ちな気がします。

--lint オプション

rubocopには -l または --lint というオプションがあるのをご存知でしょうか？
こいつはlintオプションと呼ばれるやつで、bugに繋がりやすい警告レベルを指摘してくれます。

こいつをまずデフォルトにしましょう。
.rubocop ファイルに --lint と記述すると、rubocopのコマンドが常に--lintオプションがついた状態で実行されるようになります。
.rubocop ファイルを使うことで、プロジェクトのメンバー全員がそのオプションをつけてrubocopを実行することができるため、「 rubocop -l と実行してください！」などと呼びかける必要がなく便利です。

rubocop_todo.yml と向き合う

次にこの状態で、rubocop_todo.yml を生成します。
rubocop --auto-gen-config

プロジェクトにこれ以上 --lint に違反するコードを入れないようにするためです。

rubocopを入れると、rubocop対応で色々と対応工数が増えてしまうと恐れている方もいらっしゃると思いますが、
この --lint オプションは宗教戦争的なものはほぼなく、バグに繋がる恐れがあるか？という観点での指摘です。

さて、auto-genされた rubocop_todo.yml には問題が山積です。
これらは指摘事項を修正していかなくてはなりません。

todoファイルと向き合いきれなかった場合

...

>> Continue Reading

associationをデフォルトのfactoryではnilを渡す

一般的にFactoryBotは大きなプロジェクトになってくると無駄なデータを作成する可能性が増えてきます。
例えば、こんな時。

factory :tag do
  article
end

it do
  create_list(:tag, 10)
  # 10個タグがある場合のなんらかのテスト
end

articleがtagを複数持てるDB構造になっているとして、
tagが10個以上付いているページのfeature specなどを書きたい場合がある時に、
上記のような書き方をしてしまうと、tagが10個だけできればいいものの、articleも10個できてしまうのです。

これを抑制するために、

factory :tag do
  article { nil }
end

このようにartilceは敢えてnilを渡して、validateエラーが起こるようにしておきます。
そうするとうっかり、 create_list(:tag, 10) なんて書いてもテストが落ちるようになり、、

it do
  create(: article)
  create_list(:tag, 10, article: article)
  # 10個タグがある場合のなんらかのテスト
end

おそらく、このようなテストになってくれるはずです。

あくまでデフォルトの話であって、traitを使う分には特定のcontextの名前を入れることができるので、問題ないと考えています。

factory :tag do
  trait :with_article do
    article
  end
end

↑みたいなのはOK

FactoryBot.lintの困るところ

で、この方針でfactorybotを運用すると困ることがあり、、...

>> Continue Reading

このテーマ。僕はずっとずっと悩んで来た問題です。railsdm周りで話題になってたっぽい。

ベストプラクティスというものはまだ見えない。
でも、いろいろな実績が出て来たし、自分でもいろいろやって見たのでまとめて行きたいと思います。

1. sprokets + turbolinks + webpacker + stimulus

basecamp wayですね。
それぞれハマりどころが多くrailsに精通していないと使いにくいと思います。
DHH信者にオススメの設定です。

Rails Way は良きものだけど Basecamp Way はガン無視しますね

— たにみち (@ttanimichi) 2018年3月28日

気持ちはわかるけど、染まって見るのもなしではないかな。

2. webpacker + react(or other javascript view library) (+ some cssloader || sprokets)

部分的にreactなどのviewを使う設定。場合によってはcssもstylesheet_pack_tagを使うパターン。
個人的にはこのパターンってreact使う必要ある？という気もします。
が、例えばKPIに直結する非常に重要な機能だけをSPAにして、
UXを最大化するのに使える構成ではあると思います。

この場合はsproketsを捨てない方が無難な気もしますが、
reactの中でcssを使いたい場合や、依存ライブラリをいい感じにシュッとしたい場合はwebpackerに頼ってしまうのもいいでしょう。

3. webpack + rails(without sprokets and webpacker)

例えばsproketsを捨てるのようなやつ。...

>> Continue Reading

テストコードで再現テストをしてから、bugfixするやつ。

不具合にテストを書いて立ち向かう - t-wadaのブログ

これうまく行ったら超気持ちいいけど、いつも気持ちいいとは限らないのでメモ。

バグのパターンがユニットテストとしてエッジすぎ

だいたい再現テストコードがエッジなパターンすぎて、
仕様を説明する助けとして不適切になってしまう。

describe 'somemethod' do
  subject { describe_class.new(params).somemethod }
  context 'A' do
   let(:params) { 'a' }
   it { is_expected.to eq ('A') }
  end

  context 'B' do
   let(:params) { 'b' }
   it { is_expected.to eq ('B') }
  end

  # 再現テストのコンテキストがハイコンテキスト
  context 'B and hogehogehoe' do
   let(:params) { 'a' }
   before do
     # ハイコンテキストな記述 
   end

   it { is_expected.to eq ('A') }
  end
end

↑この程度なら全然いいんだけど野生のコードはこんなのじゃすまない。

このままマスターに入れてマージすると、仕様を説明することを阻害するよなぁ的に。

しかし、マージしておかないと同じバグを繰り返すかもしれないので、対策としてそのハイコンテキストなテストを別ファイルに切り出したりしてる。

コンテキストやフィクチャでテストのファイル分ける

1つクラスに1つのテストファイルがデフォルトですが、
テストファイルがって大きくなってきたら、コンテキストやフィクスチャ、メソッド単位でテストファイルを分割しても問題ないわけです。
...

>> Continue Reading

ブログ移管した

ブログを jekyll + github pages での運用から、独自のCMS(heroku + rails)に移行しました。

移管した理由

オンラインからサクッと編集したい

記事の雛形は make post みたいなコマンドを書いて、サクッと記事を書き始められるようにしてはいたのだけれども、、、
ちょっとした修正を出先や移動時間にするのにgithubに接続してブラウザから修正することにイライラしており、サクッと編集できるものが欲しかった。

jekyll疲れ

jekyllのプラグインとか拡張とかに限界を感じていた。

GitHub離れ

買収が発表される前から検討していたので、半分冗談ですが、移管完成がこのタイミングになったのはこれもある。
blogはコミットを外に公開したくなかったので、privateリポジトリで運用していましたが、
microsoft買収により自分が課金する必要もないかなと思いました。

このお金はherokuに払っていくぞ！頑張れheroku！

(あといくつかのprivateリポをgitlabかbitbucketに移管すれば、コスト削減も同時に達成できます。ありがとうmicrosoft。)

移管先の検討

wordpress

• 拡張性は高いものの、拡張しすぎると辛そうなので手を出すのをやめました。
• また移管したい気持ちになるので、その時は楽なんですけどね。

ブログサービス系 (medium/note/qiita/はてな/livedoor/line)

この辺りのツールはスマホからも修正がかなり簡単で圧倒的に使いやすいのです。
が、当たり前ですが融通が効かない点も多いので、断念しました。

自作

• 最近メディア関連のお仕事が多く、blogに近いものをサクッと作れるノウハウが溜まってました。
• あわよくば複数のメディアを同じblogツールを使って運用できるかもという下心が湧いてきちゃいました。
• esaやkibelaやwikiツールも作りたくて同じような仕組みになりそうだから、とりあえず個人ブログだけ作ってみた。...

>> Continue Reading

前回 に続いてどうやってプログラミング覚えたか？シリーズです。
こうしてHTML/CSSをなんとなく覚えた私ですが、次は動的なサイトを作りたくなっていきます。

geocitiesからxreaの移行

geocitiesではhtml/css/javascriptは満足に動きますが、サイトを訪れた人が掲示板などサーバー上で動作するプログラムを置くことはできませんでした。

当時、ホームページを個人で運営している人は二つのいずれかの方法で、掲示板を運営していました。

• レンタル掲示板と呼ばれていた類のサービスを使う
• CGIが動くサーバーで、CGIスクリプトを動かす

前者は会員登録をすれば誰でも簡単に自分のサイト専用の掲示板を持てます。
後者はCGIの知識が多少必要とされますが、CGIスクリプトは配布されているものを使用すれば、動かすだけであれば、プログラミング自体の知識は必要ではありませんでした。

今でいうと、blogを始めるときにライブドアブログやアメブロを使うのか？wordpressやmovabletypeを使うのか？みたいな違いです。
wordpressを使えば様々なデザインや動きもカスタマイズできますが、ライブドアブログやアメブロではそこまでできません。

自分はカスタマイズも想定して、CGIが動くxreaと言うレンタルサーバーに自分のサイトを移管しました。

無料スクリプトをアップする

xreaにサイトを移管してから、配布されてるCGIスクリプトをサーバーで動かしました。
配布されているCGIスクリプトは、それぞれ微妙に設定の仕方が異なっており、動いたり動かなかったり悪戦苦闘をしました。

CGIスクリプトの提供者側で用意してくれている設定に慣れてくると、自分でも動作をカスタマイズしたくなってきました。
wordpressでいうとプラグインの改造くらいの難易度だと思えば良いと思います。

改造がしやすいCGIスクリプト

...

>> Continue Reading

どのようにしてHTML/CSSを身につけたか

きっかけはバンドを組んでないのにホームーページを作ろうとしたこと

中学校二年生の頃、バンドを組んでないのにバンドのホームページを作りたいと思っていました。
ある日、ある友達がホームページを持っていることを知り、彼にfront homepage express入門本を借り、早速サイトの制作に取り掛かりました。

その本を読み終え、geocitiesに簡単なテキストサイトを公開したように思います。

front homepage expressだけではいい感じのサイトにならず、どうしてもかっこ悪いデザインになってしまう。そこで本の巻末にあったメモ帳でhtmlファイルを編集する方法でサイトの更新を行うようになりました。

この時友達に質問したことを今でも覚えています。

sg「画像の横に文字書くのにはどうすんの？」

友達「罫線のない表を組めばいい」

爆誕tableレイアウトコーダー

tableレイアウトを覚えるとどんなデザインでも実現できるようになりました。
僕は様々なレイアウトのページをhtmlで作っていました。
htmlだけを作るのが楽しくなって、絵を描くようにいくつもサイトを作っていました。
サイトのメニューをいい感じに作れるようにframeタグもうまくつかっていました。
この頃にはエディタもterapadというお気に入りのエディタがありました。

「違う。。何かが違う。。俺のサイトはyahooとは全然違うぞ！！」

そう思った僕はありとあらゆるサイトを 右クリック→ソースを表示 を繰り返し、cssを学んでいきます。
ググりまくる中で、プロはレイアウトをdivで組むしいということを知り、floatレイアウトを覚えました。

cssは僕にとって最初aタグのhoverを作るためだけだったものでしたが、htmlは構造を書き、cssで見た目の装飾するという基本に気づいたのはこの頃でした。

インターネット上に公開されてるhtmlのソースを見て、見よう見まねでhtmlを覚えました。
この時に論理だった話はあまり勉強しなかったように思います。とほほさんのサイトにはお世話になった気がしますが、htmlは直感で乗り越えた気がします。
...

>> Continue Reading

jekyllにブログを変えてみました。
markdownで記事を書けるのはやはりすごい楽です。
お気に入りのエディタであるvimで書けることも素晴らしいです。
やったこと、やってないことをまとめておきます。

やったこと

bloggerで運営していたブログを移管しました。
一部labelページ以外を除いて、同じURLに移行しました。

bloggerで長らく運営していたこのブログですが、
bloggerのhtmlがなかなか弄りにくいことが主な要因です。

blogger自体テーマがあまり充実していないのと、良いテーマがあっても、
それをカスタマイズするのにhtmlのようなxmlを弄るのに疲れてしまいました。

wordpressという手段もあったのですが、静的サイトジェネレータに興味があったので、
今回のような形になりました。

ちなみに静的サイトジェネレータをjavascriptで作ろうとしたのですが、
そこは挫折してしまいました。。

なんでhugoじゃないの？とかなんでoctopressじゃないの？
って質問があると思うので、書いておきます。

hugoじゃない理由

rubyでpluginを作れることとgithub pagesでメジャーな手段になったことくらいでしょうか。
hugoは正直魅力的なので、どこかで試してみたいとは思っています。

octopressじゃない理由

htmlを弄りやすいようにしたいことが、今回の動機でもあったので、
octopressはテーマは充実していますが、htmlがそんなに得意ではない自分ではoctopressのテーマは弄りにくいなぁと思いました。
あと、jekyllの方がdocsも充実しているように見えたのと、コード自体の見通しもよかったです。

その他検討したもの

フロントの実装がメインになる静的サイトジェネレータですから、javascriptで全てを統一するという夢は僕もみました。
javascriptのエコシステムでほとんどのものがそろっていますので、gulpで適当にビルドしたりデプロイしたりは容易い御用なはずです。

そこでmatalsmithというjavascript静的サイトジェネレータを検討していたのですが、...

>> Continue Reading

毎年F1放送にがっかりしているF1ファンの皆さまこんにちは。koheisgです。

今年はついにBSフジでの録画放送も廃止

BSフジ、2016年のF1放送はなし 【 F1-Gate.com 】

今年はついにBSフジでの録画放送も廃止となり、日本国内でF1を見るためには有料放送の契約が必須となりました。
これを契機にCSを契約されたF1ファンも多いのではないでしょうか。

地上波での録画放送は数年前に廃止になっているので、
すでにF1を見ている人は限られた存在になっているかもしれません。

僕は現在CS契約をするかしないか非常に悩ましい決断を迫られているところです。
だって、CSの契約とか金持ちがやることでしょ。

お金持ちの条件とは

僕は子供の頃、友達の家を下記で金持ち判定していました。

• BS/CSを契約していること
• ウォーターサーバが家にあること、
• 車が外車かクラウン以上

ぶっちゃけ家にいる時間なんて対してないわけですよ。
F1という番組を見るだけのために、CS契約して月数千円ってバカみたいな話です。

それでもF1という娯楽は自分は大好きなので、CS契約するか否かを迫られているわけです。

今年のF1が面白いかで決める

そもそも、去年F1を決勝レースは録画したりあの手この手を振り絞って見ました。
でも、結果はメルセデスの圧勝。ハミルトンは早すぎだし、大したことないロズベルグにだって勝てそうにありませんでした。

その中で、フェラーリ勢がなんとか一矢報いるかどうかを見守るF1。
そんなF1なら正直、今年は見なくていいんじゃないかという気もしてきました。

今年のF1っておもしろいのだろうか。

今年はフェラーリのエンジンがかなり改善されたという噂でしたが、
ライコネンはエンジントラブルでリタイア、ベッテルはあと一歩のところで3位でした。

全くもって、メルセデスのミス待ちという感じで、今年もミスの少ないベッテルとハミルトンを早い車に乗せろ！とマッチがきっと言うはずです。...

>> Continue Reading

ワーキングメモリとは

ワーキングメモリとは自分の脳内のメモのことです。
例えば、買い物に行ったときにメモがなくても、あれとこれとそれが必要と思って、
買い物を順番にすることができます。これがワーキングメモリです。

認知症予防で注目されている分野でもあります。

今自分が考えていること

GTDやチケット駆動開発をしていると、自分で覚えておくべきことは、
全て何らかの形でメモをとることになります。

チームで仕事を行うときのエビデンスにもなるし、自分の記憶に依存することなく物事を進めていくことができるため、非常に大事なことです。

しかし、あまりにも自分が何も覚えておらずチケットやTODOリストを見ないと何もできないくらいに馬鹿になっているような気がするのです。
顕著な例がプログラムを書く時で、あの標準メソッドってどんな引数の順番だったっけ？とgoogleを頼ることがあまりにも多いこと。
もっと、フロー状態に自分を持っていくためにはもっと "ググらないこと" を実現していかなければならないと思ったのです。

ググらない x メモらない で実現できること

例えばターミナルを開いている時は、開発や作業に集中できます。
ドキュメントを作っている時に仕様が全て頭に入っていれば、ドキュメントを書くことに集中できます。

自分の脳の容量を上げていけば、自分の開発スピードをあげることができるんじゃないかなぁ？
と今実践しようと思っているところです。

GTDとは少し考え方が違うのですが、inboxくらいは頭の中に入っていてもいいんじゃないかなぁと思う今日この頃なのでした。

参考リンク

ワーキングメモリ - Wikipedia
ワーキングメモリ（作業記憶）トレーニング

>> Continue Reading

php-nabeのバージョン管理に僕はphp-nabeを愛用しています。
phpenvやphpbrewなど数ある中でこれを使っています。
phpを使わないでphpを管理したいという思想に惚れた訳です。

で、たまに php-nabe ext-install extname でphpの拡張がインストールできるのですが、
下記のようなエラーがよくでます。

$ php-nabe ext-install openssl
Cannot find config.m4.
Make sure that you run '/Users/kohei-sugi/.php-nabe/php-nabe/build/php-5.3.3/bin/phpize' in the top level source directory of the module

/Users/kohei-sugi/.php-nabe/php-nabe/bin/php-nabe: line 416: ./configure: No such file or directory

そんなときは、srcのファイルの中を覗きに行って、

mv config0.m4 config.m4

をしてあげて、もう一度実行するとOKです。

自分でコンパイルしたい欲求を程よく満たしてくれるので良いですよね。。
ただ、普通にyumでphp入れたとき見たいなお手軽感がないので、recipe的な機能を作って、
コンパイルオプションとかをデフォルトで選んだりできれば良さそうやなぁなんて思ってる今日このごろ。

historyを見たところ下記のようなextを良く入れているっぽい。

php-nabe ext-install php_pdo
php-nabe ext-install php_mysql
php-nabe ext-install php-fpm
php-nabe ext-install fpm
php-nabe ext-install php-mysql
php-nabe ext-install zbil
php-nabe ext-install intl
php-nabe ext-install apc
php-nabe ext-install pdo...

>> Continue Reading

とあるrubyのプロジェクトを進行中に不要なファイルがたまってきました。

$ git status -b -s
# master
?? a.rb
?? b.rb

上記のファイルは必要ないので、 git clean -fd を実行します。

$ git clean -fd
Would skip repository vendor/bundle/ruby/2.2.0/bundler/gems/slim-0726c443dfdd
Would remove vendor/bundle/ruby/2.2.0/bin
Would remove vendor/bundle/ruby/2.2.0/build_info
Would remove vendor/bundle/ruby/2.2.0/cache
Would remove vendor/bundle/ruby/2.2.0/doc
Would remove vendor/bundle/ruby/2.2.0/extensions
Would remove vendor/bundle/ruby/2.2.0/gems
Would remove vendor/bundle/ruby/2.2.0/specifications

oh!!!

vendor/bundle の中のgemが消えてしまいました。。
仕方なく bundle install するわけですが、なんで .gitignore の中に入っているはずの、
vendor/bundle 配下のファイルが消えてしまうのでしょう。

自分自身 .gitignore の書き方にあまり自信がなかったので、
いろいろ調べてみましたが、特に問題なし。

git clean -fdx

とかすれば、ignoreされているファイルを消すこともできるようですね。
が、今回の解決策とはなりません。。

解決策は .gitkeep をファイルに置くことでした。
vendor/.gitkeep をコミットすることで解決しました。

>> Continue Reading

能力開発や自己啓発の世界で有名な『7つの習慣』があります。
いまやどこの企業でもこの考え方に近しい考え方が取り入れられた研修を行われています。
本ブログではタスク管理の話を題材として扱っています。
タスク管理を話題にする上で避けては通れないことが、『7つの習慣』で触れられています。
今回は『7つの習慣』の概要を見て行きましょう。

ぶっちゃけ『7つの習慣』とか苦手なんです。。

僕自身は今はなき？ベンチャー・リンクという会社の研修型インターシップで、セミナーが最初の出会いでした。
当時は7つの習慣を冠したセミナーを日本国内で行っていたのがベンチャー・リンクでした。
講師は研修を受けた本物の講師ではなく、内定者が研修を兼ねて行っていました。

それ依頼、7つの習慣に触れたことは皆無です。
就活生で悩み人だったときには大いに参考になった気がしたのですが、
自分のやりたいことが見えてきた時期から、この手の自己啓発本は一切よまなくなってしまいました。

しかし、このブログでタスク管理についての題材をしっかりと扱っていくことに決めたので、
この間のGWの連休中に最近でた改訂版を読み直しました。

ざっくりした本の内容

世の中に偉大な成果を残した人の習慣を研究し、その最大公約数的なものが7つ習慣がありました。という話です。

成功者のタイプにも色々あるので、結構大枠であり方を説いています。
いろんなタイプいるけど、その中でもこれらは共通してるよ、と。

• 第1の習慣 主体的である
• 第2の習慣 終わりを思い描くことからはじめる
• 第3の習慣 最優先事項を優先する
• 第4の習慣 Win-Winを考える
• 第5の習慣 まず理解に徹し、そして理解される
• 第6の習慣 シナジーを作り出す
• 第7の習慣 刃を研ぐ

当たり前っていうと当たり前なのですが、本を読んでいくと深いところが書かれているので、自分も『そのレベルで主体的になれていないかもなぁ』なんて思い直したりします。

ちょっとでも、心のコンディションが悪かったり、斜に構えているところがあると、『は？そんなんで人生うまく行くか！ふざけんな！』と言いたくもなります。
なので、自分の心が素直に受け入れられる状態で読むべきでしょう。(特に僕のような性格の人は注意)

...

>> Continue Reading

ベイスターズ強いですね。素晴らしい。

というわけで、各チームの4番を調べてみました。

【セ・リーグ】  
横浜 筒香(1991年11月26日 (23歳))  
読売 太田(1990年6月9日 (24歳))  
中日 ルナ(1980年2月1日 (35歳))  
ヤクルト 畠山(1982年9月13日 (32歳))  
広島 ロサリオ(1989年3月29日 (26歳))  
阪神 ゴメス(1984年9月7日 (30歳))  

【パ・リーグ】  
日ハム 中田(1989年4月22日 (26歳))  
西武 中村(1983年8月15日 (31歳))  
ソフトバンク 内川(1982年8月4日 (32歳))  
ロッテ　デスバイネ(1986年6月17日 (28歳))  
楽天 松井稼(1975年10月23日 (39歳))  
オリックス T-岡田(1988年2月9日 (27歳))  

※ 4番が複数いるときは僕の好みで選んでます。

両リーグ断トツで、筒香が最年少ですね。
しかも、キャプテン。横浜は完全復活しそうですね。

読売に関しては坂本1988年12月14日 (26歳)よりは、大田の方が4番っぽいのでいいと思います。個人的には好きです。
こう見ると読売も若返りに成功しているのがわかりますね。
そしてしっかりと、ベテラン陣でバックアップできるように戦力補強。。
いやぁ憎いですね。笑

中日は同い年だし、平田(1988年3月23日 (27歳))が4番に定着して欲しいかなぁ。

ゴメスは意外と若かったの知りませんでした。
読売と違って若手の層がやはり薄いのでしょうかねぇ。
いやぁ、タイガースは最下位ですが、昨年後半のような巻き返しに期待したいです。

...

>> Continue Reading

10年つかえるSEOの基本 を読みました。
僕のようなSEOを専門にしていないIT業界の方々に、是非読んで貰いたい本です。

長年、この業界に居ながらSEOに対して懐疑的な見方をしていました。
ただ、Retty在籍していたとき、現Kaumoの太田くんのSEOに対する考え方を聴き、僕のSEOに対する考え方が変わりました。
その後の太田くんの活躍は皆の業界の知るところです。

人とモノとのミスマッチをなくすーーSEOおたくが生んだ「カウモ」で変わるモノとの出会い - THE BRIDGE（ザ・ブリッジ）
http://thebridge.jp/2015/02/kaumo

この本は平易な文章で、挿絵をふんだんに使っています。
副題にもあるように、「トレンドを追うよりも変らない考え方を抑えるためのテクニック」がしっかりと書いてあります。

ユーザに対して何を伝えるか、考え抜くことが大事だということを実感しました。
...

>> Continue Reading