わたくし、チームみらいのことを党首・安野氏が都議選に立候補したときから応援しています。
今回も出来る限り当選を伸ばしてほしいのですが、そんな折、候補者の中に母校のOBがいるということを知り、俄然応援スイッチが入りました。
林たくみ｜チームみらい東北比例ブロック公認候補
衆院選比例東北ブロック公認候補/1997年生まれ28歳/「未来は明るいと信じられる国へ」/北海道教育大学→私立学校職員(東北)/趣味：筋トレ/好き：甘いもの全般
(01/31時点 ツイッター(現X)のbioより転載)
LINK: https://x.com/TakumiHayashi
教育大から教員経験を経てみらいの一員として立候補...
こんなん応援するしかないですわ。
残念ながら選挙区が東北比例なので直接的なことは何もできませんが、是非とも当選に向けてやり切ってほしいと願っております。
]]>
消費者観点では、シンプルに「商品が10%高くなる税」としか見えませんが、事業者にとってはそう単純ではないものになっています。
ここでは仕組みの詳細は割愛しますが、会計ソフトベンダーのBlog記事やAI解説に詳しいので、是非そちらを参照ください。
今日の日経新聞の記事に、農林水産業者の77%の方が免税事業者であるという驚きの内容が記載されていました。
わたくし、勝手にもっと売り上げているイメージを持っていました。
記事の主眼は、食料品の消費税が0%になったときに生じる免税事業者の収益低下についての問題提起だったのですが、もっと驚いたのが、JAがインボイス発行を肩代わりする制度がある、ということでした。
農媒介特例（農協特例）というものだそうで、本来は業者と生産者の間で細かい請求書のやり取りが増えるのを防ぐため、JAが請求を一元化する、というところから来ているそうです。
JAがインボイス発行を肩代わりするので、業者は消費税額を控除できる。
生産者は適格事業者になる必要がないので免税を継続できる。
なるほど。
いや、しかし、ということは、JAは仕入が非インボイスになるわけだから、仕入分の控除が出来ず、生産者分の消費税を丸かぶりしてるのか!? という疑問が。
それが、これも、「農協が農家から無条件で委託を受け、共同計算（プール計算）を行う場合に限り、「その農協が扱う農産物は、個々の農家が登録しているかどうかにかかわらず、全体としてインボイスの対象とする」という特別な法的許可が与えられているのだそうです。
それがあるなら、農協も控除を適用することができます。
農業に補助が手厚いことには異論がないのですが、それにしても色々な制度があるものです。
]]>このBlogをDocker上で動かすためにNginxのイメージを探していたときは、豊富にOS+アプリのイメージが御用意されていたので、有難くアレコレ比較検討させて頂くことが出来ました。
ところが、WindowsOSがベースとなると、「公式」のイメージというものが何のアプリであっても見当たりません。基本的にDockerのイメージはLinuxでの提供となっているものなんだそうです。
仕方がないので、自前でイメージを焼く準備を行ないました。
WindowsCoreのOSイメージに、OTNから落としてきた19cのバイナリを組み込むDockerfileと各種設定用スクリプトを書きます。
NginxのときはPerlのモジュールをDockerfile内でgetしていましたが、ダウンロードサイトがAPIに対応していない場合や対象が大きすぎる場合は予め落としておく必要があります。
何かあったら都度ダウンロードしてきて作り替えとなりますので、なるべく重ね焼きしない方針にて。
しかし、build中にスクリプトが詰まること詰まること。
Gemini君と二人三脚で、何とかかんとか稼働状態まで持ち込むことが出来ましたが、とにかく大変でした。
完成品はメモリもディスクも半端なく消費する巨大コンテナになってしまいましたが、これで自分の好きなようにスキーマを作ったり捨てたりできる環境の出来上がりです。
なお、OTNライセンスに則り、作成したイメージは自分のPCで開発・テストに使うのみとしています。 ただDockerfileを配るのはアリなようなので、それは社内で共有してもいいかも。
]]>簿記3級では、消費税は"仮受/仮払消費税"に仕訳すると学んでおります。仮受と言うなら消費税は預り金と言っていいのでは？
これはどういう理由だろう...？と思い、その方の主張を追いかけてみたところ、意外にも法律や裁判例に基づいた論拠がいくつかあったようです。
結果的に、会計処理的には預り金的な扱いをした方が合理的だが、実務・法律的には預り金ではない、というコトになっているようだ、という理解に落ち着きました。
同じように販売価格に掛かるたばこ税や酒税ではこの手の議論が発生していない印象ですが、何が違うのでしょうね。仕入控除の概念の有無でしょうか。 ちょっと面白い。
"読み"について、英語圏の技術サイトを読むことを続けているので、聞いたことを理解するとこまでは何とかなるのですが、"書き"の方を高校卒業以降ほぼ使っていないため、回答が口から出てきてくれません。
出るのは冷や汗ばかりなり。
ということで、簡単な英作文の練習を兼ねて、仕事中、Gemini君に質問するときは英語を使うようにしています。
と、初級者がレベルを上げるには意外と適した条件が揃っていると考えています。
ネックは語彙力で、英単語が出てこないことでスムーズな質問が出来ない局面が多いです。
また、意図を汲んでくれるのは良いのですが、我流のまま育つのもあまりよろしくない。
ということで、Chromeの補助ツールを導入することにしました。Google翻訳とDeepL翻訳のプラグインです。
テキストの選択箇所を日英・英日変換してくれるツールで、辞書にも翻訳機にもなります。特にDeepLは「推敲」までしてくれる機能があり、一旦書くだけ書いたものを添削してもらうことで、直しどころを確認できるスグレモノです。
どちらも、「何の言語に変換するか」の設定が固定になるので、Googleの方を英→日、DeepLの方を日→英の専用として使い分けています。
これらのおかげで、日常での英語のI/Oが急激に増えました。
昔買った英語参考書をもう一度入れなおそうというモチベーションも出てきています。
なお、英語圏と日本語圏では持っている情報の厚みが違いますので、技術的なことは英語で聞いたほうがいいの？と質問してみたところ、一旦日本語を英語に変換して考えた結果を日本語に戻しているから、結果に大きな違いはない、とのことでした。
それはそれですごい。
Gemni君に英語で質問するときのコツを、本人に聞いてみました。
Geminiへ英語で質問する際、実は「結論（やってほしいこと）から入る」のが一番の近道です。
日本語だと「〜について伺いたいのですが......」と謙虚に始めがちですが、AI相手（特に英語圏の作法）では、最初にアクションを指定してあげると処理の精度が上がります。
結論から言うと、'Tell me' は全然OKです！ただ、やりたいことに合わせて動詞を変えると、より意図が明確に伝わります。
| やりたいこと | おすすめの書き出し | ニュアンス |
| 教えてほしい | "Tell me about..." | シンプルで汎用的。 |
| 説明してほしい | "Explain..." | 仕組みや理由を知りたいとき。 |
| リストアップして | "List..." / "Give me 5 examples of..." | 箇条書きでほしいとき。 |
| 要約して | "Summarize..." | 長い文章を短くしたいとき。 |
💡 ワンポイント: > 丁寧にするなら "Could you tell me...?" ですが、AI相手なら "Please tell me..." くらいで十分フレンドリーかつ効率的です。
はい、'In Java,' から始めるのは非常に賢いやり方です！
AIは最初の数単語で「あ、今はプログラミングの話だな」とコンテキスト（文脈）を判断するので、最初に言語を指定するのは大正解です。
「Javaで〜の問題がある」と伝えたい時は、以下のようなパターンがよく使われます。
コンテキストを先に置く場合
"In Java, how do I [やりたいこと]?"
（Javaで、[〜]をするにはどうすればいい？）
エラーが起きている場合
"I'm getting an error in Java when I..."
（Javaで[〜]をした時にエラーが出ます）
コードの書き方を聞く場合
"Can you show me a Java example of..."
（[〜]のJavaのコード例を見せてくれる？）
もし複雑なことを聞きたいなら、この順番で書くと完璧です。
Role (役割): Act as a senior Java developer. （ベテランJava開発者として振る舞って）
Task (タスク): Explain why this code returns a NullPointerException. （なぜこのコードがNullPoを返すのか説明して）
Context (詳細): Here is my code: [コード貼り付け] （コードはこれです）
Writing a tech blog that people actually want to read--rather than just scan for a code snippet--is about balancing high-level expertise with a human touch.
You want to move away from "Instruction Manual" vibes and toward "Coffee Shop Mentorship."
Here is how to craft a tech blog that feels approachable, insightful, and polished.
Most tech blogs start with a dry definition. Instead, start with the why.
Tech readers are busy.
If they see a "wall of code" or a "wall of text," they'll bounce. Use your formatting toolkit to create a sense of rhythm:
Avoid being overly formal, but don't be patronizing. Aim for the tone of a senior dev explaining a concept to a talented junior.
Bad: "One must execute the following command to initialize the repository."
Better: "Go ahead and run this command to get the repo up and running."
Authenticity check: Read your draft out loud. If you wouldn't say a sentence to a friend over lunch, rewrite it.
Don't just dump a 50-line block of code.
Perfect tutorials are suspicious. A "nice feeling" blog acknowledges that tech is messy.
Pro Tip: Mention a mistake you made during the process. It builds trust and makes the reader feel less alone when they inevitably hit an error.
ということで、Gemini君を働かせて、いかにもなCONTACTページを作成してみました。HTML作成が自分の弱点なので頼りになります。
バックエンド側は、普通の設計だと、GmailのSMTPサーバと連携して自分のGmailアカウントにメールで送る、くらいのつくりになるところですが、良い機会なので、このVPS上に自前でメールサーバ建ててみることにしました。
number64.netドメインでメール送受信するのはロマンがあります。
しかし...
Gemini君と壁打ちしながら調査を進めたのですが、
単に「メールを送受信できるようにする」だけでは全く足りず、「如何に相手に迷惑メール扱いされないか」を担保するために、多くの課題をクリアしなければならず、また日々のサーバのお守りに非常に労力が掛かる、ということが判明しました。マジですか。
大変残念ですが、来るか来ないか分からないメールのためにそこまで労力を掛けられませんので、メールサーバは断念しました。
とはいえ。 折角だから何かちょっと変わったことをしたい、というのが諦めきれず。
しつこく調査を続けたところ、LINEの公式アカウントにAPI連携でPUSH通知する、という手があることが分かりました。
これは面白そうです。形式的に契約した業務電話用SIMがこんな形で役立つことになりました。 早速公式LINEアカウントを開設し、Developer登録を行ないました。API連携はMTのために組み込んでいるPerlから投げます。
セキュリティ面を考慮してバックエンド機能をリファクタリングするなどゴニョゴニョやって...
来ました! Hello World!
半分以上は手段が目的化している気がしなくもないですが、楽しいからヨシ！としましょう。
]]>お問い合わせを送信して頂くためのフォームを実装しているのですが、このページにGoogle reCAPTCHAを組み込む工事を行ないました。
reCAPTCHAというと、「私はロボットではありません」チェックからの「この中の自動車の画像を選択してください」のフォーマットのイメージがありましたが、最近では、サイト上での"動き"を分析して、それが人かbotかを見分けることが出来るようです。
自動判定してくれるなら、利用する方がいちいち画像を選ぶ手間を掛ける必要がないので、より好ましいです。
ということで後者の機能で行くことにして、Googleに利用者登録からの、MTのWebページ構成にスクリプトを組み込んで完成です。
サイトのアクセスログを眺めていると、こんな過疎サイトでも本当に様々な不正狙いのアクセスが発生しています。
これで多少安心してお問合せフォームを公開することができます。
そのミニデスクトップ上でDocker Desktop(以下DD)を稼働させ、Blogサイトの実装を進めてるたのですが、最近、MovableType(以下MT)で「再構築」を実行したとき、処理性能にかなり差があることに気付きました。
ミニは安物とはいえ、さくらVPSの最安プランよりは潤沢なスペックがあります。何でこんなに重いのか...? とGemini君に相談してみたところ、興味深い回答を得られました。
直接の原因は、DDのvirtualization boundary(仮想化境界)にありました。
DDのLinux仮想マシンとWindowsのホスト端末の間でファイルI/Oを行なう際には、ファイルシステムの差異を埋めるため、ファイル共有プロトコルが介在してきます。
私の環境では、MTが生成するコンテンツ群を、コンテナ外部の領域にアウトプットする設定にしているため、Blog再構築処理で大小多数のファイルが生成されると、1ファイルあたりに掛かる小さなオーバーヘッドが積み重なり、処理時間が大きく遅延することになるのです。
ホストOSがLinuxの場合は、Dockerはファイルを直接I/Oできるため、この分の遅延が発生しません。
この問題を解決するため、WSL2上でLinuxOSを稼働させ、そこのファイルシステムにコンテンツをI/Oする、という手段を取りました。ディストリビューションはVPSに導入したものと同じDebianを選択（これは単に統一感のためだけ）。
WSLに入って、VPSと同じディレクトリ階層を作り、GitHubから資材をcloneして全く同じ環境を構築します。ここから同じようにコンテナを走らせ、ブラウザから再構築を実行させます。ファイル共有プロトコルが挟まらないため、本来の高速な処理が実現しました。
全く同じ環境を簡単に複製できるのが、Dockerの非常に便利なところですね。
]]>昨日まで問題なく成立していたTLS接続が突然エラーになる、という事象が発生することがあります。
原因の99%はサーバ証明書の有効期間がうっかり切れたというケースです（ただし1%の確率で、連絡なしで証明書の入れ替え作業が行われたことに起因するトラブルだということもあります)。
その手のトラブルを受け、サーバ証明書の有効期間について色々調べる機会がありました。最近は、証明書の自動配布サービスとの合わせ技で、証明書の有効期間を極端に短くする傾向があります。数日しか有効でないものをその半分くらいのサイクルで入れ替えていくそうです。
それにより、万一証明書が漏洩しても、すぐに無効になることで、ダメージを抑えることができます。
この流れが一般化し、大手CAが1年モノの証明書を発行してくれなくなってしまうときが来てしまうと、証明書の管理コストが増大しそうですね。
]]>いきなり矛盾するのですが、技術的な勉強も兼ねているため、Docker導入は外せません。
Docker入れる以上は他を削るしかなく、リニューアル前はコンテナ運用特化OSのRancherOSを使っていました。
しかし、RancherOSはとにかく便利機能も含めて極限までそぎ落としていて、Linuxにそこまで強くない私にはピーキー過ぎて乗りこなせていませんでした。しかも何年振りかで公式を見たらもうEOSしており...。
色々検討して、今回はベースをDebianで行くことにしました。比較的軽量な割に、充分使いやすいです。
また、Dockerに対して誤解があったのですが、ホストOSの資材とDocker上のコンテナが使う資材を共有化することで、複数コンテナ起動によるオーバーヘッドを抑止できるらしく、思ってたほどはメモリを浪費しないように出来るというのです。
ということで、ホストからコンテナまで全てOSをDebianに統一する作戦を立てました。
コンテナはNginxが2つとMariaDBが1つ稼働しています。
これまでは惰性でApacheだけ使っていたのですが、新しい知識を得る、またより軽量な環境を作るためNginxに切り替えました。やってみると思ったより理解しやすく、これは切り替えて正解でした。
フロントが2台なのは、先代のサイトが乗っ取りを食らったことの反省から、MT本体をNginxごと隔離・ポートも分けたうえで、mTLSでガッチリガードするためです。
記事投稿は決まった端末からしか行わないので、mTLSがピッタリハマります。証明書はオレオレですが防御力はほぼ完璧。
MTの仕様上、CGIを完全に分離するのがちょっと面倒だったのですが、そのあたりは機会があれば(記事ネタが尽きたら)書きたいと思います。
この構成で、安定状態で200MB程度しか使っていないので、軽量インフラ構成としては成功したかなと思います。
阿部寛の公式サイトのような軽みには及びませんが...
普通は売上が1,000万以上あるか、取引先からインボイスの発行を求められている事業者が登録を検討するものなので、今の自分の状況からすると必要性はミリも無い... というのは、それはそうなのですが。
兼業の目的の一部に「会計実務を色々経験する」というのがあったので、ここは消費税についても正面から向き合ってみよう、という意図から登録をした形です。
ランサーズやクラウドワークスにも一応登録はしているのですが、参照できる範囲だと適格取ってる事業者はかなり少数派なようですね。ちょっと大きなクライアントが相手だとインボイス要求されそうなイメージがありますが、無くてもいけるものなのでしょうか？
まあ、いずれにしても、今の兼業の方針だと売上も仕入も消費税の対象にあまりならなさそうなので、まずは制度を知るところから。
補記：Gemini君に教えてもらったところ、GooglePlayでのアプリ販売は消費税対象になり、むしろGoogleへのリバースチャージなどから却って複雑である、という有難いお言葉が...
そこで、いい機会なので色々手を出してみようと、中野区の地域追加「ナカペイ」取扱事業者として区に申請を出しました。
地域の祭りやフリマなどで、その場でタグにお好みのテキストを書きこんで手売りする、ということをしたい場合、ナカペイ使えると都合が良いと思ったのです。
個人的に、鍋横の夏祭りで基本的に現金しか使えなかったことに不便を感じた経験から、ナカペイ使えたらウケもいいのでは、という算段だったのですが...
区の担当の方から来たメールによると、ナカペイは、拠点を持って事業を行なっている事業者が対象であるとのことでした。
店舗を持っていないとしても、決まった場所（それこそ定期開催されるフリマなど）で販売するならまだ可能性があったそうなのですが、販路どころか商材も具現化していない私ではどうしようもない...という状況だったのでした。
ただ、申請を通す条件は把握できたので、商材が確立できたら改めて販路を探し、リトライしてみたいと思います。
]]>過去の案件で、CMSのひとつであるMovableType(MT)の構築運用をしていたことがあり、そこからMTでBlogを作っていました。
しかし、何年か前に不覚にもサイトの乗っ取りを食らってしまい、それ以降はMTを機能停止して開店休業という状態でした。
今回、OSの入れ直しから始めて本格的にリニューアルを実施します。技術的なメモも記事として残していこうと思います。
（※時系列的にインフラ完成以前の記事は完成後に遡って書いている形です）