唐突に使っている有料アプリケーションを紹介

僕は有料のアプリケーションの購入をかなり厳選したいタイプで、サブスクリプション型のは断固拒否して過していたんですけど、ここ最近は「契約→カレンダーに解約日を設定する」というので管理しようとしている。

MindNode

www.mindnode.com

Macマインドマップを書くアプリケーション。

かなり昔の記事だけど トニー・ブザン 頭がよくなる本 - higepon blog を読んで「マインドマップ・・あるな????」と影響されて買って使い続けている。

いわゆるAppKit製のMacネイティブなルックアンドフィールでJavaクロスプラットフォーム製な他のアプリケーションより使いやすかったのでこれにした。

マインドマップはあまりなかった。

IntelliJ IDEA

samuraism.com

プログラミングをする時の環境。

サムライズムという日本の代理店で購入してる。

IntelliJ IDEAとの付き合いは長く2011年からWebStorm→PHPStorm→Rubymineと経て、言語ごとにIDEがあるのなら、みんな買うしかないじゃない と感じたのでAll Products Packライセンスに移行した。

ただVisual Studio Codeを使えないと時代に取り残されてしまうのではという危機感から、週1ぐらいは代りにVSCodeを起動してる。

関係ないけど「IntelliJ IDEA」「JetBrains」やそれぞれの言語別製品名と呼称がバラけていてウェブ検索する時にいつも迷う。

TablePlus

tableplus.com

MacのDBクライアント。

SQL書く時に使ってる。IDEAにDataGripというツールがあるんだけど、こっちのが好き。

Alfred Powerpack

www.alfredapp.com

Macのランチャー。

スニペットクリップボード履歴を使うために購入した。あまり活用できてない。

HUAWEI CLOUD

www.huaweicloud.com

HUAWEIAWS

「これからはクラウドIDEで複数人でコーディングする時代が来る」とずっと思っていてシンクライアント的な開発環境を試しているんだけど、どのプラットフォームもSSHできるLinuxサーバーを求めてくるのでできるだけ物理的距離の近い場所にあるサーバーが欲しくて契約した。

VSCodeやJetBrainsのソリューションを試しているんだけど、時代はまだ早かった。

Strainer(ストレイナー)

strainer.jp

ビジネス系のメディア。

現代病「集中できない」を知力に変える 読む力」という本を読んでいた時に購読するメディアの意識して分類せよという話があって、何かひとつぐらいビジネスメディアを読む習慣をつけるかと思って契約したやつ。Newspicksや日経電子版などと比較して決めた。

ブラウザとJavaScriptで自動読み上げするツールを作った。その結果中身を読まなかった。

死後強まるサイト

個人開発のコストはDB次第 この記事を見てびっくりした。まずビックリしたのは「DBにお金を払えばいいのでは?」という点。

OSSへの寄付の月予算を$10にした にあるようにソフトウェアに費用をかける意思はあるのになぜプライベートの開発にコストをかけたくないのか。

記事の反応を見て気が付いたのだけど、僕は何故かサーバーレスアーキテクチャの採用を前提としていて、ここにヒントがあった。

最初はサーバー管理に関心がないのかもと思っていたのだけどパソコンとしてLinuxを使うのは結構好きだし、VPSもいくつか契約している。

これは何故なんだろうと考えていたのだけどブログのリセット でも触れたように「死後に放置されたサイトになる」ことを考えているんだろうという結論になった。

ノーメンテナンスでなるべく生き続けて欲しい。思い出してみると独自ドメインを避けるとか宣伝しないなどもその動機の為であった。

現実的なSPOFはクレジットカードの有効期限だと思うのでそれを解決しないと始まらないのたけど。

ブロックチェーンやスマートコントラクトを使った分散アプリケーションへの関心もここにありそうだ。

Tauri on mobile 現状確認会

tauri.app

Tauri とは

Electron代替として作られたRust製のGUIアプリケーション開発ツールキット。

ユーザーは各プラットフォームのWebViewで動くHTML+JavaScriptでUI開発をして、裏側はRustで書いたネイティブバイナリにコンパイルされるプログラムを呼び出す。

実際の実装のイメージが以下で、Electronに使い方は似せられている。

tauri.app

Electronは特製ChromiumとNode.jsをユーザーのアプリケーションに同梱することでポータビリティを担保させているのに対して(find /Applications -name "Electron Framework.framework" コマンドを実行してみると大抵どんな環境にもElectronが10匹ぐらい居る)

TauriはOSが用意しているWebViewにリンクして、スクリプトもネイティブバイナリにするので早くて軽い、というアーキテクチャのようだ。

GUIツールキット界隈ではこのようにプラットフォーム側かエンジン側のどちらに寄せるかという選択自体はよくあり、プラットフォームや動作環境の差異で挙動が変わったり、安定するかわりに成果物が重くなったりと一長一短の歴史ではあった。

ここ何年かの変化としてはWindowsのバージョンシェアやWebView開発環境が一新されてレガシーに引きずられることがなくなったという部分がある。

あとGoやRustのように依存が少ないシングルバイナリをクロスコンパイルできるツールの発展もTauriが出てきた背景としてありそう。

時系列的にはこうだと思う。

製品 時期
Electron 2013年
Tauri 2019年
WebView2 2020年

そしてElectronはApp Storeレギュレーション的にiOS版ビルドを吐くのは難しそうだけど、Tauriならできそうというわけでモバイル対応が進んでいるらしい。

WRYとは

github.com

このディオ・ブランドーみたいな名前のコンポーネントはWebView Rendering librarYの略で、WebViewで動くアプリケーションとバックエンドのブリッジとして機能しているらしい。

内部的にさらにtauri-apps/taoというコンポーネントと組合せてWebViewに任意URLを与えて直接Windowを持つアプリケーションとして実行できるようになっていた。

https://github.com/tauri-apps/wry-mobile というリポジトリも作られているが更新されていなく、モバイル系の開発はどうやらtauri-apps/wryの方からリンクされているHackMDページに情報があるらしい。

hackmd.io

このドキュメントからさらにリンクされているのが cargo-mobile というツールで。gomobileのようなモバイルアプリ向けのビルドをサポートするツールのようだ。

cargo-mobile

なぜかこっちも分裂していて、さらにそれぞれのリポジトリでコミットされている。

すこし眺めてみたところ、オリジナルとTauriメンテナのwusyongさんによるフォークという関係のようだった(wry-mobileのドキュメントからリンクされているのはwusyong/cargo-mobileの方。)。

TauriはもともとRust界隈のやる気勢たちによってコミュニティでメンテナンスされているが、モバイル対応をメインでやっているのはwusyongさんだけだった(モバイル開発まわりには明るくないらしい)。

あくまでも検証中の段階らしく、IPCの動作の確認とシュミレータ向けのビルドやデバッグをしていることが分かる。

tauri-apps/tauri

tooling/bundler/src/bundle/macos/ios.rs

アプリケーションのバンドル化のコードにmacos->iosがあることが分かる。

iOS SDKとのインテグレーションがあるというわけではなく、アセットファイルの生成ぐらいの処理が定義されている。

2021年に最初にコミットされたバージョンからあまり変更がなかった。

tauri/tooling/bundler/src/bundle/settings.rs

ビルドできるバンドルの種類。Androidの定義はなく、apk,appbundle,ipaなどのフォーマットに関するコードも今はない。

/// The type of the package we're bundling.
#[derive(Clone, Copy, Debug, Eq, PartialEq)]
#[non_exhaustive]
pub enum PackageType {
  /// The macOS application bundle (.app).
  MacOsBundle,
  /// The iOS app bundle.
  IosBundle,
  /// The Windows bundle (.msi).
  WindowsMsi,
  /// The Linux Debian package bundle (.deb).
  Deb,
  /// The Linux RPM bundle (.rpm).
  Rpm,
  /// The Linux AppImage bundle (.AppImage).
  AppImage,
  /// The macOS DMG bundle (.dmg).
  Dmg,
  /// The Updater bundle.
  Updater,
}

分かったこと

  • モバイル対応はまだ検証中
  • iOS/Android SDKと連携する部分の開発はされていない。
  • wusyongさんの助けが必要

ここまで書いたけど単にWebViewで動くHTML+JavaScriptアプリ開発をしたいだけならIonicを使うのがいいと思う。

ionicframework.com

Rust好きやデスクトップアプリケーションとの共通化を見据えてTauriの開発に参加したい人にはフィットするかもしれない。

iOSDC JAPAN 2022にプロポーザル提出した #iosdc

iosdc.jp

nextstep.fm でみんなすごい気を遣ってSwiftの話をしていたので、ウッ・・後ろめたい・・! と思ってiOS界隈に為になることをするぞとやる気になってiOSDC JAPAN 2022にプロポーザル提出した。

(このようにただの感想ブログにリンクを張ったら先方にPVが流入してしまうということがよくあるのが最近の困まりどころ)

fortee.jp

「全部Swiftで作るWebアプリケーション」はいわゆる縛りプレイ系の内容で、特定の技術のカンファレンスでまぁまぁ行われている伝統的な手法。僕の記憶に残っているのはyouchanさんがOpal芸をよくやっていた気がする

全部Swiftで作れるかは今をもっても判明していなくて、SwiftWasmではじめるWebアプリ開発 があるからどうにかいけるのでは??? 程度の目論見がある。

僕は普段からkateinoigakukunさんの活動を尊敬しており、SwiftWasmをカンファレンス駆動開発で実際に使ってみたいと思ったこともあります。

fortee.jp

「サーバーサイドSwiftで学ぶバックエンド開発」は上記のトークを需要を伺いよりオーソドックスな路線に下げたもので、フロントエンド側をあきらめバックエンド側に重点を置いた。

最近Cloudflare Workers上のノンフレームワークな環境でコード書いていて、ルーティングとかJWT認証やCookieの暗号化を意識して実装する必要があったため馴染みがあり。実装例もVaporを読み解けば分かりそうだなと感じたので、この内容にした。

過去のiOSDC JAPANを思い起すに僕は抽象的な話ばかり好んでいた傾向があったので、次何かやるならストレートにコードがたくさん出てきそうな内容にしたいなぁと前から思っていた。

いづれにせよ数年iOS開発から遠ざかってしまって愛機もAndroidなので、アウトサイダー感もありつつ。採択された暁にはまたSwiftをがんばってキャッチアップしないといけなさそう。

仕事でやっていないということは余暇をこれに当てるしかないので単純に他のことできなさそうでつらい。

そんなブログたちを集めたリンク集(!?)がこちらです

fortee.jp

iOSDC Japan 2022のチケットはこちらで販売中です。

www.eventbrite.com

マネーの教育

www.youtube.com

Youtubeでタレント動画を消費するような視聴者は投資について「今は貧しいけど頭を使ってかしこく大金ゲット」というコンテンツを期待しているが、本当に語りたいことは「所得を増やして資産運用」なので、地味であんまりウケないらしい。

そもそも他人の事業の労働以外の方法で所得を得るということを実践している人がまわりにいないと想像すら難しく。あっちゃん氏やプペル氏が自分の視聴者に向けて事業で所得を得ることを説くと詐欺師や守銭奴的な扱いを受けバッジングを浴びることになる。こうして世間の人に批判され続けることがマネー教育なんだなぁと語っていた。

動画に出てくる投資家(事業家?)はホリエモンのようなタイプのことで、労働で所得を得る想像力の人が思い描くお金を稼ぐ人というは「有名企業で出世して年収何千万」みたいなロールモデルだと思うけど、僕はあんまりどっちにも惹かれてない。Micro ISV37signalsワナビー的にいいなと思っているけど。

それは新興業界の中のプログラマーという職業が今の時代にたまたま労働条件に恵まれていて、生活環境的にも追い込まれていないってことだと思うが、仮に地方都市で製造業やサービス業に従事していたとしたらどうなっていたのだろう。

ブログのリセット

blog.kyanny.me

Re:のRe:ブログになっていて何やねんという感じだけど関心のある話題だったので反応。

関係ないけど本来のTumblrマイクロブログはこういう使い方をしていた気がする。

閑話休題、自分自身がブログサービスのプロバイダーにいるエンジニアでユーザーたちのことを好きだったらどうするかな、というのを考えていた。

エクスポートツールを勝手に作るのはたぶんやると思う。現にnoteからJSONファイルをダウンロードするツールを速攻作っている。関係者を説得してオフィシャルに実行できるのかはパワーバランスとか人間関係とかあるので自信はない。

note自体はMarkdownを変換して投稿するツールも自作するぐらい使っていた。IPアドレス確認事案(以後、本件と呼称します。以後出てきませんが)の際にnoteの考えるユーザー保護の考えとのズレを感じて使わなくなってしまったけど……

エクスポート機能もMarkdownエディタも、note社のロードマップ自体にはあるようだ。

noteは2022年4月の発表会では、エクスポート機能について「開発が遅れている」と説明していました。 https://news.yahoo.co.jp/byline/yamaguchikenta/20220526-00297873

自分は一般的なブロガーより「サイトが死後にどうなるか」という話題を頻繁にしていると思うのだけど、行動は結構矛盾していてサイトのログやアーカイブドメイン契約はしょっちゅう消失してしまっている。

バックアップとしてはてなグループを使っていたこともあるんだけど、はてなグループ自体が解体されてしまった。

このブログも無数にある投稿先の候補から選んでいる1つだけど、あんまり使い分けるポリシーも定まっていない。

あまりアーカイブの保護をがんばらない理由は、めんどくさいのというのもあるけど、インターネットに公開されているものを他人が自由にできる権利の方を大切に思っているからだと思う。

なくなって困る人自身が保存し、公開すべきであるという意思を持つ人によってホストされてほしい。

例えば趣味のWebデザインというサイトには他人のサイトを転載するためのページがある。

こういう厄介おたくそうなウェブのコンテンツに対する思想は『パターン、Wiki、XP』という本が売れていた時代に結構持っている人々がいた。

その環境の影響を僕も受けているのだと思うし、みんな大好き東亜飯店画像という内輪ネタがあるんだけど、これも僕はそのコンテキストで使っていた。ほんとかよ。

贋作NFTアート

トークンが紐づいたこの画像こそがオリジナルだ、だからオリジナルの所有権を手に入れるためにトークンを買ってくれ」というのを別のトークンでやった場合、大多数の人たちは「どっちのトークンが本物か」を判別できないのではないか。どちらも「トークンが紐づいた同じ画像」ではあるので。

■ - @kyanny's blog

同じことを思っていたので想像してみた。

なんらかのアート作品がトークンAとトークンBとしてマケプレにあるとする。

(ちなみにこの分野は知識がないので情報は正確ではないが、ただしい知識を得たら訂正する気はある)

トークンを見る

自分が買い手側なら  https://etherscan.io/ などで履歴を見てみる。

取引が行われていたらその量などを見る。

そこで差があったらトークンAの価格はこれぐらいだな、トークンBはこのぐらいだからどっちを買うかと決める、

しかし、明くる日の朝に目がさめたらトークンCで同じ画像がアナウンスされていた。トークンAもトークンBも贋作だったのである。

スマートコントラクトでなんとかする

数量限定トークンにはECRだか何だかの仕様とOSS実装があって。スマコンはそれを継承している。

なのでそのスマコンのアドレスから発行したトークンを辿って本物かどうか特定する。

とかできるの?(知らない)

個人的にはFirefoxのアドオンがあなたの個人情報を抜いてないかどうかインストールする前に解凍してJS読みましょうと言われる並にめんどくさい。

偽スマートコントラクト登場

しかし、明くる日の朝に目がさめたらスマートコントラクトDで同じ画像がアナウンスされていた。昨日のスマートコントラクトが偽物だったのである。

私はかぶっていたメタマスクのその場に叩きつけ、星新一SSSBTDAOミートアップへジョグで出掛けるのであった。