タグ

2015年7月23日のブックマーク (9件)

  • Goはオブジェクト指向言語だろうか? | POSTD

    “オブジェクト指向”の意味を当に理解するには、この概念の始まりを振り返ることが必要です。最初のオブジェクト指向言語はSimulaという言語で、1960年代に登場しました。オブジェクト、クラス、継承とサブクラス、仮想メソッド、コルーチンやその他多くの概念を導入した言語です。おそらく最も重要なのは、データとロジックが完全に独立したものであるとする、当時では全く新しい考え方をもたらしたことでしょう。 Simula自体には馴染みがない方も多いかもしれませんが、Simulaからインスピレーションを得たとされるJavaC++、C#、Smalltalkといった言語は皆さんよくご存知でしょう。さらにそこからインスピレーションを得たものとしてObjective-CやPythonRubyJavaScriptScalaPHPPerlなど様々な言語があり、Simulaは現在使用されているポピュラーな

    Goはオブジェクト指向言語だろうか? | POSTD
    fjwr38
    fjwr38 2015/07/23
  • javascript - 関数名の取得とtypeof()の再々発明 : 404 Blog Not Found

    2011年12月07日03:30 カテゴリLightweight Languages javascript - 関数名の取得とtypeof()の再々発明 な、なんだってー!? はてなブックマーク - kamisetoのブックマーク constructor.nameを見ればいいんじゃなの?違うのかな? そんなおいしいプロパティなんて、あったっけ? MDNの中で逢った、ような… constructor.name?そんなのJavaScript: The Good Partsどころかサイでも見たことねーぞ。でもconsoleつついたら確かに使える… 見つけました。 Function - MDN name Non-standard The name of the function. Non-standard, Non-standard, Non-standard、だと!? 実際いろいろ嗅ぎ回ってみ

    javascript - 関数名の取得とtypeof()の再々発明 : 404 Blog Not Found
    fjwr38
    fjwr38 2015/07/23
  • Rails5.0.0alphaインストール手順 - Qiita

    Help us understand the problem. What is going on with this article?

    Rails5.0.0alphaインストール手順 - Qiita
    fjwr38
    fjwr38 2015/07/23
  • Get the name of an object's type

    Is there a JavaScript equivalent of Java's class.getName()? No. ES2015 Update: the name of class Foo {} is Foo.name. The name of thing's class, regardless of thing's type, is thing.constructor.name. Builtin constructors in an ES2015 environment have the correct name property; for instance (2).constructor.name is "Number". But here are various hacks that all fall down in one way or another: Here is

    Get the name of an object's type
    fjwr38
    fjwr38 2015/07/23
  • Fixing the JavaScript typeof operator

    What’s wrong with typeof? The most glaring issue is that typeof null returns “object”. It’s simply a mistake. There’s talk of fixing it in the next version of the ECMAScript specification, although this would undoubtedly introduce backwards compatibility issues. var a; typeof a; //"undefined" typeof b; //"undefined" alert(a); //undefined alert(b); //ReferenceError Other than that, typeof is just n

    Fixing the JavaScript typeof operator
    fjwr38
    fjwr38 2015/07/23
  • モンキーパッチ - Wikipedia

    モンキーパッチ(Monkey patch)は、システムソフトウェアを補完するために、プログラムをその時その場の実行範囲内で拡張または修正するというテクニックである。モンキーパッチの影響はその時その場のプロセス(プログラムの実行インスタンス)だけに限定されて、プログラム体には及ばない。 モンキーパッチは動的プログラミング分野の用語であり、その定義はRubyPythonなどの各言語コミュニティに依存している[1][2]。サードパーティ製のランタイムシステム、ソフトウェアフレームワーク、仮想マシン上で発生しがちな、好ましくない動作の違いや各種バグに対してパッチ当てすることを目的にしての、プロセス上に展開されたクラスコードやモジュールコードの動的な修正作業、という点は共通している。 語源[編集] 当初はモンキーパッチは、ルールを無視して実行時にこっそりとコードを変更することから、ゲリラパッチと

    fjwr38
    fjwr38 2015/07/23
  • SIOS ビッグデータ技術ブログ: Postfixのログをfluentdを使ってTreasureDataに送る

    こんにちは、SSTDの髙橋です。 前回の更新から日が空いてしまいましたが、引き続き継続して情報発信をしていきたいと思います。 さて、社内メールにGmailなどのクラウドサービスを使うことは一般的になってきましたが、それでも社内メールサーバと連携することは一般的です。 そうした中で、メールサーバに障害が発生した際に、SSHしてメールサーバのログを必死に読み解いていくはなかなか面倒です。 そこで今回は、Postfixのログをfluentdを使ってTreasureDataに送ってみたいと思います(td-agentをご利用の方はfluentdの箇所をtd-agentと読み替えて御試し下さい)。 実行環境 Postfixやfluentdの設定は既に設定済みであるとします。 Mac OS 10.9.4Postfix 2.9.4smtpにはgmailを設定済fluentd 0.10.52 fluent-

    SIOS ビッグデータ技術ブログ: Postfixのログをfluentdを使ってTreasureDataに送る
    fjwr38
    fjwr38 2015/07/23
  • Fluentd+BigQuery+Elasticsearch+Kibanaで迷惑メールを解析 - yanoの日記

    僕のメールアドレスには、去年辺りから、どういうわけか毎日ほぼ決まった時間帯に、決まったフォーマットの subject をもつ迷惑メールが一日平均 5 通くらい届きます。 普通であれば削除するのですが、「ほぼ決まった時間帯」「決まったフォーマットの subject を持つ」「複数通送られてくる」という特異性からか、無意識に削除せず別のフォルダに切り分けていました。 数えてみると 1500 通くらいあったので、大して Big でもないしこれ以上 Big になって欲しくもないのですが、BigQuery に流し込んで解析してみたいと思います。 Fluentd(td-agent) を使うので、ついでに Elasticsearch と Kibana も使って可視化してしまいましょう。 入力プラグインさえ作ってしまえば、後は Fluentd の出力プラグインが Elasticsearch と BigQu

    Fluentd+BigQuery+Elasticsearch+Kibanaで迷惑メールを解析 - yanoの日記
    fjwr38
    fjwr38 2015/07/23
  • 西伊豆の感電事故の状況が多少分かったのでブコメに突っ込んでみる

    http://anond.hatelabo.jp/20150720190643の続編。 電気屋的にはNHKニュース、http://www3.nhk.or.jp/news/html/20150722/k10010162021000.htmlでほぼ完結で特段疑問は残らないんだけど、ブコメ http://b.hatena.ne.jp/entry/www3.nhk.or.jp/news/html/20150722/k10010162021000.htmlを見ると結構勘違いしている人が多いようなので多少フォローしてみる。 おさらい・なんで人が死んだの?電気さくではなかったからです。 法令上定義されている電気さくではありませんでした。今回の事故の原因となったブツは「交流を流しっぱなしにしてある裸電線」です。 前回書いた平成21年の淡路島で起きた死亡事故も電気さくの事故でなく「100Vの電気が剥き身で流

    西伊豆の感電事故の状況が多少分かったのでブコメに突っ込んでみる
    fjwr38
    fjwr38 2015/07/23