タグ

2013年3月22日のブックマーク (5件)

  • Perl のハッシュ値の再計算メカニズムの脆弱性 - JPA 運営ブログ

    JVNでも公開されていますが、perl 5.8.2からperl 5.16系までのバージョンでハッシュ値の計算に対する脆弱性が報告されています。 perl 5.16系であれば perl 5.16.3、5.14系であれば perl 5.14.4 で修正がされていますので、アップグレードを推奨されています。 すでにEOLとなっているperl 5.8系、5.10系、5.12系ではgit レポジトリに存在するパッチを適用することでこの件に関しての修正を行う事ができます (perl 5.8 -> レポジトリ 対象コミット、 perl 5.10 -> レポジトリ 対象コミット、 perl 5.12 -> レポジトリ 対象コミット 各ベンダー提供のperlも自前でインストールしたperlもアップグレードが推奨されています。

    koba04
    koba04 2013/03/22
  • 迷いながらも勉強会に参加していくひとつのやり方。 - Hack like a rolling stone

    最近、勉強会やコミュニティの入口で迷子になっている方とお話しました。 その方曰く、勉強会やコミュニティに対してこんなイメージを持っているそうです。 技術力/知識がないので、自分が参加してもよいのか悩むことがある 基礎がわかってないと「そんなのもわかってないの?」と言われてしまいそう エキスパート(モヒカン)たちはなんでも知ってる どこまで勉強したらコミュニティに参加しても恥をかかないんだろうか 今の発表、よく分からなかったけど、周りの人達は理解してるんだろうな… 忙しくて勉強する時間がとれないと、どんどん置いていかれてしまう気がする あるタイミングで勉強会で何度かお会いした別の方も、表現は違えど似たようなことをおっしゃっていました。 おそらく、僕は勉強会によく出没して発表などもしているので、 彼らの言うエキスパート(モヒカン)に該当しているかと思う*1ので 1エントリー書いてみることにしま

    koba04
    koba04 2013/03/22
    わかる。参加するだけなら気楽に色々足を運んでみればいいと思う。
  • アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog

    鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか?受け入れたところでバッファが巨大になるだけではないのか?そして、そのバッファは見えないところでい尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。

    koba04
    koba04 2013/03/22
  • アジャイルがダメだと思う7つの理由 - arclamp

    1.全体スケジュールにコミットできない アジャイルはタイムボックス型(一定期間で棚卸しをして、それを繰り返す)のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ

    アジャイルがダメだと思う7つの理由 - arclamp
    koba04
    koba04 2013/03/22
  • クライアントサイドMVCには何が必須? - はこべにっき ♨

    最近何度かクライアントサイドMVCフレームワークであるところの、Backbone.jsを使ってコードをかいたりしていたので、その時に感じたことをまとめて Kyoto.js で話してみました。 発表資料 "何がMVCをつなげているのか" Backbone.jsではMVCの各層をつなげるために、Backbone.Eventsというオブジェクトが用意されています。Backbone.jsのModelとViewのインタラクションは、ベースになっているBackbone.EventsによるObserverパターンによって実現されています。実際にBackbone.jsでコードを書いてみると、便利な機能はいろいろあるもののBackbone.Eventsの存在がMVCを実現するのに重要であることがわかります。 そこつきつめると、Backbone.EventsのようなObserverパターンを簡単に実現できるよ

    クライアントサイドMVCには何が必須? - はこべにっき ♨