Magnolia Tech

いつもコードのことばかり考えている人のために。

printデバッグに絵文字を使うと捗る話

というツイートをしたら意外と反応が多かったので、ブログのエントリとして残しておきます。

printデバッグの時は冒頭に内容を示す文字列を書いておくと思いますが、その時に冒頭に「👺」を差し込んでおくと赤くて目立つし、珍しく横を向いてる絵文字なので、「ここから先を見ろ」って分かりやすい。

あとまず普通出てこないので、検索し易い。

macOS だと「おに」の変換で出てくるのでタイプ数も少ないし。

まぁ当然別に区別できれば何でもいいんですけど、絵文字の普及でUnicodeの文字の扱いがまともになって良いですね。

当然終わったらちゃんと消しておきましょう。突然コンソールとかログに👺がたくさん出てくると驚いちゃいますからね。

『プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書』は書名に偽りのない、全部入りの1冊

プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

Amazon

予約していたので、早速届きました。

Javaを使ってプログラミングを学ぼうとする人は、とりあえずこれ買っておけばいいんじゃね？っていう全部入りの1冊ですね。

JDKのインストールから、IDE/REPLの使い方、基本的な文法、エラーメッセージの読み方、オブジェクト指向、関数型プログラミング、各種ツールチェーン（ユニットテスト、ビルドツール、バージョン管理）と、全部入りの全部入り。

全般的に単なる文法の解説に終始せず、初学者がつまづきやすいところにページを割いているところが良くて、特に「最初からIDEを使う」と、「エラーが出ることと、その読み方を最初から書いていること」、「理解が難しそうな”ループ”の概念にフォーカスしていること」あたりは、上手く理解の解像度に合わせてペースを変えている。

あと、最初からJava17ターゲットにゼロから書き下ろされているので、後から追加されたラムダ式やレコード、新しいswitch構文などが「最初からあるもの」として書かれているのも凄く良い。どうしても歴史ある書籍のアップデートだと、「今頃それを最初に解説する？」とか、「後から追加になった機能の解説の取って付けた感」がすごいけど、この本ではそれが、ない。逆に新しいswitchの構文を先に教えておいて、後から「古いswitchの書き方はこう」と既存のソースコードを読み解くための内容もちゃんとフォローされている。

開発環境の整備も、ちょっとしたつまづきやすいポイント(検索ではJDKのダウンロードページに辿り着くのが大変、とか、IntelliJのmacOS版ではOSデフォルトのショートカットキーを変えておいた方がいいとか...)が書いてあるところが良い。

500ページ近くあるので、ちゃんと手元で実行しながら読み進めるのはハードだけど、入門の時くらい最後までやり切ると、必要な知識のベースラインができて良いと思いますし、Java8より前の頃にJavaと、そのツールチェーンを学んだ人にとっては現代的なやり方に知識をアップデートするのにもちょうど良いと思います。

歴史ある言語、みんなこんな感じの解説書があるといいですね。

文法を学んだ次に知りたいのは、ゼロから巨大なコードを書き上げる方法ではなく、"既存のコードの改修を適切にやれる方法"なんじゃないか

プログラミング言語の文法や、ツールチェーンの使い方を一通り覚えた後、実際にプロダクションコードを書く場面で最初にアサインされることって、”プロダクションレベルのアプリケーションのコードをゼロから一気にリリースクオリティまで書き上げる”ことではなく、”既存のコードに対する小さな改修”だったりしませんか。

そんな時、『入門　機能追加』があればいいのに、と思ってしまう。

コードは書かれる時間より、読まれる時間の方が圧倒的に長いのだから。

blog.magnolia.tech

前回のエントリでも書いたけど、目の前の最短が必ずしも全体の最適・最短ではない、みたいな話も有って...当たり前に適用していかないといけないプラクティスを変えていかないといけないのかもしれない。

とは言っても、そんな本、容易に書けるのかなーという話もあり、世界は難しい...

という話をしていたら、こんな話もあり、世界はまだ希望が有る！ようです。

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

Amazon

見通しの悪いコードができあがってしまう、その理由

最小の変更量でやりたいことが実現できれば、それに越したことはないけど、それを積み重ねて行った時に、常にその選択をとり続けることが正解か？というとそんなことは無いし、みんな気づいているはずなんだけど、「最小の変更だけを良しとするんでしょ？どうせ...」みたいな価値観が支配的になってしまった時...

つまり、スキルの高低の、その前に、それを取り巻く価値観の方が強く支配的になっていくんじゃないか、と思った。

追記:

『良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方 』と、『プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書』を注文した

良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

Amazon

プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

Amazon

続けて2冊、今までとはちょっと違う感じのコードに関する本が出版されるというので、両方注文した。

楽しみだ。

前者は、いつもクソコード動画で私たちを楽しませてくれる、ミノ駆動さんの作、ということで期待大。 後者は、Javaに精通した、きしだ なおきさん、山本 裕介さん、杉山 貴章さんの三人の共著ということで期待大。

speakerdeck.com

さっきまで前者と後者が逆だった...ご指摘ありがとうございました＞ちゃちいさん

追記：

最近の、きしださんのオブジェクト指向に関する一連のツイートはとても興味深い。だから買ってみようと思ったわけです。

vimのコメント文字の挿入方法をカスタマイズする

vimではコメントを1行書いて改行すると自動的にコメント文字をインサートしてくれる機能が有る。1行コメント、ブロックコメントのどちらにもサポートがあり、けっこうカスタマイズの自由度が広い。

vim-jp.org

Vim-Scalaの設定が微妙に好きではないので、~/.vim/after/ftplugin/scala.vimに以下の行を追加した。

setlocal comments=s1Ob:/**,mOb:*,eOx:*/,s1Ob:/*,mOb:*,eOx:*/,bO://
  • ブロックコメントはScaladoc形式と、通常のブロックコメントの両方をサポート
  • 行コメントもサポート
  • コメント文字の後ろに1文字空けないとコメントとして認識しない
  • Oで行挿入する時はコメント文字を挿入しない

という設定にした。

YAPC::Japan::Online 2022へ参加した

yapcjapan.org

3/4,5と開催されたYAPC::Japan::Online 2022に参加しました。

オンラインカンファレンスもいくつか参加してきましたが、没入感というか、参加している感をどうやって作り上げていくか？というのは自分もイベント運営する側としていつも悩む点です。

しかし！！

あまり写真をちゃんと撮っていなかったので残っていませんが、イベント開催の真っ最中に全国の参加者にピザが届く（登壇している真っ最中の人にも！！）ってマジで画期的じゃないですか、これ。この参加しているよ感の演出は大成功だったと思います。

ビールも良かった！

残念ながら開催時間中ずっと張り付いていた訳ではないですが、今回は正規表現に関する発表が複数有ったのが個人的には結構嬉しかったです。でも使い方はほどほどにね！

特にこの発表は改めての学び、そしてその課題への「正しい」解決策の実践と、「これこそテックカンファレンスで聞きたいやつだ！」と言える内容だったので凄く印象的でした。

あとはやはりノベルティ！！これも「参加した感」に一役かってたと思います。

オフラインもいいし、オンラインもいいし、色んな参加の仕方、楽しみ方が有るのがコミュニティベースのテックカンファレンスの良さだと思います。

2019年のYAPC::Tokyoはスタッフでも参加したのですが、またスタッフ参加したくなった、そんなYAPCでした！