DropBoxのPublicフォルダが普通のフォルダになってた

以前からDropBoxのPublicフォルダに画像ファイルなんかを置いておき、tumblrでブログを投稿するときにはそれらファイルの公開リンクを取得して画像を表示させていたのだが…どうやら今年2017/3/15をもってPublicフォルダは普通のフォルダになってしまったようだ。

しかし、対処法はあって共有リンクというのを作成すること。以前はPublicフォルダ内のフォルダパスみたいなものもURLに含まれていたけどIDみたいなものに変わったようだ。

https://www.dropbox.com/s/（任意の英数字16ケタ）/（ファイル名）?dl=0

デスクトップアプリなどでファイルを右クリックすると「DropBoxリンクをコピー」というメニューがいつのまにか表示されるようになっていた。 これで上記のようなURLがクリップボードに貼り付けされる。

ただ、このままを使うとDropBoxのページでファイルを見るだけになる。そこで、最後の「dl=0」を「dl=1」にする。こうするとファイルが直接ダウンロードされるようになる。試しにtumblrで公開リンクで貼り付けていた箇所を「dl=1」にした共有リンクに変更してみたところ、404エラーになっていた画像が表示されるようになった。

このまま過去の記事を延々とリンク差し替えしていくべきかどうか悩むところだけど、そこまで大事な画像があるわけでもないのでこの際にブログを整理してもいいかな、とも思う。

さらに、今後のものは書籍っぽいものはGitBookを使ってもよいと思うのでtumblrは徐々になくしていくかな。

www.dropbox.com

40代を目前にして学ぶAndroidアプリ開発 - はじめたよ編

実はいまAndroidアプリ開発を独学している。つい最近までスマホアプリにまったく興味がなかったのだが、息子たち世代がもっとも触れているコンピュータを考えるとそれはスマホであるということを痛感したため学習をはじめることにした。

無償サービスを求めて

ここ最近、無償で学習することができるサービスをいくつか見て回ってAndroidアプリの開発を独学できるところを探していた。もちろん一番最初に見たのはドットインストールだ。Android開発をさらっと見ることができた。と言っても、ほんとうにさらっとしていて、これで何かを得られたわけではなかった。もし得るものがあったとすると、1つ目の動画で教えてくれるAndroidアプリ開発者向けのポータルをGoogleが用意していることだ。そうか、こんなのあったんだ、という気づきであった。

https://developer.android.com/index.html

そしてさらりと動画でどんなものか見てみて、「ああ、iOSアプリとかとだいたい同じっぽい雰囲気なのかな」と勝手に思いつつさらに無償で独学できるものを探していった。無償を優先的に探したのは、息子が自分で調べて学習するときにクレジットカード情報が必要になったりするとモチベーションが低下して「めんどくせぇ」となってしまうからだ。最初は無償ではじめることができるに越したことはない。

探していくと、PDFで書籍を公開している会社を見つけた。かなりのボリュームで、書籍として販売していてもおかしくなさそうなものだった。

Tech Institute アプリ開発者養成講座テキスト
http://techinstitute.jp/material/02/

ここのPDFにはJavaの初心者向けのテキストから、実際にAndroidアプリを開発してみることができる内容まで幅広く書かれたものが公開されていた。ライセンスはクリエイティブコモンズ。こちら、小学生が読むにはちょっと難しそうだったが中学生以上だともしかしたら読んで理解することができるかもしれない。1点だけ困るのが、2015年に公開されているようで、すでにテキスト内でつかわれているコードが現在のAndroid最新バージョンでは使わないことになっているものがあるところだ。しかもかなり初歩段階で登場してしまうので「ぐあっ」となってしまう。

こういう書籍がアップデートされないことによってモチベーションを低下させてしまうのも、かなりもったいない。自分の電子書籍がずっとアップデートされていないことを棚に上げて言うのは非常にアレなのだが、こうした最新バージョンが次々と登場するものを書籍としてパッキングするのはなかなか勇気のいることだと思っているので、最新化されるといいな、という気持ちではある。

結局

結局のところ、どこの無償サービスがよかったかというと、個人ではUdacityというオンライン学習サービスにGoogleが用意している無償コースがもっともよさそうであった。

Android Development for Beginners by Google
https://www.udacity.com/course/android-development-for-beginners–ud837

英語にも関わらずかなりわかりやすい。ほとんど完成しているプロジェクトと正解例として完成しているプロジェクトの両方を一式ダウンロードすることができる。Githubに公開されているので、ブラウザでコードを見ることもできる。

なにより、Androidアプリ開発者向けポータルにそのコースが紹介されているので、そこから入っていくことができたのは探し回る労力が多少軽減できてうれしいかぎりだ。

https://developer.android.com/training/index.html

Androidアプリ開発を独学しはじめて気づいたこととしては、Javaを少しでもかじっていたら参入することがたやすいということがある。Javaを選択したのは単純にC#が当時まだオープンソースでもクロスプラットフォームでもなかったからというだけではないかと思う。というのも現在ではXamarinとしてC#でiOSもAndroidもアプリをつくることができるソリューションが提供されているからだ。

iOSアプリもすこしかじってみたことがあるが、徐々にmacの独特のUIが嫌いになりつつあることを認識してしまっただけでやめてしまった。いや、日本ではiOSのほうがシェアは圧倒的に高いと思うしiOSアプリ開発者を目指すといいんじゃないだろうかとは常々思っている。わたしのようなやつはC#やJavaのようなIDEが何から何まで手取り足取り教えてくれるような環境からでないと学習をすすめることができないからというだけだ。

もうひとつ気づいたことは、Android StudioひいてはそのベースとなっているIntelli Jのすごさだ。こいつ、すげーと思う。非常につたない言葉ではあるが、Visual Studioより快適かもしれない。それにEclipseを遥か昔に使っていたことがあるのだけど、比較しないほうがいいな、と思うくらいだ。あれとはまた別の何かで、別の乗り心地の良さがある。

さらに気づきとして、Javaはものすごく進化したのだな、ということだ。Groovyをつかったりしていたけど、Java書けばいいのでは？という気持ちになってくるくらいには進化したんだなということが非常によくわかった。Androidに利用できるJavaは純粋なものではなくてAndroid向けのものではあるが、その時点でも十分なくらいだ。これならC#のクロスプラットフォーム化ももっと進めば、さらに楽しくなるのではないかと感じた。

小学生以上がAndroidアプリ開発をするとしたら

もしも息子を含めてAndroidアプリ開発をしたい！と思っているのであれば、書籍を買うのはお勧めしない。英語だけどGoogleが用意している動画を観るのが一番よい。字幕も英語だが、そのなかの単語を調べながらすすめていくと英語の学習にもなるしなぜそのような書きかたをしないと動作しないのかも理解しやすいので、ぜひ辞書を片手に学習していくといいと思う。

何を言っているのか、言葉がわかってもわからない！ということならJavaを先に学習したほうがいいかもしれない。Javaは学ぶことがたくさんある面倒なやつではあるけど、苦手意識を持たずにコミュニケーションしていけば、かなり親切なやつだと気が付くはずだ。また、スマホアプリを使ったことがなければ、なんでもよいので手元で実際に触ってみるのがいいだろう。イメージがわくことが先決だ。使ったことがあれば動画の中で話している内容が「あー、ああいうやつね。はいはい」となるのでぐっと身近になるだろう。

ひとつ懸念としては、実際に書いたものを動かしてみたくなるはずだが、エミュレータを動作させるためにはかなりのメモリが必要になるという点だ。こどもに与えられるコンピュータ、もしかするとScratchが動作すればいいや的なものだとかなり厳しいというか無理だと思う。執筆用のSurface Pro3はメモリが4GBしかないのだが、これでギリギリ動作するラインだ。大学生でスマホアプリ開発を学んで一発当てたい！などと思っているようなら初期投資として8GBを超えるメモリを積んだコンピュータを用意したほうがいいだろう。そうしなければ学習どころではない。そんな金ねぇよ…という方は4GBでコツコツやるしかないだろう。

単純にJavaがどういうものか、書いてみたいだけという方はブラウザ上でコンパイルと実行ができる以下のようなサービスを使うといいだろう。Eclipse やIntelli Jはあまりスペックの高くないコンピュータにはつらいものなので。

Compile and Execute Java Online
https://www.tutorialspoint.com/compile_java_online.php

それでは、ちょっと学習してくる。

Javaプログラマ歴20年な人のためのAndroid開発入門

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

小学生がhtmlを学びやすくするためにオンラインエディタをつくってみたがボツにしたい

こんにちは。先日は小学生の息子にhtmlを教えるとき普通のテキストエディタだと高機能すぎて使いづらいということをエントリしていた。

今回は、その結果としてオンラインエディタを作ってみたけどボツにする出来栄えだったことをご報告したい。

どんなエディタなのか

つくったのは「presch」というもので、小学生向けなのでPre-Schoolというところから名前はつけた。ウィンドウを左右真っ二つに分割して、左側ペインにエディタ、右側ペインにプレビューアというよくあるものをつくった。左側でタイプしていくと右側でタグの内容が解釈されて表示されるというものだ。

まずはプロトタイプということであまり時間をかけずにおおよそのデザインだけして、エディタ部分だけMonaco-Editorを採用した。これはわたしの愛用するVisualStudio Codeのエディタ部分で使用されているエディタだ。ライブラリとして利用することができる。埋め込むだけならものすごく簡単に埋めることができる。READMEに書いてあるとおりのコードで埋め込むことができる。ここから変更されるごとにエディタ内への記述内容をそのまま右側ペインとしている要素のinnerHMTLへぶち込むという非常に雑なつくりだ。プロトタイプなのでひとまずの使用感がわかればいいかな、というところ。

実際にこれを実装して使ってみたところ、h1タグなど小学生に教えやすい（文字が大きくなるので）ものは大きく見えるのだが、次の点でイケてない。

1. どれが見出し１なのかなど書いた要素がプレビューでどれなのかわかりにくい
2. 後付けのスタイルシートを有効にするにはインラインで記述するしかない
3. html文書構造全体を書いてもinnerHTMLなので意味がない

上記課題のうち、最初のものは事前によくあるタグについてスタイルをあてておくことで「～色の文字が見出し１だよ」と説明しやすくはなった。課題２のスタイルシートについては課題３と同じ原因なので悩むところだ。

課題２と３についてはよくあるオンラインエディタが行っているようなことを行っていないため発生している。それは、iframeによるhtml文書そのものの埋め込みを行っていないということだ。よくあるオンラインエディタ（JS BinとかJS Fiddleとか）はエディタ内の情報をバックグラウンド処理してサーバーへ送信し、htmlドキュメントとしてプレビュー部分にiframeで読み込んでいる。しかも別ドメインにしてあるためクロスドメインによる危険なスクリプト実行もできるだけ回避してあるのだ。たしかにこうすればスタイルシートもjavascriptも存分に記述することができる。JS Binを使ったことのある息子としては「htmlしかダメなの？」と聞いてくるほどなので、つらい。

ボツ

ということで、いまのところプロトタイプ段階でこのpreschエディタはボツになろうとしている。もちろんサーバー側を用意することはできるが、それならJS BinやJS Fiddleでいいじゃんということになる。こういうものはスタート時点がうまくいっていないと、あっという間にボツになるものだ。このエディタに要した時間はそれほどではなかったけれど、大いに学びはあった。

Monaco-EditorはVS Codeのエディタ部分ではあるけれど、かなりVS CodeではMonaco-Editorの標準的な動作に手を入れているように見えた。たとえば、日本語を変換、確定するために入力してあるところでは、その時点ですでにプレビューのほうへその情報が入っていた。つまり入力された内容は変換前に取得できてしまっていたということだ。そうなると、見た目はかなりおかしなことになる。それに、エディタ上で入力するときも同じ場所でずっと文字だけが変わっていくという挙動になった。これはリリース当初のVS Codeにもあった動きだったと記憶しているので、なんらか対策方法があるのだと思う。今現在のVS Codeでは発生しないからだ。

あと、このたびiframeの属性としてsandboxなどセキュリティに関するものについてドキュメントを再読したのだけど、わたしの理解が悪いのかオンラインエディタのiframeの書き方ではsandbox属性が無効になるような危険性があるようだった。ある意味で仕方ないのかな？とも思ったが理解不足であることはいなめない。

そのほか、エディタとしてアプリ内通信を行うようなものでiframeのかわりにElectronのwebview要素を使っているものも調べた。これもiframeと似たような属性を持っているのだが、Electronだけで利用できるもののようだし途中で調査をやめてしまった。インストールするタイプだとディスク容量もかかるしね。

今後エディタを開発するか、別の方法を採用することにするかは少し検討してみたい。

小学生にhtmlを教えるために考えたこと

小学生、というか息子たちからhtmlを教えてほしいと言われて教えている。すでに教え始めてから2か月くらいが経過している。いまではわが子もYoutubeの共有から埋め込みコードをコピーしてきてはhtml内に貼りこんで喜んでいる。

手元に持ってこれた！！

なんというか、素直でとてもよい。もちろんダウンロードしているわけではなくプレーヤーが手元のhtml内に表示されるので再生することができる、ということなのではあるが、それだけでも楽しいらしく、自分用のプレイリストのようなものをつくって同時に再生したり時間を少しずらして再生してケタケタと笑い転げていた。

小学生にhtml？

2020年に必修化されることになったコンピュータプログラミングだが、おそらく小学生にはScratchを教えてくれるのだと思う。けっこうすごいものをつくっている子供もたくさんいるし、大人たちも本気になってプログラミングに興じている。あれは非常に面白い。お父さんお母さんもスマホのゲームばかりしてないで、たまには自分がつくるほうに回ってみるのも面白いものだと思うのだが。

さて、一方でおそらく中学生に教えてくれるであろうhtmlである。小学生、しかもまだようやく日本語を鉛筆で書くのができるようになった頃合いにも関わらず、htmlを教えるのは思っていたよりハードルが高い。なにしろ、英語が母国語でないので自分が書いている意味を理解できるようになるまでには英語の授業を受けるくらいの年頃になるのではないかと思う。さらに深刻なのがキーボードによるタイピングだ。小学校の授業にパソコンの時間があるそうなのだが、そこで教えてもらうことができる時間内ではとてもタイピングまでは到達できない。さらに大学生でもいまはフリック入力するほうが速いくらいなので、いまの小学生は間違いなくフリック入力のほうが速い。とはいえ、フリックだけで入力できるほどhtmlは生易しくはない。

とにかく厳しいのが角かっこの存在だ。テキスト向けのブラウザしかなかった時代に、テキスト中で「ここが大事なところ、ボールド！」などと目立たせようとすれば、こうしたちょっと変わった記号を入れて囲むしかなかったのだと思う。いまとなっては入力しづらいものでしかないため、静的サイトジェネレータなんてものがあるのだと思うが。しかしそうしたものを英語どころか日本語も学習途中である小学生に「rubyでこの…」などと言っても時間の無駄である。

息子に教えるときには、率直に角かっこで囲むのだと話をした。すると、意外にも率直に入力していくではないか。もちろんタイピングは両方の人差し指で、だが。

htmlを教えて気づいたこと

わたしもアホなほうなので、以前にサラリーマンだったころに後輩などに教えていたような内容を非常にゆっくりとひとつずつかみ砕いて教えようとした。しかし、これでは子供には合わない。なぜなら、できるようになることが１つずつで全然面白くないからだ。そう、おもしろくないものは悪としか言いようがない。興味を急速に失っていき、集中力も維持できないため余計に時間がかかる。大事なことは、楽しいということだ。

以前にわたしの電子書籍でいただいていたレビューを思い出した。Windowsでプログラミング入門しようというものだったのだけど、黒い画面ばかりでつらいだけだったという内容だった。たしかにつらい内容ではあった。ほぼなにもインストールしない標準のWindowsだけで延々とプログラミングをしていくというものだったので、書籍の前半にはコマンドプロンプトしか登場してこないものだった。言語は比較的やさしいものではあったけど…まぁ楽しくないよね。

さらに失敗したことは、身のまわりにあるhtmlを見せようとしてミニファイされたものを見せてしまったことだ。もはや呪文ですらない、呪い？怨念？のようなものがずらーーーっとならんださまは、息子から完全に集中力を失わせてしまった。これもほんとうにアホだった。

一方で、予想外の大きなリアクションをもらったのがhtmlがなんの略語なのかという説明だった。ほんとうに余談として話をしたのだけど、呪文のようなものが一気にリアルの世界へやってきたような感触を味わったようだった。どうしてそれが誕生したのか、どうしてそれが普及してきたのか、なにがハイパーなのか。そこで失われていた集中力はやや回復してきたのだ。

さらにはhtmlの文法としては誤っている状態であっても、h1でデカい文字がブラウザに表示されることや文字の色を変えたことも新しいおもちゃを手に入れたという感じだった。何が妥当か、なんて子供にはまったく関係がなかった。正しいも間違っているもなかった。まずは興味を持たなければ、そのあとの世界には足を踏み入れることはできないということだ。

さらに思っていること

小学生がhtmlを学習するために最適なテキストエディタが存在しないということがわかった。いま息子にはSublimeを使わせているが、メニューを日本語化していても文字が小さいうえ、半角や全角もまだ理解しきっていないのでブラウザで見たときにうまく表示されないことが多くて困っていた。もちろん文字の大きさはエディタの設定で変更することができるが、ふつうの過程でテキストエディタをダウンロードしてきてインストールしたり英語のメニューを日本語化してもらうのは学習に入るまでのコストが大きすぎると感じた。

なにかよいエディタがないものか… などと思って、またしょうもないエディタをつくりはじめた。今回はmonaco-editorをベースにしている。というのも、htmlはハイライトできたりしたほうが学習しやすそうだと考えたためだ。

ただ、現時点ではinnerHTMLに入れているので部分的なhtmlしかできないし、息子からはcssやjavascriptはできないのかと言われているのでまだまだ作りこみが必要かもしれないが。

いちばんよくわかるHTML5&CSS3デザインきちんと入門 (Design&IDEA)

たった2日で楽しく身につく HTML/CSS入門教室

いちばんやさしいHTML5＆CSS3の教本 人気講師が教える本格Webサイトの書き方 「いちばんやさしい教本」シリーズ

GitBook Editorで快適な執筆生活を送りたい

GitBook EditorをWindowsにも導入した。第4章を追加したところで気持ち悪くなって作業を中断している。何が気持ち悪かったかというと、保存の挙動だ。てっきり保存を行うと、オフラインなのでパブリッシュされないだけでファイルが保存されるのだと思い込んでいた。しかし、実際に起こったことは別の動きだった。

Saveとはなにか

GitBook EditorにおけるSaveというのは、ファイル保存をすることだ。ただ、問題になるのはどこへ保存するのかだ。てっきりファイルシステム上へ保存されるのだと思い込んでいた情弱が悪いのだが、実際にはGitリポジトリへコミットがなされる。つまり、テキストファイルの単純な保存だと思っていたわたしにとってはコミットされるだなんて！という驚きがあったわけだ。

考えてみれば、オンラインエディタ版ではパブリッシュされてしまうのだから、この挙動は想像に難くない。むしろ便利なのかもしれない。というのも、コマンドラインからコミットする必要がないからだ。とはいえ、コミットのときにメッセージを書いておかなくていいのか？という気持ちがないわけではない。ということで、今回のこのコミットはなかったことにしたい。そういうときは「git reset」であります。コミットとしてはされなくてよくて、書いてきた内容は残したいのでワーキングディレクトリは変更することなくコミットした履歴だけ削除する。

git reset --soft HEAD^

これでひとつ前の状態にリセットすることができる。わたしの場合はchapter4.mdを追加した時点でSaveしてしまい、そのうえ第4章のタイトルをつけてSUMMARY.mdファイルが更新された時点でもSaveしてしまったので２つ戻ることになったのだが・・・

念のために書いておく。こうして巻き戻すとGitBook Editorは追跡していないファイルがあることを検知する。すると追跡していないファイルの状態を復元するか変更（ここではファイルの破棄）を破棄するかのどちらかを迫ってくる。ここで破棄を選択すると追加したファイルは削除される。つまり「–hard」のオプションと同じことになる。注意していただきたい。restoreを押すとコミットしていない、つまりワーキングディレクトリが変更された状態でエディタを起動することができる。そしてウィンドウのキャプションにも「(modified)」と表示された状態になる。Saveを、コミットをしとけということなんだな。コミットするまでアプリを終了できないじゃないかー

GitBookだけで快適な暮らしがしたい

GitBookではファイルシステム上の変更は保存というアクションを行うことなく実行することができるため、基本的にSaveはコミットを行うタイミングになる。だから、ガンガン気にせず章立ての追加やファイルの追加をしていって、ここでひと段落だな、というところで初めてSaveをするのだ。そうしなければ、わたしと同様に巻き戻す必要が出てくる。

そうなると、執筆の環境としてはsatoyama-editorと同様に保存なしということになるのでコピペをしようとするタイミングがSaveのタイミングということになる。あとはリッチすぎるくらい優秀なマークダウンエディタなので、足すとしたらBGMくらいだろう。数年前につかっていたエディタで雨の音などの環境音をバックグラウンドに鳴らすことができるものがあったり、いまでもタイプライターの音を鳴らすことができるものがあったりするが、わたしもそういうものを鳴らすようにしようかと思ったり思わなかったり。少なくとも、このGitBook Editorには必要ない！

今回のことで覚えたこと。

1. 「File」で右クリックするとファイルを追加することができる
2. 「TOC」の「add a article」をするとSUMMARY.mdファイル内にあるリンクが更新される

つまり、TOCのほうで章を追加すると章の名称をファイルのベース名として拡張子「.md」のファイルが追加されるということ。だから日本語の章を追加すると不思議な「.md」という名称のファイルが作成されてしまっていたのだ。だから面倒をなくすにはTOCのほうからアルファベットで章を追加して、その後に日本語の章に変更すればよいということ。かなり面倒。うん、VSCodeにしようかなと思うくらいには面倒。

リッチな環境はできることが多くなるわけだが、気にしてあげないといけないところも増えるので作業スタイルにあわせて利用することが求められるなーと感じた次第。うん。