16. なぜゲームループ? どんなRun-time Frameworkにも必ずある(はず) 最外の処理なので全体の流れを見るのに都合がいい 対象となるプラットフォームによって、目的のコードが何処 にあるのかある程度見当がつく 例えばAndroidの場合、SurfaceViewを継承しているクラ スを探す等
久しぶりの更新です。 コードレビューや動作確認などでスマホ画面のキャプチャを貼り付けたくなることがあります。 そういう時に、シュッとキャプチャをとってClipboardに貼り付けられるツールを作りました。 github.com インストールはHomebrew経由で行えます。 $ brew tap sakebook/tap && brew install pbssc オプションをつけてOSを指定して実行できます。 // Android $ pbssc -a // iOS $ pbssc -i READMEにdemo動画があります。 実装のコアは既存ツールに依存 実際にキャプチャを撮る部分はadbとlibimobiledeviceに依存しています。 adb、つまりAndroid端末だと次のようにキャプチャを取れます。 $ adb exec-out screencap -p > example.
Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈(少なくとも自分の観測範囲)では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
QUIC とは QUIC は、今年 5 月に RFC 9000 や他いくつかの RFC によって標準化された、次世代のインターネットにおける通信プロトコルです。HTTP/3 では、この QUIC を下位層として使うことになっており、今後のより高速なインターネット通信において QUIC の占める役割は非常に大きなものとなるでしょう。 QUIC is now RFC 9000 | Fastly この記事では、QUIC による通信が始まる第一歩であるところの、Initial packet を Ruby で受けとってみることにします。 はじめに この記事内では、いくつかの外部の記事を参照しています。それらは QUIC の、ある時点での draft を参考に書いてあるものもありますが、この記事では RFC となった QUIC version 1 に対しての内容となります。 記事内の誤り、誤字脱字等は
IETF 120 Vancouverにリモート参加しました IETF 120 Vancouver 5回目のIETF Meeting参加シリーズ、リモート参加の4回目です。期間中のバンクーバーはUTC-7(PDT)なので、日本からだと1時から13時の範囲となり、リアルタイムの参加はあきらめていました。 参加したセッション 「参加したセッション」とはいっても前述のようにリアルタイムでmeetechoに入るのは厳しく、基本的に資料と議事録を見て書いています。httpbis、httpapi、masque、webtrans、ccwg、moqについてもまとめようと思ったんですが、一旦7月中に出すことを考えると余裕がなく、力尽きました。追って書くかもしれません。 2024-08-21 追記 書きました。 IETF 120 Vancouverにリモート参加しました その2 Transport Layer
Photo by Dominik Lückmann on UnsplashWhen a task operating in a Kubernetes cluster becomes repetitive, it probably means that we are not taking advantage of all the features that Kubernetes offers, because it is designed for automation. Normally, these tasks are performed by human operators, who have deep knowledge of how the system ought to behave, know how to deploy the application, and troubles
はてなインターネット文学賞「わたしとインターネット」 初めてインターネットに接続したのはとにかく誰よりも早くコンシューマーゲームのチートがやりたかったからで、私が初めて閲覧したウェブサイトは、ゲームのチート情報サイトだった。 私の家にはなぜかバックアップ活用テクニックやゲームラボが山のように置いてあったから、私はそれを読んで、父親にねだってプロアクションリプレイというゲームをチートするための機材を買ってもらってチートしていた。 しかし月刊誌とゲームの発売日は噛み合わない。私は誰よりも早くチートしたかった。地方の田舎で、本屋もゲームショップもほとんどないような土地なのだから、私の周りにゲームをチートしている人間なんていなかった。そもそも誰もゲームすらやってない。ザリガニを爆破するのがなによりの娯楽だ。だから私はたったひとりの最速チーターだったのだけど、それでもまだ足りていなかった。 父親はゲ
Rust is built around the concept of “zero cost abstraction”. The idea is that you can write human-friendly high level code and the compiler will give you for free performance at least as good as any optimized low level code you could have written yourself. With zero cost abstraction, you no longer have to trade off between maintainability and performance. Unfortunately, it is difficult to ensure t
Windows対応の曖昧なAPIを非難する記事 この記事はGoが曖昧に扱うAPIについて非難していて、より厳格に扱うことのメリットを解説しています。 Goのこれらの指摘の挙動が実際にどの様なものかを解説していきます。 無視する挙動 Goの標準ライブラリのAPIはどちらかというとUnix/Posixに寄せていて、一部のWindowsに無い概念に関する処理(ファイルのパーミッション操作など)は黙って無視したりする。 これはUnix/Posix用の実装が同じソースコードのままWindowsでも動作するために必要なダミーです。ここでそのようなダミー実装をアプリケーション作成側の責任にすると実装やテストが大変面倒になってしまう。 逆に、GoではUnix/Posixにあるforkやthreadに関するAPIをサポートしません。特にforkというAPIはWindowsには全くない概念であり、互換性を取る
Skip-free audio and video playback is a fundamental expectation for many - if not most - Linux users. Given the importance of this feature and the increase in hardware performance over the years, one would think that the audio latency problem would have been solved some time ago. The recent posting of (and mixed reception for) the "RealtimeKit" mechanism shows that this issue remains open, though,
Spot errors in your Go code you didn’t even know you were making and boost your productivity by avoiding common mistakes and pitfalls. 100 Go Mistakes and How to Avoid Them shows you how to: Dodge the most common mistakes made by Go developers Structure and organize your Go application Handle data and control structures efficiently Deal with errors in an idiomatic manner Improve your concurrency s
cgroup には複数のサブシステム(controller)があるが、その中の cpu.shares について検証してみた。 cpu.shares とは cpu.shares を設定すると、タスクが使用できる CPU 時間の割合を変更することができる。 具体的に言うと、A B2つのグループを作り、cpu.shares をそれぞれ1024 2048とした場合、B のグループにいるプロセスが、A のグループにいるプロセスより 2倍 CPU を使えるようになる。以下、実行例。 # mkdir /cgroup/{A,B} # echo 1024 > /cgroup/A/cpu.shares # echo 2048 > /cgroup/B/cpu.shares # sh -c "while : ; do : ; done" & echo $! > /cgroup/A/tasks [1] 2835 #
GCP の CPU usage と CPU utilization 指標についてちょっとハマったので、かんたんに調べたことを整理した。 以下正確ではないが、こういうイメージで理解しているというメモ。また各例は GCE インスタンスの指標をとりあげているが、他も同じだと思う。 CPU usage (xxx/cpu/usage_time) usage_time は 1 秒あたりの cpu が利用中だった秒数。すべての vCPU について、60 秒のウィンドウで計測し集計。単位は s/s で、分子は利用中の秒数、分母は秒だと思う。 例えば 4 vCPU のインスタンスで、ある 60 秒間について、それぞれ 30 秒、0 秒、15 秒、0 秒利用中だった場合、usage_time は 0.75 s/s となる。 (30 + 0 + 15 + 0) / 60 = 0.25 (s/s) 当然数値は 1
Recent posts: 22 Jul 2024 » No More Blue Fridays 24 Mar 2024 » Linux Crisis Tools 17 Mar 2024 » The Return of the Frame Pointers 10 Mar 2024 » eBPF Documentary 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netfl
Last week during a casual conversation I overheard a colleague saying: "The Linux network stack is slow! You can't expect it to do more than 50 thousand packets per second per core!" That got me thinking. While I agree that 50kpps per core is probably the limit for any practical application, what is the Linux networking stack capable of? Let's rephrase that to make it more fun: On Linux, how hard
Docker で NVIDIA GPU を利用する場合は、NVIDIA Container Toolkit (NVIDIA Docker) が必要になります。この記事では、なぜ NVIDIA Container Toolkit がなぜ必要か、どう動くかについて個人的に調べたことを記載します。2021 年 4 月時点での情報になります。今後のバージョンアップで内容が古くなっている可能性がある点にご注意ください (#確認した環境)。 NVIDIA Container Toolkit (NVIDIA Docker) 自体のインストール方法や歴史については、NVIDIA Japan のNVIDIA Docker って今どうなってるの? (20.09 版) という記事が非常によくまとまっているため、そちらをご覧ください。 内容が長いため、「まとめ」の章を目次として見ていただければと思います。 なぜ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く