長年使っていたMagic Mouseが使っている最中に頻繁に接続が切れてしまうようになったので、ずっと気になっていた「Surface Precision Mouse」を購入。
Surface用なのでmacOSで使ってもフル機能が使えるわけでもないけど、大きさといい、重さといい、さすが伝統のMicrosoftマウス、過去に使ったマウスの中では最高の出来映え。デザインもシンプルで、他社の上位機種のようなゲーミング感が無くて良い。
注意事項としては、サイドのボタンが使えないのと、Magic Mouseと比べるとスクロールの方向が逆になることだけど、まぁ元々macOS用ではないので。
Effective DevOps ―4本柱による持続可能な組織文化の育て方
買ったはいいけど、なかなか読む時間が取れなかった「Effective DevOps」を読み始めた。
一言でまとめれば、以下のツイートで全部かな。
Effective DevOps、いくら読み進めても、どんな開発組織でも普遍的に問題になりそうな所をどうやって乗り越えていくか？って話が続いていて、もしタイトルで避けた人とかいたらもったいないなーって思った
— magnoliak (@magnolia_k_) 2018年7月1日
より良い環境を作るためにどうするか？って話でしかなく、ツールとか開発手法とかじゃない
以下、章ごとの感想
1章から4章までは歴史や概念の説明なので、少しでも最近の開発手法を知っていたり、それなりの経験がある人であれば後から読んでもいい気もするが、2.2.2だけは印象深いトピックが書かれていてぜひ開発組織に属する人であれば読んで欲しい内容(あとで5.2.1でも再度出てくるけど)。
要はミスが起きた時に、個人の責とするか、組織の問題とするか、なのだけど、それを「ヒューマンエラーはトラブルの原因だ」と考える文化と、「ヒューマンエラーをシステムのもっと深いところにある問題の兆候」と考える文化という言い方で説明するところが凄くしっくりくる。
とくに現代的な開発手法やツールの発展を考えると、20年同じ手順を秘伝のタレ的な知見に基づいて続けていく（しかもその根拠は既に失われている）という現場は少なく、個人の責を問うにはあまりに学ぶべきことは多いし、変化も激しい。また、人もどんどん入れ替わっていくし、伝統的な先輩から後輩への伝達とも限らない（ある日突然アウトソーシング先が入札でガラっと変わることだってあり得る）。
そう考えると個人を責めてもしょうがなくて、組織で考えていかないとトータルでは良くなって行かないよねって考え方は実に正しいなって。
ある程度の開発経験が有る人であれば、5章の「5.1 devopsに対するよくある誤解」と、「5.2 devopsのアンチパターン」から読み始めると良いかなって思った。特に、5.2は一番最初に読んだ方が良い章。この章に対して納得感が有るか無いかで、この本から得られるものが有るか無いかははっきりすると思う。
「Effective DevOps」を読み返しているんだけど、5.2のアンチパターンのところだけでもいいので、みんな読んだ方がいい
— magnoliak (@magnolia_k_) 2018年7月1日
挙げられているのは「非難文化」「サイロ」「根本原因分析」「ヒューマンエラー」
なるほど！というね
6章はⅡ部の導入部なので飛ばして…
ここは完全に組織で仕事をしていく上での普遍的な話にフォーカスしている。
これ、完全に組織論、人材論になっているってことがよく分かると思う。個人的には「7.6 マインドセット入門」あたりが興味深かったけど、本当にこの章はdevopsに特化した内容ではなく、どうやってより良い組織を作っていくか？という話が続くので、ひょっとしたら人によってはガッカリしたり、意外な発見が有ったりするのでは、と思う箇所。
だからこそ冒頭のツイートに繋がるんだけど、ひょっとして開発プロセスや、ツールの使い方の本だと思ってこの本を読まないとしたら、本当にそれはもったいないって。開発チームのマネジメントを行う人、特にこれからリーダーになるような人はまず読んだ方が良い。5章と7章だけでも良いので読んで欲しい。
以降はチームでの仕事をどうやってより良くしていくか？という話や、（概念的な意味での）ツール導入、devopsをスケールさせる話とかなので、一気に読むより少しずつ自分の状況に合わせて読み進める方が良いと感じた。
全般を通して「これがdevopsだ！」というより、一貫して「良い開発組織であり続けるためには？」という話が続く所が良い本。
ただ、上司にdevopsの導入を進言する時には使いづらいかもね:)
300ページ超は、この手の本としてはそこまで大ボリュームではないけど、それでも全部を一気に読み切ろうとすると消化不良を起こしかねないような「考えさせられる」本であることは間違いないので、あまり慌てずゆっくり（できれば周りの人とディスカッションしたりしながら）読んだ方が良さそう。
たまたま「GraphQL」について調べていたタイミングで開催が決定したのと、最近すっかりpmイベント以外に参加できていないことも有って参加してきた。
GraphQL自体の入門、ScalaやRubyでのライブラリなどの紹介など、丁度知りたいレベル感と合っていたので、ぴったりのイベントでした。
あと、今回開催のきっかけが主催の@htomineさんが所属する会社の中でみんながGraphQLについて楽しそうに語っているんだけど、意外と外に出て発表していないからって所も良かった。背中を押す人、環境を作る人ってマジで大事ですね。
確認できた分のスライドへのリンクを張っておきます。そのうち、イベントサイトにもまとめられると思います。
会場提供はfreeeさんでした。
あと、GraphQLのイベントとしてGraphQL Tokyoというミートアップが有るそうです。次回はすぐの7月4日だそうです。
GraphQL、複雑化した要求や制約の中で効率よくデータを取得する必要性から生まれたものだそうですが、こうやってベストプラクティスがライブラリや規約の形で世の中に広まっていく感じがいいですね。
イベント最高でした。@htomine++!
Learning GraphQL: Declarative Data Fetching for Modern Web Apps
GraphQL API Design (API-University Series Book 5) (English Edition)
java.net.URLConnectionのguessContentTypeFromNameは、content.types.user.tableというシステムプロパティで定義された内容で任意のMIME typeを推測できるようになります。
公式ドキュメントにも書かれています。
URLConnection (Java Platform SE 8)
では実際にそれを確かめてみようと、テストコードの中でSystem.setProperty("content.types.user.table", "/path/to/content-types.properties")と指定してもさっぱり有効になりませんでした。
例えば、拡張子.cssをtext/cssと判定させるためには、以下のような設定ファイルを用意します。
text/css: \
description=Cascading Style Sheets;\
file_extensions=.css
以下のようなコードを用意して、設定ファイルを読み込んでみましが、mimeTypeにはnullが入りました。
System.setProperty("content.types.user.table", "/path/to/content-types.properties") val mimeType = URLConnection.guessContentTypeFromName("test.css")
実行時ではなく、予めsbt -Dcontent.types.user.table=/path/to/content-types.propertiesというふうに実行前に設定されるようにしておくと意図した通りにmimeTypeにはtext/cssが入ります。
これは何が起きているのでしょうか？
実は最初、Stack OverflowにSystem.setPropertyでセットすれば反映されると書かれていたので、それを鵜呑みにして「正しく動かない！自分の書いたコードがおかしいのか？」と思いましたが、実際にはその回答が誤りでした。
順番に、java.net.URLConnectionのguessContentTypeFromNameメソッドの挙動を、openJDK10のコードを例に追いかけていきましょう。
openJDKの該当するソースコードは以下の場所に有ります。
jdk10/master: be620a591379 src/java.base/share/classes/java/net/URLConnection.java
public static String guessContentTypeFromName(String fname) { return getFileNameMap().getContentTypeFor(fname); } public static FileNameMap getFileNameMap() { FileNameMap map = fileNameMap; if (map == null) { fileNameMap = map = new FileNameMap() { private FileNameMap internalMap = sun.net.www.MimeTable.loadTable(); public String getContentTypeFor(String fileName) { return internalMap.getContentTypeFor(fileName); } }; } return map; }
MIME Typeに関連するデータは、FileNameMapというクラスに格納されていること、値が無ければ(nullならば)されていなければsun.net.www.MimeTable.loadTableを呼び出して、初期化していることが分かります。
なお、getContentTypeForはFileNameMapのメソッドで、ほぼ単純なmap構造のデータから該当するMIME typeを取得する機能を提供します。
では、実際にMIME typeのテーブルを保持するsun.net.www.MimeTable.loadTableの中身を追いかけてみましょう。
sun.net.www.MimeTable.loadTableは以下のファイルに収録されています。
jdk10/master: be620a591379 src/java.base/share/classes/sun/net/www/MimeTable.java
public static FileNameMap loadTable() { MimeTable mt = getDefaultTable(); return (FileNameMap)mt; } public static MimeTable getDefaultTable() { return DefaultInstanceHolder.defaultInstance; } private static class DefaultInstanceHolder { static final MimeTable defaultInstance = getDefaultInstance(); static MimeTable getDefaultInstance() { return java.security.AccessController.doPrivileged( new java.security.PrivilegedAction<MimeTable>() { public MimeTable run() { MimeTable instance = new MimeTable(); URLConnection.setFileNameMap(instance); return instance; } }); } }
loadTableから始まり、DefaultInstanceHolderクラスにdefaultInstanceというstaticなメンバが有ることが分かります。staticなクラスのstaticなメンバなので、クラス自体がロードされた時点で、getDefaultInstanceメソッドが実行され、defaultInstanceにはMIME typeのデータがロードされている、ということなのです。
更に、この時点でなぜかURLConnection.setFileNameMapを呼び出し、ロードしたMIME Typeをセットしています。getFileNameMapメソッドの中でやっているFileNameMap mapがnullか否かを判定するロジックっていらなくない？って思いますね。
実際にロードする部分のコードをもう少し追いかけてみましょう。
MimeTable() {
load();
}
public synchronized void load() {
Properties entries = new Properties();
File file = null;
InputStream in;
// First try to load the user-specific table, if it exists
String userTablePath = System.getProperty("content.types.user.table");
if (userTablePath != null && (file = new File(userTablePath)).exists()) {
try {
in = new FileInputStream(file);
} catch (FileNotFoundException e) {
System.err.println("Warning: " + file.getPath()
+ " mime table not found.");
return;
}
} else {
in = MimeTable.class.getResourceAsStream("content-types.properties");
if (in == null)
throw new InternalError("default mime table not found");
}
try (BufferedInputStream bin = new BufferedInputStream(in)) {
entries.load(bin);
} catch (IOException e) {
System.err.println("Warning: " + e.getMessage());
}
parse(entries);
}
確かにcontent.types.user.tableというシステムプロパティが設定されていれば、そこからパスを取得するようになっていますね。存在しなければデフォルトのcontent-types.propertiesを取得しています。
ちなみに、このcontent.types.user.tableというシステムプロパティを元に任意のMIME Typeを設定する機能について、テストコードが存在しません。確かにこれではグローバルにシステムプロパティを汚染しないとテストが書けないですね…
以上、java.net.URLConnectionのguessContentTypeFromNameにおけるcontent.types.user.tableの取扱について、実際のJavaのライブラリのコードを追いかけてみました。
依存関係(sun.net.www.MimeTable.loadTableがjava.net.URLConnectionに依存している)がおかしいとか、初回利用時ではなく、クラスロード時に強制的に初期化が行われ、以降は再設定もできないとか、そもそもテストが無いとか、よく考えるとguessContentTypeFromNameというメソッド自体java.net.URLConnectionではなく、独立したMIMEに関するクラスに所属しているべきでは？と、標準のJavaのライブラリでも色々と設計が気になるところが有るんだな、というのが今回の感想でした。
java.net.URLConnection.guessContentTypeFromNameはファイルの拡張子からMIME Typeを特定するメソッドです。このメソッドはJava8以前ではデフォルトで、$JAVA_HOME/lib/content-types.propertiesを参照していました。
しかし、Java9以降では、$JAVA_HOME/lib/にcontent-types.propertiesは有りません。
この辺りの事情は、Java9で削除された機能に関する解説に書かれています。
Removed APIs, Features, and Options
詳細はこちら。
ちなみに本当に削除された訳では無く、jdk/src/java.base/windows/classes/sun/net/www/配下に、ソースと一緒におかれています。
jdk10/master: 4554a9ae19ef jdk/src/java.base/windows/classes/sun/net/www/content-types.properties
なお、システムプロパティのcontent.types.user.tableに設定したパスのファイルに定義を書いておくと、任意のMIME Typeを追加することができる点は変わっていません。
以上、意外なところでJava9の変更点に引っかかって、「ファイルが無い！」と1時間溶かした記録です。モジュール化、難しい。
Java 9 Modularity: Patterns and Practices for Developing Maintainable Applications
前回のエントリの続きです。
前回はファイル名から…つまり拡張子をもとにMIME Typeを特定する方法を紹介しましたが、今回はファイルの内容からMIME Typeを推測する方法です。
前回も紹介した下記のブログエントリに、カスタマイズ方法が記載されていますが、Files.probeContentTypeがMIME Typeを決定するアルゴリズムはカスタマイズ可能で、java.nio.file.spi.FileTypeDetectorを継承したクラスを作成し、サービスとして登録します。
デフォルトのアルゴリズムでは、ファイル名を元にMIME Typeを決定しているので、独自にロジックを書けばファイルの内容からMIME Typeを推測することが可能になります…が、ちょっと使うにはかなりハードルが高いですし、汎用的に作ろうとすると異常な努力が必要になってくるので、アプリケーションの仕様から特定のフォーマットを識別したい、という時以外は採用は厳しそうです。
URLConnection.guessContentTypeFromNameはファイル名(拡張子)からMIME Typeを特定していましたが、java.io.InputStreamからの入力(つまりデータの中身そのもの)からMIME Typeを推測するメソッドがURLConnection.guessContentTypeFromStreamです。
いきなりopenJDKのソースへのリンクを張っておきますが、実装を見ると主にtext/html、application/xml、image/gif、image/png、image/jpegあたりの判定には使えそうです(それ以外は…なぜそれを判定対象にした？という感じの並びですね…)。
判定ロジックがべた書きされているので、カスタマイズ方法は無さそうです。サブクラスを作れば別ですが、そうすると完全にロジックを書かないといけないので、これまた異常な努力が必要になりますね。
ファイルの内容から推測する方法は、あまり汎用的な方法は（当然ですが）無いので、URLConnection.guessContentTypeFromStreamを使う以上の汎用性は求めない方が良さそうです。
ScalatraのMIME Type関係の機能が盛大に壊れている訳ですが、じゃあそれを直すためにMIME Typeを教えてくれるライブラリについて調べてみました。標準ライブラリだけでもいくつか方法が有りますね。
Java7から導入されたFiles.probeContentTypeを使うと、簡単にMIME Typeを取得できます。
scala> import java.nio.file.Files
import java.nio.file.Files
scala> import java.nio.file.Paths
import java.nio.file.Paths
scala> val htmlfile = Paths.get("test.html")
htmlfile: java.nio.file.Path = test.html
scala> Files.probeContentType(htmlfile)
res2: String = text/html
scala> val cssfile = Paths.get("test.css")
cssfile: java.nio.file.Path = test.css
scala> Files.probeContentType(cssfile)
res3: String = text/css
scala> val jsfile = Paths.get("test.js")
jsfile: java.nio.file.Path = test.js
scala> Files.probeContentType(jsfile)
res4: String = text/javascript
最後、javascriptがtext/javascriptになっていますが、application/javascriptで返して欲しいですね。カスタマイズは可能です。下記のブログエントリが参考になります。
返って来る値が実装依存なので、自分が使いたいMIME Typeはきちっとテストを書いておきましょう。
URLConnection.guessContentTypeFromNameもファイル名からMIME Typeを取得できます。
scala> import java.net.URLConnection
import java.net.URLConnection
scala> URLConnection.guessContentTypeFromName("test.html")
res5: String = text/html
scala> URLConnection.guessContentTypeFromName("test.css")
res6: String = null
scala> URLConnection.guessContentTypeFromName("test.js")
res7: String = null
デフォルトでは、かなり残念な結果になりました。こちらもMIME Typeはカスタマイズ可能です。こちらの記事によると、content-types.propertiesというファイルを用意すれば良さそうです。
Getting and Extending mime-types in Javathilosdevblog.wordpress.com
content-types.propertiesの正式なフォーマットの解説が見つけられませんでしたが、こちらのブログにサンプルファイルが紹介されていました。
最後はjavax.activation.MimetypesFileTypeMapです。
scala> import javax.activation.MimetypesFileTypeMap
import javax.activation.MimetypesFileTypeMap
scala> val mimeTypesMap = new MimetypesFileTypeMap
mimeTypesMap: javax.activation.MimetypesFileTypeMap = javax.activation.MimetypesFileTypeMap@7e258a05
scala> mimeTypesMap.getContentType("test.html")
res8: String = text/html
scala> mimeTypesMap.getContentType("test.css")
res9: String = application/octet-stream
scala> mimeTypesMap.getContentType("test.js")
res10: String = application/octet-stream
こちらもcssとjavascriptが正しく扱えていません。カスタマイズ方法は公式ドキュメントにきちんと書かれています。
MimetypesFileTypeMap (Java Platform SE 8)
しかし、残念ながらこのパッケージは将来廃止が予定されています。
JEP 320: Remove the Java EE and CORBA Modules
これから新しく使うには相応しくないですね。
ファイル名からMIME Typeを取得する方法を紹介しました。標準ライブラリだけでも3種類有って、更にそれぞれカスタマイズ方法が違うってなかなかカオスな感じですね。
ScalatraのMimeTypesは、ファイルの内容に基づいてMIME Typeを推測する機能も有るので、次回はその方法について紹介します。
