タグ

2014年9月26日のブックマーク (6件)

  • ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば

    条件1. /bin/shの実体がbashのディストリビューション RHEL CentOS Scientific Linux Fedora Amazon Linux openSUSE Arch Linux (自ら設定した場合: Debian, Ubuntu) 条件2. 動作環境 CGI (レンタルサーバでありがちなCGIモードのPHP等も含む) Passenger(Ruby) 条件3. プログラム内容 Passengerは全死亡 *1 systemや `command`、 '| /usr/lib/sendmail' などで外部コマンド実行 *2 PHPのmailやmb_send_mail、その他フレームワーク等を介したメール送信 *3 以下は条件1が不要 明示的にbashを呼ぶ 先頭で #!/bin/bash や #!/usr/bin/env bash しているプログラムを実行 (rbenv

    ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば
    takc923
    takc923 2014/09/26
  • モナドの六つの系統[Functor x Functor] - モナドとわたしとコモナド

    モナドは「アクション」を表す抽象的な構造である。モナドは、Haskellにさまざまな概念に対する記述能力をもたらす。 モナドの基礎 return :: a -> m a: 純粋な値をモナドで包む。 m >>= f :: m a -> (a -> m b) -> m b: モナドmに包まれた値をfに渡し、その結果として現れたモナドを結合する。 固有アクション: それぞれのモナドに固有の方法でモナドを生み出す。 実行: モナドに包まれた値を、より根源的な形に還元する。 モナド則 モナドに以下の三つの制約を課すことによって、最低限度の記述能力を保証している。 return a >>= k == k a m >>= return == m m >>= (\x -> k x >>= h) == (m >>= k) >>= h より強い制約は、より強い力を生み出す。 モナドの分類 モナドは、以下の6つ

    モナドの六つの系統[Functor x Functor] - モナドとわたしとコモナド
    takc923
    takc923 2014/09/26
    FUNCTORxFUNCTOR
  • [HUNTER×HUNTER]休載長期化へ 作者の容態回復せず | マイナビニュース

    HUNTER×HUNTER」32巻のカバー 週刊少年ジャンプ(集英社)の人気マンガ「HUNTER×HUNTER(ハンター×ハンター)」の休載期間が長期化することが22日、分かった。作者の冨樫義博さんの腰痛が思わしくないためで、22日発売の同誌43号で「冨樫義博先生の容態が想定以上に思わしくなく、治療に専念すべく、しばらくの間お休みさせていただきます」と発表された。再開については「なるべく早い再開を目指し、治療と準備を進めております」と説明しており、再開時期は今後、同誌で発表される。  冨樫さんはこれまで数回の休載を挟みながら連載していたが、「蟻編」に続く「選挙編」を終え、新しいエピソードに突入したばかりの2012年3月を最後に連載を休止。6月2日発売の同誌27号で約2年3カ月ぶりに連載を再開したが、32号(7月7日発売)、36号(8月4日発売)も休載し、39号(8月25日発売)では、39

    [HUNTER×HUNTER]休載長期化へ 作者の容態回復せず | マイナビニュース
    takc923
    takc923 2014/09/26
  • [Ruby] メタプログラミングの入り口、オープンクラスを理解する - Qiita

    概要 メタプログラミングRuby勉強録。 今回のトピックはメタプログラミングの代名詞の一つ、オープンクラスです。 オープンクラスとは 既存するクラスを好きな場所で再オープンし、 メソッド修正・追加など任意の変更を加えられる機能のこと。 例えば 以下のような文字列操作メソッドがあったとします。 def love_ruby(str) str + ' I love Ruby!' end love_ruby('My name is kidachi.') => "My name is kidachi. I love Ruby!"

    [Ruby] メタプログラミングの入り口、オープンクラスを理解する - Qiita
    takc923
    takc923 2014/09/26
  • インターフェイス分離の原則(ISP) - Strategic Choice

    インターフェイス分離の原則(ISP:the Interface Segregation Principle) クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。どういうこと?クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っているわけではない。すべてのインターフェイスを1つのクラスに押し込めてしまうことはやめ、関連性持ったインターフェイスはグループ化して、抽象基クラスとして分けて利用すべき。なんで?「太った」(多機能な)インターフェイスがある。 あるクライアントはそのインターフェイスのすべてのメソッドを利用するわけではない。 クライアントが、そのような利用しないメソッドを含むインターフェイスに依存すると、クライアントはその自分に関係のないメソッドの変更の影響をうけていしまう。 他のクライアントがクラスに強いる変更によって、それ

    takc923
    takc923 2014/09/26
  • 依存関係逆転の原則(DIP) - Strategic Choice

    依存関係逆転の原則(DIP:the Dependency Inversion Principle)上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。どういうこと?手続き型は「方針」が実装の「詳細」に依存する構造になってしまう。 方針が詳細の変更に影響されてしまう好ましくない構造。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転できる。 なんで?アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(=言うなれば「偉い」ヒト)は上位。 上位が下位に依存してしまうと、上位が、下位の影響を受けてしまう。手続き型でよく見られた悪い依存関係。 筋的にはアプリケーションの存在理由である上位が下位に対して影響力を持つ

    takc923
    takc923 2014/09/26