tech

mdbファイルが破損している場合、最初のクエリ実行時にOleDbExceptionが発生します。 これをキャッチすれば破損を検知するロジックはとりあえず書けます。

社内のLinuxサーバは極力Ansibleで状態を管理し、サービスはDockerコンテナで運用している(DB除く)。いわゆるIaC(Infrastracture as Code)を実践しているつもり。 これの何が嬉しいかというと、正直なところ個人的にコマンド一発で全てが出来上がるのが楽しい、というところが大きかったりする。ピタゴラスイッチ、ルーブ・ゴールドバーグ・マシンを見ているような爽快感、とでも言うのだろうか。 そんな感覚はない場合、紙の手順書をコードに置き換えるのは面倒と感じるのもわかる。何が面倒かと言えばコードには曖昧さが許されないことだと思う。手順書は曖昧に書いて「言わなくてもわかるよね」という雰囲気で終わらせることもできるが、コードは書いたようにしか動かない。コードに落とすためには対象のプログラム・システムの仕様を正確に理解しないといけないし、何をもって正常とするのか、それはどんなケースでも正常と言えるのか、突き詰めて考えないといけない。この辺りが利用する組織や文化によって大きな壁になるのだと思う。 ただ、慣れてしまえばむしろ誰かが決めた書式・ルールに従って手順書を書く手間、変更された際に保守する手間もなくなるし、手元の仮想化環境などで簡単に再現してテストできる、最高の環境になる。

思い切ってKubernetesを構築、試験運用を始めました。Ubuntu Server 20.04のMicroK8sです。 docker-compose で動作するところは確認できていたので余裕かと思っていたのですが、はまってしまいました。 症状は、 CrashLoopBackOffで再起動が続く状態。これ当然まともにコンテナが起動せずに終了してしまっているからなんですが、手元の環境ではDockerfileとdocker-composeの合わせ技で奇跡的にうまく動作していたため、Kubernetes側の問題だろうとあれこれ調査して時間を浪費してしまいました。 KubernetesではDockerfileによるbuild済みのコンテナイメージを起動します。docker-composeに記載している処理は、Kubernetesのyamlに記載するか、Dockerfileに記載する必要があります。 が、Kubernetesのyamlに同じ内容を記述できるとは限らず、また記述できても同じ動作をするかはわかりません。ですので、極力Dockerfileに記載してdocker-compose.ymlはシンプルにとどめておいたほうがよさそうと感じました。 また、内部の名前解決用に使用しているDNSは、解決できないと8.8.8.8にforwardしてしまう。Kubernetesの外の社内サーバを名前で参照する場合には、dnsConfigなどの設定でforward先を変更する必要がある。 https://qiita.com/sugimount/items/1873d9d332a25f5b0167

過去に開発された内製アプリをC#+RDBMSに置き換えていて思うこと。 kintoneやPowerAppsのようなローコード、ノーコードと言われる分野のアプリで置き換えようとすると機能が足りず、ガッカリして断念している。 ふと思うのは、むしろAccessが高機能すぎるのではないかということ。特にVBAはやろうと思えばなんでもできてしまう。会社の前の基幹アプリはAccess VBAでできていたし。 Accessが目指すべきなのは、クエリ、マクロ、フォームの組み合わせでできることに特化すべきで、それ以上のことは別のやり方でやってください、とすべきだったのではと思う。VBAは禁止。クエリもGUIで組み立てられるレベルまで、サブクエリは禁止、くらいでちょうど良い。 WordやExcelのVBAは、普通に作る分にはUI,データソース共に限られるので問題にならないが、AccessはなまじDBMSとしてテーブル、SQLをサポートしているので複雑なことまでやろうとしてしまう。グラフもそれなりに書けてしまうし。 他の言語がここ十何年で目覚ましい進歩を遂げて入り一方でVBAがここ何年もほとんど進化していないのは、できることが多すぎてそれらを維持したまま進化させるのが難しいという一面もあると思う。メインの利用者が非開発者でそのような進歩を望んでいないことも大きいと思うが。 最新の言語を書いた後にVBAのプアな機能を使ってコードを書くのはとても辛い… Visual Studio Tools for OfficeもAccessはサポートしてないし。 ローコード、ノーコードアプリはスプレッドシートをデータソースとすることが多いので、AccessはExcelのみをデータソースとしてサポートする、くらいで良いと思うが、それってPowerBIだよねという話で、Accessはもはや不要な製品だと思う。 Accessの値段でAccessと同等の機能を持つ製品はなく、(自分も含めて)影響は大きいが、大規模な時代遅れなAccessのVBAの保守を任される開発者も、時代遅れなVBAを進化させることができずに細々とサポートするMicrosoftの開発者も不幸な今の状況を考えると、Accessは終了すべきと思う。長めの期間をとって移行のロードマップを示す必要はあるが。10年後にVBAバリバリのAccessアプリが残っている未来を想像したくない。

最近golangでプログラムを書いてます。普段書いている.Net Framework(およびエコシステム)と比較すると物足りないところも多いですが、Visual Studio立ち上げずにサクサクかけて、クロスコンパイルしてどこでも動かせるのは良いです。 要約 sqlx のnon-struct dest type struct with >1 columns (33) というエラーの原因は、構造体のフィールドの頭文字を大文字にするとよいかも 内容 本当に初心者なので全く分かっていなかったのですが、golangのtypeはメソッドを埋め込んだりフィールドにスコープがあったりして、JavaやC#のクラスに近い位置づけなんですね。 sqlxを使ってScanしてnon-struct dest type struct with >1 columns (33)のようなエラーが出る原因は、フィールドの頭文字を小文字にしていたため。フィールドを小文字にするとprivate扱いになるよう。