ワタミ叩きのネタでは済まない問題 - hamachanブログ(EU労働法政策雑記帳)
この記事自体は、いかにもワタミ叩きのネタとして報じている印象ですが・・・、 http://www.tokyo-np.co.jp/article/national/news/CK2012051702000093.html（労働条件 言うがまま 協定 店長指示でバイトが署名） あらかじめ時間外労働の上限時間が書き込まれた三六協定届に、店長の指示でアルバイトが署名する－。新入社員森美菜さんが過労自殺したワタミフードサービスでは、違法な手続きで、従業員に時間外労働させていた。会社から一方的に提示された労働条件を、受け入れるしかない従業員。労使対等とは名ばかりの実態が浮き彫りになった。 森さんが働いていた「和民京急久里浜駅前店」（神奈川県横須賀市）。この店の三六協定届には、労使協定を結ぶ労働者側の代表は、「挙手による選出」と印字されていた。しかし、男性アルバイトは「協定届を見たことはないし、挙手で代
退職理由は「転職先のモニターのほうが大きい」から？
今や、いいエンジニアを雇うのに環境や待遇が重要なのは言うまでもないことで、「希望するマシンが支給される」とか「椅子はすべてアーロンチェア」といったフレーズは魅力的です。しかし、そんな華やかなフレーズの裏側に見え隠れする「社内のカルチャー」という本質を理解しないと、本当に素晴らしいエンジニアを惹き寄せることは難しいもの。 NingやVMware、Akamaiといった企業で働いた経験のあるJohn Josef “Sef” Kloningerさんは、Why Quit? Because They Have Bigger Monitorsというブログ記事で、自身の経験を以下のように紹介しています。 退職理由は「転職先のモニターのほうが大きい」から？ 以前の職場での話。 私はエンジニアリングマネージャーで、人材確保に関して問題を抱えていた。チームのエンジニアが会社を辞めて、もっと小さい今風の会社に移ろ
はてブとツイッターのコメントには明らかに質の違いが出るよ - 情報の海の漂流者
はてブは劣悪・Twitterは優良という勘違い はてブとtwitterのコメントには明らかに質の違いがでる、というのが僕の持論だ。 Twitterではコメントする前に「その記事について各ユーザーがどのような評価をしているのか」を知ることが困難である。 非公式RTまで含めてもせいぜい数名の評価を元に判断するのが通常。 答え合わせをせずに自分の意見を書く場合が多いし、そうでない場合も特定の人気ユーザーの意見に引きずられやすい傾向がある。 テストで言うならば独力で問題を解いている状態、もしくは隣同士で答案を見せ合って回答しているようなもの。 はてなブックマークではコメントをする前に「その記事について各ユーザーがどう評価しているか」を見ることができる。 はてなブックマークのコメントは一覧性がある その為、他の人がどんなことを言っているかを確認した後にコメントすることができる。 誰か一人が記事の内容
【解説】ワタミが３６協定の不正手続き！……でも、ワタミだけじゃない - ＮＰＯ法人ＰＯＳＳＥ（ポッセ） blog
◆ワタミが３６協定で不正な手続き 東京新聞の今朝の報道は、非常に良いものだったと思います。過労死を出したワタミの店舗で、３６協定の不正な手続きが行われていたというものです。まずは記事をご覧ください。 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 残業で不正手続き ワタミ過労死 労使協定形だけ 2012年5月17日 毎日東京（2012.5.28 修正） http://www.tokyo-np.co.jp/article/national/news/CK2012051702000216.html 居酒屋チェーンを展開するワタミフードサービス（東京）に入社二カ月後に自殺した森美菜さん＝当時（２６）＝が、長時間労働などを理由に過労死と認定された問題で、同社が労働基準法で定められた労使間の手続きを踏まず、従業員に時間外労働をさせていたことが、会社側への取材で分かった。手続きが形骸化すれば
Rails でよくある 5 つの間違い - 杉風呂2.0 - A Lifelog -
以下の文章は、Mike Perham 氏のブログ記事を翻訳したものです。原文は2012年5月5日に公開されました。 Five Common Rails Mistakes http://www.mikeperham.com/2012/05/05/five-common-rails-mistakes/ Railsをそれなりに仕事で使ってきて多くの Rails アプリを見てきて、悪い Ruby コードを読み書きした。この記事では、だいたいすべての Rails のコードベースで見られる共通の間違いを5つ挙げる。 1. スキーマの仕様がないマイグレーション データモデルはアプリケーションのコアだ。スキーマに制約がないと、データはコードベースに存在するバグにより徐々に蝕まれていき、フィールドに値が入っているか信頼できなくなる。ここに Contact スキーマがあるとしよう。 create_table
Java プロジェクトに Spock を導入するための３ステップ - bluepapa32’s Java Blog
Java プロジェクトでユニットテストにお困りなら Spock を導入することをオススメします。 もし、Eclipse を使っているのであれば、たった３ステップで 既存の Java プロジェクトに導入できます。 「上の承認がないと導入できないし…」 とか 「ビルドスクリプト直さないとダメだし…」 とか いろいろと考えるよりもまずは導入してみましょう。その効果をみてから考えても遅くはないです。 では、早速 Java プロジェクトに Spock を導入してみましょう。 ステップ１. Groovy-Eclipse プラグインをインストールしよう まず、最初に Groovy-Eclipse プラグインをインストールしましょう。 Groovy-Eclipse プラグインは Eclipse Marketplace から簡単にインストールできます。 ヘルプの Eclipse Marketplace を開
Eclipse で複数の Specification を一括実行する - bluepapa32’s Java Blog
Spock を使い続けていくと、当然ですが Specification ファイルはどんどん増えていきます。 実は Spock には Junit のテストスイートのような機能はありません。 つまり、Spock 自身には 複数の Specification を一括で実行する機能はないのです。 でもそんな時に役に立つのが Eclipse に用意されている 複数のテストクラスを一括で実行する機能です。 これは もともと JUnit の為に用意された機能ですが、もちろん Spock でも利用できます。 やり方は簡単です。 通常 Specification を実行する場合 実行したい Specification ファイルで右クリックして [Run As] --> [JUnit Test] を選択しますよね。 それと同じことを パッケージやソースフォルダでやれば、そのパッケージもしくはソースフォルダ配下
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
G*におけるソフトウェアテスト・シーズンIII