Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

A List of What Cannot JCache do

  • JCache cannot save the order of insertion. You should use LinkedHashMap for that purposes.
  • JCache cannot update whole entries in a cache atomically. You should use AtomicReference or some locking mechanisms for that purpose. (Ofcourse you can update a cache atomically if a cache has always only one reference.)
  • JCache doesn't offer read-write lock. You should use ReadWriteLock for that purpose.
  • JCache doesn't offer unmodifiable view of cache. You should use Collections.unmodifiableMap() for that purpose.

The meanings of word "cache" in software engineering

I think the word "cache" has so many different meanings in different contexts like below.

Note: In this list, the word "invalidated" means the source of cached value might be changed.

  1. Something like the cache in web browsers. The cache stores the result of each operation that had already called (Typically, these operations had cost large resources). The values in the cache might be invalidated partially because some input is volatile, but not coherent.
  2. Something like the result of precomputation. The cache stores the result of operations that programmers specified (because it will cost large time or memory). It might not be invalidated.
  3. Something like memoization. The cache stores the result of each operation that the programmers specified and had already called. It might not be invalidated but might be discarded because of time-space tradeoff (e.g. weak reference in Java). It should be coherent.
  4. Something like the in-memory views in RDBMS. The cache stores the values in files or tables that programmers specified, in order to reduce the cost of access or implement read-only view. It might be invalidated and must be coherent. It must be updated atomically.
  5. Something like on-memory copy of files. The cache stores the values in files or tables that programmers specified, in order to reduce the cost of access. Sometimes it might be invalidated, but the programmers can control the timing of invalidation. The coherency doesn't matter, but it must be updated atomically.
  6. Something like cache on CPUs or L2ARC. The cache stores the data that had already accessed, in order to reduce the cost of access. It might be updated or invalidated. It must be coherent, but doesn't have to be updated atomically.
  7. (Not in the table below) Something like on-memory data stores (e.g. memcached). The cache stores the values that programmers specified. It might be updated and never be invalidated (sometimes values are only in the cache!). It doesn't have to be updated atomically.

I tried to organize these concepts in a table like below:

Target of Cache Invalidated? Coherent? Atomic? Example
1 each no no no Memoization
2 each no no yes Memoization
3 each no yes no Memoization
4 each no yes yes Memoization
5 each yes no no Cache in Web Browsers
6 each yes no yes Cache in Web Browsers
7 each yes yes no ?
8 each yes yes yes ?
9 whole no no no Precomputation
10 whole no no yes Precomputation
11 whole no yes no Precomputation
12 whole no yes yes Precomputation
13 whole yes no no ?
14 whole yes no yes On-memory Copy of Files
15 whole yes yes no CPU Cache or L2ARC
16 whole yes yes yes In-memory Views in RDBMS

Difference of GitHub API and GitLab API

Format of Personal Access Tokens

  • In GitHub, personal access tokens are hex string, like e72e16c7e42f292c6912e7710c838347ae178b4a.
  • In GitLab, personal access tokens are like Base62 string, like 9koXpg98eAheJpvBs5tK.

Personal Access Tokens as OAuth2 Tokens

  • In GitHub, personal access tokens are used as OAuth2 tokens.
  • In GitHub, personal access tokens are different from OAuth2 tokens (There are also private tokens, but I couldn't find the way to get it).

HTTP Header for Authorization

  • In GitHub, personal access tokens are passed via HTTP "Authorization" header like Authorization: token e72e16c7e42f292c6912e7710c838347ae178b4a (also you can use Authorization: Bearer instead of Authorization: token).
  • In GitHub, personal access tokens are passed via HTTP "PRIVATE-TOKEN" header like PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK.

Query String for Authorization

  • In GitHub, you can pass personal access tokens via query string like GET /projects?access_token=e72e16c7e42f292c6912e7710c838347ae178b4a.
  • In GitLab, you can pass personal access tokens via query string like GET /projects?private_token=9koXpg98eAheJpvBs5tK.

HTTP Status Code for Authorization Failure

  • In GitHub, you will get 404 error when you failed to authorize (you cannot distinguish the authorization error from the other errors).
  • In GitLab, you will get 401 error when you failed to authorize (you can distinguish the authorization error from the other errors).

How to Specify a Project

  • In GitHub, you can specify a project by name, like GET /api/v3/repos/Project/Repository/pulls.
  • In GitLab, you cannot specify a project by name. You should use a project ID, like GET /api/v4/projects/12/merge_requests. You cannot see the project ID in the Web UI (You have to call API for project IDs, or see hidden tag in HTML source).

How to List All Comments in Pull Requests

  • In GitHub, you can list all the comments in pull requests like GET /api/v3/repos/Project/Repository/pulls/comments.
  • In GitLab, you cannot list all the comments in pull requests. You should specify each merge request and get comments like GET /api/v4/projects/12/merge_requests/42/notes (42 is the iid of a merge request).

情報システムの受託開発中に発見されたバグの情報の行方

まず、あなたの会社では、知財管理の関係から、「業務情報」の社外提供には役員レベルの判子が必要だとしよう(大きな会社の場合、これは非常にハードルが高い)。また、あなたの作業に対する支出はすべて、あなたが現在作業中のプロジェクトの財布から出るとしよう。

また、このバグは、OSS自体の修正なしに(ラッパーを書くとかで)回避可能であるとしよう。プロマネからは、OSS自体の品質保証の責任を負わないように、OSS本体に手を入れるのは避けること、という指示も来ているとしよう。

そんなに無茶な前提ではないと思うが、どうだろう?「OSSは利用上問題となるバグがないのを精査してから利用すること」「バグはそのうち誰かが直すか、過去に誰かが回避策を見つけてるだろ」みたいな考え方の会社なら、この程度は普通なんじゃないか?

さて、あなたはこのバグを業務アプリの開発中に見つけたので、このバグの情報は業務時間中に得られた業務情報と判断され得る。業務情報であれば、まず「これってバグかな?」という質問をそのOSSのフォーラムとかに投げることは、個人的な活動としては行えない。

「業務情報であれば」というより、公開されているソフトウェアの挙動に関する知識を「業務情報である」と判断している相手が社内にいた場合、「それは業務情報には当たらないのでは」という合意を形成するのが困難、という方が実態に近いな。

さて、ここで既に自分で当該バグの回避策を見つけていたとしよう。この場合、プロジェクトの職務上の作業として、同様の質問を当該OSSのフォーラムに投げる(で、誰かにBTSに登録してもらう)ことはできない。これは、プロジェクトの財布に影響があることに起因する。

すでに回避策があるのだから、その作業はプロジェクトの財布に対して追加の支出にしかならない。そのため、フォーラムへ投げるという作業内容について、プロジェクトの作業として妥当であるという説明責任が果たせない(プロジェクトの金を関係ない作業に流用したことになってしまう)。

では未解決の問題なら質問ができるかというと、そうでもない。開発用ツールのサポート契約に「提供した情報は問題の原因調査以外に使わない」等の条項があるケースなら、業務としての開発元への問い合わせにもOKが出やすいが、サポート契約のないOSSではそうはいかない。

次にBTSへの登録についてだが、これもフォーラムへの投稿と似たような理由で行えない。

じゃあいきなりパッチ書いて送り付けたらいいじゃないか、となるが、そうもいかない。バグの回避策としてラッパーを書いてたりすると、ラッパーの内容とパッチの内容がどうしても似通ってしまう。知財部門に「このソース社外に持ち出したでしょ、社則違反ね」と言われると切り返せない。

幸運にも知財部門がOSSにある程度理解があって「パッチ出すなら業務としてやりなさい(そこから生まれるうまみを期待してる)」と言ってたとしよう。今度は、開発作業の認可を出す部署が問題になる。

開発作業認可を出す部門の目標に「不要不急の開発は避ける」とかがあったりすると不幸で、知財部門は「出すなら業務として出せ」と言ってるのに、開発作業の認可をする部署は原価低減のために「じゃあそもそも出さなきゃいいじゃん」と言ったりする。

社内に緊縮財政が敷かれてたりすると、そういう目標が設定されがちですね。で、その結果、プロマネはパッチの作成と投稿に必要な工数をプロジェクトに積むことができず、「そのパッチの公開に必要な作業、誰のお金でやるの?」ということになる。

さて、幸運にもプロジェクトの財布に余裕があり、知財部門もプロマネOSSへのコントリビュートに対して理解があったとしよう。かなり幸せな環境だが、それでもパッチの提供はできない可能性がある。

業務アプリの受託開発では、お客様へソースを納品する際に「成果物の著作権はお客様へ譲渡する、開発元は著作者人格権を行使しない」という契約になってることがよくある。

そのため、問題のバグの対策用ラッパーを含むアプリをお客様へ納品した後では、パッチの提供可否の判断は自社では行えず、お客様の組織の役員レベルの判子が必要になるという、かなりな無理ゲーになってしまう。

また、お客様に納品する前にパッチをOSS本体へ組み込めたとしても、結果としてお客様に納めるソースにはOSSの一部によく似たコードが含まれることになる。お客様が自己監査でそのコードを見つけたときにどうなるかを考えると、パッチの提供はためらわれる。

開発の初期にOSSのバグを発見し、パッチを提供して、それが取り込まれた最新バージョンのOSSを使ってアプリの再テストを消化し納品、とトントン拍子で行けば、これまで挙げた条件をクリアできなくもない。

ただ実際には、そもそも開発初期に利用にあたって致命的なバグの見つかったOSSは「利用しない」という判断がされるだろうし、それにバグが見つかる頻度はテストケースの消化が本格化する開発中期以降の方が高いから、これは成立するケースの方が少ないだろう。

実際は、開発の初期にOSSに軽微なバグが見つかり、パッチをupstreamへ提供したらラッパーは削除、テスト環境は古いバージョンのOSSのままでテスト消化を継続。件のバグが再現するテストケースの消化は後工程まで保留するのが現実的かな。

その上で、パッチが取り込まれた最新バージョンのOSSがリリースされたら、正式なテスト環境は古いバージョンのOSSのまま、別に新しいバージョンのOSSを入れたテスト環境を立ち上げ、保留にしてたテストケースは但し書きつきでそっちで実行する、とかかなぁ。

新しいバージョンのOSSには、提供したパッチ以外の変更も入ってるだろうから、これまで積み上げたテスト結果について「新しいバージョンのOSSでも大丈夫です」とは言いにくい。修正箇所が限定される保証もないしね。

他にも、そのOSSへのコントリビュートって、プロジェクトの財布で賄うもんなの?という問題もある。アプリをお客様に納めるか、自社資産になるかで、プロジェクトにかけるお金は税制上の扱いが違うと思うのだけど、どうなってるんだろうね?ここは専門外なので、よく分からない。

とにかく、業務で使ってるOSSのバグ修正には、かようにややこしいハードルを色々クリアする必要がある、という話。じゃあどうしたらいいか、というと、各社どうしてるんだろうね?(投げっぱなしでおしまい)

You should disable Adblock Plus (Chrome) in Alfresco

Context:

Problem:

“New Topic” button on the discussion forum disappear.

Reason:

Adblock Plus added “display: none” to the area that has the “New Topic” button and the RSS feed button, if you subscribe some filter list.

Solution:

Set Adblock Plus to “Disabled on this site” on Alfresco site. This operation adds the site to the whitelist in Adblock Plus.