MacOS Catalinaにしたらbash起動時に毎回メッセージが出る件

tl;dr

bash開くたびにzshにしなよって怒られるのうざいからbrewでbash入れ直した

— fumihumi (@_fumihumi) 2019年10月8日

ここはすっ飛ばしても大丈夫。

catalinaからはzshがデフォルトShellになっているとのこと(下記参照) support.apple.com まぁ、それはいいんですが。 いつも使ってる.bashrcとか他のShell対応の移行してないためBashを引き続き使いたいと思い

$ chsh -s /bin/bash

で bashを使うようにすれば、Bashは当然使えますが、↓↓↓↓のようなメッセージが毎回出てきて、正直 邪魔 です

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.

まぁOSとしてzshを標準にしてるんだからそっちを使えって話はわかるんですが、もうちょっとやり方ないのかなとおもったり.........

---

解決策

homebrewでbashを入れてbrewのbashをdefault shellにすることで上記のメッセージから回避できました。

ref: Mac で homebrew の bash をログインシェルにする - Qiita

$ brew install bash
$  echo '/usr/local/bin/bash' | sudo tee -a /etc/shells
// 不安ならcatして末尾に追加されてるかみる
$ chsh -s /usr/local/bin/bash

まぁ当分はBash使う予定の人はこちらで良いのではないでしょうか。

p.s.

zshに乗り換えるなら fish shellに乗り換えたいという気持ちがありつつ、今まで書いてきたbashrcの整理と移行がめんどくさくて踏み切れない。。

fishshell.com

AWS certificate cloud practitionerを受けてみた話

はじめに

夏が終わったような気温になったと思った翌日には30度をこえる猛暑(?)に襲われ、一瞬で体調を崩してしまいました。

こんばんは。最近、TypeScript/ReactNativeでアプリ開発を行なっているfumihumiです。

ReactはHooksが出るか出ないかと騒がれた頃(?)(v15 ~ v16.4)に触って以来に(ちゃんと)触って(学んで)います。 Hooksが正式にExpo(が依存しているRN)でもサポートされたので基本的にはFunctionalComponentを使って開発するようにしています。

最近の悩みはAtomicDesignです。(そのうちブログにまとめたい。)

---

.と、そんなわけで今回の記事はタイトルの通りAWS認定資格のCloudPractionerを受けた話です。

目次

• なんで受けたの。きっかけは？
• どうしてCloudPractionerなの？
• どんな対策したの？
• 受けてみてどうだったの？

---

なんで受けたの。きっかけは？

秋のIPA資格(AP)の申し込み締め切りをすっかり忘れており、見事 申込技術者試験に落ちてしまいなんとなく、体系的に学ぶ機会を失っていたため。 なんとなく(ベンダー)資格を受けて、実力を試してみたい。という欲求がありました。

選択肢として、

• AWS認定資格
• OracleのDB関連の資格
• ruby技術者試験

などが候補にありました。

• ruby技術者試験はだいぶ過去のRubyバージョンを対象にしている試験だったため受けることをやめました。
• Oracleの試験に関しては今まで曖昧に学んできたDB周りの知識を再定着させるという意味でも改めて学ぶのはとても良さそうでしたが、それ以上に自分の中のCloudへの苦手意識をどうにかしたいという思いがあったため今回はAWS認定資格を受けることにしました。
• AWS認定資格の中で開発者向けの資格の一番入門(?)向けの資格だったから選びました。

ref: 学習パス - デベロッパー

この試験により、AWS クラウドについての全体的な理解を持つ人が、業界で広く認知された認定によって、その知識を証明することが可能です。
この試験には、クラウドの概念、セキュリティ、テクノロジー、請求と料金という 4 つの分野があります。

どうしてCloudPractionerなの？

参考までに、受験時の自分がAWSのサービスの中で触ったことがあるのは

EC2, RDS, Route53, S3, CloudFront,
lambda, Elastic BeansTalk, 
securityGroup, IAM..etc

といったようなシンプルな構成で利用するようなサービスしか利用したことがありません。

知識レベルで言えば、概要としてPros/Consを知っているものとして

cloud watch, cloud trail, SQS, SNS, 
dynamoDB, ElasticCache, ELB(ALB), 
ECS, Fargate, VPC, ..etc

というものです。

これらの物は弊学の授業にて行われた、クラウド開発実践(?)という授業内で、

1. 各回の授業でテーマを与えられ*1
2. 構成図を作成
3. 構成のPros/Cons, Cost見積もりや障害対応はどうするのか等を説明する

といったような(割と実践的な構成を検討する)機会があったためこれらの主要サービスについて学び、知ることができていました。

といったようんななんとなくわかってる(つもり)になっていても改めて学習する機会を設けないと知らないサービスを知る機会が少ない && 間違って記憶しているものがあるかもしれない。という思いがあったため、改めて学習する機会にちょうど良さそうな、AWSクラウドプラクティショナー試験を受けてみることにしました。

どんな対策したの？

結論から言えば、クラウドプラクティショナー試験への対策はしていません。

受験を決めてから申込、当日の間に3日しか時間がなかったため取り急ぎ、知らないサービスを抑えないといけないと思い、次の書籍を読んでいました。 徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略シリーズ | 鳥谷部 昭寛, 宮口 光平, 菖蒲淳司 | 工学 | Kindleストア | Amazon

クラウドプラクティショナーとソリューションアーキテクトでの範囲はあまり変化はないため問題ないだろうと思いこちらを選択しました。

基本的には概念の部分は読んでみてPros/Consは実際のアーキテクチャと一緒に 'どんなときに採用するのか'に焦点を当ててみていました。

教科書と書いてある通り、解説はかなりわかりやすく、すんなりと読むことができました。 3日前に買ったこともあり、読み終えたのは試験前夜になってしまいましたが、最後まで読んでよかったなと思います。 特に '料金と請求'の分野は普段コストの見積もりを元にアーキテクチャを検討する機会が全くないためこの部分を知れたのはよかったです。（試験ではこの範囲が見事に爆死したが。）

受けてみてどうだったの？

結果から言えば合格しました :tada: スコア的にはある程度余裕を持って合格はしたのですが、 先ほど記載してように '料金と請求'の項目があまり正答率がよくなかったみたいです。 その他の項目 (クラウドの概念 | テクノロジー | セキュリティ)に関してはスコアレポート的には "十分な知識を有する"と分類されていました。一安心....

感想

数年前にFEを受けたときに感じましたが、資格試験に向けて勉強をすると :money_with_wings: を出していることもあり、落ちて受験して2倍の金額を払うことに若干のプレッシャーがあることや、締め切り(受験日)が明確に設けられているため学習スケジュールが組みやすい。なと感じました。受験まで3日しかないのでスケジュールなんてなく、本を読んで本にある問題を解くだけだったっが、

卒業までに "AWS 認定デベロッパー アソシエイト"*2に挑戦したいな、とぼんやり検討しています。

久しぶりに資格試験を受けたらどっと疲れた

— fumihumi (@_fumihumi) 2019年8月28日

*1:オンプレのサービスをクラウドに移行するといったテーマや、新規サービスとしてECサイトを構築するというテーマ等

*2:AWS 認定デベロッパー – アソシエイト

react nativeのImage読み込みが遅くてつらい

react nativeで画像の読み込みがなぜかおそい

表題の件で悩んでいました。

docs.expo.io Imageコンポーネント使っていい感じにやれば、良さそうで、

< Image source={require('../../assets/sample.png')} />

っていう風にやれば良いらしい。

これの通りに書いてはいるんですが、なぜか読み込みに数秒かかったりするんですよねw

いろいろ調べてみたんですが、画像の読み込みが遅い というような悩みを抱えてる人がほとんどいなかったw

唯一みつけたのが↓これ forums.expo.io

---

↑のリンクとExampleのコードに 'Asset.loadAsync'を利用すれば良いというような文面をみたため

github.com

↑この Asset.loadAsyncの中に画像ファイルを置くことで解決しました。

:thinking:

きっと画像を扱う際の初歩の話なのでどこにもまとまってなかったのかなとか思ったのでめも程度に書き留めたいと思いました。

2018の振り返りしてみる

2018の振り返り

• 2018の振り返り
• いろいろ感じたこと
• 来年の目標とか

みたいなことを書いていこうかなと思います。

1月

• 昨年から引き続きアルバイトでプログラミング教室のメンターをしたりしてた
• 昨年12月よりPythonと数学を学び始め、’統計や機械学習’といった分野の入門をしていたりしました
  • 短期間で本格的に学ぶことはできなかたですが、基礎的な概念を学ぶことができたのはよかったのかなと思っています

2月

• iOSの学習をし、簡単なアプリであればなんとなく作れる程度に。
• Webフロントエンド（React）を改めて学び始め、React,SPA,PWAといったモダンなものを知った。
• 冬休みということもあり時間が取れそうだったためスタートアップの会社にてインターンを始めました

3月

• 前述した会社とは別にアルバイトとして働き始める

4月

• 学校にてプログラミングサークル(Make IT)を設立
  • プログラミングを教えたり

5月

• 初めて逆求人イベントに参加
  • 知らなかった企業の魅力を知ることもできた。
  • サマーインターンのお誘いをもらうこともできた。
  • 他の参加学生から多くの刺激をもらった
• JOBLISTのRailsを5.2.0にバージョンアップしました - Rista Tech Blog

6月

• サマーインターンの面接とか。
  • 面接や面談をとおして自分が求めている会社、環境とかを改めて考えたり

7月

• サマーインターンの面接とか
• (これといって何もしてないw)

8月

• エイチーム3Daysエンジニアサマーインターンシップ予選に参加した！ - fumihumiのブログ
  • 2020年卒業生向けにサマーインターンシップの募集を開始！ | 株式会社エイチーム（Ateam）
• AkatsukiのサマーインターンServerSonic2018に参加しました！ - fumihumiのブログ
  • Server Sonic 2018｜アカツキ新卒採用2020｜採用情報｜株式会社アカツキ（Akatsuki Inc.)
• 2月にインターン始めたスタートアップのサービスのクローズと同時に退社
  • 自分のエンジニアとしての今後の道や、サービスへの考え方を見つけることができた。

9月

• 4~7: コロプラのサマーインターンに参加
  • 高負荷対策エンジニアリングインターンシップ【サーバーサイドエンジニア向け】｜コロプラインターンシップ2018
    • 新規機能の追加と追加した既存機能を改善していくインターンだった。
    • ペアのメンバーに迷惑をかけまくってしまった。phpつらい
• 9: Git Challenge参加
  • mixi GROUP presents「git challenge」 - NAVER まとめ
  • 人並みにgitがつかえるつもりだったが最後の方の問題が全く解けなかった。奥が深い。
  • ペアのtakemioくんがすごかった（語彙力）ということもあり同率３位というそれなりの結果になった
• 10~12: ceresの３Daysインターン参加: 株式会社セレス3daysインターン.team-B
  • 新規サービスの考え方、ビジネス的な観点を学べた
  • 短期間での開発辛かった
• isuconの予選参加
  • 圧倒的力不足

10月

• エイチームインターンシップSembatsu本戦参加
  • 2020年卒業生向けにサマーインターンシップの募集を開始！ | 株式会社エイチーム（Ateam）
  • GitHub - fumihumi/mag
  • いろいろブレストとかしたりしてたらめっちゃ通話してた
  • サービス作るの楽しかった（最後の１週間が辛かった）
  • 楽しかった

11月

• BugShootingContestに参加
  • mixi GROUP presents「Bug Shooting Challenge」 - NAVER まとめ
  • 学生対象 不具合調査体験ワークショップのご紹介 – mixi developers – Medium
  • ミクシィChallengeがひとつできるまで - Bug Shooting Challenge #1 を終えて - オフトゥン大好き。
• 専門学校[横浜ｆカレッジ]公式ブログ ｜ ファッション・美容・メイク・ブライダル・ジュエリーのプロになる！: ファッション＆ビューティーライブ2018
  • 姉妹校のイベントで使う投票サイトをMakeITメンバーで作成
    • GitHub - fumihumi/f_college_sns
• サマーインターンなどでお世話になった人と面談させてもらったり、進路などに悩み始めたり。

12月

• 就活するために面談させてもらったり。
• 同時に就活したり。

---

振り返ってみて

端的に言えばエンジニアとしての成長、またサービス開発全般において１つ前に成長できたなと感じています。 サーバサイドやフロントエンド、どちらもまだ未熟ですが昨年に比べれば大きく前に進めたのかなと感じており、 以前は曖昧だったことも今ではちゃんとわかる様になったことが多くなりました。

サービス開発全般。というとよくわからない感じになっていますが、

1. アイデア
2. ビジネス
3. 開発（設計、手法、機能開発、デプロイ、保守）

こういったことに関して今まで以上に関わることが多かったです。

スタートアップの会社ではサービスの開発と同時に改善などに関わることができました。 また、サービスにとってクリティカルなバグを生んでしまったり、機能開発に携われたり、それ以上にサービスについて真剣に考えたり。といった様なことに挑戦できたのはとても良い経験になっていると感じています。

サマーインターンでもアイデア出しから開発というサービス開発において大事な部分を実践で学ぶことができました。 また、他の参加者からは個性的な人が多く、色々な意味で多くの刺激をもらうことができました。 （忘年会の時期は終わってしまったが、久しぶりに会いたいなとか思ったり。）

Akatsuki。コロプラさんのサマーインターン、isuconではサーバサイドエンジニアとしての挑戦、そして自分に足りないもの等を身を以てしれたと感じてます。 実際にエンジニアとしって働くためにはこれらのイベントで体感し、改善したことを挑戦し続けなければいけないと思うと、不安に感じることが多いですが、もっと学び、これらに対応できる様になりたいと感じています。 来年こそisuconでそれなりの結果出したい。 （惨敗した）

参加したイベントの直後にブログを書こう書こうとおもってたら複数のイベント終わってて、 9月の末にまとめて書こうとしてたら気づいたら九月がおわってて、 気づいたら年末になってた。（つらい）

---

来年は

来年は自分の道を決定し、その道に進むためにいろいろ頑張っていきたいです。 まず進路の確定。自分がどの会社でなら自分らしく働けるのかをしっかり考えたいと思ってます。

また、今まではWeb系の技術に触れていましたが、モバイル開発を再度しっかり学び直したいとも感じています。 インターンやイベントでアプリの開発にした方が良い場面が何度かあったのにも関わらず、僕の力不足でWebにしたこともあるため、自分都合での選択肢を減らすことがない様にしたいなと思っています。

情報が錯綜する世界の中で頑張る(生き残る)ために...

Make IT アドベントカレンダー25日目、最終日の投稿です。

Make IT アドベントカレンダー 2018もそろそろ終わりを迎えます。
サークルのメンバーでアドベントカレンダーをやってみよう！
とのことで始まりましたが
- 「情報を発信することの意義」
- 「人に伝えることの難しさ」
が後輩に伝わったのであれば、このアドベントカレンダーは大団円です。

昨日 @haduki1208が上記のように書いてくれましたが、改めて

• 情報の発信
• 伝えること
• 情報の収集

といったようなことについて技術ポエムを書こうと思います。

--ここから余談--

そもそも今回のアドベントカレンダーですが、

みたいな雑な感じで投げたら翌日に作成され、初日を持ってかれた次第です。:sob:

11月頭の時点では、割と早い段階でカレンダー登録をしている企業様が多く、

すごいメンツの中

というような表現になってた（と記憶してます そんな感じで提案翌日にはノリと勢いでカレンダーが作成され日程を埋めていった感じです。

---

改めてですが、本カレンダーを作成してるMake ITって'?????'ですが,私たちは情報科学専門学校の技術サークルです。

一言で言えば、プログラミングの楽しさを追求しわくわくするものづくりをしていくサークルです。*1

本サークル(Make IT)は今年より活動を始めたのでこれから何をしていくのか。といったようなことはまだ明確になっていません。まさに今検討をしている最中です。

ざっくりと説明しますと - ものづくり、プログラミングの楽しさを知ること - 技術を楽しく学べるようになること といったようなことをしているサークルです。（2回目w）

私自身がプログラミングを始めたときは弊学の先生に

1. 親身に教わり、
2. プログラム組むことの楽しさを知って、
3. コンテスト等に出たりして
4. 楽しくなってまた勉強する
5. １に戻る

みたいなことをしていました. こういったことをいい感じに広めたいという思い、今は活動していて、来年も多分続けます。

-余談終わり-

情報の発信や、情報を人に伝えること。また人に質問すること。といったことについて書いていきたいと思います

「情報を発信することの意義」

プログラミングを学んだりするとすでに発信されている情報の恩恵を受けることが多いと思います。最近だとQiitaやMedium,Note,hatenaといった様な媒体の記事がSEO的にも強く、〇〇 hogehoge 実装とかで調べるだけでサンプル実装が出てきたりします。 また、概念の様なものを調べたりする場合、（TDD,DDD...ex）といったものでも前述した媒体の記事を見かけることが多いのではないのでしょうか。

人はなぜこういった媒体に発信をするのか。 私も以前まではこういった媒体は１人の情報収集者として使うことが多かったです。

自分自身発信者としては未熟ですが発信することには以下の様なメリットがあると感じています。

• Blogが自分の価値になることもある
• 情報を発信しようとする際にまとめる必要があるため、ある程度の知識が必要になる
• 実際に公開しなくとも自分と向き合うことができる
• （いろいろ頑張れば）稼ぐことも可能

ブログ。という形を例に記載していますが媒体は、自作のブログでもいいですし、既存媒体に頼ってもいいと思います。

1. 情報を発信しようとする際にまとめる必要があるため、ある程度の知識が必要になる
2. 実際に公開しなくとも自分と向き合うことができる

この二つは特に、他者のためでなく自分自身のためにも実践する価値があるのかなと思います。

曖昧なことを改めて文章にまとめて見ようとすると、

• 自分がわかった気になってたことが改めてわかる
• 本当にわからないことを改めて調べる機会になる
• また、まとめようとすることの周辺知識も必要になる

こういったことを学ぶ（まとめる）機会になるため一歩成長できるのではないかとおもっています。

個人で開発していることや、最近学んだこと、興味のあることについてまとめ、それを発信してみてはいかがでしょうか？ 仮に自信がないのであればそれはPublicに公開せずに手元にメモとして残すこともオススメです。 半年、１年後に改めて見返すと自分の成長や、過去の自分の考えなどについて改めて知るきっかけになることがあります。

「人に伝えることの難しさ」

上記の様な、まとめることをしたものを他人に伝えることはまた別なものですよね。 人に読んでもらうための文章と、人に聞いてもらう文章では構成が違いますよね？ そういったl人に伝えること。というのはとても難しいなと感じています。(めっちゃ苦手)

ただ自分は以下の様な方法を取ることで自分のことを相手に伝え、相手に自分が欲している回答を答えてもらうことができる様になるのかなと感じています。

1. 自分の状況をまとめる
   • 過去：今まで何をしてきたのか
   • 今：何をしようとしているのか
   • 未来：これから何をしようとしているのか
2. 相手に求めているものをまとめる
   • 直接的回答
   • 比喩的回答(ヒント）
   • あくまでも相談相手になってほしいのか こういったことをメモした上で、

〇〇をしようとしているんですが。（前提）
××をしようとした際に想定外の'hogehoge'な感じになってしまっているのでヒントいただけませんか？
他にも
”fugafuga”, "piyopiyo"の様なことも試したのですが、’ほげほげ’になってしまっていました。
(相談してもらう)

の様にまとめていると事前に自分の中で相談内容がまとまります。 (内容が次項に被るため次に記載します)

「人にたずねること」

前述した内容にかぶりますが 自分より詳しい人に、知恵を借りるために質問をする。こういったことはとても大事だと思っています。 自分自身で解決に１h以上かけてしまうようなことであっても自分より詳しい人であれば即答、もしくはヒントを提供してくれるかもしれません。

ただ、この’回答’にたどり着くためには、いまの自分の状態を正しく伝え、自分が欲していることに関しても伝えなければなりません。 この質問をする。というのは初回の質問のハードルはとても低いですが、 （ここでいうハードルが低いというのは’〇〇がわからないので教えてください。’というレベル感をさします。） その先の質問された人（以下回答者）にとってはとても答えづらい質問になっています。 前項に記載した様なスタイルで質問をしたらお互いがWin-Winになれると思うので自分なりの質問Formatを作成して質問をしてみてはいかがでしょうか。

先日見かけたQiitaの記事を貼っておきます。

• 【プログラミング質問方法のすゝめ】質問する事にためらいのあるすべての人へ - Qiita
• 新卒からの質問をソシャゲっぽい仕組みにしたら捗った話 - Qiita

情報を集める力(情報を見抜く力)

私が普段、新しい情報をキャッチアップするために行なっていることについて簡単に描きたいなと思います。

極端な例ですが、１年前には最新だったことも今では少し古いものになったり、他の’何か’が出てきて手段が複数になっていたりということもあり得るのではないでしょうか。 （実際にあるかどうかはわからないです）

こういったことが起きる可能性がある以上、私たち技術者（やそれに近い人）は常に新しい情報をWatchすることが大事だと思っています。 すぐに自分がその技術やその話題を活用することがなくとも、半年後、数年後にはその技術に触れることがあるかもしれません。そういった技術傾向や最新話題をWatchするのは将来的にみても良い投資時間だと思っています。

以下が普段自分が使っている媒体です。

• slack, discordの様なコミュニティチーム
• medium, dev.to, qiitaのDaily投稿や、自分が気にしているTagのFeed
• はてブの最新投稿
• その他、企業のTechBlog等
• Twitter(OSS committerさんとか)

こういったものを朝の電車や帰りの電車、また暇な時に見る様にしています。 技術書による、inputも大事にはしていますが、今の私にとってはこういった生きている情報をもらうことの方が勉強になるし面白い話題を知るきっかけになるため楽しく読んでいます。 （あと英語を読む練習にもなりますねw）

p.s 自分が読んだ媒体をいい感じにメモっていい感じに見返す媒体がほしいんですが。オススメありませんか。

---

以上でMake IT AdventCalender最終日の投稿情報が錯綜する世界の中で頑張る(生き残る)ために...を終了します。 最後まで読んでいただきありがとうございました。

*1:めっちゃ雑

pry-railsでRuby(Rails)を探索する話

pry-rails/binding.pry 使ってますかー

私。pry-railsが好きです。 めっちゃ使いやすい。 javascriptのdebuggerも好きなんですが、それ以上に個人的にRails開発でのpryが好きなのでそれについて書こうと思っています。

はい というわけでMakeIT AdventCalendar 8日目pry-railsでRuby(Rails app)を探索する話で投稿したいとおもいます。 前回ポエム書いちゃったので2回目は技術的な何かに触れないとねw 明日は @ymzk-jp がGitのHEADとは何者なのかを投稿してくれるはずです。

./bin/rails c とか binding.pry の話

個人的な話ですが、pry-rails。最初はすごい使いにくくてエラーに遭遇してから原因調査をして、 問題箇所を修正するみたいな開発をすることが多かったなと感じています。

ただ、pry（以下デバッガ）をある程度使えるといい感じにアプリ開発が進むなと感じました。 そのため、よく使うメソッドをまとめたいなと思います

Rails始めた人とかRails使ってるけどデバッガ使わない人に届いたら嬉しいですね。

今回モデルケースにするのは↓のようなものです。

1] pry(main)>
[2] pry(main)> show-models
   (1.5ms)  SET NAMES utf8,  @@SESSION.sql_mode = CONCAT(CONCAT(@@sql_mode, ',STRICT_ALL_TABLES'), ',NO_AUTO_VALUE_ON_ZERO'),  @@SESSION.sql_auto_is_null = 0, @@SESSION.wait_timeout = 2147483
ApplicationRecord
  Table doesn't exist

Comment
  id: integer
  user_id: integer
  post_id: integer
  body: string
  created_at: datetime
  updated_at: datetime
  belongs_to :post
  belongs_to :user
Post
  id: integer
  title: string
  body: text
  published: boolean # statusって名前にすれば良かったと後悔してます
  user_id: integer
  created_at: datetime
  updated_at: datetime
  belongs_to :user
User
  id: integer
  nickname: string
  email: string
  password_digest: string
  created_at: datetime
  updated_at: datetime
  has_many :comments
  has_many :posts

みたいなものを使ってた時。を想定して話していきたいなと思います。

---

rubyは全てがオブジェクト

突然ですがいわゆるclass,moduleなども一つのオブジェクトとなります。 オブジェクトであれば - 当然メソッド持っています - ほとんどの場合クラス本体もしくは、なにかのインスタンスであるでしょう。 - またそのクラスorインスタンスはほとんどの場合親クラスが存在しています といったことを念頭に起いた状態で次のコードを見てください

[1] pry(main)> self
=> main
[2] pry(main)> ls
ActiveSupport::ToJsonWithActiveSupportEncoder#methods: to_json
Rails::ConsoleMethods#methods: app  controller  helper  new_session  reload!
self.methods: inspect  to_s
locals: _  __  _dir_  _ex_  _file_  _in_  _out_  _pry_

[3] pry(main)> cd app
[4] pry(#<ActionDispatch::Integration::Session>):1> self
=> #<ActionDispatch::Integration::Session:0x00007fd184305860
 @_mock_session=nil,
 @_routes=nil,
 @accept="text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5",
 @app=
  #<SampleApp::Application:0x00007fd180ab8c28
   @_all_autoload_paths=

デバッガ起動直後のselfは main （オブジェクト？）を参照しています。(わからんw)

rubyの実行

ここ（デバッガ）ではirb同様Rubyを実行することができます

Ex) fizzbuzz

[42] pry(main)> 100.times{|n| puts n % 15 == 0 ? 'fizzbuzz' : n % 5 == 0 ? 'fizz' : n % 3 == 0 ? 'buzz' : n }

Railsでの使い方

Rubyの使い方はあまり触れずに今回はRailsの使い方を。 先ほど cdをしましたが。 bash使ってれば察すると思いますが、 lsもありそうですよね。

[47] pry(main)> self
=> main
[48] pry(main)> ls
ActiveSupport::ToJsonWithActiveSupportEncoder#methods: to_json
Rails::ConsoleMethods#methods: app  controller  helper  new_session  reload!
self.methods: inspect  to_s
instance variables: @app_integration_instance  @controller
locals: _  __  _dir_  _ex_  _file_  _in_  _out_  _pry_
[49] pry(main)>

cd, ls

ここでいうlsは’self’のオブジェクトがもっている（利用可能な）メソッドを羅列してくれます。

例えば今回のモデルである'Post'クラスや’Post’のインスタンスに潜ってlsをしてみようと思います

[70] pry(main):1> cd Post
[85] pry(Post):2> self
=> Post(id: integer, title: string, body: text, published: boolean, user_id: integer, created_at: datetime, updated_at: datetime)

こうするとPostクラスに移動した状態です 基本的に、今いる参照先(currentなオブジェクト?)を確認する際は'self'を使う、もしくは'プロンプト'の表示項目 "[82] pry(Post)"を確認する などをすると思います

[82] pry(Post):2> ls
Object.methods: yaml_tag
ActiveModel::Naming#methods: model_name
ActiveSupport::Benchmarkable#methods: benchmark
ActiveSupport::DescendantsTracker#methods: descendants  direct_descendants
ActiveRecord::ConnectionHandling#methods:
  clear_active_connections!  clear_reloadable_connections!  connection_config              connection_specification_name=  mysql2_connection
  clear_all_connections!     connected?                     connection_pool                establish_connection            remove_connection
  clear_cache!               connection                     connection_specification_name  flush_idle_connections!         retrieve_connection
ActiveRecord::QueryCache::ClassMethods#methods: cache  uncached
ActiveRecord::Querying#methods:
  any?          distinct     find_each
  #--------省略-----------------
  Post.methods: __callbacks  _reflections  _validators  attribute_type_decorations  defined_enums  draft  published  publisheds
Post#methods: autosave_associated_records_for_user  belongs_to_counter_cache_after_update
...etc

例えば、モデルクラスであるPost、ここで'ls'をするとRailsのモデルが持ってるメソッドが全て表示されます。 破線の後半にある Post.methodsの部分はPostクラスにて定義したものが表示されます さらに、自身の定義したメソッドを見る場合はいくつか方法があります

• object#methods.grep() #-> tab押すと予測がでる
• object#find-method #-> Recursively search for a method within a Class/Module or the current namespace.
• ls --grep #-> Show the list of vars and methods in the current scope., # Exclude -q, -v and --grep because they,

だそうです。 使ってる感じはこちら

おすすめは メソッド名がある程度わかってるのであれば、ls --grepを使う。 そうでないのであれば methods.grep(:hog) -> hogを含んでるメソッドをタブで予測表示される という使い分けです。

appオブジェクト

デバッガーではappオブジェクトなるものにアクセスすることができます appオブジェクトを経由することでURLヘルパー、pathヘルパー、またリクエストを送ることが可能です URLhelperといえば $./bin/rake routesを使う人やhttp://localhost:3000/rails/info/routesを使う人は多いのではないでしょうか？

これらの確認はこのデバッガでも可能です

[138] pry(main)> show-routes
                   Prefix Verb   URI Pattern                                                                              Controller#Action
                    users GET    /users(.:format)                                                                         users#index
                          POST   /users(.:format)                                                                         users#create
                 new_user GET    /users/new(.:format)                                                                     users#new
                edit_user GET    /users/:id/edit(.:format)                                                                users#edit
                     user GET    /users/:id(.:format)                                                                     users#show
                          PATCH  /users/:id(.:format)                                                                     users#update
                          PUT    /users/:id(.:format)                                                                     users#update
                          DELETE /users/:id(.:format)                                                                     users#destroy
                    posts GET    /posts(.:format)                                                                         posts#index
                          POST   /posts(.:format)                                                                         posts#create
                 new_post GET    /posts/new(.:format)                                                                     posts#new
                edit_post GET    /posts/:id/edit(.:format)

またこのRoutingコマンドに関しても先の'ls'で確認したようにGrepを使えます

[144] pry(main)> show-routes --grep post
                    posts GET    /posts(.:format)                                                                         posts#index
                          POST   /posts(.:format)                                                                         posts#create
                 new_post GET    /posts/new(.:format)                                                                     posts#new
                edit_post GET    /posts/:id/edit(.:format)

そのほかにも。RouteをControllerごとに見るのであれば

[39] pry(main)> find-route Post
Routes for PostsController
--
index GET /posts(.:format)  [posts]
create POST /posts(.:format)
new GET /posts/new(.:format)  [new_post]
edit GET /posts/:id/edit(.:format)  [edit_post]
show GET /posts/:id(.:format)  [post]
update PATCH /posts/:id(.:format)
update PUT /posts/:id(.:format)
destroy DELETE /posts/:id(.:format)

というわけで、実際に調べた posts_path, new_post_pathなどの確認や、リクエストをしてみたいと思います。

[161] pry(main)> app.posts_path
=> "/posts"
[162] pry(main)> app.new_post_path
=> "/posts/new"
[163] pry(main)> app.post_path(1)
=> "/posts/1"
# このように生成されたRouteの確認ができますね。
# 実際にpost_pathにreqしてみると
[177] pry(main)> app.get app.posts_path
Started GET "/posts" for 127.0.0.1 at 2018-12-08 20:02:01 +0900
   (0.9ms)  SELECT `schema_migrations`.`version` FROM `schema_migrations` ORDER BY `schema_migrations`.`version` ASC
Processing by PostsController#index as HTML
  Rendering posts/index.html.erb within layouts/application
  Post Load (1.3ms)  SELECT `posts`.* FROM `posts`
  Rendered posts/index.html.erb within layouts/application (206.8ms)
Completed 200 OK in 533ms (Views: 503.4ms | ActiveRecord: 2.7ms)

=> 200
[200] pry(main)> res = app.response
# res.bodyとするとSSRされたHTMLが見れます

[227] pry(main)> app.request.params
=> {"controller"=>"posts", "action"=>"index"}
[228] pry(main)> app.request.headers
=> header情報
[229] pry(main)> app.controller.class
=> PostsController

といったようなリクエストを送信することもできます。

helperオブジェクト

railsで開発してるとメソッドの切り出しなどにHelperを使うことがあると思います。 そういったときのHelperもデバッガーにて確認することが可能です。

module ApplicationHelper
  def hello_world
    puts 'hello world'
  end
end

例えばこんな感じのHelperがあると

[4] pry(main)> helper.hello_world
hello world
=> nil

このように呼ぶことが可能です。 他にも今まで同様

[21] pry(main)> cd ApplicationHelper
[22] pry(ApplicationHelper):1> self
=> ApplicationHelper
[23] pry(ApplicationHelper):1> ls
ApplicationHelper#methods: hello_world
locals: _  __  _dir_  _ex_  _file_  _in_  _out_  _pry_
[24] pry(ApplicationHelper):1> show-method hello_world

From: /Users/fumihumi/project/sample_app/app/helpers/application_helper.rb @ line 2:
Owner: ApplicationHelper
Visibility: public
Number of lines: 3

def hello_world
  puts 'hello world'
end

という形で参照することができます ここでHelperメソッドを呼び出したい場合は

[38] pry(ApplicationHelper):1> show-source self

From: /Users/fumihumi/project/sample_app/app/helpers/application_helper.rb @ line 1:
Module name: ApplicationHelper
Number of lines: 9

module ApplicationHelper
  def hello_world
    puts 'hello world'
  end

  def self.public_world
    puts 'class method hello'
  end
end
[39] pry(ApplicationHelper):1> public_world
class method hello
=> nil
[40] pry(ApplicationHelper):1> hello_world
NameError: undefined local variable or method `hello_world' for ApplicationHelper:Module
from (pry):14:in `__binding__'

一時的にクラスメソッドにする。、もしくは mainを参照している状態でhelper.hello_worldとします。

show-method（show-source）

これはメソッドの定義を見ることができます たとえばshow-routesをみてみると

[64] pry(main)> show-source show-routes

From: /Users/fumihumi/project/sample_app/vendor/bundle/gems/pry-rails-0.3.8/lib/pry-rails/commands/show_routes.rb
Number of lines: 76

class PryRails::ShowRoutes < Pry::ClassCommand
  match 'show-routes'
  group 'Rails'
  description 'Show all routes in match order.'
  banner <<-BANNER
    Usage: show-routes [-G]
    show-routes displays the current Rails app's routes.
  BANNER

  def options(opt)
    opt.on :G, "grep", "Filter output by regular expression",
           :argument => true,
           :as => Array
  end
  ...etc

のようになっており、DescとOptionの存在を知ることができますね。 他にも自分が定義しているメソッドなども参照ができます。

edit

これは引数に渡したメソッドがVimで(?)起動がされます。 多分'.pryrc'で設定できるはず GIFにしましたがまぁこんな感じでみれるということです。

reload

editorなどでアプリのモデル等を編集したらreload!をすることでアプリを再読み込みすることができます。 ただ、時々意図しない感じな挙動になることがある？気がするのでおかしくなったら'exit'した方がいいかと思います。

watch

4] pry(main)> hoge = 'hoge'
=> "hoge"
[15] pry(main)> fuga = 'fuga'
=> "fuga"
[16] pry(main)> watch hoge
Watching hoge
watch: hoge => "hoge"
[17] pry(main)> watch fuga
Watching fuga
watch: fuga => "fuga"
[18] pry(main)> hoge = 'ww'
watch: hoge => "ww"
=> "ww"
[20] pry(main)> foo ='foo'
=> "foo"
[21] pry(main)> foo << 'ee'
=> "fooee"
[23] pry(main)> fuga << 'ee'
watch: fuga => "fugaee"
=> "fugaee"

watchを使うとWatchで指定した変数が変更があったときにwatch: <before> => <after>で教えてくれます

hist

名前の通りHistoryをみせてくれます。 これもGrepができます

[48] pry(main)> hist --grep find
20: show-method find-route
21: find-route Post
23: find-route Post

便利。w

ActiveRecord

user = User.last
user.posts.published.to_sql
=> "SELECT `posts`.* FROM `posts` WHERE `posts`.`user_id` = 10 AND `posts`.`published` = 1"
# to_sqlメソッドでこれから吐かれるSQLをみれる

[100] pry(main)> (Date.today..Date.tomorrow).to_s(:db)
=> "BETWEEN '2018-12-08' AND '2018-12-09'"
# 引用：http://thr3a.hatenablog.com/entry/20181206/1544099172

[106] pry(main)> user.posts.published.new
=> #<Post:0x00007fd184778208 id: nil, title: nil, body: nil, published: "published", user_id: 10, created_at: nil, updated_at: nil>
# user.posts.new -> user_id == user.id
# user.posts.publisdhed.new -> published: publishedな状態でnewできる

ActiveRecord周りの便利な使い方はSQLを考えながら書くといい感じに描けそうですね わたしはまだまだダメなのでもっと頑張りたいところの一つです。

model, DB構造

[92] pry(main)> show-model User
User
  id: integer
  nickname: string
  email: string
  password_digest: string
  created_at: datetime
  updated_at: datetime
  has_many :comments
  has_many :posts

のようにするとモデルのColumnなどを把握することができます

shell-mode

[130] pry(main)> shell-mode
pry main:/Users/fumihumi/project/sample_app $

と、なんかプロンプトが変わりますが操作が変わる感じはあまりしてません。 どうやって使うのか知ってたら教えていただきたいです...

つらつらと書いてきましたがこんな感じでデバッガー一つとっても複雑なことがたくさんできます。 こういった使い方もあくまでも一つの使い方だと思いますし、もっと便利な方法があるのかもしれません。 自分のデバッガーの使い方を見つけておくとよりよいプログラミングになるのかなとか思ったりしています。 もっと自由自在に使いこなせるようになりたいですね。

以上でAdventCalendar8日目を終わりにしたいと思います。最後まで読んでいただきありがとうございます。 メモ書きのような文章になってしまい申し訳ありませんw

私がLintを愛する３つの理由

Lint好きですか？？？

普段はRuby、JavaScriptを利用しているfumihumiです。 最近はTypeScriptが楽しくなってきました。

突然ですが、 私はLintが好きです。 初めてLintを導入する時ってちょっとしたルールについて揉めたりしませんか？？？？（した） リアル（現実）の揉め事なんかちっちゃく感じるくらいLintからもらえる恩恵って大きいと思っています。

はい。

というわけで MakeIT AdventCalendar 2日目は技術ポエムで投稿したいとおもいます。 明日は @wh1tecat が投稿してくれるはz...

ところでこのカレンダー5日分ほど空いてしまっている様ですね。 きっといい記事を納めてくれる人がいることを僕は信じたいとおもいます... :thinking: せっかくなので全日程埋めたい！！！！！！！！！

まぁ余談はこの程度にして、

lintを導入することで得られる恩恵とその効能について考えてみたいなと。

と、いうのもLintって基本的にカッチカチに設定した方がいいと考えてる私の設定ファイルでCIを回していると学校でLintを使ってる時に

のような意見をもらったので改めて考えてみたいなと思って考えていたことをあらためてまとめていきたいとおもいました

ところで皆さんはLintのルールってどの程度の粒度で設定していますか？？？？？

例えば、JavaScriptなら

const bool = true;

// ver 1
if(bool){return;}
// ver 2
if (bool) {return;}
// ver 3
if (bool) { return; }

のように if一つとっても↑みたいにかけますよね？？？？？？ これらのルールってどうやって決めてますか？？？？？？

他にも疑問になりがちな

• 文末セミコロン
• ブレース前後のスペース
• 同じく丸括弧前後のスペース
• 文章のシングル(ダブル)クォーテーション

これらのルールって決めた方がいいのでしょうか？

先に自分の結論から言うとルールは硬い方が良いんじゃないでしょうか？？？？？

ルールを決める

細かいルールはルールを考える人、Lintを導入する人、もしくはチームで相談すると思いますが、例えば

• クォーテーションに関して であれば私は '式展開が不可能な方' && 'US配列で打ちやすい'という理由からシングルクォーテションを採用しています。
• インデントはスペースを使ったりとしています。

ただ、こういった細かいルールに関しては開発者およびコーディング担当者は気にする必要ってないと私は思っています。 とは言ってもコード書くときに意識しないと怒られが発生しますよね？w

ただ、そういった怒られ案件(ストレス)っていい感じに回避できそうだとは思いませんか？ そうです。 EditorConfig や エディターの拡張機能たちを使えばそういったことが可能です。 私はVSCodeを利用していますが、tslint, stylelint,prettierの様な拡張機能、editorConfigといったものも導入することでストレスが少なく開発に専念することに成功しています。

これらは保存時にいい感じに整形する様な設定を加えることができる（もしかしたら他の拡張機能かも）のでコードを書く際はほとんどストレスがなく開発することができます。 また細かいLintのバグはCLIから tslint **.ts --fixの様にすることでAutoCollectができますね（めっちゃ便利

なので今回はこういった細かいルールについてではなくその他のルールについて考えていきたいなと思っています。 基本的な設定はeslint:allもしくはeslint:recommended これのどちらかを採用し、そこから好みに応じてルールを緩和するのが良いと思っています。

...本題からそれてしまいましたが、

私がLintを好む３つの理由について話したいと思います。

• 自身のコーディングを規制することができる
• チームとしてコードに統一感を持たせることができる
• 潜在的なエラー(バグ)を潰すことができる

Lintの導入にはこの様な３つのメリットがあると思っています。

それぞれについて掘っていくと。

自身のコーディングを規制することができる

これは

• 独学で学んでいる人
• いろいろな言語に触れていてその言語特有の書き方に慣れていない人
• レビューされる機会がなく各々のコーディングになってしまう人

といった人に対して抜群の効果を発揮します。

自分がそうなのですが、プログラミング初めてまもない頃はすごい適当にコードを書いてしまい、可読性が抜群に悪かったり、動くプログラムを雑に書いてしまったり、という様なことが起きていました。

こういった

• 可読性が悪い
• とりあえず動くコード（汚い処理）
• 言語特有の書き方でなくぱっと見読みづらい

という事象をLintの活用で避けることができます。

ね？Lint便利でしょ？

チームとしてコードに統一感を持たせることができる

複数人で開発を始めると当然の様に人それぞれの好み（インデント・ブレース・カンマ）などで宗教戦争が発生しますよね。（？しますよね）

こういったものを前述した

• EditorConfig
• Linter
• Editor設定（Extension）

を活用することでいい感じにすることができます

おすすめはVScodeとLint,EditorConfigの活用です。気になる方はググってください。

ね？Lint便利でしょ？

潜在的なエラー(バグ)を潰すことができる

Lintを活用することで潜在的なエラーを消すことができます。 未宣言の変数の利用や、本来もってないメソッドを使った時に怒られたり、といったことがLintによってできます。 (これがかなり便利なわけですがいい例えが思い浮かびませんでしたw。）

と、いうわけでいい感じにコードを書くために硬いLintと一緒に生活するのはいかがですか？？？ （雑すぎるまとめ方）

ね？Lint便利でしょ？

番外編：lintをCIと活用する

LintはCircleCIやTravisCIのようなCIツールと一緒に使うとよりよい Lint人生を歩けます

CIツールの設定はいい感じに調べてみれば出てくると思います。

その中でも私のオススメは他人のGitHubからパクることですね。 選択肢としては、 1. 知り合いのGitHubのRepoを漁る。GitHubの検索を活用する。 2. もしくはググって導入事例と設定ファイルを見つける。

などなどをすると良いと思います。

私もそうでしたが、CircleCIの設定は最初は難しく感じがちですが、 他人の設定を真似するとかなり楽に設定することができます。 毎回手元のTerminal（CMD)でLintの実行することもできますが、GitHubなどにPushした際を発火材にしてLintを実行することができます。 またCIツール使うことのメリットはLintだけでなくテストの実行などもテスト環境から行うこともできる様になりますよね。 初めてのCIでテストは難しいかもしれませんがテストも楽しいので明日から！楽しいCI人生を歩きましょう？！

ね？Lint便利でしょ？

まだLint入れてない人は 新規ISSUEに Lint入れたい てやってみてはいかがでしょうか？？？？ きっと考えている人が他にもいるはずです。　良いLintライフを！

---

さてお粗末な文章となってしまいましたが MakeIT AdventCalendar 2日目は@fumihumiが担当しました。

この記事をみてLintを好きになってもらえたら嬉しいですねw 明日もMakeIT AdventCalendarを楽しみにしていてください！