「byte」を含む日記

■老人のlineは名詞を絵文字に置き換えがち、なぜか

iモードなんかのメールのbyte数を減らしてパケット代を節約してた頃の癖かもしれない

他にも増田の思う諸説があったら教えてくれや

Permalink | 記事への反応(1) | 19:42

ツイートシェア

■anond:20230621135916

バラツキはあるだろうが、エントリ1件当たりの平均文字数を300文字(900byte)、1日当たりの平均エントリ数を10,000件と仮定すると

900(byte) × 10,000(件/日) × 365(日) = 3,285,000,000(byte/年)

となり、およそ3GB/年のデータ増加量になる。

年間3GB程度のデータ増加であればインフラ維持に大して頭使わなくて良いし、機能改善もほとんどないので作りっぱなしで勝手に金を生んでくれるし、サーバ維持費用＞広告収入にならない限り最低限のメンテナンスで細々と生き続けるのでは？

定期的にOSやミドルウェアのバージョンアップ＆移行作業があるだろうけど、若手社員の研修だと思えば別にそんなデメリットでもないだろうし。

Permalink | 記事への反応(1) | 15:03

ツイートシェア

■

闇byte

Permalink | 記事への反応(0) | 13:34

ツイートシェア

■「UNIX 哲学」についていくつか

名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita

この記事はよく調べてあるなぁと思う反面，事実関係の間違いも多く当時の空気感など欠けていると思う部分がいくつかある。事実関係に関しては追い切れないので参考文献を挙げるにとどめておくが，空気感のほうはいくつか書いておく。なお当該記事の「当時と今では状況が全然違うんだから，安易に『UNIX 哲学』とかいうな」という主旨には大賛成である。

参考文献

初期の UNIX の歴史について興味がある向きには次の書籍をお薦めする。

Peter H. Salus『A Quarter Century of UNIX』(1994, Addison-Wesley Publishing)

和訳の『UNIXの1/4世紀』(Peter H. Salus, QUIPU LLC 訳, 2000, アスキー) は絶版のうえ訳も微妙なので薦めづらいが，原書は The Unix Heritage Society (tuhs) で PDF が無償公開されているので，英語が苦にならないのなら読んでみるといい。

また同じく tuhs で無償公開されている Don Libes and Sandy Ressler『Life with UNIX』（1989, Prentice Hall）を読めば80年代終りの UNIX の状況（XENIX についてもしっかり言及されている）や利用者目線での雰囲気もある程度判るだろう。

「哲学」

元記事で一番気になるのが「哲学」という語の捉え方。この言葉の強さに引きずられているように読める。でもこれ，当時は設計の基本的な考え方くらいの意味でわりとよく使われていた言葉なんだよね。たとえば米 BYTE 誌のアーカイブを “philosophy” で全文検索するとこんな感じ。

https://archive.org/details/byte-magazine?query=philosophy&sin=TXT&sort=date

ほぼ毎号のように出現していたのが判るだろう。

もっとも猫も杓子も「哲学」を振りかざしていたわけではないし，UNIX の開発者たちが「哲学」の語を好んで使っていたのも間違いないように思う。傍証の一つが AT＆T の定期刊行物『The Bell System Technical Journal』の1978年7, 8月号だ。元記事で言及されているマキルロイの Forword の初出がこれで，ネットのアーカイブから PDF が入手できる。

この号は二部構成になっていて第一部が Atlanta Fiber System に関する論文12本（全172ページ），第二部が UNIX に関する（Preface や Foreword を含む）論文22本（全416ページ）となっている。さて前述の PDF は OCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX の論文なのだ。もちろん論文の性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイの哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白い。UNIX の開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが，それまでにない新しい考え方に基づいた OS を開発しているという意識があれば，そういう言葉を選ぶのが自然な時代だったことは間違いない。

UNIX が認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい，あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが，そんなたいしたものではない。マキルロイの論文に影響を受けた布教のためのああいう説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本で最初期の UNIX 解説本のひとつである，村井純・井上尚司・砂原秀樹『プロフェッショナル UNIX』（1986，アスキー）には冒頭次のような一節がある。

オペレーティング・システムは，コンピュータを使うものにとっての環境を形成する基盤であるから，そのうえで生活する者の個性を尊重し，より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが，UNIX のオペレーティング・システムとしての個性ではないだろうか。

　

　　　　プロフェッショナル UNIX（村井純・井上尚司・砂原秀樹，1986，アスキー）p 3.

「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能のコマンド群のことで，これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性を尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが，たまたまガンカースだったというだけのことである。

そしてじつは UNIX の場合，布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが，その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。

UNIX の利用環境

UNIX は PDP というミニコンピュータ（ミニコン）上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は，もちろん場所によって違うわけだが，マアおおよそ学校の教室くらいの大きさだ。長机が何列か並んでおり，そのうえにはブラウン管ディスプレイとキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校にコンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器はコンピュータではなくコンピュータに接続するための端末装置（ターミナル）だ。端末装置のキーボードで打った文字がコンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 Unix 系 OS で CLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置のエミュレータで，もともとは実体のある装置だったわけだ。

さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥や洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっともコンピュータが何台もあるわけではない。この箪笥が CPU でそっちの洗濯機がハードディスク，あの机に置かれているタイプライタが管理用コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて，なんてミニ！」という時代のお話だ。

端末装置それぞれから（USB のご先祖様の）RS-232 という規格のアオダイショウみたいなケーブルが伸び，マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び，root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。

結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは，マアどうでもいい。

自由で不安定な OS

当時の UNIX の評価を一言で表すと〝自由で不安定な OS〟となる。メーカお仕着せではなく自分好みの「より良い環境」を作りあげる自由。さらに他のメインフレームやミニコン用 OS に比べると一般ユーザ権限でできることが圧倒的に多かった。そしてその代償が不安定さ。今では考えられないが UNIX のその不安定さゆえにプロ用 OS ではないと考える向きは多かったし「でも UNIX ってすぐ落ちるじゃん」というのは UNIX アンチ定番のディスりだった。UNIX の落とし方，みたいな情報がなんとなく廻ってきたものだ。

こういった雰囲気を鮮やかに伝えてくれるのが，高野豊『root から / へのメッセージ』（1991，アスキー）だ。当時アスキーが発行していた雑誌『UNIX MAGAZINE』に連載されていた氏のエッセイの1986年11月号から1988年10月号掲載分までをまとめた書籍である。著者の高野氏は勤務先の松下電器で1980年ごろから UNIX サイトのスーパーユーザを務めており，日本では最古参の一人である。この本の中で高野氏は繰返し UNIX の自由さと不安定さに言及している。すこし長くなるが，その中の一つを引用しよう。

CPU は，システムにとって重要な共有資源であるが，この CPU を実質的に停めてしまうことが UNIX ではいとも簡単にできる。たとえば，cc コマンドを10個くらい同時に走らせてみたらよい。VAX-11/780 といえども，同時に実行できるコンパイルはせいぜい3つか4つである。それ以上実行することも当然可能ではあるが，他に与える影響が無視できなくなる。つまり，てきめんに vi のカーソルが動かなくなる。あるいは，すこし大きめなディレクトリ上での ls コマンドの出力が表示されるまでに煙草を1本吸い終えてしまったり，タイムアウトでログインが撥ねつけられたりといったバカげた現象が起きだすのである。こういった状態になると，UNIX は破壊されたに等しい。真夜中，独りで VAX を占有して使っているのなら何をやろうとかまわない。しかし，20人30人と多数の人間が使っているときに勝手をやられると非常に困るのである。当人の仕事が遅れるのは自業自得だとしても，そのとばっちりで他のエディタまで止まってしまうと，もはやどの仕事も進行しなくなる。

ディスクについても同様なことがいえる。UNIX では，ファイルシステムを使いはたすまで大きなファイルを自由に作ることができる。したがって，自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと，コンソール・タイプライターにエラー・メッセージが出力されるが，夜中にそれが発生して，コンソール・タイプライターが一晩中エラー・メッセージを打ち続け，朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい，ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると，それをしでかした本人のプロセスは当然のこととしても，同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい，わずかでも仕事を先に進めようとする意図も完璧に打ち砕かれてしまうのである。

　

　　　　root から / へのメッセージ（高野豊，1991，アスキー）pp16-17.

そして，こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンドを10個くらい同時に走らせ」たり「自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイトの利用者全員に UNIX の設計の基本的な考え方を理解してもらうことが，自分のために必要だった。UNIX の伝道がより苛烈だった理由のひとつがここにあるのだ。

ミニコン UNIX の終焉

ミニコン上で誕生した UNIX は 4.3BSD（1986）で最高潮を迎える。注意したいのはミニコン時代の UNIX は Research UNIX と CSRG BSD みたいな区別をせずにまとめて UNIX として扱われていたことだ。実際『プロフェッショナル UNIX』も『root から〜』も UNIX と記述されてはいるが実際には BSD を扱っている。べつに当時の人が無知だったわけではない。なにしろ BSD を利用するためにはまず AT＆T から UNIX のライセンスを購入し，そのうえでカリフォルニア大学バークレー校（UCB）から BSD を入手しなければならなかったからその関係は当然広く知られていた。ベル研で発明された UNIX を外部の人たちも含めみんなで改良し，それら全体が UNIX であるという考え方が自然だっただけである。『Life with UNIX』のような英語の文献によく登場する “Berkeley UNIX” という言い回しが当時の気分をよく表している。UNIX vs BSD みたいな捉え方は法廷闘争を経た90年代以降の感覚だ。

もっともそういう70年代風味の牧歌的風景はミニコン世界限定の話であった。BSD そのものはミニコン用のものしかなかったが，そのコードを受け継いだ BSD 系 Unix や AT＆T が推し進める System V などがワークステーション市場を舞台に80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で，PC 用 Unix であるマイクロソフトの XENIX も当然参戦した。ミニコン世界が牧歌的だったのは，ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争はあくまでも標準という聖杯を争う戦いであり，AT＆T と BSD 系 Unix の Sun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。

こうしたミニコン UNIX からワークステーション Unix への転変は Unix そのものや文化にも変化をもたらした。まず激しい競争は Unix の高機能化を加速した。商品として判りやすい惹句が「あれもできます，これもできます」なのは誰もが知っている。もちろん安定性を増すために quota のような利用者の自由を制限する機能も含まれていた。またワークステーション Unix は現在の Unix 系 OS と同様同時に一人が使うものであり前述の布教の必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』（1993，オーム社）を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unix のシステム管理の入門書だ。この本ではたんに知識を羅列するかわりに架空のソフトウェアハウス（開発会社）を舞台に新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており，そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。

UNIX 哲学の背骨

当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイの論文の結論部分に書かれたそれは，1973年に出版されたイギリスの経済学者エルンスト・シューマッハーの著作の題名で，中学生の英語力があれば十分に理解できる平明な一文だ。

Small is beautiful.

マキルロイは『人月の神話』を引いて一定の留保をつけてはいるものの，これが UNIX 哲学の背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•cs のアンチテーゼである UNI•x にとって，これ以上のスローガンがあるだろうか？

ひるがえって現在の Unix 系 OS をみれば，ブクブクと肥え太ったシステムコール，全容を俯瞰するだけでも一苦労するライブラリインターフェイス，一生使うことのないオプションスイッチまみれのコマンド群。UNIX が仮想敵とした OS そのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ，コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ，歴史書を飾る一項目になっただけだ。ただ現在「UNIX 哲学」を語るならそうした背景は理解していなければならないし，どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。

Permalink | 記事への反応(0) | 13:39

ツイートシェア

■anond:20220413171035

これとかバカ丸出しで最高なんだよな。

ゲーム好きのネトウヨおっさんの、脳ミソが２byteしかなくてアカかアカじゃないかという判断しか出来ない単純な理解力は、世に害悪しかもたらさないよな。

https://b.hatena.ne.jp/entry/4708401124921788194/comment/RRD

Permalink | 記事への反応(0) | 17:32

ツイートシェア

■はてなーはこの理屈理解できるの？

RRD まーた条件の違う二つのものを直結させる、一進法で動く特有の脳ミソをネトウヨが炸裂させてるな。たとえ脳ミソが２byteあっても一進法で動いてたら、1個も判断できないわ。

Permalink | 記事への反応(4) | 18:31

ツイートシェア

■脳ミソが２byte

脳ミソが２byteしかなくてアカかアカじゃないかという判断しか出来ない

物事を0か1かのどちらでしか考えないという意味でこれを書いたのであれば2byteでなくて1bitなのではないだろうか

いわゆるゼロイチ思考、1bit脳であれば2通りの判断ができるとする

すると2byte思考は65536通りの判断ができる

それはむしろかなーりグラデーションの判断ができる人で凄い

Permalink | 記事への反応(0) | 12:56

ツイートシェア

■MRTGがSNMPv1だと120Mbps以上でバグる話

2015年ごろには既知の現象だったようなので5年近く無駄に過ごしてしまった。

https://ex1.m-yabe.com/archives/1149

どうしても100Mbpsどころでは済まない通信量なのにMRTGが100Mbps少し超えたあたりから上のグラフを書かれた試しがない。

先日、200~220Mbpsでているのを手元の端末で確認しながら5分程度ダウンロードしたのにグラフは90Mbps程度。

ルーターの生の数字が10分以上、800Mbps超えてたのにグラフは115Mbpsあたりでストップ。

明らかに何かがおかしい。

bitとbyte間違えてるんでは？などとといろいろ調べたところ、SEさんが上記のトラップを発見された。

接続が100とか10Mbpsだった時代の仕組みをそのまま使ってきたのがまずかったんだよなぁ。

とにかくこれで、ようやく正しい測定結果をとることができそうだ。

「ただより怖いものはない」

必要な機器は予算投入しようね。

Permalink | 記事への反応(0) | 02:26

ツイートシェア

■thinkpad x260を買った

ので、unixbenchの結果を貼っておく。

========================================================================

BYTE UNIX Benchmarks (Version 5.1.3)

System: thinkpad-x260: GNU/Linux

OS: GNU/Linux -- 5.4.0-45-generic -- #49-Ubuntu SMP Wed Aug 26 13:38:52 UTC 2020

Machine: x86_64 (x86_64)

Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")

CPU 0: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (4999.9 bogomips)

Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization

CPU 1: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (4999.9 bogomips)

Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization

CPU 2: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (4999.9 bogomips)

Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization

CPU 3: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (4999.9 bogomips)

Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization

21:26:57 up 1:01, 2 users, load average: 0.00, 0.00, 0.15; runlevel 2020-09-04

------------------------------------------------------------------------

Benchmark Run: Fri Sep 04 2020 21:26:57 - 21:55:00

4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 38124852.7 lps (10.0 s, 7 samples)

Double-Precision Whetstone 6422.0 MWIPS (9.9 s, 7 samples)

Execl Throughput 4264.8 lps (30.0 s, 2 samples)

File Copy 1024 bufsize 2000 maxblocks 515046.2 KBps (30.0 s, 2 samples)

File Copy 256 bufsize 500 maxblocks 140474.5 KBps (30.0 s, 2 samples)

File Copy 4096 bufsize 8000 maxblocks 1617517.8 KBps (30.0 s, 2 samples)

Pipe Throughput 697605.3 lps (10.0 s, 7 samples)

Pipe-based Context Switching 170352.7 lps (10.0 s, 7 samples)

Process Creation 10427.0 lps (30.0 s, 2 samples)

Shell Scripts (1 concurrent) 9734.6 lpm (60.0 s, 2 samples)

Shell Scripts (8 concurrent) 2353.1 lpm (60.0 s, 2 samples)

System Call Overhead 398924.8 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700.0 38124852.7 3266.9

Double-Precision Whetstone 55.0 6422.0 1167.6

Execl Throughput 43.0 4264.8 991.8

File Copy 1024 bufsize 2000 maxblocks 3960.0 515046.2 1300.6

File Copy 256 bufsize 500 maxblocks 1655.0 140474.5 848.8

File Copy 4096 bufsize 8000 maxblocks 5800.0 1617517.8 2788.8

Pipe Throughput 12440.0 697605.3 560.8

Pipe-based Context Switching 4000.0 170352.7 425.9

Process Creation 126.0 10427.0 827.5

Shell Scripts (1 concurrent) 42.4 9734.6 2295.9

Shell Scripts (8 concurrent) 6.0 2353.1 3921.8

System Call Overhead 15000.0 398924.8 265.9

========

System Benchmarks Index Score 1152.9

------------------------------------------------------------------------

Benchmark Run: Fri Sep 04 2020 21:55:00 - 22:23:04

4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables 103355568.3 lps (10.0 s, 7 samples)

Double-Precision Whetstone 22425.8 MWIPS (9.9 s, 7 samples)

Execl Throughput 10514.5 lps (30.0 s, 2 samples)

File Copy 1024 bufsize 2000 maxblocks 878593.5 KBps (30.0 s, 2 samples)

File Copy 256 bufsize 500 maxblocks 237997.4 KBps (30.0 s, 2 samples)

File Copy 4096 bufsize 8000 maxblocks 2896282.9 KBps (30.0 s, 2 samples)

Pipe Throughput 1718493.4 lps (10.0 s, 7 samples)

Pipe-based Context Switching 381500.2 lps (10.0 s, 7 samples)

Process Creation 26280.8 lps (30.0 s, 2 samples)

Shell Scripts (1 concurrent) 18979.1 lpm (60.0 s, 2 samples)

Shell Scripts (8 concurrent) 2716.0 lpm (60.1 s, 2 samples)

System Call Overhead 951109.4 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700.0 103355568.3 8856.5

Double-Precision Whetstone 55.0 22425.8 4077.4

Execl Throughput 43.0 10514.5 2445.2

File Copy 1024 bufsize 2000 maxblocks 3960.0 878593.5 2218.7

File Copy 256 bufsize 500 maxblocks 1655.0 237997.4 1438.1

File Copy 4096 bufsize 8000 maxblocks 5800.0 2896282.9 4993.6

Pipe Throughput 12440.0 1718493.4 1381.4

Pipe-based Context Switching 4000.0 381500.2 953.8

Process Creation 126.0 26280.8 2085.8

Shell Scripts (1 concurrent) 42.4 18979.1 4476.2

Shell Scripts (8 concurrent) 6.0 2716.0 4526.6

System Call Overhead 15000.0 951109.4 634.1

========

System Benchmarks Index Score 2462.3

Permalink | 記事への反応(0) | 22:27

ツイートシェア

■anond:20200528022829

2ちゃんねるでは句読点をつけないという謎の文化があるからね。

もしかしたらナローバンド時代のByte節約的な意味があったのかもしらんが。

本来そこまで執着すべきルールではないんだが、そういう風潮が出来上がってて句読点をつけると馬鹿にされることすらあるから、ネット文章は句読点つけないもの、という手癖がついちゃったんだろう。

Permalink | 記事への反応(0) | 02:35

ツイートシェア

■

Intelアセンブラの基本的なモード

32bit (IA-32)

https://en.wikipedia.org/wiki/X86_assembly_language#Execution_modes

Real mode (16-bit)

Protected mode (16-bit and 32-bit)

Long mode (64-bit)

Virtual 8086 mode (16-bit)

System Management Mode (16-bit)

64bit(EMT64)

https://software.intel.com/en-us/articles/introduction-to-x64-assembly

General Architecture

Since the 64-bit registers allow access for many sizes and locations, we define a byte as 8 bits, a word as 16 bits, a double word as 32 bits, a quadword as 64 bits, and a double quadword as 128 bits. Intel stores bytes "little endian," meaning lower significant bytes are stored in lower memory addresses.

命令セット

MMX.SSE,AVX.FMA

Permalink | 記事への反応(0) | 09:38

ツイートシェア

■anond:20191024163350

それはbyte型の配列だったとしても8bit1セット×要素数の情報を持っているという意味で2次元ってこと？

なら内部的に1要素が1ビットしかメモリを利用していないbool型1次元配列はどう？

Permalink | 記事への反応(1) | 16:40

ツイートシェア

■

私はIT企業で働くプログラマだ。

最近ではコードレビューシステムを取り入れてる会社は多いだろうが

まともに運用できているのか知りたい。

私が以前勤めていた会社では地獄の運用がされていた。

変数にプラス1するだけのパッチでも

いちゃもんつけては10回、時には100回以上書き直させるというキチガイが暴れていたからだ。

1文字の変更でも数十行はコミットメッセージを書かねばならず、

ブーリアン型を2つ使っているだけでも

メモリの無駄だからビット演算しろとか

同じ処理をしている2行が一度でも現れたら関数化しなければならなかった。

重要なのは、別の修正でブーリアン型を2つ使っている箇所をByte型のビット演算にして

同じ処理をしている2行が一箇所でもあればそれらを全部関数化すると

今度は読みづらい・非効率だから直せと言われる。

つまり間違っているから直さなくてはいけないのではなく、

正確さを追求しているのでもなく、効率化でも、高速化でも、平易化でもなく

難癖つけてやり直しを命じることが目的になっていた。

出来上がったコードはひどい出来だった。

簡単なコードが難解になればなるほど彼は満足げだった。

やり直すごとにクソになっているのに書き直さなくてはいけないのが本当に苦痛だった。

ときには、嫌がらせ目的でパッチのすべての行に「is it correct?」と書いたり、

すべてのパッチを作成直後に減点してコミットできないようにしたりしていた。

変数名を決めるだけで5個ぐらい候補を上げてどれが好みですか、とキチガイにメールで聞くことすらあった。

この会社でのコードレビューシステムは完全に崩壊していて

一人でそれができてしまう、というのがとても気がかりだ。

今はまともな職場で働けているが、いつかまたそういう職場にあたってしまうかもしれない。

(そういう会社に限っていつも大量に募集してるものだ)

1文字の修正でも10回以上やりなおせと言われる職場はどれくらいの割合で存在するのか。知りたい。

Permalink | 記事への反応(2) | 18:00

ツイートシェア

■PC98版 YU-NOのメッセージファイルフォーマット

アニメがはじまったついでにPC98版 YU-NOのメッセージファイルフォーマットを解析してみた。

メッセージファイル

"*.MES"

ファイルの構成

+0　offset(2byte)

+2　辞書データ(offset - 2 byte) sjis2byte文字のつめあわせ

+offset　データ本体(ファイルの終わりまで)

データ形式

他にもコマンドいろいろあるみたい

Permalink | 記事への反応(0) | 18:58

ツイートシェア

■anond:20190110164836

サンドボックス環境はアプリ側が動的にメモリ解放はしねえからmallocのコードがあっても実質既に確保済みの byte ** を返してるだけって事だよ。

Permalink | 記事への反応(1) | 16:51

ツイートシェア

■あんなものは、やった体にしただけのガラクタなのになぁ。

もし本気で言ってるのなら、品質なんて担保できるわけがないのだ。

あのドキュメント群が、どのようにしてこの世に産まれ出たのか、顧客（エンドユーザーではない）も開発チームも知っているはずだ。

決して詳細設計ではなく、「プログラミングを一切知らないエンドユーザーが見て解る」機能について説明しただけのドキュメントなのだ。

そして更に、上っ面の機能ではなく内部仕様までこと細かく記述した「詳細設計書は作成しない」ことになったのだ。

それを顧客⇔開発チーム双方合意したうえで書かれたモノである。

すなわち今あるドキュメントは、たとえば「○○画面には△△が入力でき、決定ボタンでホストシステムに登録されます。」ということが書かれているだけで、決して「入力された△△を５byteと３byteと８byteの位置で分割し、□□と連結したものを送信用XMLのほにゃららタグにセットしてからホストに送信する。」といったことは書かれていないのだ。

なぜなら、システマティックな知識を持たないエンドユーザーが読んでもわからないからだ。

エンドユーザーは、仕組みはどうあれ、思った通りに入力したデータがホストシステムに登録できることだけを望んでいるのだ。

ところが、だ。

なぜか今は、その上っ面の機能だけが書かれたドキュメントだけに基づいてシステム要件が検討されていると言うのだ。

無理に決まっている。

上っ面の機能ですら必ずしもすべて書いてあるわけではないのだ。

誰がどう見ても数字しか入力しない入力欄には、誤って英字や全角文字を入れてしまうことが無いようチェックしたりしているのだが、「そんなの当たり前でしょ？」的なレベルのことは省略されていることも多々ある。

そしてその「それは書かなくて良いんじゃん？」には明確な基準は無く、レビュアーの感覚、さじ加減次第で省略されるのだ。

経緯は絶対に知っているはずだ。

絶対ということは絶対にない！と言うのなら、ドキュメント作成時から上流工程に携わっている人間でも知らない可能性が無いこともないのだろう。

だが、本気で「知らない」と言うのであれば、恐らくその人間はポンコツの極みである。

そのような経緯があるにも関わらず、今になって「ドキュメントに書かれていないこと」を見つけると、「ドキュメント不備だ」「きちんと書かれていないから正しい要件調整ができないじゃあないか」「不具合なのだからすぐ直せ」だとか……もうね、アホかと、バカかと。

期限と費用を重視して、詳細設計書を省略したんじゃねえのかよ？

であれば、追加開発時に改めて現状把握のためにソースコードの解析を伴う調査が必要になるに決まってるじゃねえかよ。

でもその工数を開発チームに与えることはしない。

製造が始まっているのに不安定な要件がある。

未定義部分は末端の担当者に「ユーザーに質問してみて」と、体の良い形で実のところ調整作業自体を丸投げする。

遅れや障害でも発生しようものなら「なぜだ？！」の追及の手は緩めず「対策を考えろ」とか、根本原因の大部分を上流が占めていることを認めようとは決してしない。

それで「このプロジェクトはウォーターフォールだから」とか、どの口？

もうね、アホかと、バカかと。

浄化しない排水を上流から流すせいで下流の人間がうんこまみれの水飲まされんだよ。

Permalink | 記事への反応(0) | 23:36

ツイートシェア

■[はてな統計]ブクマを集めたがホットエントリーになれなかったのは具体的にはどんなエントリーか

はてなブックマークでブックマーク数を多数集めたがホットエントリーに入らなかったエントリー

集計期間 2018年3月23日 20時10分 〜 2018年3月27日 1時0分、3日間(77時間)

集計対象は2018年3月23日 20時10分以降ファーストブクマされたエントリーで新着エントリーに入ったエントリーに限った

27日1時以降にホットエントリー入りした可能性は残っている。ただし新着エントリーに24時間以上いてからホットエントリーに上がれるケースは稀。

3ブックマーク集めても新着エントリーに入れなかったエントリーもあるはずだが、それは集計の対象外になっている。

ホットエントリーになれないエントリーはスライド共有サービスSpeaker Deckからのエントリーが目立つ。Speaker Deck以外でもテック系のエントリーが目立つ。

関連: anond:20180328202931

Permalink | 記事への反応(0) | 21:06

ツイートシェア

■http://anond.hatelabo.jp/20150223114637

ちったぁ自分で調べろや。ろくなプログラマになれんぞ。

IsNumeric Function (Visual Basic)

IsNumeric returns True if the data type of Expression is Boolean, Byte, Decimal, Double, Integer, Long, SByte, Short, Single, UInteger, ULong, or UShort, or an Object that contains one of those numeric types. It also returns True if Expression is a Char or String that can be successfully converted to a number.

ここは普通のことをいっている。 IsNumeric が True を返すのは以下のとき。

• 数値
• 数値として解釈できる文字列

だから問題があるのは Empty のほう。

VBE Glossary (Empty)

Empty

Indicates that no beginning value has been assigned to a Variant variable. An Empty variable is represented as 0 in a numeric context or a zero-length string ("") in a string context.

Empty は context にあわせて以下のように解釈される。

• 数値 : 0
• 文字列 : ""

というわけで IsNumeric(Empty) は Empty が数値として解釈されて 0 になるので True を返す。

Permalink | 記事への反応(1) | 12:39

ツイートシェア

■WinInetを使ってVBAでPOSTする

Option Explicit

Private Const INTERNET_OPEN_TYPE_PRECONFIG = 0
Private Const INTERNET_OPEN_TYPE_DIRECT = 1
Private Const INTERNET_OPEN_TYPE_PROXY = 3
Private Const INTERNET_SERVICE_HTTP = 3
Private Const INTERNET_DEFAULT_HTTP_PORT = 80
Private Const INTERNET_FLAG_RELOAD = &H80000000

Private Declare Function InternetOpenA Lib "wininet.dll" (ByVal sCallerName As String, ByVal dwAccessType As Long, ByVal sProxyName As String, ByVal sProxyBypass As String, ByVal dwFlags As Long) As Long
Private Declare Function InternetConnectA Lib "wininet.dll" (ByVal hInternetSession As Long, ByVal sServerName As String, ByVal nProxyPort As Integer, ByVal sUserName As String, ByVal sPassword As String, ByVal dwService As Long, ByVal dwFlags As Long, ByVal dwContext As Long) As Long
Private Declare Function InternetReadFile Lib "wininet.dll" (ByVal hFile As Long, ByRef sBuffer As Byte, ByVal lNumberBytesToRead As Long, ByRef lNumberOfBytesRead As Long) As Long
Private Declare Function InternetCloseHandle Lib "wininet.dll" (ByVal hInternetHandle As Long) As Long
Private Declare Function HttpOpenRequestA Lib "wininet.dll" (ByVal hConnect As Long, ByVal sVerb As String, ByVal sObjectName As String, ByVal sVersion As String, ByVal sReferer As String, ByVal sAcceptTypes As Long, ByVal dwFlags As Long, ByVal dwContext As Long) As Long
Private Declare Function HttpSendRequestA Lib "wininet.dll" (ByVal hRequest As Long, ByVal sHeaders As String, ByVal dwHeadersLength As Long, ByVal lpOptional As String, ByVal dwOptionalLength As Long) As Long

Private Function submitPost(ByRef host, ByRef url_path, ByRef sendString) As Variant

  Dim dataArray() As Byte, dataPosition, dataSize

 'WinInet初期化
  Dim hInternet
  hInternet = InternetOpenA(vbNullString, INTERNET_OPEN_TYPE_PRECONFIG, vbNullString, vbNullString, 0)
  If hInternet = 0 Then
    submitPost = dataArray
    Exit Function
  End If

 'サーバ接続
  Dim hConnect
  hConnect = InternetConnectA(hInternet, host, INTERNET_DEFAULT_HTTP_PORT, vbNullString, vbNullString, INTERNET_SERVICE_HTTP, 0, 0)
  If hConnect = 0 Then
    InternetCloseHandle hInternet
    submitPost = dataArray
    Exit Function
  End If

 'リクエストを初期化
  Dim tmpURL As String * 255
  tmpURL = url_path
  Dim hRequest
  hRequest = HttpOpenRequestA(hConnect, "POST", tmpURL, "HTTP/1.1", vbNullString, 0, INTERNET_FLAG_RELOAD, 0)
  If hRequest = 0 Then
    InternetCloseHandle hConnect
    InternetCloseHandle hInternet
    submitPost = dataArray
    Exit Function
  End If

 'リクエストを送信
  Const strHeader = "Content-Type: application/x-www-form-urlencoded"
  HttpSendRequestA hRequest, strHeader, Len(strHeader), sendString, Len(sendString)

 'データ取得
  Dim readResult, tmpArray(1023) As Byte, tmpPosition, tmpSize
  dataPosition = 0
  dataSize = 0
  Do
    tmpSize = 0
    Erase tmpArray
    readResult = InternetReadFile(hRequest, tmpArray(0), 1024, tmpSize)
    If Not readResult = 1 Or tmpSize = 0 Then
      Exit Do
    End If

    dataSize = dataSize + tmpSize
    ReDim Preserve dataArray(dataSize - 1)
    For tmpPosition = 0 To tmpSize - 1 Step 1
      dataArray(dataPosition) = tmpArray(tmpPosition)
      dataPosition = dataPosition + 1
    Next
  Loop

 'クローズ処理
  InternetCloseHandle hRequest
  InternetCloseHandle hConnect
  InternetCloseHandle hInternet

  submitPost = dataArray

End Function

Public Function downloadFilePost(ByRef targetURL, ByVal sendArray, ByRef savePath) As Boolean

 'URLの分解
  Dim startE, endE, host, url_path
  startE = InStr(1, targetURL, "//") + 2
  endE = InStr(startE, targetURL, "/")
  endE = IIf(startE > endE, Len(targetURL) + 1, endE)
  host = Mid(targetURL, startE, endE - startE)
  url_path = Mid(targetURL, endE)

 'ポストデータのエンコード
  Dim jscript
  With CreateObject("ScriptControl")
    .Language = "JScript"
    Set jscript = .CodeObject
  End With
  Dim ix, sendBuffer
  For ix = 0 To UBound(sendArray) Step 1
    sendBuffer = Split(sendArray(ix), "=")
    sendArray(ix) = sendBuffer(0) & "=" & jscript.encodeURIComponent(sendBuffer(1))
  Next
  Set jscript = Nothing

  Dim data
  data = submitPost(host, url_path, Join(sendArray, "&"))

  If LenB(data) <= 0 Then
    downloadFilePost = False
    Exit Function
  End If

 'バイナリで書き込み
  With CreateObject("ADODB.Stream")
    .Type = 1
    .Open
    .Write data
    .SaveToFile savePath, 2
    .Close
  End With

  downloadFilePost = True

End Function

Permalink | 記事への反応(1) | 22:27

ツイートシェア

■プロテクト強化後のもふったーも予想以上に酷かった件(追記あり)

ことのあらまし

1. Twitterクライアントもふったーの作者「TweetDeckのconsumer secret簡単に抜ける、終わってる」(http://blog.livedoor.jp/blackwingcat/archives/1760823.html)
2. 別の誰か「もふったーのconsumer secretも簡単に抜ける」(http://d.hatena.ne.jp/kusano_k/20130318/1363640368)
3. もふったーの作者「プロテクト強化した」(http://blog.livedoor.jp/blackwingcat/archives/1762970.html)

「プロテクトかけたアルゴリズムを実装したバージョンに差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。

手順

動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアのリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。

だから、リバースエンジニアリングではいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。

この場合も同様だ。TwitterのGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。

OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。

HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))

ここで

• Kは鍵。この場合はconsumer secret
• Hは任意のハッシュ関数。この場合はSHA-1
• mはメッセージ
• ∥は連結
• ⊕はxor
• opadは0x5c5c5c...5c
• ipadは0x363636...36

である。

まずはこのあたりから攻めようと思った。SHA-1の計算にはいくつか特徴的な定数が使われるので、そこからSHA-1の計算に使われているであろう関数444190を特定する。この関数のエントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザで認証」ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。

CPU Disasm
Address   Hex dump          Command                                      Comments
00401311  |.  33F6          xor     esi, esi
00401313  |   8D8C24 A40000 /lea     ecx, [local.54]
0040131A  |.  394C24 14     |cmp     dword ptr ss:[local.90], ecx
0040131E  |.  75 0E         |jne     short 0040132E
00401320  |.  3BF5          |cmp     esi, ebp
00401322  |.  73 29         |jae     short 0040134D
00401324  |.  0FB68434 A400 |movzx   eax, byte ptr ss:[esi+esp+0A4]
0040132C  |.  EB 21         |jmp     short 0040134F
0040132E  |   3BF5          |cmp     esi, ebp
00401330  |.  73 1B         |jae     short 0040134D
00401332  |.  8B5424 18     |mov     edx, dword ptr ss:[local.89]
00401336  |.  52            |push    edx                                 ; /Arg1 =  [LOCAL.89]
00401337  |.  8D8C24 FC0000 |lea     ecx, [local.33]                     ; |
0040133E  |.  8BD6          |mov     edx, esi                            ; |
00401340  |.  E8 CB4D0000   |call    00406110                            ; \mofooter.00406110
00401345  |.  83C4 04       |add     esp, 4
00401348  |.  0FB6C0        |movzx   eax, al
0040134B  |.  EB 02         |jmp     short 0040134F
0040134D  |   33C0          |xor     eax, eax
0040134F  |   34 5C         |xor     al, 5C
00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al
00401358  |.  83C6 01       |add     esi, 1
0040135B  |.  83FE 40       |cmp     esi, 40
0040135E  |.^ 72 B3         \jb      short 00401313
00401360  |.  895C24 3C     mov     dword ptr ss:[local.80], ebx

0040134F  |   34 5C         |xor     al, 5C

が注意を引く。もしかしてこれはopadとのxorではないか?

00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al

はxorした結果を格納している。

先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。

Hex dump
64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F|
18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E|
05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C|
5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|

あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。

追伸

はてなは増田のスーパーpre記法で半角の＜＞が含まれていると投稿が出来ないのを早く直してください。

3/23 18:45追記

もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。

CPU Disasm
Address   Hex dump          Command                                  Comments
00401324  |.  8D4424 20     |lea     eax, [local.102]
00401328  |.  50            |push    eax                             ; /Arg1 = 
00401329  |.  E8 623A0400   |call    00444D90                        ; \mofooter.00444D90

ここでeaxが指すメモリーを見ると以下のようになっている。

01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10|
F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00|
40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57|
61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63|
79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36|
36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|

先頭32バイトのゴミを無視して0x36とxorすればconsumer secretが得られる。

Permalink | 記事への反応(6) | 00:47

ツイートシェア

■[th123] MotionState

sizeof(MotionState) = 0xa8
+0x00	byte ?
+0x01	byte ?
+0x02	byte ?
+0x03	byte ?
+0x04	short x_offset;
+0x06	short y_offset;
+0x08	short duration;
+0x0a	short imageNumber;
+0x0c	short transform_origin_x;
+0x0e	short transform_origin_y;
+0x10	short tex_width;
+0x12	short tex_height;
+0x14	byte blend_mode;
+0x15	BAADF00D (3)
+0x18	RenderInfo* type2;
+0x1c	short damage;
+0x1e	short proration;
+0x20	short guard_damage;
+0x22	short spirit_damage;
+0x24	short untech;
+0x26	short damage_motion_percentage;
+0x28	short limit;
+0x2a	short self_hitstop_hit;
+0x2c	short enemy_hitstop_hit;
+0x2e	short self_hitstop_guard;
+0x30	short enemy_hitstop_guard;
+0x32	short cardgain_hit;
+0x34	short cardgain_guard;
+0x36	short hit_effect_air;
+0x38	short hit_effect_ground;
+0x3a	BAADF00D (2)
+0x3c	float velocity_x;
+0x40	float velocity_y;
+0x44	short sound_type;
+0x46	short effect_type;
+0x48	byte attack_level;
+0x49	byte combo_correction;
+0x4a	BAADF00D (2)
+0x4c	uint fflags;
+0x50	uint aflags;
+0x54	Rect* collision;
+0x58	BAADF00D (4)
+0x5c	Rect* hitboxes;
+0x60	Rect* hitboxes_end;
+0x64	Rect* hitboxes_end;
+0x68	BAADF00D (4)
+0x6c	Rect* attackboxes;
+0x70	Rect* attackboxes_end;
+0x74	Rect* attackboxes_end;
+0x78	BAADF00D (4)
+0x7c	void* ?
+0x80	void* ?
+0x84	void* ?	
+0x88	short ?
+0x8a	short ?
+0x8c	byte ?
+0x8d	byte ?
+0x8e	byte ?
+0x8f	byte ?
+0x90	void* ?
+0x94	void* ?
+0x98	short ?
+0x9a	short ?
+0x9c	byte ?
+0x9d	byte ?
+0x9e	byte ?
+0x9f	byte ?
+0xa0	short ?
+0xa2	short ?
+0xa4	short ?
+0xa6	BAADF00D (2)

Permalink | 記事への反応(0) | 05:50

ツイートシェア

■C#用FMFリーダー

platinumで吐き出せるFMFを読み取るためクラスを置いておく。特に反省はしてない。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Data;

namespace RPG
{
    class MapFile
    {
        //FMFファイルのヘッダー
        struct FMFHeader
        {
            public string dwIdentifier;	// ファイル識別子 'FMF_'
            public int dwSize;			// ヘッダを除いたデータサイズ
            public int dwWidth;		// マップの横幅
            public int dwHeight;		// マップの高さ
            public byte byChipWidth;	// マップチップ1つの幅(pixel)
            public byte byChipHeight;	// マップチップ１つの高さ(pixel)
            public byte byLayerCount;	// レイヤーの数
            public byte byBitCount;		// レイヤデータのビットカウント
        }

        private FileStream fs;
        private BinaryReader br;
        private FMFHeader _head;
        private byte[] _data8 = null;
        private short[] _data16 = null;

        public int width
        {
            get { return _head.dwWidth; }
        }

        public int height
        {
            get { return _head.dwHeight; }
        }

        public int chip_width
        {
            get { return _head.byChipWidth; } 
        }

        public int chip_height
        {
            get { return _head.byChipHeight; }
        }

        //マップファイルを読み込む。
        //エラーが起きた場合は例外を投げます
        public void Load(String fname)
        {
            try
            {
                fs = new FileStream(fname, FileMode.Open);
                br = new BinaryReader(fs);

                //識別子を確認する
                _head.dwIdentifier = new String(br.ReadChars(4));
                if (_head.dwIdentifier != "FMF_")
                {
                    throw new Exception("ファイルが壊れています");
                }

                //ヘッダーの残りの情報を読み込む
                _head.dwSize = br.ReadInt32();
                _head.dwWidth = br.ReadInt32();
                _head.dwHeight = br.ReadInt32();
                _head.byChipWidth = br.ReadByte();
                _head.byChipHeight = br.ReadByte();
                _head.byLayerCount = br.ReadByte();
                _head.byBitCount = br.ReadByte();
                switch (_head.byBitCount)
                {
                    case 8:     //8bit layer
                        _data8 = br.ReadBytes(_head.dwSize);
                        break;
                    case 16:    //16it layer
                        int count = _head.dwSize / 2;
                        _data16 = new short[count];
                        for(int i = 0; i < count; i++)
                            _data16[i] = br.ReadInt16();
                        break;
                }
            }
            catch(Exception ex)
            {
                throw ex;
            }
            finally
            {
                br.Close();
            }
        }
        //マップファイルを閉じます
        public void close()
        {
            //読み込んだデータを破棄する
            _data8 = null;
            _data16 = null;
        }
        //マップファイルからチップ番号を取得します
        public int getValue(int layer_index, int x, int y)
        {
            if (_data8 == null &amp;amp;&amp;amp; _data16 == null)
                return -1;
            if (layer_index &gt;= _head.byLayerCount ||
                x &gt;= _head.dwWidth ||
                y &gt;= _head.dwHeight)
                    return -1;

            int index = 0;
            int layer_offset = getLayerAddr(layer_index);
            switch (_head.byBitCount)
            {
                case 8:     //8bit layer
                    index = _data8[layer_offset + x + y * _head.dwWidth];
                    break;
                case 16:    //16it layer
                    index = _data16[layer_offset + x + y * _head.dwWidth];
                    break;
            }
            return index;
        }
        //該当レイヤーが存在する_dataのindexを返す
        private int getLayerAddr(int layer_index)
        {
            if (layer_index &gt;= _head.byLayerCount || (_data8 == null &amp;amp;&amp;amp; _data16 == null))
                return -1;
            return _head.dwWidth * _head.dwHeight * layer_index;
        }
    }
}

#訂正

致命的なバグがあったので修正しました＆データを取得する部分をわかりやすくした

Permalink | 記事への反応(1) | 04:10

ツイートシェア

■転送量制限について考えてみる。

某プロバイダDとNTTのBフレッツでつなげてる自宅鯖で、合法的なisoイメージのbittorrent seederをやってみた。

周囲の迷惑もあるかなと思って、ピーク流量が1,000K[byte/sec] になるよう制限した。

昨日1日でだいたい平均 500K[byte/sec]の転送があったみたいだ。

Bフレッツだぜ？　光だぜ？　100Mだとか言ってるんだぜ？　余裕余裕。

で、これが月でどれくらいの転送量になるのか計算してみたんだ。

0.5M[byte/sec]*60[sec/min]*60[min/h]*24[h/day] = 43,200M[byte/day]

43.2G[byte/day]*30[day/month] = 1,296G[byte/day]

月1.3テラバイトとか！　ちりも積もれば山となるな。

さてここで問題です。俺はこの調子でbittorrentを回し続けても大丈夫なのでしょうか。

また調子こいてピーク流量の制限をもっとゆるくしても平気でしょうか。

他の人が使ってるプロバイダだったらどう？

Permalink | 記事への反応(0) | 23:58

ツイートシェア

■やっぱオライリーはバカだな

"What Is Web 2.0" Tim O'Reilly 2005/9/30

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

Core Competencies of Web 2.0 Companies

In exploring the seven principles above, we've highlighted some of the principal features of Web 2.0. Each of the examples we've explored demonstrates one or more of those key principles, but may miss others. Let's close, therefore, by summarizing what we believe to be the core competencies of Web 2.0 companies:

• Services, not packaged software, with cost-effective scalability
• Control over unique, hard-to-recreate data sources that get richer as more people use them
• Trusting users as co-developers
• Harnessing collective intelligence
• Leveraging the long tail through customer self-service
• Software above the level of a single device
• Lightweight user interfaces, development models, AND business models

ノイズを除去してまとめれば、要するに相互接続性を確保したWebサービスのことだ。

そしてそう言えばいいのである。

「どんなデータベース資産を蓄積してるんだい？」とかアホと違うか。外部から利用できないならそんなのどうでもいいんだよ。ソフトウェアをそのByte量で評価するのと変わらん。大きいコードにはいっぱい機能が詰まってるはずだみたいな。

結局分かってないから適切な表現ができないのだろう。

それに言ってること微妙に変えてないか、こいつ。

Permalink | 記事への反応(0) | 10:54

ツイートシェア

■ASPのファイル受信

'/** Requestオブジェクトから受信したデータを取り出します。
' * @return byte配列を格納した連想配列を返します。
' */
Function getRequestItem()

  If Request.TotalBytes <= 0 Then
    getRequestItem = Null
    Exit Function
  End If

  Dim data
  Dim separator
  Dim dataArray
  Dim buffer
  Dim filePath
  Dim fileName
  Dim ix
  Dim stringIndex
  Dim myCrLf
  Dim items
  Dim itemName

  myCrLf = convertAsc(vbCrLf)
  Set items = Server.CreateObject("Scripting.Dictionary")

  data = Request.BinaryRead(Request.TotalBytes)
  data = LeftB(data, UBound(data) - 3) & myCrLf

  separator = MidB(data, 1, InStrB(1, data, myCrLf) + 1)

  dataArray = SplitB(data, separator)

  For ix = 2 To UBound(dataArray) Step 1
   '1行読み込み
    buffer = MidB(dataArray(ix), 1, InStrB(1, dataArray(ix), myCrLf) - 1)

   'アイテム名の取得
    stringIndex = InStrB(1, buffer, convertAsc("name="))
    If stringIndex > 0 Then
      itemName = convertUnicode(MidB(buffer, stringIndex + 6, InStrB(stringIndex, buffer, ChrB(34)) - stringIndex))
     Else
      itemName = ""
    End If

   'ファイル名の取得
    stringIndex = InStrB(1, buffer, convertAsc("filename="))
    If stringIndex > 0 Then
      filePath = MidB(buffer, stringIndex + 10, InStrB(stringIndex, buffer, ChrB(34)) - stringIndex)
      fileName = RightB(filePath, LenB(filePath) - LastInStrB(0, filePath, convertAsc("\")))
     Else
      fileName = ""
    End If

   'データ部の取得、改行コードの切り捨て
    buffer = RightB(dataArray(ix), LenB(dataArray(ix)) - InStrB(1, dataArray(ix), myCrLf & myCrLf) - 3)
    buffer = LeftB(buffer, LenB(buffer) - 2)

    items.Item(itemName) = parseBytes(buffer)
  Next

  Set getRequestItem = items
  Set items = Nothing

End Function

'/** 文字列の最後尾から指定文字を検索します。
' * @param Start 検索する開始文字位置を指定します。
' * @param String1 検索対象の文字列を指定します。
' * @param String2 検索する文字列を指定します。
' */
Function LastInStrB(ByRef Start, ByRef String1, ByRef String2)

  Dim ix
  Dim lastIndex
  Dim searchLength

  searchLength = LenB(String2)
  lastIndex = LenB(String1) - searchLength + 1
  If Start > 0 And Start < lastIndex Then
    lastIndex = Start
  End If
  For ix = lastIndex To 1 Step -1
    If MidB(String1, ix, searchLength) = String2 Then
      LastInStrB = ix
      Exit Function
    End If
  Next

  LastInStrB = 0

End Function

'/** アスキー文字列に変換します。
' * @param String 対象の文字列を指定します。
' */
Function convertAsc(Byref String)

  Dim ix
  Dim ascii

  ascii = ""
  For ix = 1 To Len(String) Step 1
    ascii = ascii & ChrB(AscB(Mid(String, ix, 1)))
  Next

  convertAsc = ascii

End Function

'/** Unicode文字列に変換します。
' * @param AscString 対象のアスキー文字列を指定します。
' */
Function convertUnicode(Byref AscString)

  Dim ix
  Dim unicode

  unicode = ""
  For ix = 1 To LenB(AscString) Step 1
    unicode = unicode & Chr(AscB(MidB(AscString, ix, 1)))
  Next

  convertUnicode = unicode

End Function

'/** バイナリ対応版Split関数です。
' * @param String 対象の文字列を指定します。
' * @param Delimiter 区切り文字を指定します。
' */
Function SplitB(Byref String, Byref Delimiter)

  Dim ix
  Dim lastIndex
  Dim searchLength
  Dim start
  Dim datas()
  Dim dataIndex

  dataIndex = 1
  start = 1
  delimiterLength = LenB(Delimiter)
  lastIndex = LenB(String) - delimiterLength + 1

 '最初から1文字ずつ繰り返します。
  For ix = 1 To lastIndex Step 1
   'データを比較します。
    If MidB(String, ix, delimiterLength) = Delimiter Then
     'データを取り出せたら配列に格納します。
      ReDim Preserve datas(dataIndex)
      datas(dataIndex) = MidB(String, start, ix - start)
      dataIndex = dataIndex + 1
      start = ix + delimiterLength
    End If
  Next

  SplitB = datas

End Function

'/** Byte配列を返す関数です。
' * @param data 対象のデータを指定します。
' */
Function parseBytes(Byref data)

  Const adLongVarBinary = 205
  Dim recordset

  If LenB(data) <= 0 Then
    parseBytes = CByte(0)
    Exit Function
  End If

  Set recordset = Server.CreateObject("ADODB.Recordset")
  recordset.Fields.Append "UpLoadBinary", adLongVarBinary, LenB(data)
  recordset.Open
  recordset.AddNew
  recordset.Fields("UpLoadBinary").AppendChunk data
  recordset.Update

  parseBytes = recordset.Fields("UpLoadBinary").Value
  recordset.Close
  Set recordset = Nothing

End Function

Permalink | 記事への反応(1) | 22:00

ツイートシェア