2020-03-24

Lenovo ThinkPad のバッテリーが認識しなくなって泣きかけたけど復活した話

タイトルの通り。

ある日、仕事で使っている Lenovo ThinkPad（X280）を使っているところ、Lenovo のソフトウェアかハードウェアのアップデートが走ったので、とりあえず再起動。

で、再起動が終わった後しばらくするとこんなダイアログが表示される。

f:id:umezucolor:20200324195540p:plain

( ,,`･ω･´)ﾝﾝﾝ？

なんか、調子悪いのかな？

と思い、ダイアログメッセージに従って電源ケーブルを抜くと、、ブチッ。。。

( ;∀;)ええええええ

電源が落ちたではないか。。。

おかしい、何かがおかしい。

電源ケーブルを指して再度電源を入れる。

やはり数分後に同じダイアログが表示される。

おや？(;´･ω･)

バッテリーのインジケーターを見てみるとこんな表示に。

f:id:umezucolor:20200324195555p:plain

255%！！！！！！(´；ω；`)

明らかにおかしい。。。

仕方ないのでしばらく電源ケーブルを頼りに使っていたが、めちゃくちゃ不便（そりゃそうだ）。

これじゃーデスクトップ PC と同じやないか！！

色々と調べていく中で Lenovo Vantege と呼ばれるソフトウェアを起動し、システムアップデートを確認。

（インストールがまだの人はインストールが必要）

f:id:umezucolor:20200324195626p:plain

むむっ！！！

何かのアップデートが失敗している！！

しかも、よく見ると「Lenovo Battery Firmware Update Utility」のインストールが失敗しているではないか！！！

絶対コレやん！！！！

ということで、同ファームウェアのアップデートを再度実施。

再起動が求められるので、指示したがい再起動。

ふっかぁぁぁつ＼(^o^)／！！！！！！

無事にバッテリーを認識するようになりました！！

めでたしめでたし。

下記サイトも参考になりました！ありがとうございます。

hitoshi.blog

2015-04-12

Coveralls の導入

Travis

Coveralls の導入

前提

Travis との連携が済んでいる
参考: http://sue445.hatenablog.com/entry/2013/06/01/170607

最初は Cobertura で試した。

https://github.com/trautonen/coveralls-maven-plugin#cobertura

上記の手順を参考に設定したらうまくいったんだけど、プロジェクトが Java8 に対応している場合に失敗しだした。
ということでググってみると、解決策もあった。
http://www.befreeman.com/2014/09/getting-cobertura-code-coverage-with.html

確かにコレを実施すれば Java8 のプロジェクトでも Coveralls に連携されたんだけど...
何となく気持ち悪いな〜。

次に JaCoCo で試した。

https://github.com/trautonen/coveralls-maven-plugin#jacoco

こっちは、Java8 でも問題なく連携された！！
ということで、大きな問題がなければ JaCoCo のカバレッジレポートを Coveralls に連携する方向で。

以下、設定例。

<build>
    <plugins>
        <plugin>
            <groupId>org.jacoco</groupId>
            <artifactId>jacoco-maven-plugin</artifactId>
            <version>0.7.4.201502262128</version>
            <executions>
                <execution>
                    <id>prepare-agent</id>
                    <goals>
                        <goal>prepare-agent</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.eluder.coveralls</groupId>
            <artifactId>coveralls-maven-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <repoToken>yourcoverallsprojectrepositorytoken</repoToken>
            </configuration>
        </plugin>
    </plugins>
</build>

以下のサイトを参考にさせて頂きました。
http://d.hatena.ne.jp/tomute/20140408/1396971730

2015-04-12

ローカルで通るテストが Travis 通らない問題

Travis

最近覚えた Travis を使って、GitHub にあるプロジェクトを Travis で回してみる。
するとどうでしょう。

ローカルで通っていたはずのテストが通らない...
何故だ？？

失敗するのは Java8 で追加された Date-Time API を学習するために用意したテストケース。
旧 API である Calendar と新 API である LocalDateTime との相互比較。
Calendar で出来てたことを、新しい API だとどうするのか？というのの学習テスト。

で、今回失敗するのは以下のケース。
"時間" の比較で失敗している。

@Test
public void LocalDateTimeから旧Dateクラスへ変換が行われること() {
    LocalDateTime dateTime = LocalDateTime.of(2014, 4, 20, 21, 46, 9);
    ZonedDateTime date = ZonedDateTime.of(dateTime, ZoneId.of("Asia/Tokyo"));
    Instant instant = Instant.from(date);
    Date oldDate = Date.from(instant);

    // 検証用に変換(--> Calender)
    Calendar oldCal = DateUtils.toCalendar(oldDate);
    assertThat(oldCal.get(Calendar.YEAR), is(dateTime.getYear()));
    assertThat(oldCal.get(Calendar.MONTH) + 1, is(dateTime.getMonthValue()));
    assertThat(oldCal.get(Calendar.DAY_OF_MONTH), is(dateTime.getDayOfMonth()));
    assertThat(oldCal.get(Calendar.HOUR_OF_DAY), is(dateTime.getHour()));  // ココで失敗する
    assertThat(oldCal.get(Calendar.MINUTE), is(dateTime.getMinute()));
    assertThat(oldCal.get(Calendar.SECOND), is(dateTime.getSecond()));
}

テスト結果は

Expected: is <21>
     but: was <12>

これが Travis だと失敗する。
う〜ん〜ローカルで実行すると成功するのに何故だ〜？？？

この結果の差を見てみると「9時間」...

...

もしやタイムゾーンが怪しい？

ということで ZonedDateTime と同じタイムゾーンを、変換した Calendar クラスにも設定してあげる。

Calendar oldCal = DateUtils.toCalendar(oldDate);

// 以下追加
TimeZone asiaZone = TimeZone.getTimeZone("Asia/Tokyo");
oldCal.setTimeZone(asiaZone);

ほんでもって再実行。

...

成功！！

恐らくだけど、Travis が実行されている環境 (サーバ？) のタイムゾーンが Asia/Tokyo じゃなかったから、そこで差が出たんだと思われる。
いや〜Japan で実行しているうちは気付かないところだな。
そもそもちゃんとタイムゾーンを設定してあげろよって話か。ハイ、スイマセン。

https://github.com/naotawool/learning_java/blob/master/src/test/java/naotake/learning/java8/DateTest.java

2014-08-21

初めての iPhone アプリ開発を振り返って

先日、初めて個人的に作った iPhone アプリがリリースされました。
折角なので、このアプリ開発に至った経緯とか、いろいろ思ったところを半分思い出として残しておこうと思う。

開発するに至った経緯

今回何故 iPhone アプリの開発をしようと思ったかというと、いくつか理由があるが一番は書店でとある雑誌を見つけたところから、今回のアプリ開発がスタートした。

iOSアプリエンジニア養成読本[クリエイティブな開発のための技術力/デザイン力/マインドを養う! ] (Software Design plus)

作者: 高橋俊光,諏訪悠紀,湯村翼,平屋真吾,平井祐樹
出版社/メーカー: 技術評論社
発売日: 2014/03/20
メディア: 大型本
この商品を含むブログ (1件) を見る

この書籍に書かれている内容を、今回のアプリ開発の中で結構実践して結構助かったりしたので、分厚い参考書とかよりもかなり役に立った。

それ以外にも考える理由はいくつかある。

仕事に結構余裕が出来て、定時後の自由な時間が増えた
昔一緒に仕事した人が、同じように iPhone アプリを作ったらしく、その話の中で「自分たちは折角技術者なんだから、自分たちの得意とすることを使わない手はない」という言葉がとても印象的だった
自分の爪痕を Apple に残したかった
自分の生活の中であったら便利だなーと思う機能があり、それが世に出回っていなかったぽいので、今回自分で作ろうと思った

色々思うところはあるけど、やっぱり大きいのは時間的余裕が出来たってところで、何か形に残るものを作りたいなーと。
しかも iPhone アプリを作るのに必要不可欠な Mac は手元にある。
これはやらない手はないだろ、という流れ。

開発時に考えた事、やった事、思った事、大変だった事

実際に開発に着手したのが 6月末頃。
そんでもって最初に Apple に申請を出したのが 8月頭。
なので、開発期間としては約 1 ヶ月くらい。

この短い期間で、かつ初めての iPhone アプリ開発という中で、いろいろ試行錯誤した点を箇条書きで残しておく。

考えた事

世の中にあふれているアプリの中で「ヒットするアプリ」とされるのは、必ずしもデザイン最高、機能充実とは限らないのではないか（もちろんゲームは除く）
個人的には、「ヒットするアプリ」というのはやはり『アイデア』が大事じゃないかと
かといって万人に「ヒットするアプリ」を作るのは難しい（それが出来たら起業でもしようかな）
であれば、まずはニッチな分野や人をターゲットにしてみる

やった事

まずはモックを作った。しかもペーパーモック*1で

　モックでは、大体の画面レイアウトや、大まかなアプリの仕様を考えるのに使った

個人開発だけど、ソースのバージョン管理は導入（BitBucket*2 を使った）
アプリの実機テストでは、TestFlight*3 を使った
審査に必要な iOS Developer Program には、実機テストのタイミングで申し込んだ
アプリのデザイン（今回はアプリのアイコン画像だけ）は、得意な人に依頼

思った事

ペーパーモックは良かった。Excel とかツールを使うよりも、アプリの画面くらいであれば、ペーパーモックでも十分イメージが掴める
ソースのバージョン管理を導入したおかげで、ある時点まで動いていたアプリが、とある改修で動かなくなったとしても、すぐに元に戻せる。安心感にも繋がる
TestFlight 超絶便利！！数人のテスターであっても導入すべきだと思った。理由としては、テスターを増やす手順も数ステップで済むし、不具合などの改修版をリリースする場合、TestFlight にそのアプリをアップロードしておけば、テスターはそこからダウンロードするだけで改修版をインストールできる。いちいちテスト用のハードを Mac に繋いで...なんてやらなくて済む
更に TestFlight へアップロードする用のアプリのビルド、及びアップロードまでを Jenkins を使って自動化。これはテスト段階での作業時間を大幅に短縮できたと思う
私のように絵心が無いような人は、デザイン周りを得意な人にやってもらうのが一番の近道だと思う。その際の権利周りとかは事前にしっかりね
世の中には「iPhoneアプリ開発」と銘打った書籍はたくさん出ているが、全てを購入する訳にはいかないし、必ずしも自分が欲しい情報が載っているとは限らない。そういう時には、ネットに転がっている先人達の知恵がとても役に立った。でも書籍も大事

大変だったこと

広告導入*4が思ったよりも大変だった。

　今回のアプリでは「タブ」＋「テーブル」を使用していたが、その画面で使用する Controller に、UITableViewController を使用していた
　しかし、後々広告を導入しようとしたときに、この Controller のチョイスミスが原因で、うまく広告が表示できなかった
　仕方なく、UITableViewController を UIViewController に変更。変更自体はそこまで大変ではないが、ある程度画面動作のテストが終わった後に発覚したので、細かいところの再テストまで出来なかった

リジェクトされた内容と対策

7月中の開発を無事に終え、さぁいよいよアプリの申請。
ネットの情報を見ながらなんとか申請を行ったが、（予想通り）あえなくリジェクト。しかも 2 回も(T_T)(T_T)。
その時にリジェクト理由と、それに対応した内容を残しておく。

1回目のリジェクト(T_T)：「使い方が分からないから、使い方の動画を撮ってそれを送って」

ぐぬぬ...確かにデフォルトロケールは日本語だから、英語対応とかは今回していないんだが...使い方が分からないと来たか。
という事で、ググってみると同じ理由でリジェクトされた人も結構居て、その人達の対策案を私も実践。

まずは QuickTimePlayer を使って、Xcode の Simulator の画面をキャプチャして動画を作成
それを　iPhote 使って編集して、YouTube にアップ
YouTube のリンクをレビューコメントに記載して、再申請

2回目のリジェクト(T_T)：「動画Thank you。でも、iPad で動かないから対応して」

これ原因解明に苦労しました。
私の持ってる iPad2 の実機でも問題なく動くのに何でだよーー
かといって検証するために新しい iPad 買うか...正直そこまでの余裕は...○｜￣｜＿
対応方法に行き詰った...

と色々試していく中で 64bit の Simulator で動かない事が判明。
しかも 64bit は iPad だけじゃなく、iPhone でも動かない。何だってーー
そして色々調べていく中で、どうやら 64bit 環境で動かないのではなく、英語ロケール環境で動かないという事が発覚。

理由は単純で、Storyboard を英語ロケールに対応させてなかったことが原因。
Storyboard を英語ロケールにも対応させて、一旦英語ロケールでも 64bit 環境でも動くことを確認。

しかし、これが指摘の本当の原因かどうかは正直微妙な所ではあったが、もうこれで動かないと言われたらお手上げ状態。
なので、レビューコメントに「これで動かなかったら、その時のオペレーション手順と、検証で使用したハードウェアの情報を教えて下さいテスター様」と書いて、再々申請。

一週間後...

早朝 6時過ぎに Apple からメールが！！

The status for your app, is now Ready for Sale.

iTunes Connect でもステータスが「Ready for Sale」に！！！！
やったーーーーー！！審査通った！！！！
いやー朝からテンション上がった！もう目も覚めたわ！

そして数時間後には AppStore 上で作ったアプリが見れる...(T_T)
感動...(T_T)
いやーホント良かった。

今後の課題

実際の仕事では「UT書かないなんてありえないっしょ」と偉そうなことを言っていたが、今回のアプリ開発では UT を一つも書けなかった...○｜￣｜＿
次は UT 書こうと誓いましたとさ。

おしまい。

*1:http://www.matthewstephens.com/wp-content/uploads/2012/09/iphone5-templates.pdf

*2:https://www.atlassian.com/ja/software/bitbucket/overview

*3:https://testflightapp.com/

*4:今回は AppBank Networkを使用：http://nw.appbank.net/

2014-03-05

YiiでPHPUnitでJenkinsで

Yii

Yii のプロジェクトで書いた PHPUnit のテストコードを、Jenkins で回したい場合の設定内容について覚書。
そんなニッチな需要がどこまであるか知らないが．．．

本当は、phpunit.xml は 1 つで、phpunit 実行時のコマンドだけで切り分けたかったのだが、
調べた感じだと xml を分ける以外に方法が分からなかったので、この方法法となっている。
もしかしたら、もっとスマートな方法があるかもしれない．．．ぐぬぬ

PHPUnit

純粋にテストの件数やテスト結果だけを確認したい場合は、この設定を用いた方が良い。
なぜなら、後述するカバレッジ計測まで行うと、べら棒に実行時間が掛かるからである。
（Java であれば、カバレッジ計測したとしてもここまで遅くはならないと思うのだが．．）

使用した phpunit_only.xml はコチラ。

Windows バッチコマンドの実行

cd protected\tests
phpunit --configuration phpunit_only.xml --log-junit junit.xml

JUnit テスト結果の集計

テスト結果XML に「protected/tests/junit.xml」を入力

PHPUnit ＋カバレッジ計測

上記の PHPUnit 実行に加えて、カバレッジ計測も行いたい場合は、この設定。
上記のように --configuration のオプションを指定しなかった場合、カレントディレクトリにある「phpunit.xml」という名前のファイルが自動的に使われる。

ちなみに、PHPUnit の実行結果からカバレッジを出したい場合、「Jenkins Clover PHP plugin」というプラグインを Jenkins に入れる必要があるのでご注意を。

使用した phpunit.xml はコチラ。

Windowsバッチコマンドの実行

cd protected\tests
phpunit --log-junit junit.xml --coverage-clover clover.xml

Clover PHP カバレッジレポートを集計

・Clover XMLパス
protected/tests/clover.xml

・「Clover HTMLレポートを公開する」にチェック
・Clover HTML レポートディレクトリ
protected/tests/report

JUnit テスト結果の集計

テスト結果XML に「protected/tests/junit.xml」を入力

追伸

なんで PHPUnit では、テスト失敗時にあそこまで時間が掛かるのでしょうかね。
成功する場合は 1 秒ほどで終わるテストも、失敗すると 10 秒では終わらないくらい時間が掛かる。
これって PHPUnit あるあるですかね〜。

2013-10-20

xDebug を有効にしたらエラーが出た

PHP

XAMPP でインストールした PHP の xDebug の設定を有効にしようと、以下の設定を有効にする。

[XDebug]
;zend_extension = C:\xampp\php\ext\php_xdebug.dll

↓

[XDebug]
zend_extension = C:\xampp\php\ext\php_xdebug.dll

その上で Apache を再起動しようとすると、以下のようなエラーが出てしまう。

zend_unmangle_property_name_ex がダイナミックリンクライブラリ php5ts.dll から見つかりませんでした。

起動自体はするものの、なんだか気持ち悪いので、解決策を残しておく。

で、解決策

とっても簡単。
以下のようにパスを変更すれば OK。
そうすれば、エラー無く起動できるはず。

[XDebug]
;zend_extension = C:\xampp\php\ext\php_xdebug.dll

↓

[XDebug]
zend_extension = php_xdebug.dll

んが、エラーは無くなったものの、それ以外の詳しい動作確認はしていないので悪しからず。

2013-09-07

Gii の拡張

Yii

Gii の拡張

Gii で生成される Model のテンプレートを日本語向けに拡張してみたくなったので、拡張から導入までやってみたお話。
ちなみに参考にしたのは Yii framework バージョン 1.1.14*1。

デフォルトのテンプレート

https://github.com/yiisoft/yii/blob/1.1.14/framework/gii/generators/model/templates/default/model.php

それに対して拡張したテンプレート

https://gist.github.com/naotawool/6472758
これを、[yourapp\protected\gii\model\templates\extend\model.php] のように配置する。
※ちなみに、templates配下のフォルダ名は何でもOK

導入

その後、main.php の gii の設定に「generatorPaths」を追加する。

'gii'=>array(
    'class'=>'system.gii.GiiModule',
    'password'=>'gii',
    // If removed, Gii defaults to localhost only. Edit carefully to taste.
    'ipFilters'=>array('127.0.0.1','::1'),
    'generatorPaths'=>array(
        'application.gii',
    ),
),

使ってみる

あとは、Gii の画面を開いて、画面下部の「Code Template」から、拡張したテンプレを選択すれば、それが使われる。
（「Code Template」が選択できるのが分かりにくいけど。。実は「Base Class」とかも編集できたりする）

ちなみに今回は「Model」テンプレートの拡張版。
拡張したポイントは以下の 2 つ。

クラスの PHPDoc に、プロパティ名に対する論理名を付与（DBのコメント値を表示）
インデントを「タブ」から「半角スペース 4 つ」に変更

他に余裕や要望があれば、「Controller」とかも拡張していこうかしら。

*1:https://github.com/yiisoft/yii/releases/tag/1.1.14

前提

最初は Cobertura で試した。

次に JaCoCo で試した。

開発するに至った経緯

開発時に考えた事、やった事、思った事、大変だった事

考えた事

やった事

思った事

大変だったこと

リジェクトされた内容と対策

今後の課題

Windows バッチコマンドの実行

JUnit テスト結果の集計

PHPUnit ＋ カバレッジ計測

Windowsバッチコマンドの実行

Clover PHP カバレッジレポートを集計

JUnit テスト結果の集計

追伸

で、解決策

Gii の拡張

デフォルトのテンプレート

それに対して拡張したテンプレート

導入

使ってみる

PHPUnit ＋カバレッジ計測