最近はVSCodeなどのIDEが開発に使う言語に問わずハイスピードで普及して、フロントエンドエンジニアでもバックエンドエンジニアでもコマンドを叩くことが少なくなってきたように思います。
若干老害トーク感がありますが、僕が新卒の頃は必ずサーバーにログインして何らかの作業を誰もが当たり前のようにやっていました。

それでも、少なくなったとはいえ、全くコマンドを叩かずに済むエンジニアはいないでしょう。まだ今日のGUIやその他のインターフェースは、CLI(Command line interface)より優れた部分はあれど、全てが優れているわけではありません。

CIやDocker、wikiではまだまだ現役のコマンド達

多くのCIはshellをサポートしていますし、Dockerでもやはりコマンドを使うことがあります。また、コマンドはコピペして簡単に再現できるので、まだwikiや手順書にこの順番でコマンドを実行してくださいと書かれることも多いでしょう。

意味がわからないコマンドに出会ったら？

wikiの中にわからないコマンドがあり、意味を知りたい場合はどうしましょう？
例えば $ ls -ltr の意味がわからなかったとしましょう。 $ ls の意味はわかっても、オプションの意味がわからない場合、あなたはどうしますか？
ls -ltr とGoogleで検索すればある適切な結果が表示されるかもしれません。しかし、2020年現在全てのコマンドラインオプションで検索しても、なかなか Gooleは適切な答えを表示してくれません。とくに短いコマンドラインオプションについてはかなり不正確です。

manコマンドを使ってみましょう

man ls としてみましょう。...

railsでテストコードを少なくする技術 - TDD on railsの間合い - Qiita

以前、上記のような記事を書きました。

「Model SpecやRequest Spec/Feature Spec(今ならSystem Spec)を中心に書いて、実装速度を上げていこう」という話でした。

その後、Ruby on Railsのコードを読み書きする中で、自分自信の考えが少し変化しました。ここで一度新しい僕のRuby on Railsでのテストとの向き合い方をまとめたくなりました。

いろいろと変化している部分があり長くなるので、今回はModel SpecのValidationの書き方を以前のコードと比べつつ見ていきましょう。

以前の記事に書いてあるModel Specのコード

前述の記事のvalidationのテスト という項目のコードです。(一部改変しています)

describe Post, type: :model do
  describe '#validate' do
    subject { Post.new params }
    context '全てのデータが正しいとき' do
      let(:params) { body: "iiyon" }
      it { is_expected.to be_valid }
    end
    context '正しくない場合' do...

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ベストプラクティス・パターン―シンプル・デザインへの宝石集
• リファクタリング 既存のコードを安全に改善する...

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 # 次へのリンクを探してからクリックする

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

$ 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を実行させるようなことも簡単にできます。...

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の項目に貼ったりしますので、この辺りも便利です。
...

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

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

...

はい。 #しがないラジオ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枚。
緊張と早口で大阪弁全開でまくしたて立ったぜ。
...

流しの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...

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

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

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

記事で印象に残ったこと

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

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

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

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

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

私の場合はomnifocusを整理する必要がある。...

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

何がいいって、書けば書くほど集中できます。...

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

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

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

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

権限の壁

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

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

組織の壁

...

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対応で色々と対応工数が増えてしまうと恐れている方もいらっしゃると思いますが、...

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...

このテーマ。僕はずっとずっと悩んで来た問題です。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にして、...

テストコードで再現テストをしてから、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

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

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

ブログ移管した

ブログを 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)

この辺りのツールはスマホからも修正がかなり簡単で圧倒的に使いやすいのです。...

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

geocitiesからxreaの移行

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

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

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

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

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

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

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

xreaにサイトを移管してから、配布されてるCGIスクリプトをサーバーで動かしました。...

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

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

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

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

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

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

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

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

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

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

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

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

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も充実しているように見えたのと、コード自体の見通しもよかったです。

その他検討したもの

...

毎年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っておもしろいのだろうか。
...

ワーキングメモリとは

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

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

今自分が考えていること

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

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

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

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

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

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

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

参考リンク

...

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...

とある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

...

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

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

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

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

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

ざっくりした本の内容

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

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

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

...