http://media.itc.u-tokyo.ac.jp/ktanaka/dobutsushogi/
78手で後手勝ちなのか。
盤面がすごく狭いのに、総局面数は、6億以上。
実際の将棋もいずれ解明されるんだろうけど、
完全に計算しつくすのは難しそうではあるなあ。
http://d.hatena.ne.jp/takoratta/20120902/1346553688
禅問答みたいだけど、やりたいことをシンプルに実行できるようにする、
という考え方は、事務手続きを考えたり、運用フローを決めたり、
そんな場面でも応用が効く。
たとえ裏側では面倒臭いことをしていたとしても、ユーザからは
シンプルに見えたほうがユーザにはやさしいよね。
http://www.machu.jp/diary/20110527.html#p01
screen を使うのが楽。
.screenrc に以下を書いておいて、
deflog on
logfile "logs/screen-%Y%m%d-%n.log"
Ctrl+Tの後に大文字の「H」で記録を開始。
もう一度同じコマンドで記録終了。
※screenコマンドのコントロールコードは .screenrc に
以下を書いて Ctrl-T に変更しております。
escape ^t^t
http://d.hatena.ne.jp/tmatsuu/20120320/1332262068
au の Wi-Fi の数が増えてきたので、使えると便利かも。
暇ができたら設定してみようかと。
http://howm.sourceforge.jp/cgi-bin/hiki/hiki.cgi?Pdumpfs
pdumpfs は手軽なので良く使ってた。
ところが、最新の Ubuntu では pdumpfs が apt-get で入らない。
それどころか pdumpfs 自体がそもそも最新の Ruby じゃ動かんのか。
うーむ、と思ってたら発見したのがこのスクリプト。
ありがたい。
rsync に --link-dest なんてオプションがあったのね。
ところで、今はどんなバックアップソフトが流行りなんだろ?
あれこれ試してみるかなあ。
http://www.ideaxidea.com/archives/2012/08/github_slides.html
創業5年、108名、辞めた人はいない
- 2/3のスタッフがリモートで勤務 → 家族の事情で引っ越してもOK!
- 勤務時間は自分で決める、もちろんお休みや長期休暇も → (仕事をしているときは)いつでも誰でもクリエイティブ!
- 自分がやりたいプロジェクトだけをやれる → 疲弊してしまう人がいない!
- ミーティングなし。チャットで済ませる → 作業中に邪魔されることがない!
- マネージャいない。 → 彼らは邪魔するだけでしょ?
良いなあ。
Githubがちゃんと利益をあげてるからできることなんだろうけど。
http://d.hatena.ne.jp/nappa_zzz/20120331
すごく早くタイプするやり方。
すげーわ。
タッチタイプで満足しちゃ駄目で、
なぜキーボードに執着する人がいるのかがわかる。
http://blog.64p.org/entry/20120704/1341360828
たしかに新しいフォーマットを考えるよりも
既存の良く使われるフォーマットを使うほうが良いしね。
Yamlは、バージョン違いでハマるのか。
具体的な記法は wikipedia に書かれている。
Wikipedia - JSON
英語版にXMLとの比較もある。
これ見るとやっぱりXMLは絶対使いたくない。
Wikipedia - JSON
http://www.publickey1.jp/blog/12/chaos_monkeynetflix.html
Chaos MonkeyはAmazonクラウド上で使うツール。
Amazonクラウド上のインスタンスをランダムに落としまくることで、
サービスに対して仮想的な障害を引き起こしてくれます。
エンジニアがいるときだけ、わざと障害を起こせる
あえてわざと管理された範囲内の障害を日常的に引き起こし、
それに日常的に対応できていることを証明し続けることで、
本物の障害が起きても問題なく対処できることが証明できるわけです。
なるほどねえ。
消防や警察や軍隊がやっちゃ駄目な気はするけど。
この辺のやりとりが面白かった。
たしかに2/29があるかどうか、というほうが素直な気もする。
http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20120712
http://jarp.does.notwork.org/diary/201207b.html#201207141
http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20120718
深いわ。
こういう話好きだ。
こういうノウハウは使わないにこしたことないんだけど。
0. あらかじめ作ってあったパスワードリセット用のUSB-Keyを使う
---
セーフモードで立ち上げて、パスワードリセットできる。
でもそんな準備してるぐらいなら、パスワードは紛失しないと思うんだぁ。
1. 専用ツールを使う方法
---
http://www.maruko2.com/mw/Windows%E3%81%AE%E5%88%86%E3%81%8B%E3%82%89%E3%81%AA%E3%81%8F%E3%81%AA%E3%81%A3%E3%81%9F%E7%AE%A1%E7%90%86%E8%80%85%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E3%82%92%E3%83%AA%E3%82%BB%E3%83%83%E3%83%88%E3%81%99%E3%82%8B
これは簡単。
対応OSも沢山。
Windows NT 3.51 と NT 4 の全てのエディション(Server, Workstation)と全てSP
Windows 2000 の全てのエディション(Professional, Server) と全ての SP
Windows XP の全てのエディション(Home, Professional など)と全ての SP
Windows Server 2003 の全ての SP
Windows Vista の 32/64bit 版と SP1
Windows 7 の全てのエディション
Windows Server 2008
でも、DELL の R820 だと kernel panic が出てツールが起動しない。
新しい筐体だとドライバーが対応してないとかは良くあることだ。
2. OSのインストールディスクを使う
---
http://technikblog.rachfahl.de/losungen/windows-server-2008-administrator-passwort-vergessen/?lang=en
シェルで立ち上げて、cmd.exe を Utilman.exe で置き換える。
無理矢理感が素敵。
でも、新しい筐体だとデバイスドライバーが、Windowsのインストーラに
入っていないから、専用のインストール用のユーティリティディスクから
起動する必要があったりするんだ。
でもって、シェルが起動できなかったりするんだよ。
むぅ。
3. あきらめて再インストールする
---
結局これを選択。
負けた気分だけどまあ仕方ない。
http://itpro.nikkeibp.co.jp/article/COLUMN/20120719/410078/
仕様記述言語のVDMを使うことで、仕様外の動作をするバグは防げる、
という理解で良いのかしら。
問題は仕様に問題がある場合だけど、仕様外の動作が防げれば、
仕様の問題も洗い出しやすいし、仕様を直した後の実装への反映も楽か?
Wikipedia - VDM
この辺の記事が参考になるかな。
誰でも使える形式手法:ライトウェイトな形式手法で高品質な仕様をこの手に!
http://monoist.atmarkit.co.jp/mn/articles/0809/17/news125.html
同じ用な考え方の言語として Coq なんかも面白い。
プログラミング Coq 〜絶対にバグのないプログラムの書き方〜
http://www.iij-ii.co.jp/lab/techdoc/coqt/
LL魂(Lightweight Language Spirit)のときの今井さんのプレゼン
http://ll.jus.or.jp/2007/show/Event/Session/#H-dh4f51
こういうメタプログラミング的なものは、使いこなれば、
便利そうなんだけど、理解するハードルは高い気はする。
高校や大学で使う数学記号はとても便利なんだけど、
理解しないと使いこなせない、というのに似てる気がする。
http://wired.jp/2012/06/20/beard-gallery/
大事なものは「あご髭」だという。
C言語を開発したケン・トンプソンとデニス・リッチー。
非凡なるあご髭をたくわえた二人の天才。
Javaを開発したジェームズ・ゴスリン。
プログラミング言語の成功があご髭にあることをはっきり示す写真。
C++を設計したビャーネ・ストロヴストルップ。
当然ながらかつてはあご髭をたくわえていたが、その後これを剃る過ちを犯した。
Lispの開発者ジョン・マーカーシー。
彼は50年来あご髭をたくわえており、Lispも50年以上利用されている。
SmallTalkを作ったアラン・ケイ。
将来性のある言語だったがあご髭がなかったことで苦戦した。
Perlはクールだが、ラリー・ウォールがあご髭を生やしていれば、
もっとクールだったかもしれない。
トーマス・カーツはBASICを開発した。
ただ、彼には普通の口髭があるだけだった。
SIMURAをまだ使っている人はいないだろう。
おそらくクリスティン・ニゴールがよく髭を剃っていたためだ。
Cobolの開発者であるグレイス・ホッパー[右から2番目の女性]は、
この法則の例外だ。
ヒゲを剃っちゃいかん、ってことはわかった。
http://www.visual6502.org/JSSim/expert.html
JavaScript で書かれた 6502 のシミュレータ。
なんかすごい。
6502は Apple II やファミリーコンピュータに使われたCPU。
Wikipedia - MOS_6502
http://jun.artcompsci.org/talks/fukui20120614.pdf
本当に国家プロジェクトは駄目だなあ。。。
開発することにしたものも、開発のしかたも間違っていた
多分、官僚に判断をゆだねてるのが間違いじゃないかした。
ひょっとすると、判断が難しいことが専門家はわかってるから、
官僚に甘えてる可能性はないかしら?
http://itpro.nikkeibp.co.jp/article/Active/20120528/399235
製品化の第一弾となるのが、スマートフォン向けで多用されている
ARM系プロセッサを採用したサーバーだ。
高さ18cm、幅48cmほどの4Uサイズの筐体に、288台もの物理サーバーを集積させる。
2012年半ばまでに、出荷する計画だ。
消費電力を見ると、4Uで、1800W。
結構電力使うな。
頑張って、1台のラックに10台詰むと、18000W。
ラックに、20KVA引けますか?、とか聞かれちゃうようになるんじゃろか。
http://d.hatena.ne.jp/Takeuchi-Lab/20120612/1339464759
中央大学理工学部電気電子情報通信工学科教授の竹内健氏らの研究グループは、
高速な書き換えが可能なReRAM(抵抗変化型メモリ)と大容量のNANDフラッシュ・メモリを
組み合わせたハイブリッド構造のSSDアーキテクチャを開発した。
NANDフラッシュ・メモリのみを用いた従来のSSDに比べて、書き込み性能を11倍、
消費電力を93%減、書き換え寿命を6.9倍にできるという。
キャッシュとアルゴリズムだけで大幅性能アップ。
ReRAM の説明を読むと、将来的には SSD に置き変わる可能性があるのか。
Wikipedia - ReRAM
竹内先生の本↓。面白いらしい。
世界で勝負する仕事術最先端ITに挑むエンジニアの激走記