All posts by Kenji

ネオスチグミンが最大濃度配合された目薬


ネオスチグミンが最大濃度配合された目薬を探してみましょう。 「ネオスチグミンって何?」という方は目薬に含まれる成分の効果をご覧ください。

最大濃度

そもそも最大濃度ってどれくらいなんでしょうか。 この記事を書いている時点で、一般用眼科用製造販売承認基準という基準では 0.005% です。 というのも 一般用眼科用製造販売承認基準で最大濃度配合と記載されている市販の目薬の説明書を見ると ネオスチグミンメチル硫酸塩 の含有量が 0.005% または 100ml 中 0.005g と記載されているからです。

ネオスチグミンメチル硫酸塩を最大濃度含んだ目薬

ネットで検索したところ 下記のものが見つかりました。 本当はもっとたくさんありますが、書ききれません。

第二類医薬品

第三類医薬品

こうして見ると 「ネオスチグミンメチル最大濃度配合」 というのは さほど特別なことではないと思えてきませんか?

目薬を選ぶ基準

ネオスチグミンメチル硫酸塩について差がなかった上の製品について 別の視点から比較してみましょうか。 血管収縮材なんて絶対にいやだ! という人は第三類医薬品ですね。 ではひとまず上に挙げた第三類医薬品について比較してみましょう。 単位はパーセントです。 パーセントで表示されていない製品については 1ml を 1g と仮定して計算しています。

第三類医薬品 成分比較表
ロートゴールド40マイルド マイティアフレッシュ40 サンテ40ゴールド サンテ40プラス
酢酸d-α-トコフェロール (天然型ビタミンE) 0.05 0.05 0.05 0.05
メチル硫酸ネオスチグミン 0.005 0.005 0.005 0.005
パンテノール (ビタミンB5) 0.1 0.05 0.05
ピリドキシン塩酸塩 (ビタミンB6) 0.05
L-アスパラギン酸カリウム 1 1
アラントイン 0.1
マレイン酸クロルフェニラミン 0.03 0.03 0.03 0.03
タウリン 1 0.5 1
コンドロイチン硫酸エステルナトリウム 0.5
イプシロン-アミノカプロン酸 1

大容量を選ぶならロートゴールド40マイルド (ロート製薬)です。 ほかに気にするとすればビタミンB5、タウリン、アラントインですね。 組織代謝が活発になるそうです。 アスパラギン酸カリウムは酸素を眼に送るのに役立つそうです。 酸素が大切っていう話は『目は1分でよくなる!』に載っています。 コンドロイチンは角膜保護、アミノカプロン酸は炎症を抑える働きがあります。

では次に第二類医薬品を見てみましょう。

第二類医薬品 成分比較表
スマイル40EX ゴールド デジアイ ファルチロン サンテメディカル10
レチノールパルチミン酸エステル (ビタミンA) 33000単位
酢酸d-α-トコフェロール (天然型ビタミンE) 0.05
メチル硫酸ネオスチグミン 0.005 0.005 0.005 0.005
フラビンアデニンジヌクレオチドナトリウム (活性型ビタミンB2) 0.05
パンテノール (ビタミンB5) 0.05
ピリドキシン塩酸塩 (ビタミンB6) 0.03 0.1 0.1 0.05
タウリン 0.1 1 0.5 1
ナファゾリン塩酸塩 (ビタミンB6) 0.003 0.003
L-アスパラギン酸カリウム 1 1 1
マレイン酸クロルフェニラミン 0.03 0.02 0.03
塩酸テトラヒドロゾリン 0.01 0.03
シアノコバラミン (ビタミンB12) 0.02 0.02
コンドロイチン硫酸エステルナトリウム 0.1
イプシロン-アミノカプロン酸 1
グリチルリチン酸二カリウム 0.1

ビタミンAだけパーセント表記にしていません。 スマイル40EXは市販目薬で唯一ビタミンAを含んでいるものだそうです。

有効成分がたくさん入っているのはよさそうに思えますが、たとえばナファゾリン塩酸塩には血管を収縮させて充血をとる働きがありますので、健康的にいいのかは疑問です。

ちなみに私は スマイル40EX マイルドを使っています。 よく効いている気がします。


How to Develop Test Code in Test-Driven Development


The reference book is Test Driven Development By Example [ Kent Beck ], and the Japanese version is テスト駆動開発入門.

This time, let’s talk about the essence of testing. I wrote down the important points while writing tests, implementing code, and adding functionality. This is a continuation of the procedure for writing tests first in test-driven development.

Write Asserts First

When writing tests, it seems best to start with Asserts. Indeed, starting from the goal is a common practice.

When starting with Assert, the first two things to consider are:

  • What is the right answer? (What makes it correct?)
  • How am I going to check it? (How do I check it, and what value do I check?)

Looking at the examples in the book, you can see that they start with these two points, write tests using non-existent classes from the Assert part, and finally complete the tests.

Test Data

According to Kent Beck, there are also rules for the data used in tests. It is said that easily understandable data, such as 1 or 2, should be used if possible.

Also, depending on the system, real data may be used in testing. Kent Beck mentions that real data is particularly effective in the following cases:

  • When testing real-time systems that use data output from other systems in operation.
  • When comparing output between the program before the change and the program after the change.

It’s not a particularly difficult topic, but let’s organize it in our minds for now.

Rules for Implementing Tests

Test code may deviate from general programming rules. For example, magic numbers. This is because the purpose of testing is to complete the implementation code and obtain feedback from the test as needed. As mentioned in the “MONEY EXAMPLE” chapter, they initially completed the test by using magic numbers.

The methods enumerated in the “MONEY EXAMPLE” chapter are explained again. There are “Fake It” and “Triangulation,” but the one you must understand first is “Fake It.”

Fake It (‘Til You Make It)

An example from when a testing framework was created in Python is introduced on page 102 of the English version. The part where the test code gradually changes from being fake is reprinted.

Kent Beck lists the following two merits of “Fake It.” The second one was also mentioned a little earlier.

  • First, by making the test green, you can be confident in your code. You don’t have to worry unnecessarily.
  • Even if it’s obvious, by writing tests and making them green, you can easily see what functionality is currently lacking.

From there, the discussion continues to “Triangulation.” Since it’s a review of the story that appeared in the “MONEY EXAMPLE” section, I’ll skip it.

Adding Parameters

There is an example of how to write test code when adding functionality after the test is completed, such as changing from sum(int value) to sum(int[] values). Of course, it’s an artificially created method, so there are some unnatural parts, but you should grasp the overall flow.


テスト駆動開発でテストを先に書く手順


Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う

参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。

今回読むのは Section III のところです。 テスト駆動開発のパターン について書かれています。

Isolated Test

Test の独立性についてですが、 Kent Beck は過去の経験から次のように綴っています。

First, make the tests so fast to run that I can run them myself, and run them often. That way I can catch errors before anyone else sees them, and I don’t have to dread coming in in the morning. Second, I noticed after a while that a huge stack of paper didn’t usually mean a huge list of problems. More often it meant that one test had broken early, leaving the system in an unpredictable state for the next test.

続けて書かれていますが、 ひとつの問題が発生した場合に失敗するテストはひとつであるべきです。 問題の特定を楽にするために。

そんな独立性の高いテストを作る手頃な方法として、 “実行順序に依存しないテスト” が挙げられていますね。

テストを書く前に ToDo List

Kent Beck は彼の経験から、 目的を達成するためには (プログラムで実現すべきことを実現するためには) やることを全部書き出すというのがいい と結論づけています。 Money Example の中でも ToDo List を作っていました。

ToDo List のメンテナンスにも注意が必要です。 Kent Beck は新しい ToDo が増えたとき、 既存の ToDo 含め 次の3つのカテゴリに分けます。

  • いまやる
  • あとでやる
  • できなくてもいい

テスト駆動開発において ToDo List に書かれるのは Test として実装するべき事項です。 具体的には Section IMoney Example に載っていたものです。

ToDo の書き方

Kent Beck は 大変丁寧なことに、 ToDo の書き方まで説明してくれています。 これは早く実践していきましょう。

  • 考察が必要な項目については “???” をつける。
  • すぐに実装に取りかかれるように書く。
    1. 実装が必要な演算についてテストケースを書く。
    2. もし実装前の演算であれば、 その演算の null version (特殊な場合) のテストケースを書く。
    3. 必要だと思うリファクタリングをリストアップする。

なぜテストを先に書くのか

Kent Beck はテストを先に書く理由について、 次のように書いています。

  • コードを書くプログラマとしてのゴールは機能追加であってテストを書くことではないため、実装の後(目的達成後)にテストコードを書くことはない。 (目的達成後にテストを書こうと思わない。)
  • (コードの)デザインについて考える時間が必要。
  • スコープを制御するためのメソッドが必要。 ここでいうスコープは、後のページで詳しく説明が出てくるが、要するにテストを順次グリーンにして、今実装すべき機能(スコープ)を整理するということ。

確かに、 実装が先に終わってテストがおまけになってしまう、 そんな経験が多々あります。 更に Kent Beck は テストのモチベーションのサイクルについても言及しています。 テストのモチベーションは開発者にとって一番大事かもしれません。

Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う