「RailsGirlsTokyo 12th」でスポンサーLTをしてきました
こんにちは！
BBQの匂いだけで白飯が食べられるのか挑戦しようとしているよっぴです!
もし一緒に挑戦したいよって人がいたらコッソリ教えてください。
さてさて！つい先日、「RailsGirlsTokyo 12th」というイベントでスポンサーLTをしてきたので、そのことについて書いていきたいと思います。
RailsGirlsってなに？
「Rails Girlsは女性がプログラミングを理解するための道具を提供することを目的にしています。自分が作ったRailsアプリをインターネット上に公開するという、これまでにない経験をしてもらうのがRails Girlsです。」
と公式ホームページ( http://railsgirls.jp/ )に書いてあります。
簡単に言うと、プログラミングに興味のあるGirlsがコーチからRailsを教えてもらい、プログラミングの楽しさを知ってもらおう！というイベントです。
実際にイベントに行ってみて
コーチ1人対してGirlsが1人or2人という贅沢な割合！
コーチがホワイトボードに図を書きながら説明してくれたりと、プログラミングに初めて触れた人でも理解しやすいようにかなり工夫されていました:star:
そして、女性のためのイベントだったからか、全てが可愛くて驚きです！
今回のRailsGirlsTokyo 12thのロゴがこちら。
夏祭りがテーマだったらしく、この女の子は焼きとうもろこしとチョコバナナを持っています。
オリジナルデザインのチロルチョコがあったり
懇親会のお酒まで可愛かったです！
また、コーチの中に私が読んだことのある技術書の作者の方がいて、「すごく分かりやすかったです。ありがとうございました。」と感謝の気持ちを伝えることができました！
そしてそして、Ruby / Railsコミッターの松田さんからありがた〜いお話が聞けたりと、ものすごく素敵なイベントでした。
スポンサーLTをやってみて
今回が人生初のLTだったので、手が震えてしまうほど緊張していました。しかし、聞いている方達がリアクションをとってくれたり、笑ってくれたりとものすごい暖かい会場だったので、LTをやっているときはすごく楽しかったです。
LTでは
・私がエンジニアになった理由
・エンジニアになってよかったこと
などを話してきました。
人前で話すことに対して苦手意識を持っていましたが、これからは積極的に色んなところでLTをやっていきたいと思います！
まとめ
実は、一年ほど前に行われたRailsGirlsTokyo 10thにGirlsとして応募したのですが、落選してしまい参加できなかったので、今回スポンサーLT枠として参加できて嬉しかったです！
これからエンジニアを目指そうとしている人たちに「LTを聞いて勇気をもらえました」と言ってもらえたり、コーチの人たちから「LTよかったよ！これからも頑張ってね」と言ってもらえたりと、参加してよかったと思えたイベントでした。
次回こそはコーチとして参加できるようにこれからも勉強頑張ります！
最後になりましたが、今回LTをするにあたりアドバイスをしてくださった方々にはとても感謝しています。
楽しくLTをできたのも皆様のアドバイスがあったからです！
ありがとうございました。
【技術書メモ9】入門者のLinux
技術書めも9冊目φ(･･
今回は「入門者のLinux」を読みました。
コマンドの意味もわからずコピペばかりだったなぁと反省しているので、今回はLinuxの本を読んでみました。
この本は入門書でわかりやすかったです。これをベースに次はもう少し難しい本を読んでいきたいです！
LInuxとは
コンピューターの基本ソフトの一種。
Linuxは世の中のほとんどのコンピューターに載っている。
→Linuxを知れば多種多様なコンピューターを駆使する能力の基礎を獲得できる。
コマンドに引数やオプションをつける
コマンドに続けて色々な情報を添えて打ち込むことで、多様な動きをする。
Unixのコマンドでは、半角スペースが意味の区切りになる。
コマンド本体に続けて半角スペースを空けて添える情報のことを引数と呼ぶ。（パラメータとも呼ぶ）
ハイフンに何かの記号を続ける形で表現する指示を「オプション」と呼ぶ。
コマンドにオプションを与えることで、コマンドの機能を変えることができる。
パイプで出力と入力をつなげてしまおう！
$ echo 2+3 | bc
本来は「echo 2+3」というコマンドは「2+3」という文字列を画面に出す。
しかし、そのコマンドに続いて「| bc」とすると、「echo 2+3」の結果、すなわち「2+3」という文字列は画面に表示されず、その代わりに「bc」というコマンドに渡される。そして、「bc」コマンドはそれを受け取り、計算を行った結果を出力する。
このように、「|」という記号を挟んで複数のコマンドを連結すれば、「|」直前のコマンドが出す出力を、「|」の直後のコマンド入力にするということができる。
このような機能のことや、特にそれを実現する「|」のことを「パイプ」と呼ぶ。
管理者、またの名はroot
Unixでは管理業務に携わるユーザーを一人決めて、その人だけに全権を委任する。それが「管理者」である。
管理者はすべてのファイルやディレクトリへのアクセス権をもつ。
通常、管理者はrootというユーザー名を持つ。
管理者（root）以外のユーザーのことを一般ユーザーと呼ぶ。
システムの根幹に何らかの変更を加えるには、rootにお願いする必要がある。
そこで使うのが「sudo」コマンド
「root」の権限が必要なコマンドを「sudo」コマンド経由で実行させることができる。
sudo→switch user and doの略語
定番のテキストエディターvi
viは極め付きの頑固者、だけど慣れれば頼もしい味方。
Unixにはviよりも直感的に操作しやすいemacsというもう一つの老舗のテキストエディターがある。
しかし、なぜviを学ぶのかというと、viはどんなUnixにも入っているとてもよく枯れたソフトだから。
また、GUIのテキストエディターは便利だが、GUIは多くの資源（メモリや計算性能）を必要とするので、それらが使いにくい環境（手のひらサイズの小さなマシンやネットワーク越しに接続されたマシン、どこかが故障しかけて瀕死の状態のマシン）では使えない。その点、viはCUIで動くし、とても軽いので有利。
また、viは巨大なファイルも編集できる。他の多くのテキストエディターは対象となるファイル全てをメモリに読み込まなければいけないため、巨大なファイルを扱う時にフリーズしたり停止したりすることがある。
viはそういうことがあまりない。10万行もあるテキストファイルの後半5万行を削除するなどということもviならサクッとできてしまう。
Linux力はインストール回数に比例する
Linuxには色々なディストリビューションがあり、1つのディストリビューションの中にも色々なバージョンや派生形があり、そして、色々なインストール法がある。それらを色々なソフトウェアに対して試してみると、Linuxの多様性を肌で感じられると同時に、多くのスタイルのLinuxに共通する概念や仕組みに関しても理解が深まる。
【技術書メモ8】プロを目指す人のためのRuby入門
技術書めも8冊目φ(･･
今回は「プロを目指す人のためのRuby入門」を読みました。（通称：チェリー本🍒）
説明文の後に必ず例となるコードが書いてあったので、文章で読んで理解できなくても、コードを見ることで理解できました！
また、正しい使い方だけではなく、避けた方がいい使い方なども書いてあったので、注意すべき点が明確になり分かりやすかったです。
配列と繰り返し処理を理解する
・ブロックとは
メソッドの引数として渡すことができる処理のかたまり。ブロック内で記述した処理は必要に応じてメソッドから呼び出される。
Rubyでは「要件を問わず共通する処理」はメソッド自身に、「要件によって異なる処理」はブロックに分担させて1つの処理を完成させるメソッドが数多く用意されている。
例
eachメソッドの役割は、配列の要素を最初から最後まで順番に取り出すこと。しかし、取り出した要素をどう扱うかはその時の要件で変わってくる。
そこで登場するのがブロック。配列の要素を順番に取り出す作業はeachメソッドで行い、その要素をどう扱うかはブロックに記述する。
・配列に初期値を設定する場合の注意点
コード例
a = Array.new(5, ‘default’)
a #=>[“default”, “default”, “default”, “default”, "default"]
str = a[0]
str #=> “default”
str.upcase!
str #=> “DAFAULT”
a #=>[“DEFAULT”, “DEFAULT”, “DEFAULT”, “DEFAULT”, “DEFAULT”]
このように、配列の要素全てが大文字に変わってしまう！
これは、配列の全要素が全て同じ文字列オブジェクトを参照しているために発生する問題。
「同じ値で同一のオブジェクト」なのか、「同じ値で異なるオブジェクト」なのか意識してコードを書かないと、思わぬ不具合になってしまうことがある。
ハッシュやシンボルを理解する
・シンボルの特徴と主な要素
表面上は文字列っぽいので、プログラマにとって理解しやすい
内部的には整数なので、コンピューターは高速に処理できる
同じシンボルは同じオブジェクトであるため、メモリの使用効率がいい
イミュータブルなので、勝手に値が変えられる心配がない
クラスの作成を理解する
・equal?
このメソッドはobject_idが等しい場合に、trueを返す。つまり、全く同じインスタンスかどうかを判断する場合に使う。
・eql?
このメソッドはハッシュのキーとして2つのオブジェクトが等しいかどうかを判断する。
モジュールを理解する
・モジュールの用途
継承を使わずにクラスにインスタンスメソッドを追加する。もしくは上書きする（ミックスイン）
複数のクラスに対して共通の特異メソッド（クラスメソッド）を追加する
クラス名や定数名の衝突を防ぐために名前空間を作る
関数的メソッドを定義する
シングルトンオブジェクトのように扱って設定値などを保持する
また、モジュールにはクラスと違って次のような特徴がある
・モジュールから」インスタンスを作成することはできない
・他のモジュールやクラスを継承することはできない
・モジュールに特異メソッドを定義する
includeやextendを使うとモジュールのメソッドをクラスにミックスインすることができる。
しかし、場合によってはわざわざ他のクラスに組み込まなくてもモジュール単体でそのメソッドを呼び出したい、と思うケースがある。
こういう場合はモジュール自身に特異メソッドを定義すれば直接”モジュール名.メソッド名”という形でメソッドを呼び出すことができる。
・module_functionメソッド
ミックスインとしても使えて、なおかつモジュールの特異メソッドとしても使えるメソッドを定義する場合は、module_functionメソッドを使って、対象のメソッド名を指定する。
ミックスインとしても、モジュールの特異メソッドしても使えるメソッドのことをモジュール関数と呼ぶ。
module_functionでモジュール関数となったメソッドは、他のクラスにミックスインすると自動的にprivateメソッドになる。
例外処理を理解する
・例外オブジェクトから情報を取得する
messageメソッドは例外発生時のエラーメッセージを返し、backtraceメソッドはバックトレース情報（つまりメソッドの呼び出し履歴）を配列にして返す。
・例外クラスの継承関係を理解する
rescue節に何も指定しなかった場合に捕捉されるのはStandardErrorとそのサブクラスである。
StandardErrorクラスは通常のプログラムで発生する可能性の高い例外を表すクラス。NoMemoryErrorやSystemExitなどStandardErrorを継承していない例外クラスは捕捉されない。
・意図的に例外を発生させる
コードの中で意図的に例外を発生させるためには、raiseメソッドを使う。
Raiseメソッドに文字列を渡すと。その文字列がエラーメッセージになる。
・rescueしたら情報を残す
あとで原因調査ができるように例外時の状況を確実に記録に残す。
例外をrescueしたらその場で情報を残さないと詳細な情報が失われてしまう。
最低でも、例外のクラス名、エラーメッセージ、バックトレースの3つはログやターミナルに出力すべき。
Rubyに関するその他のトピック
Railsのような巨大なプロジェクトになてくると、一度にたくさんのgemを組み合わせてプログラムを構築する。
その各々が正常に動く組み合わせを持っているため、使用するgemが増えるとgem同士の適切な依存関係はあっという間に人間で管理できなくなってしまう。
そこで登場したのがBundlerである。Bundlerを使うと、開発プロジェクトごとにgemの依存関係を適切に管理してくれる。
・エラーや不具合に対処する方法
最終手段！パソコンの前から離れる。
例
トイレに行く
飲み物を買いに行く
外を散歩する
昼寝する
ご飯を食べる
お風呂に入る
その日はもう寝る
【技術書メモ7】Webを支える技術
技術書メモ7冊目！
いろんな方におすすめされる有名な本を読みました📕
RESTやHTTPについて曖昧だったので、読んで良かったです。
第1章 Webとは何か
・HTTP、URI、HTML
Webを支える最も基本的な技術はHTTP、URI、HTMLである。
URI⇨ショッピングサイトの商品でも、学術論文でも、あらゆる情報を指し示せる
HTML⇨上記の情報を表現する文書フォーマット
HTTP⇨プロトコル。上記の情報を取得したり発注したりする。
第2章 Webの歴史
・Webの成功の一因は、必要最低限のリンク機能だけを備えていたから。逆にWeb以前のハイパーメディアの問題点は、その複雑さにあった。
・オープンで不特定多数を相手にするのがWeb。各ユーザーのコンピュータ環境は特定のOSやハードウェアには統一されておらず、様々なブラウザやデバイスから1つのWebサービスにアクセスできる。これは、クライアントとサーバ間のインターフェースをHTTPというシンプルなプロトコルで固定したことで実現できている。
・RESTが普及していくのと並行して、Webはインターネット全体を飲み込み始める。以前の地図ソフトでは、地図をローカルのハードディスクにインストールして利用していたが、この方法では1台のPCにインストールできるだけのデータしか扱えない。しかし、現在の地図サービスでは、全世界の衛星写真と地図をいつでも最新の状態で利用できる。これは、サーバ側で地図を保管し、必要に応じてダウンロードしているので、実現できている。
第3章 REST WEBのアーキテクチャスタイル
・RESTはWebのアーキテクチャスタイル。システムは具体的なアーキテクチャを持っている。そのアーキテクチャを設計するときに、ただ闇雲に作っていくのではなく、アーキテクチャ設計の指針、作法、流儀、つまり、アーキテクチャスタイルを適用する。システムのアーキテクチャを決定する際の羅針盤となるのがアーキテクチャスタイル。
※アーキテクチャとは
ソフトウェアを設計するにあたり、最も必要であるのが機能や性能の全体像と製品本体の構成要素のバランス。「ソフトウェアアーキテクチャ」はそれぞれの役割を関係性を考慮しながら、ソフトウェアを設計していくより良いスタイルを指している。
・リソース
RESTにおける重要な概念の1つにリソースがある。
リソースとはWeb上に存在する情報
世界中の無数のリソースはそれぞれURIで一意の名前を持つ
URIを用いることでプログラムはリソースが表現する情報にアクセスできる
第4章 URIの仕様
・ベースURIを明示的に指定する方法
WebページをHTMLとして保存した時に、そのHTMLファイルがもともとどのURIだったのかは通常わからない。この問題を解決するために、<head>要素の中に<base>要素を入れる。
・URIの長さ制限
使用上はURIの長さに制限はないが、実装上は制限が存在する。特に、にInternetExplorerはバージョンを問わず2,038バイトまでという制限があり、事実上この長さに合わせて実装することが多くなる。
・URIの実装で気をつけること
第５章 URIの設計
・URIはリソースを表現する名詞にする
・URIを変更したい時
どうしてもURIを変更したいときは、できる限りリダイレクトをするようにする。
第６章 HTTPの基本
・クライアントとサーバ
・HTTPメッセージ
リクエストメッセージとレスポンスメッセージをまとめて「HTTPメッセージ」と呼ぶ。
・ステートレスの利点
ステートレスでは、クライアントがリクエストメッセージに必要な情報をすべて含める。
ステートレスなサーバはアプリケーション状態を覚える必要がないため、サーバ側のシステムは単純になる。
・ステートレスの欠点
パフォーマンスの低下
送信するデータ量が多くなる
認証など、サーバに負担がかかる処理を繰り返す
通信エラーへの対処
第7章 HTTPメソッド
・POST
POSTには3つの役割がある。
子リソースの作成
リソースへのデータの追加
他のメソッドでは対応できない処理
・べき等性と安全性
べき等性⇨ある操作を何回行っても結果が同じこと
安全⇨操作対象のリソースの状態を変化させないこと
・安全でもべき等性でもないPOST
POSTはリクエストの結果で何が起こるかわからない。クライアントはPOSTを複数回送ることに慎重でなければならない。
第8章 ステータスコード
・ステータスコードの分類と意味
1xx:処理中
2xx:成功
3xx:リダイレクト
4xx:クライアントエラー
5xx:サーバエラー
・よく使われるステータスコード
200 OK リクエスト成功
301 Moved Permanently リソースの恒久的な移動
400 Bad Request リクエストの間違い
第9章 HTTPヘッダ
・認証
あるリソースにアクセス制限がかかっている場合、ステータスコード401 UnauthorizedとWWWAuthenticateヘッダを利用して、クライアントにリソースへのアクセスに必要な認証情報を通知できる。
ユーザ名とパスワードによる認証方式。ユーザ名とパスワードをAuthorizationヘッダに入れてリクエストごとに送信する。Authorizationヘッダの内容は、認証方式に続けてBase64エンコードした文字列になる。
Base64エンコードした文字列は簡単にデコード可能である。すなわち、ユーザ名パスワードが平文でネットワーク上を流れていることを意味する。Basic認証を使う場合は、それが許される程度のセキュリティコードで良いのかを検討しなければならない。
・Digest認証
ただし、パスワードを暗号化するだけなので、メッセージ自体は平文でネットワーク上を流れる。メッセージを暗号化したいときはHTTPSを利用する。
・キャッシュ
サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法のこと。
第10章 HTML
・フォーム
フォームはターゲットとなるURIを待つ。
その時に用いるメソッドは<form>要素のmethod属性で指定する。この属性の値はGETまたはPOSTになる。
・ハイパーメディアとしてのHTML
HTTPとURI、そしてハイパーメディアによるリンクの組み合わせで初めてwebが成り立つ。HTMLでリンクを設計する際は「リンクをたどることでアプリケーションの状態が遷移する」ことを強く意識する。
第11章 microformats
HTMLの中でさらに意味のあるデータを表現するための技術がmicroformatsである。
・microformatsの標準化
microformatsはHTML文書そのものにメタデータを埋め込む技術である。microformatsは「より簡単に、もっと気軽にwebページのセマンティクスを記述できるようにしよう」という目的のもと、様々なメタデータ記述の仕様を策定している。
・リソース表現としてのmicroformats
第12章 Atom
AtomSyndicationFormatは、RFC4287が規定するXMLフォーマットである。
第13章 AtomPublishingProtocol
このプロトコルを採用すると、ブラウザ以外のWebクライアントからブログを投稿したり、システム同士を連携したりといったことが簡単にできるようになる。
第14章 JSON
・JSONとは何か
JavaScriotの記法でデータを記述できるのが最大の特徴。
・クロスドメイン通信の制限
複数のドメインサーバと通信できず、単一のドメインのみと通信をしなければならないのは大きな制限。例えば、自サービスでは地図データと郵便番号データを保持せずに、それらを提供している他のWeb APIから適宜取得することができないから。
・<script>要素による解決法
HTMLの<acript>要素を用いると、複数のサイトからJavaScriptファイルを読み込める。
・コールバック関数を活用するJSONP
JSONPは、ブラウザの子の性質を利用してクロスドメイン通信を実現する手法。JSONPではオリジナルのJSONをクライアントが指定したコールバックを関数名でラップして、ドメインの異なるサーバからデータを取得する。
第15章 読み取り専用のWebサービスの設計
・リソース設計とは何か
第16章 書き込み可能なWebサービスの設計
・書き込み可能なWebサービスの難しさ
読み取り専用のWebサービスに比べると、考えなくてはいけないことがたくさんある。
たとえば、複数のユーザが同時に書き込みをしたらどうなるのか、複数の処理手順を実行するにはどうしたらいいか、など。
・リソースの削除
一般的には、親リソースに従属する子リソースは、親リソースの削除に伴って削除するべき。例えば、ブログエントリを削除した場合、そこに付随するコメント群を削除するのが一般的。
大量の郵便番号を作成したり更新したりする場合は、リクエストを一回一回送信すると、サーバへの接続回数が多くなり、パフォーマンスが問題になることがある。このようなときは、作成、更新したいリソースを一括で送信（バッチ処理）できるようにWebサービスを実装する。
・バッチ処理のレスポンス
問題になるのが、エラーが起きた時の対処方法。エラーが起きた時の対処法としては2つある。
2つめは、どのリソースの処理が成功して、どのリソースの処理が失敗したのかをクライアントに伝えること。
【技術書メモ6】オブジェクト指向設計 実践ガイド
技術書メモ6冊目📝
今回は「オブジェクト指向設計 実践ガイド」を読みました。
実際にコードでの具体的な説明がありました。
身近な自転車を例にしていたので理解しやすかったです！
- 第1章 オブジェクト指向設計
- 第2章 単一責任のクラスを設計する
- 第3章 依存関係を管理する
- 第4章 柔軟なインターフェースを作る
- 第5章 ダックタイピングでコストを削減する
- 第6章 継承によって振る舞いを獲得する
- 第7章 モジュールでロールの振る舞いを共有する
- 第8章 コンポジションでオブジェクトを組み合わせる
- 第9章 費用効果の高いテストを設計する
第1章 オブジェクト指向設計
オブジェクト設計指向とは「依存関係を管理すること」。設計がないと、管理されていない依存関係が大混乱を引き起こす。
設計の目的は「後にでも」設計をできるようにすることであり、その第一の目標は変更コストの削減。
（オブジェクト指向のアプリケーションはオブジェクトとオブジェクト間で交わされるメッセージから構成される。
その2つのうち、メッセージの方がより重要。）
・オブジェクト指向の導入
Rubyではデータと振る舞いを2つの独立した両者が決して出会うことのない領域に分けることはしない。代わりにその2つのオブジェクトを1つの「オブジェクト」にまとめる。
Rubyのようなクラスベースのオブジェクト指向言語では「クラス」を定義できる。クラスは似たようなオブジェクトの構造の設計図になる。
クラスでは「メソッド」と「属性」を定義する。
第2章 単一責任のクラスを設計する
・メソッドをグループに分けクラスにまとめる
どんなクラスを作るかによりそのアプリケーションに対する考え方が永久に変わる。
アプリケーションに変更が必要な時が来た時、それらに変更を加えられるかどうかはアプリケーションの設計によって決まる。
・なぜ単一責任が重要なのか
変更が簡単なアプリケーションは再利用が簡単なクラスから構成される。
2つ以上の責任を持つクラスは簡単には再利用できない。変更が加わるたびに、そのクラスに依存するクラスを全て破壊する可能性がある。
・クラスが単一責任かどうかを見極める
1文でクラスを説明してみる。考え付く限り短い説明に「それと」が含まれていれば、おそらくクラスは2つ以上の責任を負っている。
・データでなく振る舞いに依存する
単一責任のクラスを作れば、どんな些細な振る舞いもそれぞれがただ一箇所のみに存在するようになる。振る舞いにどんな変更があっても、だた1箇所のコードを変更するだけで実現できる。
・単一責任のメソッドがもたらす効果
隠蔽されていた性質を明らかにする
クラス内のメソッドを他のクラスに再編する意図はないときでも、それぞれのメソッドが単一の目的を果たすようにすることによって、クラス全体が行うことがより明確になる。
コメントをする必要がない
もしメソッド内のコードにコメントが必要ならば、そのコードを別のメソッドに抽出する。その新しいメソッドの名前が当初のコメントの目的を果たす。
再利用を促進する
小さなメソッドは健康的なコードの書き方を促進する。他のプログラマーはコードの複製ではなく、再利用をするようになる。
他のクラスへの移動が簡単
いくつものリファクタリングやメソッドの抽出をしなくても。振る舞いの再構成が可能になる。
第3章 依存関係を管理する
・オブジェクト間の結合
依存関係があることで、これら複数のオブジェクトはあたかも1つのオブジェクトであるかのように振る舞うようになる。
つまり、変更は同時にやってくる！
・依存を隔離する
もし不必要な依存を除去できないなら、クラス内で隔離するべき。
依存は外からの侵略者であり、コードの脆さを表している。それゆえ、依存は簡潔、明示的であり、隔離されるべき。
クラス名の依存関係が簡潔明瞭で、隔離されているアプリケーションは柔軟性がなく、新しい要求に対し簡単に対応できる。
第4章 柔軟なインターフェースを作る
・パブリックインターフェース
クラスの主要な責任を明らかにする
外部から変更されることはない
気まぐれに変更されない
他者がそこに依存しても安全
テストで完全に文書化されている
・プライベートインターフェース
実装の詳細に関わる
他のオブジェクトから送られてくることは想定されていない
どんな理由でも変更され得る
他者がそこに依存するのは危険
テストでは言及されないこともある
・責任、依存関係、そしてインターフェース
クラスのうちパブリックな部分は安定した部分でもある。対して、プライベートな部分は変化し得る部分。
他のクラスのプライベートメソッドに依存することを決める時には、本質的に不安定な何かに依存していることを理解し、関係ない変更にも影響を受けるリスクが増えることも知った上で行わなければならない。
・パブリックインターフェースに含まれるメソッドは次のようであるべき
明示的にパブリックインターフェースだと特定できる
「どのように」よりも「何を」になっている
名前は考えられる限り、変わり得ないものである
オプション引数としてハッシュをとる
第5章 ダックタイピングでコストを削減する
・ダックタイピングを理解する
Rubyにおけるオブジェクトの振る舞いについての一連の想定は、パブリックインターフェースへの信頼という形で行われる。もしあるオブジェクトが他のオブジェクトの型を知っていれば、どのメッセージにそのオブジェクトが応答できるかを知っていることになる。
・ダックタイピングの影響
具象的なコードは理解は簡単だが、拡張にはコストが伴う。抽象的なコードは最初は分かりにくさは増すかもしれないが、一度理解をしてしまえばはるかに変更しやすい。ダックタイプを使うことで、コードは具象的なものから抽象的なものへと変わっていく。拡張はより簡単になるものの、ダックの根底にあるクラスは覆い隠される。
・ポリモーフィズムとは
多岐にわたるオブジェクトが同じメッセージ応答できる能力。メッセージの送り手は受け手のクラスを気にする必要がなく、受け手はそれぞれが独自化した振る舞いを提供する。それゆえ、1つのメッセージが多くの形態を持つ。
・静的型付けの特徴
可視化された型情報は文書の役割も果たしてくれる
コンパイルされたコードは最適化され、高速に動作する
・動的型付けの特徴
コードは逐次実行され、動的に読み込まれる。そのため、コンパイル/makeサイクルがない
ソースコードは明示的な型情報を含まない
メタプログラミングがより簡単
第6章 継承によって振る舞いを獲得する
・継承を選択する
継承によって2つのオブジェクトが関係を持つように定義できる。その関係によって1つ目のオブジェクトがメッセージを受け取り、それが理解できないものだった場合、自動的に転送、つまり移譲を行い、そのメッセージを2つ目のオブジェクトに渡せるようになる。
・抽象を見つける
継承が効果を発揮するためには次の2つのことが常に成立している必要がある。第一に、モデル化しているオブジェクトが一般-特殊の関係をしっかりと持っていること。第二に、正しいコーディングテクニックを使っていること。このルールを破る時は危険を覚悟する。
・スーパークラスとサブクラス間の結合度を理解する
他のクラスについての知識を持つということは依存を作り、依存はオブジェクトを互いに結合する。
サブクラスがsuperを送る時、これは事実上、そのアルゴリズムを知っているという宣言。つまりサブクラスに「依存」している。アルゴリズムに変更があれば、たとえサブクラスで特化していること自体に変更はなかったとしても、サブクラスは途端に壊れてしまう。
・フックメッセージを使ってサブクラスを疎結合にする
上の問題の解決方法は、サブクラスにアルゴリズムを知ることを許し、superを送るよう求めるのではなく、スーパークラスが代わりに「フック」メッセージを送るようにすることができるようになる。これにより、サブクラスからアルゴリズムの知識は取り除かれ、代わりにスーパークラスに制御を戻すことができる。
第7章 モジュールでロールの振る舞いを共有する
・メソッド探索の仕組み
オブジェクトがメッセージを受け取ると、オブジェクト指向言語はまずオブジェクトの「クラス」を見に行き、合致するメソッドを探索する。
このように、メソッドの探索はメッセージを受け取ったオブジェクトのクラスから始まる。このクラスがそのメッセージを実装していなければ、探索はそのクラスのスーパークラスへと移る。
1つ目は、オブジェクトがtypeやcategoryという変数名を使い、どんなメッセージをselfに送るかを決めているパターン。この場合、わずかに型の異なるオブジェクトが含まれているため、新たな型を追加するたびにコードも変更しなければならない。
このようなコードは、共通のコードを抽象スーパークラスにおき、サブクラスを使って異なる型を作る。
2つ目は、メッセージを受け取るオブジェクトのクラスを確認してから、どのメッセージを送るかを決めているパターン。このようにしてしまうと、メンテナンスの際、受け取る側のオブジェクトを増やすたびに、毎回コードを変更せねばならない。この場合、受け手になり得るオブジェクトはどれも共通のロールを担っているので、このロールはダックタイプとしてコードに落とし込まれるべき。
第8章 コンポジションでオブジェクトを組み合わせる
・コンポジションとは
組み合わされた全体が単なる部品の集合以上となるように、個別の部品を複雑な全体へと組み合わせる行為。
・継承による影響を認める
階層構造は「利用性が高い」。簡単に新しくサブクラスを作って新しい変種に適応できる。
継承を使う際の懸念は2つ。1つ目は、継承が適さない問題に対して誤って継承を選択してしまうこと。この間違いを犯すと、新たに振る舞いを追加したいのに、簡単に追加できる方法が全くない未来。2つ目は、問題に対して継承の適用が妥当であったとしても、自分が書いているコードが他のプログラマーによって全く予期していなかった目的に使われるかもしれないこと。
・コンポジションの影響を認める
利点
コードが簡単に理解でき、変更が起きた場合に何が起こるかが明確ということ。また、コンポーズされたオブジェクトはほんのわずかなコードしか継承せず、それゆえ、それより上の階層構造にあるクラスへの変更によって生じる副作用に悩まれることは一般的にない。
コスト
それぞれの部品は小さく簡単に理解できるものでも、組み合わせられた全体の動作は理解しやすいとは言えない。
組み立てのルールを規定するにはとても優れているが、ほぼ同一なパーツが集まっているコードを構成する問題に対しては、そこまでの助けにならない。
第9章 費用効果の高いテストを設計する
・テストの意図を知る
バグを見つける
仕様書となる
設計の決定を遅らせる
抽象を支える
設計の欠陥を明らかにする
・テスト中ではプライベートメソッドを無視する
無視する理由
1つ目は、そのようなテストは冗長だから。プライベートメソッドはパブリックメソッドによって実行され、パブリックメソッドは「すでにテストされている」。
2つ目に、プライベートメソッドは不安定。プライベートメソッドのテストは、アプリケーションコードの変わりやすいところへの結合。
3つ目に、プライベートメソッドのテストを行うことで、他のメソッドがそれらを間違って使ってしまうことになりかねない。テストはプライベートメソッドを隠すべき、晒すべきではない。
【技術書メモ5】プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原則
技術書メモ5冊目！
今回は、よいコードとはどのようなものか、よいコードを書くためにはどうしたらいいのかが書いてあるこちらの本を読みました！
今までは動くことが目的になっていて、よいコードについてあまり意識をしたことがなかったので、この本に書いてあったことを念頭に置いてコードを書いていきたいです。
まだ知識不足なので、半年後に読んだらまた新しい発見がたくさんありそうな本！
第1章 前提
・プログラミングに特効薬はない
ソフトウェアは本質的に困難であるので、歴史を学び地道に改善していく。
⇨物事には「本質的」な面と、「偶有的」な面があり、偶有的な部分は容易に改善することができる。偶有的な部分を見つけたら自動化して本質的な部分にできるだけ時間を割けるようにしていく。
・コードは必ず変更される
コードが変更されるという前提で行うようにする。
書いている時間よりも読んでいる時間の方がはるかに長くなる。
⇨変更されるという視点に立つと、書くのにどれだけ時間がかかっても読む時間を短縮できるなら十分に元を取ることができる。
第2章 原則
・コードをシンプルに保つ
コードは自然に任せて修正していくと、無秩序になり複雑になっていく。
⇨プログラミング中、「動作させるためにもっとシンプルなものは何か」と常に問いかけることが大切。
・DRY（繰り返すな）
コードのコピペは厳禁である
コードに重複があると障害修正や機能追加など、コードを改善していくことが困難になる。
⇨コードを抽象化することによって重複を排除する。そのために、処理のまとまりに名前をつけて「関数化」「モジュール化」する。
・コードの意図を伝える
コードだけがソフトウェアの動作を「正確に」「完全に」知るための手がかりである。
⇨コードを書くときには「書きやすさ」より「読みやすさ」を重視する。読みやすければ書くときの効率が多少落ちたとしてもそれに見合う価値がある。
・コードで命名は最重要課題
名前はコードを読む人へのユーザーインターフェース。適切に名前がつけられているコードは「何を」「どのように」やっているか明確に理解できる。
⇨コードはまず名前を決める。名前を短いコメントとして考えると伝えるべき情報が含まれやすくなる。
名前には「効果」と「目的」を説明し、「手段」には言及しない。
第3章 思想
・コードはコミュニケーションの場である
ソフトウェアの開発コストの大半は保守のコストになる。そのコストを節約するためにコードは読みやすくする必要がある。
⇨コードで良好なコミュニケーションをとるには、コードを書いているときに他の人のことを考えるようにすることである。コードには「コンパイラやインタスプリタへの入力である」という側面だけでなく、「人に見せる文章である」という側面もある。この後者を「コミュニケーション」として価値を置くようにする。
・コードの複雑性は排除する
シンプルとはコードから余分な複雑性が取り除かれた状態のこと。余分な複雑性とはコードが達成しようとしている目的の複雑さを反映したものではなく、コードを動かそうとして格闘した痕跡による複雑性のこと。余分な複雑性は正しく動作する確率を減らし、将来の変更を困難にする。
⇨本質的な部分を目立つようにして、それ以外の余分な要素がそこに紛れこまないようにする。
・変更頻度でグルーピング
「変更頻度」とはコードを修正するタイミングが同じという意味。つまり、「変更理由」が同じということ。同じタイミングで変更される要素は同じ場所に置き、異なるタイミングで変剋される要素は別の場所に分けておく。
⇨例えば、「一般的な計算ロジック」と「年ごとに固有なロジック」があったらそれらを分離する。こうすると、「年ごとに固有なロジック」を毎年変更しても「一般的な計算ロジック」の品質は担保される。
・効果的にテストする能力
テスト容易性とはソフトウェアに対して、「効果的」かつ「効率的」にテストを行う能力のこと。また、テストが効率的とはテストのコストや労力が少ないことを指し、安く早くその品質を検証することができる。
⇨テスト容易性のための設計では、モジュール間の依存関係の排除がポイントになる。依存関係があるとテストしにくい部分に全体が足を引っ張られる可能性が高くなる。
・安全性にこだわる
例えば、あるif文に対してありえないと思いつつもelse文を考慮したり、あるcase文に対してありえないと思いつつもdefault句を考慮したり、ある変数に対してありえないと思いつつもnullチェックを行ったりすること。
⇨必然性のないところや曖昧なところは安全サイドに設計する。全ての動作を洗い出し、それぞれが安全になるように考慮する。
・速いコードより正しいコード
十分に動作するものがない段階で細かいところを磨いていくことには意味がない。
パフォーマンスが低い上に必要以上に複雑なコードが残ることになる。
⇨まず動かし、正しくしてから速くする。コードの複雑度を上げないようにして、シンプルな状態を保つ。
第4章 視点
・モジュールは「純粋」に
凝集度の低いモジュールは関係性のない仕事をしたり、仕事が多すぎたりする特徴がある。これは以下のような問題を発生させる。
・コードが理解しにくい
・コードが保守しにくい
・コードが再利用しにくい
・コードが脆弱で変更による影響を絶えず受ける
⇨モジュールの独立性を高めるためにできるだけ機能的強度モジュールを目指す。
実際にモジュール化を行う場合は、色々な事情の兼ね合いで情報的強度や機能的強度以外のモジュールになってしまうときがある。
止むを得ずそこに行き着くにしても、明確な評価基準の下にどれだけ代替案を検討するのかのプロセスは重要。
・コードの吉凶を見逃すな
⇨「コードの臭い」について把握しておくことが重要。
・よく見る
重複しているコードは修正しにくくなる。重複コードは1つにまとめるようにする。
・長すぎる
長すぎたら分割して短くする
・大きすぎる
モジュールが大きすぎて管理不能な状態。モジュールが大きすぎるということは、そのモジュールが担っている責務が大きすぎるということ。
大きすぎたら分解して小さくする。
・名前が合わない
修正を加えていくうちに、はじめは正しかった名前が不適切になる場合が非常に多くある。
表現したい概念と名前があっていないコードを発見したら直ちに適切な名前に変更する。
第5章 習慣
・怠惰
全体の労力を減らすために手間を惜しまない気質
・短気
コンピューターがサボっているときに怒りを感じる気質
・傲慢
高いプライドを持ち人様に恥ずかしくないコードをかく
・ボーイスカウトの規則
自分がそこに来た時よりも綺麗にしてからその場を立ち去る。最初にそのコードを書いたのが誰であるかに関係なく、少しずつでもコードを改善する努力を続ける。
コードの改善を続けていくことがプログラマのミッションである。
⇨変数名をより良くしたり、大きすぎる関数を分割したり、重複を排除したり、条件分の連なりを無くしたり、循環参照を解消したり、インターフェースを追加することで使用方法と実現方法を切り離したり、なんでも、どれくらいでも構わない。
・エゴを捨てよ
「うぬぼれ」や「プライド」を捨て、仲間に協力を求めるようにする。
自分の書いたコードを積極的に仲間に見せ、改善点を指摘してもらう。
同僚にコードを見せ、アドバイスを謙虚に受け入れる開発スタイルはソフトウェアの品質を向上させることがわかっている。
⇨書いたコードは自分自身ではない。「人に優しく、コードに厳しく」して、人ではなくコードを批評することを念頭に置いてコードを書くようにする。
第6章 手法
・「かもしれない」プログラミング
関数に不正なデータを渡された時に、それが他の関数のせいであったとしても被害を受けないよう「防御的な」コードを書いておく。
不正なデータを早めに見つけようとすると、デバックの効率が上がる。また、不正なデータを早めに処理することで運用中の問題が大きくなることを防ぐ。
⇨「バリケード戦略」をとる。コードにバリケードを築くためには特定のインターフェースを「安全地帯への境界」として使用する。そして、「安全地帯への境界」を通過するデータを検証して、不正なデータには適切な処置をとるようにする。
第7章 法則
・悪いコードは「蟻の一穴」
ソフトウェアの「悪い設計」「間違った意思決定」「悪いコード」を放置すると、それがどんなに小さなものでも、ソフトウェア全体をごく短期間で腐敗させることになる。
⇨コードの良くない部分はそのままにせず、発見と同時に修復する。コードが清潔で美しく保たれていれば、プログラマはそれを汚さないよう、細心の注意を払うことになる。
・2番目のリリースは昨日過多
2番目のバージョンには機能を盛り込みすぎてしまい、品質が悪く、機能の使い勝手も悪くなる傾向がある。機能を盛り込みすぎるとコードが複雑になり、コードの保守性が悪くなる。
⇨ユーザーを明確に定義し、イメージすることが重要。
プログラミング中は以下の問いを改めて考えてみる
・ユーザーは誰なのか
・ユーザーは何を必要としているのか
・ユーザーは何が必要だと考えているか
・ユーザーは何を望んでいるか
【技術書メモ4】SQL ゼロからはじめるデータベース操作
技術書メモ4冊目！
仕事でSQLのタスクをいただいたので、この本を読んで得た知識で精一杯頑張るぞ！
- 第1章 データベースとは何か
- 第2章 検索の基本
- 第3章 集約と並べ替え
- 第4章 データの更新
- 第5章 複雑な問い合わせ
- 第6章 関数、述語、CASE式
- 第7章 集合演算
- 第8章 SQLで高度な処理を行う
第1章 データベースとは何か
DBMSには5つの種類がある
・階層型データベース
・キューバリュー型データストア（KVS）⇨キーと値の組合せだけの単純な形でデータを保存する
SQLの基本的な記述ルール
・SQL文の最後に「 ; 」をつける
・大文字、小文字は区別されない
・文字列と日付の定数はシングルクォーテーションで囲む
・数値の定数は囲まない
・単語の間を半角スペース、または改行で区切る
データベースを作成する
CREATE DATABASE <データベース名>;
テーブルを作成する
CREATE TABLE <テーブル名>;
(<列名1> <列名2> <列名3>,
<列名1> <列名2> <列名3>,
<列名1> <列名2> <列名3>,
・
・
・
<このテーブルの制約1>, <このテーブルの制約2>, ・・・・);
テーブルを削除する
DROP TABLE <テーブル名>;
※削除したテーブルは復活できないので注意
列を追加する
ALTER TABLE <テーブル名> ADD COLUMN <列の定義>;
基本的なデータ型
・INTEGER型
整数を入れる列に指定するデータ型（数値型）。小数は入れられない。
・CHAR型
文字列を入れる列に指定するデータ型。
CHAR(10)やCHAR(200)のように列の中に入れることのできる文字列の長さをカッコで指定する。
固定長文字列が格納される。固定長文字列とは、列に入れる文字列の長さが最大長に満たない時、文字列が最大になるまで空きを半角スペースで埋める。
・VARCHAR型
CHAR型と同じく文字列を入れる列に指定するデータ型。
可変長文字列が格納される。可変長文字列とは、文字数が最大長に満たない場合でも半角スペースで埋めたりしない。
・DATE型
日付を入れる列に指定するデータ型。
第2章 検索の基本
基本的なSELECT文
SELECT <列名>, ・・・・
FROM<テーブル名>;
SELECT句にはテーブルから出力したい列の名前を書く
FROM句にはデータを取り出すテーブルの名前を書く
列に別名をつける
例
SELECT shohin_id AS id,
SELECT shohin_mei AS "商品名",
SELECT shiire_tanka AS tanka
FROM shohin;
WHERE句による行の選択
SELECT <列名>, ・・・・
FROM <テーブル名>
WHERE <条件式>;
※WHERE句は必ずFROM句の直後に書く
NULLである行を選択したいときは条件式にIS NULL演算子を使う。
NULLでない行を選択したいときはIS NOT NULL演算子を使う。
ORを優先させたいときは、（）を使用する。
第3章 集約と並べ替え
SQLの基本的な集約関数
・COUNT テーブルのレコード数（行数）を数える
COUNT(*)はNULLを含む行数を、COUNT(<列名>)はNULLを除外した行数を数える。
・SUM テーブルの数値列のデータを合計する
・AVG テーブルの数値列のデータを平均する
・MAX テーブルの任意の列のデータの最大値を求める
・MIN テーブルの任意の列のデータの最小値を求める
グループ分けをする
GROUP BY句を使用する
ケーキを切り分けるようにテーブルをカットしてグループ分けする。
例
SELECT <列名1>, <列名2>, <列名3>, ・・・・
FROM <テーブル名>
GROUP BY <列名1>, <列名2>, <列名3>,・・・;
GROUP BY句を使うときはSELECT句に集約キー以外の列名を書けない。
句の記述順序
SELECT⇨FROM⇨WHERE⇨GROUP BY⇨HAVING⇨ORDER BY
実行順序
FROM⇨WHERE⇨GROUP BY⇨HAVING⇨SELEC⇨ORDER BY
集約関数を書けるのはSELECT句とHAVING句とORDER BY句だけ
集合に対する条件を指定できる句がHAVING句
HAVING句はGROUP BY句の後ろに置く
集約キーに対する条件はWHERE句に書く
WHERE句＝行に対する条件指定
HAVING句＝グループに対する条件指定
並び替えをするときはORDER BY句
ORDER BY句は常にSELECT文の最後尾に書く
昇順 ASC（何も書かなければ昇順になる）
降順 DESC
ソートキーにNULLが含まれていた場合、先頭か末尾にまとめられる
第4章 データの更新
テーブルにデータを挿入
INSERT分の使い方
INSERT INTO <テーブル名> (列1、列2、列3、・・・) VALUES (値1、値2、値3・・・);
データを削除
DELETEの使い方
DELETE FROM <テーブル名>;
データの更新
UPDATEの使い方
UPDATE<テーブル名>
SET <列名> = <式>;
トランザクションとは
セットで実行されるべき1つ以上の更新処理の集まりのこと。
トランザクションの構文
トランザクション開始文;
DML構文①;
DML構文②;
DML構文③;
・
・
・
トランザクション終了文（COMMIT または ROLLBACK）;
使うDBMSによって開始文は異なる
ACID特性
・原子性
全て実行されるか全て実行されないかの状態で終わることを保証する性質のこと
・一貫性
トランザクションに含まれる処理はデータベースにあらかじめ設定された制約を満たす性質
・独立性
トランザクション同士が互いに干渉を受けない
・永続性
トランザクションが終了したらその時点でのデータの状態が保存されることを保証する性質
第5章 複雑な問い合わせ
ビュー
テーブルが「実データ」を保存するのに対し、ビューはテーブルからデータを取り出す「SELECT文」を保存する。
ビューの作り方
CREATE VIEW ビュー名 (<ビューの列名1>, <ビューの列名2>, ・・・)
AS
<SELECT文>
ビューの上にビューを重ねることはしない（できれば）
サブクエリ
サブクエリを一言で言うと、使い捨てのビュー
サブクエリの中にさらにサブクエリを入れる入れ子構造も（一応）可能
相関サブクエリ
相関サブクエリは小分けにしたグループ内での比較を行うときに使う
第6章 関数、述語、CASE式
LIKE述語
文字列の部分一致検索を行うときに使う
前方一致、中間一致、後方一致の3種類
BETWEEN述語
範囲検索、引数を3つ使うのが他の述語と違う
CASE式
検索CASE式
場合分けを行う
第7章 集合演算
テーブルの足し算
集合演算子は通常は重複行は削除する。
注意事項1、演算対象となるレコードの列数は同じであること
注意事項2、足し算の対象となるレコードの列のデータ型が一致していること
注意事項3、SELECT文はどんなものを指定しても良い。ただし、ORDER BY句は最後に一つだけ
結合
別のテーブルから列を持ってきて「列を増やす」操作。欲しいデータが1つのテーブルだけからでは選択できない場合にこの操作が役に立つ。
内部結合 INNER JOIN
Ａに属する列を橋渡しの橋に使って、Bに属する列同士を一緒の結果に含めてしまうこと。
・ポイント
結合を行うときはFROM句に複数のテーブルを記述する
内部結合ではON句は必須。記述場所はFROM句とWHEREの間
結合を使った場合のSELECT句は全て<テーブルの別名>.<列名>の書式で書く
外部結合 OUTER JOIN
・ポイント
内部結合と違い、片方のテーブルの情報が全て出力される
どちらのテーブルをマスタにするか
第8章 SQLで高度な処理を行う
ウィンドウ関数
構文
<ウィンドウ関数> OVER ((PARTITION BY <列リスト>)ORDER BY <ソート用列リスト>)
RANK関数 レコードのランキングを算出する関数
PARTITION BYは順位をつける対象の範囲を指定
ORDER BYはどの列をどんな順序で順位づけを行うかを指定
PARTITION BYによって区切られた部分集合をウィンドウと呼ぶ
PARTITION BYは指定しなくても良い⇨テーブル一つが大きなウィンドウとして扱われる
ウィンドウ関数は原則としてSELECT句のみで使える
注意点
OVER句の中でORDER BYを使うので、勘違いをしてしまいそうだが、結果の並び順には影響しない。
GROUPING演算子 合計と小計を一度に求める
ROLLUP
集約キーの組み合わせが異なる結果を一度に計算する。合計、小計を一度に求められる便利な道具。
CUBE
CUBEは集約キーで切り分けたブロックを積み上げて立方体を作るイメージ
