作成者別アーカイブ: ベッチ

ベッチ について

世の中のIT企業の開発動向にアンテナをはりつつ、良いものは社内に取り込んで行こうと日々努力しています。

10分でELKスタックを構築してみる

タグ: , , | 投稿日: 投稿者:

満員電車の時はとなりにハイヒール女子がいない事を確認しておきましょう。電車が揺れた時に痛い目をみます。

ベッチです。

今回はログ収集・解析・可視化についてです。

もはやデファクトとなったELKスタックをローカルマシン(ただしこの記事での説明はMacに限ります)に10分で構築します(コマンドは数回実行するだけです)。

ELKスタックとはElasticsearch社のElasticsearch(解析) + Logstash(収集) + Kibana(可視化)の3つの製品の総称です。 

順番的にはLEKの方がしっくりくると思うのは自分だけでしょうか。

ちなみにLogstashのかわりにfluentdを使うパターンがEFKスタックと呼ばれるものです。

それでは早速構築していきます。

もちろん10分で構築するのですからアレを使う前提です。 そうですコレです。

  • Boot2Docker
  • docker-compose

コレの環境は今の時代当然インストール済みであると思っているので特に説明しません。

ソースはGithubにあがっている以下を利用します。

https://github.com/deviantony/fig-elk

上記ソースを利用して構築されるELKのバージョンは現時点でそれぞれ以下の通りです。

  • elasticsearch 1.5.0
  • logstash 1.4.0
  • kibana 4

1.fig-elkをクローンする

git clone git@github.com:deviantony/fig-elk.git
cd fig-elk

2.logstash.confにfilterを追加

これ追加しとくとApacheのログ収集する時にいろいろと分析しやすくなります。

# 修正対象ファイル logstash-conf/logstash.conf

input {
    tcp {
        port => 5000
    }   
}

# Add your filters here
filter {
    grok {
        match => { "message" => "%{COMBINEDAPACHELOG}" }
        break_on_match => false
        tag_on_failure => ["_message_parse_failure"]
    }   
    date {
        match => ["timestamp", "dd/MMM/YYYY:HH:mm:ss Z"] 
        locale => en
    }   
    geoip {
        source => ["clientip"]
    }   
    grok {
        match => { "request" => "^/%{WORD:first_path}/%{GREEDYDATA}$" }
        tag_on_failure => ["_request_parse_failure"]
    }   
    useragent {
        source => "agent"
        target => "useragent"
    }   
}

# Must use http protocol and specify the host to use Kibana4
output {
    elasticsearch { 
        protocol => "http"
        host => "elasticsearch"
    }   
}

3.docker-compose upする

最後に以下を実行すればELKのそれぞれのコンテナが起動し始めます。(※初回のみコンテナイメージのダウンロードで時間かかります。10分で構築するという部分の9割がここに時間使います)

docker-compose up

kibanaが起動してきたら完了です。念のためコンテナのプロセスを確認しておきます。(折り返しちゃってみずらいですが)

$ docker ps
CONTAINER ID        IMAGE                                 COMMAND                CREATED             STATUS              PORTS                           NAMES
f42553439266        deviantony/elk-logstash:latest        "/opt/logstash/bin/l   About an hour ago   Up About an hour    0.0.0.0:5000->5000/tcp          figelk_logstash_1        
d5697254c482        deviantony/elk-kibana:kibana3         "nginx -g 'daemon of   About an hour ago   Up About an hour    443/tcp, 0.0.0.0:8080->80/tcp   figelk_kibana3_1         
0f9a20c87f6e        deviantony/elk-kibana:latest          "/entrypoint.sh"       About an hour ago   Up About an hour    0.0.0.0:5601->5601/tcp          figelk_kibana4_1         
810736bac50d        deviantony/elk-elasticsearch:latest   "/usr/share/elastics   About an hour ago   Up About an hour    0.0.0.0:9200->9200/tcp          figelk_elasticsearch_1   

これで環境構築は完了です。

それでは実際に動きを確認してみます。

以降にでてくるboot2docker-ip-addressという部分はboot2dockerのIPに便宜変更して下さい。

以下で確認できます。

boot2docker ip

4.ローカルマシン上でApacheのログファイルをLogstashへ送る

サンプルとしてなんでも良いので適当にApacheのログファイルをLogstashへ読み込ませてみます。

以下を実行するだけです。(※access.logのファイルパスは便宜変更して下さい)

nc boot2docker-ip-address 5000 < access.log

5.Elasticsearchにインデックス化されているかを確認する

確認する前にelasticsearchに「elasticsearch-head」というプラグインをインストールしておきます。

インストールしておくと実際にデータがelasticsearchにインデックスされているかどうかの確認ができるWebインタフェースが利用できます。

docker exec -it b483227414d0 bash
cd /usr/share/elasticsearch
./bin/plugin install mobz/elasticsearch-head

ブラウザで以下へアクセスする。

http://boot2docker-ip-address:9200/_plugin/head/

以下のような画面が表示されてインデックス状態がわかります。 

elasticsearch-head

ちなみに「Bison」って書かれているのがnode名です。 指定しないと自動的にMARVELヒーローの誰かの名前になります。

今回はBisonってなってます。知りません。

6.お待たせしました、最後にKibanaで確認します

ブラウザで以下にアクセスします。

http://boot2docker-ip-address:5601

すると最初は以下の画面が表示されます。

Settings_-_Kibana_4

「Time-field name」を@timestampにして「Create」ボタンをクリックして下さい。

すぐさまSettings画面に遷移しますが、Discover画面に遷移して下さい。

すると単純な棒グラフが表示されると思います。

Discover_-_Kibana_4_と_iOS_Certificates_-_Apple_Developer

表示されない場合は画面右上のTimeFilterを今回インデックスしたログファイルのタイムスタンプの範囲にすると表示されるはずです。

これでいろいろ触りながら確かめる環境ができました。

実際にはこのVisualizeの画面で可視化したいデータを選んでグラフつくって保存してっていうのを繰り返してDashboardでみるという流れになるので好き勝手にいろいろいじり倒してみて下さい。

それでは。

 


とりあえず15分でAnsible体験してみる話

タグ: | 投稿日: 投稿者:

 

こんちにはベッチです

今回はAnsibleをとりあえず体験してみよう!というのがテーマです。

Ansibleとは

  1. Pythonで記述された構成管理ツール
  2. ここ数年で人気がでてきている
  3. サーバ側はsshができてpython2.6以上が入っているという条件だけで使える優れもの


デブサミ2015でもGMOインターネットさんがAnsible使って開発環境構築の効率化していますなんて話してました。

このままいくと「Andibleかー。なんか便利そうだなー」なんて話で終わってしまうのでとりあえず体験してみましょう。
15分あれば十分な内容です。

15分でAnsible体験する手順

Mac環境前提で進めます。

1.まずはAnsibleをインストールして下さい。

brew install ansible


※事前にHomebrewはインストールしておいて下さい。(詳細は省きます)


2.Ansibleのインベントリファイルに対象サーバを登録します


※インベントリファイルとはansible用のhostsファイルだと思って下さい

インベントリファイルパスは以下となっているはずです。
 

/usr/local/etc/ansible/hosts

内容は以下のように1行追加して下さい。(example.jpはホスト名、192.168.11.100は対象のサーバのIPですので便宜変更して下さい)

example.jp ansible_ssh_host=192.168.11.100


3.pingを送信したらpongが返ってくる確認をしましょう

ansible example.jp -u [SSHユーザ名] -k -c paramiko -m ping


※ここでは「-c paramiko」は深く考えずにおまじないだと思って下さい。

成功すればjson形式で以下の内容が出力されます。

192.168.11.100 | success >> {
    "changed": false, 
    "ping": "pong"
}

4.もういっちょサーバ情報も一気に取得してみましょう

ansible example.jp -u [SSHユーザ名] -k -c paramiko -m setup

成功すれば対象サーバの情報がjson形式でズラッと出力されます。


ここまでくるとちょっと面白くなってきませんか?
実際にはPlaybookというファイルを作成してサーバの定義をしていくかたちになります。

参考までに自分なりのAndsibleの勉強方法は以下の通りです。

1.Kindleのこの本をとりあえずサラッと読む(サラッとが大事です。まずは大枠をつかんでください)    

2.やりたい事を公式ドキュメントを確認しながら実際にやってみる

<公式ドキュメント>

http://docs.ansible.com


どうでしたか?
とりあえずAnsibleに限らず「なんかよさそうだなー」と思ったら実際にやってみて感覚をつかむ事が大事だと思います。

 

 


GitLab7.1.1でGitHub Flowを実践してみた!

タグ: , | 投稿日: 投稿者:

こんにちは。

最近はもっぱらチーム開発を効率よくできる仕組みを考える事に必死なベッチです。

そんな時に電車でいろいろ調べていたら以下のスライドをみつけました。

少人数チームにおけるプロジェクト管理のベストプラクティス

このスライドでは以下の2つの事を実践する事で品質が向上すると提唱しています。

  1. コードの強制自動テスト
  2. プログラマ同士のコードレビュー

最近開発チーム内でもコードレビューの必要性について議論されてきているのでこのタイミングで開発フローにのせれるように検証してみようと考えました。

ただし「1.コードの強制自動テスト」を強制するのは現場が混乱するのでとりあえずは保留にしておきます。

スライドではRedmine、GitLab、Jenkinsを使った開発フローが紹介されていますが、いきなり全てを連携してというのは無理なので、まずは「2.プログラマ同士のコードレビュー」を実現する為にGitLabを使った「GitHub Flow」を実践してみようというのがこの記事の本題です。

GitHub Flowについてはググればいくらでもでてきますが簡単に説明すると以下のフローになります。

  1. 作業をする時はmasterブランチからトピックブランチを作成する
  2. ローカルで作業、コミット、pushをする
  3. Pull Requestによって誰かにコードレビューを依頼する
  4. コードレビューで問題ない事を確認後、masterブランチにトピックブランチをマージする
  5. 即時にmasterブランチをプロダクション環境へデプロイする

なお、GitLabではPull Requestという名前ではなくMerge Requestになっていますが機能はほぼ同じだと思います。

それでは最新のGitLab7.1.1でGitHub Flowを実践したいと思います。

以下、長くなりますが結論から言うと問題なく実現できました。

ストーリー

地球に挨拶をする(「Hello, Earth!」という文字列を表示する)プログラムがあります。
今回、さらに宇宙にも挨拶をする機能を追加して下さい。

登場人物

  • 開発者A(開発担当者)
  • レビュアB(開発者Aのコードのレビュー担当者)

手順

1.作業をする時はmasterブランチからトピックブランチを作成する

この作業をするのは開発担当者なのかプロジェクト管理者なの かはそのチームで決めておく方が良いと思います。

GitLabにて対象のプロジェクトを選択後、「Commits」をクリックします。

1-1

現在masterブランチだけなのでブランチ数が「1」となっていますが、この「Branches」タブ部分をクリックします。

1-2

「New branch」ボタンをクリックします。

1-3

トピックブランチ名と、元のブランチを選択して「Create branch」ボタンをクリックします。

トピックブランチの名前は他の開発者がみてもあなたが何の機能を実装しようとしているか、どんなバグを修正しようとしているか一目でわかるようにします。
これは自分自信にとっても、何の機能を実装すべきかを明確にしてくれるので非常に有益です。

元のブランチはGitHub Flowでは必ず「master」ブランチとなります。

1-4

トピックブランチが作成されている事を確認します。

1-7

2.ローカルで作業、コミット、pushをする

開発者Aはトピックブランチをローカル環境にpullし、チェックアウトします。

トピックブランチ上で要件を実現する為の実装作業を行います。

ここで大事なのは以下の2点です。

  1. トピック以外の作業は絶対にコミットしない事
  2. レビュアや他の開発者の為に意図が伝わる粒度でコミットする事

 

3.Pull Requestによって誰かにコードレビューを依頼する

開発担当者はコードレビューを依頼する前に一度リモートリポジトリにpushしておきます。

push後、該当プロジェクト画面の「Commits」をクリックし、コミット一覧画面で「Compare」タブをクリックします。

4-1

差分を確認し、問題なければ「Make a merge request」ボタンをクリックします。

4-3

マージリクエスト画面が表示されるので以下の項目を入力して「Submit merge request」ボタンをクリックします。

  1. タイトル
  2. 概要
  3. 担当者(レビュア)
  4. マイルストン(今回は使用しない。GitHub Flowでは不要かも)

後から気づきましたが、ここで入力した内容はmasterブランチにマージする際のデフォルトのコミットメッセージとなります。

よって、このトピックブランチでどんな変更が加わるのかという内容を簡潔に記載するのが適切でしょう。

つまり以下のような「レビュー依頼」というタイトルは間違いですので注意して下さい!

4-4

マージリクエスト完了です。

※マージリクエストを行うまでのフローはこの他にもあります。

4-5

レビュアBはマージリクエスト申請のメールを受信したので確認をします。

「Changes」タブをクリックする事でソースコードの差分が確認できます。

4-6

4-7

サイドバイサイドでの差分確認も可能です。

4-7-a

レビュアBがソースコードを確認したところ、指摘事項があったので開発者Aに対してコメントを送信します。

4-8

4-9

開発者Aは該当のマージリクエストにコメントされた旨のメールを受信したので内容を確認します。

4-10

開発者Aはコメントの内容にもとづいてソースコードを修正し、コミット、pushします。

push後、対象のマージリクエストでコメントを入力します。

4-10

レビュアBはコメントを受けてソースコードを確認します。

4-11

レビュアBは意図したものと違うコードがあがってきたので指摘をしようと思いましたが、リリースまでに時間がなかった事と、その内容が軽微なものであったので自分自身で修正する事にしました。

「Edit」ボタンをクリックする事で画面上から直接修正し、コミットが可能となります。

4-12

コミット完了です。

なんか画面上でソースコード修正してコミットまでするのって変な感じです。

実際はあまり利用しないでしょうが、GitLabの機能紹介という事でやってみました。

4-13

その後、開発者Aはふと気づいた事があるのでソースコードに対してコメントしました。

※GitLabはソースコードの該当箇所にたいしてもコメントが可能です。

4-14

レビュアBはその内容を確認して再度自分自身で修正、コミットし、その旨コメントしました。

4-15

 

4.コードレビューで問題ない事を確認後、masterブランチにトピックブランチをマージする

リリースできる状態となりましたのでレビュアBはmasterブランチに今回のトピックブランチをマージします。

該当のマージリクエスト画面にある「Accept merge request」ボタンをクリックします。

 

4-16

問題なくマージができました。

4-18

 

5.即時にmasterブランチをプロダクション環境へデプロイする

プロダクション環境へのデプロイ方法についてはまだ未検討です。

製品にもよりますが、最終形はDockerを利用したブルーグリーンデプロイメントが理想なんじゃないかと思ったりしています。

弊社ではこの部分についてはまだ当分手動になりそうです。

 

今後はRedmineとの連携、その次はJenkinsとの連携をやっていきます。

 


FuelPHPで管理画面のベースを爆速で作成してみる

タグ: , | 投稿日: 投稿者:

こんばんは、ベッチです。

タイトル通り、FuelPHPで管理画面のベースを爆速で作成してみたいと思います。
Mac前提ですので、Windowsの方は便宜読み替えて下さい。

1.まずはoilコマンドをインストールします。

※CakePHPでいうbakeコマンドみたいなものです。

curl get.fuelphp.com/oil | sh

2.oilコマンドを使ってFuelPHPプロジェクトを作成します。

プロジェクト作成には思ったより時間かかりますので気長に待って下さい。

oil create SampleSite

作成されたFuelPHPプロジェクト内のpublicディレクトリをドキュメントルートにしてアクセスするとちゃんと画面が表示されます。

fuelphp1

3.データベース設定を書き換えます。

ファイルは「fuel/app/config/development/db.php」です。
デフォルトでは以下となっていますが、ご自分の環境に合わせて便宜変更して下さい。

<!--?php /**  * The development database settings. These get merged with the global settings.  */ return array(     'default' =--> array(
        'connection'  => array(
            'dsn'        => 'mysql:host=localhost;dbname=fuel_dev',
            'username'   => 'root',
            'password'   => 'root',
        ),
    ),
);

4.アプリケーション設定ファイルを書き換えます。

ファイルは「fuel/app/config/config.php」です。
always_loadにてauthとormを有効にします。

/**************************************************************************/
/* Always Load                                                            */
/**************************************************************************/
'always_load'  => array(
     'packages'  => array(
        'auth',
        'orm',
     ),
),

whitelisted_classesにてValidationを設定します。

'whitelisted_classes' => array(
    'Fuel\\Core\\Response',
    'Fuel\\Core\\View',
    'Fuel\\Core\\ViewModel',
    'Fuel\Core\Validation',
    'Closure',
),

タイムゾーンを設定します。

'default_timezone' => 'Asia/Tokyo',

5.SimpleAuthライブラリの設定を変更します

ファイルは「fuel/packages/auth/config/simpleauth.php」です。
グループ設定を有効にします。

'groups' => array(
    -1 => array('name' => 'Banned', 'roles' => array('banned')),
    0 => array('name' => 'Guests', 'roles' => array()),
    1 => array('name' => 'Users', 'roles' => array('user')),
    50 => array('name' => 'Moderators', 'roles' => array('user', 'moderator')),
    100  => array('name' => 'Administrators', 'roles' => array('user', 'moderator', 'admin')),
),

6.ユーザモデル、ユーザテーブル、ユーザアカウントを作成します

以下のコマンドでユーザモデルが自動的に作成されます。

oil generate model users username:varchar[50] password:string group:int email:string last_login:int login_hash:string profile_fields:text
	Creating model: /Volumes/DATA/DocumentRoot/SampleSite/fuel/app/classes/model/user.php
	Creating migration: /Volumes/DATA/DocumentRoot/SampleSite/fuel/app/migrations/001_create_users.php

上記で作成された「fuel/app/migrations/001_create_users.php」からユーザテーブルを作成します。

oil refine migrate
Performed migrations for app:default:
001_create_users

次に実際のユーザアカウントを作成します。

oil console
Fuel 1.1-rc1 - PHP 5.3.6 (cli) (Sep  8 2011 19:31:33) [Darwin]
>>> Auth::create_user('admin', 'password', 'demo@example.com', 100);
1

Ctrl+Cでぬけて下さい。

7.管理画面用のビューを作成

管理画面用のビューを作成するのですが、管理画面で操作する用のモデルを1つつくらないといけないのでとりあえずpostsというダミーのモデルを作成します。
この過程で管理画面のビューが作成されます。(存在していれば作成されません)

oil generate admin posts title:string slug:string summary:text body:text user_id:int

8.管理画面にアクセスしてみましょう

/adminにアクセスすると以下のようになります。

Login

ちゃんと認証画面が表示されました。

6で作成したアカウントでログインできます。

この後はCakePHP同様oilコマンドを利用する事でCRUD画面は即座に作成できます。

FuelPHPはCodeIgniterの派生系なので使い勝手良さそうです。

これからちょっとずつさわってみようかと思います。


UISwitchのOn/Offにオリジナル画像の設定ってできないのね

タグ: | 投稿日: 投稿者:

こんにちは。

最近またiOSアプリにどっぷりつかり始めて「おっ、やっぱりiOSアプリ楽しいじゃん」って思ってる脂がのって水がはじいちゃうベッチです。

iOS7からUISwitchの見た目が変わりましたね。これ結構好きです。

uiswitch

このUISwitch、アトリビュートインスペクタで確認すると「On Image」「Off Image」っていう項目があるので画像設定できるのか!って思ってワクテカで設定してみました。

・・・・・

・・・・・

実行しても変化なしです。アトリビュートインスペクタで設定した画像が表示されません。

とりあえずUISwitchの公式リファレンス確認しました。

「iOS7では効果がない」って書かれていました。

そんな事あんの?!って思っちゃいましたよ。

プロジェクトのDeployment TargetがiOS7.1になってんだからアトリビュートインスペクタの「On Image」「Off Image」は消しといてよって感じです。

という事でiOSのバージョンがあがって使えなくなったプロパティでも設定だけはできるっていうケースがあるので今後気をつけたいと思います。

え?何が悪いの?でも設定できるんだからどうにかすれば表示できるよね?っていろいろやってみて時間を浪費しないようにしましょう。

時は金なりです。


Mac SafariのアドレスバーでReturnする前にリクエスト送信される件

タグ: , | 投稿日: 投稿者:

春うらら。

こんにちはベッチです。

MacユーザでSafariを利用されている方!

アドレスバーで直接URLを入力した時、Returnで確定する前にWebサーバにリクエストが送信されてしまっていた事に気づいていたでしょうか。

リクエストは送信されますがレスポンスで返ってきたhtmlはReturnで確定するまでブラウザに描画されないのでWebサーバのアクセスログをリアルタイムでみていないと気づかないんですけどね。

何が言いたいかというと、Webアプリ開発時に直接URL入力して検証したりする時に途中でキーボード入力をとめるとその段階のURLでリクエストが送信されたりしてすごいうざいんです。

で、その問題がようやくなおったとの事なんですが・・・

App_Store

私のマシンでは未だに問題が解決しません。

で、改めてSafariの設定をみたらあやしいところがあったので設定変更したら解決しました。

プライバシー

同じ悩み抱えていた方は設定を確認してみて下さい。


スニペットつかおーよ

タグ: | 投稿日: 投稿者:

こんばんはベッチです。

今日はMacユーザ向けにオヌヌメのスニペット管理アプリの紹介です。
※Windowsとかは知りません。自分で探して下さい。

【スニペット管理アプリ】
Snippets

スニペット使っていない人は、スニペット管理アプリを使うと作業効率が格段にあがります。

<スニペットとは>
翻訳すると「断片」という意味です。
うん、全然わからないですね。
ここでいうスニペット管理とは、具体的にいうとプログラムを書いていてよく使うコードってありますよね?
これらの断片的なコードを登録し、使いたい時にすぐに引き出せる状態にする事をいいます。

sniptgistみたいなWebサービスで管理するという方法もありますが、ローカルのアプリで管理した方が必要な時の引き出しやすさが断然あがります。

登録済みのスニペットを探す場合、Mac OSのメニューバーにある本アプリのアイコンをクリックすると検索パネルが表示されるのでキーワードを入力するとヒットしたスニペットの一覧がズラッと表示されるので、目的のスニペットをクリックすると現在アクティブになっているアプリ内にそのテキストが貼付けられます。

この検索パネルの表示にはショートカットキーを割りあてられるので、キーボードだけで作業すると神になれます。

ちなみにスニペット管理はコードしか登録できないわけではなく、文字列なら何でも良いので、例えばメールとかでよく使う文言を登録するとかなり便利です。

こんな説明を聞いているより実際に使ってみたら相当便利ですので是非使ってみて下さい。

有料ですが今なら半額です!

スクリーンショット 2014-03-29 1.33.59


デブサミ2014 〜1日目〜

タグ: , , | 投稿日: 投稿者:

こんにちはベッチです。

昨日はデブサミ1日目でした。

まずはChefのセッション

私自身はOpsの人間ではなくDevの人間なのですがChefについては関係なくもないので参加しました。
DevOpsの時代ですし。
別のセッションでサイバーエージェントのフロントエンジニアの方も自分のドメインに固執するのではなく「越境しよう!」って言ってたなー。
良いサービスを作るには必要な事ですよね。
クックパッドさんもSalesとDevとOpsで1チームをつくって各部署の境をなくしたかたちでプロジェクトを進行しているそうです。

で、Chefの話ですが今回のセッションはGREEさん。

相当数あるサーバにChefを導入する場合、Chef Serverで一元管理するのが常套手段だと思っていたのだけど、GREEさんは自社のサーバ管理システムと役割が重複するという事でChef Serverを使わずにChef Bridgeという独自でつくった簡易Chef ServerみたないものとChef Soloで運用しているとの事だった。

あと、クックブックの内容は以下のツールを使用して結構しっかりとテストしているみたい。

  • serverspec/Test Kitchen(ブラックボックステスト)
  • chefspec(ホワイトボックステスト)
  • Foodcritic(Lint)

サーバの設定がテストできるってよく考えたら斬新。
Chefによって冪等性の確保ができるというのは、サーバ設定を属人的にさせない手段としては良いいですよね。

ちなみに参加された方の中で実際に業務でChefを利用しているのは1割程度でした。

次にherokuのセッション

基本的にサービス紹介でした。
なんでも今後force.comのデータとの連携ができるようになるとの事でした。
ただ、基本的にRailsアプリ作る時に使うくらいでしか今のところお世話にならないだろうなと、自分は。

最後はサイバーエージェントさんのフロントエンジニアの方のセッション

「え、ちょっとフロントやること多すぎじゃない!?」っていう事でしたが、やること多すぎなのはフロントエンジニアだけじゃないだろと思いつつも、現場のあるある的な話がちょっと面白かった。
で、その「やる事多すぎ」な状況をいろんなツールを使って解決しようとしてきた結果最終的に今はGruntとJenkins使って落ち着いてるとの事。
弊社ではGrunt使うほどまでフロントごりごり系案件はあまりないですが、個人的に使ってみたいツールではあるかな。
余談話として、プロジェクトによってはプロデューサーが女子のところがあるそうです。
というか男女比が6:4の会社ですからそんなプロジェクトはざらで、そういう位置づけにいる女子は俗にいうキラキラ女子ってやつです。
そのキラキラ女子の中には、金曜日当日に本番リリースをぶっこんでくるギラギラ女子もいるとの事でした。
「もう広告うっちゃいましたよー❤」っていって。
仲がいいんですね。

総括として他の会社の現場の事がわかったり、同じ事で悩んでたりするなーっていうのを感じれたのが良かったと思います。


プロジェクト管理ツールとかの話

こんばんは。
たまには誰からも邪魔されずに1つのプロジェクトにがっつりのめりこんだ開発をしたいなと思っているベッチです。

今日はプロジェクト管理ツールの話です。

弊社ではプロジェクト管理ツールとしてRedmineを使っています。
最近、1.4から2.3にアップデートしました。

アップデートというよりも、開発していく上で便利なプラグインが最初から入っているalminiumをインストールしました。

https://github.com/alminium/alminium

この時に、1.4のsqliteから2.3のmysqlへのデータ移行でうまくmigrationできなかったので手動で移行しました。
休日丸1日かけて・・・

苦労した甲斐もあってなんとか移行できましたが、若干データ移行がミスってますww。
ま、影響少ない部分だからいっか。

前置きはさておき、一番使いたかったのがredmine_backlogというスクラム開発用のプラグインです。

https://github.com/backlogs/redmine_backlogs

ストーリーやタスク、スプリントの管理、かんばんの表示/更新がRedmineで使用できます。

使ってみると若干融通がきかない事もありはがゆかったりします。

で、今回のRedmineの移行で何度かエラーが出た時にソースを追っていく過程でRailsに慣れ始めてきたのでこの勢いでRailsを使えるようにしてRedmineを使いやすく改修していくぜ!っていう目標をたてたりたてなかったり。

あと、実は裏でJenkinsを動かしているのでRedmineやGitと連携して開発を効率よくまわしてやるぜ!っていう目標をたてなかったりたてたり。

そんな事を考えているうちに来週末はデブサミが始まったり始まらなかったり。

http://event.shoeisha.jp/devsumi/20140213/

2日とも行きます。

それでは良い週末を。


extorage APIを公開しました!

タグ: , | 投稿日: 投稿者:

あけましておめでとうございます、ベッチです。

早速ですが、弊社のサービスであるextorageをご利用のお客様向けにAPIを公開致しました。

[extorage API] http://extorage.fairway.ne.jp/doc/

まだまだAPIとしては使いづらい部分もあるかと思いますが、是非ご利用ください。

今後ともextorageをよろしくお願いします。