ドコモスマホ（Xperia A2）のバッテリーを自力で交換しました

所有しているドコモスマホ（Xperia A2）のバッテリーが７５％ぐらいから急に０％になってシャットダウンする状態が続いたため、バッテリーを交換することにしました。

Xperia A2は裏蓋が開かない機種で、ドコモ窓口に持っていくと１０日ほど預ける必要があり、費用も９０００円ほど係ります。

預けるのはいいのですが、その間は代替え機で過ごす必要があるのですが、普段使っているアプリを入れ直したり、今まで撮った写真をバッグアップしたり、Lineのトークをバッグアップから移したりするのはかなり面倒に思えました。

ドコモの店頭に並んで、あれこれ手続きするのも面倒です。 そこで時間短縮のため、裏蓋を開けて、自分でバッテリー交換をすることにしました。どうせ２、３年は使ってきていて保証も切れています。 他の人のブログ記事も参考にして、自力でのバッテリー交換に挑戦してみました。

バッテリーが交換できないXperia[エクスペリア]を自力で交換する方法（ただし保証外） http://www.okuta.com/blog/yoshiaki_wakae/2016-02-19/xperia_battery/

分解手順（一部省略）

まずは裏蓋を開けます。裏蓋は、黒くて細い両面テープのようなものでシールされているので、裏蓋の隙間に薄いカードなど差し込んで丁寧に開いていきます。 両面テープが剥がれやすいように、ドライヤーも使いましたが、気休め程度でしょうか、吸盤を使うと楽という意見もあったのですがなしで頑張りました。

一箇所、スマホの下側が太い両面テープで固定されている箇所があってなかなかカードが差し込まれず、手間取りましたが基本、丁寧にゆっくり剥がしていきました。 　

バッテリーはスマフォ上部、左側のネジを外して、またスマフォ下部のバッテリーのコネクタをピンセットなどで外せば取り外しできます。 スマフォ上部のNFCの端子部分は、繋がっていないので、丁寧に外せば外れました。

取り外したバッテリーにNFCのアンテナがシールでくっついているので、QUOカードなどの薄いカードを差し込んで、丁寧にはがしていきます。

交換したバッテリーをスマホに収めて、NFCのアンテナを新しい両面テーブで貼り直して固定します。

NFCアンテナの接続端子を軽く固定している銀色の留め具が一回外れちゃったんですが、上から押し込んでもはまりません。フックに引っかかるよう斜めにして下から引っ掛ける感じです。 留め方がわからなくなるのでいっそ、丁寧に外しましょう。

バッテリーの接続端子は、純正品に比べるとちょっと丈が長いです。蓋を閉めた時に浮きやすいので、ピンセットなどで丁寧に押し込みます。 他の人のブログ記事では、端子が斜めになっているケースもあるようなので、その頃に比べればやりやすく改良されているようです。

端子を接続したら、一旦電源入れて確かめてみましょう。蓋を閉めてからもう一回、開け直すのは面倒ですから。

蓋を閉める前に、蓋を開ける時に接着していた、黒い両面テーブをケースに沿って這わせていきます。

角はピンセットなどで丁寧に。

実は、他の人のブログを参考に、Amazonで2mmの両面テープを、交換バッテリーと一緒に注文していたのですが、間違って5mmが送られてきたので、蓋を開ける時にシールされていた両面テープを再利用するしかなかったのです。 両面テープはかなり細いので、1mmのものでもよかったかもしれません。

ただし、下記のURLの3Mの両面テープは、もともと使われていたものと同一製品かどうかは私にはわかりません。防水性能があるのかもわかりませんので、バッテリ交換後はどちらにせよ防水性能は期待しない方が良さそうです。

1 mm * 50 メートル　3M 9080 Hi-Temp　両面テープ　LED 液晶パネル用接着剤 https://www.amazon.co.jp/dp/B00FU09OP2

最後に蓋を閉めて完成。両面テープで圧着し直す感じです。

防水性能は期待できなくなりましたが、３０００円に満たない費用と、数時間の手間でバッテリ交換することができました。 これで、お昼でバッテリーが切れて、他と連絡がつかなくなったりする問題もなくなります。 ドコモの窓口で１０日間お預けしている間、代替機にデータを移す手間を考えたら、時間短縮できてよかったです。

Sato Commerce Xperia Z1f LIS1529ERPC 互換バッテリー ( SO-02F ) 3.8V 2300mAh https://www.amazon.co.jp/dp/B01688KMQE

準備するもの

• 薄っぺらいカード （QUOカード）
• 精密ドライバー
• ピンセット
• 交換用バッテリー
• 1mm幅の特殊用途の両面テープ
• 見えない状況に対応する適応力
• 失敗を恐れる心とそれでも進む勇気
• 自己責任という確約

想定されるリスク

• 蓋をはがす時に、無理にはがそうとして蓋を変形、破損させてしまう。
• ドライヤーで温めすぎて電子部品を故障させる。
• 交換したバッテリがまた不良品。
• バッテリ交換後、防水性能を失った状態で水没させてしまう。
• データのバッグアップを取っていない為、データ完全に消失する。
• 他、上記以外の3つ以上のリスクが自分で思い浮かぶこと。

「納品のない受託開発」を語る会 から２年余

このブログを書き始めるきっかけになった、2013年の「納品のない受託開発」を語る会 から２年余り

yosshy79.hatenablog.com

２年前の当時は、『終わりのない受託開発』とでも命名してもいいような、「要件定義が出来ないから、何の合意も約束もないまま、丸投げされた、名ばかりのアジャイル開発」にアサインされていました。それを１年ぐらいかけて乗り切ったあとは、Web案件を離れて未経験のWindowsタブレットで動作する地理情報フレームワークの開発をするという過去に比べてとても平和な案件の日々を１年ぐらい過ごしてました。

普段の生業は、客先へフルタイムで常駐して働く、フリーランスのプログラマなので、「納品を目指して、納期を守る為に、時間単価計算」で働くのを日常としています。

自分はなぜ「納品のない受託開発」に切り替えないのか？

2015年の７月、Rubyビジネスフォーラム　に参加してに「納品のない受託開発」の話をもう１度聞いて、あらためて、そう考え、「常駐の仕事にやりかたに馴染んでしまった」事が制約になっていると結論づけました。

それでその制約を乗り越えるにはどうすればいいかを考えていると、「納品のない受託開発」をやりたい理由も、常駐の仕事をやり続けている理由も、それは「安定したキャッシュフロー生む」という、自分の中ではどちらも同じ方向を向いていることに気がつきました。

つまり、「納品のない受託開発」でも「常駐の仕事」も自分の中ではどっちでもやりたいことが出来る可能性があると気づき、「常駐の仕事」をやりながら「納品のない受託開発」の思想を取り入れ、ある程度割り切った仕事のすすめかたをして来ました。

私の仕事は、「納品を目指して、納期を守る為に、時間単価計算」で契約しています。

「納品」は区切りですが、その先にある「運用・サービス」をイメージしていますし、「ベストエフォート」で残業を押さえていますが、「納期」はだいたい守れています。「時間単価」での契約ですが、本当に売っているのは機能が提供する「価値」で、そこをお客様から評価してもらっていると思っています。

私はこれからも常駐型の仕事を続けていくと思いますが、少しづつでもいいので「時給で働く」ことから卒業して、「提供する価値」を評価される働き方にシフトしていって、契約も実態にそった形に切り替えていければいいですね。

DevLove関西「TOCを初めて知ってみる」に参加してみた

devlove-kansai.doorkeeper.jp

6/26にDevLove関西の勉強会でTOC（制約理論）を勉強してきました。

TOCについては、「ザ・ゴール」の小説ではなくて、漫画版の方を読んだことがあっただけでしたが、目標を実現する為の思考スキームだという認識で参加しました。

セミナーに参加した目標は「ものごとを全体的に考えられるようになる」としました。

最近は仕事の事や子供の事で、ずっと考えがどうどう巡りをしていて結論がまとまらないことが多かった為です。

内容は、風が吹けば桶屋が儲かるというような、原因と結果のツリーを図表化するといったものが主でした。

ワークショップでは、自分のやりたい目標とそれが出来ない制約をテーマにして、ペアどうして図表をつくり、別のグループに説明するというものでした。

ポイントとしては「解決策を見つけようとしない」方が疲れなくてよいそうです。

たしかに制約を書き出していって矢印を引いて、紙に書き出すだけで考えが整理されていくので、それだけでも意味はある様です。

学んだ事をもとに、家に帰ってからも同じ手法でプライベートでやりたい事を図表化してみました。

まず、私はボルダリングが趣味なので、やりたいこと（目標）を「子供（幼稚園児）にボルダリングさせる」としました。（図表の赤色）

できていない理由は「クライミングジムは小学校高学年から入会できる」からです。

やっていると、最初に決めた目標とは違う、「子供が小学校にあがっても授業についていくことができる」という本当の目標が見えてきました。

最初の目標は「自分がやりたいこと」でしかなかったのですが、本当に目標としなければならなかったのは「家族みんなの共通のゴール」だったのですね。

それに気づいてからは家族で話し合って決めたことと、自分のやりたいことがどうつながっていくのか整理することに始終しました。

上に書いた図は、あとで家族にも見てもらったのですが、そこで子供の習いごとに対する新たな意見や思いも聞く事ができました。それに伴ってまた図表を更新しなければならないのですが、図表にすることで家族での意思疎通のコミュニケーションの道具としても利用出来る様です。

セミナーではほんのさわりしか学べませんでしたが、家に帰って実際にやってみて初めて少しずつ身に付いてきた様に思えます。

講師の方からはおすすめの書籍として下記のものをおすすめされたのですが、ワークショップでやったのはここで紹介されている「ブランチ」という手法の様です。

Amazon.co.jp: 考える力をつける３つの道具 電子書籍: 岸良 裕司, きしら まゆこ

セミナー後 、講師の東さんが「TOCは５歳児から使える」と行っていました、子供の場合は、文章の代わりに絵で説明したもので矢印を引っ張って図表化するそうです。

たとえば、子供が「おかしを食べたい」というやりたいことがあればお菓子の絵をかいて、それが出来ない制約として「夕食が食べられなくなるから」という説明にお母さんがおこっている絵や夕食の絵を書いたりするそうです。

CodeIQのカラオケマシン問題を解いた

ソニックガーデン社員によりCodeIQに出題されたカラオケマシン問題のベストコード発表会がUstreamで7/8に放送されます。

http://sonicgarden.doorkeeper.jp/events/12901

CodeIQの締め切りは既に済んでいたけれど、問題がブログで公開されていたので遅れながらも解答してみました。

※注意　以下の文章は、まだ上記のカラオケマシン問題を解くつもりで、解いていない人にはネタバレとなってしまいます。

以下に最初に作った解答コードを掲載します。 

# coding: utf-8

class KaraokeMachine
  TONES = ["C", "C#", "D", "D#", "E", "F", "F#", "G", "G#", "A", "A#", "B"]
	
  def initialize(melody)
    @melody = melody
  end

  def transpose(amount)
    melody = ""
    sharpFlag = false
    @melody.reverse.chars {|tone| 
      if tone == "#" then
        sharpFlag = true
        next
      end

      if sharpFlag then
        tone += "#"
	sharpFlag = false
      end

      index = TONES.index(tone)
      unless index.nil? then
        index += amount
	index %= TONES.length
        tone = TONES[index].reverse
      end
      melody += tone
    }
    return melody.reverse

  end
end

rubyの文字列操作の処理しやすさを活かしたとすると、今の私ではこれぐらい。

アルゴリズムを簡素化するために、データを後ろから処理するようにした。

上記のコードを見直してみたものを以下に掲載します。

他のブログに、解答例を公開している人がいたので、それも参考にしました。

# coding: utf-8

class KaraokeMachine
  TONES = %w(C C# D D# E F F# G G# A A# B)
	
  def initialize(melody)
    @melody = []
    melody.chars {|tone|
      if tone == "#" 
        @melody[-1] += "#"
        next
      end
      @melody.push(tone)
    }
  end

  def transpose(amount)
    melody = ""
    @melody.each {|tone| 
      if i = TONES.index(tone)
        i = (i+amount) % TONES.length
        tone = TONES[i]
      end
      melody += tone
    }
    return melody

  end
end

基本的なデータ構造とアルゴリズムは、参考にした他者のブログの解答コードともはや同じです。

これならば、データ後ろから処理する工夫も必要もない。また、分岐を減らすためelse句を極力使わない工夫は残しました。

これを超えるアイデアで根本的にコードを奇麗にするのは私には無理かな。

ベストコードの発表が楽しみになってきた。

 7/8追記

放送を視聴した上で、もう一度リファクタリングしたコードを以下に掲載します。

正規表現を使うアイデアで見直しました。

rubyの標準APIを駆使してハッシュで変換テーブルを使うアイデアが紹介されていましたが、ruby実務経験が無い私には難しかったかもしれません。性能改善の観点でも良さそうですね。

またrubyの文化ではreturnはあまり書かないそうです。

# coding: utf-8

class KaraokeMachine
  TONES = %w(C C# D D# E F F# G G# A A# B)
	
  def initialize(melody)
    @melody = melody
  end

  def transpose(amount)
    @melody.gsub(/[A-G]#?/){|tone| 
      i = (TONES.index(tone) + amount) % TONES.length
      TONES[i]
    }
  end
end

勉強になりました。

プロジェクトの地獄天国を分ける要因の一つはコードの簡潔さだと改めて思いました。

homebrewでphpのimap環境を構築

PHPでIMapをやるための環境構築をしたときの覚え書き

開発環境はMac OS Xでパッケージ管理にはhomebrewを使用した。

homebrewでimapのオプションを利用するには先にimapも入れておく必要があるらしい。

brew install imap-uw

brew install php55 --with-imap

でOKだった。

勝手にSSLのサポートもONになっていた。

ただ、imap-uwを先に入れなければならないということが最初は分からず、自分でimap.tar.Zをソースからコンパイルしたものを使おうとしたり、だいぶ骨を折ったが、brewだけでできることが分かった。

分かるまでは試行錯誤の末、最終的にはbrewのFormulaの中身を覗いて、imap-uwを利用していることに気づいた。

Formulaの中身は下記の場所にあった。

/usr/local/Library/Formula/abstract-php.rb

最初はMAMPで環境を作ろうと思ったが、IMAPのSSLサポートがなくて、phpを再コンパイルしようかと思ったが、homebrewを導入してよかったと思う。

portやyumのパッケージ管理ツールの裏側の仕組みは正直よく分かっておらず、ツールが何をやっているのかよくわからないまま利用していた。

brewはどこにソースがダウンロードされていて、コンパイルされたものはどこに展開され、また、Formulaはどこに配置されているかなどがよく解った。

IMapで詰まったのが、brewの仕組みを調べるきっかけとなり、かえって良かったと思う。

Ruby On Rails系統のフレームワークの選定

　フレームワーク選定するにあたって、軽量フレームワークで、素早い開発ができるかどうかが、今のトレンドのように思える。

　一般論とは言えないかもしれないが、プロジェクトがうまくいくカギは２つあるように思える。

　１つは要件が確定していること。一括請負で一括納入することが前提だが、プロジェクトの期間の中盤を超えている状態で、要件が1割すら確定していない状態でプロジェクトの成功に希望を持てるだろうか？

　もう１つは、実装コードが軽量で、ＤＲＹな状態が保たれており、素早い開発がおこなえること。非常に重くて、カスタマイズの手の施しようのないソースを抱えていて、プロジェクト終盤の混乱の中で発生する仕様変更や、品質問題に耐えうる自信をプログラマは持てるだろうか？

　この両輪を揃わないと、プロジェクトの収束は難しい様に思われる。

　そこで収束の為の1輪として期待されるのが軽量なフレームワークであること。代表的なものに規約により従来よりもコード量を削減することができるRuby on Railsがある。

　ＰＨＰならＣａｋｅフレームワークがあり、ＪａｖａならＳＡＳｔｒｕｔｓや、Ｐｌａｙフレームワークがある。

　正直どれでもいい。プロジェクトを完遂するためのコントロールを握ることができるなら。

　フレームワークの選定はだいたいが、いつも政治活動になる。みんなやりたいものが違う。フレームワークなんて使いたくないという人もいる。トップダウンで決められてしまう場合もあるし、既に決まっていて、開発も始まっている状態が多い。

　すでに決まったフレームワークをひっくり返すのは、難問だ。でも、やらなければいけないときはあると感じている。

　必要なのは「本当に今のフレームワークである必要があるのですか？」という前提を疑う問いを起すことと、「今のフレームワークを最後まで使い続けるのと、それをやめて新しいやつで1からやりなおすのと、どっちが早い？」という問いに明確に答えることが出来ること。

　どっちが早いかという問いに答える為の材料が必要だ。チェックポイントを検討してみよう。なお、プロジェクト完遂のための両輪のうちの1つは整ったことにして、ここではその事には言及しない。

　例えば、政治的な理由からＣａｋeＰＨＰが一番、異論が少なく、協力者も得られそうだとして、それを候補にあげるとする。

　チェックポイントとして次のような点があげられる。こっからは技術の話。

　１、フレームワークは軽いか？コードを書くときに少ないコードで書けるか？学習コストは低いか？

　２、フレームワークに変な癖がないか？

　３、画面回りの作りこみは楽か？テンプレートエンジンなどは利用できるか？

　４、データベース周りの実装はややこしくないか？ＳＱＬクエリ自由に書くことができるか？

　５、スキャフォールドでどこまでできるか、むしろ、どこまではできないか？

　６、ライブラリは使えるものが多いか？

　７、技術的な資料や情報は多くあるか？日本語で情報があるか？

　８、周りで、既にプロジェクトに使っている事例があるか、できればソースコードが共同所有されているか

このあたりで引っかかるところがなければ、混乱の中でコントロールを握りやすい。

　「本当に今のフレームワークである必要があるのですか？」という問いの答えを相手の頭の中に考えさせることさえができたら、後は「どっちでやった方が早いか」という問いに明確に答えるだけで、すべて成る。

　それと「そのフレームワークを使ったら納期に本当に間に合うのか？」という問いには答えてはいけない。たとえ「はい」といえば、本当にフレームワークを変えることができるとしても。

AmazonWebServiceのEC2を利用する上での費用

　ＡＷＳを提案に入れようとすると費用は顧客にどう説明しようかと思い悩みます。

　ＡＷＳの料金表を見ても、細かくてよく分からない。ドル建てになるし、どういうことをすると、どれぐらい掛かるのか？

　ある程度、リスクを積んだ上で、プラン別の価格表をつくり提案するしかない。為替変動があったら価格表を改定したりとかする必要がある。

　いっそ、ユーザーが直接ＡＷＳと契約して、間に入っていかない方が話が早いんだが、受け入れられるかどうか？

　どちらにせよ費用感を持つにはやってみたほうが早い。

　たまたま、今の仕事でＡＷＳにデモサイトを構築してほしいという依頼がありましたので、手を挙げてやりましたとも。

　ＥＣ２＋ＲＤＳを利用した構成が理想なのですが、とりあえずＥＣ２の１インスタンスのみでＷｅｂサーバー、ＤＢサーバーをすべてを兼ねるという構成となります。

　仮想ＯＳはＡｍａｚｏｎＬｉｎｕｘを使いました。

　となるとたくさんの料金メニューがならんだ価格表から見るべき個所は限られてきます。

　いろいろ、はしょってしまうと。

　いくつかプランがあって、t1.microというのが一番安いのですが、メモリが６００ＭＢ相当しかありまん。あるオープンソースを入れたのですが、ＭｙＳＱＬサーバーが落ちて起動しなくなってしました。

　これはキャッシュを割り当てを１ＧＢに設定することで、ある程度持つのですが、オープンソースが重すぎたため、やむなくプランを１つ高いm1.smallに上げることになります。これはメモリは１．７ＧＢ相当です。

　普通ならデモサイト程度ならt1.microで十分のハズだと思います。

　では計算してみましょう。

 （単価）ＡｍａｚｏｎＬｉｎｕｘの場合 アジアパシフィック価格 

　t1.micro　$0.027/1h　　

   m1.small　$0.088/1h

　１日２４時間起動しぱなっしで、１か月放っておいたとすると、

　t1.micro   $0.027 × 24h × 30日 × １米ドル １００円 ≒ ２０００円

　m1.small $0.088 × 24h × 30日 × １米ドル １００円 ≒ ６０００円

　机上で計算すると上記が目安となるのですが、実際は違うと思う。

　お客様に費用感を説明できるようになるには、実際にやってみるしかない。

　ＡＷＳでビジネスをしたい人は、さっさとＡＷＳをサインアップして使ってみるべきだ。１年間の無料利用枠なんて正直いらない。でもお客さんには１年間の無料枠でどこまでできるか説明できなくてはならない。

　なお、デモサイトぐらいにしか使えないが、必要な時だけ起動すれば安く上げることもできます。ただし、ＩＰアドレスが、つまりＵＲＬが起動するたび変わってしまいます。

　ＵＲＬが毎回変わるのが困る場合はＥｌａｓｔｉｃＩＰという、固定ＩＰを割り当てる別のオプションサービスがあり、オプション費用がかかります。

　１割り当てはまでは無料かと思ったら適用条件があり必ずしもそうでない。

　これもお客様に説明できるようにならないといけない。

　他にもリザーブドプランなどお得なプランがあるようです。

　これもお客様に説明できるようにならないといけない。

　あれ、なんか敷居高いな。

　複雑な携帯電話の料金プランを頭にたたきこまなければならない、携帯電話の販売代理店の販売員の気分だ。

　要するに自分自身がユーザーになってサービスを体験した上で、お客様にとって一番お得なの方法をわかりやすく提案できる能力が求められている。

　辛。

参考：Amazon EC2 料金表 | アマゾン ウェブ サービス（AWS 日本語）