GoogleAppsScript勉強会に行って来ました

GDG京都さんとKyotoGASさんが主催する勉強会に行って来ました。
正直なところ今更感、漂う感じの記事ですが気にしないでください。
実は、用事があって関西に行っていたのです。

以下にメモを記載します。。。

GASとは


大雑把に言うとMSOfficeのVBAみたいなもの

  • JS 1.8Base(既存のJS資産が使える)
  • サーバサイド実行
  • Googleのサービスと連携できるAPIがいっぱいある
  • GoogleAppsの拡張
  • Advanced Google Serviceが利用(API Keyが必要)
  • Charts(グラフ)
  • JDBCでクラウドSQL利用可
  • ウェブアプリケーションの作成が可能
  • スクリプトトリガーで、任意or一定間隔でスクリプト実行できる
制限

主にあげられる制限

  • メールの本数など(GoogleAppsのユーザーや一般ユーザーの違いなど)
その他

  • GAEよりもお手軽にできる
  • ソースの共有(ソースの共有を設定していれば)
  • GAEよりも制限がゆるい

AppsScriptとクラウドBPM


  • GASの学習コストは低い
  • GAS自身に足りないところはSpreadSheetで補う(最適な方法)
  • サーバ処理、クライアント処理の連携がよい

連携例

1.Sheetでマスタ管理

(連携例) サイト<->GAS(処理を実施)<->SpreadSheat

JSONPでデータを返してやればサイト側でJS処理をするだけでよい

問題

  • JSとGASお通信でクロスドメイン問題
  • ブラウザの設定だけでやると戻すデータがカラになってしまう
2.リアルタイム集計

(連携例) サイト<->GAS(処理を実施)<->SpreadSheat

データ送信してSheetで集計

3.帳票出力

(連携例) サイト<->GAS(処理を実施)<->SpreadSheat

SpreadSheetを利用して、帳票を出す

4.一括処理

(連携例) SpreadSheetからGASに投げ、GASからサイトのAPIを実行する

定期実行をするようにしてやる

5.Googleカレンダー連携

  • キーワードをGASで取得してやる
考慮点

  • セキュリティ(サーバからアクセスするので、GoogleApps認証ができない、Keyというパラメータをもたせる)
  • 運用監視(ログをspreadSheetへ)
  • エラーの発生を極力回避するようにする
GASを使用していて困るところ

  • ソースコードの構成管理
  • httpリクエストのデバッグ(実際に手動で実行してみてリクエストを送信するしかない)
  • IP制限がない
  • 予期せぬエラーが出た場合の対処

GoogleAppsScriptを積極活用


GAS+SpreadSheetがすごいという事例紹介 特に以下がやりやすい

  • GASで勤怠管理
  • 集客ツール
勤怠管理

  • SpreadSheetをDBのように扱う
  • SpreadSheetの変更管理が大変(ユーザーが大変)
  • 受託ではやらないほうがいいかもしれない。(予期せぬ問題が起きたときの解析などが大変)
  • プログラムが得意ではない人でもGASは使いやすい(Excelユーザ向け)
  • 各種GoogleServiceとの連携に向いている

GoogleAppsScriptの新機能


GoogleAppSAPIは以下の使用方法がある

  • DATA API
  • AppsScript

GAE vs GAS

  • 速さGAE
  • 柔軟GAE(なんでもできる)
  • お仕事GAE(GASは不安定)
  • お手軽GAS(GAEよりも圧倒的に楽にアプリが組める)

GAS

  • Forms + GAS
  • Documents + GAS
  • new UI Component(Dialog,sidebar)
  • GoogleDriveIntegration

新しくFormsにToolsというメニュー項目が追加

GASからフォーム作る

ソースから新しくFormを作成するソースコード

  • フォームの作成
  • メールの送信
  • ログ出力
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function myFunction{
    // 空のフォーム
    var form = FormApp.create("アンケートひな形").setDescription("アンケート用のフォームです");    
    //入力フォーム
    form.addtextItem().setTitle("Email")
    // 1-5までのラジオボタンを作る
    form.addScaleItem().setTitle("評価").setBound(1,5).setHelpText("1..5");
    //  自由入力欄
    form.setParagrapheTextItem.setTitle("")
    // メールの送信
    MailApps.sendEmail("宛先","本文")
    // 公開用のアドレス
    Loger.log(form.getPublishedUrl())
    // 編集用のアドレス
    Loger.log(form.getEditUrl())
}
Document + GAS

  • 文章の構造化(DOM構造みたいにItemとか)を制御できるようになった
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
function myFunction{
    //ドキュメント本体
    var body = DocumentApps.getActiveDocument().getBody();
    // インデックス
    body numChild = body.getNumChild();

    var i = 0,chld,type,hending,html="<div>";
    for(;i<numChild;i++){
        //  子要素
        child = body.getChild(i)
        type = child.getType()

        if(type == DocumentApps.ElementType.PARAGRAPH){
            heading = child.getHeading()
            // 不要なHeadingが付いている。これは、文章自身もパラグラフと認識されてるためだったっけ(?)
            if(heading != DocumentApps.ParagraphHeding.Normal && child.getNumChild() > 0){
                Logger.log(heading +" "+child.getChild(0).getText() )
                html + ="<p>" +heading +" "+child.getChild(0).getText()+"</p>" 
            }
        }
    html +="</div>"
}

ダイアログ表示

1
2
3
4
function showDialog(){
    var ui = HtmlService.createHtmlOutput(myFunction()).setWidth(400).setHeight(300)
    DocumnetApps.getUi().showoDialog(ui)
}

サイドバー表示

1
2
3
4
function showSideBar(){
    var ui = HtmlService.createHtmlOutput(myFunction()).setWidth(300)
    DocumnetApps.getUi().showSideBar(ui)
}
DriveSDKを使う

以下のようなコードでGoogleDriveを操作できる

  • ファイル名取得
  • ファイルをゴミ箱へ送る
  • ファイルへアクセス権を追加
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
function drive(){
    // ファイル検索
    // 結果はイテレータで帰ってくる
    var fails = DriveApp.searchFiles("title contains","検索ファイル")
    var file
    while(fails.hasNext()){
        file  = fails.next();
        // ファイル名を取得する
        file.getName()
        try{
            // ファイルをゴミ箱へおくる
            // 権限がないとエラーが出るかも
            file.setTrash(true)
            // 権限を追加(Owner権を追加)
            file.setOwner("追加するユーザー")
        }catch(e){
        }
    }
}
質問

  • 補完は出ないときは、一回保存して開き直すとかで対処(リファレンス読み直せばいい)
  • GASでプレゼンテーションは操作できない(予定もない)
  • GASで作ったファイルはドライブに保存される
  • FormはSpreadSheetにプログラムでひもづけることもできる

削除してしまったDropboxのデータを復元する

簡単な経緯


このブログ記事を書くキッカケになった内容を以下に記述します。

お馬鹿すぎて笑えますwww

  1. Dropboxアプリ起動
  2. アプリを起動したまま、あるコマンドを実行
  3. Dropboxと同期したディレクトリが2で実行したコマンドで削除される
  4. 1のDropboxアプリが削除した状態を同期開始
  5. 削除だけなので、同期が一瞬で終わってしまう
  6. Dropboxサーバのデータが削除

こんな感じでした・・・ 実際は、Dropboxのディレクトリだけでなくもっと影響がでかくて涙を流しています。

復元の手順


復活の呪文を唱えるにも条件があります。

削除してからの日数が30日以内であれば、復元可能

というものです。

幸いなことに削除した次の日に気がついたので、自分はこの条件を満たしていました。

で、肝心の復元の手順ですが、以下で実施します。

  1. Dropboxのウェブサイトにログイン
  2. 画面右上の「削除済みファイル」をクリック
  3. ファイル名の横に表示されている逆三角を押下し復元をクリック

公式の手順

これで削除したファイルが復元できます。

RubyのStructクラスが便利

特にちょっとしたデータ構造を作成したいときなんかは非常に有効な手段かも

Structクラス


Rubyの組み込みクラスです。(Classに比べて影が薄いですが・・・)

平たく言うと、Classクラスに似ているものです。

じゃー違いは何なの?ってなります。

  1. newしたとき、引数で指定したアクnセッサをもつクラスを生成する
  2. 第一引数の文字列がクラス名となるが、指定がない場合は無名のクラスになる

これだけ。

1
2
3
4
Point = Struct.new("Point", :x, :y)
item = Point.new(100,200)
p item => #<struct Struct::Point x=100, y=200>
p item.x => 100

無名クラスだと、こんな感じ

1
2
3
4
Point2 = Struct.new(:z)
Point2.class => Class
item2 = Point2.new(300)
p item2 => #<struct Point2 z=300>

ドキュメントに無い機能


ブロックを使うことができることです。
ブロック内では、独自のメソッドを定義することができます。

こんな感じです。

1
2
3
4
5
6
7
8
9
10
11
Point = Struct.new(:x, :y) do
  def sum
        x + y
  end

  def minus
        x - y 
  end
end
p Point.new(600, 700).sum => 1300
p Point.new(800,900).minus => -100

他にも、superを使うことで、上位のコンストラクタを実行することができます。

1
2
3
4
5
6
7
8
9
class Point < Struct.new(:x, :y)
  def initialize(x, y)
    z = x + y
    super(z, y)
  end
end

item = Point.new(400, 500)
p item => #<struct Point x=900, y=500>

使いどころ


正直、あんまり無いような気がしなくもないですが、自分だと以下で使います。

  • csvファイルとか読み込むとき、ちょっとしたデータ構造を定義するとき
  • ちょっとしたデータのソート
  • ちょっとしたアルゴリズムの追加
  • ハッシュの代わりとか(既にデータ構造が分かってる場合など)

データソートする場合の例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class Point < Struct.new(:x, :y)
  def initialize(x, y)
    z = x + y
    super(z, y)
  end
end

item = Point.new(400, 500)
item2 = Point.new(200,300)

p item => #<struct Point x=900, y=500>
p item2 => #<struct Point x=500, y=300>

array = []
array << item
array << item2

p array => [#<struct Point x=900, y=500>, #<struct Point x=500, y=300>]

result = array.sort{ |item1,item2|
                    item1.x <=> item2.x
               }
p result => [#<struct Point x=500, y=300>, #<struct Point x=900, y=500>]

書き捨てみたいなRubyコードを書くときにはちょうどいいのかもしれないですね。

Dependency Injectionについて

DI(Dependency Injection)について、あるところで聞かれたので回答したときのメモでも残します。

簡単に言うと、よく言われる「依存性の注入」といいます。

が、なんのことかさっぱりわからないですね。 少し言い換えてあげると

「依存性をモジュールもしくはクラス内部に抱え込まずに外部から依存内容を設定してあげる」

となります。

擬似コードを出すとDI前にこんなコードとすると

1
2
3
public Hoge(){
    this.fuga = new Fuga("hogefuga");
}

DI後の擬似コードはこんな感じ

1
2
3
public Hoge(Fuga fuga){
    this.fuga = fuga;
}

コンストラクタの引数Fugaを差し替えるだけで容易に設定内容を変更できます。
依存前のコードだと、依存性はFugaコンストラクタの中にありますが、依存後のコードは依存性は外部にあります。(引数の内容次第)
このFugaのコンストラクタがリソースに関わる何かだとDI前のコードであればユニットテストが大変になりますね。
しかし、DI後のコードであれば引数を差し替えるだけでユニットテストができるようになります。

なので、DIをするメリットというと(個人的に)以下が挙げられます。

  • 依存しているものが外部にあるので、ユニットテストで差し替えが簡単にできる(外部からモックにしやすい)
  • IFさえ同じものであれば、別の実装を行ったものを設定として渡してやることができる(柔軟性)

面倒になるのは、事前準備ですがメリットのほうが大きいと個人的には思ってます。
面倒な事前処理(主にコンストラクタ生成ですが)をやってくれるのがDIコンテナですね。

よく使うDIコンテナだと、有名なjavaのコンテナはこんなところですかね。

  • GoogleGuice
  • Seaser2
  • SpringFramework

自分が使うときの基準だと、以下になりますね。

  • Seaser2なプロダクト(SAStrutsとか)を使っている、もしくは使う場合は、「Seaser2」のDIコンテナ
  • Spring関係の何かを使っている、もしくは使う場合は、「SpringFramework」のDIコンテナ(尤も殆ど使ったことないです)
  • それ以外の場合なら、大体「GoogleGuice」(どこかに事例とかあればいいですし、大体がWicketとかで使います)

AndroidにもDIコンテナ(RoboguiceやDagger)あるのですが、殆ど使いませんね。
使い勝手が悪かったり、ドキュメントがなかったりなので・・・

Dependency Injectionについて

DI(Dependency Injection)について、あるところで聞かれたので回答したときのメモでも残します。

簡単に言うと、よく言われる「依存性の注入」といいます。

が、なんのことかさっぱりわからないですね。 少し言い換えてあげると

「依存性をモジュールもしくはクラス内部に抱え込まずに外部から依存内容を設定してあげる」

となります。

擬似コードを出すとDI前にこんなコードとすると

1
2
3
public Hoge(){
    this.fuga = new Fuga("hogefuga");
}

DI後の擬似コードはこんな感じ

1
2
3
public Hoge(Fuga fuga){
    this.fuga = fuga;
}

コンストラクタの引数Fugaを差し替えるだけで容易に設定内容を変更できます。
依存前のコードだと、依存性はFugaコンストラクタの中にありますが、依存後のコードは依存性は外部にあります。(引数の内容次第)
このFugaのコンストラクタがリソースに関わる何かだとDI前のコードであればユニットテストが大変になりますね。
しかし、DI後のコードであれば引数を差し替えるだけでユニットテストができるようになります。

なので、DIをするメリットというと(個人的に)以下が挙げられます。

  • 依存しているものが外部にあるので、ユニットテストで差し替えが簡単にできる(外部からモックにしやすい)
  • IFさえ同じものであれば、別の実装を行ったものを設定として渡してやることができる(柔軟性)

面倒になるのは、事前準備ですがメリットのほうが大きいと個人的には思ってます。
面倒な事前処理(主にコンストラクタ生成ですが)をやってくれるのがDIコンテナですね。

よく使うDIコンテナだと、有名なjavaのコンテナはこんなところですかね。

  • GoogleGuice
  • Seaser2
  • SpringFramework

自分が使うときの基準だと、以下になりますね。

  • Seaser2なプロダクト(SAStrutsとか)を使っている、もしくは使う場合は、「Seaser2」のDIコンテナ
  • Spring関係の何かを使っている、もしくは使う場合は、「SpringFramework」のDIコンテナ(尤も殆ど使ったことないです)
  • それ以外の場合なら、大体「GoogleGuice」(どこかに事例とかあればいいですし、大体がWicketとかで使います)

AndroidにもDIコンテナ(RoboguiceやDagger)あるのですが、殆ど使いませんね。
使い勝手が悪かったり、ドキュメントがなかったりなので・・・

日経ソフトウェア7月号の特集を読んだ感想

日経ソフトウェア7月号の特集「そのコードは古い!」を読んだ感想。

これとは別の技術書を書店まで買いに行きました。

そこで日経ソフトウェアを手に取りました。

いつもは、日経ソフトウェアを書店でパラパラ目を通す程度です(エンジニアに端くれかみたいな感想は兎も角) ただ、今回は特集のタイトルに惹かれて買ってじっくり読んでみました。

なので、特集に限って読んだ感想というメモを残します。 あくまで、私めの意見というか感想なので・・・スルーしていただけると。

C言語編


point1「void mainはやめよう」とありますが、これは入門書のサンプルが諸悪の根源かと思います。
自分がC言語を学習したときは、普通にvoid mainで教わりました。
当時は、Unix/Linuxの知識も無いので当たり前ですし、戻り値が、intになっていてもおまじない程度の認識でした。

なので、intの意味まで教えてあげるべきかなーと思います。(特に初学者に対してですが)
こうやって、サンプルコードとして教えてあげればいいかなーとか思いました。(これなら処理が正常終了していることが明確になるかと)

1
2
3
4
5
6
7
#include<stdio.h>
#include<stdlib.h>

int main(void){
 printf("Hello world");
 return EXIT_SUCCESS;
}

以下のものは当たり前の話かなーと思いました。

  • point2「文字定数にchar型は使わない」(関数同士で受け渡す際はint型に変換されるから)
  • point3「古い関数定義はやめよう」(K&Rの記述方法。本を読めば分かります)
  • point4「gets関数は古い」(確保された領域以上のものが入力されたらバッファオーバーフローになっちゃうから)
  • point5「switch文あり気で考えない」(これはどの言語でも言える話で、コードが見づらくなっちゃう上に、break文忘れるとバグになってしまう)
  • point6「何でも#defineで定数や関数マクロを定義するのは古い」(コンパイル時の型チェック等スルーする上、関数マクロは記述ミスをしやすくなるから)
  • point7「定数の羅列に#defineは古い」(意味のある連続したものだとenum使ったほうが便利ですね)
  • point8「ポインタサイズでメモリを確保しない」(ポインタ型とデータ型は処理系によってサイズが違うから)

point8の良くないコードは以下のもの

1
2
double *d
d = (double *)malloc(sizeof(d)*100)

良いコードは以下のもの

1
2
double *d
d = (double *)malloc(sizeof(*d)*100)

書いて思ったけど、普通のことだな。。。

java編


お仕事柄メイン(?)で使ってたので・・・

  • point1「C言語で主流だったハンガリアン記法は古い」
  • point2「スネークケースは使わない」
  • point3「メソッドの先頭に変数宣言を並べるのは古い」
  • point4「エラー種別をintで返さない」
  • point5「処理結果を引数に格納しない」

このあたりはCの悪癖なんで、マジ勘弁して下さい・・・。
コードレビューにこんなコード出してきたら速攻Rejectしちゃいますよ。。。
poin4は、Exceptionをthrowすればいいのでなんとかなります(尤もjniに依存するようなコードだと考えてもいいかなーなんて個人的には考えてしまいます)
point5なんか副作用が山盛りなコードになりますしね。

気を取り直して・・・。

  • point6「ジェネリクスを使用しないコードは古い」(リストを型安全にできますよねー。キャスト地獄はヤダー)
  • point7「定数インターフェースは古い」(static importとか、定数の機能分割をやるでしょ)
  • point8「意味のない定数値は書かない」(enumにしろって話。これもC言語の定数定義の話と同じですね)
  • point9「finally句でcloseするのは古い定石」(java7以降だとそうですね。java6までだとこの定石を使いましょう)
  • point10「ジェネリクスで型を省略しないのは古い」(point6と矛盾してるような感じですが、こちらはjava7の話で俗にダイヤモンド演算子と呼ばれるもの)
  • point11「ファイルの読み込みには数行も使うな」(java7以降に限る話です。java6までは従来道理の読み込み処理を書きましょう)
  • point12「定番ライブラリはApacheCommonsだけではない」(それもそうだよねーって話。ジェネリクス非対応だったり、流れるようなインターフェースもなかったりだし)
  • point13「Listからある条件に一致した要素を取り出す際、for文を使うのは古い」(filterメソッドを使ったらいいよってこと。因みにGroovy使えって言ったらダメ?)

point9で言ってるjava7での新しい定石「close句の省略」

1
2
3
4
5
6
try ( FileReader in = new FileReader("hoge.txt");
    BufferdReader br = new BufferedReader(in);{
    // 詳細な処理
}catch(Exception e){
    // 例外処理
}

point10のダイヤモンド演算子

1
List<String> list = new ArrayList<>();

point11のファイル読み込み処理(Filesクラスが便利になった)

1
Files.readAllLines("hoge.txt",Charset.defaultCharset());

因みに、従来の長い処理(途中の前後を省略)

1
2
3
4
5
BufferdReader br = new BufferedReader(in);
String line;
while((line = br.readLine()) == null){
    // 読み込んだときの処理
}

javascript編


思うところというよりも・・・
HTML5といいJQuery,CoffieScript,Dart等、言語の発展が最近めざましいと個人的に思ってます。
そのため、感想というよりもこうするのが最近のトレンドだよねーみたいな感じでした。

  • point1「HTMLのform要素に処理を埋め込むのは古い」(特殊な事をしなければ、HTML5で事足りることが増えてきたと思う)
  • point2「ロールオーバにa要素を使っているのは古い」(ブラウザのサポートに依るのは?と思った。SE/SIerなところだと未だにIE6でみたいなことがまかり通るし、一概に古いと断言するのはどうかと思った。)
  • point3「JavaSriptライブラリを使わないのは時代遅れ」(これはそうかなーと思う。実際にjQueryは使いますし。)
  • point4「jQueryを使わないコードは古い」(古いと断言するのは、どうかと思うが使うほうが楽できる。コラムにあったけど万能ではないね。特にIEが絡むとなると途端に辛くなる)
  • point5「HTML5のAPIを使わないと時代遅れ」(新規に書く場合ならHTML5を使っていき、補助(Flashがやってたとことか)でJSを使うのがいいのかなーと思う)
  • point6「多言語の助けを借りる」(DartとかTypeScriptかな。得手不得手があるので適材適所で使えばいいと思う。jsとかで書きづらいところはサーバサイドJavaとかでやってもいいわけだしね)

C#編


自分が、C#を現在進行形で勉強中なので、感想が出てくるより先にこう書けばいいのかー。
なんてことを思いました。
サンプルのあるのが全てではないよ~的な感じですね。

Ruby編


これは、好きな言語

  • point1「大量の引数が必要な際ハッシュオブジェクトを利用するのは古い」(このテクニック自体は好きだけど、ハッシュキーが無かったら大惨事になることがありますね)
  • point2「配列のグループ分けを長々と書くのは古い」(1.8系に限らず、1.9系でも思わずやってしまいそうな処理がコード例だった。chunkメソッドで配列のグループ分けができるのか)
  • point3「配列からランダムに値を抽出する際delete_atメソッドは古い」(samplingって意味から作ったっぽいsampleメソッドを使用すればランダムに値を抽出できる)
  • point4「テストフレームワークは1つと考えるのは古い」(要するに適材適所。RSpecとTestUnitの両方を併用(てテスト範囲なり、記述方法なり、assertなり)してテストをすればいいと個人的に思ってる)
  • point5「execコマンドでjavaのクラスを読み込むのは古い」(一々、外出しにしたjavaを読み込む何かの実行ファイルを作成する必要はなく、JRubyを使えばいいよって話。割りと普通かと思ってた)

point1はRuby2.0で導入されたキーワード引数でデフォルト値を設定すればいいですね。

1
2
3
4
5
6
def keyword(hoge:0,fuga:"fugafuga")
    puts #{hoge}
    puts #{fuga}
end

keyword hoge:10 fuga:"hogehoge"

point2の配列のグループ分け(偶数のものと奇数のもを分ける)

1
[1,2,4,7,9].chunk{|a| a.even?}.each{|k,v| puts "#{k} #{v}"}

point3の配列からランダムに値を抽出する

1
[1,2,4,7,9].sample(2) #-> [4,9]

point5のJRubyで実行する話(Jythonとかも似たような感じですね)

1
2
3
4
5
require 'java'
import 'java.lang.System'

puts "hogehoge"
System.out.println("fugafuga");

特集を読んだ感想は以上かなー。 なんとなく、書籍のサンプルがアレな時があるって感じじゃねーの?みたいな感想でごめんなさい。

Rubymineを使ってみる

皆さんはRubyやRailsでアプリを書くときどのようなエディタを使いますでしょうか?

僕は、Emacsで書いていることが多いです。。。

多いのですが・・・
こんな感じで若干面倒な面もあってですね。

  • 設定がともかく面倒くさい・・・。
  • 色々設定を追加しているので、重くなってきた(僕の設定が悪いのかもしれませんが・・・)
  • 補完周りも効くのか効かないのか微妙な時も(僕の設定が悪いry)
  • オムニ補完が・・・効きすぎてお節介すぎる(僕の設定がry)
  • その他色々。。。

良い面もありまして、僕が思う良い面はこんな感じ。

  • キーバインドがカスタムできるよ
  • 画面が分割できるので、TDDにも向いてるよ
  • オムニ補完が良い感じに効いたときは、さくさくコードが書ける
  • タブやフォーマットとか「{ }」の自動補完とかきっちりやってくれる
  • あとは、タグを使ってソースからソースへのコードジャンプができる

殆ど、Emacsの機能ですねw

で、面倒くさい面もあるのでRuby開発に限ってはEmacsを卒業してもいいのではないかと最近思うようになりました。

なので、Rubyをスムーズに開発できるエディタってなんだろうとか気になりだした訳です。
エディタとして候補が挙げれたものは・・・

  • Vim
  • Text Mate
  • Sublime text2
  • Coda
  • Aptana Studio(Eclipse)
  • RubyMine

自分が観測できた範囲だとこんだけ。

色々ありますね。とりかえず今回はRubyMineを使ってみます。

Rails コマンド

「$rails migration」とか実行する場合、「Ctrl + Option + G」
よく使いそうなものは大体実行できます。
主に以下のようなことができる。(ここでは一部のみ記載)

  • scaffold
  • migration
  • helper
  • controller
  • その他色々
Rails Server

サーバを起動する場合、「Option + Shift + F10」
デバッグ実行やプロダクション起動、リリース

リファクタリング

変更箇所をカーソルで選択後「Shift + F6」
プレビューが表示されるので、「Do Refactor」を実行しましょう。
いちいち、「Do Refactor」ボタンを押さないといけないところに操作性のムカツキを感じる。

その他

エディタ自身の設定でデフォルトで有効になっている「フリーカーソール」をOFFにしたい。(余白をクリックすると、行の末尾にいかない)
設定項目のエディタ設定で、「Vertual Space」を見つけます。

「Allow Placement of caret after the end of line」のチェックボックスを外します。

そうすると、余白をクリックしても行の末尾にいくようになります

Vi(Vim) on Emacsを思いつきでやってみた

ただのネタカテゴリですwww

昨夜、盛大に悪酔いしましてその時思いつきました。

手順とか見れば、誰でも思いつくでしょう。

という訳で以下に起動手順と感想を書いてみました。

Vi(Vim) on Emacsの手順


  1. ターミナルを起動します。
  2. おもむろにemacsとタイプしてEnterを押します。
  3. M-x shellを実行し、shellモードを起動します。
  4. shellモードで入力受付状態になりますので、おもむろに「vi」もしくは「vim」とタイプしてEnterを押します。

あら不思議、Emacs上でVi(もしくはVim)が起動しましたよっと。

Vi(Vim) on Emacs使った感想


やめておけの一言!! ざっと、使用してみた感覚だとこんな感じ。

  • Escを押したのか押してないのか判断がつけられない
  • モード切り替えの挙動が怪しい
  • 環境かもしれないけど、Macだとスクリーン表示がおかしい

ネタとしてはありですが、実用にはとても耐えられるものではないのでやめましょう。

初海外がGoogleI/Oだったので、準備とか苦労したことのメモ

GoogleI/O2013に行ってました。

初海外の人が如何にして海外に行ってきたかを記録します。

前提


何はともあれGoogleI/Oのチケットを手に入れましょう。
話はそれからです。

必要なもの


海外へ渡航するにあたって必要なものは以下のものでした。

  1. パスポート
  2. ESTA
  3. 航空チケット(もしくは海外に行ける手段)
  4. 宿泊先の確保
  5. 旅行期間の調整(会社とか学校とか)
  6. スーツケース
  7. 衣類など
  8. 印刷物一式
  9. その他

上から順番に解説します。

パスポート

これは当たり前なので、解説不要でしょう。
持ってなくても、チケット購入から開催日まで一ヶ月以上日数があるので
チケット購入してからすぐに申請すれば十分間に合います。(パスポートの受け取りも含めて)
戸籍抄本とか必要なので、このあたりの準備がネックでしょうか。

ESTA

アメリカ旅行では必要です。
ネットから申請できるので、実施しましょう。
お金がかかるのとパスポート番号の入力があるので気をつけましょう。
パスポート持ってない場合は、チケット購入後パスポートを直ぐに取得してればESTAの申請も間に合います。

航空チケット

ここはお任せで・・・。
自分の失敗談は後述します。

宿泊先の確保

大体、こんなパターンになるのではないかと思います。

  • エクスペディアで宿泊先を確保する
  • 後述する情報交換で、相部屋募集にのっかる

自分は、勝手がわからなかったので、相部屋募集にのっかりました。

宿泊先は、開催地に近いほうが何かと便利です。 エクスペディアで申し込むところは、KingGeorgeホテルがオススメだったりします。

旅行期間の調整

社会人だと当然だと思いますが、やりましょう。
宿泊期間に直結します。観光やMakerFairも参加となると長期になります。
できれば、調整は、チケット取る前がいいと思います。

スーツケース

大きいほうがよいと思います。
I/Oでお土産をいただきますので、お土産が入るぐらいのがベストですね。

衣類など

思ったほど要らないかも。
現地は、朝と晩は寒いので防寒対策にパーカーぐらいあったほうがいいかもしれないです。(寒いといっても気にならない程度かもしれないですけど)
というのも、I/OにチェックインしたときにTシャツ貰えたり、会場でTシャツ配ってたりしてるため。
自分は合計で13枚貰ってました(ぇ
実は現地にユニクロあるので、服の調達はそこでーみたいな人は殆ど要らないかも。

印刷物一式

あったほうがいいですね。
I/Oのチェックインはバーコード読み取り式なのですが、携帯からだと精度があまり良くないようです。
これはGoogleの中の人も話してました。(うまくいくことはうまくいくようですが・・・)
他にも空港のチケット発券や入出国で航空チケットや宿泊先など聞かれたりすることもあるので、印刷しておくとスムーズに事が進みます。

自分はこれだけ印刷して行きました。

  • 往復の航空チケット(支払い証明やフライト情報)
  • I/Oのチケット
  • ESTA
  • 現地滞在先ホテル情報(入国時の申請書類に記入するため)
  • ちょっとしたメモ(空港案内や宿泊先までのルートなど)

あとここには書いてませんが、ガイドブックもあるといいですね。
ほとんど不要だと思いますが、入国とか出国とかで提出する書類の記載方法が参考になります。

その他

通信事情ですが、auであればAT&Tに自動(設定でデータローミングをオンにする必要はあります)で接続してくれます。
ドコモやSoftBankは知りません。
が、値段はお高いで1日いくらの料金なので5日もデータローミングで使用しまくると大変な金額になります。
現地で、simカードを購入することをオススメします。(T-mobileがオススメです)
T-mobileであれば、会場の近辺に店があります。(Powel Streetにありますね)
会場(モスコーン)はwifiを提供していますが、T-mobileだと殆ど繋がりません。(特に基調講演時は接続出来ませんでした)
基調講演以外では繋がってたような気がします。

飲料水事情ですが、かなり安い値段で水が売ってました。(1ドルしたかしなかったぐらい)
僕はトランクに1.5Lを詰めて持って行きましたが、8割ぐらいしか飲みませんでした。
持っていくにしても500ml2本ぐらいがベターじゃないかなー。

電源ケーブルですが、日本と同じ端子(2つ口)が使用できました。
が、電圧が少し高い(らしい)ので不安であれば変圧器(だったけ?)を持って行くといいかもしれないです。
旅行用に何か買うことは不要だと思います。

情報交換


皆さんがよく使われるところで参加者どうし情報交換を行なっています。

  • Twitter
  • Facebook(参加者用のグループとメッセージ)
  • Google+(参加者用のコミュニティ)

参加権限とかなければ、Twitterとかで参加者を探せば入れてくれると思います。
# 自分は過去の参加者の招待でコミュニティに入れて頂きました。

現地通貨はどうやってたのか


殆どがクレジットで支払っていました。
アメリカは、信用や支払い能力の世界なのでクレジットが有効です。
ドルで払うことはあるにありましたが、殆どがクレジットで支払っていました。

アメリカで使用できるクレジットの会社ですが、「VISA」、「American Express」が9割でした。
日本で使用できる「JCB」は殆ど使用出来ません。(自分はコレでやばいってなりました)

一応、紙幣でドル札も3万円用意していました。
高額紙幣は、現地で嫌われるため、最大で20ドルで換金して行くとよいでしょう。
3万あれば、チップ等含めて0にすることが出来ました。

さて、チップの話ですが特に意識してチップに何か使うということはあんまりありませんでした。
お高いレストランに行ったときはサービス料として会計に含まれていました。
精々ベッドメイキングとその他ほそぼそぐらいでしたね。
大体、1ドル程度置いておけばいいでしょう。(ここらへんはその人やサービス内容によりけりです) #ベッドメイキングは枕元に1ドル置いておきましょう。(どこに置けばいいだろうになりました)

現地での言語とかコミュニケーションはどうしたか


現地は殆どで英語でしたが、特に困ることはありませんでした。
これは本当です。

英語を話す機会がある最初の関門は入国審査です。(飛行機は日本語話せるスタッフがいるので英語話せなくても困りません)
ここできっちり英語で会話できれば、入国してから特に困らないでしょう。
重要なことなので、もう一度言います。(一応、日本語で入国審査通ることもできるようですが、入国してからが困ります。)

入国審査時に英語で会話して乗り切りましょう

さて、入国してからですが・・・。
相手はしどろもどろの英語でもきっちり聞いてくれます。(相手によりけりかもしれませんが、基本的に聞いてくれます)
ここらへんは、日本でいうところの方言に近い感じなんですかね。
日本でも海外の方に道を尋ねられたりすると聞こうとするので、同じ感覚かもしれないですね。
多少訛っても気にならないような感じ。

失敗したこと


ここからは自分の失敗談を記載します。

航空チケット

これは、往復で購入したほうがよいです。
料金が高くなってしまいます。(大体1.5倍くらいします) 内訳は以下のような感じです。

  • NRT->SFO : 約23万
  • SFO->NRT : 約14万

大体これぐらいしました。往復便で買えば、23万ぐらい(?)で済みます。
勿論、料金は航空会社や時期にもよりますがI/Oの時期だとこれぐらいですね。
日本は航空便が高いですね。

但し、片道で行くメリットもありまして・・・

  • 航路を自分で選択できるので、面倒な乗り換えの手間がなくなる
  • 乗りたい飛行機の航空会社を選択できる
  • 経由することで、旅行気分を変えることができる

自分は、乗り換えの手間を極力省きたかっただけですね・・・。
初海外で、飛行機の乗り換えや経由は厳しいと思ったので。

手荷物

これは、失敗と言うよりもI/Oだから不要といったものでしょうか。
手荷物で以下のものを持っていました。

  • iPad mini
  • iPhone4S(sim free)
  • iPhone5(国内版)
  • Nexus7
  • MacBookPro
  • モバイルブースター
  • Walkman
  • Shure SE530(遮音性高いので飛行機とか耳栓代わりになる)

こんだけ持ってましたが、使用しないものが大半でした。
不要なものを列挙すると・・・

  • iPad mini(飛行機の中で使用してればよいと思っていた)
  • Nexus7(飛行機の中で使用してればよいと思っていた)
  • MacBookPro(盗難にあうと不味いので常時持っていたのですが、兎に角重い)
  • Walkman(飛行機や海外で使用した記憶無し)

ぐらいでしょうか。自分の場合、2台あるiPhoneはどちらも必要でした。

逆に持って行ったほうがよかったものを列挙します。

  • デジカメ(当たり前ですが撮影機会は非常に多いです)
  • Android端末(sim freeかつNexusとかXperiaとかの著名な端末)
  • MacBookAir(常時持ち運びするなら軽いほうがいいですね)

なので、こんなところにしておけばよかったとおもいます。

  • MacBookAir
  • デジカメ
  • Android端末
  • iPhone
  • モバイルブースター
  • Shure SE530
金銭周り

事前に調べてなかったのが悪かったのですが、クレジットで「JCB」が使用できなかったことです。
手持ちの「VISA」カードの利用残高が殆どなくってかなりキツかったです。(3万少々ぐらいだったはず)
航空チケットに「VISA」カードを使用したのが失敗でした(支払い期日がちょうど5月末だったので利用残高が増やせなかった)
カード会社によりますが、事前に申請することで海外用に利用残高を一時的に増やすことができます。
本当に事前にやりましょう。現地でやっても増額申請が降りませんでした。(2日以上かかるようでした)

あと、ベッドメイキング毎にチップを置きましょう・・・。 忘れていました。

次回(あれば)この失敗は繰り返さないようにする。

IntelliJ IDEAで/usrディレクトリ配下のものが選択できなかった

そんなことがあったのでメモしておく。

どういうことかと


ProjectStructureでSDKとか設定する訳なのだが・・・
これ、MacだとSDKの場所をGUIで選べって方式なんですよね。

それはそれで便利だし楽でいいんだけども

/usr/ディレクトリ配下にあるものは選択できない!!

( ゚д゚)

Macの隠しディレクトリを表示する以下のコマンドを実行しても選択することが出来なかった。

1
2
$defaults write com.apple.finder AppleShowAllFiles -boolean true
$killall

結局どうしたか


ものすごく力技ですが・・・

ホームディレクトリから/usr/ディレクトリまでシンボリックリンク張っちゃいました

とりあえずこの方法で解決しました。
あんまりよくないというのは理解していますが、しょうもないことに時間取られるのも嫌だったのでこうしました。
うまい解決方法あったら教えて下さい。

正直なところ


そんなところにファイル置いてるほうが悪いのでは?と言われるかもしれないですが、SDKとかって「/usr/local」の下に入れたくなるじゃないですか。
特にLinuxとか弄ってると

ぶっちゃけ、IDEAが悪いわけではきっとないと思っているし、ステマでもなんでもないです。

本当だよ。