読者です 読者をやめる 読者になる 読者になる

#devsumi 2016 に行ってきました

今年もデブサミに行ってきました

event.shoeisha.jp

ここ数年は毎年行っているのですが、やっぱりデブサミは良いですね。

なんというかモチベーションが上がります。参加者には開発者からデザイナーから経営者から色々な方がいるんだと思います。それぞれが色々なものを良くしようと思ったり、仲間を募ったり、はたまた単に趣味の話をしにきたりして一つの場所に集まっているのだなと思うとなんとなく気分がアガります:)

Day 1

speakerdeck.com

いきなり素敵なお話でした:)

要件定義とか仕様書出したりとかしてる段階ではお客さんはおとなしくて、動くものが出てきてから色々な話が出始めるというあるある話。

動くものを見ないとわからないことが多いのは当たり前の話で、お客さんから(悪い意味ではなく)クレームが出てくるのは当たり前だと。それを意識しておかないと、お互いに嫌な気持ちになってしまうわけですね。

クレームが出てから直されるまでの間が開くと「諦め」が発生する。これは改善の機会を逸することになるので、短い間隔で継続的にリリースできることが大事。コツコツ継続的にやっていこう。

失敗を0にすることは出来ない。リスクを0にしようとするのは不可能をなそうとしている、リスクをマネジメントしなければいけない。

大事なことは「価値がある」「使える」「作れる」こと。それぞれを判断できる人は別であることが多いので、一緒に考えなければいけない。みんなで集まって解決していこう。

なるべく小さなアウトプットで、なるべく大きなインパクトを出そう!

スクラムとユーザーストーリーマッピングでうまくいくかも?

友情→努力→勝利!!!

ユーザーストーリーマッピング

ユーザーストーリーマッピング

 

 

2つ目は1つ目と内容がもろかぶりだったので、本を立ち読みしてから休憩と充電を兼ねてカフェに行ってきました^^;

f:id:NYamairi:20160224121058j:plain

バナナ美味しかったです:)

 

www.slideshare.net

 打って変わって言語のお話。

JavaScriptも大分こなれてきたという話(だと勝手に理解)。2015年にガツンとバージョンアップされて、しばらくは緩やかな変更にとどまるらしい。他の言語からもいろいろ取り入れているとのこと(C#からAsync Awaitとか)。

JavaScriptにありがちな「でもその機能はこのブラウザで実装されてないよね」問題。トランスパイラ(BABEL)で解決する。最新の言語仕様で書いて、実際にデプロイするときは環境にあった形に変換する。LESSだのSASSだのminifyだのと同じタイミングでやる。

2015でめんどくさかったこととか色々良くなるらしい。文字列内で変数展開できる(バッククォート括り)とか、デフォルト引数とか、可変長引数とか、オブジェクトの特定のプロパティのみ抜き出して変数に代入とか、classとか、ブロックスコープの導入( (function() {...})() ←これを書かなくていい)とか、定数とか、矢印関数(thisが差し替わらない)とか、非同期処理にasync awaitが使えるようになるとか、Setとか、とにかくいい感じとのこと。

パフォーマンスも順調に最適化が進んでいるとのこと。生JSを書くのが苦痛でなくなっているのか、仕事で使ってみたい。

 

www.slideshare.net

こちらはアーキテクチャの話。トレンド(?)になっている「リアクティブ」とか「マイクロ・サービス」とかですね。プロジェクトの進め方系の話と並んで興味のある分野です。

 個人的にはカタカナが多めでそこが結構厳しかったのですが、無理して翻訳しないというのは大事ですよね、うん。

 スライドがしっかりバッチリしていて内容については読めばわかるのですが、まとめるとこんな感じだと捉えました。

  • 分散分散言うけどちゃんと考えて気をつけてやれよ
  • ネットワークとかそんなに信用できないからエラーのケアしろよ
  • サーバとか増えて運用辛くなるからしっかり自動化とかしとけよ
  • 自分たちで頑張るんじゃなくて先人に頼れよ

 

www.shoeisha.co.jp

1日目最後はこちら。毎年これを選んでます:) 

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

 

↑ おすすめポイントはインフラに関して散らばっていた知識が繋がることだそうです:)

個人的には結構興味深い内容だったのですが、いかんせんクラウドイケイケの世相から不利でしたね:(

ハッカーの学校

ハッカーの学校

 

↑ 業界外の人にITについて興味を持ってもらうのが意図だ的なことだったと思います(うろ覚え^^;)。

個人的にはとても喜ばしいという印象で、技術書部門はこの本に投票しました:)

会社に買ってもらう候補です。

プログラマ脳を鍛える数学パズル シンプルで高速なコードが書けるようになる70問

プログラマ脳を鍛える数学パズル シンプルで高速なコードが書けるようになる70問

 

↑ 技術書部門大賞ですね:)

個人で購入したのですが、「サイン本ラス1です^^」と言われてTwitterに投げたら同じことを呟いている方がいて、どっちが真のラス1なのだろうか…

HARD THINGS

HARD THINGS

 

↑  ベン・ホロウィッツさんが実際に直面した困難と教訓をまとめた本とのことです:)

人→製品→利益 の順番で大切にしろとのこと。読んでいると胸が痛くなるとのこと^^;

ビジネス書部門はこの本に投票しました:)

会社に買ってもらう候補です。

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える

 

↑ 去年も似た本が出てましたが、所謂Googleの働き方というやつですね。

帯には「グーグル」と入っていますが、別にGoogle独自じゃなくてGoogleだって他から取り入れたりしている、「あのGoogleが!」的な先入観を抱いてほしくないと言っていた気がする。 

↑ ビジネス書部門大賞ですね:)

ディープラーニングの入り口的な立ち位置だとか?個人的に購入したいと思ってます:)

電子書籍版が紙媒体の売上を上回っている稀有な本とのこと。

Day 2

event.shoeisha.jp

(資料が見つからなかった…;)

大体の問題はプログラミングではなくマネジメントの問題。これはまさしくそのとおりだなと思います。

大規模開発をマネジメントし切る実力を持っているマネージャなんてそんじょそこらにはいないのではないか。しかし壁を超えた先には魅力的な世界が広がっている。

アジャイルに期待しすぎるのはダメ。ウォーターフォールはダメだからアジャイルでやりましょうよ的な言葉は鵜呑みにしてはいけない。

問題は方法論ではないのではないか、その場合はウォーターフォールアジャイルだ言ってても解決できない。アジャイルが言っているのは当たり前のこと。乱暴に考えるとウォーターフォールでも細かくやればアジャイルではないか的な(私個人の捉え方です、マサカリが飛んできそう;)。

アジャイル=無計画 ではない(当たり前ですな)。

ツールに振り回されてはダメ。ツールありきで仕事の進め方を決めているのでは本末転倒、やり方が先にあってそのためにツールが有る。

常に反省すること。結局は最初から最後まで「覚悟」と「人」の話である。

 

event.shoeisha.jp

会場を間違えました…(そしてそれに気づいたのは結構経ってから…^^;)

わりとGithub エンタープライズの宣伝的な感じでした。

まとめとしてはこういうパラダイムシフトの導入にあたって費用対効果を出すのは無理なので、熱意で頑張れとのこと。もう流行りとかじゃないんだよ、普及してるんだよ、使えるのがメリットなんじゃなくて使えないことがデメリットなんだよ。

 

www.slideshare.net

はじめはAWSの宣伝かな?と思いましたが、思ったより得るものが多かったです。わりとこれからやろうとしているところにハマりそうな内容でした:)

マイクロ・サービスはクラウドとの相性が良い。小さな部品を組み合わせる的なね。

モノリシックなシステムから開放されよう(「モノシリック」だと思ってた…^^;)。

ここでも分散システムの難しさについて釘を刺される。

API GatewayとLambdaの組み合わせでEC2を使わずに構築するのがイケてる気がする。API GatewayもLambdaも面倒なことを色々やってくれて大変よろしい。ビジネスの本質と関係ないコードの量を減らせる。大抵の場合はEC2よりコストが減る。もちろん必要であればEC2を使ったって構わない。

 

event.shoeisha.jp

(資料が見つからなかった…)

途中からで立ち見だったのでろくにメモも取っていないです…^^;

しかし良い話でした:)

マネージャになって辛いことがあったが、自分のモチベーションを考えなおしてみると意外に合っている仕事だと思い直したとか:)

 

www.slideshare.net

最後は気になっていたブロックチェーンについて。ブロックチェーンの有用性についての話かとおもいきやDisの立場からのお話でした^^;

やっぱり難しくて曖昧な解釈しか出来てません…><

ブロックチェーンは「新聞」の代わり。群衆が「(出来事の証拠としての)新聞」を発行していくようなイメージ(?)。

ブロック(塊)・チェーン(連鎖)

ブロックは取引(TX)の集まり。取引(TX)は状態の変化の記述(例: 送金)。状態の変化の塊の連鎖。

3つの層があり、コンセンサスのプロトコル、ダイジェスト(ハッシュ値)を格納するブロックの連鎖、デジタル署名によるデータ構造となる。

コンセンサスのプロトコルとしては現実と同期して動く上では問題がある。ダイジェストを格納するブロックの連鎖の構造は想定されていたほど強固ではない。デジタル署名によるデータ構造は有益である。

整合性の担保を確率に頼っている部分があるので、コンセンサスの成立とするには弱い(という私の理解)。

Proof of Work。作業コストを膨大に、検証を容易にすることでスパムや不正行為を抑止する。例えば「先頭20ビットが0になるダイジェストを生成できる乱数」を作る、作成には時間が掛かるがその乱数が条件を満たすかどうかの検証は一瞬で可能である。

取引の改ざんはデジタル署名によって不可能であるが、取引の削除は可能性がある。POWによって改ざん者vs世界という図式を作り、事実上不可能にするという理屈だが…あくまでも事実上であって、改ざん者がタイミングを見計らってコストをつぎ込めばBitcoinが破綻する可能性は存在した(する)といえる。

世界各地の主要金融機関がブロックチェーンの研究・実験をしているらしい。

小さいブロックチェーンは小さいコストで破綻させることが可能である。そもそも小さいなら従来の手法でコンセンサスをとればいい。

分散システムは一貫性・可用性・分断耐性の全ては満たせない。ブロックチェーンは一貫性を確保できていない。例として「ビットコインを支払うと上空のドローンがドリンクを落としてくれるサービス」を考える。ドリンクはいつ落とせばいい?ビットコインの取引は確定するタイミングを予測できない。同時に2つのブロックが成立することがあり、そのうちどちらのブロックが有効であるかは時間が経たないと確定しない仕組みである。そのため現実に当てはめるにはリスク(取引が後で無効になる可能性)をとらなければならない。

ブロックチェーンは不確実性というリスクをとれるのであれば有用であり、可能性がある。しかしそうでないシステムには向いていない。

だがしかし、ブロックチェーンが示した世界には魅力がある。

 

 まとめ

やっぱりデブサミはその場にいるだけでも得るものがあるのではないかと思います:)

社長とか忙しいので行けないとの事だったが、ぜひとも優先順位を上げていただきたい。

モチベーションを頂いたので、得たものを活かして楽しくやっていきたいです:)

他に気になったお話

失敗から学ぶデータ分析グループのチームマネジメント変遷 (デブサミ2016) #devsumi

エンジニアコミュニティで組織は動き出す

【資料公開】強いチームの作り方(デブサミ2016版) | Ryuzee.com

外注が主な企業でどのように内製開発を立ち上げ・進化させているのか?

今日の習慣が明日をつくる~よりよい技術者を目指して~ - Google スライド

プロダクト開発におけるプロダクトマネージャーの役割とは #devsumi‬

YAPC::Asia 2014 に参加してきた #yapcasia

今年もYAPC::Asiaに参加しました。

相変わらずPerlには殆ど触らない生活をしているけど、やっぱり業務で本格的に触った初めての言語だし、有名人もいっぱい見れるし、(ぶっちゃけPerlとか関係ないし、)モチベーションが上がるので参加できるならしようと思ったのです。

Day 1

インフラエンジニア(狭義)は死んだ

  • コードが読めない書けないインフラエンジニア→死。
  • 開発だけやるとか、インフラだけやるとか、もはや通用しない。分業は成立しない。
  • 自分は〇〇エンジニアだから、××はしないみたいな先入観、思い込みはマズイ。それでは問題の解決に臨むときに無意識でブレーキをかけてしまうのでは?

課題を解決したり楽しんだり喜んでもらったりするのが目的じゃないのか?コーディングだけしたりインフラの面倒を見るだけが目的ではないはず。その意識は大事だなと改めて認識出来ました。

完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ

#yapcasia 2014 でシステムとの時間の旅の話をしてきました - さよならインターネット

yapcasia2014 // Speaker Deck

  • スピリチュアル
  • 再現性・簡便性
  • シンプルかつ環境に依存しない
  • 式年遷宮・長屋 どうせ壊れるので、壊しやすく、立て直しやすく、壊れても問題ないようにする

すべてのシステムに共通してすべきこととして、シンプルで、依存が少なくて、壊れても問題ないように保険をかけましょうというお話でした。

シンプルであるべきというのは、1関数〜1システムまで全てに共通する考え方なんだなー。

そして、人は絶対にミスをする(今朝もした)ので、その前提で環境・体制を構築するべきということですね。

Scala In Perl Company : Hatena

Scala in Perl Company という内容で発表しました #yapcasia【YAPC::Asia Tokyo 2014】 - はこべブログ ♨

Scala楽しそうだなーと思いました(小並感

最近は型好き好きなので、興味はアリアリです(Option型があるのも素敵ですよね)

コマンドラインツールについて語るときに僕の語ること

コマンドラインツールについて語るときに僕の語ること #yapcasia // Speaker Deck

  • コマンドのオプションについて、ShortとLongの両方を用意する
  • デフォルトで破壊的動作はしない(破壊的動作はLongで)
  • 対話的な動作をしない(自動化の妨げになる)
  • README.md > Usage > Man の順にユーザは見ていく。ちゃんと用意する
  • 1コマンドでインストールできる
  • デバッグオプションを用意する
  • 1ツールは1つのことだけやる。他のツールと連携できるようにする
  • RDD → README Driven Development

コマンドラインツールでもシンプルであるということは当然大事。

RDDは自分のやりたいことを明確にしてから開発に取り掛かれるし、一番モチベーションのある時にドキュメントを書くことができる。(ドキュメントを書くのは面倒なので、やる気があるうちにやっておくほうが良い。開発自体は楽しいからあとでも大丈夫)

「プロトタイプを手軽に作れる環境を用意すると良い」確かにオプションのパースとか、毎回書くのうざいですよね。

手でおっかなびっくりやるんじゃなくて、都度都度ツールを作ってどんどん楽をしたいですなー。

DeNAが歩んだデプロイ自動化への道

  • 安全工学としてのデプロイ自動化
  • 悪いシステムほど、後になって問題が発見される
  • リリースに困難さを感じるかどうかが、そのシステムの安全性を図る指標のひとつになる
  • 出荷プロセスの見直しは生産システム全体の見直しになる。リリースプロセスの自動化により自浄作用を働かせる

今まさにやりたくてできてないデプロイ自動化。VSでの自動化(特にWindows Forms)を早いとこ成し遂げたい… 

手動でのデプロイがおっかなびっくりでバタバタしてしまっているので、きっちり整えて自動化するのが安全安心というのはすごく納得できるです。

WHERE狙いのキー、ORDER BY狙いのキー

Where狙いのキー、order by狙いのキー

  • インデックスとは、ソート済みのデータの複製(異論はあると思う)
  • WHERE狙いのキー: 条件判定が少ない、残った行をソートする必要がある
  • ORDER BY狙いのキー: ソートはしなくていい、条件判定が残った行分走る
  • ネステッドループジョインは評価する行が倍倍で増えていくので遅すぎる
  • 充分に絞り込めるならWHERE狙い、そうでなければORDER BY狙いが良い

今まで超適当にぼんやりと考えていたインデックスですが、コードでわかりやすく解説していただいたおかげで大分理解が出来たような気がします:)

上っ面だけじゃなくて内部的なこともちゃんと把握できていないとダメなんですよね…;

遅いクエリを速くするのは結構な快感なので、積極的にやっていきたいと思います:)

Lightning Talks Day 1

  • モナドはやっぱりわけわからん
  • デート中にSEGVの原因を考えてブチ切れて振られても結婚出来る
  • PIXIVは全部小文字

LTは話しが早過ぎるので、私の実力ではメモれないし覚えきれません^^;

その分カジュアルに聞けてとても楽しかったです:)

Day 2

突然ITインフラを任された人のための…監視設計入門

突然ITインフラを任された人のための…監視設計入門 #yapcasia

  • レイヤーを分けて整理。外形、デーモン、リソース、サーバ
  • netstatはなくなるからssコマンドを使っていきましょう
  • 誤報慣れ怖い

個人的には今回一番聞けてよかったトークです。

しなきゃいけないのはわかってるサーバ監視だけど具体的に何をすればいいのかが曖昧だったけど、今回それがはっきりしたと思います。ありがたや。

レイヤーに分けて考えるというのがとてもわかりやすくてモヤモヤが解消しました:)

例によってWindows対象の話がなかったですが、それは自分で調べれば出来そうですね:)

半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情(5.6対応)

  • PSRでPHPの世界に秩序をもたらそうとしている
  • PHPはテンプレートエンジンであるが、PHPの中でもっと安全な別のテンプレートエンジンを使うのが常識
  • SPL(Standard PHP Library)でいろいろ便利に
  • モダンなPHPJavaっぽい
  • PHP5.6が出てきた余波で5.3はおしまい。PEARライブラリは消滅の流れ
  • npmのパッケージ数はバグ
  • レールが無いからあっさり崖から落ちる
  • 弾さん「あ、そっか・・・ try-cactchあったんだ・・・」

PHPのトークでYAPCのベストトーク賞1位を獲得するという伝説を打ち立てた素晴らしいトークでした:) そう、YAPC::AsiaはYet Another PHP Conference Asiaだったのです。

触るたびに苦い思いをして避けよう避けようとしているPHPですが、やっぱり避け切れません:( どうせ避けきれないので、ちゃんと最新事情を掴んでおきたいですね:)

Perlあるある

Yapc::Asia 2014 Perlあるある

  • Jcode.pmがめちゃくちゃ懐かしい
  • dan kogaiはエンジニアに愛される方
  • 朝起きた直後が一番集中できる→昼寝を導入する→朝が2度来る!
  • 実は出演者全員77年生まれ
  • コードも作文も同じ。読まれて意味の分からないコードは書かない
  • コードを書くのに許可はいらない
  • 変態たるもの基礎が大事
  • Done is better than perfect

こちらもすごく楽しかったです:)

有名エンジニアの1日のスケジュールはすごく興味深かったですね:) 自分のピークに合わせて効率を上げるというのは、当たり前だけど難しいですね…。

グダグダ言って動かないのではなく、とりあえずコードを書けと。そしてきれいなコードが書けないと言っていつまでも未完成なままにするのではなく、まずは完成させろと。

Lightning Talks Day 2

TDD(Twitter Driven Datsu-Syoshinsya) / Twitter駆動脱初心者 #yapcasia // Speaker Deck

2014 08-30 YAPC::Asia 2014 LT

  • TwitterはWebエンジニアの仕事
  • Twitterで有名な人をフォローするといいよ
  • Twitterやったり、勉強会行くようになってから技術力上がってった気がする
  • メタプログラミング、すなわち魔法
  • 挫折を挫折のままにしない

Twitterで有名な人をフォローするのは本当に有効だと思う。受信できる情報量がすごく増えますよね。仕事中にTwitterは必要です( ー`дー´)キリッ

あと、わからないことをつぶやいたら有名な人から回答が来るのは本当に嬉しいです:)

自分ダメだな~と思っても、勉強会やカンファレンスでモチベーションを得て、有名な人達に引っ張ってもらって、自分も誰かを引っ張れるようになれると良いなと思うです:)

キーノート

  • typester.Jr可愛い
  • 受託開発が楽しい。新しい技術、新しい人に出会える
  • 一度の人生楽しまなきゃ損!
  • ロールモデルを持とう 10年後にどうなってたいか 10年後にどうなりたいか

自分はどうなりたいのか、それを持っていれば何があってもエンジニアとしてやっていけそうです:)

まとめ

2年連続の参加でしたが、今年も存分に楽しめました:) やっぱり勉強会やカンファレンスはなかなか上がってくれない私のモチベーションを大いに高めてくれます:)

YAPC::Asiaは世界で一番大きなYAPCだということで、それに参加できる現状はとてもありがたいと思っています。たまたま一番初めに仕事で触った言語がPerlだったわけですが、それがこんなに価値のあるコミュニティを持つ言語だったことは私にとってとても幸運なことだったのですね:)

きっと来年も開催されて、きっと来年も参加させてもらっていると思います:)

怪我について - #kabepy Advent Calendar 2013 20日目

ボルダリング #kabepy

この記事は #kabepy Advent Calendar 2013 の20日目の記事です。

前日の記事は @takanory さんの 

#kabepy Advent Calendar 2013: #19 Tシャツを作った — takanory.net です!

 

日が登るまでは今日は昨日なのです!(意味不明

 

さて、この記事ではボルダリング(スポーツ)にはつきものの怪我について書きたいと思います。

私自身が11月下旬に結構重い捻挫をしてしまったので、その経験から怪我をした時のために必要なことなど列挙していきます。

(翌日の記事とネタが被り気味な気がしますが、怪我すること自体に焦点を当てることでお許し頂きたいです;)

 

怪我をした時に持っているといいもの

  • お金
  • 助けてくれる友達や家族など
  • 店員さんに助けを求める勇気
  • 晒し者状態になってもくじけない心
お金

皆さん知っての通り、お金は大事です。持っているに越したことはありません。

何をするにしても必要ですが、怪我した時ももちろん必要です。

今回私が捻挫した時に一番お金を使ったのは「交通費」です。

救急車を呼ぶほどの怪我ではない、でも電車に乗って帰れるような状態でもない(職場近くのジムで怪我したので家まで遠い)。仕方ないのでタクシーを使って1万6千円を支払いました;;

他にもシップやら包帯やらテーピングやらで結構使いました、お金重要。

助けてくれる友達や家族など

皆さん知っての通り(ry

包帯やらなんやらを買ってきてもらったり、介抱してもらったり、移動するのに肩を貸してもらったりしました。

店員さんでも助けてくれるというのはもちろんあるのですが、友達や家族の方が気が楽ですし安心できますよね?

登るときは誰かと一緒に行ったほうがいいです、ぼっち危険。

店員さんに助けを求める勇気

怪我というのはいち早く対処しないといけません、恥ずかしいからといって独りで何とかしようとしてもろくな事にならないですし、きっと周りもその方が迷惑です。

特に捻挫の場合はすみやかに患部を冷やす必要があるので、店員さんに氷を用意してもらうのは最優先事項です。

また、今回の私のようにひどい捻挫になると目眩を起こしてしまったりするようなので、横になるスペースと毛布などを確保するためにも店員さんの協力は必須です。

晒し者状態になってもくじけない心

上に書いたとおり、怪我をするといろんな人に協力して貰う必要があります。

必然的に目立ちます、しかも目眩で横になったりしたら、学校のように保健室があるわけでもないので大抵は他のお客さんもいる場所でしょう。

私も何人もの人が通る場所で小1時間ぐらい横になっていました。横目で見ていく人、声をかけてくれる人、色々いらっしゃいましたが人が横になってるのをあえて無視する人は殆どいないので、しばらく晒し者状態です。

恥ずかしいかもしれませんがしかたのないことなので、やっちまった感を味わいつつ耐えましょう。

怪我をしたあと

もちろん整形外科なり整骨院なり行くべきなのですが、私の場合は夜10時にやっちまいましたので、もうやっている時間ではありませんでした。救急窓口などはあるのでしょうが、ひとまず骨に異常はなさそうだったので一旦帰って、翌日整骨院に行きました。

素人判断で怪我の状態をみるのは危険ですが、捻挫であればこのぐらいの対応でも問題なかったようです。

ただし、応急処置はちゃんとしておかないとまずいことになるので、症状に合わせてググりましょう。私の場合は足の捻挫なので足を心臓より高い位置にあげて、氷で冷やしながら一晩過ごしました。

足の怪我の場合は無理をせずにタクシーなどを使って移動しましょう。無理は禁物です。

しばらくはお医者さんの指示に従って治療やリハビリに励むことになりますが、怪我の原因について思いを巡らせ、反省しながら登れない苦しみに耐えましょう。

最後に

締め切り守れなくてスミマセンでしたm(_ _)m

リハビリについては次の記事で書いていただけるようなので、私も参考にさせてもらおうと思っています。