読者です 読者をやめる 読者になる 読者になる

ふんわりした生活

本を読んだり仕事でやってみたことなどの日常から、ふんわりと気づきなどを書いていきます

雑記 慣れないJavaScriptとやりあうおっさん、そしてマークダウンとGroovyのこと

Kindle javascript うまくいかない ブログ プログラミング 雑記

f:id:m0t0k1m0t0k1:20170223145604j:plain

ふだん行わないような、慣れないことをするとさまざまな学びがあるものだ。わたしは基本的にPowerShellを書いて暮らしていた。もちろんhtml+css+jsもつかってはいたけど。しかし、主にやっているものでもないので、思いのほかいろんなことを知ることができている。これもsatoyama-editorを開発しはじめたからだ。

無知

ほんとうに無知なものである。スマホのブラウザでも同じようにできるものと考えていたのだけど、そうはいかなかった。たとえば、10分後に鳴らす予定の鐘の音なのだが、これがiOSAndroidでは鳴らすことができなかった。厳密にはiOSでは鳴らすことができるのだが、クロージャスコープにある変数が参照できず動作していないことがわかった。しかし本当にそうなのかな、ということはあるので、さらに調査する必要がある。Androidのほうは厳密にはKindle FireOperaでのことだ。こちらはどうやらAudioBufferSourceNodeが未サポートのようだ。そのため音を鳴らすことができなかった。

AudioBufferSourceNode - Web API インターフェイス | MDN https://developer.mozilla.org/ja/docs/Web/API/AudioBufferSourceNode

いずれにしても、10分以上の執筆をスマホで行うことは考えにくいという考えに至ったため、無理に対応する必要はなさそうだ。それに、開いたままだと音が鳴ってしまうというのはいかがなものか、とも思う。 よって、先に実装すべきは音を鳴らすことよりミュートなのではないかという気持ちにもなった。

その他にも、いまの方式ではテーマを選択するようなことは難しそうだ。UIとして設定を行うためのスペースをほとんど確保していないうえ、スマホではその場所すら惜しい。いまは80%程度をエディタ領域にあてており、スマホではさらに100%にできるだけ近づけたいと考えている。そのため、ボタンのようなものを配置するスペースすらなくしていきたいところだ。

では、メニューかのごとく画面上部に文字数などを表示させている箇所があるから、ここをそれにあてては?ということはある。これらも画面幅が小さくなれば非表示にしてしまう。最後はsatoyama-editorのアイコンのみが画面上部に表示されるのみとなるくらいに徹底的に部品を排除している。ほんとうを言えば、フッターもなくてもよいくらいだ。

いつかサイドバーを表示できるようにして設定をするように変更するまでは、この形で落ち着きそうである。

慣れないことをすること

慣れないことをすると、ふだん使わない何かを使っているようだ。筋肉でもそうだが、やたらと疲れるものだ。JavaScriptとの付き合いは非常に長く、大学生のころからなので15年近いのではないだろうか。しかし、一度も得意だと感じたこともないし理解できた!と思ったこともない。あいつはほんとうに難しいやつだと思っている。

htmlもそうだ。cssも。ウェブブラウザの発展とともに姿形を変えていき、わたしの知らない領域へどんどんと進んでいく。その結果、わたしはいつも追いかける立場になっている。追いつかないので、ここ数年は追いかけることすらやめていた。そうすると最近はReactうんぬんが登場していて、少しだけ触ってみたが今回は採用しなかった。ユーザー入力に応じて画面を再描画するほどの必要性が感じられなかったためだ。そのためjQueryさえ使っていない。

一方でCSS3は非常に便利だ。いままでJavaScriptなしには実現しえなかったことをブラウザのレベルでやってくれるため、見た目は見た目、という切り分けがしやすくて非常にうれしい限りだ。html5は…いまいちどこに恩恵を受けているのか感じないレベルであるため、きっとよくできているということなんだと思う。

マークダウンとApache Groovy

唐突に何を言い出すのかと思いきや、マークダウンとGroovyは似たようなところがあるなと思い立ったので書き始めてみた。どちらも最終的には別のものになる。マークダウンはブログサービスなどではhtmlに変換される。Apache GroovyもJavaコンパイルされる。そしていずれもマークダウン中のhtmlタグはそのままアリとして生き残る。Groovyもスクリプト中のJavaコードは妥当なGroovyコードになる。非常に面白い。

satoyama-editorではhtmlタグは除去してから文字数カウントを行うようにしてある。それは、書籍を書いているときにAtomやVSCodeだと文字数はそうしたタグも含めての数になってしまうからだ。つねづね、そこは違うんだけどなーと思っていたので除去することにしてある。

いずれにしてもマークダウンもGroovyもどちらも好きなものである。マークダウンを超える表現手法が必要なときはhtmlを内部に記述していく。GroovyではなくJavaを書くべきところではJavaを記述する。結果的には1つのアウトプットになるというところが素晴らしいところだ。PowerShellでもC#VB.Netスクリプト内部に記述することができるのだけど、そのままとはいかない。ヒアストリングという形式の文字列に埋め込んで、Add-Typeコマンドレットで一時的にコンパイルして利用することになる。これがなければPowerShellも素晴らしいのになぁと、時々Groovyのような.Netプログラミング言語がないものかと考えてしまうことがある。

とりとめもない話になってきたので、そろそろここらで終わりとしたい。

追記:2017/02/23 15:04

Kindle Fireでは何もとくに変更していないが、音を鳴らすことができた。なんなんだこれは…謎が深まるばかり

確かな力が身につくJavaScript「超」入門 (確かな力が身につく「超」入門シリーズ)

確かな力が身につくJavaScript「超」入門 (確かな力が身につく「超」入門シリーズ)

プログラミングGROOVY

プログラミングGROOVY

【改訂新版】 Windows PowerShell ポケットリファレンス

【改訂新版】 Windows PowerShell ポケットリファレンス

名前をsatoyama-editorに決めた(変えてしまいそうだけど)

ブログ プログラミング 書きたい 雑記

f:id:m0t0k1m0t0k1:20170223101250j:plain

m0t0k1m0t0k1.hatenablog.com

昨日から開発をはじめた、快適な何もしない執筆環境を「satoyama-editor」と命名した。ああ?なぜ里山なんだよ。なぜかって?それは、静かな場所をイメージしながら開発しているからだ。虫の声。風の音。小川に流れる水の音。鳥の声。そうしたものを想像しながら開発している。

いまわたしは里山という環境にはいない。実際は地方都市の2番目に大きな街にある町に暮らしている。だから、里山には程遠い。近所には交通量の多い幹線道路があって、窓を開ければ日々昼夜を問わず自動車の音や緊急車両のサイレンも聞こえている。さらに線路も走っているので、踏切や電車の走行音も聞こえてくる。ある意味で交通の便がよく、快適な町だ。

そうした環境はプログラミングするには非常に向いている。集中してさえしまえば、何も気にはならない。没頭することができるのでね。だけど、書籍のときは慣れていないせいか集中できない。あれこれ目に入るとまったくもって集中できない。たとえば構文ハイライト。マークダウンの構文に沿って書くことができているか?それがハイライトされると「よっしゃ」となってしまって本来書くべき内容は薄くなってしまっていることに気が付いた。メール文章を書くときにも、はじめのうちはテキストエディタを使用していたのだけど、結局最後はプレーンテキストにはほとんど何もしないTeraPadを使用するようになっていた。

リッチなエディタは非常に便利なのだけど、不便なほうがより集中できるということもあるのだと考えたのだ。では、里山にたとえた形になっているわけだけど、里山に何もないか?というとそうではない。たくさんのものがある。ある、というか生きている。生きているものがたくさんある。もちろん、街の中でも生き物はたくさんいるし、足元を見つめるだけでいろんなことに気が付くだろう。だけど、街の中にはないものを求めているという「ないものねだり」というところだと思う。

使い心地

いまのところ、なにもしないのはとても快適だ。見出しになっているかどうか、リストになっているかどうか、いちいち気にならないし、それほど目につらいものでもない。開発自体はhtml+css+jsでいまのところ外部ライブラリも一切使っていないので、振り回されることもない。ひどい話、自分の使用している環境で動作すればよいので無理なハックを使わなくてよいのもすこぶるよい。なぜ、いままでこういうものをつくってこなかったのか。不思議でならない。

そういうわけで、違う意味で快適なのではあるが少々バグも目に付くようになってきた。一日中つかっていれば、バグにも気が付く。昨日のブログ投稿のあとに追加した修正でバグっているようだ。自分でつかいつづければバグもとれてくるのだろうか。最大のユーザーが自分というのはある意味でよいことだ。なんだ、ドッグフーディングとかいうやつかな。

昨日追加した機能のなかでもっとも気に入っているのは、この文章を読むためにどのくらいの時間がかかるものなのかを計算して表示するようにしたものだ。適当にググると人間はだいたい400から600文字くらいを1分間で読むことができるらしい。どう考えても普段のブログ記事を読むスピードより遅い気がしなくはないが、600文字にしておけば目安にはなるだろうということで600文字で計算するようにしてある。いまこの時点で1400文字強なので、およそ2分と4秒くらいで読み終わることができる。ブログ記事であれば2000文字くらい書いてあることが多いので、3分前後というところかな。

プレビュー機能について

昨夜も寝る前に考えていたのだけど、プレビュー機能はブログサービスなりにあるのでやはりつくらなくてよさそうな気がしている。書籍だと実際にePubやmobiファイルにしてビューアで読んでみないとわからない。エミュレータもあるのでそういうもので読んでみると、初期のころに出版したもののコード部分が死ぬほど読みづらい箇所がたくさん見つかる。なかなか簡単にはいかないものだな、と思っている。今後出版するものは白黒のビューアでも快適に読むことができるようにハイライトはやめようと決心している。思い返せば、ハイライトしている紙の書籍ってほとんどないはず。だって、ブログじゃないから読みづらいんだもの。

いまウェブサーバーはPHPをつかっているので、PHPでサーバー側の機能をつくればプレビューはおろかサーバーサイドでのドキュメント保存もできそうだなーと思うことは思うのだけど、個人的にはあまりエディタの同期機能をつかうメリットを感じていないので他の方法があるんではないかと思っている。わたしはDropBoxにファイルとしてアップしたほうが便利なのでそうしている。ファイルは開くことができなくてもいいし。貼り付ければいいのだから。

類似としてクリップボードの制御もいまのところ考えていない。全選択してコピーは別にブラウザの機能を使わなくてもOS標準のものでよいと思っている。なぜなら、このエディタはあくまでも単なるtextareaで、データはプレーンテキストなのだから。

そういうわけで、とりあえずゴミみたいなレベルのバグを修正することにする。

NHK ニッポンの里山―ふるさとの絶景100

NHK ニッポンの里山―ふるさとの絶景100

自分用の執筆環境を整える長い旅に出てしまった

ブログ プログラミング 書きたい 電子書籍

f:id:m0t0k1m0t0k1:20170222140930j:plain

とうとう、時間を見つけてつくりはじめてしまった。自分だけの、快適な執筆環境のことだ。

いままで、いろんなマークダウンエディタ、テキストエディタを試してきた。ところが、どれもしっくりこなかった。理由というか原因がはっきりしたのでそれを踏まえてつくりはじめた。

古今東西、素晴らしいテキストエディタがある。いつもお世話になっているものもたくさんある。たとえば、TeraPadにはじまって、VimAtomSublime Text3、そしてVisual Studio Code。マークダウンエディタなら、MarkdownEdit、Typora、オンラインのStackEdit.ioとかwri.pe、そしてGitbook。どれもそれぞれ素晴らしいエディタで、どれも愛用している。

だけど、あるとき気が付いた。わたしが本当に必要としているのはそうした優れた環境ではない、ということに。気に入らないことがあるか?いや、ない。そう、必要としていない理由はそこだ。だからわたしは自分用の環境をつくることにしてしまったのだ。

優れた環境から必要なかったもの

わたしが長い時間をかけて文章を書くとしたら、電子書籍をつくるときだ。このときはマークダウンを延々と書いていく。あるいは、ブログの記事を書く。こうしたときに必要なものはそれほど多くないことに気が付いた。

優れたエディタの、素晴らしいけどわたしがそうした作業のときに不要なものをあげていきたい。

  1. マークダウンの構文ハイライト
  2. コード部分のプログラミング言語ごとのハイライト
  3. 行番号
  4. コード補完機能
  5. PDFやePubファイルへのエクスポート機能
  6. カーソルのある行のハイライト
  7. 優れた一括置換機能
  8. 矩形選択機能
  9. ファイル検索機能
  10. プロジェクト機能
  11. マークダウンのプレビュー機能

これらは大規模なプロジェクトではどれも必要になってくるものだ。ないと話にならない。だが、わたしが執筆をするにあたってはほとんど不要な機能だ。まずは…マークダウンの構文ハイライト機能。これはマークダウンとして妥当なものを書いているかというチェックには役立つ。しかし、それ以上のものではない。

次に、コード部分のプログラミング言語ごとのハイライト機能。これも当初はすげー便利ー、と思っていた。特にTyporaなどはプログラミング言語を後から指定しなおしてほかの文章部分へ影響が出ないようなブロックを生成してくれる。しかし、ずっと書いていると逆にうっとおしく感じるようになっていた。なぜか。動作するコード片を書籍に埋めたいのであれば、必ず動作確認をしているからだ。そうなると、実際に動作したコード片をペーストしてくることになる。そうなれば、コードはプログラミング用のエディタを利用するため、ハイライトもコード補完も必要ない。

3つ目は行番号。最初はこれ、必要かなーと思ったのだけど、何行書いたのかはまったくもって大事ではなかった。文章なのでプログラムやスクリプトではなかった。書き換えていくと何行目なのかはまったくわからなくなるが、推敲のときにはプログラミング用のエディタを利用してこまごまと修正していくので書くときには必要なかった。

4つ目はマークダウンのコード補完機能。できることはわかった。でも、いらない。必要なものは最低限だけでよくて、見出しはたいてい3以降のものしか使わない。リストはハイフンかアスタリスクで記述する、リンクは角かっこと丸かっこの組み合わせ、画像もこれの先頭に「!」がつくだけ。このくらい知っておけばたいていの文章は書くことができる。脚注?必要ならつけるといいし、動作しない環境も多いのでほっておけばいい。

5つ目はエクスポート機能。最終的に文章はファイルにしてからカバー画像やスタイルシートをあててePubやPDFにするので、手軽で便利だと思うがわたしにはいらない。こういう手軽なものが必要なときって、マニュアルやドキュメントを書くときなので電子書籍用ではないよね。

6つ目はカーソル行のハイライト機能。プログラムやスクリプトを記述するときにはものすごく便利な機能なのだが、単なる文章を書いていくときには必要ない。カーソルは見えているのでそれで十分だ。何行目なのかも関係ないしね。

7つ目は一括置換機能。これは書いていく時ではなくて推敲するときに必要になる。気分的にガンガン書いていきたいときには必要ない。

8つ目は矩形選択機能。固定長テキストファイルを修正するときにはものすごく便利な機能なんだけど、記事や書籍の文章が固定長なわけはない。

9つ目はファイル検索機能。どのファイルにどんなテキストがあるか?うん、知ったことではない。

10個目はプロジェクト機能。これもプログラミング用のエディタにあるので書くときには必要ない。いままでの経験上、だいたいの構成を決めてもあとから構成をしなおすこともあるので、最初からファイルを管理してなくてもいい。

最後、11個目はマークダウンのプレビュー機能。だいたいどのエディタでもこの機能があってプレビューできるんだが、最初にイラっとしたのはマークダウンエディタで書いたあとに貼り付けた先でhtmlにうまく変換できていない場合。たとえばバッククォート3つで囲んだコード部分はtumblrではコードとしては扱わない。tumblrはスペース4つ以上が行の先頭にある箇所をコードと認識する。ほかには、段落から改行してすぐハイフン記号などで箇条書きをはじめたとして、あるエディタではそれを箇条書きとしてプレビュー表示できる。しかし、はてなブログではきちんと段落のあとに改行だけの行がはさまらないと箇条書きとして編集してくれない。こういうことがあるなら、むしろ紛らわしいのでプレビュー機能はいらない、ということだ。これだけじゃなくてPandocでマークダウンから変換したときのePubなんかでもこういうことはよくある。どのサービスやアプリで書き出すかによってマークダウンの記法を微妙に変える必要がある。Githubとかでもそうでしょ?

どんなエディタにしたのか

以前から、理想のエディタではなく現実的なエディタとして考えていたのはブラウザだけで動作するものだった。というのも、アプリだとそこらじゅうにインストールしてまわることになるので面倒だし、AmazonKindle Fireだとアプリ自体がほとんど流通していないのでブラウザで動いてもらわないことには困ってしまうのだ。

スマホだとどうせフリック入力になるので、正直なところなんでもいい。iPhoneだったら下手をすると音声入力のほうが速いということも考えられるぞ。

ということで、本当に最低限のミニマムなエディタをつくっていっている。まだまだつくりはじめたばかりだし、今どきのつくり方ではない。だけど、用を足せるならなんでもよい。

機能

  1. 単語数と文字数が表示される
  2. 何もしてくれないエディタ
  3. 5秒おきにローカルストレージへ保存
  4. 10分おきに鐘の音を再生する

たったこれだけ。いまのところこれで十分に快適な執筆を行うことができている。とてもいい。

まず1つ目の単語数と文字数だが、これはエディタ用のtextareaの値を単語数では半角スペースと改行文字で区切ったときの数にしてある。英語の文章を書くことはあまり考えにくいけど、最低限ということで。文字数はtextareaの値のlengthプロパティそのまま。せいぜいtrimしてあるくらい。

次に2つ目。本当になにもしてくれないエディタ。キーアップのイベントを拾って単語数と文字数を表示させるのみ。

3つ目はよくあることなので。文章を書いている途中で割り込みが入ったときにファイルに保存してなくて…ということが頻繁にある。これはwri.peがかなり頻繁にlocalStorageへ保存してくれていたことを思い出して入れてみた。再度開いたときにlocalStorageに指定のキーがあればそれをエディタへ表示してくれるようにしてある。

4つ目は完全に謎の仕様だけど、わたしには必要。熱中して書いていると、時間を忘れてしまう。そこで、10分おきに鐘の音を鳴らすようにしてある。鐘の音はFL Studioにデモ版として付属してくるSytrusというFMシンセサイザーにプリセットされている鐘の音を鳴らしたものをmp3にエクスポートして利用している。やはり金属音っぽいものはFMシンセサイザーに限る。もちろんWebAudio APIなのでFMシンセを実装して鐘の音を鳴らしてみてもよかったのだけど、以前つくってみたときには思ったよりきれいな音にならなかったので普通にシンセの音にしたほうがいいな、と考えていた。いまのところこのタイマーを一時停止する機能はつけていないので、10分おきに鳴り続ける。もう少し使い方に慣れてきたらタイマーの間隔を指定できるようにしたいと思っている。

今後実装したい機能

もうほんの少しだけ機能追加したいな、と思うものはある。きっと近いうちに追加していくと思う。

  • 鐘の音のタイマー時間を設定できるようにする
  • Ctrl+Sでタイマーを待たずにローカルストレージへ保存できるようにする
  • 文章を読むために要する目安時間を表示できるようにする
  • フルスクリーンモードにできるようにする
  • テーマを切り替えできるようにする
  • スマホ向けブラウザでの見栄えを改善する

今後は公開サーバーでホストするようにもしたい。わざわざローカルのウェブサーバーを起動するのが面倒なので。そうなるとほかにもいろいろすることが増えそうだな…

現時点の開発環境

項目 環境
OS Windows10
サーバー PHP7.0 ビルトインサーバー
ブラウザ Chrome, Edge
IDE Visual Studio Code
記事の執筆 開発中のエディタ

cloud9とかつかったほうが便利なような気がしなくはないけど、静的ファイルのホスティングにわざわざウェブサーバーの環境とか必要ないだろうと思うのはわたしだけだろうか。

また進捗があったらここへ投稿していきたい。

PowerShellはどうした

PowerShellPHPビルトインサーバーを起動するために利用しているよ! 以上だ。

Image-Line FL STUDIO 12 SIGNATURE BUNDLE【国内正規品】

Image-Line FL STUDIO 12 SIGNATURE BUNDLE【国内正規品】

はじめてのVisual Studio Code (I・O BOOKS)

はじめてのVisual Studio Code (I・O BOOKS)

Y!モバイルにした話

雑記 メモ 振り返り 格安SIM

突然のMNP

まったく考えていなかったのだけど、妻が唐突にケータイ変えようと言い出して急速に調べてMNPしてしまった。 以前からiPhone5sの容量不足を嘆いていた妻からすると、ごく自然な流れだったのかもしれない。 これに拍車をかけたのが、妻の同僚のMNPだった。ここで、身近にキャリアを変更した人物が登場して一気に現地味を帯びたわけだ。

その方はいま頻発にCMを見かけるようになったUQモバイルMNPしていた。そう、妻のようなケータイ事情に疎い人間にも格安SIMは身近な存在となったのだ。そうなると、月額使用料の差をガツンと見せつけられ、感情が高まるのも無理もないことだった。

そういうわけで、数社をピックアップして比較検討と現在のキャリアに残り続けるメリットとの比較がはじまった。

キャリアvs格安SIM

既に機種自体の支払いは終えていたのだが、更新月以外での解約には解約料が必要になる。よって、解約料が夫婦揃って必要になることは明白だった。にも関わらず、我々は乗り換えを選択したのだった。

我々夫婦ともに次のような状況だった。

  • 自宅には光回線がある
  • 外出先でネットは殆どしない
  • 通話も殆どしない
  • 連絡はLINEが主

このため、固定費としての基本料は見合わない額だと感じられた。 一方で格安SIMは基本料がキャリアに比較してかなり押さえた額となる。ここはメリットのひとつであることは間違いなかった。ただ、格安SIMに移る場合に大きなデメリットとして次が挙げられた。これはいずれも妻の利用形態である。

  • キャリアメールを使用する
  • SMSでしか連絡の取れない友人がいる
  • ECサイトにはキャリアメールを登録している

このため、SMSとキャリアメールが必須という条件が付いた。こうなると、かなり選択肢が絞られてしまう。

格安SIMはその特性上、音声通話などのキャリアがこれまで提供してきたサービスはオマケのような存在になる。というのも、キャリアの回線を借りて通話以外の通信をするインターネットサービスが主な内容だからだ。 こうして、最終的にはワイモバイルとUQモバイルが残った。

UQモバイルは妻の同僚が採用していたため、この時点では最有力候補だった。それに、月賦払でiPhone5sを使用することができる。また標準サービスでSMSが提供されており、キャリアメールもオプションで付けることができる。 ここで、なぜこのご時世にわざわざiPhone5sなんだ、と思うところだが、むしろ7や6sを選択したくなかったためメリットとなった。個人的にはSEがよかったのだが、5sで十分なのだ。

  • 使い方がわかっているし慣れている
  • 慣れたので容量も少なめでいい
  • LINEとネットが中心の使用であり高い性能も不要

個人的に気になっていたのは現在でも圏外になるようなところで妻が勤務していることだった。格安SIMなので優先順としてはキャリアよりも低く設定されており、繋がらない可能性が高かった。それに、UQモバイルAUの回線であるため3G回線での通信をすることができない。そこがデメリットだ。

ワイモバイルは格安SIMといいつつ、独自の通信回線をもつので実はキャリアということもわかった。ソフトバンク回線を使用するので格安SIM扱いだが、他とは少し違ったアドバンテージがある。さらにSMSもキャリアメールも標準サービスで提供されている。

言い忘れたが、UQモバイルもワイモバイルもテザリングは無料で標準サービスとして提供されている。キャリアでは有償サービスで使用していたのでありがたかった。

ここまでくると、キャリアとの勝負は基本料くらいしか残っていなかった。ここで、息子に持たせてある子供用ケータイのことを思い出した。このタイミングで子供用ケータイまでMNPするのは手数料プラス解約料で1.2万はかかることになる。それに、機種の選択肢がスマホになることもあった。ネックが突如として浮上してきたため、検討は一度保留された。

子供用ケータイ事情

格安SIMの会社はイオンなどもスマホ想定であり、通話とメールのみとかいうような化石のような機種を取り扱ってはいなかった。それに、ショップで主回線がMNPした状態では子供用ケータイは使うことができなくなるとの説明も受けたため、完全に暗礁に乗り上げた格好となった。

議論の結果、UQモバイルMNPすることになった。そのため、子供用ケータイは契約更新月まで使用不能のまま残しておこうということになった。ひとつデメリットを除外することで価格メリットを前面に押し出すようにしたのだ。もはやキャリアに未練など残っていなかった。

再びショップへMNP予約番号をもらいにいったところ、次なる課題が発覚した。それは光回線だった。ケータイとのセットによる割引がなくなってしまうのだ。そういう方法でキャリアに残るようになるのか…と予約番号を受け取る決め手に欠けたためショップを後にした。

決意

再び議論を進めた結果、やはりUQモバイルに移る決断とした。光回線とのセットによる割引よりも移ったことによる基本料の差額の方がもろもろの金額を大きく上回ってしまったからだ。通話品質はいいのか?という課題は残っていたが、あまりにも電話として使ってないよねという言葉にぐうの音も出なかった。

そして、今度はショップの女性に制止されないようにMNP問い合わせ窓口へ電話をすることにした。ここはウェブから出来たりしない。おそらく機械的にできないからだろう。

すると、意外なことを教えてもらうことができた。 まず、子供用ケータイは主回線がいなくなっても使用できる。管理はできなくなってしまうのだが、管理するにはキャリアのオペレーターに言って変更することなどができるそうだ。 次に、ワイモバイルではガラケーを取り扱っていた。キャリアに近い立ち位置だからだろうか?このため、子供用ケータイが更新月を迎えたら解約してガラケーにすればよいという選択肢ができた。ただ、このガラケーはLINEが使えるようになっている。登録しなければよいということではある。それにテザリングもできるそうだ。やり過ぎじゃね?

散々悩んだ挙句、UQモバイルと決断したはずなのにワイモバイルを選択した。ここも月賦払できるスマホiPhone5sがある。それにソフトバンク回線なので3G回線も使える。ガラケーがあるし、ソフトバンク光とのセット割引ができるそうだ。

そんなわけで、ワイモバイルにMNPした。

MNPその後

正直を言うと、やはり通話品質は良くはない。相手の声がかなり遠くに聞こえる。しかしダメだな、と明らかなのはそこくらいだ。テザリングiPhoneの設定だけで簡単にできるので、キャリアの頃のiPhone5sをそのままテザリング利用している。おかげでネット接続さえあればいいのでアプリで移行したのはLINEくらいだ。他は元のiPhoneを使用している。二台持ちに近い雰囲気に見えるかもしれないが、単純にiPod touchをもっているだけということではある。新たに購入することを考えたら一気に現金が出て行くことはない。さらにアプリ移行しなくてよいのだから便利この上ない。 今後、例えば2年後に同じ環境で暮らしているかは全くわからないけどね。

子供用ケータイのその後

契約は続いていて、電話もメールもできている。さらに、GPSによる位置情報もメールについてきており、受けているのがgmailでも全く問題ない。格安SIMにせず、残しておいてよかったと言える。格安SIMだと子供用などないため、大人と同じ使用料になるわけだしテザリングやLINEができてしまうのは嬉しいことではない。

いずれスマホを持たせることになるのかもしれないが、その前に子供の成長を待っている。

どうなの、ワイモバイル

管理画面がソフトバンクとだいたい同じで、名前もMy Y!mobileとか読みづらい感じ。ソフトバンクのときはメニューが左にあるがワイモバイルは右にある。統一しないのは会社が違うからなのか?

MMSが使えるのだが、ドメインがyahoo.ne.jpになる。それはそうか、と受け入れたがアカウントを他にも持ってるのでややこしい。

キャリアメールとしてymobile.ne.jpドメインのものももらうことができる。何に使ったらいいのかわからないが、妻は使っているようだ。

スマホプランSでもキャンペーンで2年間はデータ容量が2倍の2GBになる。しかし、このキャンペーンは契約月の翌月から適用になる。ショップの店員さんが教えてくれたが、割引も翌月からなので契約したばかりの月はスマホプランMにしておいた。どう考えても容量を食い尽くすことが目に見えたからだ。なかなか罠がある。

最後に、LINEが生活の中心にある方はバックアップしておいた方がいい。新しいスマホに移ると元のスマホにあったデータが消えてしまう。妻はそのことに気づかず困っていた。わたしは困ることはなかったが。

最後に

通信手段としてのスマホになったiPhoneは非常に快適だ。SNSやニュースアプリに時間を費やすことも激減したし、容量が足りなくなるほど何かを保存しておくこともなくなった。もっと早く移っていてもよかったかもしれない。自動的に断捨離した格好となったからだ。

あとはアプリなしでブラウザだけで快適に文章を書くことができるサービスが見つかったら、さらに身軽になれそうだ。

雑記 2年目以降の住宅借入金控除を確定申告するとき

雑記 メモ

毎年やってるけど覚えられないので、メモとして書いておく。

必要なのは以下のものだけ。

  • 確定申告書
  • 住宅借入金控除の計算書 提出用
  • 金融機関からの年末残高証明書

住民票とか契約書とか封筒に共通書類としてチェックする箇所があるけど、必要ない。

毎年これで、必要だったっけーと悩むので書いておいた。助かったな、来年のオレ!!