今回は「目的」を表すto do / for doingについてです。 言うまでもなく、to doは「to不定詞」と呼ばれ、for doingの方は、forが前置詞なので後ろは「動名詞-ing」になっており、どちらも「目的」を表せます。 同じ「目的」でも…… では、「目的」を言いたい場合、どちらを使っても同じなのでしょうか？ まずは次の英文をご覧ください。 〇 ex) Tom bought a screwdriver to fix his bicycle. 「トムは自転車を修理する”ために”ドライバーを買った」という英文で、to doは「doするために」という「目的」を表しています。 では次の文はいかがでしょうか？ × ex) Tom bought a screwdriver for fixing his bicycle. こちらの英文は間違いとは言い切れませんが、少々不自然です。 前置詞f

以前（2014年ごろ）このブログに「圏論の本」という記事を書いたが、あれ以降いろいろな本が出てきたようだ。特に、和書が増えた。 というわけで、この記事では2018年時点で手に入る圏論の本を独断と偏見で紹介する。ここで紹介するのは入門書、和書が中心となり、より専門的な話題に特化した本は省く。 圏論の入門書と一口に言っても、書き方や内容は著者によって様々である。読者にも代数学をやりたい人、プログラミングやロジックをやりたい人、色々いるだろうが、読者のバックグラウンドや興味の方向によって読むべき本は変わる。 読者が適切な本を選択する為に、この記事が（十分なガイドとまではならなくとも）なんらかのヒントを提供できれば幸いである。 適宜、Web上で他の方が書いた書評にリンクを貼る。 入門書、教科書 圏論の歩き方 圏論の歩き方委員会 編 「圏論の歩き方」日本評論社、2015年 [出版社ページ] 「圏論っ

レビューで CL を閲覧する 要約 前節でコードレビューの観点を学びましたが、では複数ファイルにまたがった変更をレビューする最も効果的な方法は何でしょうか？ 変更はうまく機能するでしょうか？適切なディスクリプションはあるでしょうか？ いちばん重要な変更を最初に確認してください。それは全体としてうまく設計されているでしょうか？ CL の残りの部分を適切な順序で見てください。 ステップ 1: 変更を広く眺める CL のディスクリプションと CL が大まかに何をしているかを確認してください。 この変更は機能しているでしょうか？ そもそもこの変更が行ってはならないものであれば、変更すべきでない理由を添えてすぐに返信してください。 そのように変更を却下する場合、代わりに何をすべきかを開発者に提案するのも良い考えです。 たとえば、次のように伝えることができます。「これに関して良い仕事をしてくださってい

コードレビューの観点 （注）以下のポイントを検討する際にはつねにコードレビューの基準を忘れないでください。 設計 レビューで確認すべき最も大切なことは、CL の全体的な設計です。 CL のコードの各部分は相互にきちんと連携するでしょうか？この変更はコードベースに属するものでしょうか、それともあるライブラリに属するものでしょうか？システムの他の部分とうまく統合するでしょうか？この機能を追加するタイミングは今がふさわしいでしょうか？ 機能性 この CL は開発者の意図通りに動作しますか？開発者の意図はこのコードのユーザーにとって適切でしょうか？「ユーザー」とは普通、エンドユーザー（その変更によって影響を受ける場合）と開発者（将来このコードを「使う」必要のある人）の両方を指します。 通常、CL がコードレビューに至るまでには、コードが正しく動作することを開発者が十分にテストしていると期待できます

コードレビューの基準 コードレビューの主な目的は、Google のコードベースにあるコードの全体的な健康状態を時間をかけて改善することです。 コードレビューのすべてのツールとプロセスは、その目的のために設計されています。 これを実現するには、さまざまなトレードオフのバランスを取る必要があります。 まず第一に、開発者は自分のタスクを進めることができなければなりません。 コードベースに改善を提出できなければ、コードベースは改善しません。 また、どんな変更に対してもレビュアーがいちいち難色を示して変更を取り入れずにいると、早晩、開発者は改善を行う意欲を失います。 一方、CL の品質を確認するのはレビュアーの義務です。CL を取り入れてコードベースのコードの全体的な健康状態 (code health) がだんだんと悪化するのは問題ですから、きちんと確認しなければなりません。 これは骨の折れるやっか

春休みに3週間ほどインターンシップに参加してきました. いろいろと思うところがあったので, 参加した感想を書いていきます. 経緯 近年ではインターンシップ(以下インターン)が盛んに行われています. 就職活動には関係ないという建前で行われているのがほとんどですが, 実際には就活の選考に有利に働くことが多いようです. 就活に出遅れるのも得策ではないと思い, インターンに参加してみました. 具体的なインターン先は述べませんが, ITベンチャーとかではなく, いわゆる Japanese Traditional Big Company です. 多分, 日本人なら誰でも知っている企業だとは思います. 応募したきっかけは, そこに就職する先輩がいたことと, 大学OBが学内でそこのインターンの紹介をしていたからです. 非IT系の企業ですが, 配属先はICTでソリューションするような所でした. インターンの

英語の文章のタイトルをキャピタライズするとき、前置詞や冠詞などをキャピタライズしない場合、"be" や、助動詞や、5W1H の単語や、指示代名詞は、キャピタライズすべきでしょうか？（フォーマルな場面で） キャピタライズすべき品詞と、すべきでない品詞との、一覧があるウェブページをご紹介いただけると、それが一番よいです。

これは一人Computer Scienceアドベントカレンダー 15日目の記事です。 Computer Science何も関係ないけど大丈夫か？(まぁ一応Haskellはテーマの1つであったというアレはあるけど) 今回はHaskellで開発を始める時にいつもやってるセットアップの作業とかの説明をします。 どうも、Haskellerによるstackみたいな周辺ツールの情報の発信が足りてないんじゃないかみたいな噂が流れてきたのでじゃあまぁなんか記事にするかという流れです。 ところでstackの説明はググれば日本語の記事がそれなりにヒットするようになったと思うのでここではあんまり説明しません。 開発環境構築 このセクションは初回のみです。 Haskellのインストール stackはプロジェクトを管理するツールっていうのかな？まぁビルドツールになったりパッケージマネージャーになったりghcを管理す

DI DIの重要性はここ数年で急速に高まってきている。 依存性が注入されたりとかそういうことはどうでもよくて、設計と実装を分けたい、人類はそれだけのために色々と工夫をこらし最終的にたどり着いたのがDIであったのだろう。 Haskellでも設計と実装を分けるためにDIしたいというのは自然な流れである。 ここでは型も含めて設計が実装に依存してはいけないということを要求する。 例えば設計でMySqlConnection、みたいな型が出現することも分離できていないので禁止とする。 問題点 設計を定義するときには他の言語ではインターフェイスなどの仕組みが使われることが多い。 Haskellには型システムという仕組みがあるのでこれがインターフェイス相当の機能として紹介される場合がある。 しかし型システムはインターフェイスとは違い、型を固定する仕組みがない。型クラス TypeClass a のインスタン