CentOS6.7の設定
前回インストールしたCentOS6.7の設定を行っていきます。
SELinuxの無効化
何はともかく無効化しましょう。以下に設定変更します。
SELINUX=disabled
# [cp -a /etc/sysconfig/selinux{,.bak}
# vi /etc/sysconfig/selinux
# shutdown -r now
SELinuxが無効化された事を確認します
# getenforce Disabled
開発ツール、Baseパッケージのインストール
# yum groupinstall base # yum groupinstall development tools
監視ユーザ追加
# useradd hogehoge # passwd hogehoge ユーザー hogehoge のパスワードを変更。 新しいパスワード: 新しいパスワードを再入力してください: passwd: 全ての認証トークンが正しく更新できました。
作成したユーザに管理者権限付与
/etc/sudoersに以下の内容を記載
hogehoge ALL=(ALL) ALL
# cp -a /etc/sudoers{,.bak}
# visudo
# cat /etc/sudoers |grep hogehoge
hogehoge ALL=(ALL) ALL
$ sudo whoami
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for hogehoge:
root
root権限が付与された事を確認。
rootユーザリモートログイン不可設定
rootでssh接続は禁止して、作成したユーザでssh接続するようにしましょう。
PermitRootLogin no
# cp -a /etc/ssh/sshd_config{,.bak}
# vi /etc/ssh/sshd_config
# service sshd restart
# service sshd restart
sshd を停止中: [ OK ]
sshd を起動中: [ OK ]
# cat /etc/ssh/sshd_config | grep PermitRootLogin
#PermitRootLogin yes
PermitRootLogin no
PermitRootLogin noが追加されていることを確認。サービスも正常に起動しています。
リモートログインの確認
rootユーザでのログイン不可の確認します。
# ssh root@xxx.xxx.xxx.xxx The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established. RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'xxx.xxx.xxx.xxx' (RSA) to the list of known hosts. root@xxx.xxx.xxx.xxx's password: Permission denied, please try again.
Permission deniedで権限が拒否された事を確認
一般ユーザでのログイン確認
# ssh hogehoge@xxx.xxx.xxx.xxx hogehoge@xxx.xxx.xxx.xxx's password $
一般ユーザが管理者権限になることを確認
$ sudo su - [sudo] password for hogehoge: #
プロンプトが管理者権限になったので管理者権限になることに成功
プロンプトが一般ユーザになったのでログイン成功
Quizここで#や$になったりしているのはなぜでしょうか。調べてコメント欄に書いてみてください。
カーネルパニック設定
「/etc/sysctl.conf」はカーネルパラメータを記述する設定ファイルです。 ここにパニックリブートの設定を追加
# cp -a /etc/sysctl.conf{,.bak}
# echo >> /etc/sysctl.conf
# echo kernel.panic = 30 >> /etc/sysctl.conf
# cat /etc/sysctl.conf |grep kernel.panic
kernel.panic = 30 //パニック後30秒後に再起動
yum設定
参考サイト : Yumの構成 : yumが遅い場合にダウンロードを速くするyum-fastestmirror : CentOSでyumのリポジトリを国内指定したりほか
1.yumのプラグインをインストールしてダウンロードの速いミラーサイトを自動で選択するように設定
yum -y install yum-fastestmirror
2.「mirrorlist=」の末尾に「&cc=JP」を追記し、国コード別のミラーリストを返すように設定
# cp -a /etc/yum.repos.d/CentOS-Base.repo{,.bak}
# vi /etc/yum.repos.d/CentOS-Base.repo
# cat /etc/yum.repos.d/CentOS-Base.repo |grep mirrorlist=
# If the mirrorlist= does not work for you, as a fall back you can try the
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib&infra=$infra&cc=JP
3.「yum -y update」ですべてのパッケージを、それらが依存するパッケージとともに更新
# yum -y update
4.更新がないことを確認
# yum check-update 読み込んだプラグイン:fastestmirror, security Loading mirror speeds from cached hostfile * base: ftp.tsukuba.wide.ad.jp * extras: ftp.tsukuba.wide.ad.jp * updates: ftp.tsukuba.wide.ad.jp
5.yumおよび関連ユーティリティの設定ファイルである「/etc/yum.conf」でpluginsが1に設定されていて、yumの機能を拡張するプラグインが有効である事を確認
# cat /etc/yum.conf |grep plugins=1 plugins=1
6.mirrorlistの設定が正しくされているか確認
# cat /etc/yum.repos.d/CentOS-Base.repo | grep mirrorlist=http:// mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra&cc=JP mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra&cc=JP mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra&cc=JP mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra&cc=JP mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib&infra=$infra&cc=JP
自動起動設定
1.以下のサービスを自動起しない用設定
# chkconfig --level 2345 mdmonitor off # chkconfig --level 2345 atd off # chkconfig --level 2345 smartd off # chkconfig --level 2345 haldaemon off # chkconfig --level 2345 restorecond off
| サービス名 | サービス内容 |
|---|---|
| mdmonitor | ソフトウェアRAIDをモニターするサービスなのでソフトウェアRAIDを使用していないので無効 |
| atd | 単発的にスケジュール化した コマンド を実行させるデーモン。指定時間にコマンド実行を行える，atコマンドを使用したい場合に利用 |
| smartd | ハードディスクの内蔵の自己診断機能(S.M.A.R.T.)を利用し、異常が発生したときにレポートするデーモン。RAIDを使わないので無効 |
| haldaemon | システム上のハードウェアに関していくつかのソースから情報を集めたり管理したりするデーモン。デスクトップ環境ではないので無効 |
| restorecond | SELinuxと連動して、ファイルの作成などを監視して適当なラベルを付与するがSELinuxは無効なので、こちらも無効化 |
参考サイト : 不要なサービスは停止～ソフトウェアRAIDモニター（mdmonitor） : 不要なサービスは停止～HALデーモン（haldaemon) : 不要なデーモンを停止させる (CentOS 6.5) : 不要なデーモンを停止しましょう
2.設定変更したlevel設定の確認
# chkconfig --list |sort -s
offにしたサービスが起動していないことを確認
CentOS6.7のインストール
CentOS6.7をインストールしたのでメモ代わりに手順を共有します。
- CentOSのisoダウンロードやvirtualbox環境は省略します。
参考サイト : CentOS6.4をISOを書き込んだDVDからインストール
1.「Wellcome to CentOS 6.7!」のメッセージ画面
「Install or upgrade an existing system」を選択
2.「Disk Found」の画面
「Skip」を選択しCDチェックを行わない
3.「Cent OS6」の画面
「Next」を選択
4.言語の選択
「Japanese(日本語)」を選択し、「Next」を選択し次の設定へ
5.キーボードの設定画面
「日本語」を選択し「次(N)」で次の設定へ進む
6.「どちらのタイプのストレージデバイスにインストールしますか？」
「基本ストレージデバイス」のラジオボタンを選択し。「次(N)」を選択
7.「現在お使いのシステム上には既存のシステムがインストールされています。どのようになさいますか？」
「新規インストール」のラジオボタンを選択し「次(N)」を選択
8.ホスト名
「localhost」に設定
9.ネットワークの設定
「ネットワークの設定」を選択 「System eth0」を編集
「自動接続する(A)」にチェックする
※ローカルIPアドレスを割り当てたい場合は以下の設定も行いましょう。 方式を「DHCP」から「手動」に変更 「IPv6のセッティング」タブに移動し、無効化されていることを確認 「適用」を選択し設定を反映させる。 「ネットワーク接続」のウィンドウを「閉じる」で閉じ、「次(N)」を選択
「次(N)」を選択
10.タイムゾーンの選択
「アジア/東京」で変更なし Rootパスワードを設定
8文字のものを設定
11.どのタイプをインストールをしますか？
物理ボリュームの場合
中段にあるボックスから「カスタムレイアウトを作成します。」を選択 既存のパーティションを全て削除
「作成」を選択し、以下のパーティションを追加し、「次(N)」を選択
| マウントポイント サイズ(MB) | 基本パーティションにする | ファイルシステムタイプ |
|---|---|---|
| /boot 250 | チェック | ext4 |
| <適用外> 2048 | チェック | swap |
| / 150328 (残り全て) | チェック | ext4 |
「ストレージ厚生をディスクに書き込む中」というウィンドウが出るので、「変更をディスクに書き込む」を選択
論理ボリュームの場合
カスタムレイアウトを作成するを選択する。 パーティションの設定は以下の通りとする。 「swap」領域を「2048MB」割り当てる。 「/boot」領域を「250MB」割り当てる。またファイルタイムを「ext4」とする。 上記のパーティションの設定完了LVM物理ボリュームを作成する。設定は以下の通りである。 ファイルサイズ:physical volume サイズ:5892MB 最大許容量まで使用:チェックを入れる LVM物理ボリューム作成後、次にLVMボリュームグループを作成する。設定は以下の通りである。 ボリュームグループ名:VoGroup00 物理エクステント:4MB マウントポイント: / ファイルシステムタイプ:ext4 論理ボリューム:LogVol00 サイズ:5892MB
12.ブートローダの設定
デフォルト設定で「次(N)」を選択
CentOSのインストール完了
【報告】YAPC::Asiaの感想【8/21&8/22】
【Blogを書くまでがYAPC】
去年と数えて今回が二回目のYAPCでした。このblogもYAPCの感想を書く為、専用となってしまっています。
昨日は以下のショックでblogを書く元気が無くなってしまいました。
YAPCパーカーのサイズ感を完全に誤って早速秋用のパジャマに成り下がった。XL異常なデカさ。
— トトス (@oza_shu) 2015, 8月 21
しかし、今回でYAPC最後ということなので、気を取り直してblogを書かないわけにはいけません。それでは8/21&8/22の感想を書いていこうと思います。
・8/21
【参加したセッション】
メリークリスマス！
世界展開する大規模ウェブサービスのデプロイを支える技術
Conway's Law of Distributed Work
Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN
Lightning Talks Day 1
【セッションの感想】
・メリークリスマス！
まずはPerlの父Larry Wallのメリークリスマス！から。「メリークリスマス！」って何のこっちゃと思ったら、ついに噂のPerl6が今年のクリスマスにリリースされるとのことが発表されました！( ※ただし約束はしていない。)
そしてLarryのPerlとトールキンの作品との関係性。Perl5である「ホビットの冒険」からPerl6である「指輪物語」は書かれるまで、何年も待たなければいけなかった。そして、それはホビット(Perl)が成長していく物語なんだ。と知性あふれるLarryの語りと、それを同時通訳をこなせているプロの凄さからニヤニヤが止まりませんでした。観ててよかった「ロード・オブ・ザ・リング」。物語性あるプログラミング言語はなんて素敵なんだ。「PerlはUnixのtoolになり見えない存在になることで革命的になった。 」このUnixと共に成長していった感じも好き。革命的なものは革命的とみないものなんだ。あとは「人間の価値は何を得られるかでなく何を与えられるか」というgiveの精神。これがOSSの精神なんだろうなあ。「I fail good」正しく失敗できるようになりたいです。
最初がLarryWallのセッションだったからか、Larryより同時通訳者の方が話題になり、誰も質問しないなんて展開になってしまったのかな。とLarryには申し訳ない気持ちにはなった。
・世界展開する大規模ウェブサービスのデプロイを支える技術
consul とstrecherめっちゃ早いって話だった気がします。
成果物をプルリクするよりS3に管理することで早いとのこと。デプロイ話はピンと来なかったなあ。cap2&gitより早くて、autoscaleと連携しマルチリージョンできるらしい。ココらへんは用語も知らないこと多かったので、ググッて調べとこ。Jenkins先生のテストは大事っぽい。YAMLは何の文脈で出てきたっけなあ。
##ブレイクタイム##
お弁当の支給ありがとうございました。美味しかったです！
・TBD
お昼のお弁当をさっさと食べ、Matsのセッションだったから一番前ので席を確保。
おじさんが座ってたから2つぐらい席を離して座りました。するとスタッフの方が話しかけててMatsだった。
隣にMats様が座っていた #yapcais
— トトス (@oza_shu) 2015, 8月 21
今日からRubyやるわ。
— トトス (@oza_shu) 2015, 8月 21
※ Ruby始めます。
「今日はRubyの話は封印します。」では何の話をするか、「不揮発性のメインメモ」の話をします。でも実際スライド作ったら15分しか持たないから不揮発性のメインメモリがもしもできたら、言語設計者としてどのような言語を設計するかっていう話は飲み会とかで」と追っしゃてました。いつか聞きたいです。笑
それでは「Rubyの封印を早速解きます。Rubyの悪口を言っても問題ないのは問題ないから」と初めてMatsをみたけど面白い方だった。
Rubyの設計はPerlやLispの影響を受けているから、もしいまRubyを設計をしたら取り入れなかった機能の話をしてくれた。こういう話を聞くと、プログラミング言語の説明で、OOの言語の影響を受けているって話はこういうことだったんだと納得出来ました。新しくプログラミング言語を作った言語設計者も意識したプログラミング言語があるんだ。そして今新しく作っているプログラミング言語のデモをしてくれた。シェルスクリプトが今見直されている。その理由がパイプ処理でCPUのマルチコアを正しく使うから、っていう話は面白かった。ハードウェアの進化に伴い、プログラミング言語の使われ方も変わるのだろう。それを踏まえた新しいプログラミング言語「Streem」については今後チェックしておこう。
・Conway's Law of Distributed Work
Remote! リモートワークの話でした。今はインフラエンジニアをやっているので、このリモートワークとは縁が無いだろうけど、諦めない。
【Effective communication saves Time】
リモートワークでのコミュニケーションの話で、次のようにグループ分けをしていた。「Text Chat:Archive,Group Chat, Privete Chat. Full Participation」
【コミュニケーションを円滑にするツール】
・CHATOPS:lita,hubot
・Audio/Video Communication:Headphones,Microphone,Camera
・HipChat,Google Hangouts,appear.in,sqwiggleSCREEN SHARING:Screenhero(for slack),Hip Chat,join.me.WebEX
・CODE REVIEW:Pull Requests,Gerrit.ReviewBoard.Code COllaborator
・Piivotal Tracker,Trello,Github Issues,waffle.io for GitHub Issues
・Ether[ad,Haclpad,Google Docs.Github Wiki
・Dropbox,Boc.net,GoogleDrive.NFS
・Google Calendar,Exchange
※誤字脱字あるので後でスライド再度確認しておこう。
【Everyone should experience remotie work】
リモートワークを理解してもらうには「期間は一週間で実感してもらうのが大事」
【Have on-site meetups】
定期的に人と会うのが大切。invite remote workers into hallway conversations. Over communicate. 37signalsのREMOTEでも似たような話があったような。読み返してみよう。
【アイデアを書き、コミュニケーションを行う】
これは付箋なり、テキストチャットなり、人それぞれの好み。Share your personality.人格個性を共有。自分の趣味は何か、オフィスを離れて何をしているのか。オフトピックの場を設ける。つまりはHipChatの雑談板みたいなものですね。Remoteって能力だけで評価するのかなと思ったら、人格であるソフトパワーも大事なんだ。結局人と人だから当然か。
【Exhibit a "visible pulse.】
大事なのはバイタルを見せる。生きてることを知らせる。いついるのかいないのか知らせる。 なんかネトゲの話に通じるのではないかと思いました。
Pick a timezone.Standard Operating Time(SOT).基準の時間を設ける。これはきっと本社がどこなのかで決まるんだと思う。
sociotechnical Theoryは造語らしい。
【感想】
このセッションで思ったのはRemoteWorkはMMOと近い何かがあるし、同時通訳者がいるなら英語で質問をするのは避けるべきだと思いました。日本語で質問したほうがいい答えが返ってくるのは良い知見だ。「日本語で質問してね」と言ったのはスピーカーなのか通訳者の心の声が漏れたのかどっちなんだろう。
でも英語出来る人が多くて驚いたし、凄いと思う。懇親会とかでせっかく来てくれた外国人スピーカーと話したら嬉しいな。そしてそういうことができるようになりたい。
※英語始めます。
最後に質問の答で「常にスマートフォンを握っていると友達や家族が強いフラストレーションを持つよね」これってリモートワーク関係なく大切なことではないでしょうか。
・Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN
Podcastの話でした。あとお金の話。
.fmってドメイン名らしく年間1万以上するらしい。Podcastも大変そう。音質という宗教の世界になるっていうのはこだわりだしたら怖い。静かな場所であればiphoneのスピーカーでも大丈夫らしいし、大事なのはいかに雑音が入らないところでやるのかなんだろう。とりあえず溜まってたrebuild.fm聴いていこう。
「大規模でも小中規模サービスでも捗る microservices な Web サービスのつくりかた」を見たくて途中で抜けてしまったけど、結局、満室で部屋にはいることができず、その後は無限コーヒーを飲んでました。スライドを後で確認しておこう。
・Lightning Talks Day 1
みんな話が面白く楽しかったです！papixさんのは笑ったし、嫁botと一緒にプロビジョニングする話もあらゆる意味ですごかった。
・8/22
【参加したセッション】
ISUCONの勝ち方
サーバーサイドエンジニア(特にPerl)のためのiOSアプリ開発入門
Adventures in Refactoring
Posture for Engineers
Run containerized workloads with Lattice
Profiling & Optimizing in Go
Lightning Talks Day 2
クロージング
【セッションの感想】
・ISUCONの勝ち方
おはよー。YAPC寝坊した。ううう
— トトス (@oza_shu) 2015, 8月 22
走って走ってちょっと歩いて走ったらギリギリ間に合った！
チューニングってどんなことをやるのか興味がありました。
ISUCONとはベンチマークツールの計測したスコアで順位付けするらしい。
勝つためには、普段から一緒に作業をしている人と作業分担をして、お互いの作業をチェックしてミスを減らすことが大事だと。問題をいち早く相談して解決すること。決まったことはメモをして書き出し、後戻りは減らす。最初の1時間は課題の理解、プロファイリングとチューニングの方向性。最後の30分再起動テストを設けること。ちゃんと起動するか確認が大事。
【事前準備】
PrivateGitRepository,Wiki,メンバーのssh公開鍵、秘伝のタレ、Chatroom,技術選択についての簡単な打ち合わせ、過去問を解く、ローカルより、EC2,GCPとかで試したほうがいい。
【チューニングの進め方】
１：課題の理解、レギューレーションヤ当日の説明を理解、どのようにスコアが決まるか、失格になるのか、ブラウザで課題となるサイトへアクセス。とりあえずベンチマークを動かす。
初期設定が間違いなど、はずれインスタンスをひいたかわかるため、とりあえずベンチマークを動かす。
2.プロファイリング、Webアプリで起きてることを知る、アクセスログの解析、MySQLのSlowLog解析、アプリケーションの解析、負荷分散。
【アクセスログの解析】
ベンチマークツールがアクセスしている先を確認。頻度とレスポンス時間をバランスよく見る。スコアに関係ないところはもういじらなくていいよねと決める。analyze_apache+log,kataribe
apacheのアクセスと具解析、httod.confをいじり、accesss_logを消し、サーバ再起動し、解析にかける。kataribeは１回しかアクセスしてないなら重くても無視する。全部を見てどこをチューニングするか決める。
【MySQL_SlowLog解析】
クエリ実行回数と頻度の両方を見る。遅いクエリ、より秒間数千クエリを食うクエリ両方を見る。ツール。pt- query.MySQLSlowLOg解析。myconfを0にして全てをslowlogに出す。最後にはslowllogを消す。どんなクエリが動いてるのか確認。
【アプリケーションのプロファイリング】
各言語のツールを使う。strace,tcpdumpなど。
アプリケーションが何をしてて、どこと通信をしているのかを確認することが大事。
サーバの負荷を見る、top.iftop,iotop,dstatなどなど、ネットワークがつまるなど、通信が一番重くなる。
【サーバ構成】
Client,リバプロ、APPサーバ、Cache,KVS,RDMSそれぞれどんなサーバで、ミドルか、その設定、過去には設定のtypoや罠もある。
チューニングの方向性を決める。与えられたサーバを使い切る。
【効率の良いCPUの使い方を知る】
コンテキストスイッチング。いかに何もしないアプリケーションにいかに近づけるか、参照通信を減らし、無くしていくこと。
Apache VS NginxだったのがNginx VS h2oになると予想。
h2oっていうのは知らなかったな。h2oはスレッドなのでNginxより早いが、設定はNginxのほうがある。外部プロセスの起動HTMLテンプレート処理、テキスト画像変換処理、RDMBMS/Cacheとの接続、N+1問題などが重い処理。
B+Tree。一番下にデータがぶら下がっている。インデックスはidだけがぶら下がっている。つまりプライマリキーがぶら下がって いる。このしょりが重い。MySQ:LのOFFSET処理。最後の古いページも見る。捨てるデータの読み都営を最小限に。
どうやってデータを取りに行くかを心に描くのはちゃんと動きを理解しないといけない。これは小手先のスキルじゃなく大規模システムの会社で働くなどして、スキルを磨かないとダメだ。やっぱり大きなシステム持ってる独自サービスの会社に勤めてみたいなー！
最後に初期状態を記録。変更を都度記録。前日はよく寝る。あきらめないことが大事。
・サーバーサイドエンジニア(特にPerl)のためのiOSアプリ開発入門
swift2.0で仕様が固まり、もうobjective-Cを書くことはないだろうと聞いて、これはiOSアプリも触ってみたいなと思いました。APIを使ったデモはネットワークの問題で上手く行かなかったけど、xcode-betaでのスライド遷移の簡単さを見るとGUIでもできることあるみたい。でもswiftはマシンパワーを要求するからMacbookProと外部ディスプレイを買ったほうがいいというのは知見だ。あとiOSアプリのいいところは作ったのを手軽に他の人に見てもらえるから、フィードバックもらえてたのしい。自分しか使わないモノを作って、自分が知りたいことだけを勉強していくのがいいよっていうのはMuraseさんでもそうなんだと思い親近感。
・Adventures in Refactoring
個人的には一番面白かった話！ヒゲで雑音が入って通訳の人からマイクの位置変えるようにとお達しが笑
リファクトリングとはコードを変えるが、振る舞いは同じ。悪いリファクター結果を計ることが大事。一貫性もいいと思うが、一貫性というものは計れないものだ。重要なのは正しいことをキープすること。良いリファクタリングは取り除くこと。不要な行を取り除く。テストカバレッジが改善されるとよい。テストのExpressabilityを改善するとよい。テストの表現性。これは造語らしい。
テストの振る舞いが変わっているところに対してリファクタリングを行う。パフォーマンスの改善がされること。コードの振る舞いを変えないで、スピードを改善。その結果を測るものとしてディベロッパーがハッピーがどうかはコードを見れば測ることができるwリファクタリングとISUCONの勝ち方も似ていると思った。
【リファクタリングの理由】
ディベロッパーがハッピーになり、性能向上する。将来の作業のに向けてのの自信を得ること。そして技術的負債を払うこと。リファクタリングした後は自信を持てる。そして他のディベロッパーの教育になる。システムがどういう振る舞いをしていくか学ぶことができる。
【テクニック】
コードの中にちょこちょこハッピーを得る。それは測定できる。例えば二つのコードを一つにするとか、アドレスをオブジェクト、リストにするとか、クオートマークの一貫性や、抽象コードを入れること。関数を入れること。小さなテーブルをスプレッドシートなどでハッシュにする。
【大切なこと】
スタイルガイドがあることが大事。それを得ること。まずスタイルガイドを決める、後はルールを踏襲する。$go fmt とか素晴らしい。というよりgo素晴らしいだってw
verbe type.動詞を名詞化できるかどうか。ちいさなメソッドを名刺にする。抽象化レイヤーを導入する。pullリクエストをマージできるのか。
あと 不要な抽象化レイヤーを取り除く。
【リファクタリングの落とし穴】
既存のバグ。リファクタリングをやっている時にバグを直してはダメ。壊れた時、fixが原因なのか、リファクタリングが原因かわからなくなるかた、それぞれ別に直していく。これは最後に質問で補足されていました。
パフォーマンスの変化がわかる。コンテキストなど。
【リファクタリングを分解】
Deprecate; 古いメソッドを取れ除けない時にする。これはtail_bytesの時はできない。Backwards Compatible : currentが一つから二つになるとき、APIを書き換え全てcurrentとする。
ここはデモで話してたところなので再度確認したい。
また大きなリファクタリングにはリスクがある。リスクを抑制するにはToolsを書く。大規模なリファクタリングにはコードが増える。
【大規模なリファクタリングによいツールの紹介】
・Backscatter.なんでコールされているのか吐く。コールスタックより上流のスタックがわかる。良い点はランタイムで実行される.
・Science:rubyのライブラリ。実験ができる。古いと新しいメソッド二つを実行できる。e.use/e.newパフォーマンステストでもscience.グラフが出る。rubygemsでパブリックされている。scienceを後でダウンロードしてみよう！
【リファクタリングの不満話】
Backscatterは時間がかかるし、scienceはrubyしかない。可視化できなくてエディタレベルしかない。それに比べてjavaは素晴らしい。言語の中に入っている。Deprecatedがある。C++14も入ってる。Djangoなどのフレームワークもある。
【Q&A】
リファクタリングのアプローチに意見が分かれたらPull requestを使う。style guideがあることが大事。セミコロンやクォーテーションはどっちがいいか等はstyle guideを見て決めていく。リファクタリングのアプローチはテストの結果をコミュニケーションのキーにしていく。テストの結果がいいほうを取ればいいんだね。
リファクタリングと開発どっちを優先するか。その基準は変更に関する自信のレベル。変更する前に自信がないとダメ。その自信を計測するのは難しい。機能の動きに変化がないか自信が大事。ここはテストを通して、決めていけばいいのかな。
先ほど話にあった、バグfixとリファクタリングの優先の問題は、個別に切り分けてやるのが大事。
リファクタリングの目標は振る舞いを変えないこと。それはテストを行うこと。テストカバレッジと表現性。テストがどれだけ複雑であるか。テストの複雑性はコード改善されないとダメ。テストカバレッジはテストがうまくいっているかでわかる。
リファクタリングのデザイン主導は好ましくない。コードがテストに、良いテストからコードは生まれる。テスト駆動ドリブンのことなんだろう。最初にテストがあって、それに通るコードを書くことが大事。コードを最初に書いて、それが通ってしまうテストを書くことになるのは避けるべき。
スタイルガイドを変更するかはpull requestで管理する。「”」にするか「’」にするかは、pull requestでレポジトリで管理する。リファクタリングが終わったらスタイルガイドを変えるなど、別々の問題としている。リファクタリング途中で変えたりはしないのかな。
レガシコードに対してのリファクタリングはどうするか。まずはテストを書くとこから始める。テストを書き切ってから、リファクタリングをする。別々に切り分ける。変更を行う前に6か8つのテストを加えるのは最初のプルリクでする。
テストのリファクタリングは絶対にやらないといけない。テストを変更するのは別のリファクタリングにする。コードとテストのリファクタリングはミックスして時にはやる。ケースバイケースなのかな。
リファクタリングとISUCONの勝ち方の類似点は振る舞いを変えず、パフォーマンスを向上させること。それがいかに大変なのか。奥が深い。
・Posture for Engineers
エンジニアのための姿勢の話。
エンジニアでありヨガのインストラクターの方の話だった。正しい姿勢の仕方と前傾姿勢の悪影響を話してくれた。腹痛も姿勢の問題かもしれないんだって。
座ることは新しいこと。長時間座ることができない。長い時間座っていると体が正しく機能しない。筋肉は縮んだり、弱くなったり、腰痛が出てくる。脊椎がずれてくる。カイロプラクティックでは背骨が全ての中心とする。咳つがずれると神経が圧迫する。
腹痛の原因が原因だったりする。ストレッチ大事。姿勢を保つ筋肉を鍛えることができる。みんなの体は違うからできないポーズがあってもへこまないで。痛みを感じたらやめてた方がいい。痛みがあるのは不自然なことだから。
立って仕事をするのはいいけど、今まで座ってた人がやると、膝を痛めたりするかも。立方として耳が背骨の中心に来るようにして前傾姿勢を防ぐ。
みんなで実際に立って面白かったなｗ
【ストレッチ方法】
床の上に座る。肩甲骨を壁につけて、４秒かけて頭を前後に倒す。脇の下の筋肉は四つん這いcat/cow、または椅子に座って肩を中心にし、頭を倒す。
骨盤が丸々と膝にも問題が出る。腹筋を鍛える。丸まらないようにする。でも腹筋運動は危険かもしれないから、エクサザイズボールに座るのが良い。30分座ることから始めよう。
以下はポーズの名前。後でググっておこう。
BoatPose/full pose.背骨をまっすぐにするのがポイント。
Staropen/Close。
Standingholdpose/Ardha
Uttanasana(Halfway Lift)
座りっぱなしは体に良くないけど、そういう仕事だから気をつけた方がいい。
姿勢について知見を得ることができ感動した。
・Run containerized workloads with Lattice
CloudFoundryオープンソース、もっと簡単なLatticeっていうのを作ったよって話。
Latticeのアーキテクチャーを話してくれた。LatticeはDockerやBuildPackを実行できる。CloudFoundyより簡単なのが特徴。適していないのはプロダクション環境ではダメ。Persistent dataもダメ。セキュリティーポリシーが強いのもダメ。使うのはローカルでお願い。
Kubernetesはスケジューラにすぎない。SelfHealing,LoadBalancingは他でやらせること。
Latticeはインストールが楽で、vagrant upだけでいい。クラスター化できるしterraformも適している。スケジューラの名前はDiego。Task,LongRunningProsess。Schedulingはコンテナの数 インスタンスの数。
【Usage】
Dockerイメージのデプロイや、アプリのスケールアップとか。Builtpack:dropletをつくったら実行。自分のワークロードも作れる。own workloadのことね。
ルーティングレイヤー：デフォルトあるが、変えることもできる。
【Logs】
アプリログを指定。X-Rayアプリのインスタンスディトリブーションゾーンを可視化。X-RayhはOSSだよ。
Latticeは開発環境で、本番環境はCloudFoundry.でも使い方はほとんど似ていて、コマンドが違うだけ。Latticeでローカルでいじってから始めるのが良さそうだった。インストールも簡単だったし。
・Profiling & Optimizing in Go
Go,Go,Go,Go,Go.
Go言語の話だった。
終始、デモだったのでEmacsの流れるようなデモコーディングにインフラはVimで、開発はEmacsでやろうと思いました。
※Emacs始めます。
go tool pprofはすごい便利そうだった。いろんなツールが有るんだな。
・Lightning Talks Day 2
MySQL5.7はデフォルトで360日でパスワード変更求められるらしい！これで呪いは回避できたかな。
みんな昨日今日で作ったとは思えない内容で面白かったです。すごかった！
・クロージング
これで本当にYAPCは終わりなんだなあと思ったら感慨深いですね。いろんなエンジニアの同窓会にもなってたんだろうなあ。最後の最後で知れてよかったです。こんなにも楽しいカンファレンスって無いんじゃないでしょうか。Perlはワンライナーいや、プログラミング書かない人でも、十分楽しめるセッションばかりのカンファレンスなんて無いですよ。今はperl以外の言語を書いていて、perlから巣立っていった発表者の方々も多かったのではないでしょうか。
別の言語や、Perlとは全く関係ないサービス、開発手法について話せるカンファレンスなんて他にないですよ！Perlのコミュニティとそこで育った皆さんの懐の深さが知れました。Perl入学式みたいにプログラミング入門の勉強会があるし、Perlコミュニティっていいですよね。Larryも言ってたけど育っている感じがとってもいいコミュニティだと思います。
別の言語や、Perlとは全く関係ないサービス、開発手法について話せるカンファレンスなんて他にないですよ！Perlのコミュニティとそこで育った皆さんの懐の深さが知れました。Perl入学式みたいにプログラミング入門の勉強会があるし、Perlコミュニティっていいですよね。Larryも言ってたけど育っている感じがとってもいいコミュニティだと思います。
最後のYAPC今回は2130人参加とのこと、前回は1361人参加だったので、最後にこんなに多くの人が集まったのは凄いと思います。そしてスキルが有ればこんなにも沢山のエンジニアさんと出会えるのって凄いことだと思いました！
そしてスタッフの皆さんお疲れ様でした！楽しかったです！
ありがとうございました！
【報告】YAPC::Asiaの感想【二日目】
【ブログを書くまでがYAPC】
YAPCのブログを書くために開設したので、
もちろん二日目の感想を書かせていただきます。
一日目の興奮とアルコールが抜けきれなかったので、中々寝付けませんでした。
その結果。
#yapcasia 寝坊した！
— oza_shu (@oza_shu) 2014, 8月 30
一番聞きたかった「突然ITインフラを任された人のための…監視設計入門」には
ギリギリ間に合ったので良かったです。
そんな感じでYAPC二日目が始まりました。
【参加したセッション】
突然ITインフラを任された人のための…監視設計入門
Perl Mongersのためのstrace入門
Perl入学式 in YAPC::Asia Tokyo 2014
あやかNow!
そんなにビッグでもないデータ処理手法の話
Lightning Talks Day 2
キーノート
YAPC::Asia Tokyo 2014 - クロージング
【セッションの感想】
・突然ITインフラを任された人のための…監視設計入門
→インフラエンジニアとして一番身近でためになると思い楽しみにしていたセッションでした。NOWで現行踏襲という設計で障害が絶賛発生中な現場にいるので、設計とはどうやるのか気になってました。
これは質問しそびれたことが一つあって、オープンソースのミドル使ってるWEB系の会社は障害発生時どのような対処をしているのか気になった。OS,NW,DB,運用MW,業務MW幅広い領域だと思う。SIerはベンダー製品と手厚いサポートがあるけど、WEB系はどうしているのか幅広いスキルと知識を持って対処できるのか、てかどうやったらWEB系のインフラで働けるのか！ハードウェア保守としてはAWSみたいなクラウドの時代が来たら死ぬと思いました。
・Perl Mongersのためのstrace入門
→先頭でstraceの見方の話を聴いていてら、後方から上手く動いてないんじゃないかとか
声が聞こえてきて、セッション中に登壇者に話しかけるのすげえ！誰だろうと思ったら
弾小飼さんでCooool!!と思いました。もちろんstraceはちゃんと動いていて、straceの見方を教えていただき勉強になった。普段はstraceをとってもサポートに投げて終わりと他人任せな事しているので、自分でもちゃんと調査します。反省
時間に追われて発表をしているからラフなセッションというのは中々難しいのかなとも思いましたが、ぶっ込む弾小飼さんCooool!
・Perl入学式 in YAPC::Asia Tokyo 2014
→Perl入学式#1補講以来の参加だったので、かなりパニクりながら練習問題に取り組んだので時間があっという間に過ぎました。サポートの方々に助けられながらもPerlを動かせてプログラミングすごい！たのしい！という感覚を得られました！9/23の第3回は参加しますので、雅なPerlを読んで望みます。最終問題の同じお店が出ないコードが未だに書けていなくて、ブログに載せようとしたのですが間に合わなかった。
そういえば一日目のHUBで話したお姉さんとは別の席だったから、話す機会なく残念です。
・あやかNow!
→Rubyアイドルがいた！かき氷うまい！無限コーヒー！
・そんなにビッグでもないデータ処理手法の話
→何をしたいか。サイズはいくつか。それにあったプラットフォームを選ぼう！という話だったと思います。FrameworkやAPI等の概念がわからず技術的なことは余りわからなかった。取り敢えずわかったことはビッグデータはペタサイズのデータと聞いて、ビッグデータに関わることはなさそうだなあというのは分かった。
#yapcasia ビッグデータはどんな世界で扱っているのか。官公庁でも扱ってない木ガス。
— oza_shu (@oza_shu) 2014, 8月 30
・Lightning Talks Day 2
→よいLTばかりでした。ドラ娘も良い。有名な人達を早速フォロー！きっと技術的なことと変態的なことがTLにいっぱい流れるんだろう楽しみ！
・キーノート
→趣味と仕事の話。3年目になり仕事にも慣れ始めてきて漫然とした態度で仕事をするようになった自分には刺さりました。自分がしたいことを仕事にしたい！エンジニアってめっちゃ楽しい！と思う人が増えると世界がよくなるんだろうなあ。そういう姿勢で仕事もしたいとも思います。100%受託の仕事をしていますが、受託は新しい人と技術に出会えると聴いて、受託なんてと腐らずに得られるものは得ようと思います。20代になにをするかは大事って話は20代後半に突入した自分には何かやらないとって思いをさせてくれました。これからどんなエンジニアになりたいか、勉強していろんな人に出会って、ロールモデルを見付けたいと思います。もっとエンジニアらしく振る舞いたいです。
・YAPC::Asia Tokyo 2014 - クロージング
→来年もあると嬉しいです！技術的にリベンジしたい気持ちでいっぱいです。技術的にも分かることを伸ばして来年はいろんな人と技術的なことを話したいです！エンジニアの人たちってこんなにいるんだと感激しました。
今回は1361人参加とのことで、スキルが有ればこんなにも沢山のエンジニアさんと出会えるのって凄いことだと思いました！懇親会来年はワイワイの中に入れるようにしたい！
そしてスタッフの皆さんお疲れ様でした！楽しかったです！
ありがとうございました！
YAPCのために開設したこのブログも、せっかくだから勉強した技術的なことや勉強会の感想など書いていこうかなあ。
そういえば一つ自慢話、この間の神楽坂ゆかさんのライブ最前列でした！
世界一かわいい人をすごく近くで見れた。( ･ㅂ･)و ̑̑ ｸﾞｯ !
【報告】YAPC::Asiaの感想【一日目】
【ブログ開設背景】
メールでセッションの投票と感想ブログのお願いが来てたのでブログを解説してみた。
YAPCの存在をPerl入学式#1補講に参加した時に初めて知りました。
Perlの生みの親Larry Wallも参加予定のPerlの祭典とききPerl初心者の俺も参加してみたい！と思い参加してみました。
"ブログを書くまでがYAPC:Asia"とオープニングでゆーすけべーさんも仰っていたので感想を書かせていただきます。
YAPC会場到着！駅前だ (@ 慶應義塾大学 日吉キャンパス (Keio University Hiyoshi Campus) in 横浜市, 神奈川県) https://t.co/ErzYijrJ3J
— oza_shu (@oza_shu) 2014, 8月 29
【参加したセッション】
YAPC::Asia 2014 Tokyo - オープニング
インフラエンジニア(狭義)は死んだ
Introducing Swift - and the Sunset of Our Culture?
作られては消えていく、泡のように儚いクラスタの運用話
コマンドラインツールについて語るときに僕の語ること
YAPC::Asia2014会場ネットワークのツクリカタ
O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門
ウェッブエンジニアのローレベルプログラミング
Get a kick out of CPAN
初心者が Web エンジニアのコミュニティに触れてみて感じたこと - ゆとりエンジニアの成長戦略
Lightning Talks Day 1
【YAPC感想】
結論から言うと行って良かったです。
プログラミング知識がない俺でもセッション理解できるか不安だったけど、参加させていただいたセッションはどれも聴いていて楽しい物ばかりでした。
いくつか印象に残ったセッションの感想を書きます。
・インフラエンジニア(狭義)は死んだ
→初っ端から自分に該当する話であばばばｂｂっｂｂ
プログラミングできないインフラエンジニアですが、自称が自分が何をする人なのか無意識に決めてしまい、自分の担当領域を勝手に決めるというのはあると思いました。自分の仕事じゃないと決めて敬遠する作業などあったりするし、やってみたら新しいスキルが身についたと達成感を得ることもある。
解決すべき問題はなにか。目的を果たすためにコードを書く。というのは写経レベルから抜け出せていない自分にはまだ無い感覚でした。
問題解決できるエンジニアになれるように頑張ります。いつか仲間を見つけてISUCONへ。
・ウェッブエンジニアのローレベルプログラミング
→アセンブリの話からRaspberry Piはてやモールス信号と発表者が一番楽しんで発表していたのが印象的なセッションでした。
特にハードウェアを学ぶのは人生を豊かにする。
プログラミングを初めて学んだ時の今日はこんなことができるようになった等の達成感が得られる！など本当に人生楽しくなりそうな発表で好きでした。
Raspbery Piでメモリをいかに使わないでコードを書くかというのは、メモリが有り余る環境では得られないコードスキルが身につきそうで本当に良いんじゃないかと思いました。眠っているRaspbery Piたんを起動させようと思います。
・初心者が Web エンジニアのコミュニティに触れてみて感じたこと - ゆとりエンジニアの成長戦略
→Webエンジニアに転身してみたいと密かに思っている、初心者の自分には一番参考になるセッションでした。
発表者の方は新卒一年目とは思えないほどしっかりした発表で凄いと思いました。
勉強会に参加して顔を覚えてもらうことでコミュニケーションコストを下げるの大切というのは参考になりました。ここが一番大切でハードル高いところかなあと思いますので超えられるように頑張りたい。
顔と名前を覚えてもらうことでブログ読んでもらえたり、初心者にやさしいおじさんが助けてくれたりするらしいです。そのためにも懇親会に参加したり、勉強家で発表したり挑戦してみたいです。
今日の反省点は懇親会で発表者の森さんに話しかけられずにおずおずと引き返してしまったことです。ううう
【気になったこと】
・Introducing Swift - and the Sunset of Our Culture?
→@dankogaiさんのスライドに@chibicodeさんの引用があった。時間がなかったから飛ばされたけど、あれはどういう話になる予定だったのか気になる。
【そうろん！】
インフラ寄りのセッションが多数あって自分には耳の痛い話や刺激になる話、とても勉強になりました。
HUBでPerlの人口は減ってきていると仰っていた方がいましたが、Perlコミュニティのプログラミングへの愛を感じたカンファレンスだったと思います。
二日目はPerl入学式に参加して終わりそうな気がするけど、YAPC二日目頑張るぞい！
以上。
