- 制御機器を作りたいが、UI はリモートのブラウザで実現できちゃえばコストダウン出来るし使い勝手もいいなぁ・・・みたいな場合。
C++ なので、BSD SOCKET さえ用意されている環境なら実装できます。機器にゴージャスなタッチパネルを搭載しなくても事足ります。 - WindowsXP でしか動かせないハードウェアがありスタンドアロンアプリしか存在しない・・でも、効率化の為、リモートのブラウザで操作したい・・・みたいな場合。
C++ なら環境固有なコードも書きやすいので、ブラウザとの橋渡しという用途もありそうです。 - 流行りの言語を使ったアプリ開発をしたいが、どうしても低レベルな制御は必要。低レベルな箇所だけは C++ で書いて、上位レイヤとは WebSocket でやり取りをする。とか。
昨今の流行り言語ならほぼすべて WebSocket をサポートしてそうです。たぶん。 - シビアなタイミングが要求されるようなケースで C++ を選択せざるを得ないが、UI はブラウザを使ってラクに作る。みたいな場合。
JSONパーサーを GitHub で公開してみました。C++11 での実装です。
とはいえ、世には沢山のJSONパーサーが存在している上に Boost.JSON も出来たようですし、いまさら？ というご感想ごもっともだと思います。
なので現実的には既存のものを採用すればよいと思うのですが、JSON の仕様は比較的シンプルなので自前実装もアリかなと思いました。
JSON にコメントを書きたいし、配列＆連想配列の末項のカンマ記述を許したい。という付加機能あたりと、JSON Pointer なる仕様も(緩く)実装しています。
C++11未満とストリーム入力のパースは切り捨てているので、コード量は少な目だと思います。
昨今のライセンス事情よくわかっておりませんが、いちばん緩い条件と思われる CC0 にしています。
Boost.JSON が出来たことで、C++界隈でJSONを扱う場合はコレが本命になるのかなーと漠然と思っています。
となると Boost.property_tree のほうの JSONはどうするんだろという疑問もわきます。
property_tree には XML の実装もありますが、どちらも property_tree っていうデータ構造に対するちょっと便利な付加機能っぽい印象だったので、用途が違うのかなとも思いました。
弊社の PC の中ではかなり高価な部類に入る Mac mini (2018) が文鎮化しました。
電源入れると数秒で電源が落ち、勝手に電源が入り・・落ち・・を繰り返す・・。
リカバリモードやセーフモードにも入れず再起動を繰り返す・・。
外付けHDDからの起動（起動ディスクを選択するとこまでは動くので）でも再起動を繰り返す・・。
インターネットリカバリもダウンロードし終えたあたりで再起動を繰り返す・・。
「mac 文鎮化」で検索すると出てくる SMC、NVRAM/PRAM クリアなども全て効果ナシ・・。
文鎮化の原因にもまったく心当たりがなく、やったことと言えば前日に macOS Big Sur 11.0.1 を 11.1 にしたくらい。
が、特に問題なくアップデート出来たのでこれが原因とは考えにくい。（MacBook Pro だと危ない的な記事は目にしましたが。）
appleサポートとのやり取りでも解決せず「修理に出して下さい」という結論に。
しかし当方 AppleCare なんて未加入。買い替えられるくらいの修理代金を覚悟すべきか・・・。
・・・というのが昨年末頃の出来事で、どんよりした気分で新年を迎えました。
が、今年に入って Apple Configurator 2 なる存在を知り、これで復元を２パターンほど試してみたところ、たぶん無事に復活しました！嬉しいです。ありがとうございます。
このツールの存在すら知らなかった自分猛省しつつも、2021年 幸先良い滑り出しとなりました。
皆様におかれましても幸多き一年となりますようお祈り申し上げます
本年もよろしくお願いいたします
10年以上利用していた さくらの専用サーバー が11月末で終了とのことで、運営していた各サービスの引っ越し等々でここ数か月バタバタしていましたが、まぁたぶんなんとか無事に引っ越しを完了出来ました。
その当時、まだ懐疑的な声が多かった（と思う）ながらも仮想化を採用したので、引っ越しも比較的容易なほうだったんだと思います。とはいえバタバタしました。
割り当てられていたグローバルIP（計9個）は何をどうやっても使い続けられない。現行サービスに移行もできない。と、さくらのサポート様はおっしゃり、
お困りなら専門窓口(別業者様?)を紹介しますとのことで、その窓口の方と話をしたけど、特別な権限をお持ちなわけでもなく、出来ることは一般ユーザー（=当方）と同じだそうで、なんだかなーと。
とはいえ、この手のインフラサービスも終了することがあるということを実体験で思い知ったことだけはプラスだったかも。
もし、AWSサービス終了！なんてことになったらどうなっちゃうんだろうとか考えるようになりました。
AWSが終了するなんてことは今は想像も出来ないですが、10年後どうなってるかなんて誰もわかりません。
AWSの各種機能に乗っかり、それを前提に組んだ環境は、そう簡単に他のサービスに引っ越せません。
手間いらずな良く作られているサイトほど誰もメンテ出来ないって事もあるあるです。
そう考えると、引っ越しが出来ないって理由でインフラ業者のサービス終了と同時に閉鎖せざるを得ないサイトも沢山ありそう。
だからと言って、じゃあどうすりゃいいのかはわかりません。便利なサービスを利用しない訳にもいきません。
なので、サービス終了に限らず、値上げとか、仕様変更とかとか、
胴元様（プラットフォーマーっていうのかな）の一挙手一投足にビクビクしながら使っていくしかないかなと。
ちょっと違うかもですが、googleフォト有料化とか、youtube仕様変更でユーチューバーの生活が・・とか、
ユーザー囲い込みビジネスが多い昨今、１企業のさじ加減一つで影響を受けまくる事例も多いですが、根っこは同じなのかなと。
みたいなことを、ぼや～っと思った次第です。ありがとうございました。
こちらの写真。
おわかりいただけただろうか・・・・・
バッテリーがパンパンに膨れ上がっています。
今にも破裂しそうな雰囲気を醸し出してて怖かった記念に激写してみました。
このPCは、スマホと違って準はめ殺し形式（と言うのかな。工具使って本体を開ければ取り出せる程度の作り）のバッテリーなので、取り外してACアダプタ駆動でいちおう使えています。
当社は2019年12月3日に設立20周年を迎えるに至りました。
これからもお客様にご満足頂けるよう、職員一同で励んで参ります。
今後ともご指導ご鞭撻を賜ります様、心よりお願い申し上げます。
有限会社シンクリッジ 職員一同
FreeNAS の他にもNASソフトウェアはありますが、諸々の条件を考慮すると FreeNAS に自分としては落ち着きます。
NASとしてRAIDや定期スナップショットやレプリケーション機能がある他に、Docker と bhyve っていう仮想 PC までサポートしてるので オンプレサーバーとして必要最小限な機能が１台の PC で（スペックは奢る必要がありますが）事足りてしまいます。
そして、複雑なことさえしなければ全てブラウザ上で操作できちゃうので、自分のように物覚えの悪い人間にはピッタリ。
このキャプチャは、FreeNAS + bhyve で CentOS7 を動かしているトコです。
ただ、FreeBSD ベースなのと bhyve っていう VM 機能が、自分の知識不足なため扱いが少々不安。開発者の方々に感謝しつつ精進します。
自動アップデータ兼ランチャーを GitHub で公開してみました。
magome で作った自動アップデート機能を、目的や内側のアルゴリズムはそのままに、VisualStudio2017、boost など今のテクノロジでコマンドラインツールとして焼き直したものです。
そもそもはその当時スマホアプリとか、PCアプリの chrome とかもそうですが、ユーザーが意識することなく自動でアップデートして常に最新を利用出来る！ってイイネと思ったのが始まりです。
当時のPCアプリは（今もそうかもですが）、アップデートするときはユーザーが能動的にダウンロードしてインストーラを起動して指示に従う。というのが主流でした。
が、そんなことを意識しなくても勝手に最新になってほしいなと。（勝手にアップデートされたら困るケースがあることも承知しています・・）
Windows には ClickOnce というのもあったけど使い勝手も悪くイマイチ流行らなかった（ような気がする）し・・。
で、アプリの自動アップデートです。
差分を配信する為に配信専用データを作るための専用ツールとか、サーバーに配信用アプリをインストールとか、そういうケースを見てきました。
が、ものぐさな自分的には敷居高すぎます。なので、
手間なく！ミスなく！お手がるに！ってことを重視して以下の感じにしました。
・アップデータ作成は、アプリのファイル群を一般的なツールで ZIP に固めるだけで完成！
・配信サーバーは最低限の web サーバーで可。サーバー側に配信アプリをインストールとかは不要。
・アプリは起動時にサーバーをチェックしてアップデータがあれば勝手にアップデート。
・ダウンロードするのは更新に必要な最低限のファイルのみ。
です。
作ってみたら結構便利で他でも使ってました。
特に業務アプリでは、勝手にアップデートして常に最新、全ユーザーが同じバージョンを使うってことを有難がる場合は多いです。
これはオンラインゲームとかでもありがちな要求な気がします。
というわけで使えるケースがあれば使ってみて欲しいなと思います。
が、込み入った状況など、そのままじゃ使えない場合も多いと思いますので、そんな場合はお気軽にご相談頂ければと思います。
最後に。
C++ の仕様を作ってる方々、boost などのライブラリを開発している方々に感謝です。
WebSocket っていう単語をネットで見るようになって数年経ちますが、すごーく興味がありました。
これまで、HTTP だと不向きなケースで、BSD SOCKET や Winsock を使ったオレオレプロトコル(っていう表現が正しいかはわかりません)で実装をしていたことがありますが、この場合、サーバー側のみならず、クライアント側もソケット API のレベルから同じくらい労力かけて作る必要があります。
がしかし、WebSocket を採用することでコストダウンという可能性が増えるだけでなく、いろいろな選択肢が出てきます。
WebSocket は HTTP と何が違うかというと、一番の違いは、サーバーからのプッシュ通信は不可能だったのが(って言い切っちゃうと反論ありそうですが、そこはすみません)、WebSocket では可能になったことだと思います。
高々それだけの違いかと感じるかもですが、自分はすごーく大きいことな気がするんです。
というわけで、備忘録兼ねて C++ で WebSocket サーバーアプリのテストコードです。boost::asio を使わせてもらっています。
Windows (VisualStudio2015) 及び Linux (gcc) での実装を作ってみました。なおクライアントはブラウザ(javascript)です。
https://github.com/tr-takatsuka/TestWebSocketChat
ネットの記事などを見ると、WebSocket と言えば node.js で組むのが一番メジャーなのかなーと思います。次点で Ruby とか Python とかでしょうか。
なので、「いまさら C++ でサーバー？ しかも WebSocket！？ぃゃぃゃぃゃぃゃ・・」という声もありそうな気がしますが、きっとニッチな活用場所があるだろうと思っています。
今後は C++ + WebSocket も選択肢の一つとして提案していきたいなーと思った次第。よろしくお願いいたします。
PukiWiki にファイルを暗号化する機能を追加してみました。
GitHub で公開していますので興味のある方は見てみてください。
https://github.com/tr-takatsuka/PukiWikiEf
自前サーバーで運営する分には、わざわざ PukiWiki の機能としてファイル暗号化をせずとも、OS の暗号化機能で同じことが出来るんですが、レンタルサーバーなど、他者が管理してるストレージを使うような場合に、「それで情報は守られるか！？盗まれることはないのか！？」っていう意見が少なからずあるんじゃないかなーと思いますし、その懸念はおっしゃる通りな気がします。
PukiWiki を利用するにあたり、そのあたりの懸念を多少は払しょくできる材料になるかもしれないなと思います。
昨今の CMS は DB を使うものが多く、そうなると DB の暗号化を考えなくてはなりませんが、レンタルサーバー等、利用者からは手を出せない場合が多いです。
PukiWiki は DB を使わないのでそういう面では有利なのかなーと思います。
PukiWiki 開発者様に感謝です。
・・・
最近は amazon を筆頭に google や microsoft などの超有名企業から、さくら や GMO など老舗業者はもちろん、あまり耳にしたことないような企業も、各種クラウドサービスを提供しています。
きっと利用者の情報は漏れないよう色々対策しているとは思うんですが、どういう対策をしているのか、あるいはしてないのかっていう具体的な説明はほとんど見たことがありません。（約款とか小さい文字を隅々まで読めば何か書いてあるのかな・・・）
が、時代的にクラウドサービスを利用することは当たり前になってきたので、例えば AWS を利用するって提案したときに、「 AWS！？ サーバーは何処に置くの？ HDD は暗号化されてるの？ そこの社員には情報筒抜けなんでしょ？危なくない？ 」なんてことを気にすることも少なくっているのかなーと思います。
だからどうだっていう訳ではないですが、時代の流れを感じます。