Eclipse デバッグメモ

このスライドがとても参考になるので、メモ。

www.slideshare.net

実は、Q5 の Eclipse で実行中の変数の値を書き換えられることをつい最近まで知らなかったという...。Visual Studio でできるのは知ってたけど、まぁ必要に迫られることがなかっただけかもしれない。

あと、Q31 を応用すると、簡易的に処理時間を計測できる。計測したいところの前後にブレークポイントを打ち、Breakpoint Properties で Conditional にチェックして以下のように書く。

System.out.println(System.currentTimeMillis());
return false; // ブレークポイントで停止させない

これでブレークポイントを通過したときに標準出力にミリ秒が出力される。

GitBook Tutorial

以下の続編です。

GitBook on Windows - kntmr-blog

今回、GitBook のデモとして、チュートリアルのようなものを作成しました。コンテンツは随時更新しようかと思います。(たぶん)

gitbook-tutorial.firebaseapp.com

GitBook でビルドしたファイルを Firebase Hosting にデプロイしています。一応、ドキュメントとして使える見栄えにはなってるはず...。

ソースコードはこちら。

GitHub - kntmr/gitbook-tutorial


以下、備忘録。

プロジェクトが一覧に表示されない

Firebase Console からプロジェクトを作成して firebase init で初期化したところ、作成したプロジェクトが一覧に表示されない。とりあえず、以下でプロジェクトの設定は追加できる模様。

> firebase init --project <project_id>

また、firebase deploy すると 503 が返る。しばらく時間を置いて再度試したら普通にデプロイできた。新しく作成したプロジェクトが利用可能になるまで少し時間がかかるんだろうか...?もしかしたらプロジェクトが一覧に表示されないのもこれが原因?

GitHub X CircleCI で実現する DevOps に行ってきた

GitHub X CircleCI で実現する DevOps に行ってきました。簡単に所感をまとめます。

peatix.com

所感

GitHub と CircleCI のような CI ツールを組み合わせることで、コードやレビューをオープンにして、開発サイクルを早く安全に回すことができるというのがポイントなんだろうと思われます。今回はどちらかと言えば入門的な内容だったかと思いますが、資料やデモがあってとても分かりやすかったです。テストがなければ CI の意味はあまりないかと思ってましたが、日常の手作業を自動化するだけでも CI と言えるというのは目から鱗でした。

早速、CircleCI を試してみようかな。ちなみに CircleCI は、Jenkins や Concourse とはどこらへんが違うんだろうか。そのあたり聞いてみればよかったか...。

以下、メモから抜粋。ただ、話を聴くのに集中しててちゃんとメモが取れてません...。スライドが公開されたらリンクを貼っておきます。

(2019/02/06 CircleCI のスライドを追記しました)

GitHubとCircleCIで実現するDevOps

  • DevOps の背景
    • 開発スピードをあげたい / 改善サイクルを回したい
    • サービスの安定性や信頼性は保ちたい
  • 開発サイクルを安定して高速に回す
  • DevOps を実践している企業としていない企業の違い☆
  • DevOps の原則☆
    • 開発チームとインフラチームには壁がある
      • 目指しているものが違う (改善 / 安定)
    • 「失敗をなくす」から「失敗を早く見つけて直す」にマインドをシフトする
    • 個々の変更は小さくする
    • 計測によって問題を早期に発見する
  • CI/CD
  • CI とは☆
    • 共通のテストを実行できるメリットがある
  • CI でできること☆
    • テスト、ビルド、静的コード解析、脆弱性チェック、テストサマリー
    • テストがなくても CI はできる
      • 作業を自動化するだけでも CI と言える
  • CI が解決する問題☆
    • 実行するテストの粒度は設定で制御できる
    • 静的解析によるコードの標準化
    • テストが失敗するコードをマージブロックして master ブランチを安全に保つ
  • CD とは☆
    • デリバリは環境への資産の配備のみ
    • デプロイには人間の手が入る
      • そこを自動化すると継続的デプロイメントと言える
  • デプロイ作業を自動化することで属人化やヒューマンエラーを防ぐ
    • 最近は CI/CD の設定をコードで書く (バージョン管理できる)
  • GitHub
  • 議論やアクティビティを GitHub 上で
    • 組織内で知識や専門性を共有する
  • GitHub Flow
  • PR のメリット☆
    • さまざまな議論やフィードバック
    • 開発の透明性をあげる
  • PR に CI を組み込む
    • レビューとテストが通るものをマージする
    • 早い段階でエラーに気が付くことができる
  • CircleCI の最新機能
    • ワークフロー (パイプライン)
      • スケジューリング、承認
    • Docker サポート
      • 2.0 ではいちばん推してる
      • VM による CI より高速にビルド可能
      • 本番環境のコンテナと同じ環境でビルドできる
    • 多言語サポート
      • Docker イメージがサポートしている言語であれば使える
    • テスト環境を統一 (yaml)
      • 設定をコードで書くことでバージョン管理できる
    • SSH デバッグ
      • ビルドしたコンテナをキャッシュしておいて ssh でログインできる
      • テストの再現やコード修正ができる (修正をそのままpushできるわけではない)
    • デプロイ
      • 主要なプラットフォームにデプロイ可能
    • Orbs
      • config をパッケージ化 (共通化) できる
  • GitHub の中でもある程度は CircleCI の情報は見れる
  • レビューとビルドが通ったものだけ master にマージできるなどの制御が可能
  • GitHub Actions
    • GitHub 上のイベントをトリガーにしてワークフローを実行する
    • アクションは Docker コンテナで定義
    • 簡易な CI/CD はできる
    • CI/CD ツールと共存するものという位置付け
    • CI/CD 以外の日常の作業を自動化する
  • CircleCI Japan
    • 日本のマーケットは大きい (日本のユーザーが多い)
    • 海外拠点としては日本が初めて
    • 日本語サポート
    • ドキュメントの日本語化
  • あとで読む

codezine.jp

ユーザー事例 (サイボウズ)

www.slideshare.net

  • 国内DC & AWS
  • 最近はクラウドサービスの活用が多くなってきた
  • オンプレ開発基盤は導入、運用、外部クラウドサービスとの連携が面倒
  • クラウド開発基盤は社内ネットワークと連携しにくい
  • GitHub 導入
    • svn から移行
      • master を壊さずにレビューできる
    • PR
      • 変更理由やレビューの経緯がオープンになる
      • チーム外から PR できたり
  • CircleCI 導入
    • Jenkins から移行
    • コンテナ内ビルド
      • CircleCI 公式 Docker イメージが使える
  • GitHub 連携
  • Performance Pricing Plan (従量課金)
    • コンテナ数の課金より無駄がない
  • DevOpsQA
  • インフラも継続的に
    • 1日1回 CI で VPC を削除して再構築
    • ゼロから環境を作成できることを保証する

正数や小数のみ入力を許可するテキストボックスコンポーネント

正数や小数のみ入力を許可するテキストボックスを Vue.js のコンポーネントとして作ってみました。一般的には type="number" を使うといいのかもしれませんが、今回はもろもろの事情により type="text" を使います。あと、Vue.js らしいところはあまりないです...。

サンプルコード

正数のみ入力を許可するテキストボックス

テンプレートは次の通り。

template: `
  <input type="text" :size="size" :maxlength="maxlength" v-model="value" @keypress="validate" @input="value=format(value)" />
`

@keypress@input で制御する。イベントハンドラは次の通り。

methods: {
  validate (e) {
    const charCode = (e.which) ? e.which : e.keyCode
    if (charCode > 31 && (charCode < 48 || charCode > 57)) { // 数字入力のみ許可する
      e.preventDefault()
    } else {
      return true
    }
  },
  format (val) {
    if (!val) {
      return ''
    }
    const replaced = val.replace(/\D/g, '') // 数字以外を除去
    return replaced ? replaced : ''
  }
}

@keypress では、keyCode で数字入力のみ許可するようにしている。ただし、これだと IME の入力が制御できない。仕方がないので、@input で数字以外を除去して上書き。泥臭い。

正数と小数のみ入力を許可するテキストボックス

テンプレートは次の通り。

template: `
  <input type="text" :size="size" :maxlength="maxlength" v-model="value" @keypress="validate" @change="value=format(value)" />
`

こちらは @keypress@change で制御する。イベントハンドラは次の通り。

methods: {
  validate (e) {
    const charCode = (e.which) ? e.which : e.keyCode
    if ((charCode > 31 && (charCode < 48 || charCode > 57)) && charCode !== 46) { // 数字と小数点の入力のみ許可する
      e.preventDefault()
    } else {
      return true
    }
  },
  format (val) {
    if (!val) {
      return this.prevValue = ''
    }
    if (/^([1-9]{1}[0-9]{0,1})(\.\d{0,2})?$/.test(val)) { // ##.##
      return this.prevValue = val
    }
    if (/\.\d{3,}$/.test(val)) { // .### => .##
      return this.prevValue = (Math.floor(parseFloat(val) * Math.pow(10, 2)) / Math.pow(10, 2)).toString()
    }
    return this.prevValue
  }
}

@keypress では、keyCode で数字と小数点の入力のみ許可するようにしている。今回、整数部2桁&小数第2位という形式で制限している。@input だと厳しい感じだったので、@change でフォーカスが外れたタイミングでチェックしている。前回の正常値を data プロパティに保持しておいて、不正値が入力された場合は前回の正常値で上書きしている。泥臭い。

まとめ

どちらも最終的に泥臭い感じになりました...。もう少しスマートにしたいところ。

あと、今回初めて知ったのですが、KeyboardEventkeyCode プロパティなど、割とよく使われているだろうと思われるプロパティがいつの間にか非推奨になっていました。代わりに keycode を使う模様。

developer.mozilla.org

正規表現でカンマの3桁区切り

備忘録。金額表示などでよくあるカンマで3桁ずつ区切るアレ。正規表現で実現できることを知りました。便利なのでメモ。

"123456789".replace(/(\d)(?=(\d{3})+$)/g, '$1,'); //=> "123,456,789"

現場からは以上です。

プログラミングはできるのにデバッグが下手なひと

この note の記事、なかなかおもしろいので未読の方はぜひ読んでみてください。

で、狭い観測範囲で恐縮ですが、こういうひとの特徴を考えてみました。

  • 問題の切り分けができない
  • 仮説を立てて検証できない
  • 原因の推測が正しくない

問題の切り分けができない

問題の切り分け、つまり、どこが正しくてどこが異常なのかを把握することができないということです。まずは問題の原因がどこにあるのか見極めることが必要です。「見極める」と書きましたが、経験による直感が働くときもあれば、適切に範囲を絞りつつ調べて原因の所在を特定することもあります。

また、大局的には切り分けられるけど、局所的に精査することができないひともいます。こういうひとは、デバッガを使ったりコンソールにテキストを出力しながらロジックを追うことをしません。あと、ログ(スタックトレース)を読まない。

得てして、このようなひとは「原因はここにある」という思い込みによる誤った判断によって問題の解決に時間がかかる傾向にある気がします。まずは目の前の現実をしっかり認識/把握することが大事。

仮説を立てて検証できない

仮説を立てて検証するということは、デバッグというかトラブルシューティングの基本かと思います。仮説を立てるにはある程度の経験や動作原理の理解が必要で、最初のうちは愚直に調べるしかないかもしれません。ただ、経験を通して引き出しが多くなっていくと、発生している事象からいくつか原因が思い当たるようになる気がします。脊髄反射的に原因を言い当てるひとも過去にいろいろなデバッグの経験を積んでいるんだろうと思われます。

あと、個人的に大事だと思うことは、仮説と想定する結果を書き出すこと、1つずつ試してみること(1度に複数のことをやらない)、(可能であれば)書き出した仮説をすべて試してみること。特に3点目については、副次的に別の事象が発見できるケースがあります。いわゆる、水平展開というものです。

手当たり次第ではなく、順序立てて分析することが大事。

原因の推測が正しくない

仮説&検証と若干内容が重複します。推測すること自体は大事なことですが、思い込みによって推測にバイアスがかかることがあるような気がします。少し落ち着いて考えてみれば見当違いであると思われるようなことを割と真面目に言われて唖然とするものです。

まずは仕組みや原理を理解することが大事。あと、最初からいろいろと推測し始めるひとがいますが、可能な限り手元の環境で再現確認しましょう。事象を再現させるところから始めて、切り分け、仮説&検証のプロセスを繰り返すことで、推測の確度を高められるのではなかろうかと思います。

まとめ

ここまで書いておいてあれですが、人間というものは気持ちに余裕がないと冷静な判断ができなくなりがちなので、これらは一概に言えることではないかもしれません。ただ、書いてて思ったのは「思い込み」というものは恐ろしいということ。

2018年のふりかえりと2019年のこと

年末&元日は帰省先で賑やかに過ごし、三が日が過ぎた今は自宅でマターリ。

2017年のふりかえりと2018年のこと - kntmr-blog

というわけで、基本的に何か目標がないとだめだめマンみたいなので、今年は英語勉強の目標として TOEIC で600点あたりを目指してみようかな。あと、どこかで Java 9 と Spring 5 は腰を据えて学ばなければ。現場からは以上です。

これのふりかえりと2019年のことでも書いてみようかと。

英語

2018年前半は進捗ゼロで、結局 TOEIC は受けられず。が、夏頃から『スタディサプリENGLISH』のプレミアム会員に登録し、通勤時間を利用して1日30分程度勉強しています。課金駆動学習。今年は1日1時間程度は勉強できるようにしたいところ。

eigosapuri.jp

Java & Spring

Java や Spring の新しい機能はなかなか試すことができず。ただ、Java のリリースモデルについてはそこそこキャッチアップできました。仕事で使わずとも新しいバージョンの情報は収集していきたいところ。特に、クラウド (サーバーレス) 関連の機能やフレームワーク/ライブラリはウォッチしておかねば。

その他

普段、仕事でクラウド関連のサービスを使う機会がなく、なかなか手付かずの状態だったのですが、2018年は AWS のオンラインセミナーを受けたり、無料枠でいくつかのサービスを試してみました。可能であれば仕事を通して AWSGCP などのクラウド関連のスキルを身に付けたいところですが、引き続き、基礎的なところは自己学習で補おうかと。ついでに認定でも目指してみようかな。

あと、全然たいしたものではないのですが、初めて GitHub で PR や Issue を投げてみました。


とりあえず、2019年は英語の勉強を中心にしようかと。まずはリスニングとリーディング。その他は必要に応じて。