Posted 1 day ago

そもそも目標管理制度は、それを書いている時間が有効に使えている気がしないので、嫌いです。四半期の間に役割や目標はほぼ確実に変わっているのに、経緯を細かく書いても上長は読まないだとろうなと思いながら、忙しい中でわざわざ時間をとって雛形のシートにまとめて、さらに面談しなくてはいけません。四半期という評価をまとめる期間と、ビジネスのサイクルが一致してないので、余計ストレスを増幅してるかと。事業全体の戦略に沿って自分のタスクとその優先順位はどうあるべきかと考える時間は、仕事は言われたことをやるのではなくて、自分でつくりだすという意味で大切。でも、書類を埋めるという作業感がしっくりこないのかと。

とはいえ、組織が大きくなると、給与査定と紐づいてるかぎり、なんらかの目標管理の仕組みは必要。

それなら、GitHub上で管理するとどうか。個人の戦略的目標の進捗記入と、その目標が変わればアップデートする(事業会計上の四半期という単位に縛られず、変更時点から30日後/90日後の姿を目標として明示するのがよいかな。)ことで、その度に上長やチームに通知ができる。さらに履歴も残るので、それで経緯を確認しながら必要なときに面談すればよい。こうすれば、会社の中に存在する週次の報告書や四半期にまとめて目標管理シートを書くという時間を削減できないかなと思ってます。

Posted 1 day ago
Posted 1 day ago
Posted 1 day ago

igi:

プロが教える「食べ放題」攻略法 | web R25

様々な条件を鑑みたうえで、東龍さんおススメのブッフェを教えてください。

「“高コスパ”という意味では、『柿安 三尺三寸箸』(池袋、二子玉川など)や『ビタースイーツ・ビュッフェ』(新宿)が挙げられます。スイーツをたっぷりと味わいたいなら、ウェスティンホテル東京の『レストラン ザ・テラス』(恵比寿)や横浜ベイホテル東急の『スマーハウス』(みなとみらい)がオススメですね」

他にも、肉やエスニック料理を楽しみたい時は、「バルバッコアグリル」(表参道)や「マンゴツリー東京」(東京)が最適だそうだ。  

Posted 1 day ago
しかし私の知る限りでも、「あるベンダーにIT部門が提案を依頼 → その提案をベースに調達部門がコンペを実施 → とんでもない最低料金を出したベンダーが受注 → プロジェクトが炎上」という“おバカプロセス”を何度も繰り返した超有名企業があった。
Posted 1 day ago

fencehopping:

Fogo De Chao knows exactly what the fuck they’re doing when it comes to commercials. Christ.

Posted 1 day ago

engadget:

Slimmer, lighter, juicier: Sony’s revamped PS Vita hits the US on May 6

PS4は米国他より日本が遅かったのにVITAは逆なんだよね。

Posted 1 day ago
日本の多くの会社は、時給800円でアルバイトする若者が仕事をサボることは叱るくせに、時給換算でその何倍もの人件費を支払われている人間が会議で不毛な時間を過ごすことに対しては思いのほか無頓着である。
Posted 1 day ago
「スティーブが亡くなった後、限界を超えるためのエンジニアの発言よりも、多くの中間管理職の発言力が強まり、保守的な決定に重点が置かれています」と話す元エンジニアリング部門副社長のマックス・ペーリー氏。「今やどのような重要なミーティングもプロジェクト管理や世界的需要管理によって決定されると聞いています」とペーリー氏は話しており、昔とは優先順位が変わってきていることを示唆しています。
Posted 2 days ago
注意して欲しいのは変数payloadはユーザから与えられたデータということだ。つまりだれでも勝手に設定できるため、正しい値が入っていない可能性がある。 この場合の正しさというのはリクエストデータの大きさを正しく反映しているかどうかということだ。 もしこのpayload変数(受け取ったデータの先頭から2byteの値)がデータの長さを正しく反映していない、特に実際のデータ長よりも 長い値がpayloadに設定されているとしたらどうだろう。レスポンスデータを作る以下のコードは正しく動作するだろうか。 memcpy(bp, pl, payload);
正しく動作しない。正確にいうと動作に特に影響はないが、余計なものを送ってしまう可能性がある。ここに脆弱性が生まれる。実際のplに入っているデータはpayloadに設定されている値よりも短いため、plから連続したメモリ領域をbpに コピーしてしまう。そして、このあふれた領域にSSL秘密鍵のデータが載っていたらどうだろうか。OpenSSLプロセスであれば秘密鍵のデータをプロセスメモリ上に乗せているのは 十分考えられることだ。 このコピーされてしまったSSL秘密鍵のデータはbpを経由してそのままクライアントの手にわたってしまうことになる。 もちろん、最近のコンピュータはプロセスあたりのヒープ領域が大きいため、ただちに秘密鍵の値をコピーしてしまうことにはならないが、やはり可能性はゼロではない。

Heart Bleedを読んだ - The first cry of Atom

攻撃側は今回のopensslのバグで意図した情報を抜き出せるのではないけど、何抜かれたかは全然わからないのでとっても危険。

(via daxanya1)

いやー、exploit code を手持ちのサーバに試してみたけど、例えば直近にアクセスのあった Basic 認証の ID / Password とかまるっと見えたよ。