当社は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！？ぃゃぃゃぃゃぃゃ・・」という声もありそうな気がしますが、きっとニッチな活用場所があるだろうと思っています。
- 制御機器を作りたいが、UI はリモートのブラウザで実現できちゃえばコストダウン出来るし使い勝手もいいなぁ・・・みたいな場合。
C++ なので、BSD SOCKET さえ用意されている環境なら実装できます。機器にゴージャスなタッチパネルを搭載しなくても事足ります。 - WindowsXP でしか動かせないハードウェアがありスタンドアロンアプリしか存在しない・・でも、効率化の為、リモートのブラウザで操作したい・・・みたいな場合。
C++ なら環境固有なコードも書きやすいので、ブラウザとの橋渡しという用途もありそうです。 - 流行りの言語を使ったアプリ開発をしたいが、どうしても低レベルな制御は必要。低レベルな箇所だけは C++ で書いて、上位レイヤとは WebSocket でやり取りをする。とか。
昨今の流行り言語ならほぼすべて WebSocket をサポートしてそうです。たぶん。 - シビアなタイミングが要求されるようなケースで C++ を選択せざるを得ないが、UI はブラウザを使ってラクに作る。みたいな場合。
・・・・なんか似たようなケースを羅列したような気がしますが、そんな感じです。
今後は 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 は暗号化されてるの？ そこの社員には情報筒抜けなんでしょ？危なくない？ 」なんてことを気にすることも少なくっているのかなーと思います。
だからどうだっていう訳ではないですが、時代の流れを感じます。
ユーザー車検をしている方の中には、発煙筒のチェックで落とされる運の悪い人が、少なからずいるハズです。
自分もその一人です。
ただ、発煙筒には有効期限があってたぶん４、５年くらい。
そのたびに買い替えとかないと、運の悪い検査官に当たったら落とされてしまいます。
で、自分の発煙筒ももう有効期限切れ。
どうしよう・・。新品を調達するか、運を天に任せて期限切れのまま臨むか・・。
と思っていたら、発煙筒代わりになるものがあることを知りました！
値段も手ごろだし、壊れない限り無期限！
というわけで早速購入して、意気揚々とユーザー車検に臨みました。
案の定、発煙筒のチェックなどされることはなく、せっかく買ったものを活用することなく通りましたが、いい買い物をしたと本気で思った次第。オススメです。
自分ではまったく気にしてなかったんですが、ご指摘頂きウラを見てみたら、もう寿命な感じでした。
クルマで言えば、これくらいのミゾなら、１５分くらい走ってバーストさせて終わらそうって感じなのですが、
機械ではない自分の足のことを考えて、シューズ買い換えました。
旧モデルで安売りしてたアシックスのニューヨーク４です。このシリーズを買い続けて３足目です。
とにかく故障はしたくないので、クッション性重視！初心者向けバッチコイ！です。
走った感じの感想としては、なんか気分がいい！って感じです。
やっぱり新しい靴はいいすね。
社内の FreeNAS を 9.10 にアップデートしてみました。
手順は簡単で、ブラウザから[システム]-[更新]の画面のコンボボックスで FreeNAS-9.10-STABLE を選択、”Check Now” ボタン押して、”OK” ボタンを押す。あとは自動でアップデートしてくれます。
9.10 がリリースされてから数ヶ月経ってますし、これといって新し物好きという性格でもありません。がしかし、仮想化機能「bhyve（ビハイブ）」っていうのが載っているというあたり、仮想化好きな自分としては惹かれます。
FreeNAS を iSCSI 使って ESXi でマウントして使うっていうのがスタンダードな構成（かな？）だったところに変化がくるかもしれません。
とはいえ安定して使えるようになるのはもっと先になりそうということなので、それまでは開発者の方に感謝しつつ、期待して待ってようと思います。
8年前に買った DELL の inspiron1520 っていうノートPC。
とても気に入ってて当時、家から事務所から現場にとほぼ常にカバンに入れて持ち歩いてました。
が、それが災いしてかACダプタのどこかが、たまーに断線してるっぽくて、コンセントに繋いでいるつもりが実はバッテリ駆動になっててそのまま気が付かず突然シャットダウンなんてことがありました。
というわけで、ACアダプタを修理を試みました。
まず躓いたのが、ACアダプタを開けられない。
昨今のACアダプタのケースは溶接（という表現ではないと思いますが）されているようで、マイナスドライバでこじ開けることとなりましたが、なんとか開きました。
で、開けたところで、実は断線してるとこがわかりません。
一番怪しげな箇所をテスタで見ても通電してそうだし・・。
たまーに断線っていう状況のめんどくさいところです。
で、めんどくさいので、その一番怪しげなケーブルのヨレヨレになってる箇所をバッサリいってみました。日曜大工万歳。
読みが外れるなんてことは考えもせずに、意気揚々とケーブルをハンダでコテコテして繋げて、ACアダプタのケースはタイラップで閉じました。タイラップ万歳！
で、いざPCにつなげてみたところまったく症状改善せず！でした。見事に読みが外れました。無念です。
最新の xoops cube をベースに PHP も MySQL も新しいバージョンで動くようにしました。
文字コードも UTF8 を基本にしたので文字コード絡みの面倒さも激減。
xpwiki や xpress などのモジュールも使って、更新もラク出来そうです。
旧ホームページは１０年前に当時の xoops をベースに構築したものですが、今までほぼ手をかけずに使い続けたことを考えれば、十分な成果だったと思います。
xoops cube プロジェクトとしては、今後セキュリティフィックス以外の更新はないとのことなのでとても残念ですが、自分でいじれることを前提にすれば今でも良い選択肢である気がします（と言っても自分も全然理解は足りてませんが・・）。
開発者の皆様に感謝しつつ使わせて頂こうと思います。
なお、ホームページを改修したとはいえ、コンテンツの類はまだまだ工事中なので徐々に整えたいと思います。
今後とも有限会社シンクリッジをよろしくお願い申し上げます。