ニクニクドットミー

カッコいいおっさんを目指すエンジニアの厳かなブログ

GOTRACEBACKのメモ

182b65b9 539c 4d24 9b1f ee4a1a8756f1

GOTRACEBACKという環境変数があり、それを設定することによって、go runしたときのプログラムのトレースバックが変わるようです。

The GOTRACEBACK variable controls the amount of output generated when a Go program fails due to an unrecovered panic or an unexpected runtime condition. By default, a failure prints a stack trace for every extant goroutine, eliding functions internal to the run-time system, and then exits with exit code 2. If GOTRACEBACK=0, the per-goroutine stack traces are omitted entirely. If GOTRACEBACK=1, the default behavior is used. If GOTRACEBACK=2, the per-goroutine stack traces include run-time functions. If GOTRACEBACK=crash, the per-goroutine stack traces include run-time functions, and if possible the program crashes in an operating-specific manner instead of exiting. For example, on Unix systems, the program raises SIGABRT to trigger a core dump.

Google先生で翻訳したところ、

GOTRACEBACK = 0は、単位のゴルーチンスタックトレースが完全に省略している場合は終了コード2で終了します。

GOTRACEBACK = 1の場合、デフォルトの動作が使用されます。

GOTRACEBACK = 2場合は、単位のゴルーチンスタックトレースは、実行時の機能が含まれます。

以下のサンプルコードで試してみました。


package main


import (
        "log"
        "runtime"
)

func main(){
        log.Println(runtime.NumGoroutine()) //動いているゴルーチンの数
        select{}
}

GOTRACEBACK=0


[root@localhost vagrant]# GOTRACEBACK=0 go run sample.go
2015/02/12 13:39:00 4
fatal error: all goroutines are asleep - deadlock!
exit status 2

終了ステータスコードとエラーメッセージが出力されます。

GOTRACEBACK=1


[root@localhost vagrant]# GOTRACEBACK=1 go run sample.go
2015/02/12 13:40:02 4
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [select (no cases)]:
main.main()
    /vagrant/sample.go:11 +0xd5
exit status 2

終了ステータスコードとどの行でエラーになったか出力されます。

GOTRACEBACK=2


[root@localhost vagrant]# GOTRACEBACK=2 go run sample.go
2015/02/12 13:40:17 4
fatal error: all goroutines are asleep - deadlock!

runtime stack:
runtime.throw(0x54f7e3)
    /usr/local/go/src/runtime/panic.go:491 +0xad fp=0x7fff416d3b58 sp=0x7fff416d3b28
checkdead()
    /usr/local/go/src/runtime/proc.c:2854 +0x1f8 fp=0x7fff416d3ba8 sp=0x7fff416d3b58
mput(0x551e40)
    /usr/local/go/src/runtime/proc.c:3175 +0x47 fp=0x7fff416d3bb0 sp=0x7fff416d3ba8
stopm()
    /usr/local/go/src/runtime/proc.c:1176 +0xea fp=0x7fff416d3bd0 sp=0x7fff416d3bb0
findrunnable(0xc208012000)
    /usr/local/go/src/runtime/proc.c:1487 +0x562 fp=0x7fff416d3c08 sp=0x7fff416d3bd0
schedule()
    /usr/local/go/src/runtime/proc.c:1575 +0x151 fp=0x7fff416d3c38 sp=0x7fff416d3c08
runtime.park_m(0xc2080006c0)
    /usr/local/go/src/runtime/proc.c:1654 +0x113 fp=0x7fff416d3c60 sp=0x7fff416d3c38
runtime.mcall(0x42d204)
    /usr/local/go/src/runtime/asm_amd64.s:186 +0x5a fp=0x7fff416d3c70 sp=0x7fff416d3c60

goroutine 1 [select (no cases)]:
runtime.gopark(0x0, 0x0, 0x4ef830, 0x11)
    /usr/local/go/src/runtime/proc.go:130 +0x105 fp=0xc20802df08 sp=0xc20802ded8
runtime.block()
    /usr/local/go/src/runtime/select.go:176 +0x46 fp=0xc20802df30 sp=0xc20802df08
main.main()
    /vagrant/sample.go:11 +0xd5 fp=0xc20802df98 sp=0xc20802df30
runtime.main()
    /usr/local/go/src/runtime/proc.go:63 +0xf3 fp=0xc20802dfe0 sp=0xc20802df98
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20802dfe8 sp=0xc20802dfe0

goroutine 2 [force gc (idle)]:
runtime.gopark(0x42edb0, 0x5516e0, 0x4e49d0, 0xf)
    /usr/local/go/src/runtime/proc.go:130 +0x105 fp=0xc20801a798 sp=0xc20801a768
runtime.goparkunlock(0x5516e0, 0x4e49d0, 0xf)
    /usr/local/go/src/runtime/proc.go:136 +0x48 fp=0xc20801a7c0 sp=0xc20801a798
runtime.forcegchelper()
    /usr/local/go/src/runtime/proc.go:99 +0xce fp=0xc20801a7e0 sp=0xc20801a7c0
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20801a7e8 sp=0xc20801a7e0
created by runtime.init·4
    /usr/local/go/src/runtime/proc.go:87 +0x25

goroutine 3 [GC sweep wait]:
runtime.gopark(0x42edb0, 0x558978, 0x4e21f0, 0xd)
    /usr/local/go/src/runtime/proc.go:130 +0x105 fp=0xc20801df98 sp=0xc20801df68
runtime.goparkunlock(0x558978, 0x4e21f0, 0xd)
    /usr/local/go/src/runtime/proc.go:136 +0x48 fp=0xc20801dfc0 sp=0xc20801df98
runtime.bgsweep()
    /usr/local/go/src/runtime/mgc0.go:98 +0xbc fp=0xc20801dfe0 sp=0xc20801dfc0
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20801dfe8 sp=0xc20801dfe0
created by gc
    /usr/local/go/src/runtime/mgc0.c:1383

goroutine 4 [finalizer wait]:
runtime.gopark(0x42edb0, 0x558970, 0x4e4550, 0xe)
    /usr/local/go/src/runtime/proc.go:130 +0x105 fp=0xc208019730 sp=0xc208019700
runtime.goparkunlock(0x558970, 0x4e4550, 0xe)
    /usr/local/go/src/runtime/proc.go:136 +0x48 fp=0xc208019758 sp=0xc208019730
runtime.runfinq()
    /usr/local/go/src/runtime/malloc.go:727 +0xba fp=0xc2080197e0 sp=0xc208019758
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc2080197e8 sp=0xc2080197e0
created by runtime.createfing
    /usr/local/go/src/runtime/malloc.go:707 +0x5e
exit status 2

長いです。終了ステータスコードと他に動いてるゴルーチンが出力されます。

こう思った

GOTRACEBACK=2で他のゴルーチンがわかるのは便利かも。 なぜall goroutines are asleep - deadlock!となるのかは謎。。。

GoをCentOS-6.5に入れてみた!

182b65b9 539c 4d24 9b1f ee4a1a8756f1 Goで生きていくと決めて数時間経ちました。皆さんいかがお過ごしでしょうか。

つい先日行われたdotssummit 2015でたくさんのスタートアップ企業がプレゼンを行いました。

多くのスタートアップが、Goへ舵を切り始めているのが印象的でした。

  1. パフォーマンスがいい
  2. 単一バイナリなので管理が楽
  3. 並立処理が簡単

gunosyではappサーバはGoで動いていて、ピーク時のレスポンスタイムは30msだそうです。はやい。

メルカリは部分的にGoを使っていて、発表者の久保さん@cubicdaiyaのGo使いぶりが凄まじく、「めっちゃかっこいいな」と思い、Goで生きて行こうと決めたのでした。なので、数時間というか2日くらい経ってます。

Go自体はMacに入れていたのですが、昨日Vagrant Cloudを試していて作ったCentOS-6.5の環境があるので、そちらに改めて入れてみました。

Goのダウンロード


cd /usr/local/src

wget --no-check-certificate https://storage.googleapis.com/golang/go1.4.1.linux-amd64.tar.gz

tar zxvf go1.4.1.linux-amd64.tar.gz

でGoがダウンロード出来ましたので、PATHが通っている所に設置します。 シンボリックリンクを張ってみました。


ln -s /usr/local/src/go/bin/go /usr/bin/go

GOPATH,GOROOTを設定

.bash_profileに以下を書きます。


export GOROOT=/usr/local/src/go
export GOPATH=$HOME/go/bin
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT
export PATH=$PATH:$GOPATH
export PATH=$PATH:$GOPATH/bin

※追記 GOPATHの指定が誤っていました。binまで付けてしまうとgo getした際に/bin/bin/とbin以下にさらにbinディレクトリを作ってしまう為、PATHが通らなくなってしまいます。 GOROOTはGoを設置してるディレクトリを指定します。 GOPATHはgo getしたときに格納されるディレクトリになります。

ちなみにGOPATHを設定しないまま、go getすると怒られます。

package github.com/cubicdaiya/nginx-build: cannot download, $GOPATH not set. For more details see: go help gopath

GOPATHについて詳しく説明してくれている記事がありましたので、引用。

GOPATH には2つ役割があります。 ビルド時のインポートパスとして、GOPATH に指定したすべてのディレクトリを参照する(コロン区切り) go get コマンドで外部パッケージを読み込んだ時、 GOPATH の先頭のディレクトリにダウンロードする そして、公式ドキュメントにもありますが、Goで自分のプロジェクトを書く時にも、このGOPATHの下で書くのが良いとされています。 例えば、自分が githubソースコードを管理していて、ユーザー名が foo、リポジトリが bar だったら $GOPATH/src/github.com/foo/bar というディレクトリを作ってそこで作業します。

ここまでくればGoは動くはずです。


$ go version
go version go1.4.1 linux/amd64

go getしてみる

せっかくなので、go getしてモジュールを手に入れましょう。 dotssummitで衝撃だった@cubicdaiyaさんのnginx-buildを入れてみます。 nginx-buildでnginxをビルドしよう


go get -u github.com/cubicdaiya/nginx-build

mkdir -p ~/opt/nginx
nginx-build -d ~/opt/nginx
cd ~/opt/nginx/1.7.9/nginx-1.7.9
sudo make install
objs/nginx -v

無事インストールされました! ※途中make installする必要がありました。

参考

これからGoを始める人のためのTips集

こう思った

Goの時代が来てます。Goはバイナリを配るだけですぐ使えるので、インフラエンジニアにもってこいな言語です。 ポインタの概念があるので、そこはしっかり覚えないといけませんが、その分効率的なプログラムが書けると思います。 Goで生きて行けるようにがんばるゾ!

Vagrant Cloudからbox追加する

Vagrant

Vagrant Cloudというboxが集まっている?サイトがvagrant 1.5の公開と合わせて出ていたようです。

自分が気づいたのは最近のことで、ちょっと使ってみたいと思います。

Vagrant Cloudを使うにあたってユーザー登録が必要なので、済ませておきましょう。

vagrant loginを実行する


~/l/v/nginx-lab ❯❯❯ vagrant -v
Vagrant 1.7.2

versionは1.5以降であればOK!


~/l/v/nginx-lab ❯❯❯ vagrant plugin list
vagrant-share (1.1.3, system)

pluginはshareがデフォルトで入っているようです。


~/l/v/nginx-lab ❯❯❯ vagrant login
In a moment we will ask for your username and password to HashiCorp's
Atlas. After authenticating, we will store an access token locally on
disk. Your login details will be transmitted over a secure connection, and
are never stored on disk locally.

If you do not have an Atlas account, sign up at
https://atlas.hashicorp.com.

Atlas Username: maaaato
Password (will be hidden):
You are now logged in.

Vagrant Cloudに登録したユーザ情報を入力。 login成功!

vagrant cloudからbox追加


~/l/v/nginx-lab ❯❯❯ vagrant box add chef/centos-6.5
==> box: Loading metadata for box 'chef/centos-6.5'
    box: URL: https://atlas.hashicorp.com/chef/centos-6.5
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.

1) virtualbox
2) vmware_desktop

Enter your choice: 1
==> box: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox
    box: Downloading: https://vagrantcloud.com/chef/boxes/centos-6.5/versions/1.0.0/providers/virtualbox.box
==> box: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'!


~/l/v/nginx-lab ❯❯❯ vagrant box list                                                                                                                                               ⏎
chef/centos-6.5 (virtualbox, 1.0.0)

vagrantの起動

Vagrant initしていればVagrantfileがあるので、以下の様に修正。


config.vm.box = "chef/centos-6.5"


~/l/v/nginx-lab ❯❯❯ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'chef/centos-6.5'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'chef/centos-6.5' is up to date...
==> default: Setting the name of the VM: nginx-lab_default_1423404350975_49918
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if its present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => /Users/masayuki.nakano/lab/vagrant-project/nginx-lab

Checking if box 'chef/centos-6.5' is up to date...

vagrant cloud上のboxに変更があったら取り込んでくれるみたいです。


~/l/v/nginx-lab ❯❯❯ vagrant ssh
Last login: Fri Mar  7 16:57:20 2014 from 10.0.2.2
[vagrant@localhost ~]$

無事sshで接続できました!

注意点

vagrant 1.5からbox追加の仕様が変わりました。


vagrant box add <box-name> <url>
vagrant box add centos-6.5 chef/centos-6.5


vagrant box add <box-name>
vagrant box add --name sl6-64 http://lyte.id.au/vagrant/sl6-64-lyte.box

参考

vagrantのboxをvagrant cloudからもらってくる

こう思った

Vagrant Cloudでbox追加が楽になったと感じました。 一方でユーザ登録はちょっとめんどいなと感じますが、vagrant cloud上にあるboxの信頼性が上がったのかなと思います。 (変なboxが上がっていないという意味で)

apache preforkパラメータについてのメモ

Apache log

前回、apacheのMaxRequestsPerChildを検証してみたというタイトルで、MaxRequestsPerChildを軽く試してみました。

他にもいくつかパラメータがありましたので、それらの意味をメモっておきます。


<IfModule prefork.c>
StartServers       5
MinSpareServers    5
MaxSpareServers    5
ServerLimit        5
MaxClients         5
MaxRequestsPerChild  5
</IfModule>



パラメータ 説明 補足
StartServers 起動時に生成される子サーバプロセスの数 StartServers ディレクティブは、 起動時に生成される子サーバプロセスの数を設定します。 プロセス数は負荷に応じて動的に制御されますので、 通常はこの値を調整する理由はあまりないでしょう。
MinSpareServers 待機時の最小子プロセス数 子プロセスがMinSpareServersより少なくなったら、この値まで子プロセスを上げます
MaxSpareServers 待機時の最大子プロセス数 子プロセスがMaxSpareServersより大きくなったら、この値まで子プロセスを下げます
ServerLimit 設定可能なサーバプロセス数の上限 MaxClientsを256以上に設定したい場合はServerLimitも設定する必要があります。また、 MaxClientsの上に書かないと効きません
prefork MPM の場合は、このディレクティブは Apache プロセス稼働中における MaxClients に設定可能な上限値を設定することになります
MaxClients リクエストに応答するために作成される 子プロセスの最大個数 MaxClients ディレクティブは、 応答することのできる同時リクエスト数を設定します。 MaxClients 制限数を越えるコネクションは通常、 ListenBacklog ディレクティブで設定した数までキューに入ります。 他のリクエストの最後まで達して子プロセスが空くと、 次のコネクションに応答します。
スレッドを用いないサーバ (すなわち prefork) では、MaxClients は、リクエストに応答するために起動される 子プロセスの最大数となります。 デフォルト値は 256 で、これを増加させたい場合は、 ServerLimit の値も増加させる必要があります

※いまの設定値はダミーで設定してます。 またこれらのパラメータの値は揃えた方がいいです。 理由は、forkは重い処理なので、出来るだけforkさせない為です。 とても分かりやすく説明してくれている記事がありましたので、記載しておきます。 プロのサーバ管理者がApacheのStartServers, (Min|Max)SpareServers, MaxClientsを同じにする理由

こう思った

前回はMaxRequestsPerChildを調べましたが、他にもたくさんあったので、調べてみました。 基本はすべての値(RequestsPerChild以外)は揃えるのがベターのようです。 WEBサービスボトルネックなるのはDBが多いと思うので、apacheのチューニングはあまり無いような気がしてます。 でもチューニングできるとカッコイイと思うので、する機会あればしてみたいと思います。

参考 ・httpd.confについて調べたのでまとめたよ

apacheのMaxRequestsPerChildを検証してみた

Apache logapacheの設定をちゃんとわかっていないので、configをいじってみたいと思います。

今回はMaxRequestsPerChildです。

この設定は個々の子サーバが稼働中に扱うリクエスト数の上限を決めるもので、子プロセスが捌くリクエスト数を指します。

MaxRequestsPerChild ディレクティブは、 個々の子サーバプロセスが扱うことのできるリクエストの制限数を 設定します。MaxRequestsPerChild 個のリクエストの後に、子プロセスは終了します。 MaxRequestsPerChild が 0 に設定されている場合は、プロセスは期限切れにより終了することはありません。

今回検証する環境はこんな感じです。 ・Apache/2.2.15 (Unix) ・CentOS release 6.5 (Final)

configはこんな感じ。


<IfModule prefork.c>
StartServers       1
MinSpareServers    1
MaxSpareServers    5
ServerLimit        1
MaxClients         1
MaxRequestsPerChild  5
</IfModule>

MPMはpreforkとなっています。

MaxRequestsPerChildは子プロセスが設定されている数だけリクエストを捌いたら終了するので、このconfigでは5回リクエストを捌くと終了するはずです。

一度この状態で

ps aux | grep -v grep | httpd
するとこの様になりました。


[vagrant@localhost ~]$ ps aux | grep -v grep | grep httpd
root      1328  0.0  0.8 183648  4072 ?        Ss   14:47   0:00 /usr/sbin/httpd
apache    6147  0.0  1.1 185308  5292 ?        S    15:15   0:00 /usr/sbin/httpd

この状態で、

curl http://localhost/
を叩いて5回リクエストを送ってみます。 その後プロセスを確認すると、


[vagrant@localhost ~]$ ps aux | grep -v grep | grep httpd
root      1328  0.0  0.8 183648  4072 ?        Ss   14:47   0:00 /usr/sbin/httpd
apache    6169  0.0  1.1 185308  5292 ?        S    15:17   0:00 /usr/sbin/httpd

最初確認した時とプロセスIDが変わっているのがわかりました。子プロセスがMaxRequestsPerChildの数(今回は5)だけ捌いたので、終了して別の子プロセスが立ち上がったことがわかりました。 MaxRequestsPerChildを設定するメリットは以下の通りです。

MaxRequestsPerChild を非ゼロに制限することには、二つの利点があります: (偶発的な) メモリーリークが起こった場合に プロセスが消費するメモリの総量を制限できる プロセスに有限のライフタイムを設定することで、 サーバ負荷が下がった時にプロセス数を少なくすることができる

こう思った

子プロセスがリクエストを捌いて仕事したら、帰っていいよという事です。子プロセスが長く生き続けると太り始めてメモリリークの原因になってしまいます。 MaxRequestsPerChildの数が多いと子プロセスが長く生きてしまうので、設定する数は気をつけた方がいいと思います。短すぎると子プロセスが立ち上がるまで時間が掛かる?と思うので、その間はリクエストが受け付けられなくなってしまうのではないかと思います。

ちょこちょこapacheのconfigの検証をしていきたいと思います。

2015年はゆる〜い目標を立てるぐらいがちょうどいいかと思う件

123H

あけましておめでとうございます。今年もよろしくお願いします。

だいぶ遅い挨拶になりましたが、皆さんいかがお過ごしでしょうか。

昨年の年末は一昨年と比べて、31日に出勤するという事がなくのんびりと新年を迎えれそうでしたが、、、 29日,30日と風邪で熱が出てしまい、おもいっきり寝込んでしまうというアクシデントに見舞われました。

自分は喉の調子が悪いとすぐに体調崩してしまうので、ちょっとでも異変を感じたらイソジンを飲み干したいと思います。

さて、昨年に引き続き今年も目標を立てようかと思うのですが、今年はゆる〜く立てようと思います。

なぜ?

しっかり立てても達成できないからです。

残念ながら昨年に立てた、応用情報技術者試験合格と年50本のブログ更新は未達となりました。。。

応用情報技術者試験に限っては一応受けに行ったのですが、一切勉強していなかったので途中で諦めてしまいました。

ブログはちょこちょこ更新していましたが、30本という結果になり20本も足りていないという状態。

活躍されているブロガーさんだと月に50本くらい余裕で更新してしまうので、そもそも目標の数値自体かなり低レベルな目標だったと気づきました。 (それすら達成できないなんて^^;)

そもそも達成できなかった理由は、

  1. スケジュールを立てなかった
  2. 自分の力量をわかってなかった

などがあるかと思います。 スケジュールを立てなかったというのは、まさに資格取得への道筋が一切ない状態でした。この期間はこの分野を勉強する!など無かったので、ダラダラとたまに参考書を見たりするぐらいでした。

つぎに自分の力量がわかってなかったというのは、ブログ更新に関わるのですが、今までの自分のブログ更新数を把握せず、なんとなく時間もあるし、月に4~5本書けばなんとかなるか!と思っていました。 ブログのネタもそんなにポコポコ出てこないので、月に4~5本の更新はかなり厳しいものでした。

という感じなので、~~に合格する!とか○○本ブログ更新する!という具体的なものではなく、すごくアバウトな目標を立ててみようかと思います。

アバウトにする理由

自分が決めたことをちょっとでもいいから達成して、自信を付ける為です。

自分で言い出した目標設定でしたが、こうも達成できないとさすがに振り返ってみてショックです。自分はダメな奴だな〜と。

なので、~~をする!とかアバウトに考えてみようと思います。

目標1 ブログを書く

昨年からちょっとずつ書くようになったブログですが、たまに読んでくれる人がいて、「読みましたよ!頑張ってください!」とか言ってもらえる時があります。

技術的なブログを書いた時には「あの記事役に立つ人いるんじゃない?」とかお褒めの言葉を頂いたりして、ブログを書くのが楽しいと思えるようになりました。

書く内容は大したことではありませんが、読んでくれている人がいるのはとても嬉しいですし、アウトプットは大事なので、続けます。

今回は○○本記事を書く!ではなく、ただ好きなタイミングで好きな内容を楽しいと感じながら更新して行こうと思います。

目標2 会社を毎日1%ずつ良くする

かなり格好を付けた目標ですが、ライフハッカーのこの記事を読んでこの目標を決めました。 会社の急成長につながるリーダーシップ13のヒント

5. 継続的な改善 あなた自身とあなたの会社を毎日1%ずつでも良くしていきましょう。1年の終わりには生産性や売り上げが2倍になっていることでしょう。決して自己満足してはいけません。あなたのチームが競争相手より優れていたとしても、彼らは虎視眈々とあなたの座を狙っています。より成長することで顧客はあなたのパフォーマンスに魅了されるのです。

大きな成果を出すのはいまの自分のスキルや力では無理です。しかし、小さな改善活動は少しずつできるはずです。例えば仕事に役立つスクリプトを書いたり、手順書をwikiにまとめたり。

自分の手が届く範囲で、自分が出来るチーム・会社を良くなることを1%ずつ毎日取り組みたいと思います。

たぶん小さなスクリプトを書いてると思います(笑)

目標3 インプット・アウトプット

エンジニアという職業は手を動かしてナンボだと実感しました。いままでなんとなくわかっていた事が実際に手を動かしてみると全く違った動作をして、手を動かさないとわからないことが多々ありました。

そして、手を動かさずに理解をしようとしない事が悪だということもわかりました。

インプットよりアウトプットが大事なことは重々承知でしたが、しっかり手を動かしてアウトプットしようと思います。

最近だとVagrantとイチャイチャしていて、仮想環境便利だな〜と実感してます。手軽に試せるのは本当にいいですね。これで手を動かないのは悪です。

こう思った

アッ・・・バウトな目標を3つほど立ててみました。たぶん他にもこれやろう、あれやろうと出てきそうです。そろそろ体も鍛え直さないとなーとかこの記事を書きながら思いました。 肩の力を入れすぎずに、小さな達成感継続するということをしっかり行います。 ゆる〜く目標に向かって日々笑進します。

靴磨きは目に見えて綺麗になる!KIWIのクリーナーセットを買ってローファー磨きました。

KIWI 年を取るにつれて、ちょっとずつファッションの嗜好が変わってきました。

昔はウィンドブレーカーにリーバイスのサルエルにナイキターミネーターを合わせたりというなんともガキっぽい(いまもたまに着るのですが^^;)感じでしたが、

最近はシャツにセーターを合わせ、ジーパンにローファーという大人っぽい?感じを好んで着てます。

ファッション雑誌もOCEANSやLEONを読むようになりました。モデルさんかっこいいです。

ということで、よくローファーを履くようになったのですが、履く機会が増えるとやはり汚れやすくなってしまいます。ターミネーターと違って、洗剤でゴシゴシ洗うわけにもいかず、さらに革靴なので慎重に扱わねばなりません。

愛着を持って長く履きたい!と思ったので、KIWIのクリーナーセットを購入し、磨いてみました。すんごい綺麗になりますよ。KIWI-set 今回買ったのはKIWIというメーカーのクリーナーセット。中身はこんな感じで、ブラシ、中性クリーナー、油性靴クリーム、布、説明書です。

KIWIについて引用。 靴磨き・手入れ-KIWI(キィウイ)-|ジョンソン株式会社

「キィウイ」は、1906年にオーストラリアでブーツの保革剤として生まれ、その2年後に発売した「ダーク・タン」の爆発的ヒットにより、オーストラリア中に広まりました。 その後、キィウイ油性靴クリームを愛用したオーストラリア兵のピカピカの軍靴が、イギリス兵やアメリカ兵の目に留まり「キィウイ」は急速な勢いで世界への普及を果したのです。
日本においても、キィウイ油性靴クリームは、靴を大切にする人たちの間で「丸缶」の愛称で呼ばれ、革靴の本格的なお手入れに無くてはならない製品として愛用されてきました。

丸缶という愛称で呼ばれているらしいです。他にもメーカーはたくさんありますが、このパッケージのポップさに惹かれて、KIWIにしました。

靴磨きの手順

さて、KIWIのクリーナーで靴を磨いてみます。 その前にどういう手順で磨くかというと。

  1. 汚れ落とし
  2. クリーニング
  3. 靴クリーム塗布
  4. ポリッシュ(ツヤ出し)

クリーナーセットについていた説明書の通りに磨いていきます。

汚れ落とし

ブラシで汚れ落とし 靴のコバ(縫い合わせ部分)の泥やホコリをブラシで落とします。コバの汚れを落としたら、ブラシで靴表面の汚れを落とします。 コバより表面のホコリが多く見られました。

クリーニング

中性靴クリーナー 布に中性靴クリーナーをちょびっと取り、靴表面に円を描く様にのばします。その後で布で汚れを拭き取っていきます。

クリーニング 結構コバに溜まりやすいので、溜まったクリーナーも布で拭き取ります。

靴クリーム塗布

靴クリーム三色 セットには3色のクリームが付いてました。自分の靴に合わせた色を選びます。

靴クリーム 布に取るとこんな感じ。これを靴表面に小さく円を描くように塗り込んでいきます。 布を巻いた指先を、油性靴クリームの表面に置くと、体温により油性靴クリームを自然に布にとることができます。 油性靴クリームの塗布のしすぎは、乾きを遅らせます。また次の磨きの段階で輝きが出にくくなります。

ポリッシュ(ツヤ出し)

仕上げに掛かります。塗りこみ、しばらく乾かした後、きれいな布で乾拭きをすると輝きが出てきます。 この時にミラーフィニッシュ(鏡面仕上げ)というテクニックがあります。 ポリッシュ 靴表面に水を2,3適散らし(少量の水を指先に巻いた布に含ませてもOK)油性靴クリームを少量取ります。その後丹念に指先で円を描くように磨き上げます。 靴表面に鋭い輝きが生まれるまでじっくりと繰り返し磨きます。

仕上がり

こちらがまだクリーナーセットを買う前の汚れていた状態 BEFORE before

そしてこちらが丹念に磨き上げた状態! AFTER after

写真では伝わりにくいかもしれませんが、ほんとうに光り輝くほどにピカピカになりました。

こう思った

以前から革靴の手入れの仕方はどうやってやるんだろ?と思っていて、ついに実行しました。 そこそこいいローファーを買っていたので、ちゃんと手入れ出来てよかったです。それにしてもこんなにピカピカになるなんて。。。驚きです。 オシャレは足元からと言いますが、自分で磨いたきれいな靴を履くと気分が楽しくなります。 靴に限らず、身の回りの物を愛着を持って使っていきたいと感じさせてくれました。靴磨き最高。ほんとうにオススメです。