Dockerリベンジ

お久しぶりです、1年もこのブログ書いてなかったんですね。
びっくらこいた。
インターンシップでDockerを触る機会がまた出てきたので1年越しのリベンジです。

Dockerをどっかーん

で、おなじみのDockerです。
前回の記事ではなんかわかった気になっていたんですが具体的にどこで使うのかよくわからないといった感じでした。
今回、「なるほど、こうやって使うのか」という感じになったのでそのメモです。

あらためてDockerって何?

Dockerとは、簡単に言うとVMっぽい何か、です。
VMなのですが、カーネルの部分はホストのOSを使うので従来のVMと比べるとめちゃくちゃ軽いVMです。
ただ、そのせいか今のところホストOSはLinuxに限られています。建てることができるVMもLinuxです。

実際にどんなことやってるかは前の記事で。
この記事では細かいDockerの説明はしないので別に読まなくても大丈夫かと。

Docker Hub

Dockerの強みの一つにDocker Hubがあります。
Docker HubはOS版Githubみたいなやつです。
このDocker Hubにはあらかじめアプリケーションが立ち上がる環境を整えたOSのイメージがアップロードされています。
僕達が今までやっていた面倒なサーバ構築は必要ありません。
僕達がすべきことは

  1. DockerHubからイメージ(OSのインストーラみたいなもの)をダウンロードして
  2. そのイメージからコンテナ(実際のOSのインスタンス)を立ち上げ
  3. 使う!

これだけです。
DockerHubはそのOSで動かしたいアプリケーションや言語などの名前でイメージが上がっているのでとりあえずそれで検索すると引っかかることが多いです。
Docker Hubにはどんなアプリケーションがあるのかというと、Wordpress、Redmine、Slack、nginx、Apacheなどなど。
また、ApacheとかはPHP5用のApache環境などかなり細かい指定のイメージもあったりします。
Redmineとかはコンテナ立ち上げるだけで勝手にサーバを立ち上げるので、あとは指定されたlocalhostのポートにアクセスするだけでOKでした。
また、WordPressのようなデータベースを使うアプリケーションはそのアプリのDockerコンテナの他にDBサーバ用のDockerコンテナも一緒に建てる必要があるようです。

あと、起動したコンテナにアクセスしてなんかやりたいときは

 $ sudo docker exec -ti {CONTAINER_NAME} bash 

ってやるとbashを立ち上げて中に入れます。
execってのは立ち上がってるDockerにアプリケーションを立ち上げるためのコマンドなんだそうな。

つまりどこで使えるのか

まず、外部サービスと連携するようなアプリを作るときにかなり楽にテスト環境を構築できます。

また、Webアプリを作るときも自前でサーバを立ち上げる必要がなく、Docker内のサーバにデプロイできる仕組みさえ整えておけばさくっと開発環境が整います。

さらに、作ったアプリケーションを環境ごと公開できます。
DockerはDockerfileという一つのファイルによってコンテナ立ち上げ時の処理を記述できるので、
それを使ってアプリケーションの環境を整え、Githubなどからアプリケーションをクローンし、アプリケーションを起動する、という流れをDockerfileに記述することによってアプリケーションを環境ごと提供できます。

なお、Macでも一応Docker使えるらしいんですがなんかvagrantかなんかで小さいLinuxを一回建ててそこで起動するみたいなことしかできないらしいです…
Windows? VM使うほかないです。

【Rails3.2】deviseを触ってみた

最近DSLとかばかり見ているのでたまにはプログラミングもせなあかんということで、Railsを復習がてらアプリを作成することにしました。

そこで、IDとパスを使った認証が必要になりそうだったのでdeviseというgemを使って色々やってみたのでそれの記録です。

deviseとは

gem上で使えるサインアップ、ログイン、ログアウトの仕組みを作ってくれるgemです。これを使ってモデルを作るだけで勝手にログイン画面とかを作ってくれます。

Railsでdeviseを使う

実行環境

今回はの実行環境は以下。

  • Rails 3.2.16

  • Ruby 2.0.0p481

インストール

Railsでdeviseを使うためにはGemfileに次の行を書き加えます。

/Gemfile

gem 'devise'

後に、bundle installをする。後に、関係ファイルをジェネレート。

$ bundle install
$ rails g devise:install # config/devise.rb(設定ファイル)の作成をします。

また、deviseをログインしていない状態でログインしないと入れないアクションを実行しようとした時rootにリダイレクトするのでテキトウにrootをroutes.rbに書いておきます。

/config/routes.rb

  root :to => "home#index" # home/indexをルートにする

モデルを作る

これで使う準備ができたので、deviseを使ってモデルを作成します。railsプロジェクトのルート上で以下コマンドを実行。

$ rails generate devise User
$ rake db:migrate

Userは任意のモデル名です。まあ、普通ログインシステムを作る時必要なのはユーザの情報なのでUserが一般的でしょう。

このコマンドを実行するとdevise用のモデルが作成されます。その後マイグレートしてあげましょう。

警告用のビューを足す

警告を全てのページに表示ができるようにlayoutsを編集しましょう

/app/views/layouts/application.html.erb

<p class="notice"><%= notice %></p>
  <p clss="alert"><%= alert %></p>
<%= yield %>

yieldの前に置いておくのが一番自然だと思われます。

ルーティング

rake routesを実行すると以下の様なルーティングになっています。

                    root        /                              home#index
        new_user_session GET    /users/sign_in(.:format)       devise/sessions#new
            user_session POST   /users/sign_in(.:format)       devise/sessions#create
    destroy_user_session DELETE /users/sign_out(.:format)      devise/sessions#destroy
           user_password POST   /users/password(.:format)      devise/passwords#create
       new_user_password GET    /users/password/new(.:format)  devise/passwords#new
      edit_user_password GET    /users/password/edit(.:format) devise/passwords#edit
                         PUT    /users/password(.:format)      devise/passwords#update
cancel_user_registration GET    /users/cancel(.:format)        devise/registrations#cancel
       user_registration POST   /users(.:format)               devise/registrations#create
   new_user_registration GET    /users/sign_up(.:format)       devise/registrations#new
  edit_user_registration GET    /users/edit(.:format)          devise/registrations#edit
                         PUT    /users(.:format)               devise/registrations#update
                         DELETE /users(.:format)               devise/registrations#destroy

このアクションのURLを直接入力することでログイン、サインアップなどのフォームが出現します。ビューも勝手にできているようです。

ビューを編集できるようにする

ビューは初期状態では内部で処理されてしまっていますのでカスタマイズをするためにapp/viewに出しておいたほうが懸命です。以下コマンドで出力されます。

$ rails generate devise:views users

後に、devise.rbの208行目にあるconfig.scoped_viewsのコメントアウトを外し、trueにしてしまいましょう。

/config/devise.rb

  # ==> Scopes configuration
  # Turn scoped views on. Before rendering "sessions/new", it will first check for
  # "users/sessions/new". It's turned off by default because it's slower if you
  # are using only default views.
  config.scoped_views = true

ログインしないとできないページを作る

アクションのコントローラの先頭ににbefore_filterを追加します。

/app/controllers/user_controller.rb

  before_filter :authenticate_user!, :except => [:show, :index]

  class UsersController < ApplicationController
  def index
  …

:exceptパラメータで認証なしで実行可能なアクションを指定可能です。

ログイン方法をe-mailからユーザネームに変更する

ログイン方法がデフォルトではe-mail、パスの入力になっています。これを例えばユーザネームとかに変更したい場合の対処法。

とりあえずモデルに変更するカラムを足す。今回はusernameというカラムを足していきます。

$ rails g migration add_username_to_users username:string
$ rake db:migrate

次に、付け加えたカラムを認証用のキーに変更します。所謂、「主キー」の変更ですね。devise.rbの32行目config.authentication_keysを書き換えます。

config/devise.rb

 # config.authentication_keys = [ :e-mail ]
 # ↓
 config.authentication_keys = [ :username ]

このdevise.rbではdeviseの様々な設定ができるので覚えておいたほうが良いですね。

あとはビューをいじります。
emailを入力するべきところをすべてusernameを入力するように変更しましょう。とりあえずは、/app/views/users/sessions/new.html.erbと/app/views/users/registrations/new.html.erbを変更すればサインアップとサインインはできるようになります。コードは省略。

これでうまくいくかなーとおもいきや、e-mailを入れろと怒られます。バリデーションの回避がうまく行っていないようです。
以下のメソッドをUserモデルに付け加えましょう。

/app/model/user.rb

  def email_required?
    false
  end

これでバリデーションを無視することが出来ました。本当はe-mailカラムを削除しておかないといけませんが、まあとりあえずはこれで変更が可能ですね。e-mailは後で任意で入れさせるようにするかもしれないので今回は放っておきます。

参考

 

Dockerを触ってみた。

おはようございます。レモンです。

友人がDockerすげえ、やべえって言っててかつ一緒に作ってるサービスもDockerで運用する予定だと言い出したのでこれは僕もある程度触れるようになっておかないとまずいっちゅうわけで少し触ってみました、というお話。どっちかというと使い方というよりは所感と言った感じです。

そもそもDockerって何さ

さて、そもそもDockerとは何なんでしょうか?自分も彼に紹介されるまで全く知りませんでした。

詳しくは公式ページを見てもらえればいいのですが当たり前のように英語なのでちょっとわかりにくいですよね。

ざっくりというと、めっちゃ省スペースなVMと考えて差し支えないと自分は思いました。

細かく言うと従来の変更の度に既存のサーバに変更を加えるやり方ではなく、Immutable Infrastructureと呼ばれる既存の環境をイチから作り直し、古いものを切り捨ててしまうという考え方によるものであります。
これを実現するためにDockerではコンテナとイメージという単位でOSを管理していき、Gitのようにバージョン管理を行いながら逐次更新したり削除していきながらOSを操作していきます。
そして、これがすごいんですが、ある構築した環境を別のDockerがインストールされている環境へまるまるコピーができるわけです。こうすることで、環境移行のときにわざわざ前の設定を思い出しながらLinuxを泣きながらいじるという手間をDockerさえ入れてしまえばSkipできてしまう!というわけなんです。なぜ、省スペースなのか、というと元となるイメージが最小構成(bashくらいしか動いてない)なのと、差分で環境を管理しているためなんだそうです。そのため、起動や破棄、リソース量などが従来のVMと比べて軽い上、差分で管理しているためGitでDockerの設定状況を管理する!みたいなこともできるんだそうです。すげー。

コンテナとイメージ

さて、Dockerを使う上で必ず覚えなくちゃいけない概念がこのコンテナとイメージというものです。この2つをやりとりすることがDockerの基本的な操作になります。

詳しくは@IT様のこちらのページがわかりやすいなーと思いました。

まあ自分なりにも説明してみます。

まず、イメージというものはOSのモトとなるもので所謂テンプレートです。オブジェクト指向でいう「クラス」にあたりますね、このクラス、もといイメージからDockerはコンテナを作ることが出来ます。
ちょうど、クラスからオブジェクトを生成するのとおなじ感覚でいいと思います。自分はその感覚が完全にしっくり来ました。

オブジェクト指向と異なる部分はここからで、イメージから生成されたコンテナを作ってあげるとその中のOSを起動し、いじることができます。例えばapt-get updateをしてあげたり、vimをインストールしたり、apacheを入れたりと様々なLinuxでできる操作を行うことが出来ます。ホストOSとDockerで起動中のコンテナ上のOSもコマンド一発で行き来できます。(後述)

ある程度変更が完了したら、コンテナの変更状況をイメージに書き込みます。イメージに書き込んであげるとコンテナの変更状況を反映したイメージが再び生成されます。普通に生成してあげるともともとあったイメージと、新しく変更を反映したイメージどちらとも残ります。これらは作業の進行状況に合わせて削除したり残しておいたりすることができます。と言った感じです。

また、変更作業中以外は基本的にはコンテナは使いきりで、変更が終了したら必ずイメージに反映させ、中途半端な変更をしたコンテナを残さないようにすることで変更作業が混乱することがなくなるようです。

図示すると以下の様な感じでしょうか。

 

Docker

 

実際に使う

さて、じゃあ実際に使う場合にはどうすりゃいいのよって話なんですがそんなに難しくないです。

参考:いまさら聞けないDocker入門(2):ついに1.0がリリース! Dockerのインストールと主なコマンドの使い方 – @IT

参考ってか、これのインストール以降部分を噛み砕いて説明って感じです(・ω・`)

インストール

まず、Dockerをインストールしましょう。今回はCentOS7を使いましたが、Ubuntuとかでも多分大丈夫です。ただ、インストールが一番楽なのはCentOSなんだとか。

 $ sudo yum install docker 

これだけでOKです。ただ、バージョンが低いので最新版が欲しい場合はEPELを用いてパッケージを引っ張ってきてください。

dockerのベースイメージをダウンロードする

Dockerが入ったので元となるイメージをDockerから引っ張ってきましょう。現在安定しているOSがUbuntuしかないのでとりあえずUbuntuで。
他にも、CentOSや各サービス(MySQL,WordPress,PostgreSQL,nodejsなど)が引っ付いたUbuntuイメージも引っ張ってこれるのですが、今回はまっさらなUbuntuイメージを持ってきます。
また、CentOSは現在安定版が存在せず致命的なバグが多いためあまり使わないほうが懸命のようです。

「引っ張ってくる」のでdocker pullを使います↓

 $ sudo docker pull ubuntu:latest 

pullのあとにOS名:タグ名と入れてあげるとDLが可能です。タグ、というのはバージョンごとに付いている名前のようなものです。ここに載っています。

DLができたら確認をしましょう。

 $ sudo docker images 

これで現在インストールされているイメージの一覧を表示することが出来ます。

イメージからコンテナを生成する

イメージが引っ張ってこれたので今度はここからコンテナを作って実行してみます。

「実行」するのでdocker runですね。

 $ sudo docker run -it --name ubuntu-container ubuntu /bin/bash 

でOKです。これでubuntu-containerというコンテナを作成し、実行することが出来ます。オプションなどはDocker公式@ITのページなどを参考にしてください。一応-itでコンテナの標準入力を開き(-i)、かつtty(端末デバイス)を確保する(-t)という意味みたいです。まあ、上のコマンドを最初のウチは呪文のように打っておいても問題なさそうです。

無事にrunできるとrootでDockerコンテナ上のOSのbashが起動し、いじることができるようになります。あとは、ここから普通のUbuntuと同じように色々インストールをしたり、ネットワーク設定をしたりしてあげればOKです。

また、Dockerコンテナ上のOSからホストOSに戻るにはCtrlを押しながらpを押した後、qを押します。

また、ホストOS上で現在起動しているコンテナを確認するためには以下のコマンドを実行します。

 $ sudo docker ps -a 

コンテナからイメージを生成する

さて、コンテナの調整ができたらイメージを作ってとりあえず作業は一段落ですよね。

ということでイメージを作ります。まず、ホストOS側にCtrl-p-qで戻りましょう。そして、現在起動しているdockerコンテナOSを停止させます。OSなので起動中にイメージの生成とかできません。

 $ sudo docker stop ubuntu-container 

イメージの生成ではdocker commitというコマンドを使います。Gitのリポジトリにcommitしている感覚でしょうか。コミット前にdocker psでコンテナがきちんと止まっているかも確認しておくと安心です。

 $ sudo docker commit ubuntu-container myubuntu-image1 

commitの後にコンテナの名前とイメージ名を入れればOKです。上ではmyubuntu-image1というイメージ名で作成しました。

この後に、

 $ sudo docker images 

と打ってあげれば作ったイメージが在ることが確認できるかと思います。

既存のイメージを削除したいときには

 $ sudo docker rmi (イメージ名) 

と打てばOKです。

また、止めてしまったコンテナはdocker startというコマンドで再開することもできます。

 $ sudo docker start -i ubuntu-container 

 

基本的には以上の操作の繰り返しなんだそうです。ここまでくれば、作ったイメージからまたコンテナ作っていじってイメージ作っていらないイメージ消してーといったやりとりが出来ますよね。
僕がいじったのはここまでなので他のことはあんまし言えません。他にもDockerfileなるものとかもあるみたいですが、今回は触れていないので、No Touch!で。

所感

友人の彼いわく、これの実用的な使い方としてはテスト用の鯖と本番用の鯖を2つ同じような環境(例えば同ネットワーク内など)に用意して、両方にDockerを入れ、変更をテスト用の鯖にDockerを使って反映しながらテストを行い、それがうまく行ったら本番用の鯖を一瞬止めてテスト用鯖で作ったイメージを本番用鯖に突っ込み、コンテナを生成&起動してしまえばメンテ時間がめちゃくちゃ短くなる!みたいなことを語気荒く説明してくれました。

もしこれが本当に実用で使うようになればサーバ管理に革命が起きそうだなーと思います。このDockerなんでもまだ作られて1年立ってないとからしいのでめちゃくちゃHOTなサービスです。今後も注目ですねー(`・ω・´)

 

DSLとXtext

Xtext書けるようになっておいてねという指示を頂いたので、勉強してたらどうも今までのプログラミング言語とは毛色が違うらしいので定義からさらってみる。XtextはDSL生成のためのIDEらしいのでそもそもDSLってなんじゃいってところから。

DSLについて

DSLとは

ドメイン特化言語(Domain Specific Language)の略

「ドメイン」に特化した言語なので特定の種類の問題に対してのみ有効な言語である。

主にメタプログラミングに用いられる。

メタプログラミングとは?

meta- は、高次の-とかいう意味なのでプログラミング言語をプログラミングする的な意味かな?

内部DSLと外部DSL

内部DSL

ホスト言語自身で強力なDSLを記述できる、所謂「プログラム可能なプログラミング言語」。実装が楽な反面、内部言語に依存するため表現力に劣る。多分interfaceをインプリするのも広義で言えば内部DSL。

EX)Ruby on rails、Rakeとか

外部DSL

ホスト言語とは異なる言語で作成するDSL。DSL設計者が自由にフォーマットを作成することができるが、フォーマットをパースする「パーサ」という処理を書く必要があるため内部DSLよりは実装コストは高い。パーサっていうのは簡単に言うとこれがクラスで、これが予約語で~といった処理を書くのだ。

EX) Make,SQL,UML(UMLはグラフィカルに形式を表すという意味でLanguageになる)など

参考: 第1回 DSLとは? – gihyo.jp

Xtextについて

Xtextとは

Xtextとは、Eclipse上で動くDSL開発支援環境。言語を定義するとエディタを勝手に作ってくれるのが強み。定義を元にDSLエディタ、パーサ、言語モデル、ジェネレータまで作る。MDD(モデル駆動開発)に基づいているのじゃ。XtextはXtext本体の他に、Xtend(Java生成LL),MWE(パースやモデル変換をするエンジン),EMF(Eclipse Modeling Framework:あらゆるEclipseプラグインの基板)というフレームワーク及びエンジンが基板に乗っかっており、それらが組み合わさってDSLを生成している。

参考: Xtext入門 – Slideshare

具体的にどのように実装するか?

ごくごく簡単に言うと、

  1. EclipseでXtextプロジェクトを作成する。
  2. パーサを記述する。
  3. 実行するとEclipseがもう一個起動してその中で指定した拡張子を使ってやるとDSLが適用されている。

これだけ。

とりあえずは、ここまで。次からは実際に実装するべ。

結局レスポンシブデザインってなんだ

おはようございます。レモンです。

院試が間近に迫ってますが、まあたぶんなんとかなります。

今回の記事はほぼ雑談というかコラムというかテキトウな話です。レスポンシブデザインってなんじゃいと思ったことを書くだけなのです。

そもそもレスポンシブデザインとは

Webデザインの手法の一つで、様々な種類の機器や画面サイズに単一のファイルで対応すること。(IT-wordsより)

つまりは、HTMLはひとつにしておいてCSSの上書きとかでモバイルやタブレットにもいい感じに対応させようぜってのがレスポンシブデザイン(RWDって略すらしいです)なんだと自分は勝手に思っています。

このWordPressのテーマもRWDですよね。プロが作ったデザインだけあってしっかりしていると思います。

レスポンシブデザインについて思うこと

RWDは自分は思想的にはすごく合理的な考え方だなと初めて触れた時思いました。なるほど、確かにSEO的にも良いしHTMLを書く手間を減らすことができる。と。そして、PCとモバイルのデザインはあまり変わらないほうがユーザが混乱しない、というのも納得でした。同一のサイトであるという認識は確かに必要です。

RWDに対応したCSSフレームワークも徐々に定着しつつ有ります。BootstrapやFoundationなんかがありますね。特にBootstrapを自分は最近よく触っているのですがこれを使えば最低限のWebデザインはできるというのはデバイス対応も含まれてるなーと感じています。

実際にレスポンシブデザインでWebをデザインすると

さて、この合理的かつ効率的なRWDでありますが実際にデザインするとすごく難しいことが最近じわじわとわかってきました。

RWDの前のデザイン、つまりはPC版とモバイル版に分けるやり方だとそれぞれについてだけのデザインを考えれば良いのです。

PCは解像度に多少の違いがあっても横長のウィンドウで一度に多量の情報を表示できる。モバイルは縦長で一度に少量の情報しか表示できない。(正確に言うと多量の情報を入れると文字や画像が小さすぎて見てくれない)と言った違いがあるわけです。つまりはデバイスに合わせて情報量を取捨選択しながらレイアウトしていけばいいのです。ただし、モバイルとPCで齟齬がないようにjQueryなどを使って階層表示にしたりといった工夫がありました。確か、WikiPediaのモバイル版では見出しだけ表示しておいて必要な情報だけをタップで表示するといった方法を取っていたと思いますが、あれはそういうわけです。

しかし、RWDではこれを同じHTML上で考える必要があります。同じデザインでもこれがPCで表示されたらどうなるか、モバイルだと、タブレットだと?という考えを常に持ってレイアウトしていく必要があります。

PCでは見た目がよくってもモバイル表示にしてみると文字が多すぎてうんざりしたり、その逆ということもしばしばあります。同時にこれらのことを考えるデザインは先ほど述べた従来のやり方と比べてすごく手間を取る上、レイアウト上の制約も大きいです。意外に手間なんだなあと作ってみて感じるのでした。

レスポンシブデザインの使いドコロ

RWDを作ってみてきついと感じましたが、たぶんこれはコンテンツの量によるんじゃないかなとも思いました。量が多いとどうしても取捨選択が大変で情報の整理を同一HTMLで整理するのがつらくなります。

ただ、フォームやギャラリーサイトなんかの比較的コンテンツの量が多くない、多くても密集度や種類がそこまで多くなく整理がしやすいものであったらRWDはささっと作れそうな気がします。

だから、同一サイト内でもRWDの部分とPCとモバイルを分ける部分とがあってもいいのかなあと思いました。各ページに載せる情報を予め整理してここはRWDでいけそう、ここは分けたほうが辛くないみたいな話をしておいたほうがいいのかなあ、、BootstrapなどはGridシステムとかだけに使っちゃえばいいと思います。最悪visibleとhiddenを使って同じHTML内に2種類のレイアウトを用意するという力技もできなくはないですし。

ただし、デザインは極力合わせたほうがいいとは思います。せめてテーマカラーは統一しないと混乱します。たぶん僕も混乱します。

RWDにしろ、CSSフレームワークにしろデザイナや開発者が楽をするために開発されたものであるのだからこれに四苦八苦するのは本末転倒というものです。

ある程度融通を効かせて自分なりにテキトーに解釈してしまうのが精神衛生上も効率的にもいいんじゃないかなーと思った次第でした。

自分で書いててよくわからない文章になっちゃいましたが、まあコレで終わりです。現在RWDのせいでぐるぐる混乱してるので所謂愚痴と頭の整理でした。

自分のWebページのデザインを更新したよという話。

こんばんは、レモンです。

院試勉強からの現実逃避に自分のほとんど需要がないWebページのデザインを一新することにしました。
旧デザインはモノクロな感じのシックな感じに仕上げていたので今度はレモン色を使ったポップなデザインにしました。

旧デザイン↓

2014-7-22_4-25-54_25o-00

新デザイン↓

2014-7-22_4-29-40_29o-00

 

新デザインではBootstrapというCSSのフレームワークを使っています。
正確にはフレームワークじゃなくってデザインを補助するツール、という位置付けらしいです。

Bootstrapのリファレンスは非常に丁寧というか、コピペして中身を編集すればある程度のことができてしまうのでデザインの手間が非常に少なくなります。
ただし、その分デザインの個性が失われがちになるのであとでCSSを上書きしてあげないといけませんね。
上書きを行うにはBootstrapのCSSを読み込んだ後に自作のCSSを読みこませれば上書きができるようです。
ただ、classの数が尋常じゃない量あるためどこに何を加えれば変更されるかを特定するのが非常に手間です。

そのため、大きな変更を行う場合は予めBootstrapのカスタマイズページで変数を変更したCSSをダウンロードするのが賢いと思います。
自分はNavbarだけはどうしてもよくわからなかったのでそこだけいじったCSSをダウンロードしました。

もっと大きな変更をしながらデザインしたいという場合はLESSファイルをGithubから持ってきてコンパイルしつつするのが早いんでしょうね。
LESS(あるいはプラグインを使ってSASS)を覚えないといけませんが…今回はそこまでやってませんね。

さて、変更したデザインどっちが見やすいかなーと考えてますがなかなか他人に聞きづらいですねこういうのは…(^_^;)
一応「改善」をしたつもりなんですが「改悪」になってるとも限りません。
まあ、どっちにしろ誰が見るわけでもないページなので気軽に遊んで行こうと思います(`・ω・´)シャキーン

 

 

【Ruby】Clockworkを触ってみた

Ruby on Railsは基本的にはユーザの入力を受け取ってDBを操作、表示するのが主な仕事だと思ってるんですがどうしても定時処理が必要なことは多いと思います。

自分は予め用意されたDBをもとに一定時間ごとにDBの内容をTweetするような定時処理を作ってやりたいのですがcronにスクリプトを書いて直接DBをいじるのはやり方がよくわからない・・・ということでRubyのgemにClockworkというモノがあるらしいので少し触ってみました。諸サイトによると「Rubyのcronっぽいやつ」らしいです。

参考

今回ちろっとしか触ってないので詳しい説明はこっちのがよっぽどよい。

Qiita/Clockwork Cheat Sheet http://qiita.com/ogomr/items/27e9fc7af5b978b5ced6

Clockwork本家 https://github.com/tomykaira/clockwork

準備

とりあえずgemでclockworkをインストールしましょう。

$ gem install clockwork

最新版は0.7.7みたいです。

テスト

とりあえずどこでもいいので適当なrubyファイルを作成しましょう。ここではclock.rbとしてます。

まずは、clockworkをrequireしてあげてClockworkというモジュールを作ります。
後に、handlerというメソッドが提供されていますのでイテレータを使って呼び出すようです。(この辺がRuby不勉強で不明…

後に、everyというメソッドをhandlerのあとに呼び出してどういう間隔で処理を行うか、を指定します。
このeveryのあとにdoをつけてブロックをつけてあげると下のようにhandlerを使わなくても簡単に処理を書くことができます。

every(5.second, 'hoge.job') do
    p "Running!"
end

これを元になんとなくこんな感じで書いてあげると5秒毎に「second_job」という自作のメソッドを実行します。

require 'clockwork'

def second_job
	p "method_print"
end

module Clockwork

  handler do |job|
	case job
	when 'hoge.job'
		second_job
	end
  end

	every(5.second, 'hoge.job')

end

実行

実行をフォアグラウンドで実行してみる。

$ clockwork clock.rb

 

でおk。ログを残しながら実行をしてくれます。

ただし、通常はバックグラウンドでの実行が主になると思いますのでそのへんをまた研究が必要そうです。やり方自体は参考サイトを見よう。

Webデザインはじめの一歩

こんにちは、レモンです。台風やばいっすね、家に籠城がはかどりますわ。

ある人からWebデザイン教えろという圧力を受けましてスライド作ってみました。
とりあえずWebデザインしないといけないけど何からすればわからない!という方向けのスライドです。
対象は一応HTML,CSSがわかっている人向けですが技術的な話は殆ど無いので何言ってんのかわかんね~ってことは無いと思います。

もしお暇でしたら閲覧ください(`・ω・´)シャキーン

MacにEclipse all in oneの環境を作る

研究の関係でpleiadesの環境がMacに欲しくなったのでインストールしてみましたが、かなり詰まった…のでメモ@研究室

Mac用のpleiadesはないため、Windowsのpleiadesを落としてきて、dropin,plugins,featuresの中身をすべて移した。普通はこれだけいいらしいんだけどclean起動してもどうもエラーが出てくる。調べてみるとJStyleというWindows用のプラグインが悪さをしているらしい。JStyleとはエディタ強化用のプラグインで、フォントの調整や全角半角などの視覚化を行っているらしい。

ので、アンインストールをする

アンインストールするには以下の手順を踏む

1.plugins ディレクトリーの以下 jar ファイルを削除。
jp.sourceforge.mergedoc.jstyle_4.x.x.x.jar
org.eclipse.swt.win32.win32.x86_64_xxx.xxx.jar
org.eclipse.swt.win32.win32.x86_64_source_xxx.xxx.jar

2.plugins ディレクトリーの以下バックアップ jar をリネーム (末尾 .backup 除去)。
org.eclipse.swt.win32.win32.x86_64_xxx.xxx.jar.backup
org.eclipse.swt.win32.win32.x86_64_source_xxx.xxx.jar.backup

(ここで元々のエディタの設定ファイルを戻している)

この辺の設定はここからzipを落としてきて中のhtmlを読むと分かった。