osa2's memo

自分の記憶のために・・・。

[雑感] 格安スマホ市場で生き残っているシャープから思うこと。

最近乗り換えもしたので、MVNO各社のサイトをちょいちょい見てまわっている。

iPhoneはちょっと置いておくとして、Android系端末はもう、海外品一色である(もちろん販売にあたり国内で技適を通している製品)。ASUSのZenfone、Huaweiの最新はnova、ちょっと前はP10シリーズ、ほんとに安いところでAlcate PIXI 4.0(4インチの意味)、たまにHTCやMotorola(といってもMotorolaブランド製品の製造・サポートは中国のLenovoである)。Alcatelはフランスだが製造拠点は私は知らない。

というわけで国内格安Android端末市場は、ほぼ、中国・台湾(ここではあくまでも地域として両者をあげている)製品。

その中でMVNO各社が残している純国産ブランド、それは各社のトップページでは、シャープだけである。今はAQUOS sense (lite)などがZenfone, Huawei, SHARPの順で並んでいる。若い方々はお金もないしどれも大差ないだろうと見抜いているが、御年輩の方々は格安=安かろう悪かろう・・という印象もなくはないであろう。

実際には、厳密には劣る部分はあるのだが、特に御年輩の方々の日常利用において、大キャリアと格安キャリアではネットワークも個々の端末も、機能・性能での大きな差はない。もちろん高いものを買うか安いのを買うかで違うのは当然である。しかしおそらく、3大キャリアからなかなかMVNOに顧客が流れないのはこのあたりの漠とした不安感というか不信感というか、何か心もとない感情を抱くのだろう。そこにAQUOS、である。

MVNOとしては仕入れは海外スマホの方がおそらくかなり有利と思われるが、SHARPがあることで乗り換え顧客が安心感を抱くのであろう。そのために人気上位3製品の中の「常に3番目」にSHARP製品が表示されるのである。「見たこともないメーカーで不安なあなた様には!」というわけである。もちろん、SHARPもこのことを理解し、あるいはいまとなっては意図的に、3大キャリアとMVNOで製品の販売戦略は分けているのでは?と推測はできる。

総務省は格安スマホ市場の成長を、モバイル市場全般の価格を下げる圧力として大変に期待しているようで、かつてインターネットサービスの価格破壊を成し遂げたSoftBankの系列にあたるY!モバイル同様に、楽天モバイルにも期待をしていることをかなりはっきり示したニュースもあったりする。しかしその格安業界でも、こと格安端末となると純国産は、シャープ以外ほとんど登場しないのである。

3大キャリアは、iPhone、Galaxy、Xperiaにラインナップを絞りつつある。これらはブランディングに成功した、高級機種である。メーカーはキャリアと初めから高値で交渉をできるので、製造コストに余裕を持たせられる。さらに高機能・高性能を追求できる。

3大キャリアの顧客は「思考停止」した顧客が大半。なぜならガラケーでよかったのである。それをいきなりだだっ広いスクリーンにズラズラとアイコン並べられても、パソコンと同じで何をどうしていいか、ワカラナイ。よって思考停止。今のキャリアで、勧められるがまま。

iPhoneはカスタマイズの余地が少ないことと、AndroidのようにサプライヤーによってまるでUIが異なるということがない。電話とLINE、せいぜいFB+インスタ、Twitterさえできればいい人にはiPhoneをデフォで使ってもらうのが、キャリアとユーザーの「お互いの平和」にはちょうどいいのである(ま、Android端末でもキャリアがランチャー入れたりしますけどね)。

他方、Android界隈はというと、Galaxy S9のCMを観ていても、「それ、いらねーだろ」というハイレベル・素敵な機能が満載である(夜景が綺麗に撮れるのはいいですね)。

XperiaはもともとがSony Ericssonなので、常にグローバルモデルとして製品が開発され、国内はその1市場、1出荷先である(日本企業がグローバル企業にならんとするならば本来はこうすべきである、という稀なるお手本である)。もともとの海外市場でのタフな戦いを生き抜きながら、SONYならではのデザインや内部モジュールへのこだわりをも両立して、シンプルながら非常に高品質な製品を生み続けてきたことが、顧客に「定番の高級ブランド」として支持されている要因であろう。

iPhoneは当初はイメージ先行ではあったが、ここに来て「安心な端末」としての地位を確立しつつある。Android端末がサプライヤーサードパーティー)ごとに製品戦略を描けるメリットがあった反面、個々のサプライヤー・製品の保守・サポートにばらつきが出てしまった。一方のiPhone, iPadなどのApple製品はハード仕様からOSまで(実際の製造者はともかく)Appleが中央集権的にコントロールしている。昨年のWPA2の規格仕様不良についても、Apple配下の機種と、Android連合体の対応には天と地ほどの差があった(もちろん、Appleの方が全体としては遥かに的確な対処を為し得た)。

という訳で、いまの市場のシェアだけをみれば3大キャリア・MVNOとも椅子取りゲームは終わったかに見えるが、日本の製造業の強みはかつてのガラパゴス戦略?であり、利益優先主義よりも顧客優先の品質重視主義であった。シャープは加えてAQUOSブランドで顧客へのリーチが強かったために、いまMVNO各社で採用されていると思うのである。

ここまでで雑感の内容は本来は終わりなのだが、もう少し(笑)

MVNOは低価格戦略がベースにあるため、安い端末を海外から調達せざるを得ない。そうなるとMVNOでの主役はiPhoneではなく、さまざまなサードパーティーAndroid端末である(それでも他国より異常に多いiPhoneユーザーを取り込みたくて、iPhoneを並べるのである)。

日本のメーカーは概ね製造コストが高く、AndroidであってもなかなかMVNOに売り込める価格(≒原価)を実現できていない。しかしMVNOにしてみれば、もっと国産機種も並べて、サポートにも安心感を付帯して、新規顧客(=3大キャリアからの乗り換え)を獲得したいであろう。

唐突ではあるが、もし、東アジア・東南アジア諸国・地域で、Android端末に関する統一ルールがあったらどうなるか。主に製造品質と、サポート品質であるが、これらを域内で定義・共有すると、Android端末の機能レベルやサポートポリシーが明確になり、顧客への大きな安心感となるであろう。

また、iPhoneと違い、Androidは廉価な端末から高度な端末までサプライヤーが自由に開発できる。このため、機能水準にはグレードを設けつつ必須要件を定義することで、サプライヤー各社はどのグレードに注力するか、また同一グレード内での差別化や、下位グレードでの徹底的なコストダウンを図る、など個社ごとに戦略を立てやすくなる。顧客の側もメーカーにこだわらず、「グレード」というブランディングで商品を横並びに見ることができる。日本のメーカーは域内に「高級感」を謳ってハイグレード製品を集中的に提供すればよく、中国・韓国も上位グレードからミッドレンジまでをカバーできるだろう。中韓の強みは下位グレードも展開できるメーカーが山ほどいることである。

またサポート品質については域内でグレードにかかわらず、標準化をするのが望ましいと思われる。Androidでは最新バージョンの2つ前のメジャーバージョンまでが常に保守(アップデータ配信)の対象となり、新しいメジャーバージョンが発表されたら、3つ前のバージョンはその1年後にサポート終了となる(1年後までに移行してね、という意味)、というようなルールである。具体的な年数等は参加国・地域の事情で決めることになるが、今はこういうルールの土台すらないのがAndroidの脆いところである。

ま、GoogleもそろそろAndroidは飽きてきただろうから、いまさらAndroidについてあれこれ手間暇かけるのもなんですけどね(笑)

でもAOSPをしゃぶり尽くして、広域圏でのレギュレーションを整備すると、日本のサプライヤーGoogleに縛られずにもっと色んな場面で存在感を出していけると思うのですがね。どうなんでしょ?

プログラミング言語のリバースランキング。

いいかげん、クソガイシャ乗り回すのも飽きたので、少しお外の世界で遊ぼうかなと思いたち。

で、きょうび世の中ではどんな言語でWebとかアプリとか書いてんでしょ?と調べてみるも、言語ランキングは、Java, C, C++, Python, ...。仕方ないからWebで、と絞り込みかけると、Web開発でおすすめの言語5選というサイトを開くと 1位:HTML, 2位:CSS, ... orz おいおい、3位まで無駄にしてますがな。

もーどいつもこいつも、と思ったら、さっすがPublickeyさん、目の付け所が違います!これはひじょーに参考になりますわ。

www.publickey1.jp

新しものが雨後の筍のごとく(←見たことないけど)出てくる中で、ただ新しいだけでは駄目で、勝馬になるのか生き残れるのか、とりわけマイナー言語大好きな私としては、Java, C, ...ではなく、リバースランキングが必要!と改めて認識した次第。

オリジナルのサイトで拡大してみると、いるわいるわ、私の馬券に名を連ねている馬たちが。あれもこれも駄馬と言われている(笑)

意外だったのは、CoffeeScript。CSON便利だよ!と思ってたのに..はっ。CSONだけ持って行かれたのか?

Rust!概ね言語としての評価が悪くない中で Job Marketで堂々の2位。Mozilla にでもいなければ、Rustはカネにはならない、のか。

なんとなくダメかなーと思っていたElmもjobカテゴリで3位。まぁ RustにしてもElmにしても、いまワーストでもこれからなのか、もう下ってきてここなのか、という意味では、いまは放置で1年後を見たいですね(こういう輩のせいでますますランクが下がる)。

ErlangHaskellも、Erlangの圧勝(リバースで)。ということは上モノのElixir, Phoenixも...? ま、わたくし、動的型付け言語があまり得意でないので、やはりランクでは劣勢なご様子のRubyともども(ここはニッポン、お口にチャック!!)。

えーと。すべて6位で総合も6位のClojure。他のJVM言語は?Kotlinは、Google様が付いているから。あとは Scala。コミュニティが見放しつつあるの?まぁ Scalaもなんとなく苦手でした。今ならもうJavaでいいのではとも思ったり?使いやすさが違うのかな?

ここまで見てふと。「並列処理が得意」と言われている言語が振るわない結果のような気が、しませんか?

地味にPerlやGOも視界に入りますがスルーして、JS系はというと...ダントツのCoffeeの他は(ElmもJS系とも言えますが)TypeScriptさん。JSな人々が型チェックとかされたら気が狂っちゃうのでしょうかね。でもJS屋さんはJSLintとか、使うのかな。

それにしても、よく見りゃCも、C#もある。Rもある。ここに載らない方が難しいのでは?載ってないのは・・・Java, C++, Python あ... PHP(笑)

これはとってもいい情報でした!!m(^-^ )m

== END ==

我が家のパスワード管理

一般の、ネットヘビーユーザーさんなら誰もが苦しむこの課題。
今日、こんなメールが来ました。


■ とあるメーリングリストによる情報

2014年のIPAの調査によれば、64%の人が複数のパスワードは覚えられないと答え、50%の人がパスワードを複数サイトで使い回ししています。 つまり、2人に1人は1箇所でIDとパスワードを盗まれたら、利用している全部のサイトで被害に遭う危険性を持っています。  
IPA情報処理推進機構は、経済産業省所管の独立行政法人

  • パスワード運用の実態
  1. どのようなパスワードが安全かを理解している 70%
  2. 実際に安全なパスワードを設定している 13%
  3. 同じパスワードを別のサイトに流用している 50%
  4. いくつものパスワードを覚えていられない 64%

■ 私の中の変遷

ぐうたら感謝の日を崇敬する私としては、上記、1,2,3,4全てに当てはまります!つまり、

「♪わかっちゃいるけど やりきれない♪(ハイッ

  1.  ネットを始めたころ(1993〜1996)
    適当に8文字くらい。好きな単語に数字をつける程度。誕生日の数字そのものは使わなかったけど、掛けた値や足した値を使ったりはしていた。
  2.  サイトが増え始めた(50サイトくらいの)ころ(1997〜2010)
    正直、使い回すしかない。面倒くさい。当時はブラウザが憶えてくれるなんて素敵な機能はなかった(今も正直、あまり使いたくはないので、自宅のブラウザに限定している)。
    その代わり、パスワードの作り方を強化。いまはもうこの方式は使っていない。
    ・お金の絡まないサイト: xx999999 アルファベット小文字2文字+数字6桁
     このパスワードだと、約6億7600万通り。
    ・お金の絡むサイト: xxxx9999 アルファベット小文字4文字+数字4桁
     このパスワードだと、約45億6900万通り。
    作り方は、アルファベットは(紙本の)辞書を適当に開き、
    アルファベット : ページの上端に載っている見出し語の上から2桁目
    数字 : ページの上端に載っているページ数の10の位
    8回ページを開き直して、1個、お金用、非お金用で2個を作る。
    これをだいたい半年ごとにやり直して、後継のパスワード2個に入れ替えていく。
  3.  利用サイトが更に増大(100サイト以上)(2011〜2013)
     &世のサイトのパスワード規則が厳しくなっていった時代
    さすがに100サイト超えていくと、パスワード更新が漏れはじめる。特に利用していないサイト。すると、2.で決めたランダムな文字列を数世代(多いときは5世代くらい)憶えていないと当てられない時も出てきた(涙)
    サイト側が文字数(これは8文字なら概ねクリア)や必須の文字種(大文字や記号)を増やし始め、2.のルールでは対応できないサイトができてしまった。現在は使っていない方式だが、2.のルールで作ったパスワードの先頭だけ大文字にしたり、末尾に自分の中でこれと決めている記号1つだけを足して、その場しのぎ。後にこれでもうまったく思い出せないサイトが増えていくことに。
  4. 表計算スプレッドシート+ランダムパスワードジェネレータ (2013〜2017)
    そこそこ使えたが、モバイルのパスワード入力に対応できなかった方式
    開くときにパスワードを入れて開くシートに各サイトのユーザーID、パスワードを記録。またパスワードはNortonのジェネレータのサイトを使用。これでもう自身ではまったく記憶のしようのないパスワード、かつ、サイトごとの使い回しを回避。
  5. 暫定モバイル対応(2015〜2017)
    2.や3.で使っていたパスワードを複数連結し連結の際に記号を足したりルールを決めて大文字化したりして16〜20桁のパスワードを5本程度用意して使い回し。
    しかし、このパスワードがリーク(漏洩)していることが外部のサイトから警告あり、6.に移行。
  6. パスワード管理ソフト+USBメモリ(2017〜)
    5.を受けて、4.の方式はまだしも、モバイル環境でもシームレスに利用するためには、パスワード管理ソフトは使用せざるを得なくなる。
    多くのパスワード管理ソフトは「クラウドに保存」することと、PCやモバイル用のソフト・アプリを提供することでパスワード管理環境を提供している(多くの方々はこれでも良いはず)。が、以下の理由で私はそういったプロダクトを採用できなかった。
    (1) 自宅のメイン環境がLinuxのため、対応していないベンダー製品がほとんど。
    (2) クラウドに置いた以上、自身の手で、物理的に情報を隔絶する手段を失うことになる。
    (3) USBならPCやスマホから抜けば外界からのアクセス手段は住居侵入以外不可能。
      (ドロボーに入られたら印鑑だって通帳だってやられるんだからこれはもう仕方なし)

■ 結論(=現状)

次の次の投稿で詳細を紹介するが、現在は上記6の段階に来ている。改めて書くと、

  1. パスワード保存方式をKeePass2ベースとし、PC(Linux, Windows)、AndroidWindows Phoneでの対応ソフト、アプリを利用している。
  2. 保存先はUSB-OTG対応のUSBメモリスマホにも挿せるUSBメモリ)を使い、そこにパスワードを格納し、普段はPCやスマホからは物理的に隔離している。もちろん、バックアップも取得し、隔離している。
  3. 上記4.はまだ移行中だが(既にサイトが200以上あって、不要なサイトをアカウント閉鎖しながらやっている)、5.は完全に廃止した。もちろん、3.以前の方式も廃止済みである。

一般ユーザーとしては既に利用しているセキュリティソフト会社のID管理ソフトを追加購入するか、この方法くらいが限界ではと思われる(個別に有用なツールはあるが、それはまた別途ご紹介したい)。

== END ==

自宅のリモコンのリメイク(1)

冬に作った部屋の照明&エアコンのリモコンを作りなおすことに。冬に作ったから暖房のデータしかサンプリングしてないのですよ(笑)

まぁせっかく作り直すので、アーキテクチャから見直しをかけて、将来のために、無駄に(今は)要らないツールも使っているのでなかなか肝心の冷房機能が実装できてないのですけど・・。

1. ハードウェアアーキテクチャの変更

これまではESP-WROOM-02(以下ESPrIR)という3cm✕4cmくらいのWiFi+IR(赤外線LED)のみで、リモコンを作っていた。WEBページで利用可能にしたが、何のことはない、80番ポートでソケット開いて、処理結果をHTMLで(HTMLで!)返していたのだった。

1つで家の中全体に赤外線を飛ばせるならこれでも不自由はない。が、小さな部屋と言えど、1つでは無理。2つは要る。他に赤外線でなくてもコントロールしたいものが増えるかもしれない。

なので司令塔として、部屋に転がっていたRaspberry Pi 2 B+(以下RPi)を使うことにして、WEBのレンダリングもRPiにやらせる。まずRPiがUIからのリクエストを受けて、各子機(今回はまだESPrIR1機のみ)にリクエストを投げる。親機と子機の間もHTTPだが、ここはJSONかCSONでやり取りすることにして、まぁ、RESTful風にする。

2. ソフトウェアの変更

WEBのUIレンダリングには(別の案件で使いたいと思っている)Vue.jsを使用した。RPiのWEBサーバーはNginxにしたが、単に好み。実際に子機との通信部分をCGIでやらせても良いのですが(笑)、せっかくなので、これも別案件で使いたいと思っていたPython、その軽量フレームワークのFlaskを使ってみることにした。

というわけで、UI(HTML,CSS,JS,Vue.js)、サーバー(Nginx+Python+Flask)という、、実はindex.html1枚とCGIで済むところに、無駄にふんだんに仕掛けを投入(笑)。ちなみに別案件はビジネス向けのWEBシステム(のプロトタイプ)で、MySQLという名のMariaDBとMroonga、MongoDB辺りを使うのと、Rや,Cともバインドがあるのではと思われるので、ららべるに後ろ髪引かれながらもPHPではなく、グルー言語の誉れ高いPython、なのでした。

3. しかし、この組み合わせは・・・(笑)

なんと、Flaskのテンプレートエンジン(Jinja2)でのサーバーサイドレンダリングと、Vue.jsでのHTMLへのデータインジェクションの「ノテーションが同じ」という軽いワナがあることが判り。やってみるもんですね。超ざっくり書くと、

<h1>{{ greeting }}</h1>

と書いて、これがVue.jsのため、と思っていても、Flask側でこのHTMLファイルをtemplatesフォルダに入れて、render_template(xxxx.html)とすると、greetingが定義されとらん! とTrace吐かれるのデス。

ま、SPAで行くならサーバーサイドレンダリングなどせずに、staticから諸々ファイルをまんま読み込んで、あとはAJAXでのリクエスト処理だけ Flaskにやらす、でいいや、というところで今日は終わり。

4. ちなみに

つまらないものですが、UIイメージだけ出来とります。ペタっ。

f:id:osa2:20180415232809j:plain

== END ==

 

 

 

リパーティション、REPARTITION♪

久々にスマホのリパーティションしたのですが、以前やったのにすっかりやり方忘れてましたので、メモです。

ご注意:やり方にもよりますが、基本的に、データが吹っ飛びます。パーティションを再構成するのだから当然ですよね?ということで、何が起きるのか、何をしたいのか分からない人は、真似しないでくださいね(リンク先やダンロード先の安全性も自己責任でお願いします)。

1. パーティション書き換えツール "parted"

旧型AndroidではARM(32bit)のバイナリが必要です。自分でクロスコンパイルしてもいいけど、ここから落としました。

iwf1.com

2. 潰し方と作り方

ココが参考になります。

forum.xda-developers.com

基本的には、fdiskとpartedで確認しながら潰し、確認しながら作って、お名前つけていきます。

パーティション一覧の見方

 # fdisk -l /dev/block/mmcblk0

パーティションの潰し方

 # ./parted /dev/block/mmcblk0 rm <パーティション番号>

パーティションの作り方

 # ./parted /dev/block/mmcblk0 mkpart primary <開始セクタ>s <終了セクタ>s

パーティションへの名前付け

 # ./parted /dev/block/mmcblk0 name <パーティション番号> <名前>

3.気をつけること

ま、これをやりたいのはsystem(factoryfs)パーティションが足りないとき。よく隣にuserdataパーティションがあるので境目をずらす感じですね。

== END ==

 

AndroidにErlang/OTPとElixirを仕込んでみた

忘れないうちに作業メモ。

Erlang/OTPのビルドと配置

基本的にはこの手順が正だとは思う。

otp/INSTALL-ANDROID.md at master · erlang/otp · GitHub

一番参考になったのは、この手順。

Building Erlang for Android

あとでこの2つの手順をベースに書き直すつもり。ソースのバージョンは20.2.2を使用した。

Elixirのビルドと配置

2つ目の手順で概ね問題なかったが、Elixirの導入でハマる。原因は、ソースをビルドしないまま配置していた!elixir.beamがなかったので、elixirやiexを使っても、呼ばれたerl(Erlang/OTP)が中でcrashしていた。

Elixirのソースはここから。

GitHub - elixir-lang/elixir: Elixir is a dynamic, functional language designed for building scalable and maintainable applications

手順はほとんどなく、git cloneした後、チェックアウト(v1.5のHEAD。v1.6はまだRC1だったので)。

で、make clean test をする。これをしてなかった。

あとはAndroidに突っ込んでパス通すくらい。スクリプトの先頭行(#!/bin/sh)がAndroidでは微妙に違う。

余談

Erlang/OTPはあまりビルドで手こずらなかった(node.jaの方が難しかった気がする)。

CordovaとElmでのapk作成はできたので、あとはElmからどーやってElixir/Erlangを叩くか。全部通ると、Androidアプリを最新のリアクティブな言語で作れるのでは?まぁ、WebViewでできる範囲のことだけですけどね。

で、Erlang/OTPからLinuxをコールできれば・・というようなことをすると、Googleが圧力をかけてくるのかこないのか、この辺りの話はとにかく情報の量が少ない。

== END ==

LPC1768からHelloを打ち込んでみた

明けました。特に何もないです。何がめでたいのかもよくわからない。

で、人とは楽な方へと流れるもので(笑)最初に手を付けたのはLPC1768(以下mbed)。といっても昨日、珍しくハンダ付けが調子よく(決め手は老眼鏡!)、転がっていたmbed用のEthernetパーツを作り上げて接続。

f:id:osa2:20180101090027p:plain

しかし、シリアルをつないでないので、つながったかどうかがわからない。それならと、つないだついでにHTTPサーバーにPOSTを投げるところまでやってみた。途中、諸々、省略(笑)最後の方に参考にしたサイトをメモっておく。

mbedのコード。

// main.cpp
#include "mbed.h"
#include "EthernetInterface.h"

EthernetInterface net;

int main() {
    net.set_dhcp(false);
    net.set_network("192.168.1.101","255.255.255.0","192.168.10.1");
    net.connect();

    TCPSocket socket;
    socket.open(&net);
    socket.connect("192.168.1.100", 80);

    char sbuffer[] = "POST /cgi-bin/hello.py HTTP/1.1\r\nHost: 192.168.1.100\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 19\r\n\r\nurname=Mbed_LPC1768\r\n\r\n";
    int scount = socket.send(sbuffer, sizeof sbuffer);

    socket.close();
    net.disconnect();
}

結果(mbedをリセットすると接続→POSTリクエスト送信となる)。

f:id:osa2:20180101090345p:plain

 ま、これであとはセンサでも付けて情報をPOSTすればいいのかな、と。たぶん、Mbed Device Connectorのような、コントロール用のホストを中に立てた方が良さそう。手許には可視光の光センサがある(何故あるのかが不明。)のだが、いかんせんこの子、Wiredなので何処にも連れていけない。いまそこで引っかかっている。なんかWiFiっぽい部品も転がってるんだけど・・・めんどうい。

参考にさせていただいたサイト:

まだ、Hello! の世界。いつもこればっかり(笑)