トップ コラムGoogleAnalyticsのCookieは、なぜサードパーティCookieではなく、ファーストパーティCookieなのか？ ブログをご覧頂いている皆さん、こんにちはニコライです。Nexalではテクニカルエンジニアとして勤めています。技術的な観点から、皆さんの業務にお役立て頂けそうな情報を更新して参ります。今後とも宜しくお願いします。 初投稿のお題は、GoogleAnalyticsのCookieについてです。 公式ヘルプによると、GoogleAnalyticsではアクセス解析の仕組みとしてCookieを利用しており、且つそれはファーストパーティCookieであると謳われています。ただ、これには合点がいかない方も多くおられるようです。「Googleのサーバと通信しているのだから、サードパティではないのか？なぜファーストパーティ？」という疑念があるからです。以下が公式ヘルプの一

Vagrant の基礎知識 Vagrantとは？ なぜ Vagrant なのか？ Box と Provider 共有フォルダ機能 (Synced Folder) プロビジョニング (Provisioning) WindowsではじめるVagrant 第1回 : Vagrant をWindowsにインストールする手順 第2回 : Windows版Vagrantを利用して仮想マシーンを操作してみよう 補足1 : WindowsでVargentを使う場合のプロキシ設定 macOS ではじめる Vagrant 第一回 : Vagrant を macOS にインストールする手順 第二回 : Mac OS X 版Vagrantを利用して仮想マシーンを操作してみよう Vagrant の基本操作を覚えよう Vagrant の Box の基本操作(追加・更新・削除・一覧)を覚えよう 設定 Vagrantにお

id:0422 time:[2013-11-19 02:34:58] level:INFO method:POST uri:/api/v1/textdata reqtime:3.9726677258569842 foobar:LFK6XV1N id:0423 time:[2013-11-19 02:34:58] level:DEBUG method:GET uri:/api/v1/people reqtime:0.49912949125272277 foobar:DcOYrONH id:0424 time:[2013-11-19 02:34:58] level:WARN method:POST uri:/api/v1/textdata reqtime:2.930590441869852 foobar:XEZ5bQsh 設定パラメータ ちょっと長くなるので読み飛ばしてもらっても良いのですが、

Bashに脆弱性が見つかるという恐ろしい事件。 脆弱性があるかないか確認 takuya@debian01:~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test vulnerable が表示されたら、アウト。コレを消す apt で対応する。 sudo aptitude update sudo aptitude upgrade bash apt のキャッシュをアップデート、その後、bashのパッケージをアップグレード。 apt 使えば、該当のパッケージだけを更新できるから便利ね。 対応結果 takuya@debian01:~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" this

同じgemでもアプリによって依存するバージョンが違ったりする場合やちょっと試したい場合に、rbenv-gemsetをつかって、gemsetを分けておくと便利。 例えば、bundlerとかpryとか共通に使うgemは、globalと名付けたgemsetにして、railsとかsinatraとかのgemはアプリごとにgemsetを作るとはかどる。 まず下のようにglobalなgemsetを作る。 当然ながら、gemsetはrubyのバージョンごとに作る決まり。 $ rbenv gemset create 2.0.0-p247 global 作ったgemsetを確認 $ rbenv gemset list 2.0.0-p247: global 現在有効なgemsetを確認する $ rbenv gemset active global globalが印字されれば,上で作ったglobal用のgemse

すぐさま rbenv-gem-rehash を入れよう Qiita で「rbenv を使って Ruby をインストールした」記事は 毎日1回以上 あります。にも関わらず、そのほとんどが「Rails などをインストールしたら rbenv rehash します」と書いている。 なぜ rbenv-gem-rehash を入れないんだ。 Never run rbenv rehash again. This rbenv plugin automatically runs rbenv rehash every time you install or uninstall a gem. もう二度と rbenv rehash しなくていい。 gem をインストール/アンインストールする度に、この rbenv プラグインが自動的に rbenv rehash する。 sstephenson/rbenv-gem-

【重要】Mac環境を前提としております。Windowsでは現状残念ながらunicornのmakeに失敗するので、うまく行きません。 Windowsの場合は、VMwareをご使用下さい。vagrant 環境でも可能です。 １．macportを削除すること ２．Xcodeをインストールしてあること。 ３．Xcodeのコマンドラインツールをインストールしてあること ４．rvmを使っている人は「rvm」を削除すること ５．.bash_profile に変なことが書いてある人は消すこと。 ６．万が一の為にタイムマシンでバックアップをとっておいた方が幸せ。 ７．MYSQLを使う人というかほとんどだと思いますが、MYSQLのインストール ８．MacOSが「El Capitan」の場合は「SIP」を無効化する必要性があります。 手順は以下参照 ■URL SIPの無効化 Xcodeのインストール Xcode

某所でRのformulaオブジェクトの扱い方について話題になっていて，自分自身あまり詳しくはなかったので，まとめておく。 formulaはRに特有のクラスで，使いこなせば分析を非常に効率化できるが，つっこんだ情報はあまり見かけない。formulaは基本的には回帰系の関数の引数に用いられる，モデルを表現するオブジェクトである。 fm1 <- y ~ x1 + x2 + x3 class(fm1) #=> [1] "formula" update(fm1, . ~ . + x4) # updateで書き換えられる #=> y ~ x1 + x2 + x3 + x4 update(fm1, . ~ . -x1) #=> y ~ x2 + x3 + x4 update(fm1, y2 ~ (.)^2) #=> y2 ~ x1 + x2 + x3 + x1:x2 + x1:x3 + x2:x3 #

Rails ではアプリケーションで必要となる Gem パッケージの管理に Bundler を使用します。 Bundler の設定ファイルである Gemfile 、インストールを行った結果を保存する Gemfile.lock を使うことで複数の環境で別れて同じアプリケーションを開発する場合でも、簡単に同じ開発環境を整えることができます。ここでは Bundler を使って複数の環境で同じバージョンの Gem を使用する方法について解説します。 Gemパッケージとは まずは Gem パッケージについて簡単に解説します。 Ruby で使われるライブラリやアプリケーションは、 Gem と呼ばれる形式のパッケージにすることができます。多くのライブラリが Gem 形式でパッケージされ公開されており、これらは RubyGems と呼ばれるパッケージ管理ツールを使ってダウンロードしたりインストールすることが

GitHub - rbenv/rbenv: Groom your app’s Ruby environmentを使ってRuby環境を構築しました。Rubyは実質初めてなので、二の足を踏んだりよく分からず調べてばかりで、なかなか先に進まなかったりもしたけど、ようやく基本的な要素を把握出来た感じ。そんななので、細かく書きすぎてて若干くどいかもしれない。 rbenvのインストール $ cd ~ $ git clone git://github.com/sstephenson/rbenv.git .rbenv $ vi .bashrc #rbenv export PATH="$HOME/.rbenv/bin:$PATH" eval "$(rbenv init -)" rbenv自体はこれでインストール完了。 ここで、Terminalを開きなおす等して、.barhrcを読み込ませる。 ruby-bu

MacPorts と比べて Homebrew は依存関係でインストールされるソフトが少ないためか、パッケージ管理システムとしての人気が高まってきています。 MacPorts は、Mac に最初から入っているソフトウェアを無視してパッケージが依存するソフトを新規でインストールするという性質を持っていますが、Homebrew は極力 Mac に入っているものを使うように作られています。ゆえに、パッケージ導入時のシステムへの負担や、インストールにかかる時間が比較的少なくて済むようです。 また、Homebrew はスーパーユーザでコマンドを実行する必要が無く、一般ユーザー権限で使うことが出来ます。 ※【2015/07/07 追記】最近では Homebrew が大きく台頭してきて、MacPorts の名前を見ることは減ってきました Homebrew について Homebrew は「ユーザが自らパッケ

rbenv と RVM との違い 列挙してみる。 rbenv は RVM と違ってシェルにコマンドをロードしない → 代わりに $PATH を追加するだけで使えるrbenv は RVM と違ってシェルコマンドを上書きしない（RVM は cd などを RVM 独自のものに置き換える）rbenv は RVM と違って設定ファイルが無い → どのバージョンを使うかの指定のみrbenv は RVM と違って Ruby をインストールしない（rvm install 相当の機能が無い） … 代わりに自分で好きに Ruby をインストールできるし、rvm install 相当の ruby-build を使うこともできるrbenv は RVM と違って gemset の概念がない … 代わりにアプリケーション毎の Bundler を使ったほうがいいよrbenv は RVM と違って他の gem を変更する

Linuxシステムを管理している人には常識的なことだと思うけど、アプリケーションが使用中のポート番号を調べる方法についてのメモ。今日某プロジェクトの実験用マシンの設定をしていた最中、あるサービスを起動したら「address already in use.」というエラーメッセージが出てきて調べたので。 アプリケーションが使用中のポート番号は「lsof」や「netstat」コマンドで調べることができる。lsofは「lists open files」の略で、プロセスが開いているファイルを列挙するコマンド。 $ ps aux | grep zsh shin 1644 0.0 0.1 602692 2676 s000 S 1:09AM 0:00.12 -zsh $ lsof -p 1644 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME zsh

前から使っていたTomcatの起動スクリプトをDebian 6.0(Squeeze)に作成し、 update-rc.dを使って自動起動させようと思ったら警告が表示されました。 どうやらDebian 6.0から「update-rc.d」ではなく「insserv」を使う作法に変わったようです。 何が変わっているのか気になったので、 http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot ここの冒頭をざっくり翻訳してみました。 Dependency based boot sequence - 依存関係ベースのブートシーケンス Debianは、各々のinit.dスクリプトのヘッダーに記載されているLSB fields(*1)を参照し、 サービスの起動順序を制御する仕様を満たしています。 この機能は、前からある起動順序を制御する不具合を解消