タグ

2014年8月21日のブックマーク (5件)

  • Dockerの将来

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Dockerの将来
    ziguzagu
    ziguzagu 2014/08/21
  • Google認証なリバースプロクシ&静的コンテンツ配信サーバー「gate」 - unknownplace.org

    Kibana や Grafana を使う時に、これらはjsのツールなので、 Erasticsearch や InfluxDB といったバックエンドサービスにjsからアクセスできるようにする必要がある。 そのためには、 普通にバックエンドサービスのportを開放 nginxとかでリバースプロクシ とかする必要があり、めんどくさい。 さらにセキュリティのことを考えると、2の方法のうえに、nginxでSSL+Basic認証なんかにする必要があってよりめんどくさい。 さらに、僕はBasic認証が嫌いだ。 昔は Firefox + 1Password で良い感じにBasic認証の入力が行えたが、いまはだめになってしまったし、 Basic認証だとアカウントの管理もめんどくさい。 なので、Google認証なhttpdでリバースプロクシもできる、gateというツールを作った。 https://github

    ziguzagu
    ziguzagu 2014/08/21
  • インフラの継続的デリバリー - naoyaのはてなダイアリー

    事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更

    インフラの継続的デリバリー - naoyaのはてなダイアリー
    ziguzagu
    ziguzagu 2014/08/21
  • 電子書籍に移行することで失われる読書体験の中身が少し判明

    By mobilyazilar KindleやKoboといった電子書籍リーダーやタブレット・スマートフォンの普及により、以前は紙ベースでしかなかった読書スタイルの多様化が進んでいます。従来の製された書物を支持する層からは「紙と画面は別物だ」と指摘する意見を聞くこともありますが、そんな読書方法の違いによる差異を調査した研究からは興味深い結果が浮き彫りになっています。 Reading Literature on Screen: A Price for Convenience? - NYTimes.com http://www.nytimes.com/2014/08/14/arts/reading-literature-on-screen-a-price-for-convenience.html?_r=0 研究を行ったのはノルウェー・スタヴァンゲル大学のAnne Mangen氏とフランス・エク

    電子書籍に移行することで失われる読書体験の中身が少し判明
    ziguzagu
    ziguzagu 2014/08/21
  • fork()は失敗するんだぜ、覚えときな

    fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか? マジで分かってるか? マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか? そうだよ。お前多分、"-1"(forkのエラー通知)をpidとして扱ってるんだろ。 さて、問題の始まりだ。

    ziguzagu
    ziguzagu 2014/08/21