はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
みたのブログ: 障害に備えて役立ちそうなブートオプションを教えてください
会社の業務の一環でサーバセレクトという雑誌の六月号に 4 ページ記事を書きました、 いま日本にもどっているので、ちょっと気になって確認してみたところページの都合上いくつかボツになっている部分があったので、それを抜粋して紹介します。 panic= panic_on_oops= kernel.panic と kernel.panic_on_oops カーネルパラメータと同じ設定をするブートオプションです。 なぜ同じような設定がカーネルパラメータとブートオプションの両方にあるかという理由は、カーネルパラメータは通常 /etc/sysctl.conf の設定ファイルに記述されたものがシステムの起動スクリプト実行中に設定されます。それ以前に パニックや Oops が起こる場合に備えて、デフォルト値 (panic=0, panic_on_oops=0) 以外に設定したい場合に利用します。 log_bu
みたのブログ: ブートオプションの一覧はどうやったらわかりますか
サーバセレクトという雑誌の六月号ボツになった記事の抜粋のつづきです Documentation/kernel-parameters にブートオプションの一覧や解説が書かれています。ただし、カーネルコンフィギュレーションによっては無効のものもありますし、このファイルには記述されていないものもあります。 もし利用しているカーネルイメージ vmlinux があればつぎのようにしてブートオプションの一覧を得ることができます。$ nm -n vmlinux | grep __setup_str_[a-zA-Z_] | \ awk '{ print "p (char *) 0x" $1}' > list-setup.cmd $ gdb -batch -x list-setup.cmd vmlinux | awk '{print $4}'ただし、vga ブートオプションや parse_cmdline
みたのブログ: モジュールパラメータの一覧はどうやったらわかりますか
サーバセレクトという雑誌の六月号のボツになった記事の抜粋のつづきです。 モジュールについての情報を得るには modinfo コマンドを利用します。設定可能なモジュールパラメータの説明だけ表示したい場合はつぎのようにします。# modinfo -p <モジュール名>モジュールをロードしたあとに動的に変更できるものや、設定値を参照する価値のあるモジュールパラメータは sysfs ファイルシステムの以下のファイルから読み書きできるようになっています。/sys/module/<モジュール名>/parameters/<パラメータ名>
みたのブログ: カーネルに組み込まれたモジュールの場合はどうですか
サーバセレクトという雑誌の六月号のボツになった記事のつづきです。 カーネルに組み込んでビルドされたモジュールのモジュールパラメータを設定したい場合は、カーネルのブートオプションとして設定する必要があります。 例えば e100 ネットワークドライバをカーネルに組み込んでビルドし、そのモジュールパラメータ debug を 1 に設定したい場合は e1000.debug=1 というブートオプションを与えます。 つまり、以下のようにブートオプションを設定します。<モジュール名>.<モジュールパラメータ名>=<モジュールパラメータ値>またカーネルに組み込まれたモジュールについての情報は modinfo コマンドで表示することはできません。ただし、カーネルイメージ vmlinux があれば、つぎのようにして組み込みモジュールパラメータの一覧を知ることができます。$ nm -n vmlinux | gr
smart_ptrはスマートなポインタか？(2) - やねうらおブログ(移転しました)
昨日のエントリに対して返答(id:okzk:20060623)が来たので回答しておきます。 ■ 動的に型サイズを取得できるのか？ 昨日のエントリは、ひなた先生にあった「動的な型サイズを求めることができる」というところに ついてのツッコミであって、smart_ptrの実装とか有用性とか使用する際の注意事項とかは問題に してないんですよー。 「動的な型サイズを求めることができる」なんて書いたかなー？と思って、元原稿を読み返すと…。 ケンイチ「それであれば、ポインタをwrapするようなtemplateクラスを作って、virtualな operator++を定義して、動的な型のサイズを加算するようにしておけばいいのではないでしょうかね」 「動的な型のサイズを加算する」とは書いてあるけど、「動的な型のサイズを(upcastされたポインタから)動的に求めることができる」とは書いてないのだけど…。私とし
動的に型サイズを求めるスマポ - 兼雑記
http://d.hatena.ne.jp/okzk/20060622#1150958620 から。動的にサイズを調べるのは以下のようなコードはどうでしょうか。先に言っておくと冗談です。 GCC と cl.exe で確認。たぶんきっと他でもだいたい動きますおそらく。 template<class T> class smart_ptr { T* p_; int size_; static int size_of(void* vp) { char* p = (char*)vp; void* vt = *(void**)p; for (p++; vt != *(void**)p; p++); return p-(char*)vp; } public: explicit smart_ptr(T* p) : p_(p) { #if 0 // 落ちる size_ = sizeof(T); #else
smart_ptrはスマートなポインタか？(1) - やねうらおブログ(移転しました)
id:okzkさんからSoftware Design 7月号のひなた先生で気になったところについて指摘をいただいた。 ■ smart_ptrとは？ まず読者のために前説。ここで出てくるsmart_ptrというのは、yaneSDK3rdに実装されている、smart_ptrのことである。(→gggの24章) ■ 指摘1 つまりはそのsmart_ptrにポインタを渡す時に「アップキャストされていない本来の型」の ポインタとして渡す必要があるぢゃないかと。は正しいです。私のsmart_ptrを用いる場合、newはsmart_ptrのコンストラクタ以外のところでは書かないというコーディング方針を守る必要があります。(循環参照の問題があるのでboost::weak_ptrに相当するものがあるべきだとは思います。) boostを使う場合でも、boost::shared_ptr , boost::weak
TOYOTAで考えた、見える化の本質 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。 まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。 今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くの本があるかと思いますので、見える化をキーワードにして
EXEファイルの内部構造（PEヘッダ）：CodeZine
はじめに 皆さんは、アプリケーションを起動させるEXEファイルの中身について考えてみたことはありますか？ 本稿では、EXEファイルの内部構造について解説していきます。特にEXEファイルに関する日本語の資料が少ないのが現状です。そのため、解析に手を出してみたいと思っても挫折してしまった方も少なくないのではないでしょうか。本稿は、筆者自身の経験を踏まえ、実際にEXEファイルの解析ができるようになるための資料となるよう解説していきます。 前回、第1回では、EXEファイルの概要として、MZシグネチャ、マシンタイプ、ネイティブコード、リソース、デバッグ情報などについて説明しました。これらの一部はPEヘッダと呼ばれる場所に格納されています。また、そのPEヘッダより前にあるEXEファイルの先頭には、IMAGE_DOS_HEADER構造体、MS-DOS用スタブなどがあり、それらがWindowsの元となった
ユビキタスの街角 全世界プログラミング
という論文を 夏のプログラミングシンポジウムに 投稿予定... ------------------------ 計算機やインターネットの爆発的普及にもかかわらず、 プログラミングを楽しむ人の数は全然増えていないようである。 初期のパソコンでは購入者の多くがBasicプログラミングを楽しんでいたものだが、 現在のパソコンにはプログラム開発環境は標準搭載されておらず、 環境の整備には多大な労力と資金が必要で、 プログラミングするのは計算機オタクだけという状況が続いていた。 しかし幸いなことに、以下のような理由により状況は好転しつつある。 手軽な開発環境が増えてきた 標準的なWebブラウザではJavascriptを利用できるし、 Basic並の手軽さで使える Processing のようなシステムも普及しつつある 扱える対称が増えてきた Phidgets や GAINER のようなシステムを利
路地裏 ソース解読研究所: 時間は無限?
マシンを立ち上げるとLinuxカーネルが立ち上がります。そして、マシンを停止するまでカーネルが動きつづけるわけです。この間、カーネルは刻々と時を刻んでいきます。 そこでカーネルでの時間の管理に使われるのが、jiffiesという変数です。 kernel-2.4では、kernel/timer.cで次のように定義されています。 ---- unsigned long volatile jiffies __cacheline_aligned; ---- unsigned longなので、32bit環境では、0〜0xffffffffの範囲を表すことができます。 このjiffiesは、timer割り込みと呼ばれる処理の際に1ずつ増加していきます。timer割り込みの頻度は、"HZ"として定数で定義されています。 linux-2.4.21/include/asm-i386/param.h ---- #if
無理して(圏論的)モナドをJavaで説明してみる - 檜山正幸のキマイラ飼育記 (はてなBlog)
どうも関数型の風（微風かな？）が吹き始めているようです（「技術者の技術的教養は変化するのか（しないのか）」参照）。とはいえ、ほとんどの現場で実際に使われているプログラミング言語はせいぜいオブジェクト指向と称するものです。そんな状況ですから、中途半端な過渡的方便としては、“バカバカしくめんどくさい”記述になるのを承知で、現場的言語でファンクショナルな、いやもう一声、カテゴリカルな概念を説明するのも無意味ではないかもしれません（とか言ってみたが、単に興味本位で実は無意味だろう、ダハハハハ）。 Listモナド それで今日の話題は、Listなんです。型パラメータXを付けたList<X>の形のものね。これは、「型Xを渡すと新たな型を創り出す機能」ですから、「型に型を対応させる関数」ともいえます。 このList<X>は、単に「型→型」対応を与えるだけでなく、独特の（しかし普遍性もある）構造と法則性を持
モナドの定義とか - 檜山正幸のキマイラ飼育記 (はてなBlog)
モナド関係で、KMさんと酒井さんにコメントをいただいて、僕もコメント欄に書き込みました。話が少しややこしくなったので、このエントリーで続きを。 コメント欄のやりとりで分かったことは、“Haskellのモナド”がモナドもどきではなくて、どうも、正真正銘の圏論的モナドであるらしいことです。であれば、Haskell知らずの僕が語ってもまー大丈夫かな、と。（メモ編に書くべき内容かもしれないけど。） Listは典型的モナドに思えないかも知れない 「Listモナドは典型的モナドだ」と僕は書いたのだけど、Haskellのヒトには違和感あるかもしれないですね -- Listはたいていのプログラミング言語でサポートされている平凡なデータ構造ですから。状態遷移とか入出力のような副作用を表現するモナドのほうが“モナドらしい”のでしょう、おそらく（憶測モード）。そうであってもなお、Listがやっぱり典型例なのは事
「モナド入門」への補足とか応答とか - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日の「モナド入門」、一晩のあいだにブックマーク数が70近くまで。タイトルでウケたのかしらね？ しかしそれにしても、モナドなんかに（って語弊があるな）興味を持つ人がたくさんいるってのは驚きです。技術者の技術的教養がほんとに変化しているのかな？ それはともかく、ブックマーク・コメントに応える形で、補足をしておきます。 sshiさん：結論の三つ組とhaskellのモナドの対応がよくわからず。 [後日変更 date="20050421"]トラックバックいただいたnanakosoさんのエントリ（http://www3.atwiki.jp/nanakoso/pages/15.html）が、この問題を扱っています。当該エントリーの2回前から順に読むと、extの対応物を求めてラムダの森をさまよい歩く物語として読めます。(=<<)に出会った場面に僕も感動しました。[/後日変更] コメント欄でKMさんにご教
さらに「モナド入門」に補足：記号だの図だの - 檜山正幸のキマイラ飼育記 (はてなBlog)
「モナドの定義とか」への追記で書こうかと思ったけど、ちょっと長いからエントリー起こします。 まず、「Kleisliトリプルの拡張オペレータ（extension; 僕はextと書いた）のHaskellでの対応物」の件は、nanakosoさんが“彷徨の末に落ち着いた経緯”を報告なさっているので、http://www3.atwiki.jp/nanakoso/pages/16.htmlをご参照ください。「>>=」と左右逆の形状の記号「=<<」で表現される高階関数は、完全にextと一致します。 右向きの矢印に見える「>>=」のほうは、右側オペランドだけをfixした状態(>>=f)がext(f)になりますが、その形状（左から右に向かう）の印象から、a >>= f で「引数aをfの拡張に送る／渡す」と読むのが心理的に自然な気がします（あくまで印象論ですが）。左から右へと書けることが>>=の重要な点かと思
howm wiki - モナド
This Wiki is frozen. Use GitHub for reports, discussions, etc. 訳あって Haskell 試食中. モナドって, こんなイメージでいいんでしょうか? (参考ページ) やさしい Haskell 入門 (バージョン98) モナドのすべて haskell-jp ML MonadicContinuationPassingStyle (英語) 2ch Haskell スレ過去ログの 500 前後 慣れない内容は, 頭がしんどい 慣れない表現も, 頭がしんどい 両方いっぺんだと, もう○×△□… なので, ひとまず haskell は置いといて, scheme にしてみます. Intro. ふつうの「値」を包んで, ふわふわした謎な外見の何か(以下「ふわふわ」) にするラッパー ret (return のつもり)を考えよう. (ret 3)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
