読者です 読者をやめる 読者になる 読者になる

webpackを使った Rails上でのReact開発

はじめに

こんにちは、投稿開発部エンジニアの芳賀です。

既存のRailsプロジェクトの中でReact.jsを利用する機会があったので、その時にやったことについてまとめてみます。

私自身は普段RailsのサーバサイドとCoffeeScriptが中心で、最近のJavaScript開発環境についてあまりキャッチアップできていなかったのですが、それらの状況を把握しつつ試行錯誤で開発していった経験から、できるだけ「React採用してみたいけどJavaScript界隈よくわからない目線」で書いてみようと思います。

RailsでReact.jsを使ういくつかの方法

2016年時点で、RailsでReact.jsを使う方法はいくつかあって、どれを採用するかで悩みました。

  1. vendor/assets/javascripts にreact.jsを置いて利用する
  2. react-rails gem を利用する
  3. browserify-rails で npm管理して利用する
  4. railsプロジェクト内に、JavaScript開発用のディレクトリを用意して webpack + babel-loader で利用する

調査したところ、だいたいこんなパターンがあると思っていて、下に行くほどRailsよりもJavaScript開発の知識が必要になってくるイメージでした。

最終的にはwebpackを選択したのですが、それぞれ軽く振れておくと

vendor/assets にライブラリを置く

Railsで外部JSファイルを利用する場合、vendor/assets にダウンロードしたファイルを置いて Sprocketsのマニフェストファイルで読み込んで利用するのが1番手軽だと思います。

手軽だとは思いますが、Reactを使いはじめると他のnpmモジュールもどんどん使いたくなってきて、それらを全部 vendor/assets に入れて sprockets で読み込み順を考えながら開発していくのは、ごく簡単なReactアプリケーションでもすぐ辛くなる印象でした。もっと良い環境を作った方が最終的に楽になると思います。

react-rails

https://github.com/reactjs/react-rails

その名の通り、RailsでReactを利用するためのGemです。 Bundlerで react-rails をインストールするだけで、すぐ利用できるようなお膳立てをしてくれます。

React.jsのファイルが同梱されているのはもちろん、Rubyで設定を書けたり、Reactコンポーネントのレンダリングヘルパーが用意されていたり、coffeescriptでもes2015でもJSXでも書けるなど、JavaScriptよりもRailsやRubyに慣れている場合、かなりとっつきやすいです。

React以外のnpmライブラリは自分でなんとかする必要があります。

browserify-rails

https://github.com/browserify-rails/browserify-rails

React用というわけではありませんが、browserifyというJSビルドツールをRailsのSprocketsで利用できる browserify-rails は、JSモジュールをnpmで管理できて、baberifyを通せば、es2015やJSXの変換もできます。

react-railsのヘルパー関連が必要なければ、browserify-rails のnpmで管理したreactを利用するのも手だと思います。

ただ、開発時のビルドが結構遅くて辛くなってきたのと、既存プロジェクト固有のコードと相性がよくなかったため採用は見合わせました。

browserify-railsに関しては、弊社外村の http://techlife.cookpad.com/entry/2015/12/14/130041 の記事が詳しいです。

webpack

http://webpack.github.io

webpackは依存関係のある分割されたJSやクライアントサイドのアセット群を、いい感じにまとめてくれるビルドツールです。

webpackにはLoaderという仕組みがあり、ソースコードに適用する処理を柔軟に設定できるのですが、babel-loaderを使うことでes2015やJSXで記述したJSファイルを変換することができます。

Reactに関わるモジュールバンドリング(複数ファイルの結合)、ソースコードの変換、ビルドしたコードの配置まではwebpackで行い、ファイルへのフィンガープリント付与などはこれまで通りSprocketsに任せます。

このやり方の場合、Rails開発者がある程度webpack環境について理解する必要があり、若干コストが高いような気もするのですが、今回JavaScriptのコードを触る人間が限られていたのと、JSを触らない開発者はある程度気にしないでもRailsの開発はできるような状態にしておきました。

また、私自身がReact、es2015などをはじめて使ったこともあり、問題があった時に切り分けが簡単であることが重要だったのと、開発中のビルドが速いということが決め手となり採用しました。

webpack利用時の構成

ディレクトリの構成は、以下のような感じで プロジェクトルートの client が webpack環境となっています。

├── Gemfile
├── Gemfile.lock
├── README.md
├── Rakefile
├── app
├── bin
├── client
├── config
├── config.ru
├── db
├── lib
├── log
├── public
├── test
├── tmp
└── vendor

webpack環境のディレクトリは

client
├── src
├── node_modules
├── package.json
└── webpack.config.js

このような構成になります。

client の 構成は一般的なwebpackによるreact開発とほとんど変わらないのですが、 ビルド時にファイルを配置する場所に ../app/assets/javascripts/webpack を指定しています。

client/node_modules../app/assets/javascripts/webpack はバージョン管理対象外としたいので .gitignore に追加しておきます。

# .gitignore
/client/node_modules
/app/assets/javascripts/webpack

webpack + babelの設定

webpack環境の準備をします。 必要な作業は以下の様な感じです。

  1. package.json を作り、npmでライブラリをインストールする
  2. webpack.config.js でビルド設定を書く
  3. foreman で webpack buildプロセスを起動する

1. package.json を作り、npmでライブラリをインストールする

client ディレクトリで

$ npm init -y

を実行して、package.json を生成します。公開することはないので「private」にしておきます。

{
  "private": true,
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  }
}

次に webpack と babel関連のライブラリをインストールします。 npm install -D は 開発時にのみ必要なライブラリをインストールしつつ、packpage.jsonに依存関係を記述してくれるオプションです。

$ npm install -D webpack babel-loader babel-preset-es2015 babel-preset-react

「babel-xxxxxx」が多くて混乱するのですが、 babel-loader はwebpackからbabelを使ってトランスパイルするためのパッケージ。 babel-preset-xxxxx は、es2015やJSXを変換するためのプリセットがbabel本体と分離しているので 個別にインストールする必要があります。

なんとなくBabelをインストールすればいい感じに全部やってくれるんでしょ?と思っていたのですがそうではありませんでした。

そして、いよいよ react をインストールします。 -S オプションは、アプリケーションに必要なライブラリを、packpage.jsonに追加しつつインストールをします。

$ npm install -S react react-dom

2. webpack.config.js でビルド設定を書く

次に webpackのビルド設定を書いていきます。 ここでは最小限やりたいことの

  • ソースコードのエントリファイルを指定する
  • 出力先のルールを設定する
  • 出力する際に、Babelによるトランスパイルを設定する

を、記述していきます

// webpack.config.js
module.exports = {
  entry: {
    app: './src/index.js',
  },

  output: {
    path: '../app/assets/javascripts/webpack',
    filename: '[name].js',
  },

  module: {
    loaders: [
      { test: /\.(js|jsx)$/,
        loader: "babel",
        exclude: /node_modules/,
        query: {
          presets: ["es2015", "react"],
        }
      },
    ]
  },
}

これで client/src/index.js がある状態で

$ ./node_modules/.bin/webpack -w

を実行すれば、ファイルの変更を監視して Railsの app/assets/javascripts/webpack/app.js にビルド結果が配置されるようになります。

さらに packpage.jsonに npm scripts に開発ビルドと本番ビルドのコマンドを用意しておくと、foremanやcapistranoから実行するときに便利です。

{
  "private": true,
  "scripts": {
    "webpack-watch": "webpack -w",
    "webpack-build": "webpack -p"
  },
  "devDependencies": {
    "babel-loader": "^6.2.4",
    "babel-preset-es2015": "^6.9.0",
    "babel-preset-react": "^6.11.1",
    "webpack": "^1.13.1"
  },
  "dependencies": {
    "react": "^15.2.1",
    "react-dom": "^15.2.1"
  }
}

3. foreman で webpack buildプロセスを起動する

このままでは、Rails開発者もわざわざJSビルド用の別プロセスを起動しておかなければならないので foreman start で railsとwebpackのプロセスを起動するようにします。

# Procfile
rails: bundle exec rails server
webpack: npm --prefix client run webpack-watch

その他

今回は最低限の設定のみふれましたが、webpackの設定で アプリケーションコードと react などのベンダーコードを分けて あまり変更のないベンダーライブラリをキャッシュしやすくしたり

複数のアプリケーションコードに分割しておくことができます。

https://webpack.github.io/docs/code-splitting.html#split-app-and-vendor-code https://webpack.github.io/docs/code-splitting.html#multiple-entry-chunks

最後に

今回は RailsでReactを利用する際に、react-railsやbrowserify-railsを利用しないアプローチについて書いてみました。 誤解のないようにお伝えしておくと、弊社のすべてのプロジェクトでこのアプローチを採用しているわけではなく、 react-railsやbrowserify-railsを使っているプロジェクトもあります。

各々のチームにあった方法を検討する参考になれば幸いです。

クックパッドでは エンジニアを積極採用中です。 https://recruit.cookpad.com/

今回のサンプルをこちらにおいておきます https://github.com/func09/react-on-rails-sample

デザイナー横断組織の変遷

こんにちは。デザイナーの池田(id:tikeda)です。6月末までユーザーファースト推進室というデザイナーを中心としたユーザー体験について横断的に責任をもっている室の室長を勤めていました。7月からこのユーザーファースト推進室をなくし役割を各部室に分散させる体制変更を行いました。 ユーザーファースト推進室については、過去のインタビューブログのエントリーをご覧ください。

はじめに

サービス開発では、デザイナー・エンジニアといった職種毎に部を構成し各プロジェクトに派遣するようなスタイル(A)、ディレクター・デザイナー・エンジニアといった役割の異なる職種で部を構成するスタイル(B)、またこの2つを組み合わせたハイブリットのような組織が存在しており、弊社だけでなく開発の現場ではよりよい開発が行われるよう試行錯誤が行われていると感じています。

f:id:tikeda:20160715091652p:plain

クックパッドではここ数年、アプリケーションエンジニアは各事業に所属していましたが、デザイナーのほとんどはユーザーファースト推進室に所属しプロジェクトやサービス毎にジョインするスタイルをとっていました。 本エントリーは私がこのユーザーファースト推進室を通して得た主にデザイナー組織についての知見を書きたいと思います。

2013年 : デザイナーをひとつの組織に

属人性をなくし、みんなでサービスを作れるように

まず、ユーザーファースト推進室は、社内で新規事業が立ち上がっていく過程で、デザインやユーザー体験がバラバラにならず統一感をもつこと、デザイナーがいない事業でも早いスピードでサービスを立ち上げられることなどを目的として、まずデザイン部という形で立ち上がり、のちにユーザーファースト推進室となりました。

それまで、デザイナーは各部門に所属していましたが、人数不足により、デザイナーが関わっていないプロジェクトや、あるプロジェクトのデザイナーが他のプロジェクトに頼まれてデザインしているといった事が自由に起こっていて俗人化していました。これを束ねて担当をつけることにより、リソースの分配や優先順位付けていき開発に取り組めるようになったと感じています。

ひとつの組織に集めてよかったこと

1 : デザイナー人数以上の力を発揮

1つに束ねたことで、デザインのガイドライン、フレームワーク化が促進され仕組みが整い効率化されました。そして、個々のデザイナーにとっても視野が広がることでこれまで幅広い仕事の領域にトライでき成長にもつながったと思っています。コーディングが得意な人、イラストが得意な人、UI が得意な人、ディレクションできる人がコミュニケーションを高め、教えあう環境を自然に作り個々の経験を高めるということです。結果、苦手なところを補いあってトータルの完成度も高められたのではないかと感じています。

そんな過程で、それぞれがお互いの仕事に意見を言い合える、360度でレビューの仕組みなどが生まれました。全体の見通しをよくするとともに、自信がない場合でも得意な人に聞け角度を高める文化となっています。

360度レビューの事例
f:id:tikeda:20160715091815p:plain:w400

2 : デザイナー以外スタッフのデザイン意識の高まり

横断的組織になることで、開発にとどまらず会社全体での接点も増えたと感じます。その結果、デザイナー以外のスタッフがデザインへの感度が高まったとも感じています。 コーポレイトロゴ、年賀状、広告のクリエイティブ確認など範囲は広がりましたが、コンペ形式をとり社内の参加を促すこともこの感度を高める一つの事例です。

コンペの告知事例
f:id:tikeda:20160715092023p:plain:w400

そのために相談しやすいインターフェイスを作るというのも意識していたひとつです。チャットでもメールでも、廊下ですれ違ったときでも相談方法は柔軟にしつつ、それをチームに持ち帰り整理し優先順位をつけていくことに労力を割くことが社内に浸透していく秘訣とも言えます。相談しにくい環境を作り品質管理を怠るよりも、小さいものでも受け入れ、クオリティをあげるチャンスをつかむ方が大切です。もちろん、それを継続させていくためには、それに答えるクオリティが外せないためデザイナーにもプレッシャーになります。

3 : 特定事業だけなく、全体を意識しデザインできるように

各プロジェクトにユーザーファースト推進室のメンバーが加わっていることで、事業部長などの縦串のプロジェクト責任者だけでなく、ユーザーファースト推進室としての横串の責任が生まれてきます。デザイナーは他のチームメンバーと共に事業成功に貢献するのが大切でありますが、エンジニアがエンジニアリング面での仕様や設計の責任を持つのと同様に、デザインに関してもデザイナーが責任を持つべきだと思っています。そしてそこには、事業サイドだけでなくトータルでのユーザー体験やブランディングの意識が欠かせません。そのため、例えば「この色は以前別のプロジェクトでやっていたここと合わせましょう」「このデザインをこのまま進めるとあっちのユーザー体験を毀損することになりそうです」といったことが主体的に行われるようになったと思っています。

全体を意識した取り組みの事例
f:id:tikeda:20160715092114p:plain:w400

2016年 : デザイナーを各組織に分割

目的を絞り、責任範囲を明確に

横断機能が社内でうまく作用していると感じている側面についていくつか書いてきました。しかし、もちろんうまくいうことばかりではありません。前述した通り、デザイナーは様々なプロジェクトに参加できる一方で、1つのプロジェクトを継続していく力や、1つのユーザー体験に集中して考えることに対して弱さを感じるようになりました。また、プロジェクトにジョインはするもののタイミングにずれがでることでコミュニケーションコストが嵩んだり、「依頼」的な観点が抜けない、依頼者側もユーザー体験についてお任せで頼りがちになるという問題もあります。 今回、ユーザーファースト推進室をなくした理由はこれらの課題の解消。そして、デザイナー同士の距離はこのままに、エンジニアやディレクターとの距離をもっと縮めて同じ責任領域でゴールを目指すことに意識に振り切ることで新しい組織力がつくように思っています。

最後に

以上、ユーザーファースト推進室での経験を元に組織を作る側の目線とデザイナーとしての目線を織り交ぜながら書いてきました。冒頭でも書いたように今回は各事業部に責任を強め、ディレクタ・エンジニアそしてデザイナーが1つの部で仕事をするようにしました。 かといって、これまでやってきた文化やカルチャを失わせる事を目的でやっていることではありません。フェーズにあわせて横と縦のバランスをうまく組み替えていくことでさらによいサービス作りが行えるとおもっています。

開発体制は会社が何を成し遂げたいのかによって左右し、それは規模や事業内容によっても変わると思います。今回のエントリーはクックパッドが会社として変わっていく過程でのデザイン組織の変遷事例として参考にしていただければと思います。

なお、クックパッドではエンジニア・デザイナーを絶賛募集しています。一緒にサービスを作ってくれる人のご応募お待ちしています。

ディレクターがSQLを使えてよかった話

こんにちは。ディレクターの川原田です。 クックパッドでお気に入りレシピを保存する「MYフォルダ」のサービス開発や、保存・記録に関する新規サービスの検討・開発を担当しています。

ディレクターの仕事は様々ありますが、今回は私が身につけたことで仕事領域が広がった!と感じているSQLについてお話ししたいと思います。

いきなりですが、SQLが使えてよかった点をまとめると以下です。

よかったこと

  • 数値抽出から分析まで自己完結
  • エンジニアとのコミュニケーションがスムーズに
  • 仕事が増えていそうで実は効率アップ
  • 周囲の知的好奇心を刺激

それぞれ具体例を交えてお話します。

数値抽出から分析まで自己完結

事例1:ログ構造を理解でき後の仕事がスムーズに

昨年、アプリのサービス開発を担当した際、エンジニアの設定したログが、実際に送信されるかどうかを事前チェックをしました*1

アプリのリリースはタイミングが決められており、ウェブのようにリリース後の修正がすぐには反映できません。そのため、仕様や設定にミスがあると修正が反映されるまでの期間のログが欠損してしまいます。

ログの事前確認により、欠損を防げただけでなく、新規に設定したログデータの構造も理解できていたので、リリース後すぐにデータベースに蓄積したログをSQLで抽出し、利用状況の把握を自ら行うことができました。今まではエンジニアに抽出してもらうことが多かったのですが、自己完結できたことでエンジニアの負荷を軽減できました。

また、この時はログデータ構造を理解した際に、出したい数値を抽出するためのSQLを書いておいたのですが、この虎の巻がリリース後の自分やチームを助けました。

事例2:エンジニアのタスクを削減

SQLを使え、ログ抽出を自ら行うとデータ構造の理解も進むため、必然と会社のサービス全体のログ構造の理解も進みます。

今年初めに、Web版のクックパッドに機能追加を行ったことがありました。その際、既存のログ構造を把握できていたため、今回の機能においては新規のログ設定は不要、とディレクター側で判断がつきました。そのため、この時の開発においては、ログの設計や設置というエンジニアタスクが削減されました。

SQLがわからずともデータ構造を理解していれば同じことができそうですが、実装時にテスト環境で検証する際、テスト環境のログもSQLで抽出ができたので、今回に関してはログの新規設置が不要だ!と自ら確信が持てたことはよかったです。

エンジニアとのコミュニケーションがスムーズに

事例3:データ設計の検討時に、エンジニアと会話がちゃんと出来る

事例2の時、見たい数値が既存ログで対応できそうという予測がつけられ、実際に取得ができたことをエンジニアに共有することで、エンジニアも新たにログの設定が不要であることが理解できました。

今まではどのようにログが設定されるのか理解できていない状態で依頼をしていたので、設定後取得できないものがあったり、より深く調査したいと思っても不可能なことがありました。

SQLを身につけたことで、ログ設計の検討をディレクターだけで出来たり、エンジニアが行ったログ設計の内容を聞いてKPIの数値が確実に取れそうかの判断がついたりと、設計検討時に、より具体的な話ができるようになりました。私からのオーダーがエンジニアに伝わりやすくなりました。

事例4:エンジニアが書いた長いSQLをダブルチェックでき、書いた人も依頼した私もお互い安心(逆もしかり)

この頃、社内ではre:dashというツールを各部署で使っています。re:dashでは、SQLで抽出したデータをそのままグラフにでき、任意の間隔で自動更新ができます。また、複数のグラフやデータを組み合わせてダッシュボードとしてまとめられます。今までは抽出データをスプレッドシートに貼り付け、グラフ化し、そのシートを共有していました。

re:dashダッシュボードのサンプル f:id:erikwrd:20160704110904p:plain

このre:dashの浸透により、様々なデータの可視化が便利な一方、可視化させたいことが多くあり、グラフ化するために複雑で長いSQLを書く機会が増えました。例えば「あるサービスに3ヶ月継続して訪問している人をアクティブ、それ以外を非アクティブして、その2グループの有料会員の継続率(1年間月ごと)を出す」などです。

少し時間はかかりますが、私のチームでは、あまりにも複雑そうなものはエンジニアと私で独自でSQLを書いてみて、結果を見比べ、その後にSQLを互いにレビューするという手法を取っています。

細かな点の漏れ(アプリのバージョン指定が間違っている、サービス閲覧の定義が足りていないなど)が見つかり、お互いのミスをカバーしあえます。

今では、エンジニアに複雑な抽出を任せっきりにすることは、お互いに不安だと感じるようになりました。

仕事が増えていそうで実は効率アップ

SQLを扱えると仕事が増えるのでは?と、思われるかもしれないですが、事例4に書いたre:dashというツールの採用もあり、以前よりも新規プロダクトの定期的な数値分析の効率はアップしています。

新規のプロダクトだと新たなログ集計ツールの用意自体が工数増になるので省略することが多く、日々SQLで抽出してスプレッドシートに貼って、、、ということが多々ありました。今ではすべてre:dashにお任せしています。

また、プロダクトや目的ごとにダッシュボードを作ることで、改めて分析し直す時や新たなプロダクトの分析をする際も、過去の様々なSQLから参考になりそうなものをさっと取り出せるので、ゼロから考えることが減りました。

さらに私自身のSQLの理解が進んだことで、見たい数値が取れてない!ということもなくなり、エンジニアとの認識齟齬もなくなっているので、結果としてチームの効率もアップしています。

周囲の知的好奇心を刺激

事例5:ペアプロならぬペアSQL

ありがたくも、周囲から質問だけでなくSQLを一緒に考えて欲しいと頼まれることも出てきました。

あるときは、ちょうど自分が最近身につけたウィンドウ関数を使った累積和や、事例4の時に身につけたwith句が使えそうだったので、説明しながら出し方を共に考え、実際に書くところまでを一緒に行いました。

人に教えることで自分の理解も深まり、普段自分が出そうとしている内容とは全く違うSQLを考えることで、分析の仕方に新たな発見もありました。

事例6:初心者向け勉強会を開催

上半期(1〜6月)まで所属していた部署は人数が多く、ディレクターも多くいました。私含め部署内にSQLが書けるディレクターがいる一方、SQLを書けないけれど興味を持っている初心者もいました。勉強会を開催することになり、私が講師役を務めました。

勉強会は、SQLとは何かをただ理解するだけではなく、「SQLを書く!」に徹した内容を伝え、実際に書けるようになることを目指した内容にしました。実践に集中できるように、SQLとは?という基本理解は、弊社エンジニア青木峰郎の著書「10年戦えるデータ分析入門」の第1〜3章にお任せし、各自で事前に読んできてもらいました。

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)

また、勉強会当日は最初にお題を出し、以下のように「お題=出したい内容(日本語)からSQLを作る、その作る過程で基本のSQL構文を理解してもらう」方法で伝えました。 お題を分解し、どこから(from)、どんな条件の(where)、何を(select)出すのか?を考えた上でSQLを書いてもらいました。

スライド抜粋 f:id:erikwrd:20160704113640p:plain

また、私が普段実践している「出したいことがあっても出し方がわからない(何のカラムを見たら良いか、カラムに何が入るのか不明な)時は、実際に自分で操作して自分のログを抽出する」という自己解決法を伝えました。誰でも今からやれる方法ですし、エンジニアに聞く前に少し調べるだけで、解決したり、聞き方が明確になったりして有益だと思っています。

勉強会の実際のスライド(一部抜粋)は以下です。

勉強会で人に教えることで自分自身の理解が深まったり、理解しやすい伝え方を考えたりと、とてもよい機会でした。また、参加してくれたディレクターのみんながその後チーム内で継続して、SQLを習得するために1週1題を実践しています。 自分の知見を共有することで、周囲にもよい影響を与えることができ、とてもよかったです。

最後に

SQLが書けると色々な数字が出せること自体が面白くなり、データ構造がわかるとあれこれ調べたくなります。それはそれでデータ分析の入り口に立てた!という意味では良い気がしますが、どんな仕事も同じで、その仕事の目的を明確に持ち、また常にその仕事の目的が何かを意識すること、単に作業すること自体を目的にしないように心がけることが、当たり前ですが大事だと思います。

この会社で、初めてディレクターという職種で2年半働き、様々なことを周囲から学んだ中で、特にこのSQLのスキルに関しては身につけて心底よかった!と思っています。この記事が、もし今後SQLを学んでみようという方の役に少しでも立てたら幸いです。

事例6で紹介した本はとてもわかりやすいので、最初の1冊にされることをオススメします。

*1:この時はAndroidStudioを使いました

/* */ @import "/css/theme/report/report.css"; /* */ /* */ body{ background-image: url('http://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527163350.png'); background-repeat: repeat-x; background-color:transparent; background-attachment: scroll; background-position: left top;} /* */ body{ border-top: 3px solid orange; color: #3c3c3c; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; line-height: 1.8; font-size: 16px; } a { text-decoration: underline; color: #693e1c; } a:hover { color: #80400e; text-decoration: underline; } .entry-title a{ color: rgb(176, 108, 28); cursor: auto; display: inline; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; font-size: 30px; font-weight: bold; height: auto; line-height: 40.5px; text-decoration: underline solid rgb(176, 108, 28); width: auto; line-height: 1.35; } .date a { color: #9b8b6c; font-size: 14px; text-decoration: none; font-weight: normal; } .urllist-title-link { font-size: 14px; } /* Recent Entries */ .recent-entries a{ color: #693e1c; } .recent-entries a:visited { color: #4d2200; text-decoration: none; } .hatena-module-recent-entries li { padding-bottom: 8px; border-bottom-width: 0px; } /*Widget*/ .hatena-module-body li { list-style-type: circle; } .hatena-module-body a{ text-decoration: none; } .hatena-module-body a:hover{ text-decoration: underline; } /* Widget name */ .hatena-module-title, .hatena-module-title a{ color: #b06c1c; margin-top: 20px; margin-bottom: 7px; } /* work frame*/ #container { width: 970px; text-align: center; margin: 0 auto; background: transparent; padding: 0 30px; } #wrapper { float: left; overflow: hidden; width: 660px; } #box2 { width: 240px; float: right; font-size: 14px; word-wrap: break-word; } /*#blog-title-inner{*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-position: left 0px;*/ /*}*/ /*.header-image-only #blog-title-inner {*/ /*background-repeat: no-repeat;*/ /*position: relative;*/ /*height: 200px;*/ /*display: none;*/ /*}*/ /*#blog-title {*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-image: url('http://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527172848.png');*/ /*background-repeat: no-repeat;*/ /*background-position: left 0px;*/ /*}*/