サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
飛行機の音が聞こえたとき、「この機体はどこへ行くのだろう」と気になったことはありませんか？ この記事では、Raspberry Piで航空機信号用の受信機を使う方法と「レーダー風表示装置」の作り方を紹介します。リアルタイムで頭上を飛ぶ航空機の位置情報を画面に表示し、自宅で小さな管制塔気分が楽しめます。 ラズパイで飛行機の信号を受信 多くの飛行機は、現在位置・高度・速度・機体番号などの情報を送信しています。そうした通信手段の中でも、旅客機をはじめとする多くの航空機で使われているのが、ADS-B（Automatic Dependent Surveillance–Broadcast） という仕組みです。
ミック @copinemickmack むかし米国人の書いたコードをレビューした時のこと。データ量が少ない時は問題なくても増えてきたら必ず遅くなる箇所があったので直すようにコメントした。すると相手曰く「なあ、それは今やる必要があるか？」。もちろん、今やっておかないと後で大変なことになる。「当然だ」と答えた。 2025-03-28 16:34:34 ミック @copinemickmack すると「どれくらいの確率で問題になると思う？」と聞いてきた。まあ正直分からない。サービスが当たるかどうかなんて事前には分からない。そう答えると「そうだよな。だったら今やる必要はない。日本人てのは起きていない問題まで見つけてくるから大したものだ」。嫌味というより素直に感心している。 2025-03-28 16:38:47 ミック @copinemickmack 「心配事の大半は起きない。だったら期待値の低いこ
私の勤めるマイクロソフトにも、レイオフがやってくるようだ。それもパフォーマンスベース。つまり、今首になると、「この人はローパフォーマー」とわかるので、再就職が難しくなるだろう。 自分はマイクロソフトの仕事が面白いし、職場も最高なので、こんな中途半端に首にはなりたくはない。ただ、自分がハイパフォーマーとはとても言えない。周りの人はめっちゃ優秀やから。 私は今までは、自分の性能が「三流」であるけど、ダメな自分を「戦略」でカバーして何とかしてきた。しかし、この流れを見ていると、「三流」のままでは早晩解雇されてしまうだろう。たとえ今回のレイオフを生き延びても、記事を読むと、ワークフォースは減らさないと書いてあるし、出来ない人はいらないという流れなのだと思う。 「優秀」になるしかない 今まで、自分がダメなのは受け入れていたが、これからはそうもいかないのだと思う。「優秀」になるしかない。この面白い仕事
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに そりゃまあ 30 年も経てば古くなりますよ。「入門UNIXシェルプログラミング」は今もシェルスクリプトに関するオススメの本として名前が挙がる名著です。しかしこの本は古い本です。POSIX でシェルが標準化される以前の本で、内容から判断するとおそらく 1990 年ぐらいの常識に基づいて書かれています。 古いから参考にならないと言うつもりはありません。しかしどれだけ優れた本でも時間の流れには勝てません。良書であると思っているからこそ、古くなってしまった内容は訂正する必要があると考えています。なおシェルスクリプトに関する古い本はこれ
はじめに システムに存在するリソースには同時にアクセスしてはいけないものが多々あります。身近な例を挙げると、Ubuntuのパッケージ管理システムのデータベースがあります。aptコマンドの動作によってこのデータベースは更新されるのですが、同時に2つ以上のaptが動作できたとすると、データベースが破壊されてシステムが危機的状況に陥ります。 このような問題を避けるために、あるリソースに同時に1つの処理しかアクセスできなくする排他制御というしくみがあります。排他制御はOSが提供する重要な機能の一つです。 排他制御が必要なケース 排他制御は直感的ではなく非常に理解が難しいのですが、ここでは比較的理解が簡単なファイルロックというしくみを使って説明します。説明には、あるファイルの中身を読みだして、その中に書いてある数字に1を加えて終了するincというという単純なプログラムを使います。
IT業界が外部の人間から敬遠される理由の一つに「デスマーチ」がある。 ほとんど実現不可能に思える無理なスケジュールで、深夜におよぶ残業、休日出勤の連続、人海戦術でほとんど役に立たない新人までが駆り出され、終わりの見えないプロジェクトの完成にひた走る、これがデスマーチである。 そこではプログラマは一人また一人と過労に倒れ、うつろな目でキーボードを叩き続けるプログラマの連続勤務時間は20時間を優に超える、といった光景が見られる。 このようなデスマーチについて、人材の疲弊やそれに伴う退職など、ITベンダー側の不利益が語られることは多いが、クライアント側の不利益、もっといえばプロジェクトの成果物自体がデスマーチで台無しになってしまうことはあまり知られていない。 デスマーチのきっかけ 営業の無謀な受注、仕様の調整不足などで、システムの実装行程が確保できず、どうやっても通常の開発体制ではシステムの完成
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
