Takuya Sawada

@reconbot Thank u for developping such a nice library! I was very impressed with this library because it makes manipulating asynchronous serial communication devices very easy. But I have same...

@reconbot Sorry, it seems the issue is related to docker's behaviour. I'm tested this simple code below in docker container which is mounting `/dev/ttyUSB0` ```c:porttest.c #include #include #include #include #include...

@adids93 I had same issue, but in my case when i install the latest visual c++ runtime below, the problem was gone. https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

@Yangsin さんがおっしゃっているように 現在は、消費税の移行期間のため（2021年）3月31日までは外税表記も許容されていますが、すぐに特例期間も終わってしまうので外税表記に対応するメリットはもうあまりないのかなと思います。

@nanasess 要件によっては、商品コードを必要としない人もいるかもしれないので UNIQUE 制約をつけたりインデックスを貼ることには賛成ですが、NOT NULL 制約をつけることについては他の人の意見も聞いたほうが良いかもしれません。私の場合は、NOT NULL 制約がつけられても困らないですが。

@nanasess そうだったんですね。 情報共有ありがとうございます。 もちろん私は困らないので異論はないです！

@tao-s 私も以前から気になっていました。 また、逆にブラウザーのオートフィルで住所２が補完入力されても、 郵便番号の補完により住所２がクリアされてしまうという仕様も同時に不親切だと思っています。 利用しているライブラリの側で対応されるのが良いような気はしますが。

@nanasess 情報ありがとうございます。 時間があるときに、Codeception のテスト書いてみます。 既存のテストコードを編集するより、別ファイルで作った方が良いでしょうか？ どうやらテストはナンバリングされているようですが、ナンバリングの規則がよくわからないので好きな名前でテスト書いて別ファイルにした方が良いかなと思っています。

@nanasess phpunit の件は修正させていただきました。 まだ、codeception がコケていますが。 もともと、コードを書き換える段階で問い合わせフォームだけなぜかカナフィールドが必須ではないのが気になっていたのですが、他と統一した方が良いのではと思い勝手に仕様を変更していました。 なぜ、問い合わせフォームだけカナがもともと必須フィールドでなかったのかについては理由はわからないですが、設計者の意図があるようにも感じます。問い合わせフォームのテストでカナが必須ではないことを検証するようになっているので、ここの仕様は変えるべきではないと判断しました。私はカナフィールドいらない派なので、問い合わせフォームがカナを必須にできないことは私にとっては問題ではありません。 みなさんの意見を聞いて必要であれば、仕様の変更を検討したいと思います。

あまり EC-Cube の開発の歴史的なことについて詳しくなくて恐縮ですが、電話番号の WEB 上での表記や帳票類でのハイフンなしのフォーマットはあまり美しくないなぁと思っていました。国際化対応に向けての布石で現状のような形になっているのかもしれませんが、Google の libphonenumber 等を使って表示するときだけでも整形した方がよいのではと思います。