タグ

naoyaに関するBigFatCatのブックマーク (29)

  • Chef Solo の Environments - naoyaのはてなダイアリー

    今年3月に入門Chef Soloを書いた時点では、Chef Solo は Environments の機能をサポートしてなかったため解説は省略しました。 その後、Chef はバージョン 11.6.0 (現在は 11.8.2) で Chef Solo での Environments をサポートし、入門Chef Solo で推薦している knife-solo も 10月末にリリースされた 0.4.0 から Environments をサポートしました。というわけで、現状 Chef と knife-solo が最新版であれば Environments を利用することができます。 たまたま今手をつけている仕事で Environments のことを調べたので備忘録的に記しておきます。 Environments とは Chef の Environments は、例えば development や pr

    Chef Solo の Environments - naoyaのはてなダイアリー
  • Infrastructure as Code - naoyaのはてなダイアリー

    今年の3月に 入門Chef Solo - Infrastructure as Code というを書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う

    Infrastructure as Code - naoyaのはてなダイアリー
  • 「書く」のは特別な道具 - naoyaのはてなダイアリー

    This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが

    「書く」のは特別な道具 - naoyaのはてなダイアリー
    BigFatCat
    BigFatCat 2013/11/09
    "ちなみに自分は会議の際も、自分がファシリテーター役になるようなときはモニタにエディタを映し出して発言を書いて整理しながらミーティングを進める。"
  • テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー

    一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき

    テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
  • DevOpsの今とこれから #init_devops

    フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

    DevOpsの今とこれから #init_devops
  • JavaScriptフロントエンド開発の昨今

    フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

    JavaScriptフロントエンド開発の昨今
  • require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー

    先日書いた自分用アプリケーションのひな形 http://d.hatena.ne.jp/naoya/20130503/1367581629 http://d.hatena.ne.jp/naoya/20130504/1367640512 これに、JavaScript のテスト環境も追加したい。 結論からいくと、フレームワークには mocha + expect、ランナーは testem を使うことにした。ついでにテストダブルライブラリとして Sinon.js も有効にした。 ちなみに今回の文脈は End to End のテストではなくてユニットテスト周りのおはなしです。 mocha + expect JavaScript のこの辺のテスト周りは今もいろいろなツールの整備が進んでいて、今回採用した以外にも Jasmin や QUnit そのほか色んな物がある。昨今の状況に関しては 先日の HTML

    require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー
  • Backbone.jsガイドブック - naoyaのはてなダイアリー

    Backbone.jsガイドブックposted with amazlet at 13.05.07高橋 侑久 ラトルズ 売り上げランキング: 2,459 Amazon.co.jpで詳細を見る Backbone.js ガイドブックを一通り読みました。言及するか少し迷ったけど、まだあまり話題になっていないようなので書いておこうと思います。 Backbone.js あるいはこれによく似たようなフレームワークは今後、Webアプリケーション開発でよく使う道具になっていくと思う。というか、すでになっているでしょう。 Backbone.js は「クライアントサイドMVCフレームワーク」と呼ぶと良くわからない。クライアントサイドMVCフレームワークが注目される以前から、ある程度以上の規模の JavaScript アプリケーションになるとちゃんとしてるものは構造化が行われていた。イベントを集約するオブジェクト

    Backbone.jsガイドブック - naoyaのはてなダイアリー
  • Vagrant - naoyaのはてなダイアリー

    先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2 なにこれすごい。 % vagra

    Vagrant - naoyaのはてなダイアリー
  • Kindle向けに『入門Chef Solo - Infrastructure as Code』を出版しました - naoyaのはてなダイアリー

    Chef のスタンドアロン版である Chef Solo の技術書Kindle 向け電子書籍として出版しました。 入門Chef Solo - Infrastructure as Codeposted with amazlet at 13.03.17伊藤直也 (2013-03-11) 売り上げランキング: 14 Amazon.co.jpで詳細を見る がんばりました。原稿\(^o^)/オワタ Chef Solo Chef はサーバー/インフラの状態管理フレームワークです。より単純化して言うならサーバー構築の自動化ツール。コードは Ruby で書きます。ウェブアプリケーションをホストするサーバーの管理にもちろん利用できますし、チームメンバーの開発環境を同じ状態に揃える、あるいは個人の開発環境の整備を自動化する、といったことにも利用できます。 書の内容のは、その Chef の入門書です。C

    Kindle向けに『入門Chef Solo - Infrastructure as Code』を出版しました - naoyaのはてなダイアリー
  • Gyazo + Amazon CloudFront で簡単☆高速スクリーンショット共有 - naoyaのはてなダイアリー

    確かに Dropbox にファイルを保存して public url だとちょっと遅い。自分は Gyazo で撮ったスクリーンショットを dropbox に放り込んで blog に貼る、というのを一時やってたけど GET が遅いので結局やめてしまった。 Gyazo x Dropboxで簡単スクリーンショット共有 - プログラミングノート ここにやり方がある。相当に便利なんですけどね。 さて、「遅いのがリージョンのせいなら速いリージョンにして更にCDNを挟めばいいじゃない」ということでちょこっと Quick Hack してみるとしましょう。Gyazo の画像保存先を Amazon S3 にして、S3 に保存された画像を CloudFront (AWS の CDN) で配信するように変更してみます。あらやだ便利・・・! でも従量課金 \(^o^)/ ちなみにわざわざ CloudFront を使わ

    Gyazo + Amazon CloudFront で簡単☆高速スクリーンショット共有 - naoyaのはてなダイアリー
  • LTSV FAQ - LTSV って何? どういうところが良いの? - naoyaのはてなダイアリー

    LTSV って何? Labeled Tab-Separated Values という、テキストのフォーマットの仕様です。CSV や TSV や JSON そのほかと同じ、テキストデータのフォーマット名。主にログ、特に httpd のアクセスログなどに適用すると便利です。 仕様は http://ltsv.org にまとまっています。随時更新中です。 LTSV は単なるログのフォーマットであって、それ以上でもそれ以下でもありません。 LTSV ってタブ区切りで値に名前を付けただけのもの? はい、そうです。 これが 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (

    LTSV FAQ - LTSV って何? どういうところが良いの? - naoyaのはてなダイアリー
  • LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー

    ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで・・・というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか・・・ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue

    LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
  • 開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決 - naoyaのはてなダイアリー

    開発メモその4です。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で、システム構成の変更時に EC2のスナップショットからインスタンスを複製して Elastic IP で切り替えているという話をしました。 ただ、この方法はそのままでは一点問題があります。スナップショットを取ったタイミングと現時点でシステム構成に差分があった場合にどうするか、です。例えば nginx の設定をほんの少しだけ書き換えたい、とかその都度スナップショットを取っていては流石に面倒。 その手のスナップショット時点からの差分を複製されたインスタンスに簡単に適用するために、基的なサーバー設定周りは chef-solo で管理してます。chef はサーバー構築自動化ツールで、chef-solo は chef のクライアント・サーバーを必要としないライト版、とでも

    開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決 - naoyaのはてなダイアリー
  • Webはインターネットになった - naoyaのはてなダイアリー

    先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回:HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回:HT

    Webはインターネットになった - naoyaのはてなダイアリー
  • 近頃の開発環境 : Mosh、z、tmux、Emacs、Perl について - naoyaのはてなダイアリー

    昨日は年始の挨拶ついでに ELPA について脈絡もなく突然書きましたが、引き続き近頃の開発環境についてもだらだらと書いてみよう。 Mosh mosh というと一部の人間はひげなんとかさんが開発しているモナー的なあれを思い浮かべるかもしれないがそうではなく、mobile shell のことである。 思い切り簡略化して言うと「快適なssh」。回線が不安定な所でもエコー遅延など全く気にせず使えるし、Mac をスリープさせて復帰させたときもリモートホストにそのまま繋がりっぱなしのように見せかけてくれたりする。 詳しくはこの辺を。 mosh: MITからモバイル時代のSSH代替品 - karasuyamatenguの日記 インストールはリモートとローカル両方に必要ですが、まあ大概パッケージがあると思います。EC2 の Amazon Linux でも yum レポジトリの EPEL を有効にすれば y

    近頃の開発環境 : Mosh、z、tmux、Emacs、Perl について - naoyaのはてなダイアリー
  • inetd の仕組みを見てみる - naoyaのはてなダイアリー

    inetd や xinetd (以下 inetd) はインターネットサービスをデーモン化するのに共通している処理を担い、ほとんどの時間をアイドル状態で過ごすその手のサービスに必要なリソースを節約する役割を果たします。 inetd のひとつ面白いところは、inetd でサービス化したいプログラムの標準入力/標準出力がクライアントソケットの入出力に接続されるところです。例えば daytime 相当のサービスを自分で作ろうと思った場合 #!/usr/local/bin/perl # daytime.pl use strict; use warnings; use DateTime; use IO::Handle; STDOUT->autoflush(1); STDOUT->printf( "%s\n", DateTime->now(time_zone => 'Asia/Tokyo') ); と標

    inetd の仕組みを見てみる - naoyaのはてなダイアリー
  • メモリ使用量の確認

    サーバのメモリが思った以上に消費していたのでサックリ調べてたのですが 各プロセスのメモリ使用状況の調べ方としては ps aux --sort=-rss | head -40とやるとRSSのサイズでソートしてくれるのでheadとかでみてやればメモリ使用量が多い順に参照可能。 ただたんにps auxしただけだと見るのがしんどい。 topでもshift+Mで同じ感じでみれるのでそれでも良い。 (cを入力してプロセスの詳細を表示するとなおよい) あとはCoWに乗ってるかを調べたが、 http://d.hatena.ne.jp/naoya/20080212/1202830671 naoyaさんが紹介されている方法そのまんまでよいでしょう。 sudoして実行すること。 Cowはアプリの質にもよるが基的にはライブラリが共有メモリに乗ってればいいから アプリの質をみつつsharedなパーセントを調整出

    BigFatCat
    BigFatCat 2010/11/09
    BSD系では-mオプションぽい。
  • PHPerのためのYAPC::Asia2010

    YAPC::Asia2010 の発表資料、動画が面白いので、まとめ。 YAPC=Yet Another Perl Conferenceは、その名のとおりPerlのイベントです。PHPで言うならPHPカンファレンスにあたるでしょうか。(違ったらごめんなさい) Perl のイベントということで特に気にしていなかったのですが、先日行われたYAPC::Asia2010の発表資料を見ると PHPer が見てもかなり面白いです。もちろんPerlならではの発表もあるのですが、言語を問わずWebシステム開発をするなら参考になる内容が多くあります。 Perl だから、という理由だけで避けるのはホントに勿体無いので是非見てみて下さい。 PHPerにオススメな発表 PHPユーザの自分が見て面白かった発表です。リンク下にある一言は自分が面白いと思った点で、要約では無いです。内容は各発表を見てみて下さい。 ソーシャ

  • エンジニアの不安と壁 - naoyaのはてなダイアリー

    このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ

    エンジニアの不安と壁 - naoyaのはてなダイアリー