「Kanazawa.rb x Hokuriku.NET x JAWS-UG北陸」に参加してきた

Kanazawa.rb x Hokuriku.NET x JAWS-UG北陸 : ATND

メモはこちら。

感想。 ・JAWS Toyamaが出来るらしい。手伝えることがあれば、手伝いたい。 ・北陸はやっぱり、クラウドとかの勢いは弱い。 　けれど、関東と比べてそれほど比率が低いわけでは無さそう。 　現に、このイベントは満員。 　ただ、人口がそもそも多くないし、意識高い系の人数は少ない。 ・金沢・福井のコミュニティは比較的回っているらしい。 　富山はあまり上手くいっていない。 　勉強会などを開いても、人を集めるのが大変。 ・ITなおっさんらが集まると、IT大喜利が始まる。

内容。 ・AWS Lambdaは来そう。 　Tokyoリージョン来るまでにちょっとぐらいやっておこう。 ・Azureも頑張ってるらしい。 　イベントのストリーム処理は必要になってきそう。 ・Dockerとk8sの概要はなんとなく理解できた。 　Docker自体は、小規模に使っていくだろうけど、どこまで使うだろうか。 ・ポータビリティとしてのDockerは、あまり考えてなかった。 　けど、たしかに。 　結構ゴタゴタしてるし、Docker大丈夫かとも思ってたけど、もうちょっとやっておいた方がいいのか。 ・便利なSaaS、いっぱいあるな。 　PaperTrailとか、そろそろ使っておいた方が良さそう。

あれ、やることいっぱい。。。

エンジニアだけど、ポートフォリオっぽいもの作りました

twitterなどのURLを、このHatena Blogにしてました。 そうすることで、自分の書いた記事や自分のアプリを紹介できてると思ってました。

ふとしたときにスマホで見てみると、サイドバーのアプリへのリンクが全く表示されてなかったのです。 これはまずい、ってことで、アプリの紹介をメインに、保持スキルも紹介できるようなページを作ってみました。

それがこちら↓
Ishikura Noboru portfolio

BEMもどきだったり、jade / stylusで作ったりと、フロントについてもいろいろ頑張りましたが、それよりも公開までのプロセスを一番頑張ったと思います。

というわけで、具体的な話。

コードリポジトリ

リポジトリは、 noboru-i/noboru-i.github.io · GitHub です。

ただ、masterブランチには成果物しか置いておらず、こちら noboru-i/noboru-i.github.io at src · GitHub にソースを置いています。

開発

gulp serve によって、インクリメンタルにビルド・ブラウザのリロードを行っています。
ほぼ、会社の同僚が書いていたのの劣化コピーですが。

/gulp/task に個別にタスクを記述したり、config.coffee にパスを一括で定義したりしてます。

詳細は、本人の記事を確認してもらえばと思います。

qiita.com

CircleCI

circle.yml に設定が書いてあります。

• masterは生成結果なので、CircleCIの処理対象外にしています
• nodeのバージョンは最新がいいだろうと思って、とりあえず0.12にしています
• srcブランチに対して、script/deploy.sh を実行しています。

script/deploy.sh にデプロイの手順が書いてあります。

• npm run build により、package.jsonに定義されている通り、gulpのdefaultタスクが実行されます
• gitの設定として、メールアドレス等を設定しています
• publicの中身をtarにまとめてArtifactとして保存しておきます
• public内をgitのリポジトリとして初期化し、リモートをnoboru-i/noboru-i.github.ioに設定します
• このブランチにcircle.ymlが存在しないと、デフォルトの動作が実行されてしまうので、circle.ymlをコピーしています
• 強制的にgit add, git commit, git pushしています

イメージ図

全体としては、こんな感じ。

感想

GitHub Pagesは便利なんだけど、ソースと生成物を一緒のリポジトリに入れちゃうのは嫌だし、手動のビルドでビルド漏れも嫌ですし。

その点、リポジトリにあるコードをCircleCIでビルド・デプロイするのは、必ず・クリーンな状態で公開できるため、メリットは大きいと思います。

仕組み部分は、それなりにいい感じに出来たと思うので、酷評されてるデザイン面と、BEMもどきって言われたCSSの命名をがんばってみようかとか思ってます。

iOS証明書の期限が切れたので、再取得する

前提

• 昔、証明書を作った
• 今、期限が切れている
• とりあえず、申請用の証明書を再取得したい

手順

キーチェーンアクセスを起動します。 期限、切れてますね。。。

メニューから、証明書アシスタント -> 認証局に証明書を要求... を実行します。

証明書アシスタントが開くので、メールアドレス・通称が設定されていることを確認、ディスクに保存を選択して、続けるを押します。

証明要求が作成されました。 CertificateSigningRequest.certSigningRequest が保存されたと思います。

iOS Dev Centerを開き、Certificates のAllを選択します。 「＋」を押します。

ProductionのApp Store and Ad Hocを選択、Continueを押します。

Continueを押します。

先ほど作成した証明要求（ CertificateSigningRequest.certSigningRequest ）を選択し、Generate を押します。

生成されるので、Downloadを押します。ios_distribution.cer が落ちてきた気がします。

iOS Distributionの行が増えてますね。

行が増えてますね。

続いて、Provisioning Profileを作ります。 Expiredだらけです。

今回はDistributionのものを取得したいので、それを選択し、Editを押します。

選択されてるCertificatesが無いので、選択し、Generateを押します。

再生成されました。Downloadを押すと、 XXXX.mobileprovision がダウンロードされたと思います。

これで、申請用のipaは作れるようになりました。 同じように、AdHoc/Developmentのprovisioningも出力できそうです。

PUSH通知の証明書も切れてるので、再生成が必要です。 Apple、面倒ですね。。。

AndroidのGradleでbuildTypes毎にtaskを作成する方法

前提

build.gradleにて、下記のように書くことで、buildTypesを増やせます。

buildTypes {
    hoge.initWith(buildTypes.debug)
    hoge {
        applicationIdSuffix ".hoge"
    }
}

これだけで、 assembleHoge とかは作成されます。

src/main と同じように、 src/hoge ディレクトリを作り、そこにファイルを配置することで、それらで上書きすることが出来ます。

本題

作成した hoge 環境と、元々ある debug , release それぞれにタスクを定義したいとする。
（各環境事のapkファイルを、ゴニョゴニョやる必要がある、とか。）

GradleでAndroidアプリを起動するタスクを追加する - インターネッコはじめました

の丸パクリですが。

とりあえず、下記のように定義できる。

android.buildTypes.all { theBuildType ->
    def buildType = theBuildType.name

    task ("exe${buildType.capitalize()}", dependsOn: "prepare${buildType.capitalize()}") << {
        // 何かを実行したり
    }

    task ("prepare${buildType.capitalize()}") {
    }
}

この場合、

./gradlew exeHoge

とか、

./gradlew exeRelease

とかが出来る。

「2015 新春 JJUG 特別企画 Jenkins まつり」に参加しました

http://jjug.doorkeeper.jp/events/19259

先に感想

• Oracle来たこと無い（あったかも。忘れた）と、どこ行っていいかわからんかった。
• スーツ率高め。7割ぐらい？
• Slack使ってる人がほとんど手が上がらなかったのが、ちょっと衝撃的。
• プラグインいっぱい。実運用する前に、プラグインテスト用の環境が欲しい。作ろう。
• UrbanCodeは、自分がエンタープライズじゃないからあんまり関係無い気がした。
• 川口さんの話は、最初何を話しているのかわかんなかった。ついていけてからは面白かった。
  • 広い範囲を上手く自動化していきたい。
• 荷物だけあって、結局誰も来なかった席は何だったんだろう。

Javaユーザに贈るJenkins 25のTips

Javaユーザに贈るjenkins 25のTips

Jenkins実践入門書いた人

必須

• Gitプラグイン
  Validated Mergeプラグイン（エンタープライズ限定）
• Githubプラグイン
  webhookでプッシュ。ポーリングじゃない。
• Gradleプラグイン
  gradleラッパーでもできるけど、スレーブとか使うとき便利

コーディング中のやつ

• checkstyleプラグイン
• FindBugsプラグイン
• TaskScannerプラグイン
  TODO / FIXMEを警告にしてくれる

ジョブの設定系

• JobConfigHistoryプラグイン
  設定の変更履歴を見れる。
  ビルド履歴にハンマーマークが出てくる。前回との設定の差分も見れる。

コンソールを見やすくする系

• Timestamper
  コンソール出力にタイムスタンプを表示できる。経過時間も見れる。

自分色に染める

• Emotional Jenkinsプラグイン
  Jenkinsおじさんが3变化する
• chuck norrisプラグイン
  チャックノリスさんに
• GreenBallsプラグイン
  青をグリーンに変えられる
• Nested Viewプラグイン
  パイプラインプラグイン使った時に、階層構造で表示出来る。

プラグインじゃないTips

• JUnitのテストレポート表示
  JUnit互換で出力させると、Rspecの結果も表示できる。
• マルチ構成プロジェクト
  Safariはmacだけ、とかをフィルターで出来る
• パンくずメニューでショートカット
  いろんなメニューが出てくる。 画面遷移を減らせる。
• コンソールにジャンプ
  ビルド中の青いメーターをクリックすると、コンソール出力を見れる
• safeRestart
  /hostname/safeRestartにアクセスすると、再起動出来る

CIを制す

• Deployプラグイン
  Glassfish / jboss / tomcat に対応
• Xvfbプラグイン
  仮想ディスプレイで、Seleniumなどのブラウザテストが出来る
• Build Pipeline Viewプラグイン
  Jobの流れをGUIで見やすい
• Promoted Buildsプラグイン
  だれかが承認した場合のみ実行
  3つの並列テストが全て通ったら、とか。
• Workflowプラグイン
  一杯プラグインが入る。
  Groovy DSLでジョブを書けるようになる。
  スニペットもある。

CIを制したら

• Slackプラグイン
• Email-extプラグイン
  メールの細かい宛先設定など。
• Disk Usage プラグイン
  ディスクをいっぱい使ってると、使ってる感が見える。
• Monitoring
  CPUとかメモリとかをモニタリング出来る。グラフで。

Jenkins実践入門は改訂予定のため、まだ電子化されない

継続的インテグレーションから継続的デリバリーへ

• エンタープライズを意識した話。
• 開発部門がさわれなかったり、上長の承認が必要だったり。。。
• 本：継続的インテグレーション入門、オライリーのJenkins
• 本：継続的デリバリー
• ツールの共有が難しい。Dev vs Ops。思いの違い。
• 組織が大きくなっていくと、分担・チェックが多くなる
• CI：ビルドジョブの組み合わせ→CD：環境毎
• CDの領域はDevとOpsが重なる

UrbanCodeの説明・デモ

• プッシュボタン・デプロイメント
• D&Dでフローを作れる
• 細分化したViewもある
• プラグインの活用
  Jenkinsとの連携とか、メインフレームに対するデプロイとか
  Groovyで書ける
• 環境ごとのリリース状況を視覚的に見れる。どのバージョンが入っているかをみれる。
• 品質ゲートの設定
• リリース承認プロセスの定義
• リリース状況のリアルタイム確認
• ログインユーザに依る権限管理

Jenkinsとの違い

ビルドに焦点を当てているか、リリースに焦点を当てるか。

Chef/Puppet + Jenkinsによる継続的デリバリ

会社紹介

• CloudBees
  • Jenkins Enterpriseなど、Jenkins周りの開発・サポートなど

背景

• より広域なend-to-endの自動化
• jenkins-ci.org 運用上のニーズ

個々のサービスをコンテナ化

サンプル。 https://github.com/jenkins-infra Puppetの中の人のベストプラクティスが詰まっている。

• git -> Jenkins -> docker
  • jenkins-infra/ircbotとか
• rspec-puppetによるプルリクエストの検証
  • jenkins-infraというコントロールリポジトリ。puppetのmanifestの集合。環境＋ビルド番号を持っている。
  • まずは文法チェック＝rspec-puppet。
• serverspecによる一時サーバでの検証
  • vagrantに適用してみる。EC2でやっている。EC2でやることで、並列に高速に実行できる。
  • Vagrantfileに書いてある。
  • 今はmasterに対してだけやっている。金があれば、Pull Request単位でもいいんじゃないか。
• r10k + puppet enterprise
  • ブランチ名＝環境名になる。
• 環境別の際を吸収するHiera
  • 階層構造も自由に出来る -> yamlファイルに外出し
• 鍵・秘密の情報の取り扱い
  • dockerのpackageに入れなくていい
  • hiera-eyaml でパラメータの個別暗号化。eyamlというエディタで変更 -> 保存すると暗号化。鍵は別に保存しておく必要がある。
• ブランチと環境の関係
  • Pull Requestをマージすると、自動的に本番に反映される、とか。
    ビルド履歴がGitHub上に残る。

継続的デリバリの課題

• 実際にいつ起こったのか
• 現在のサーバで走っているのはどのビルドか

ファイル指紋

• md5 check sum。
• 自動的に指紋を取る
• テストとビルドが関連づいていなくても、追える
• デモ
  • Jenkinsでビルド -> 手動でデプロイ（デプロイ結果をJenkinsに通知） -> Jenkinsでテスト
  • Promotionプラグインを入れておくと、デプロイされたことが星印で出てくる
• いつ・なにが・どこにデプロイされたのかを確認できる
• Chefとpuppertにしか対応してないけど、拡張可能な形式で作ってある
  • Chefはカスタムレポートハンドラーとして実装

今後の予定

• データの可視化
• ファイルじゃないのもの指紋
• jenkins-ci.orgの運用でも使っていく

from 2014 to 2015

あけましておめでとうございます。

2015年が始まり、数日経ってしまいましたが、2014年のまとめと、2015年の目標を書いておこうと思います。

2014年にやったこと

仕事

• 初のオフショア開発リーダー（？）

短納期で、途中からの引き継ぎだったで、ちゃんとチームでやる気もなく、やってる暇も無かった。
そんな状態かつ、初のオフショアだったもんで、出来たコードが自分の思ったのと大幅に違い、最低限は自分で作りなおすという暴挙にでる。
オフショア恐怖症が、完全に発症。自分がオフショア使うぐらいなら、会社辞めるって公言するレベルに。
お陰様で、その後はオフショアと直接やりとりすることは無くなって良かったです。

• PM業務

iOSアプリの開発で、PM業務をやることになりました。
1回ぐらい経験しておこうかなーというのもあったので、タイミング的には良かったのですが、やっぱり面倒ですね。
見積もりから、外部設計を作り、内部設計を依頼し、実装を確認する。
しまいには実装もし始めたので、てんやわんやに。
やっぱり、マネージャーはマネージメントに徹しないとダメですね。
そして、私はマネージメントに向いてない。

• 初、業務でAndroidアプリ開発

iOSアプリは出来てる状態で、1ヶ月程度で作れという。
突貫工事で作ったため、いろいろとまずい部分があったまま完成はしたけど、上の都合でお蔵入り。
その後、別の方向性で同じ名前のアプリを作りなおして、そっちはちゃんと設計しました。
Butter Knife / lombok とかを使って、コード量の削減にも努めました。
いろいろとチャレンジ出来たので、楽しかったです。
要件がころころ変わるのは辛かったですが。

個人

• iOS版 詰め共円リリース（1月）

2013年9月にデベロッパー登録し、1月にようやくリリースしました。

• Raspberry Pi / IRKit買った（5月）

IoTのきっかけとして、買ってみました。 自宅の電気・エアコンなどを操作したかったのですが、めんどくさくなって放置してます。

• Androidアプリ SlideViewerリリース（9月）

Speaker DeckのAndroidクライアントが無かった and Web画面が見づらかったので、作りました。 スクレイピングの勉強になったし、自分ではいい感じに使っているんですが、DL数は伸びないですね。。

• Androidアプリ TetherSettingの収益アップ（9月）

全画面広告を導入したことにより、1日当たり100円前後だったのが、1日当たり800円前後ぐらいになった。

2015年にやること・目標

仕事

• 改善業務

1月は半分ぐらい引き継ぎに割かれるけど、それ以降は基本的に案件には入らず、引いた立場となります。
具体的に何をやるかは、まだ検討段階ですが、情報共有を推進したり、CI / CDを導入したりしていく予定です。
この活動によって、品質が上がったり、稼働時間を減らしていければと思います。

• リモートワーク

1月下旬か、2月の頭ぐらいに富山に戻ります。 （飲み会の席で社長もちらっと言ってたし、いいよね？酔ってて、正確には覚えてないけど。）
在宅での作業になります。
ちゃんとバリューを出せるかなど、不安満載ですが、頑張っていこうと思います。
ちなみに、「結婚すんの？」と言われますが、そうでもないっす。

個人

• 各アプリの改善

Android版の詰め共円は目下改修中ですが、それ以外のアプリも、CIを導入したり、Material Designに変更したりしていこうと思います。

• 本を読む

元々長いこと関東に住む予定も無かったので、物理的な本はあんまり買わないようにしていました。
電子書籍はそれなりに買って読んでたんですが、物理本は敬遠してました。
がっつり本棚買って、本も買って読もうと思います。

• スマートハウス化

本来の言葉の定義とはちょっと違う気もしますが、新しい部屋にいろんなデバイスを導入したいと思います。
IRKitとかはあるので、あとは hue とか買ってみようかなーと思ってます。

• 健康に気をつける

在宅での作業になると、何も考えないと、日に100歩も歩かない気がします。
27才になるので、多少は気を使った方がいいかなーと。
具体的に何するかは決めてないですが。。。

• アニメ見る本数を減らす

毎クール20〜30本ぐらい見てたっぽいです。
毎日1時間ぐらいをアニメに費やしていたようです。
無駄とまでは言いたくないですが、もっとやるべきこと・やりたいことがあるはずです。
減らしていこうと思います。

• 文章を書く技術をつける

前から気づいてたけど、文章作成能力が弱い。
読みやすい技術ブログが、なぜ読みやすいかを分析して、自分の力に変えていこうと思います。
ブログとか、社内の情報共有で、その成果を発揮したいです。

雑感

2014年は、結果、そんなに大きなイベントは無かったような感じです。
ただ、後半からは2015年に向けていろいろと動けた気がします。
このまま、いろいろと進めていければと思います。
個人目標はいっぱい書きましたが、それなりに達成したいです。

Travis CI と Slackを連携させる

準備

• Slackアカウント
• Travis CIアカウント
• travisコマンド（gemよりインストール）

GitHubと、Travis CIは既に連携済みの状態を想定しています。

手順

• SlackのIntegrationsより、「Travis CI」を追加
• 表示されている「Token」と、画面左上のアカウント名を覚えておく
• リポジトリのディレクトリにて、下記のコマンドを実行

travis encrypt "<account>:<token>" --add notifications.slack

• .travis.yml に下記のような記述が追加されている

notifications:
  email: false
  slack:
    secure: XXXXXXXXXX

• Slackに下記のように、緑色が出たら成功。

参考

Travis CI: Configuring Build Notifications

Referencing DOM nodes in Angular expressions is disallowed! が出たとき

Angularのイベントの最後にDOM操作を行っていました。

$scope.send = () ->
  $("#dialog")?.hide()

ng-click で上記の関数を呼び出していました。 そこで、タイトルのエラーが表示されてしまいました。

$scope.send = () ->
  $("#dialog")?.hide()
  ''

これで解決。 DOMをreturnしたらいけないっぽい。

参考：

AngularJS - Fix "Referencing DOM nodes in Angular expressions is disallowed" - Midgets standing on the toes of others

Codeigniterでヘッダの扱いでハマった話

仕事でネイティブアプリと通信するAPIのサーバサイド実装をしています。

アプリの強制アップデート機能を実装するために、HTTPヘッダに"App-Version"という項目を追加して、Inputクラスのget_request_headerで取得しようとしました。 最初にやってみた実装は下記の通り。

$this->input->get_request_header('App-Version');

で、取得できませんでした。

とりあえず、出力させてみようということで、下記を実行してみました。

log_message('debug', var_export($this->input->request_headers(), true));

で、ログを確認すると、キーがApp-versionになってました。

$this->input->get_request_header('App-version');

にしたら、無事、取得出来ました。

---

request_headersメソッド内のコメントを見ると、

// take SOME_HEADER and turn it into Some-Header

ってかいてあったから、versionの頭も大文字になるものだとばっかり。。。

CodeIgniterのバージョンは、2.1.4です。

最新のバージョンでどうなってるかはわかんないですが、こうゆうことが、ちらほら出てくるので、CodeIgniterはあんまり好きになれないんですよねー。。。

社内勉強会を開催しました

10/9の20時より、サーバ・インフラ社内勉強会を開催しました。
（自分が面接官をやらないといけなかった関係で、こんな時間になってしまいました）

参加者は下記のような感じ。

• 中堅Android・サーバエンジニア
• 中堅サーバ・インフラエンジニア（鹿児島からリモート！）
• 若手エンジニア
• 若手ビジネスプロデューサー（いわゆる営業）
• 中堅？フロントエンドエンジニア（最後の数分のみ参加）

スライドはこちら。

結構初歩的なことしか喋ってないですが、サーバやインフラのことを理解してない人には勉強になったんじゃないかな、と思います。
中堅の人にはツッコミを入れてもらい、私も勉強になりましたし。
「勉強会開いて下さい！」って言ってきたフロントエンドエンジニアが参加できなかったのは残念でしたがｗ
鹿児島からも発表してもらって、自分も勉強出来ました。

続くかも、って書いてますが、社外への常駐が増えそうなので、難しいかなーと思います。
まぁ、機会があればまたやってみたいと思います。