カテゴリ別 2003年 | 2004年 | 2005年 | 2006年 | 2007年 | 2008年
知り合いサイト: よんだもの / 暴想 / Linuxでやる夫 / 新宿Vipper / 僕だけが幸せになればいいのに。
マクドナルド化する労働というサブタイトルは意味不明ながら、インパクトは十分ですね。
外食産業やコンビニでは、実質は平社員やアルバイトと同じ仕事内容・権限しかないにも関わらず、店長を管理職として扱って残業代を払わずに長時間労働させることが横行しているのだそうです。この本では、マクドナルド、すかいらーく、セブンイレブン、コナカ、CFJ のケースを取り上げ、偽装管理職の実態と労働者側の自衛の動きについてレポートしています。
マクドナルドに関しては 1/28 に マクドナルド裁判は原告店長の全面勝訴というニュースが記憶に新しいですが、まさにこの原告の方が訴訟するに至ったのかが描かれています。
話の流れはどれも、サービス残業と長時間労働の常習化を含めた労働環境の悪化→労組を結成→経営陣は偽装管理職を認めず→訴訟、という感じです。
各ケースに共通していえることは、企業側は管理職とは名ばかりで法遵守していないと承知していながらコストカットのために偽装管理職を置いていること、従業員を単なる労働力としかみなしておらず労働環境の改善のために結成された労組を蛇蝎のように忌み嫌うこと、でしょうか。
P40-41 のマクドナルド研究の第一人者（と本文にある）ロイル教授の言葉のエピソードが印象的でした（この教授がどのくらい権威でどのくらいちゃんとした研究をしている人なのかはわかりませんが。とりあえず Industrial Relations Journal に論文を発表しているようです）。
「世界中のマクドナルドで労働運動がつぶされてきた。そもそも労働組合をつくらせないというのが、米本社の方針なのです。（中略）一時はあまりの待遇の悪さから労組設立の動きが盛り上がったこともあった。投票をおこなえば確実に労組が承認されるに違いないといった状況になったとき、会社側はなにをしたか。会社の息のかかった新入社員を大量に採用したのです。新人は採用時に”労組に反対する”と誓約させられている。つまり投票しても労組賛成派が負けてしまうくらいに、新人を雇用というかたちで動員したわけです。マクドナルドとは、そこまでやる企業なのです。」
過去の労組の是非はともかく、会社という組織に対して労働者が権利を勝ち取るには、会社内という狭い世界のルール下ではなく外の社会の法のルール下で、個々ばらばらではなく組織で対抗するしかないのではと思います。
肩書だけの管理職―マクドナルド化する労働 (シリーズ労働破壊 3)(安田 浩一/斎藤 貴男)
最近 SF マガジンで短編をいくつか読んで気になったので単行本を読みました。
悪夢のような手触りの話でした。語り手の「僕」は状況に巻き込まれるままあるいは人の思惑のまま悲惨な目に遭います。突発的に逆上する以外には主体的に行動することがほとんどありません。もがくでもなく諦めているでもなく、ほとんど内面を見せずにただただ語る彼はむしろ淡々としているようにさえ見えます。
夢の中では因果の関係は崩れ、自分がどう行動しようとそれに関係なく夢の物語が進んでいきます（いつも脈絡のある夢を見る人もいるのかもしれませんが）。それが醒めてほしい悪夢であるときほど特に、カメラ越しかのように受動的に見続けるしかなかったりします。この本はそんな夢に似ています。
異形の生物や登場人物以外の繋がりを持たない断片的なエピソード、妙に描写が細かい部分があるかと思えば「僕」が知りたいと思う事実が曖昧模糊として知れないといった、アンバランスさが夢のような感じに拍車をかけます。
決して読後感のいいタイプの小説ではないのですが、目覚めた後に何を見ていたのか気になる夢のように、もやもやとした何かが残る一冊でした。
なお、本人のブログ 平山瑞穂の白いシミ通信: 在庫一掃セール によると、絶版になってしまうそうです。もったいないですねえ。
極北の恐怖という副題がありますけどホラー小説ではないです。史実に基づいたフィクションという点では諜報指揮官ヘミングウェイと同様ですね。どちらも史実に基づきつつ大胆に想像力を膨らませています（筆者によるフィクションだろうと思った部分が史実だったりしておもしろいわけですが）。
ハヤカワのサイトからあらすじを引用します。
大西洋から北まわりで太平洋に抜ける北西航路。その最後の部分を発見すべく、1845年５月、探検隊長のサー・ジョン・フランクリン率いる二隻の英国艦〈エレバス〉と〈テラー〉は出航した。だが、当初は順調だったものの、翌年９月には北米大陸の北で完全に氷に閉ざされ、身動きがとれなくなってしまう。想像を絶する寒さの中、生き延びる道を探るフランクリンらの前にやがて巨大な白い怪物が現われ、激烈な闘いが始まる。
ザ・テラー ―極北の恐怖― 上:ハヤカワ・オンライン
寒さや飢えの中の壮絶なサバイバルが上下巻1000ページに渡ってこれでもかと続くわけですが、終盤はエスキモーの神話が織り交ぜられ、エデンの炎や愛死の「歯のある女と寝た話」を思い出させます。
視点人物が複数入れ替わりながら集団のサバイバルが語られてきたので終盤の展開がどうも唐突でしたが、全滅という結末が史実により決まっていながらも陰惨な終わり方ではなかったのは良かったです。
史実については、ジョン・フランクリン - Wikipedia が参考になります。
ザ・テラー―極北の恐怖 (上) (ハヤカワ文庫 NV (1156))(嶋田 洋一/ダン・シモンズ)
ザ・テラー―極北の恐怖 (下) (ハヤカワ文庫 NV (1157))(ダン・シモンズ)
Windows 版 Freeciv を gentoo でクロスコンパイル の続きです。GTK+ とその依存ライブラリ一式をインストールした後に、client=gtk でクロスコンパイルしましたが、win32 同様にバイナリを実行してもうんともすんとも言わずに終了しました。残念。これは深追いせずに放置することにします。
Firefox3 beta4 がリリースされました。早速インストールしてみました。beta3 に比べて動作が多少軽くなっています。
リリースノートによると Javascript のパフォーマンスが劇的に改善されたとのことなので、SunSpider で確かめてみました。
トータルタイムだけ抜き出すと以下の通りです。
3 倍速くなってますね……
実アプリではそこまで差が出ないとは思いますが、gmail など体感的にも実際レスポンスが良くなっています。何をどう実装を変えるといきなり こうも速くなるんでしょうねえ。
メモ。
cookie もダウンロード履歴も sqlite ですし、Firefox3 ではデータ保存のバックエンドはほとんど sqlite になるようですね。
Firefox 2 から Firefox 3 にアップグレードする際に、Firefox 2 の bookmarks.html が places.sqlite に自動的にインポートされるようです。具体的には、places.sqlite が存在しないと起動時にプロファイルディレクトリ内の bookmarks.html を読んでくれる模様(beta4 では)。places.sqlite があると bookmarks.html はもう更新されません。
Firefox 終了時に bookmarks.postplaces.html というファイルが作られますが、これが何に使われるのかは不明です。ブックマークをホームページにしている人など、旧形式のファイルもほしい人向けですかね。
あと、設定の browser.bookmarks.overwrite を true にすると、bookmarks.postplaces.html を作らずに bookmarks.html を更新するようです（元の bookmarks.html は bookmarks.preplaces.html としてバックアップされます）。まあ、デフォルトの false のままが無難ですね。
調べたのでまとめておきます。なお個人向け新築マンションの場合です。事業者や一戸建ての場合はまた別。
建物や家財に対する損害を補償する保険です。補償対象を建物だけにするか家財も含めるか、損害の原因をどこまでカバーするかで保険料が違ってきます。大抵の場合、ローンの期間と同じ期間だけ建物への火災保険に入ることが住宅ローンを借りる条件の一つです。
以下の 5 つから決まります。
現在と同じ建物を再取得するのにかかる費用です。評価方法に時価額と新価額の二種類がありますが、新価額（再調達価額）が基本です。購入金額を元に見積もります。本当に必要な額よりも多くても少なくても損です。マンションの場合は専有部分の建築にかかった金額は販売会社に聞かないとわからないですね。新築マンションならたぶん保険の説明会があるので、適切な金額を見積もってもらえるかも知れません。
例）新価額（再調達価額）で専有部分のみ対象とした場合。
5,000 万で買ったマンションの土地代が 2,500 万、共有部分の建築費が 1,500 万とすると専有部分の建築費は1,000万。よって補償金額は 1,000万です。
専有建築費 = 取得価格 - 土地代 - 共有建築費
1,000 = 5,000 - 2,500 - 1,500
火災保険といっても、火災以外の原因による損害もカバーできます。火災と風災の範囲を住宅火災保険、水害や落下物などの災害や人災による被害も含むものを住宅総合保険と呼びます。さらにピッキング被害によるドアロック交換や罹災時の仮住まいの費用の補償などが特約としてあります。
つまり、何が原因で損害が発生したかによって補償されるか否かが変わります。もちろん補償範囲が広いほど保険料は高くなります。
補償の対象には各社差はほとんどありません。つまり、A 社は盗難も補償対象にできるけど、B 社はできない、ということはまずないです。組み合わせがどのくらい自由にできるかという点で違いがでてきます。
必要だと思うものだけ補償範囲にすることが重要です。例えば洪水の危険性のない地域やマンションの非低層階なら水害は省けます。大抵の損保会社には水害を除くことで保険料を抑えるプランがあります。また、盗難や個人賠償責任などはクレジットカードや傷害保険などですでに補償されている可能性があります。
住宅総合保険の範囲については水害を除くなどいくつかのパターンしか選べない損保会社が多いです。中にはより細かく補償範囲を決められる保険会社もあります。
つまり最大で以下の4種類の保険を契約することになります。
建物の設備や契約の仕方によって割引があります。どんな割引があるかは会社によって多少違ってきます。例を挙げます。
一回の契約での期間です。少なくともローンが終わるまで何度も契約し続けるわけです。
90 歳でしたし後世に残る著作や思索がありますので大往生といえると思いますが、やはりショックです。一度スリランカに詣でたいですねえ。
結局なぜ売れるかはよく分からなかったものの、歴史的経緯については把握できました。恋愛資本主義の観点からの解題については評価保留。
ケータイ小説を読んでいる人の 0.1% でも、非ケータイ小説も読んでくれるようになればいいなと本読みとしては思いますが、「小説」と名称についていて同じく文字をベースとしているだけで、まったくの別物なのかもしれませんね。
なぜケータイ小説は売れるのか (ソフトバンク新書 63)(本田 透)
これは力作。考古学的な手法で、アイヌ文化が形成されるまでの経緯、アイヌの民がどのような文化と価値観を持ち、どのように周辺の民族（和人やオホーツク人など）と関係を持っていたかを詳らかにしています。
本書を読む前は、文字を持たず鮭を獲って暮らす狩猟採取民で、明治政府の殖民政策によって文化や土地を奪われたというくらいの認識しかありませんでした。長きに渡って文化と歴史を積み重ねてきたのですから実際はそんなに単純なはずもないわけです。交易民としての側面や宝を権威・権力の源とした文化など、この本を読んで初めて知りました。
また、政治的なバイアスなどもなく、ただただ考古学的知見を丁寧にまとめていますので内容に信頼がおけます。
アイヌの歴史―海と宝のノマド (講談社選書メチエ 401)(瀬川 拓郎)
タイトルのママです。いま restful_authentication で認証を実現した Rails アプリを作っています。
before_filter :login_required して認証下にしたコントローラ/アクションへアクセスすると、 AuthenticatedSystem#access_denied を通り、その中で呼ばれている AuthenticatedSystem#store_location で元の URL が記録され、redirect_back_or_default で認証下ページへリダイレクトされて戻ることができます。
一方、認証下ではないページ（アクション）の場合、そこからログインさせるには link_to 'login', login_path などといったログインページへの直接のリンクを書かざるを得ません。
ユーザがログインページへのリンクを踏んで遷移した場合、access_denied は通りませんので、元ページの URL は記録されず、redirect_back_or_default では戻ることができません。
非認証下ページからログインページに移動してログイン後に自動的に元のページに戻すにはどうすればよいのか、いくつか手段は思いつきましたが……あまりぱっとしません。何かいい方法はないものでしょうか。
restful_authentication で非認証ページからログインページに遷移してログイン後に redirect_back_or_default で戻るにはどうすればいいのでしょうの件続き。
deli.cio.us と同僚からリファラ使えばいいんじゃないとサジェストを受けましたので、そうしてみました。
class SessionsController < ApplicationController
def new
if logged_in?
redirect_back_or_default('/welcome')
else
begin
if request.referer and URI.parse(request.referer).host == request.server_name and
URI.parse(request.referer).request_uri != login_path
session[:return_to] = request.referer
end
rescue
end
end
end
end条件文がとっ散らかってますので書きなおすとして、以下をチェックしています。
redirect_back_or_default は session[:return_to] を参照して redirect back するので、それに request.referer (= HTTP_REFERER) をセットして終了。
しかし。一応機能としては動いていますが、integration test 時には SERVER_NAME がセットされないのでテストができないという問題が発生しています。
後で整理して公開します。
更新フォームに以下が追加されます。
こんな画面です。
@nifty 投票プラグインを公開します(nifty_vote_plugin.tar.gz)。機能は単純で、
だけです。
@nifty 会員登録が非常に面倒ですね。@nifty 投票が OpenID で使えると気軽なのですが。
tDiary のトップディレクトリ（index.rb tdiary.rb があるところ）で nifty_vote_plugin.tar.gz を展開してください。
他のプラグインと同じです。インストールに成功していれば、tDiary の [設定]-[基本]-[プラグインの選択] で新着プラグインとして表示されますので、チェックを入れて OK ボタンを押してください。
有効化すると [設定]-[その他]-[@nifty 投票] という項目が現れます。
設定項目は以下の通りです。
@nifty投票の管理画面に行かなくても、tDiary 上で投票が作成できます。作る手順は以下の通りです。
注意点としては、ボタンを押すとフォームに post されますので画面遷移が発生します。日記が書きかけですと消えてしまいます。文章を書く前に投票を作ることをオススメします。
最近作成した投票 4 つが更新フォーム下に並びます。「本文に追加」ボタンを押すと、本文に @nifty 投票表示タグが挿入されます。
プラグインをインストールしていると利用できるタグです。
<%= nifty_vote (user_id, vote_id) %>
例) <%=nifty_vote 31, 10728%>
@nifty 投票を表示するための script タグに変換されます。
最近のコメント：
RSS
This work is licensed under a
Creative Commons License
(note: text only. w/o web design, citations, (re)distributed softwares).
