【追記（2019/02/10 9:53）】 現在開いているこの記事は技術書典５に向けての記事です。 技術書典６に向けての最新記事は以下をご参照ください。 使いやすくなったり、Re:VIEWなどのバージョンが更新されています。 at-grandpa.hatenablog.jp 【追記おわり】 Re:VIEW+CSS組版の環境は、わかめさんの vvakame/review-css-typesetting で整いつつあります。今回は、個人的に欲しい機能を追加した、という話です。いい感じに回っているのでブログにまとめることにしました。 目次 目次 Re:VIEWとは CSS組版とは Re:VIEW+CSS組版 環境構築 使い方 やってること デザインの変更 CSSを編集する htmlを編集する 完成したPDFは印刷所で印刷可能か（確認完了） まとめ Re:VIEWとは Re:VIEW形式で書かれた

この疑問は、以前から興味がありました。過去の記事でも少し触れています。 at-grandpa.hatenablog.jp 今回は、今までの自分の経験と、この疑問を考え続けた結果から、あるひとつのプロセスが浮かび上がってきたのでまとめます。 目次 目次 学習したのに身についていない現実 「身につく」とは より多くの問題を解決するには 学習プロセス 抽象的な知識の「種」を定義する 具体的な問題解決にトライしてみる A. うまく問題解決できた場合 B. 汎用性がなく、解決できなかった場合 C. 具体的な問題解決に結び付けられず、解決できなかった場合 フィードバックループを回す 学習に対する姿勢が変わる まとめ 学習したのに身についていない現実 自分はこんな経験があります。 あの本を読んだのに、実際の仕事に活かせていない 手を動かしてモノを作ったけど、何を学んだか説明できない 自己学習をしているが

日々、githubのissueにその日の振り返りを書いているのですが、その時「なぜ自分はそのような行動を取ったのか」という疑問が生まれました。そこから連動して「自分の行動原理ってなんだろう」と思ったので、いろいろと深掘ってみました。 自分の行動原理を紐解いていくの面白い、という話をだらだらしたいなぁ。 「なぜ自分はこういう行動を取ったんだろう」というのを突き詰めていくと、どんどん深く潜れて、一見反対の行動でも最終的に一つの解に行き着く。— at_grandpa@技術書典4執筆中 (@at_grandpa) 2018年2月28日 以下、勢いで書きなぐっているので、とても長いですし、いつもとは文体がおかしいです。ご了承ください。 日々のふりかえり Githubに「diary」というプライベートリポジトリを作り、毎日issueを立て、そこにふりかえりを書いている。結構良い。自分と対話できて、自分

当たり前のことかもしれませんが、ふと忘れがちになってしまうので自戒も込めて記します。 TL;DR 技術の仕組みだけを勉強するのではなく、その技術が解決しようとしている「課題」も意識すると身につきやすい 身についた技術と身につかない技術がある ふと思い返してみると、気づいたことがありました。日頃勉強をしているのに、身についた技術と身につかない技術があるのです。 今回は、「これはなぜだろう？」と疑問に思ったのが発端です。単純に勉強時間と相関があるわけではなさそうです。 身についた技術に対して何をしたか どんなことをしたらその技術が身についたのかを、ざっくり振り返ってみます。 身についた 自作ライブラリを作った 業務で使用した 身につかない 書籍をパラパラと読んだ 仕組みだけを勉強した 惰性で勉強会に参加した 身についた技術には何か共通項があるのでしょうか。 共通項は？ 軽く共通項を考えてみると

@t_wadaさん翻訳の「新訳版 テスト駆動開発」の第Ⅰ部を終えました。 テスト駆動開発posted with ヨメレバKent Beck オーム社 2017-10-14 AmazonKindle この本を読むにあたってgitリポジトリを作って読み進めたので、その方法を記しておきます。 読んで終わりにしたくない 読む前に、注意点として「読んで終わりにしないこと」「エンジニアリングに活かせるようにすること」を掲げました。以前、ピアソンから出版されている旧訳版を読んだのですが、今の自分に残っているのは「テストから書き始めること」くらいでした。あまりにも身についていないことに気付き、読み方を変えてみようと思いました。以前は「スキマ時間にさらっと読む」というスタイルだったので、それが原因かもしれません。 まずはリポジトリを作る そのため、今回はリポジトリを作って「開発」を行うようにしました。以下が

以下のイベントにて、Crystal言語について発表しました。 rubyassociation.doorkeeper.jp タイトルは 「Crystalのこれまでの歩みと v1.0 に向けたロードマップ」 です。 Matzさんの発表の後ということですごく緊張しましたが、Crystalについて話す機会をいただき、こちらも大変勉強になりました。主催者の方、会場をご提供いただいた株式会社クラウドワークスさん、そのほか関係者の皆様、いろいろとありがとうございました。 以下、このイベントを通していろんな方と話したこと、思ったことをメモします。 Ruby3の型チェックについての構想 Matz「型はもちろんなるべく何も書きたくない。テストも書きたくない。書くけど」 #ruby_a— urakawa (@urakawa) 2017年7月6日 書きやすさ重視 型は書きたくない、考えたくない 全てをチェックしよ

「好きな技術はなんですか？」 こう聞かれた時、今の自分は真っ先に「crystal言語」と答えます。ですが、昔の自分は好きな技術を明確には持っていませんでした。この 好きな技術がある時/ない時 を振り返ってみると、いろいろと違うなと感じたのでまとめます。 目次 目次 好きな技術がない時 好きな技術がある時 嬉しい二つの効果 周辺知識が自然とついてくる 自分に「特定のイメージ」がつく 好きな技術を持つには まとめ 好きな技術がない時 好きな技術がない時を振り返ってみると、総じて 受け身 でした。 「好きな技術は？」と聞かれても答えられない ウォッチしている技術もなく、躓いた時に調べる程度 「みんなやってるから」という理由で勉強会に参加 周りと比べて自分だけ知らない技術は慌てて調べる 「この本良いよ」という本は買うが、積ん読が増えていく 自発的な行動ではなく、周りが発端となって行動しています。こ

３回同じことを繰り返したので自動化しました。 作ったもの crystalで des というツールをつくりました。docker環境の設定ファイルを生成するCLIツールです。 github.com まれによくあるケース crystalを試したいけどcrystalがローカルに入っていない php7を試したいがphp7がローカルに入っていない ディープラーニング本の勉強のためにpython環境がほしい サクッと試したいだけなのに、ローカルにいろいろ入れるのは面倒ですよね。自分の場合は、実現したい環境をdockerで用意していました。Dockerfile、Makefile、docker-compose.yml の雛形を用意しておき、必要な時にそれをコピーし、適宜書き換えて利用していました。 この作業が面倒だったのでツールを作りました。 使い方 以下の３つのコマンドを打てば、docker環境に入ること

この問いに対して、自分なりの答えを言語化できたのでまとめます。 目次 目次 疑問 実践する機会 自分なりの答え 「コードを書く瞬間の思考」にアドバイスを貰える 他の方法で代替できない ペアプロの欠点 まとめ 疑問 きっかけは、下記の方々のやり取りをTwitterで見かけたからです。 「それをできる人とペアプロする」以上に短期間で新しい技術を身につける方法を知らない。— Jxck (@Jxck_) 2017年2月3日 ペアプロが最速だろうなあ https://t.co/SdbZZ2EypI— Takuto Wada (@t_wada) 2017年2月3日 サッと調べると「最速なのは同意」という意見が大半でした。自分もこれには同意するのですが、「なぜペアプロが最速なのか？」という疑問を持ったのです。 ペアプロ、最速だと思うんだけど、なぜ最速なのかがハッキリわからない。「わからないことがすぐに聞

いろいろと得るものが多かったので、やったことと感想をまとめます。 長くなってしまったので、お時間ある時にどうぞ。 TL;DR Crystal言語（ja） で、isucon5-qualifier-standaloneのWebAppを実装 新しい言語の勉強をする際、isuconを題材にすると良さそう 実装するものが決まっているので余計なことは考えずコーディングに集中できる 参考にできる他言語の実装がすぐそばにある ライブラリのコードを読むことに抵抗がなくなった ライブラリのリポジトリにPRを送りたくなった リポジトリ Crystal言語 で、isucon5-qualifier-standaloneのWebAppを実装しました。 github.com 目次 TL;DR リポジトリ 目次 発端 実際にやったことのピックアップ DBライブラリからの返り値が壮大なUnion型になっていてつらい マルチ

rubyを書き始めて間もない頃、 「なんで NoMethodError なんだ...。あ、メソッド定義にself 付けたら通った。」 みたいなことがありました。 rubyの本を読んでいると、そのあたりがハッキリとイメージできるようになったのでまとめておきます。 参考にした本 年明けからひたすらRuby本を読んでいます。読了したのは以下。 現在は Effective Ruby を読んでいます。 これらを読んでいくと、中途半端に理解していた部分がカチッとハマるのでオススメです。 ※ 今回のコードは ruby 2.2.0 で試したものです。 オブジェクトとクラスの関係 サンプルコードを見てみましょう。 class C def c_instance_method @my_var = 1 end end obj = C.new 当初、自分はオブジェクトとクラスの関係を以下のように考えていました。 （

こんにちは！@at_grandpa です。 社内勉強会でdockerについて話す機会がありました。 以下に、勉強会で使用したスライドを載せます。 「dockerって聞いたことあるけどなんなんだ？」という人向けに作りました。 （自分もその立ち位置だったので） はじめてのdocker from at_grandpa 内容としては以下になります。 現在のサーバー運用が抱える問題 ( p.9 ) dockerを支える技術 ( p.56 ) AUFS LXC 実際にdockerを使う流れ ( p.85 ) pingとvimをインストールしてみる dockerのその他の機能 ( p.113 ) AUFSやLXCについては、以下のサイトが個人的にわかりやすかったです。 Dockerが利用しているAUFSとLXC スライド内で使用したURLはこちらです。 Docker: Linuxコンテナを使ってアプリ

お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている！」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中