タグ

2015年3月29日のブックマーク (8件)

  • Rubyistのための型入門

    浜松Ruby会議01 http://regional.rubykaigi.org/hamamatsu01/ の発表資料です。 http://mzp.hatenablog.com/entry/2015/03/29/213909 もあわせてご覧ください。

    Rubyistのための型入門
    Jxck
    Jxck 2015/03/29
  • モナドの本当の力を引き出す・・・モナドによる同期/非同期プログラミングの抽象化 - xuwei-k's blog

    以下の2つの続き ScalaでFutureとEitherを組み合わせたときに綺麗に書く方法 FutureとEitherの話の続き(ApplicativeとMonadの違い) 上記の2つ(特に最初の方)を読んだことを前提で書くので、読んでない人は先にそちらを読みましょう。 なんだか少し関連する話(?)で盛り上がっていて、書かないといけない気がしてきたので 非同期プログラミングの難しさとScalaのFuture そのtogetterの議論について色々書きたいこと*1もありますが、それは置いておき、表題の「モナドによる同期/非同期プログラミングの抽象化」について書きます。というか、(非同期プログラミングの話より)便乗してモナドとモナドトランスフォーマーの便利さを話したいだけかもしれません(?) 前回2つは「Future使って非同期にしても、だいたい関数の体同じでいけるよ」ということを書きました

    モナドの本当の力を引き出す・・・モナドによる同期/非同期プログラミングの抽象化 - xuwei-k's blog
    Jxck
    Jxck 2015/03/29
  • Markdownテキストでシーケンス図とフローチャートを描く - Qiita diagram sequence

    つい先日、とあるシステムの処理の流れと一部処理のフローチャートを付けた見積り資料を書くことになり、ちょうど良い機会だったので、MarkdownでUML図表が描ける「StackEdit」を使って、オールMarkdownで資料を作成してみた。 いやぁ、打ち込んだテキストがリアルタイムに図表化されていく様は、とても新鮮で、そしてすごく面白かった。資料が出来上がった後の達成感というか、完成した図表を見た時の感動が結構はんぱない。技術系の資料作成でこんな良い体験ができたのは初めてかもしれんな…(笑) ──と、結構感動的な体験ができるMarkdownでのUML図表作成なんだが、せっかくなのでそれの書き方を含めてもう少し突っ込んだTIPSとしてまとめておこうかと思った次第。 Markdown+UML とは? とりあえず、「Markdown+UML」というのは私の造語だ。まぁ、正確に言うなら「UML di

    Markdownテキストでシーケンス図とフローチャートを描く - Qiita diagram sequence
    Jxck
    Jxck 2015/03/29
    seqdiag 系使ってたけど、ちょっと気にはなる。
  • 2015年3月に発生したGithubへのDoS攻撃についてまとめてみた - piyolog

    Githubが同社サービスに対してDoS攻撃が行われていることを発表しました。一連のDoS攻撃はGreatfire.orgに対して行われているものと考えられ、ここではGreatFire.orgに関係するDoS攻撃の情報をまとめます。 公式発表 GreatFire.org 2015年3月19日 We are under attack 2015年3月25日 (PDF) Using Baidu 百度 to steer millions of computers to launch denial of service attacks Github 公式Blog 2015年3月28日 Large Scale DDoS Attack on github.com · GitHub Github 公式Twitter The attack has ramped up again, and we're evo

    2015年3月に発生したGithubへのDoS攻撃についてまとめてみた - piyolog
    Jxck
    Jxck 2015/03/29
  • BabelとTraceurでES6末尾再帰最適化を試す - teppeis blog

    ちょっと前にBabelに末尾再帰最適化が入って話題になったけど、同じくTraceurにもv0.0.85で最適化が入ったので試してみた。 末尾再帰最適化って何? 厳密な話はそちらの筋に任せるとして、ざっくりしたストーリーはこんな感じ。 再帰って深くなるとstack overflowになっちゃう 再帰をシンプルなループ(スタックを使わないジャンプ)に変換できればstack overflowを避けられる 一般に末尾再帰であれば再帰をループに変換できる方法が知られている(これが末尾再帰最適化) 末尾再帰とは、関数の最後のステップだけで再帰呼び出しを行うこと 末尾再帰ではない再帰関数でも、CPS変換を使うことで末尾再帰関数に変換が可能 CPS変換とは、関数を結果の値を受け渡すスタイルから継続渡しスタイルに書き換えること つまり、普通の再帰関数 -> CPS変換で末尾再帰化 -> 末尾再帰最適化を適用

    BabelとTraceurでES6末尾再帰最適化を試す - teppeis blog
    Jxck
    Jxck 2015/03/29
    関係ないけど sandbox 用のアカウントは別であるのか。俺もメンテしないもの分ける用に別アカウント作ろうかなぁ。
  • ふわっと JVM のヒープ領域監視について考える - ようへいの日々精進XP

    ども、かっぱです。 はじめに Java アプリケーションを運用する上では避けて通れないであろうヒープ領域の監視についてフワッと考えてみた JVM には幾つか領域があるがヒープ領域に焦点を当てる 参考 http://www.whitemark.co.jp/tec/java/javaHeap.html http://www.whitemark.co.jp/tec/java/javagc.html http://d.hatena.ne.jp/ogin_s57/20120623/1340463194 http://d.hatena.ne.jp/ogin_s57/20120709/1341836704 https://docs.oracle.com/javase/jp/1.5.0/guide/management/agent.html http://chonaso.hatenablog.com/en

    ふわっと JVM のヒープ領域監視について考える - ようへいの日々精進XP
    Jxck
    Jxck 2015/03/29
  • 新入社員必見!プレゼン資料の作り方からプレゼン方法の基礎まで学べる良質SlideShare11選

    ビジネスシーンにおいてプレゼンをする機会は誰にでもあるのではないでしょうか。 プレゼンというと「商品を販売する行為」をイメージしがちですが、一口にプレゼンといってもお客様に提案をする時、自分の売り込みをしたい時以外にも、社内メンバーへの提案や上司を説得する際にもプレゼンは必須です。 つまり、プレゼン能力は全てのビジネスパーソンにとって無くてはならない能力なのです。そのための、プレゼン力をつけるためにはまず、基的なルールを学びましょう。 今回は、世界的に有名なファイル共有サービス「SlideShare(スライドシェア)」より、プレゼン資料の作り方から実際のプレゼン方法まで学べる資料を11個厳選してご紹介します。 資料作成時には実際のプレゼンを想定し、伝えたいポイントだけを記載する必要がありますが、書きたいことを整理出来ず情報を詰め込んでしまいがちです。 このスライドでは、聞き手に伝わるプレ

    新入社員必見!プレゼン資料の作り方からプレゼン方法の基礎まで学べる良質SlideShare11選
  • grunt-parallelize v1.1.0リリースおよび零細OSSの継続性について - teppeis blog

    2015/03/29 10:30 フォークについて末尾に追記 gruntタスクのファイルリストを分割して並列実行するgruntプラグイン、grunt-parallelizeを前に作った。 そこそこ使われてるっぽいのだけど、 ファイルリストが長大な場合にエラーになることがある ファイルリストにdestがあるタスクに対応していない という2点についてissueや問い合わせがよくあってどうしたもんかなと思いつつ放置していたところ、ちょうど良いプルリクをもらったので重い腰を上げて取り込みつつもろもろ修正してv1.1.0をリリースした。 さて、最近こんな記事を読んで、「プラグイン開発者として」あたりのところをまさに感じていた。 若気の至りで、おっさんも昔はよくGruntプラグインを作ったのです。実際に自分のプロジェクトでGruntを使い、必要だったので、プラグイン開発に対する情熱もあったわけですけど

    grunt-parallelize v1.1.0リリースおよび零細OSSの継続性について - teppeis blog
    Jxck
    Jxck 2015/03/29
    すごくわかる。