- リンクしたいページを開いて共有から「Textwellに追記」
- Textwellに移動、タイトルとURLが2行で出力され選択されているのでそのまま
- Textwellの「Twitter(Direct, Current & Clear)」アクションを実行
短文ブログを書く方法
3つのルールでやっている(これも短文ブログ)。
- 記事内のURLは1つだけ
- 画像を1枚貼るとよい
- 記事内のテーマは1つ
- 執筆からリリースまで全てモバイルで書く
記事内のURLは1つだけ
特にモバイルだと大量のリンクを集めて貼り付ける作業は大変面倒くさい。
また大量のリンクが貼られた記事はモバイルだと読むのも面倒。
しかしリンクが無い記事だとそこで完結してしまい関連した記事を次々に読めるWebのメリットが生かせない。結論としてリンクは1つでよい。
画像を1枚貼るとよい
リンクをたくさん貼る代わりにスクショなどを駆使して画像を1枚貼ると分かりやすく文書を少なくできる。
スクリーンショットの保存や切り取り加工、ブログへの画像の投稿機能などはむしろモバイルの方が充実しているので積極的に活用する。
記事内のテーマは1つ
複数のテーマを展開させるとどうしても文書が長くなるので1つの記事のテーマは1つに絞る。
テーマを変えながら関連した話題を続けたい場合は新しい記事を書いてそのURLへのリンクを元記事に貼る。
執筆からリリースまで全てモバイルで書く
モバイルで最初から最後まで書けないとどうしても気合いを入れないと書けなくなってしまう。
技術的な話題だと大量のリンクや引用を挟まないと書きにくいものが多いが、どうすればできるようになるかはこのルールに沿いながら模索が必要。
テキストの記述はTextwellのおかげでモバイルでも思い通りに文書が書けるようになった(スライドによるカーソルのスクロールが超便利)。Scrapboxやはてなブログへのエクスポートもアクションを使えば簡単。
経緯
私のようなPC大好きっ子でもモバイルの便利さには勝てず記事を読むのにモバイルを使う割合が年々増えている。それに伴いブログを書く時間も著しく減ってしまった。
同じような状況の人は増えているように感じており、商業的な文書ではないのに、ある側面では専門家の人より詳しく書いてあるような面白いブログに出会える機会が減っている(注: 私のブログは昔から駄文です)。これは文書プラットフォームにおける中間層の喪失ではないだろうか。
アウトプットはインプットに比例するため、インプットの中心となるモバイルで書きやすい記事のフォーマットとして、短文ブログというルールを考え中。
テスト駆動開発 書評
テスト駆動開発を読み終わった。評判通りの良い本だった。
- 作者: Kent Beck,和田卓人
- 出版社/メーカー: オーム社
- 発売日: 2017/10/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
ソフトウェアを書くときにテストフレームワークを使ってテストを書くことはやっていたが、きちんとテストファーストで書いたり(実験的にそういうことをやろうとしていた時期はあった)、体系的に学んだことはなかった。内容がテスト駆動開発(TDD)だけにフォーカスしているのもよさそうで手に取った。
TDDとはなにか
まえがきがとてもシンプルにTDDとはなにかに言及しているのがよい(まえがきをペラペラと数ページ読んで購入を決めた)。
- 自動化されたテストが失敗したときのみ、新しいコードを書く。
- 重複を除去する。
これが実践できるようになれば本の重要なことの50%は達成できたといってよい。(しかしそれを現実のソフトウェア開発でやるのが難しい。)
どのように進めればうまくいくのか?以降に実例を挙げて説明されていく。
実際にコードを書きながらコードとTODOリストを育てていく様も見ることができるのが個人的には嬉しかった。(自分はちょっと大きめにTODOのタスクを切り出してしまう癖があることを発見した。)
TDDのスキル
ネットの情報を漁ると、なぜテストが重要なのか、どのようなツールを使うとテストをかけるのか、といった情報が多い。しかし実際にテスト駆動開発を始めようとすると必要な知識はその先になる。
書籍にはうまくテストを書いていくには何に気をつければよいのかの例がたくさん書いてある。
- まずは仮実装としてベタ書きの値を返すことでとりあえずテストを通してしまう。
- 高すぎず低すぎない階段を作るように1つずつテストを書いていく。
- 三角測量、2つのテストから1つの実装を導き出す。
- LogStringパターン、実行した関数名を文字列に追記していくことで関数が正しい順番で呼ばれていることをテストできる。
- はじめのテストで書くべきものは何か。
- コレクションの操作をテストするときはまず単数を対象にしたテストを通してからコレクションでも正しく動くように育てていく。
- 1回のテスト、実装、リファクタリングのループは15分から30分が目安。
「フィクスチャー」など専門用語の意味も書籍のお陰で分かった。
訳者解説
あとがきの訳者解説も面白い。
TDD初期から最近までのテストにまつわる歴史や訳者の見解がぎっしり書かれている。
原著は割と古い本なのだがこのあとがきのおかげで最新技術とのギャップを上手く補完してくれている。(とはいえ、原著の内容はほとんど古さを感じることはなく、私自身あとがきを読むまで気がつかなかった。)
個人的には”TDD is dead, Long live testing.”がどのような文脈で出てきた記事なのかが分かったのがよかった。
「教条主義化と意味の希薄化」は技術が盛り上がったときにどこでも起きうる現象なので気をつけたい(いい言葉を知った)。
まとめ
全体を通して感じたのはTDDとは考えることを少なくするための技術だということだ。
テストを書くときはテストのことだけ、実装のときは実装だけ、リファクタリングのときはリファクタリングだけに集中する。それを繰り返すことで大きなソフトウェアになる。ソフトウェアが大きくなったときにはすでにたくさんのテストコードがあるので安心して修正できるようになっている。
派手な技術ではないが、堅実に長くソフトウェアを作るのに大変役に立つ。
iPadに昔のiMacに付属していたMagic Keyboardを接続した
ブログの執筆環境に使っている。
iPadはいつも台座付きでリビングに置いてあるので便利。
Vue.jsでTODOリストを作るチュートリアル
前回からの続き。 次は定番のTODOリストを作る。
ToDoリストを作りながら学習しよう! | 基礎から学ぶ Vue.jsを進める。
できた。
https://github.com/ongaeshi/tutorial-todo
こんな感じになる。
結構いい出来。もう少し調整したら普段使いのTODOリストとして使えそう。
index.htmlのthがtdのような気がするので後でMRを出す。(ただ見た目が変わってしまうのは正しいのだろうか?)
vue.jsを勉強できる短いサンプルコードを触る
nippで色々やってやはりJavascriptや周辺のライブラリは便利だと改めて思った。
やはりリアクティブなUIライブラリが1つ使えると何を書くにも便利そう、vue.jsの勉強を再開した。
https://github.com/alephmelo/vue-github-api
手始めにvueを使ってgithubのapiを叩くサンプルコードを動かしてみた。
cloneしてindex.html開すだけであっさり動いてすごい。
※なんとなくmatthさんを検索してしまった、、
短いので理解や改造も簡単。短くて役に立つサンプルコードを探すのは重要。
GitHubからスクリプトを読み込んでnippで実行する
経緯
nippは便利なのだが、一度URLを公開した後にスクリプトを修正すると再度URLを公開しないといけないのが面倒なときがある。
そこでgithubに置いたスクリプトを読み込んでnippにロードする仕組みを作った。(ほとんどnipp作者の @nwtgck さんが作ってくれた)
@ongaeshi さんのコードをお借りして、既存のnippで再現してみました! https://t.co/eDwk4L4Ase #nipp
— @nwtgck (@nwtgck) 2019年2月20日
使い方
で、そのロード用のURLを作るためのnippを作った。例によってawesome-nippに置いてあるが、
- Load from GitHubを開く
ongaeshi/mynipp/master/length.rb
などGitHub上のパスを入力- 出力されたURLをブラウザで開けば https://github.com/ongaeshi/mynipp/blob/master/length.rb がnipp上に展開される
- つまりLoad from GitHubで作ったURLを一度ブックマークしてしまえばGitHub上のスクリプトを修正すれば自動で更新される
感想
スクリプトをGitHubから読み込んでnipp上に展開するためにES2017を使っているのだが、
Opal.load('opal'); Opal.load('opal-parser'); (async ()=>{ const gh = location.search.split("?")[1].split("=")[1]; const res = await fetch(`https://raw.githubusercontent.com/${gh}`); const rbScript = await res.text(); const e = document.querySelector("textarea[ng-model='inputText']"); const $scope = angular.element(e).scope(); $scope.script = await rbScript; $scope.transpiler = RubyTranspiler; $scope.enablePromiseWait = false; $scope.enableClickRun = false; $scope.enablePromiseWait = false; $scope.setLocationHash(); $scope.transpile(); })();
こんな短いコードで書けて感動した。async await の便利さがよく分かった。