組み込み端末のアプリケーションに Electron を採用し開発・運用を行っています。 継続的な機能追加やトラブルサポートを行いながら 3 年が経過したので、Electron を採用した経緯や結果を経験を交えながら共有したいと思います。 組み込み案件自体が初めてでしたのでその話も入っています。 約 700 台ほど導入されており、なかなか大きな案件での採用と思いますので参考になれば幸いです。 ※Electron の基本的な説明は割愛します。 システムについて 一般的に「受付精算機」などと呼ばれ、店頭に何台か並べて設置して自動で受付・精算を行うシステムです。 ホテルの受付端末のイメージです。ハード的にはセルフレジにも近いです。 筐体自体は他社が用意し、弊社はその上に載せる GUI アプリケーションのみを担当しました。 機能 主な機能として 来店受付・整理券発行 予約チェックイン チェックアウト
PCのキーボードは、現在に至るまでのベースとなったIBM PCの頃から大きく変わっていない。いまだにPS/2コネクタを持つマザーボードも存在し、変換コネクタを使うと当時のIBM PCのキーボードを接続して利用できる。 一方で今の時代は、USBやBluetoothといった接続方式を使うキーボードも存在する。あらためてWindowsのキーボードはどうなっているのかを見ていく。今回はユーザーがキーボードを押してから、アプリケーションにそれが通知されるまでを概観する。各所に細かい話はあるのだが、なるべく全体を見るようにしたい。 Windowsのキーボード入力の仕組み。USB/BluetoothでPS/2の大きく2つのハードウェアに分けられ、双方が押されたキーをWindowsスキャンコードで表現して、kbdclass.sysで処理する。この時点では、どのキーも単なるコードでしかないが、その後、レイア
3月からCOVID-19の影響でずっと在宅勤務をしているのですが、一番ストレスがたまるのが、ビデオ会議で通話が頻繁に途切れることです、仕事になりません。 そこでシリコンバレー界隈のWiFi詳しいお兄さんこと、yabejpさんに相談したところUniFi製品の購入から導入まで手とり足取り教えて頂き、約10万円の投資で非常に満足の行くエンタープライズWiFi環境を自宅に整える事ができたので、ブログにしてみます。 はじめにこの記事で紹介しているソリューションは万人のためというわけではなく、人を選びます。対象読者としては以下を想定しています。 不安定なネット環境が本当に許せない基礎的なネットワークの知識がある(Ethernet, TCP/IP, DNS, DHCP, etc)基礎的なUNIXシステムの知識がある自宅WiFi環境に3-10万円程度の予算をかけられる自宅WiFi環境の設定にある程度の時間
自分にとっての“Endgame（究極の）キーボード”を、どこかのメーカーが作ってくれるまで待つのはもう止めだ。Endgameは自作してしまえ！ というのが最近のキーボードマニア、即ち“キーボー道”のムーブメント。 前回は、キーボードのキースイッチの違いや配列など、キーボードを語るにあたっての基本要素を解説したが、そろそろ実践に移りたい。 だが自作キーボードもピンキリだ。自作キーボードの難度といってもいいし、沼の深さと言い換えてもよい。どんな段階があるのかを浅いものから順に以下に簡単に紹介しよう。 （1）キーキャップのカスタマイズだけ 既存のキーボードのキーキャップだけ交換するというのも、オリジナルなものを作り出すという意味では自作キーボードに入る（かもしれない）。 前回解説した通り、Cherry MXに対応したキーキャップなら、多くのキーボードに装着できる（静電容量無接点式のキーボードでも
ハードウェアのエラーでメモリの内容が化けてしまうことが稀にある。大抵のDRAMエラーはせいぜいプログラムがクラッシュする結果になるだけだが、データ破壊になることもありえるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に実際に観測したところ、1年間に1回以上のエラーが発生したDIMMモジュールは全体の8%にのぼったそうだ。DIMM 1枚に数百億個のメモリセルが実装されているといっても、このエラー率はちょっとびっくりするくらい大きな数字ではないだろうか？ サーバでは普通はエラー訂正付きのDIMMを使うので1ビットのエラーは問題にならないが、エラー訂正のないコンシューマ機器ではこれは実際的な問題になりえる。 メモリエラーを利用したセキュリティ破り
10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で１台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 #高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
