格闘技メモ
ずっとメモにしてばかりなので履歴も兼ねてログ残す。
2年ぐらい前から職場近くのジムに通っている。
スポーツジムではなく格闘技のジム。以前膝の手術をしたので、リハビリも兼ねてフィットネスジムに通ってたけど、日常生活に支障がなくなると、特に筋トレする理由が無くてモチベーションが保てずに、半年ぐらいで飽きた。
その後、現在の職場に転職して、定時後に何かをしようと思い、格闘技をやろうと思って、近場のジムを探す。
会費安いし、いろんな種類の競技が教えてもらえそうだったので
入会。
キックボクシングや、寝技(柔術、グラップリング)のクラスがあり少しづつ参加していたら今では土日も含めて毎週2、3日は通う程にハマる。
筋トレはまあ少しはやってたが格闘技未経験という事もあり色々と指導を受けて少しづつ成長してんのかなともおもうし、指摘された時の内容をメモがてらブログに書いていく。
その時にやった事も忘れないよう書いてく。
先ずは基本から。
スタンス
大きくオーソドックス(左足前、右利きに多い)と、サウスポー(右足前、左利きに多い)がある。
- 前足:後ろ足は4:6ぐらいの荷重割合
- 顎は引いて狙われない様にする。足元を見てから目線だけを前に向けるとイイ感じになる。
- 前側の肩を出して、後側の肩を引く事で真正面に急所が見えない様にする
- 肩はリラックスして下げておく
- 前手は顎に当ててから少し前に出す。
- 後ろ手は顎に付けるぐらいの位置で待機
- 肘は締めて、アッパーなどが入ってこない様にする
ジャブ
- 素早いジャブは裏拳ぎみ、または縦拳のまま
- 肩を上げて自分の顎を守る
- 当て込む時は拳を内側に捻る
- 出した後は素早く引いて体制を戻す
ストレート
- ストレートは前傾して打つのではなく、腰を捻って打つ。
- インパクトの時に腰の回転を絞って止める。脇を締めて小さくまとめる
- 相手にバレやすいので肘が開かないように真っ直ぐに拳を出す。
- 前のめりにならないようにして、前足は前傾しないように耐える。
- 後ろ足は横にズレたりしないようにつま先で地面に立てて止め、拳からの力を後ろ足で支えれるように踏ん張る。
- ストレート出した後に拳を引くときは腰、肩を捻って元の位置まで戻す
- 打ったらすぐに引いて元の体制に戻せる重心位置を意識。
- 自分のパンチの距離をサンドバッグなどで把握しておく。
- 距離があるときはジャブで距離を詰める
意外とやる事が多くて形がマトモになるまで時間がかかるし、鏡とかを見ながらのシャドーと、対人の場合で大きく勝手が変わってきて難しい。
自宅PCのUbuntu化
先日、いきなり使ってたMacがぶっ壊れた。
とは言っても3年ぐらい前に中古で同僚から売ってもらった、2008年?モデルのMacbookProだけど。(もう起動しないのでモデルも確認できん)
ある日(12月24日)の早朝4、5時までは起動してたけど、寝て起きてつけたら起動すらしなくなった。
非常にショックを受けて落ち込んでた日に、ベンチプレス100kgが挙がって若干救われた。
んで、今まで数年Macを使ってて慣れてたんで次はMacbookAirにでもしてみようかと思って、オークションサイトや、フリマサイトを徘徊して物色してた。
年末年始休暇に家の中を持ち運べるPCがないのは困ると思ってたけど、やっぱ衝動買いな感じが抜けなかったので、いろいろ考えてデスクトップ使おうと覚悟した時にひらめいた。
「昔使ってたWindowsのノートPCにLinux入れたらいいんじゃね?」って。
以前、使ってたノートPCが実家に規制中にCPU焼けて使えなくなって、即買いしたWindows7
のノートPCが残ってた。Windows8→10にアップグレードして、元に戻そうと思ったら戻らなくて、リカバリもCDじゃなくてHDDの領域にあったけど、OS自体が書き換わってて二度とリカバリできない感じになって放置してたヤツ。
以前の会社だと、MSOfficeをメインでつかってたかあら、たまに自宅で資料作成してた時にLinuxだとキツイなー。と思ってたけど、今の会社は対外だけぐらいでMSOffice使って社内ではGoogleDriveでもOKみたいな感じだったんでそこら辺の問題もなさそうだし。
ってことでUbuntu 16.04 LTSを導入。
久々にLinux。やっぱWindowsはどこにでもあるけど、SSHとかITインフラ系のソフトが初期状態で揃ってないのが面倒。ちょっとした手間なんだけど、意外と萎える。
最近触ってるAnsibleとか、Dockerとかもローカルで実行できそうだなと思ってやっぱMac or Linuxが良かった。
んで、インストールしたけど、無線LANが繋がんない。。。優先はいけるけど、せっかくのノートPCが無駄になってしまう。ってことでググりました。
Ubuntu日本語フォーラム / NetworkManager が無線LANを認識しない
そしたらなんのことはない。無線LANの機能がOFFられてただけ。ただ、意外と気づきにくい、Windowsの時は気にせずつながってたし。
まあ、毎度起動時にOFFになってるんで一手間増えたけど、いつまで持つかわかんないMacを中古で買うよりかはとりあえずいいかなーって感じ。
んで、今度は日本語入力できないんで、またググる。パッケージが不足してた模様。
次は、個人的には重要なアプリの「keepass」をインストールしたら、一部の文字が文字化け。
まあいいかなーと思ったけど、またググッて発見。
kokufu.blogspot.jp設定変更で対応可能。
これで、とりあえず問題なく使える環境が用意出来た。
一瞬、最新のMac買おうとも思ったりしたけど、無料でもここまで出来て、今のとこ数日間は特に問題感じてないんで、やっぱLinux最高。
仕事で使うOSもLinuxなんで偉大だなと。
まだ、ブラウジングぐらいしかしてないんで今後は開発系の作業するときに効率の上がるアプリを導入していこうと思う。
もう、日付変わって明日からは2017年。
また今後の事も考えなきゃいかんので、進歩ある一年にしていきたいです。
では。
ベンチプレス成果(目標達成)
もう2016年も残り数日って事で年始に立てたベンチプレス100kg挙げるって目標をギリギリ達成‼‼
先週の挑戦では少し挙げた所で止まって失敗して、残り日数も少ないしかなり焦ってたけど一つは目標達成した年にできて良かった。
色々あってユルくではあるけど中学ぐらいから目指してただけに嬉しい。
これも定期的に通いたくなるような楽しいジムがあったからこそ。
まだまだギリギリな感じなので来年はパワーアップ&ダイエットして体脂肪下げていこう。
ログ収集・分析基盤の検討
今の会社では、自社のWebシステムをBtoBで販売してて、そのサーバ・インフラ周りの面倒を見てるけど、プロダクト数が10くらいあってサーバの台数も200台ぐらいになってきてる。
この台数を2人でプロダクト毎に担当分け。
プラットフォームは主にAWSを利用していて一部IDCフロンティアも利用している感じ。
そのIDCフロンティア側も自分が担当していて、サーバ台数が25台ぐらい、CMSのシステムでWEBサーバ20台、DBサーバ5台って感じ。
んで、WEBサーバ中でVirtualHostが60個ぐらい存在するんで、正味800サイトぐらい存在している計算。
その中でTVとかに公開されてちょっとアクセスが増えるとすぐにCPUが上がってくるんで、どのサイトが原因なのか確認してた。
でも、実際ログも60個ぐらいあるんでタイムスタンプが最新のログとか見て目星つける感じなので、あまり正確なもんでもなかったし、tailとかで内容見てるけどそもそもそのログじゃなかったときとか意味ないなー。とは思ってた。
そこで、EFK(ElasticSearch+Fluentd+Kibana)に代表される、ログの収集分析基盤を導入すれば傾向とか掴みやすいだろうと思ってちょっと検証してみた。
前にも試しで構築とかしてたけど、ElasticSearch辺りが面倒な印象だったけど、今はAWSのElasticSearch Serviceがあるんでクリック数回で立ち上げれる。(さすがAmazon様)
なので、実際はFluentdの辺りだけを頑張った感じ。
もちろんこの本も参考にしました。
まだ、正式に導入はできてなくて、検証の段階だけど、大量のVirtualhostがあった場合にも、アクセス先のホスト名とかもログに出してしまえばサーバ側でログを分割する必要がないんじゃないかな、って思う。
しかも、同じElasticSearchのインデックスに投げればサーバ全体での傾向や、複数サーバのログを合わせて分析してCMSシステム全体での傾向も可視化することができるってのはなんとなくわかってきた。
「なんとなく」ってのは、CMSのシステム自体にはまだ導入できていないので他のプロダクトのログを投入して試験的に分析しているかんじなので。。。。
あとは、今まではApacheLogViewerとかでグラフ化してたのが、ブラウザだけでリアルタイムにできるんでかなり調査、分析するなら便利。
サーバログインとか、コマンドとかわからない非エンジニアの人に対しても状況把握とかはしやすいだろうし、kibanaの使い方を覚えれば自分の希望する分析もできる。
今後クラウド化が進んでいくにつれて、AWS AutoScalingみたいにサーバ自体が永続的なものではなくなっているんで、ログみたいな「あまり使わないんだけど、すぐに捨てるわけにはいかない」データを外出しして活用できる仕組みないと運用系のエンジニアはキツくなっていくだろうな。
ただ、まだWEBサーバのログの活用方法まではちゃんとできてないんで、そこらへんのメリットを他のマネージャなどにアピールできないと本格導入ができないんだよなー。
Hadoopセミナー参加
先日、某巨人の会社で開かれた無料のハンズオンセミナーに参加した。
テーマは実務では経験の無いHadoop/Sparkについて。
今の会社は導入・検討の可能性があれば平日でも外部セミナーに参加させてくれるところはありがたい。
やっぱそういうとこで社員のモチベーションとか、学習意欲って変わると思う。
本題に戻って、今迄なんとなくHadoopって聞いたことあったし、調べたりもしてたんでどんな時に使うソフトウェアなのかってのもざっくり分かってたけど、実際に触れるってのが良かった。
まあ、前もネット記事見ながら立ち上げて、クエリ投げて結果返ってきたけど、んで何がすごいの?的な感じだったんで肌ではメリットを感じれていなかった(データ数が少なすぎるんで当然)
書籍も電子で買ってたけど、よーわからんって感じで見なくなってたし。
まあ、今回一番良かったのは、実際に使ってる人に対して自分のモヤモヤを質問出来たこと。
最近だとRedshiftみたいな列志向RDBとかも出てるしGoogleとかぐらいしか出番ないんじゃないのか?とか思ってたけど、結論としては『大規模データ集計はどっちも出来るけど、そこからの操作に得手不得手がある』って感じ。
当然ペタバイトとかになればRDBじゃどうにもならんだろうけど。
ざっくり書くとこんな感じ。
■RDB
SQLが使える(かなり重要)
トランザクションが使える
インデックス使って絞り込んだデータ抽出が得意
バッファプール使って同じ結果を高速化
クエリの結果が早い
めちゃくちゃデカいGroupByとかどうなんのかわからん
ロール管理、アクセス管理がしやすい
オプティイマイザが枯れている
■Hadoop
シーケンシャルアクセスの設計なので特定のデータ抽出が苦手
大規模データにもスケールアウトで対応できる
少ない件数だと結果が返ってくるのが遅い
基本的にはjavaじゃないとデータの操作ができない
ディスクへのデータの格納方法が冗長化前提
チューニングが難しい
こう書くと、意外とRDBの方が良いなって印象。
ただ、時代と共にデータも増えてきてRDBも色々頑張って来たけど、どうにもならんくなってHadoopが使われるようになって来た感じかな。(歴史的な背景は不明)
本当は使いたくないけど仕方ない的な。
ただ、使い易くするようにSQLライクにデータ操作が出来るようにしたHiveなんかが出て来たみたい。
javaは一切出来ない俺でもデータ操作が出来る(すごい)
あとは、HadoopはMap/Shuffle・Sort/Reduceって処理の際の中間結果をディスクに書き出すようでまあ、デカいデータであればやっぱり時間がかかるってことで、インメモリで処理して高速化するようにしたSparkも出来てかなり実用的になった模様。
そういや最近はよくSparkって聞く気がする。
機械学習みたいに大量なデータを高速に処理する時にはメモリ上でササッと処理するんだろう。
メモリも安くなって来たからこそ実現できた事なのかもしれない。
最後はHadoop周りの自社製品の説明とハンズオンをやって終了。セミナーの時間が押しまくってセミナールームの利用時間ギリギリに逃げるように退散。
だけど、Hadoopに対する理解も深まったし、手ブラで無料であれだけの事を教えてもらえたのはラッキーだった。
さすがはインターネットの巨人様。ありがとうございました。
もう一回Hadoopの本を読んで再挑戦して見よう。
https://www.amazon.co.jp/Hadoop徹底入門-第2版-オープンソース分散処理環境の構築-太田-一樹/dp/479812964X
ベンチプレス成果
1月頭にジムの人と一緒に「2016年内にベンチプレス100kgを達成」を目標にして少しづつ記録してきた。
もう師走ってことで残り時間もないのでそろそろあと一歩のとこまで行ってないとヤバ目。
11月ぐらいに95kgに挑戦したら、他の人は挙がったけど俺はちょっと挙げたとこでそれ以上持ち上げれなくなって、失敗。
かなり焦ってそれから挑戦できなくなってたけど、ジム行った時にたまたまベンチプレスに挑戦することになったから、95kgにトライ。
ゆっくりだったけど、重さ的には余裕ある感じで挙がった。
追い込むつもりで2回挙げようとしたけど、バーに巻いてあるスポンジのマジックテープがシャツに引っ掛かって無理だったw
でもこれであと残り5kg。今年もあと20日ぐらい。ジムもギリギリまではやらないから実質残り2週間。なんとか間に合いそうな気もする。
来年は年初から別の目標を立てているので気持ち良く年内に目標をクリアしたい!
ZABBIX ホストのテンプレート設定
今、会社ではWEBシステム監視にZABBIXを利用している。
前職でも利用していて、ちょっと面倒な部分もあるけど、細かい設定もできるし、まあまあ慣れているのですぐに馴染んだけど、監視の設定自体がごちゃごちゃしてたので、統一化や、自動登録、マクロ利用などしてプロダクト毎にイイ感じに修正して運用していた。
あるプロダクトで日常的にリソース監視の通知が来てて「もうそろそろこの設定見直したほうがイイんじゃないか。」と思って、既存の監視テンプレートを流用して、修正した新規の監視テンプレートを作って適用してた。
毎日通知が来てる監視のトリガー感度を下げたけど、なーんかまだ通知がくるなーと思ってはいたけどちょっと経過観察してた。
んで、ふと気づくと新しい設定でもトリガーが登録されてたけど見覚えのないトリガーがあった。しかもテンプレートに紐付いてない。
よくよく考えてみると新規のテンプレート適用前の設定が残ってる模様。
そういえば、監視データを捨てるのが勿体無いのでテンプレートの「リンクを解除」してたからっぽい。
何台か同じ設定を適用したサーバがあったんで、悩んだ結果、元々の監視ホストをリネーム(一時的にそんなホストねーよ!って言われる)して、そのホスト設定を複製して新しいテンプレートを設定したホストを登録。
そうすると要らないトリガーとかがない真っさらなホストで登録できた。
もちろん監視データはないんで、古いホスト設定は削除せずに無効化しておいて後で削除する予定。
ZABBIXの仕様なのかちゃんと調べてないけど、ちょっと注意が必要みたいだ。