9704
コメント:
|
2285
|
削除された箇所はこのように表示されます。 | 追加された箇所はこのように表示されます。 |
行 1: | 行 1: |
#acl Known:admin,read,write,delete,revert All: | #acl alstamber:read,write,delete,revert All:read |
行 12: | 行 12: |
== rainbowさんはどこにいるの == * 192.168.2.20-30にいるらしい. * redは192.168.2.19にいるらしい. |
|
行 31: | 行 28: |
{{{ #!wiki caution '''温度を変更したら、再度元に戻しましょう''' }}} |
|
行 38: | 行 39: |
== 自由とはなにか == * すごく哲学的な話ですが。 * 件の掲示板でもめている話を見ていると、結局「自由とはなんなのか」という部分に帰着するのではないかなと思っている。 * 自由とは人間の権利の一つといっていいだろう。 * もっと言えば人間の権利の中でもっとも重要な存在のひとつと言えるだろう。 * ひとつといったのは、なにも自由であることだけが人間の権利ではないから。 * 極端なことを言えば自由を制限される権利というのも人間にはある。自由を制限されたほうが最終的に良い結果を生むことだってある(←重要)。 * 自由は人間にとってもっとも重要な権利、すなわち天賦の権利であるから、とうぜん最優先に保証されなければならない。 |
== 最大の素数 == * [[attachment:biggest_prime.txt]] |
行 48: | 行 42: |
* 今回の話で言うと、MMAでなにか新しいことを始めようとしたときまず重要視されなければならないのが、それに参加している人々が自由に行動できることだろう。 * なにか他の理由でそうした自由な行動が阻害されるようなことがあるのであれば、その原因を取り除かなければならない。 |
== time関数がオーバーフローする時刻を求める == * I科基礎のレポートに出たので。 * time関数は32ビット符号付き整数なので、2^31-1が扱える最大。 * よってUNIX時間で2^31-1秒がいつなのかを調べれば良い。 * こういった問題はスクリプトに解かせるのが良い。 |
行 51: | 行 48: |
* 自由な行動の保障、それを阻害するものの除去は、結果としてよい成果を生むだろうし、今回の案においてもそれを念頭においた条文が練られるべきだと思う。 | === pythonの例 === {{{#!highlight python import time print(time.asctime(time.gmtime(2**31-1))) }}} {{{ % python hoge.py Tue Jan 19 03:14:07 2038 }}} |
行 53: | 行 58: |
== 自由を制限することで生まれるもの == | === rubyの例 === {{{#!highlight ruby puts(Time.at(2**31-1).utc }}} {{{ % ruby hoge.rb 2038-01-19 03:14:07 UTC }}} |
行 55: | 行 67: |
* しかし、MMAというサークルに大きな影響をあたえるようなもの(調布祭なりなんなり)に関しては、一歩引いて考える必要があるだろう。 * 自由は良い成果を生むことがあるが、すべてを自由にした結果、うまくいかなくなることも当然あるだろう。 * 市場の失敗という言葉がある。自由市場に任せた結果物事が失敗した例である。 * MMAに大きな影響を与えるようなものは、失敗していいような物ではない。 * メンバーの自由な行動と同時に、その計画(あえてプロジェクトとは書かない)が確実に成功することが保証されねばならない。 * 計画が確実に成功するために重要なことはいくつかあるが、進捗状況の透明化というのは重要なファクターだろう。 * 進捗状況が見えない計画は、何をやっているのかわからなくなる。何をやっているのかわからなくなるど、あとどうすれば成功に導けるのかわからなくなる。 * 進捗状況を透明化するためには、「最初仕様だけを定めて、あとは自由。適当に集まって大雑把なやりとり」では不十分ではなかろうか。 * 計画の確実な成功が保証されなければならない計画に対しては、やはりはっきりと定まったミーティングを設けるべきだと私は思う。 * 自由は重要だが、同時に計画の確実な成功を保証するためには、ある程度の自由の制限は必要である。 * MMAに大きな影響を与える計画である以上、そのメンバーのみの問題ではないのだ。 * 例えればMMAに大きな影響を与える計画は「公共事業」のようなものであろう。 * 進捗状況を透明化することで、このような利点もある。 * 新規に計画に参加したいという人が現れたとき、進捗状況がはっきりと分かっていると素早く計画に合流できる。 * これは定期的なミーティングなしになぁなぁで計画を進めていると難しいことではなかろうか。 * つまり、新規メンバーの「自由な参加」を進捗状況の透明化は促すと言えるのではないかと思う。 * 今回の案では、MMAに大きな影響を与える計画以外に対してはミーティングを「推奨」としている。 * 提案者の意図は私にとって完全に知り得るものではないが、ミーティングという方式によって少なくとも上のような利点が生まれ得る、という点にフォーカスしているのだろうと思う。だからわざわざ「推奨」としているのだろう。 * 少なくともMMAに大きな計画を与え得ない計画に対しては、「必ず成功させなければならない」までの責任は発生しないと私は考える。 * ここまで来て、「MMAに大きな影響を与える計画」についてはもう少し精密な定義がなされても良いのではないかと思った。 * 「強制」という言葉にアレルギーのある人はやはり一定数いるものだ。 == 自由を制限する上で気をつけなければならないこと == * 自由の制限によって以上のような利点が生まれるとして、その上で気をつけなければならないことがある。 * 過剰な自由の制限はかえって利点よりも欠点が上回ってしまうことにつながるからである。 * 原案を読むと、ミーティングに関して頻度の目安は設けているが、ある程度頻度を変えられるようになっている。 * こうした配慮は、過剰な自由の制限を防ぐ上で重要だろう。 * 「1週間に一度やらなければならない」という意識が、計画の進行の妨げになっては全く意味が無い。 * もちろん頻度の変更に当たって、その定期性、リアルタイム性が失われてはならない。 * 少なくとも次のミーティングをいつ行うのか、という目安は定める必要があるだろう。 == MMAが現実に抱え込んでいるタスクをめぐって == * 僕は新入部員なので、MMAがどんなタスクを抱え込んでいるかどうかすべて知っているわけではない。 * しかし、数年前に比べて仕事量が増えているのは事実だろうと思う。 * 仕事量が増えているにもかかわらず、そうしたタスクが部員に上手に振り分けられていないのが現状ではなかろうか。 * 一部の人の様子を見ていると僕にはそう思える。 * ミーティングおよび部会報告による作業状況の可視化は、こうしたタスクの振り分け失敗を防ぐ手段となり得るのではないかと思う。 * 部会報告によってタスクの大まかな状況を知ることができ、ミーティングによってタスクの内部状況を知ることができる、という感じだろうか。 * MMA全体に大きな影響を与える計画は、やはり規模の大きなものが多く、タスクの上手な振り分けを行えるようにすることが重要ではないかと思う。 == いろいろ思ったこと == * この案が出てきて以来、いろんな人が活発に意見を出しているのを見て「このサークルって真面目だなぁ」とか思った。 * UECの中にはここまで真剣に自分のサークルの運営を考えていない人もいるだろうに。 * 1年生からもっと活発な意見が出ればいいと思う。部会でも掲示板でも1年生から意見が出ず、2年3年の独壇場になってしまっているのは残念だ。 * 1年後ないし2年後、MMAの主役となるのは今の1年生である。サークルの今後の運営に関わる重大な議案だと思うので、1年生も意見を出していけるようになればいいなと思ったり。 * ただむしろ、1年生が発言しにくい環境が形成されている気がしなくもない。 * 2年3年がやんや言っているところに、入っていくのはやはり気が引けるというものだ。自分ならそうである。 * '''しかし新入部員がこんな偉そうなこと書いていいんだろうか''' |
* 結論:スクリプト言語は楽 |
メモ
- Tipsとか備忘録とか.
Macで公開鍵認証でsshするときに, パスフレーズを毎回入力したい
- 次のフレーズをMacの.zshrcに記述.
unset SSH_AUTH_SOCK
覚えておくと便利なラテン語略記法
略記 |
ラテン語 |
意味 |
e.g. |
exempli gratia |
for example |
et al |
et alii |
and others |
i.e. |
id est |
in other words |
cf. |
confer |
参照せよ |
q.e.d. |
quod erat demonstrandum |
かく示された |
UECのウォシュレットの温度を変更する方法
- UECのトイレはほぼ全てがウォシュレットになっているが、たまに便座が熱すぎたり冷たすぎたりして残念な気持ちになることがある。
UECのトイレはほとんどTOTOですが、まれにINAXがあります。INAXのトイレでは以下の方法は使えません。
温度を変更したら、再度元に戻しましょう
- 「便座」と「温水」ボタンを同時に長押しする。10秒ぐらい押す。
- するとランプが点滅する。
- ランプが点滅したら、温度を変更できる。「便座」・「温水」ボタンを1度押すごとに温度がそれぞれ切り替わる。
- 良いあんばいになったら、もう一度ボタンを同時長押しする。
- ランプが点滅したら設定完了。
最大の素数
time関数がオーバーフローする時刻を求める
- I科基礎のレポートに出たので。
- time関数は32ビット符号付き整数なので、2^31-1が扱える最大。
- よってUNIX時間で2^31-1秒がいつなのかを調べれば良い。
- こういった問題はスクリプトに解かせるのが良い。
pythonの例
% python hoge.py Tue Jan 19 03:14:07 2038
rubyの例
1 puts(Time.at(2**31-1).utc
% ruby hoge.rb 2038-01-19 03:14:07 UTC
- 結論:スクリプト言語は楽