Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

ブックマーク / naoya-2.hatenadiary.org (12)

  • Cask - naoyaのはてなダイアリー

    昨年 ELPA で elisp を管理 - naoyaのはてなダイアリー に書いたとおり、昨今は Emacs にもパッケージ管理システムが搭載されいて、どこからか elisp をコピペしてきてその後管理できなくなる・・・みたいなことはなくなった。 ただ、じゃあ ELPA で全て解決したかというとそんなことはなくて、ELPA はパッケージのインストール自体は簡単にしてくれるけれども、それだけだった。 elisp の管理も Bundler のように入れたいパッケージ一覧を書いて bundle install すれば全部まとめて入るみたいな、そういうのが欲しい・・・と常々思っていた。 と思っていたら、Cask というのを見つけた。これがずばりそのものだった。 (source gnu) (source melpa) (source marmalade) (depends-on "ag") (dep

    Cask - naoyaのはてなダイアリー
    sgtakeru
    sgtakeru 2014/05/14
    Caskでのelisp管理。
  • RubyMotion を1年以上使い続けてみての雑感 - naoyaのはてなダイアリー

    RubyMotion Advent Calendar 2013 に何か書こう、ということでエントリ。 ご存知のように iPhone アプリの HBFav は RubyMotion で作っています。Objective-C ではなく。以前は Titanium Mobile で作っていましたが、去年にバージョン2として作り直すにあたって RubyMotion に移行しました。 RubyMotion に関しては以前、以下のエントリで概要を説明しています。 RubyMotion - naoyaのはてなダイアリー それから、今年 5月に開催した RubyMotion カンファレンスのスライドなどもあります。 実践RubyMotion - Speaker Deck RubyMotion が発表されたのは 2012 年の5月 とかで、それからずっと使い続けているので1年半近くが経ったことになります。App

    RubyMotion を1年以上使い続けてみての雑感 - naoyaのはてなダイアリー
  • Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー

    先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう

    Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
    sgtakeru
    sgtakeru 2013/10/15
    bitbucket + pull request で開発してる。確かにpull requestの方が開発しやすい。
  • YAPC::Asia 2013 / Github によりバザールモデルへ - naoyaのはてなダイアリー

    ブログを書くまでが YAPC、ということなので、書きます。 初日「モダンPerlリファクタリング」 自分は20分枠で 「モダンPerlリファクタリング」という題で話しました。スライドは以下で公開してます。 https://speakerdeck.com/naoya/modanperlrihuakutaringu-number-yapcasia 今回、思いの他 CI やテストに関する発表が他に多くてそれらに比べると基礎的な内容に終始しちゃいましたが と @t_wada 御大よりお褒めに与ったので個人的には満足です。 リファクタリングはテストさえ書ければその半分以上は終わったことになる、ただしテストはテストを書くことそのものが主目的になりすぎないように。そして書いたテストはとにかく計算機を利用して頻繁に実行しましょうということが言いたかったのですが、意図通りに伝えられたんじゃないかなと思う。

    YAPC::Asia 2013 / Github によりバザールモデルへ - naoyaのはてなダイアリー
  • Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー

    Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル

    Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー
  • 開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー

    開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この

    開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - 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のはてなダイアリー
  • あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー

    お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinuxtop して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と

    あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
  • はてなブックマークの関連エントリー機能開発、PFI さんとの合宿 - naoyaのはてなダイアリー

    はてなブックマークに関連エントリーを配信する機能を追加しました。詳しくは 告知日記で。 この関連エントリーは、株式会社プリファードインフラストラクチャー (以下 PFI) の技術者のみなさんと一緒に開発しました。週末に2泊3日で京都で合宿をしてコア部分を作り、その後京都と東京に分かれてオンラインで連絡を取りながら2週間ほど作り込みをして、今日リリースです。 この合宿では何チームかに分かれて、今回の関連エントリーの機能以外の開発も行っています。その辺の成果はまた後日にリリースできるのではないかと思います。 はてなブックマークの一つの問題として、昔のエントリーがデータベースに埋もれてしまうという点がありました。その問題の解決策としての類似記事抽出、それから検索機能の強化を以前から考えていました。PFI のメンバーのみなさんは情報検索技術のスペシャリストです。アカデミックな研究の成果を製品化を通

    はてなブックマークの関連エントリー機能開発、PFI さんとの合宿 - naoyaのはてなダイアリー
    sgtakeru
    sgtakeru 2008/07/16
    国際大会に出るようなプログラマとのペアプロ。楽しいはず。レベルの違いに悲しくなりそう。
  • インターフェイス指向設計 - naoyaのはてなダイアリー

    を読むこととは、そのを読んだことに費やした時間の間、その書籍のテーマについて考えを巡らせることではないか、と近頃思います。を読みながら集中して、ある特定のテーマについて考え続ける。を読み終えた頃には、その思考の量的な価値が、自らの中で質的な価値に変換されているというのが理想であり、それが読書の醍醐味ではないかと思います。 インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践 を読みました。この書籍はシステム設計における「インターフェイス」(ユーザーインターフェイスではなく、プログラムインターフェイス) についての書籍です。インターフェイスについて考えを巡らせるにあたって、思考のための指針を与えてくれる良著だと思います。 プログラムインターフェイスというものをどのように捉えるか。ファイルをブロック単位で読むための手順であるとか、ソートのアルゴリズムであるとか、そ

    インターフェイス指向設計 - naoyaのはてなダイアリー
  • Introduction to DBIx::MoCo - naoyaのはてなダイアリー

    YAPC::Asia 2008 で OR マッパの DBIx::MoCo について発表しました。DBIx::MoCo は最近のはてなのサービスで利用しているバックエンドのソフトウェアで、Ruby 風のリスト操作や memcached による透過的なキャッシュなどをサポートしています。 http://bloghackers.net/~naoya/ppt/080516introduction_to_dbix_moco.ppt にて発表資料を公開しています。

    Introduction to DBIx::MoCo - naoyaのはてなダイアリー
  • 僕やはてながPerlを選ぶ理由 - naoyaのはてなダイアリー

    ご存知の通り、はてなのシステムはほぼすべてPerlで書かれています。そもそも僕がはてなに入った一つの理由に、僕が一番得意とする言語であるPerlを使ってシステムを構築していたという点があったりします。 世の中にはたくさんのプログラミング言語があります。PerlJavaRubyPHPPython、C、C++、lisp、Smalltalk、Cobol...数え上げたらキリがありません。そして、プログラマはかならずと言っていいほど、どれかひとつ以上の言語を愛しています。好き、ではなく愛しているのです。 自分が愛しているものを批判されると感情的になりやすいのは人の常、プログラミング言語の差異に関する議論は炎上しがちで、よく宗教戦争だなんて言われたりもします。その中で、言語なんてどれも一緒だなんていう乱暴なまとめがされることもよくあったりします。 しかし、何年かプログラマというものを経験して

    僕やはてながPerlを選ぶ理由 - naoyaのはてなダイアリー
  • 1