2015年12月8日火曜日

【AndroidStudio】設定のカスタマイズ

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

ただ今、業務都合により急ぎAndroidStudioの検証を進めています。
今回は設定の微調整を。

不便極まりない


前回の日本語が不完全なことも去ることながら、エディターを開いても行数が出ていないとか、インポートが自動で入ってくれないとか、色々不便なことは盛りだくさん。
しかしこの辺りは手動で設定することで快適化出来るようです。

今回は色々とカスタマイズ&ショートカットを把握していきましょう。

エディターに行数を表示する&空白を表示する


最初はこれ。エディターに行数の表示が無ければやり辛くてしかたありません。
空白を表示する機能も追加出来ます。
以下で設定出来ます。

  • ファイル > 設定 > Editor > エディタ > 外観

私は空白は表示しない方が好みなんですけどね。

コードのフォーマット、インポート最適化


実装していたらソースがデコボコ……。フォーマットしたい。
インポートもゴジャゴジャ。綺麗にしたい。

そういう時はショートカットで行きましょう。

  • コード > コードの再フォーマット(Ctrl + Alt + L)
  • コード > インポートの最適化(Ctrl + Alt + O)

ショートカットキーも覚えていけば効率も上がっていくでしょう。

インポートの自動セット


あれ~。上に書いてある「インポートの最適化」をしてもインポートされないぞ???
これは「不要なインポートを削除する」だけで、必要なインポートのセットはやってくれないのです。
オートインポートから「オンザフライで設定する」にしちゃって下さい。

  • ファイル > 設定 > Editor > エディタ > AutoImport

オンザフライってどういう意味なんでしょう???
まあ、自分の操作とは別の所で自動インポートが作動するという意味なのでしょうが、余り聞かない用語です。

変更したタブに*(アスタリスク)を付ける


「沢山開いたらどれを変えたか分からなくなっちゃいました♪(テヘペロ)」なんて馬鹿げたことをしないように、未保存編集中のファイルには*(アスタリスク)が表示されるようにしましょう。

  • ファイル > 設定 > Editor > エディタ > Editor Tabs

マウスオーバーでドキュメントを表示する


「あれ~? EclipseだとマウスオーバーでJavaDocが出るのに、こっちは何も出ないぞ???」

  • ファイル > 設定 > Editor > エディタ

テーマ変更


AndroidStudioの色彩を好みに変更出来るようですね。

  • ファイル > 設定 > Appearance & Behavior

お好みでどうぞ。

メモリインジケータ表示


「くそっ、メモリ不足で落ちやがる……」
AndroidStudioが今、どれくらいのメモリを消費しているのかのゲージを表示出来ます。

  • ファイル > 設定 > Appearance & Behavior

コードテンプレート


クラスを新規作成すると、真っ新な状態でファイルが生成される……。
「@Author」みたいなJavaDocコメントとか、パッケージ上部の署名などは自動セットした方が楽チンですよね?

  • ファイル > 設定 > Editor > エディタ > ファイルテンプレート

ここは会社のコーディング規約などと照らし合わせて最適化しておくと便利でしょう。

JavaDoc入力支援機能


「新しくメソッド作ったぞ。さて、JavaDocを……。えーっと、どういう記述ルールだっけ???」

JavaDocを書きたい場合は、そのメソッドをクリックして「Alt + Enter」です。


AndroidStudioのショートカットは「Alt」が多めな印象です。
特に「Alt + Enter」はJavaDoc以外にも色々出てきますので、「困ったらとりあえずAlt + Enter」を試して見ると良いかもしれません。

終わりに

他にも設定は色々ありますが、とりあえず、私が最初にザーッと設定した方が良いと思ったのはこんな所ですね。
人に依っては「Logcatの色を変える」とかまでやっている人もいるそうな。

この記事のみならず「こういうことは出来ないのかな?」という着想を持って調べて頂ければ、案外細かく要望に応えてくれるのではないかと思います。

2015年12月1日火曜日

【AndroidStudio】インストール&日本語化

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

ただ今、業務都合により急ぎAndroidStudioの検証を進めています。
では、早速アプリをインストールしていきましょう。

インストール


インストールについては記事を省略させて頂こうと思います。
以下公式サイトからアプリをダウンロードして下さい。

日本語化


さて、AndroidStudioは初期状態では英語ですので、日本語化していきたいと思います。
しかしこの日本語化がちと問題。
今回のテーマは日本語化です。

調査を進めていきますと、AndroidStudioを日本語するには二種類のやり方があることが分かりました。
Eclipseの日本語化ツール「Pleades」を使用する方法と、
AndroidStudioのベースとなったIDE「IDEA」の日本語化ツールを流用する方法です。

Pleadesで日本語化


結論を言いますと、Pleadesを使用する方法はやめておいた方が良いと思います。
一応、手順をご紹介します。

まず、Pleadesの公式サイトよりプラグインをダウンロードします。


ダウンロードしたZIPファイルを解凍すると「plugins/jp.sourceforge.mergedoc.pleiades」というフォルダがありますので、これをAndroidStudioの「plugins」の配下に置きます。
そして起動オプションファイルに起動引数をセットします。
ファイルは使用しているOSのビット数に依って違います。

  • 32bit:studio.exe.vmoptions
  • 64bit:studio64.exe.vmoptions

ここからが問題です。
まず、起動オプションに以下を設定しろという記事が目立ちます。

-javaagent:../plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar

でも、これだと動かないんですよね。
ダブルクリックで起動するとホームディレクトリがログインユーザのホームパスになるもんで、相対パスでは動かないのが真相だと思います。
AndroidStudioをホームパスにインストールしているとは限りませんからね。ダメダメ。
絶対パスで指定する必要があります。

さて、絶対パスで無事にパスを通したとしても、以下のエラーログが出ます。

EmptyThrowable: Short name not matched for class com.google.gct.idea.appengine.validation.ConstructorInspection: getShortName() = コンストラクター; ep.shortName = Constructor
20:25:59 NullPointerException: null

原因は分かりませんが……。
一応、日本語化そのものは作動しますが、得体の知れないエラーが継続的に出てしまいます。
ちょっとこんな状態で作業をするのはどこに落とし穴があるか分かりませんので、現時点においてはPleadesを使った日本語化は辞めておいた方が良いでしょう。

IntelliJ IDEAの日本語化ツールを流用


では、本命であるIntelliJ IDEAの日本語化ツールを使用しましょう。
GitHub上に有志の方が日本語化ツールを公開して下さっていますので、これを使用させて頂きます。


右下の方にダウンロードボタンがあるのでここからダウンロードして下さい。


これを解答すると「resources_jp.jar」というファイルがあるので、これをコピーし、
「Android Studio/lib」の配下に置きます。


これでOK。
無事に日本語化出来ました。


しかし……、ん~。
日本語化が十分とは言えませんね~……。
元々がIntelliJ IDEAの日本語化ツール。
AndroidStudioはIntelliJ IDEAをカスタマイズしたツールですから、8割方はこのツールで日本語化出来るのですけど、出来ていない部分もあるのです。

完全に日本語化するのは現時点では難しいようです。
中途半端でもいいから少しでも日本語化するか、いっそのこと覚悟を決めて全部英語のまま進めるか、ここは利用者の判断が入るところだと思います。

やっぱりこっちもちょっと不安があるかなぁ……。
だって「元からAndroidStudioを想定していない」んだから、どんなバグがあったって不思議じゃないでしょ?

幸い「resources_jp.jar」を削除すれば一発で元に戻ります。

ここはちょっとハイブリッドな方式にして、

  • 最初は日本語化して使う。
  • 慣れてどこにどんな機能があるか全て把握したら、英語に戻す。

英語でやれるなら英語でやるのが一番に決まってますからね。
自分が英語を覚えるまでの手助けツールくらいの位置づけが良いかもしれません。

終わりに


日本語化が不完全なところあたり、Eclipseと比べるとまだまだ発展途上の感は否めないAndroidStudioです。
引き続き調査を継続します。

2015年11月24日火曜日

【AndroidStudio】始めに

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近は目下MicrosoftAzureの利用方法を検証中ですが、業務都合により急遽Android開発環境「AndroidStudio」に切り替えます。

Eclipseプラグインのサポート終了


さて、事の発端はEclipseのAndroidプラグインのサポート終了でした。


うっ……。きっつー……。
長年の間、Androidの開発環境と言えば、それは「Eclipse + Androidプラグイン」でした。
GoogleがそのAndroidプラグインのサポートを辞めてしまうので、間もなくこの環境は過去の遺物と化してしまいます。

その代わりにGoogleが公式開発環境として掲げるのが、この「AndroidStudio」なわけです。

しかしですね、私みたいに「Eclipse以外で開発なんてやったこと無いよ!!(=やりたくねえ)」ってエンジニアは星の数ほどいると思いますよ。
容赦無く切り捨てられてしましました。無念。。。

でも、Googleの気持ちも分からなくは無いですね。
だって、「Eclipse + Androidプラグイン」の構成って確かに動作がイマイチな部分もありましたからね。

  • Javaのバッチ開発⇒Eclipseで
  • JavaのWebアプリ開発⇒Eclipseで
  • JavaのAndroid開発⇒もちろんEclipseで!!

みたいな感じに、「同じJavaだから全部同じEclipseで」っていう発想が限界に来ていたのでしょう。
特にAndroidは独自の仮想マシンを積んだりシミュレータを積んだりと、他の開発と比べても特に異質なものです。
色々と重かったり、互換性やなんやらでデザイナーが表示出来なかったり……。
GoogleがAndroidに限った特化環境を欲したのも無理からぬ話と言えば納得です。

残念ではありますが、他ならぬGoogle様が仰るのだから従うしかありませんね。

ちなみに、それでもEclipseで開発を続けたい人も当然おり、Andmoreという延命プロジェクトが進行中のようです。


往生際が悪いですね……。
面白い試みだとは思いますが、そんなことやってたらそれだけAndroidStudioへの移行が遅れるではありませんか。
今はAndrodid勢は一丸となって技術を推進していかなければならない時なのですから、そんな反乱分子みたいなことはやってないで、そのパワーはAndroidStudioのプラグイン開発にでも使って頂きたいです。

これをお読みの皆さんはくれぐれも「もうちょっとEclipse使えないかな?」なんてセコいことは考えず、さっさとAndroidStudioへと移行し、人柱となって下さい。

そもそもAndroidStudioって何だ?


しかし、私もEclipse人間である都合上、急にAndroidStudioなんて出されても困るのは事実。
ちょっとAndroidStudioの背景を勉強しておきましょう。

調べた所によると、AndroidStudioはココに至るまで概ね以下の歴史を辿っているようです。

  • 2013年:発表
  • 2014年:ベータ版
  • 2015年:公式ツール化

2015年現在では最新鋭の開発環境です。
最新鋭と言えば聞こえは良いですが、要するにそれだけまだまだ発展途上の環境と言い換えることが出来ます。
色々と問題が起きることは目に見えていますが、やるしかありません。頑張って行きましょう。

さて、更に調べて見ると、AndroidStudioはEclipseとは全然別物だということが分かってきます。

AndroidStudioは「IntelliJ IDEA」という別の開発環境をベースにAndroidに最適化した環境とのことです。

IntelliJ IDEA


では、AndroidStudioの元となっているIntelliJ IDEAとは何でしょう?

ZeroTurnaround社の2012年の調査報告によると、世界第二位の人気を誇る開発環境にしてEclipseの第一のライバルです。

  1. Eclipse:76%(IBM)
  2. IntelliJ IDEA:28%(JetBrains)
  3. Netbeans:17%(サンマイクロシステムズ⇒Oracle)

76 + 28 + 17 = 121% って100%超えてるじゃねえか!!って思いますが、きっと複数の開発環境を使い分けているチームもいるということでしょうね。
しかしEclipseが圧倒的第一位であることは間違いありません。

しかし、統計を見ると全体の3割弱はIntelliJを使っているって意味になりますよね。
でもその割にはIntelliJを使ってる現場なんて全く聞いた事が無いぞ。単に私の住む世界が狭いだけでしょうか?

それはですね、特の根拠はありませんが、多分日本は世界標準よりも圧倒的にEclipseが強い」、これだと思います。

結構あるんですよ。
世界の人気傾向と比べて日本はちょっと独自文化を築いているというパターンが。
きっとIntelliJもこのパターンなんだと思います。

終わりに


と言うわけで、AndroidStudioの正体はIntelliJ IDEAだということが分かりました。
そして日本での普及は低い……。

となると、今後に調べていく上での心構えも足ってくるというものです。

  • AndroidStudioのベースはIntelliJ IDEAである。
  • AndroidStudioで調べて分からない場合はIntelliJ IDEAで調べる。
  • 日本語情報が少ないので英語サイトもバンバン読むべし。

こんなところでしょうか。
次回以降もしばらくはAndroidStudioの勉強を進めていきます。

2015年11月16日月曜日

【AzureでSugarCRM】日本語化

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はAzureでSugarCRMを使用可能にしようと画策しています。

英語



英語だ!!

これじゃ全く使い物にならないぞ……。
日本語マニュアルはあるんですけど、肝心のどうやったら日本語に出来るのかが見つからない……。


日本語化プロジェクトは閉鎖してるし。


参ったな、こりゃ。。。
最初から日本語のCRMを導入したいところですが、Azureでやるという制約がある以上、何としてでもSugerCRMじゃなきゃ困るんですよ。

GitHubを探しても無い。

6カ国語しか対応していないのか?
過去には日本語パックがあったはずなんですよ。

Japanese Language Packはどこ行った……。

まあ、結論としてはネットの海から拾ってきました。

  • SugarCE-JLP-6506.zip

日本語化作戦

最新バージョンでは無いようですが、これでもそこそこは日本語化出来るでしょう。
しかし、古いバージョンのパッチを最新バージョンに宛てようとしても出来ませんので、小細工を行います。

まず、展開しているアプリのバージョンを確認。


Aboutのページを見ると「Version 6.5.22 (Build 1055)」となっています。
これがAzureのバージョンのようです。

SugerCRMの最新バージョンは2015年11月現在で7.6ですから、随分と古いですね……。
どうやら2013年頃から止まっている模様。
まあ、タダだし仕方ありませんね。

ともかく、これで展開環境のバージョンが分かりました。
次に、日本語化パッチをゴリ押しで宛てる為の小細工を行います。

「SugarCE-JLP-6506.zip」を解答すると以下ファイルが出てきます。


ここから「manifest.php」を開きます。

そこに「acceptable_sugar_versions」という項目があり、正規表現でそのパッチの対象バージョンを指定出来るようになっています。
これを無理矢理Version 6.5.22書き換え!!


終わりましたら、再びZip圧縮して元に戻して下さい。
これでバージョン変更完了ッ!!

ここまで来たら後は簡単です。
Adminページを開きまして、Module Loaderページへと進む。


その先はファイルアップロード画面ですので、先ほどのZipファイルをアップロードして下さい。


これでパッチ適応完了です。
一回ログアウトしてログイン画面に戻りますと、選択メニューに日本語が選べるようになっています。


そしてログインしますと……。


やった!!
日本語化成功です。

検証

さて、無理矢理過去のバージョンの日本語化パッチを宛ててしまったのでどこかバグっていても不思議ではないのですが、
どうやら九分九厘は正常に日本語化出来ているようですね。

それでももし上手く日本語化出来ていない部分があったら、自分で改修すれば良いでしょう。
日本語化パッチの正体は以下ですから。


単純にラベルを日本語に置換しているだけのようです。
これなら自分でも何とかなりそうです。

終わりに


さて、これでめでたく無事にSugerCRMを使用開始出来そうです。
少し触ってみましたが、ちょっと動作が重い点が気になるものの、それ以外は普通に使って行けそうですね。

最後に、私が上記で改修した日本語化パッチを以下に置いておきますので、
これからAzureでSugerCRMを活用した方がいらっしゃいましたら、ご自由にご利用下さい。


クラウドは積極的に活用していきたいものですね。

2015年11月9日月曜日

【AzureでSugarCRM】アプリ作成

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

前回よりAzureの「最初からツールがインストール済み」というSaaSならではの長所生かし、
プロジェクトのスモールスタートを行っています。

現在はSugarCRMのセットアップ中です。

アプリ作成

では、さっそくアプリを作っていきます。
まあ、作るだけなら一瞬なんですが、一応画面キャプチャを。
特記事項無し。




これで完成ですが、ここから完了まで数分の待ち時間が発生します。
ブランクのプロジェクトを作った時は本当に一瞬だったのですがね。

恐らく、裏側で仮想マシンのコピーを行っているか、もしくはSugarCRMのインストールを行っているものと思われます。
裏側がどういう作りになっているのか大変気になる所ですが、今回はそこまで深掘りするのはやめておきましょう。

「深く分かっていなくても問題無く使える」というのがクラウド系アプリの長所の一つですからね。

そうこうしているうちに作成が完了しました。


ログイン

さて、ここで問題が。
ログインIDとパスワードが分からないぞ……。
そんなの設定してないし……。

ここはちょっとSugerCRMの公式サイトに行ってみましょう。




バッチリ書いてありました。初回ログインはID:admin/PW:adminだそうです。
これでログイン出来……ねえよ!!

参ったな、こりゃ。一体どうなってんの????

そこで私の勘が冴えました。


これ。
アプリ展開途中で「デプロイの設定」という所でパスワードを入れています。
コレなんじゃないでしょうか。


  • ID:admin
  • PW:アプリ作成時のパラメータ

正解!!


なるほど、確かに


  • 普通のSugerCRM:セットアップが終わってからネットに繋ぐ。⇒その時にはパスワードも変える。
  • AzureのSugerCRM:最初からネットに繋がっている。

ですから、初期状態がID:admin/PW:adminでは垂れ流しもいいところです。
ここはAzureが気を利かせてカスタマイズしてくれたのですね。

さて、無事にログイン出来ました。
ここから先は公式サイトを参考に進めていきましょう。


無事に初回セットも完了しました。


さて、そろそろお気づきの方もいらっしゃるかと思いますが、公式サイトは日本語なのに、Azureの方は英語なのです。

SugerCRMは日本語パッケージを用意していますが、Azureのデフォルトは英語だけ。
日本語化は自分でやらなきゃいけないのです。

これが英語圏ではない人間の辛さ……。
基本、クラウドって英語しか対応してません。
アプリも、ユーザーガイドも、全部英語、英語、英語。

気合い入れて英語を読む覚悟で臨んで下さい。

終わりに

次回はサイトの日本語化にトライしてみたいと思います。

2015年10月28日水曜日

【AzureでSugarCRM】始めに

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

前回までのAzureの調査を行って参りましたが、結局の所、Azureは普通の開発と特に変わりなく開発出来るということが分かってしまいました。
なので、後はAzureのメニューの中で用意されているお好きな製品をどうぞ、ということになるわけですが……。

これからしばらくはいくつか製品を見ていきたいと思います。

Azure標準製品

過去にも触れましたが、AzureのWebアプリには標準で多数のライブラリが揃っています。


基本的にはこの中から選んでいくのがAzureのポイントでしょう。

クラウドの利点の一つは、スタートが早いことです。

普通だったら、サーバを買って、OSをインストールして、DBをインストールして、使いたい製品をインストールして、他にもあれこれ。
それで漸く起動するWebアプリがボタン一個で起動する。
早い。

「インフラ+アプリのセット販売」

それがクラウドの中でも「SaaS」と呼ばれる形態の特徴でしょう。
なので、セット販売されているカタログの中から製品を選ぶのは当然です。

逆にカタログに無いマイナーなアプリを使いたい場合は「IaaS」と呼ばれる形態のクラウドサービスを使用する必要があります。


ともかく、AzureWebアプリケーションを使っていく以上、その中にある「ライブラリ」の中から好みの製品を選ぶ必要があります。

2015年10月現在では以下のメニューが取りそろえられております。

  • Acquia Drupal 7
  • Apache Tomcat 8
  • Better CMS
  • BlogEngine.NET
  • Bottle
  • BugNET
  • CakePHP
  • Composite C1 CMS
  • Concrete5
  • DasBlog
  • Django
  • DNN Platform
  • Drupal Commerce
  • EC-CUBE
  • Express サイト
  • Flask
  • Gallery Server Pro
  • Ghost
  • Incentive
  • Java Coffee Shop
  • Jetty
  • Joomla!
  • Kentico CMS for ASP.NET
  • Lemoon
  • MageliaWebStore (IIS 用)
  • Magento
  • MediaWiki
  • mojoPortal
  • MonoX
  • MVC フォーラム
  • nopCommerce
  • nService
  • NuData DKAN
  • OpenCart
  • Orchard CMS
  • osCommerce
  • OWA
  • phpBB
  • Piwik
  • Pligg
  • razorC.net
  • SageFrame
  • Service Gateway
  • SoNET Web Engine 4.1
  • SugarCRM
  • Umbraco CMS
  • Virto Commerce
  • WordPress

さて、この中から試しにめぼしい製品を一つ…・・。

まずは「SugarCRM」から行ってみたいと思います。

SugarCRMとは


SugarCRMとは、アメリカで開発されている顧客管理システムです。

取引先の住所、電話番号、メールアドレスなどの情報管理に始まり、メールを一斉送信したり、営業活動支援ツールが入っていたり、
まあ色々と製品独特の高機能なものが入っています。

なぜ私がSugarCRMを選んだかと言いますと、我が社の社内に既にそれがあるからです。
ただし、社内からしか閲覧出来ず、SugarCRMのフルパワーを発揮しているとは到底言い難いでしょう。

しかしクラウド基盤Azureに載せれば社外のどこからでもアクセス出来るようになるはずです。
一方、セキュリティ要件も重要ですので、検証が必要……。

と言うわけで、弊社営業のお手伝いとAzureの技術調査を兼ねまして、AzureでSugarCRMを使っていく連載を始めたいと思います。

終わりに

では、来週はさっそSugarCRMを起動していきたいと思います。

顧客管理システム導入というのは、基本的に高いです。
小さい会社だとコストパフォーマンスも鑑みて、顧客管理をエクセルとかでやっているところも多いと思います。

しかし、AzureでSugarCRMを展開する方式であれば凄く安い値段で運営出来ることでしょう。

そのように、顧客管理システムを導入したいけれども及び腰でいる方々のお役に立てる連載にしていきたいと思います。

2015年10月12日月曜日

【Azure】チェックアウトとデプロイ

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はMicrosoft Azureについて連載中です。
引き続き調査を継続していきます。

今回はクラウドサーバ上に展開されているソースそのものに着手していきたいと思います。

チェックアウト

先日の記事でGitによるソースチェックアウト方法まで確認出来ました。
では、実際にソースをチェックアウトしたいと思います。

まず、コンソールの「デプロイ」の所からGitのURLをゲットします。


このソースを元にGitをクローンします。
前提としてローカルPCに既にGitがインストールされていることになっています。
まだの方はインストールして下さい。

TortoizeGitがオススメです。




途中でパスワード入力が聞かれますが、Gitリポジトリ作成時に入力したパスワードを入力して下さい。

AzureのパスワードとGitのパスワードは別です。

サービスとして全く別物なのでID&パスワードの統合が技術的に出来ないのでしょうが、ちょっぴり不便な気もしますね。

そんなこんなで無事にチェックアウト出来ました。


チェックアウト後の姿はこんな感じ。


今回は最初にCakePHPを選択していますから、そのライブラリ一式が登録されているだけ。
特にAzure独特のファイルは見当たりません。

至って標準的なソースです。

デプロイ

では、ソースを変えてデプロイしてみましょう。

CakePHPで一番手っ取り早い確認は「\app\View\Layouts\default.ctp」これを書き換えることですね。
適当に書き換えてみます。


次はこれをコミットします。よいしょ。


コミットしたらプッシュします。
Gitに慣れていない方に向けて補足ですが、コミットとは「ローカルリポジトリに保存」、プッシュとは「リモートリポジトリに保存」を意味します。
SVNの時は「コミット=リモートリポジトリに保存」でしたので、この違いに最初は混乱するかもしれませんね。


さて、無事に何事も無くプッシュ出来ました。
サーバ上のサイトはどうなっていますでしょうか?


左上に改修した痕跡が……って、思いっきり文字化けしてますね!!

どうやら最初は英語状態になっているようです。
日本語を表示するにはエンコードの指定等の対処が必要なようです。

このままでは格好悪いのでエンコードを指定して再表示。


うん。ちゃんと表示されました。

以上、特にコレと言って特筆すること無くデプロイまで完了出来ました。

従来方式のやり方で手動でサーバ上にファイルを設置するより、このGitを利用したやり方の方がずっと簡単だと思います。
実に便利ですね。

終わりに

以上により、デプロイに関しては特にAzure独特の知識が求められるものではありません。
この点のみならず、Azureは総じてAzure独特仕様というものが少なく、汎用知識で対処出来ることが多いイメージです。

新規に導入するに際してもハードルは低いと思われ、大変好印象ですね。

引き続き調査を継続していきたいと思います。

2015年9月28日月曜日

SubversionとGitの連携

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はMicrosoft Azureについて連載の途中なのですが、その副産物でちょっとした事に気付いたので、今回は番外編です。

内容は、「SubversionとGitの連携」です。

今の潮流はGit

さて、このブログをご愛読の皆さんはGitをご存じでしょうか?
使ったことの無い人でも名前くらいは聞いたことのある、世界的に有名なバージョン管理システムです。

細かい内容は専門サイトにお任せするとして、やっぱり最近はGitが流行ですよね。

流行の原動力となっているのは、こちら、GitHubが最大の要因でしょう。


まあ、簡単に言ってしまえばGitサーバレンタルサービスとでも申しましょうか。

オープンソースを開発してGitHubに掲載!!
今の時代はこれが世界で一番クールなIT技術者というイメージです。

プログラマーなら一度はオープンソースを作ってGitHubデビューしてみたいですね。

弊社はSubversion

しかし、バージョン管理システムはGitだけではありません。
他にも色々なバージョン管理システムがあり、その一つにSubversion(以下、SVN)があります。

弊社、ジェニシスでは主にこのSVNが使われています。

何故、GitではなくSVNを使っているかって?
そりゃ、前からSVNだからですよ。

今までSVNでソース管理してきちゃってるんだから、今更Gitに引っ越しなんて大変でしょ?

分かり易い事情としてご理解頂けると思います。(泣)

このため、私もGitを使う機会が殆ど無かったのですが、最近の連載であるAzureはGitを使う都合上で触っていたら、なーんだ。
既にSVN運用していても途中からGitデビューする方法があることに気付きました。

これが今回のテーマになります。

SVNの問題点

さて、何故私がSVNからGitに乗り換えることを画策するのか?
それはSVNには困った問題点があるからです。
それは「ゴミコミット」です。

まず前置きとして、SVNは特にチーム内で運用ルールを設けない限り、開発メンバーは以下のようにガンガンソースをコミットしてきます。



結果、このようにコミット履歴がボンボコボンボコ。。。
中にはミスコミットも混ざり込んでいることもあります。
リポジトリの肥大化が著しいですね。
これがゴミコメット問題です。




「だったらコミットルールを作れば良いじゃん?」

ってのはありますね。

  • レビューが完了するまでコミットしない。
  • コミットする時は複数人でコミット。

こういうルールにしておけばゴミコメット問題は発生しません。
しかし、これは面倒&非効率なのですよ。

実装者の立場としては、

  • ちょっと作って、動作確認。コミット。
  • ちょっと作って、動作確認。コミット。
  • ちょっと作って、動作確認。コミット。

これを繰り返したいのです。
そして何かミスってソースが壊れちゃった場合は、前回コミット段階までロールバック。
綺麗スッキリやり直し。

こうやって実装を進めるのが効率が良いのです。

しかし、「レビューが完了するまでコミット禁止」なんてやられるとこのテクニックが使えません。
あっちこっち未コミット状態になってしまって、何が何やら……。

逆にミスして変なバグが起きたりしないか、心配でなりません。



小まめにコミットした方が安全、合理的。

これは絶対そうなのですよ。
しかしこれだと上記のゴミコメット問題が発生する……。

Gitの利点

しかし、Gitだとこのゴミコメット問題が解消されます。


Gitでは本体リポジトリのクローンを自分のリポジトリに作って、クローンに対してコミットします。
そしてレビュー完了など万全な状態になったら、「プッシュ」を行うことで本体と統合!!

自分のパソコンに作ったクローンに何をコミットしようが本体リポジトリには影響がありません。

これで作業効率は高いまま、リポジトリへのミスコミット、ゴミコメットを防ぐことが可能になります。

これはぜひGit使いたいなぁ……。
でもウチの会社って本体がSVNだし……。

SubversionとGitの連携

ずっとこう思っていたのですが、Gitを触り始めて気がつきました。

本体SVNをGitクローン化。
これが出来るじゃありませんか。



本体がGitでなければGitは使えないと思っていたが、そんなこと無かった。

例えばTortoizeGitのクローン操作画面でも、以下のようにSVNからのクローンというメニューが出てきます。


Gitクローンを自分のローカルPCに作ったら、後は普通のGitと同じです。

本体がSVNである以上はGitの全機能が解放されているとは言えませんが、
少なくとも自分のローカルPC内ではGit機能がバッチリ使えます。

ゴミコミット問題もこれで解決です。

すぐに始めてOK

このGitクローンの好都合な点は、自分のローカルPCの中だけで完結する話だということです。

自分のローカルPCに何が起きても周囲に派生しませんし、
本体SVNから見れば普通にチェックアウトしてコミットしているようにしか見えませんからね。

今までSVNを使っているチームメンバー全員が一気にこのやり方に変更するのはチーム運用上手間がかかる話ですが、
このSubversion-Git連携の場合、自分一人だけコッソリGit活用していても周囲には何の影響もありません。

さあ、Gitを使いたがっているそこのあなた、さっさと移行してしまいましょう。

ただし、今までGitを使ったことの無い人は、事前にちゃんと使い方を覚えてからをオススメします。
微妙に高機能で複雑ですから。

例えば、当記事の「何度も作業コミットして、最後に一回だけ本番プッシュしたい」という目的の時に、
普通に「SVNへコミット」を実行すると、ご丁寧にも作業コミット履歴まで遡ってSVNに入ってしまってゴミコミット状態と何も変わらないという憤怒のオチになっちゃったりします。

事前に「一つのコミットに集約」をやっておくとか、Gitの機能を知っておかないと目的を果たせませんので、事前勉強は怠らないようにして下さい。



終わりに

既にGitを使っている人にとっては当たり前の知識かもしれませんが、
新しい技術領域にチャレンジしてみると、副産物でこういうチョイテクに気付くこともあるものです。

技術者たる者、アンテナは幅広く伸ばしていきたいものですね。

2015年9月24日木曜日

【Azure】ソースチェックアウト

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はMicrosoft Azureについて連載中です。
引き続き調査を継続していきます。

ソースを見たい

さて、前回までの記事の通り、AzureではWebアプリ作成時に最初からデフォルトで一通りのアプリがセットアップされた状態でスタート出来ます。
よって、Web上では既にソースが展開されているはずなのですが……、どうやってそのソースに手を加えれば良いのでしょうね?

どこかからチェックアウト出来るはず。今回はそれを探してみましょう。

ソース管理の統合

該当箇所はどこかな、と探していると、Webコンソールの最初の所にそれっぽいものがありました。

「ソース管理の統合」です。


トップページの一番下にありますね。
これを選択してみると……。


ふむ。
「デプロイの設定」というタイトルで一覧が表示されてきました。

  • Visual Studio Online
  • ローカル Git リポジトリ
  • GitHub
  • Dropbox
  • Bitbucket
  • CodePlex
  • 外部リポジトリ


色々ありますが、見た限りだと「Git」が目立つ印象です。
やっぱりGitにPushした瞬間にリリース完了、という手順が一番合理的なように思えますね。

話はそれますが、こんな所にDropboxが……。
画像とかドキュメントとかを共有したりクラウド活用したりする為のサービスだと思っていましたが、同じ要領でソースのデプロイにも使えるようです。
意外でした……。

さて今回、私は「ローカルGitリポジトリ」を選択したいと思います。


自分のパソコンにGitリポジトリを置いて、そこと連動するモードのようです。
これに当たって、私は先にGit本体と「TortoiseGit」をインストールしています。
WindowsでGitするならこれが定番でしょう。

では、次に進みます。

すると、ユーザとパスワードを登録する画面に来てしまいました。


んー。
AzureコンソールのログインIDとは別にデプロイ用のIDを必要とするようですね。

ここはIDは一緒にさせて貰った方がお手軽なのになぁ、と思う所ですが、
Dropboxとか別のアプリと連動する機能もある以上、別に権限管理しなければいけない技術的な都合があるのでしょうね。

お好みでIDを作成して次の画面へ。


おお。
心の準備をする前にGitリポジトリを作り始めてしまいました。ちょっと驚きました。

この辺りは外国製らしさを感じます。
日本のサービスだったら、きっと「Gitリポジトリを作成します。宜しいですか?」と確認メッセージが出て、そこで「はい」を押すと作成開始に進む流れだと思います。
しかし、外国製サービスでは問答無用で作っちまうというスタイルが多いです。

ユーザが作るつもりは無いのに間違えて作ってしまったら? その時は消せばいいのですよ。

  • 日本:間違えないように確認する為に確認画面を作成する。⇒工数高
  • 外国:間違えた? 修正画面で直せば大丈夫でしょ?⇒工数安

こういうノリなんですね。
日本人のおもてなし精神が垣間見える一面です。
しかし、その分だけ開発効率が……。なかなか悩ましい問題です。

さて、そうこうしているうちにリポジトリの作成が終わった模様です。


GITのURLをゲット出来ました!!

先ほど作成した私のIDがモロに出てしまっているので一部隠させて頂いていますが、URLをゲットすればこっちのもの。

後はコレをGit機能を使ってクローンしたりチェックアウトしたりすれば、無事にソースに触れるはずです。

続く

記事が長くなってきたので、ここから先は次回に回します。
しかし、かなり簡単に実現出来そうで好印象ですね。