「tailwind」の記事 - Crieit

【個人開発】作るのも、答えるのも簡単なWebアンケート「ankeyto」を作りました！

2022-08-31T09:35:31+09:00

2つ目の個人開発サービス公開

アプリケーションのモダン化を勉強しようと個人開発を始めて、以下の記事のように公開していました。もう振り返ると1年経つんですね…　こういった個人開発活動を続けることにより、少しずつ知識も身についてきて、開発スピードも上がってきていました。

Github Issuesをキレイに外部公開するサービス「2go」作ってみた
- https://qiita.com/nice2have/items/28449ae4ef45fef2c671
海外進出を目指して、ProductHuntへ個人開発サービスを投稿するまでにやったこと&やった結果を全面的にシェアする
- https://qiita.com/nice2have/items/f59a27c266efb9b8821c

実際には公開していないのですが、atodyという「Twitterでいいねしたツイートに含まれるリンク・画像だけを自動でまとめてブックマーク化できるサービス」を開発したのですが、いまいちサービスの完成度に納得がいっていなく、開発したサービスとしては3つとなったのですが、公開したサービスは２つとなります。

簡単Webアンケート

今回は会社の一定の範囲で簡単にアンケートを取りたいときに、Google FormｓやMicrosoft Formsを作るのは手間だな、もっとライトな感じで反応を知りたいなと思ったのがきっかけです。

また、アンケートの回答を得るまでのハードルが結構高いと思ったんです。アンケートURLにアクセスして、回答を入力して、、、となると、答えてくれる人が少なくなってしまって、アンケートの価値が薄まってしまうような気がしたんですよね。

機能を最小限に絞ったアンケートをリリースしよう

これらの課題を解決しようと、ankeytoというアンケート機能を最小限に絞ったサービスを開発しようということに至りました。ankeytoはアンケートのモジりで「アンキート」と名付けることにしました。ちなみに、先程のatodyも「あとで」のモジりで「アトディ」と名付けています。

https://ankeyto.com

開発する前の大まかなコンセプトは、A3ノートにまとめる用にしているのですが、汚い字で申し訳ないですが、公開してみます。

サービスのコンセプトは以下の２つと設定しました。
+ 最大３つまでの選択肢
+ 選択肢ごとのURLにアクセスすればもう回答済みになる

そのため、選択肢を表示して回答ができるページをSNSでシェアするのではなく、アクセスしたら回答できるURLをSNSでシェアするだけで良くなるのです。例えば、「これが良いと思ったら、このURLにアクセスして！」と言えば良くなり、アンケート回答のステップとハードルを減らすことができるのです。つまり、個人個人で対象への「いいね」を調査・獲得できるイメージです。

画面イメージ

こちらのようにアンケート回答がリアルタイムにグラフやUIに反映されるので、回答が多いと変化を楽しめるかもしれません。例えば、プレゼン最中の意見を軽く聞きたいときや、勉強会のフィードバックを簡単に得たいときなどに利用できるかもしれません。

アンケートを作るときの画面も極力シンプルにしています。こちらもログインが必要だと手間が増えてしまったり、入力項目数が多いと途中で離脱してしまう可能性が高くなってしまうので、最小限にすることを意識しています。

利用技術

個人開発者としてはまだまだペーペーなので、利用技術も運用負荷が最小限になることを意識しています。
- Firebase(Firestore/Functions/Hosting)
- Vue.js
- Tailwindcss
- Slack

サービス自体がとてもシンプルなので、HostingでWebページを表示し、質問作成や回答をFunctionsで処理し、結果をFirestoreでリアルタイムに反映しているだけです。一応、モチベーション維持のために、質問が作成されたり、回答されたりしたら、FuncitonsからSlackに通知されるようにしています。

将来に向けて

最後に、将来は以下のロードマップを考えています。
- URLにアクセスするよりもさらにハードルを下げるために、URLをQRコード化できるように。
- Cookie等を利用した重複回答者の防止機能
- 質問IDをランダムでなく、わかりやすいIDを提供できる機能
- API機能（UIだけでなく、いいねAPIを提供）
- 英語対応

最後に。

まさにこのankeytoを利用して、このWebサービスってどうですか？とアンケートを取って終われればと思います。以下が質問ページから、SNS共有用にコピーできる文章になります。「いい！」か「まあまあ」のURLにアクセスすれば回答が完了しますので、ぜひよろしくお願いします！

Q. このWebサービスってどうですか？
https://ankeyto.com/q/BbDJA3P11

いい！ : https://ankeyto.com/BbDJA3P11/1
まあまあ : https://ankeyto.com/BbDJA3P11/2

また、個人開発の進捗などを垂れ流すTwitterもやっていますので、こちらもよろしければフォローお願いします。
https://twitter.com/jnakajima1982

サブスクの解約忘れ・無駄遣いを防止するサービス「Subreco」を開発して得た3つの学び

2022-06-26T14:43:49+09:00

筆者について

「多くのユーザーが実際に使って、価値があるものはなんだろう？」と考えながら、個人開発を趣味ではなく「収益を出す」ために行なっています。

技術だけでなく、デザインやグロースハックも好きで、色々な視点からWebサービスを作り上げていくのが好きです。

今回ご紹介する「Subreco」は個人開発を始めて3つ目のサービスとなります。

Subrecoの公式サイトはこちら

なぜ、サブスク管理サービス「Subreco」を作ったのか？

自分自身、何度もサブスクの「解約忘れ」で失敗した経験があったからです。

あなたも、サブスクなどで使っていないサービスを解約し忘れて"無駄な支払いをしてしまった経験"ありませんか？

家計簿アプリ、クレジットカード会社が提供しているアプリは時々見ていたものの、「あっこのサービス使ってないのに解約し忘れたぁ！(絶望…)」ということが何回かあったんですね。

1回だけならいいのですが。何回も経験したので「さすがにどうにかしたいなぁ」と思って、次はメモアプリとカレンダーアプリを併用して使っていました。

これでサブスクと契約更新日を両方管理できる！対策バッチリ！

、、、と思いきや、だんだんメモとカレンダーアプリで二重管理するのが面倒くさくなり、結果的に続かなかったんです。。

メモアプリやカレンダーアプリだと「毎回今月は〇〇を使っていたっけ…？」とわざわざ自分が使っているサービスを"意識"して見直さなければなりません。

でも、そんなの毎回意識できないし、面倒ですよね？

この経験から、使っているサブスクを「定期的に見直す仕組みを自動化」しようと生まれたのがSubrecoです。

Subrecoの特徴

Subrecoの使い方はシンプルに3STEPで完結します。

①今使っている全てのサブスクを一括管理して把握する
②各サブスクの契約更新日があるたびに自動通知する
③通知があるたびに「利用継続」or 「利用停止」を判断する

契約更新日はメールで自動通知するため、わざわざメモを見直したり、毎回カレンダーで契約更新日を設定し直さなくて済むのがポイント。

使っているサブスクを登録しておくだけで、自動でSubrecoが契約更新日をお知らせします。

Subrecoの公式サイトはこちら

「Subreco」を作って得た学び

①慣れないことはしない
②コア機能を徹底的に絞る
③自分は使うのかを考える

ここからは実際にSubrecoを開発して、得た学びを3つ紹介します。

①慣れないことはしない

実は、当初SubrecoはNuxt.jsで作っていました。(ちなみにNuxt.jsを使うのが今回が始めて)

最初は順調だったものの、徐々にハマるポイントが多く、開発スピードが落ちてきたので、思い切ってLaravel×Vue.jsでリプレイスしました。

結果、開発スピードは3倍以上にUP。

ここから分かったのは、収益目的で個人開発をする場合、絶対に自分が慣れているフレームワークで開発すべきだということ。

ただでさえ開発以外にもすべきこと(デザイン、マーケetc.)が多いのに、開発に負荷がかかる進め方は合理的でないと痛感しました。

②コア機能を徹底的に絞る

テレビのリモコンを想像してみましょう。

・電源の入/切ができる
・チャンネルで主要な局が切り替えられる

一番使う機能が多いのは上記だと思います。

しかし、実際にテレビのリモコンを見ると他にもボタンがありますよね。
で、実際にほとんどのボタンを使っていないという方も多いのではないでしょうか？

そう。実際にユーザーが求めている機能はシンプルであることが多いです。

これはWebサービスも同じ。

Subrecoの場合、

・サブスクの管理が一覧で見れること
・カレンダー形式で契約更新日を確認できること
・契約更新日を自動でメール通知してくれること

これさえあれば、Subrecoが提供したい価値の必要条件は満たせていると判断して実装していました。

実装前に大事なのは、Webサービスの機能として「必要条件」と「十分条件」を分けて考えること。

これは過去の自分に何回も言い聞かせたいです。

③自分は使うのかを考える

個人開発でアイディアを出す際に、

①自分起点・・・自分の課題を解決するアイディア
②相手起点・・・自分以外の人が抱えている課題を解決するアイディア

の2パターンがあります。

今回思ったのが、個人開発をするという前提に立って言えば、圧倒的に自分起点で開発するのが良いと思いました。

なぜなら、スタート地点で需要が少なくとも「1つ」は存在しているから。
需要が0の場合はそこからスケールさせようがないですが、1であればスケールさせられる可能性は残っています。

また、1番のヘビーユーザーは自分になるため、あった方が良い機能や操作する中で潜在的なバグに気付くことができます。
最悪、誰も使わなくても自分を助けてくれるツールとして機能するので"一石三鳥"ですね。

まとめ

収益目的で個人開発をすると考えることは膨大にあります。

もしかしたら、あなたも「個人開発で収益を出したい！」と、もがいて、あがいている途中かもしれません。

僕もあなたと一緒です...！

ただ、辛いことや苦しいことがつきものの個人開発ですが、その過程で得られる

「うひょ〜！」という小さな成功体験(考えていた機能が完成した時etc.)
「よし進んでるな」という実感(Todoリストにチェックを入れる瞬間)

これらは圧倒的な揺るぎない自信、資産として必ず残っていきます。

だからこそ、個人開発を続けている方は諦めないで、一緒に頑張りましょう！

僕は引き続きSubrecoの改善を続けていきます！ではでは！

Subrecoを実際に利用してみて、ご要望・感想などありましたら、メッセージ頂けると嬉しいです！^^

Github Issuesをキレイに外部公開するサービス「2go」作ってみた

2021-09-10T06:00:03+09:00

はじめに

今回初めて個人開発で作ったサービスを公開します。今までも何回かトライしていたのですが、なかなか公開までに至らないうちに、なにか問題にぶちあたったり、時間がかかりすぎて情熱が冷めてしまったりしていたので、今回はまずはスモールスタートで公開して改善していくことを心がけました。大体今回の公開まで、開発を始めてから1ヶ月程度になります。毎日朝4時半に起きて、子どもたちが起きる7時過ぎまでを開発時間として取り組んできました。

どんな人向け？

自分で作っているサービスの開発ロードマップをユーザーに公開するために、都度ブログを書いたりするのも大変ですよね。もし、自分のサービスのソースコードをGithubで管理していたとして、Github Issuesを見せるとしてもGithubに馴染みのない人にとっては読みにくいですし、外に出すサービスであればあるほど、Githubのレポジトリは非公開になっていると思います。これをなんとかできないかなと思いました。

どんなサービス？

まずはこちらを見てください。
https://2go.plus/nice2h/2go/roadmap
このようにGithubのレポジトリ内のIssueをMilestone区切りにして、Githubに馴染みのない人にも見やすいロードマップサイトを公開するサービスです。もちろん、非公開のレポジトリを公開設定にすることなく、ロードマップだけを外部公開することができます。

Githubアカウントでログインすると、以下の設定画面になります。レポジトリを選択して、どのMilestoneを共有するかをチェックして保存します。すると、自動的にロードマップサイトのURLが生成されるので、こちらにアクセスすれば常に最新のロードマップを見ることができます。このURLをシェアすれば、多くの人にあなたのサービスのロードマップを簡単にキレイに公開できるわけです。

Milestoneを今まで使っていな方は、Milestoneを作成して、Issueを割り当てればロードマップを整理することができます。また、Labelを活用している方もいらっしゃると思いますので、Milestoneの中のLabelでIssueをフィルタすることもできます。これらを駆使することで、Bugは見せずにenhancementだけ表示するなどのことも可能です。
今後の予定としては、今はMilestone基点で表示しているところを、Labelベースで表示できるようにもしたいと思っています。その他は、まさに上記のURLを参考にしていただければ、いつも最新です。

どんな技術を使ってる?

企業での開発経験はないので、全て自己流です。書籍やWebサイトを中心に勉強して開発しながら学んできました。念の為、利用している技術は以下のとおりです。
- Laravel : APIとBlade（SSRはやってみたことあり）
- Vue3 : フロントエンド（今回初挑戦）
- Tailwindcss : デザイン（Bootstrapからの脱却）
- Docker : これらの開発環境と、本番でもDocker利用（いずれ分割予定）
- Cloud : Conoha VPS(インフラに時間を掛けたくなかった)

気になっていること（随時追加予定）

開発環境はLaravel sailを使いましたが、本番は自前でdocker-compose.ymlを使いました。このあたりのコンテナの構成をどのようにしているか気になりました（本番でもsail使う？）
本番環境にコードをpullしてからnpm run prodしてbuildが終わるまでにラグがあり、この間は使えない機能が出てしまったりするが、このあたりをみなさんはどのように工夫しているか？
DBについては、どこまでレコードを暗号化するか。検索機能などとのトレードオフになると思われるが。。

今後は？

現在alphaフェーズですが、alphaとしてもう1段階リリースの予定があります。多くの人に使っていただき、Feedbackをいただきながら改善して、開発経験を増していきたいと思います。また、今回の個人開発は最初から海外も同様の問題を抱えていると思ったので、最初から英語圏も視野に入っており、今の所すべてのUIは英語にしています。以下の英語Twitterアカウントも作成して、情報発信していこうと思っています。

https://twitter.com/2go_plus

もちろん、日本語のTwitterは私の今まで通りのアカウントを利用していく予定です。
https://twitter.com/jnakajima1982
ぜひご感想・ご指摘をいただければと思います。

cargo-makeによるプロジェクト・ビルド入門

2020-04-26T21:58:35+09:00

cargo-makeによるプロジェクト・ビルド

モチベーション

cargoはrustのパッケージ管理ツール兼ビルドツールである.これい自体非常に便利なのだが, Web標準は無視できない. 特にSeedのようなWebフロントエンド・フレームワークによる開発ではWeb標準に合わせる必要も出てくる. 単純なケースではQuickstartに従ってindex.htmlに直接wasmモジュールを導入すれば良いのですが, 複雑なアプリなどはwebpackなどが使えた方が便利だと思います. 今回のケースではTailwindの導入などがそれに当たります.

目標

CSSフレームワークであるtailwindcssをSeedプロジェクトで利用する.

前提条件

rustupの導入

とりあえずこれを導入しておけば諸々の開発環境の導入・管理が行えるようになります.

NPM vs Cargo

機能	NPM	Cargo	備考
パッケージ管理	⭕️	⭕️	パッケージのインスタール・公開などができる
依存性管理	⭕️	⭕️	lockファイルがある点など共通点が多い
タスク・ランナー	⭕️	❌	Cargoではカスタム・コマンドが開発できる(はず)
ビルド	❌	⭕️	NPMでは代わりにタスク・ランナーを使う
コマンド拡張	❌	⭕️	タスク・ランナーから呼び出せば良い

Cargoにはnpm-scriptsのようなタスク・ランナーがありませんが, カスタム・コマンドで機能を拡張することができます. その一つがcargo-makeです.

cargo-makeによるプロジェクト管理

seed-quickstartのMakefile.toml内容を解説する感じです. wachモードなどはEvaQL/ui/Makefile.tomlを参照してください.

cargo-makeの導入

cargo-makeの実行にはcargo-makeバイナリが必要になるのでインストールしておきます.

cargo install --force cargo-make

次にプロジェクトを作成します. これもコマンド一つでできます. 今回はwasmモジュールとして読み込まれるので--libオプションをつけます.

cargo new --lib project-name

できたらプロジェクト・ルートに移動し実行してみましょう.

cago make

この時点ではデフォルトのtomファイルが参照されます. 次にMakefile.tomlファイルを作成します.

cd project-name
touch Makefile.toml

同様に実行すると今度はMakefile.tomlをもとに実行が行われます. 任意のmakefileを指定するには--makefileオプションを使います.

cargo make --makefile ./my_build.toml test

Makefile.tomlの書き方

seed-quickstart/Makefile.tomlの解説です. 必要ない方は飛ばしましょう.

タスク

実行するコマンドはタスクという単位で管理します. 何もしないタスクは以下のようになります.

[tasks.do_nothing]
# do nothing

基本

cargoのbuildサブコマンドを呼び出してみましょう.

# cargo make compile
[tasks.compile]
description = "Build"
workspace = false
command = "cargo"
args = ["build"]

それぞれの意味は以下のようになります.

セクション	意味
description	このタスクの内容
workspace	workspaceでタスクを実行するかどうか
command	実行するメイン・コマンド
args	引数の指定

依存タスク

dependencies属性を指定するとコマンドの依存性を指定できます. 要するに呼び出し順序です.

# cargo make start
[tasks.start]
description = "Combine the build and serve tasks"
workspace = false
dependencies = ["build"]

これでcargo startを実行するとbuildタスクが実行されます.

開発サーバーと環境変数

開発サーバーとしてmicroserverというクレートを使います. 簡単なWeb UIの開発には便利そうなのとクレート導入の例として紹介しておきます. 開発の趣旨を開発者の人がブログに書いています.

Microserver: local http server with SPA support

今回のようにあるタスクの前提となるバイナリ・クレートのインストールも記述できます.

[tasks.serve]
description = "Start server"
install_crate = { crate_name = "microserver", binary = "microserver", test_arg = "-h" }
workspace = false
command = "microserver"
args = ["--port", "${PORT}"]

サーバーということでポートの指定もしています. 環境変数もenvセクションで指定できます.

[env]
PORT = "8000"

別ファイルに指定して読み込むこともできます.

[env]
env_files = [
    "./my_env.env",
]

conditionによる条件設

ある条件を満たすときにタスクを実行することもできます. 環境変数がきちんと指定されている場合だけ実行するという条件ならconditionセクションをタスクに追加します.

[tasks.start]
condition = { env_set = [ "PORT" ] }

あるいは特定の環境変数を条件にして新しい変数を定義することができる.

[env]
PORT_EXISTING = { value = "true", condtion = { env_set = ["PORT"] } }
PORT = { value = "8000", condition = { env_not_set = ["PORT"] } }

条件によって読みやすい環境変数に変換したり, 環境変数が定義されていない場合に設定したりということができそうです.

profileによるモードの切り替え

webpackのモードの指定ののようなこともできます.

[env]
env_files = [
    { path = "./development.env", profile = development },
    { path = "./production.env", profile = "production }
]

cargo make --profile production some_task

developmentはデフォルト値なので指定する必要はないです.

タスクの拡張とリリース・ビルド

タスク名をextend属性で指定するとタスクを拡張できます. 例えばcompileタスクをリリース・モードでビルドするように拡張すると以下のようになります.

[tasks.compile_release]
description = "Release Build "
extend = "compile"
args = ["build", "--release"]

プラットフォームごとの拡張も簡単にできます.

[tasks.hello-world]
script = [
    "echo \"Hello World From Unknown\""
]

[tasks.hello-world.linux]
script = [
    "echo \"Hello World From Linux\""
]

[tasks.hello-world.mac]
script = [
    "echo \"Hello World From macOS\""
]

スクリプティング

シェルスクリプトを指定して実行することもできます.

[tasks.echo]
script = [
    "echo hello world"
]

script_runner属性を指定することでpythonなどスクリプトのランナーを指定できます.

[tasks.python]
script_runner = "python"
script_extension = "py"
script = [
'''
print("Hello, World!")
'''
]

またファイルを指定して実行することもできます.

[tasks.run_from_script]
script = { file = "hello.py" }

@rustの指定でRustを実行することもできます.

run_tasks

実行するタスクを指定します. dependenciesで指定したタスクは事前に実行されますが, run_task属性で指定したタスクは事後に実行されます.

[tasks.pre_task]
script = [ "echo pre task"] 

[tasks.post_task]
script = [ "echo post task"] 

[tasks.do_something]
dependencies = ["pre_task"]
run_task = "post_task"

この例の場合pre_task -> do_something -> post_taskの順で実行されます. 並列実行やフォークなど細かいタスクのフローを設定することできます. 詳しくはSub Taskを参照してください.

エイリアス

タスクを別名で参照できます.

[tasks.build]
alias = "default_build"

Seedのexamplesフォルダは複数のクレートが含まれており, そこにはMakefile.tomlが存在します. それぞれのクレートではプロジェクト・ルートのMakefile.tomlを拡張する形でルートのタスクを参照しています. つまり実行する処理は同じといことです.

条件付き実行

条件を満たした場合にタスクが実行されます.

[tasks.test-condition]
condition = {
    platforms = ["windows", "linux"],
    channels = ["beta", "nightly"],
    profiles = ["development", "production"],
    rust_version = { min = "1.39.0", max = "1.42.0" }
}
script = [
    "echo \"condition was met\""
]

このタスクはmacでstableチャネルを利用している人は実行されません. またscriptの代わりにrun_taskで他のタスクを条件を満たした時だけ実行するということもできます.

watchモード

watch属性をつけるとwatchモードで実行できます.

[tasks.run_from_script]
script = { file = "hello.py" }
watch = true

監視対象からの除外のような設定もできます.

[tasks.watch]
description = "Start building project in watch mode"
workspace = false
dependencies = ["build", "build_wasm"]
watch = { ignore_pattern="pkg/*" }

watchモードでサーバーを起動することはできません. この場合run_taskのparallelを使うとファイルの変更を監視しながら配信もで可能です.

[tasks.dev]
description = "Build in watch mode while serving file"
run_task = [
    { name = ["watch", "serve"], parallel = true }
]

tailwindcssの導入

npmを使います.

npm init # if needed
npm install tailwindcss

これでtailwindというコマンドがパッケージ上で使えるようになります. cssフォルダを作成して以下の内容をstyle.cssファイルを新規作成します.

@tailwind base;

@tailwind components;

@tailwind utilities;

これをビルドして利用します. publicフォルダを同じ階層に作っておいて, css用のフォルダを作ります. carg-makeのタスクを追加しましょう.

# cargo make tailwind
[tasks.tailwind]
script = [
    "npx tailwind build ./css/style.css -o ./public/css/style.css",
]

style.cssからstyle.cssが出力されますが中身を見ると見れ慣れたCSSファイルです. 出力されたファイルをpublic/index.htmlに読み込めばtailwindが提供するユーティリティ・クラスを利用できます.

Seedでtailwindを使ってみましょう. Seedの説明はしませんがRustのマクロを使って要素を記述できます. 注目するのはclassマクロです. ここに指定された文字列がtailwindcssのユーティリティ・クラス名です.

fn view(model: &Model) -> impl View {
    let button_class = class!["bg-gray-400", "px-8", "py-4"];
    div![
        class![
            "flex",
            "flex-col",
            "justify-center",
            "items-center",
            "h-screen",
            "text-gray-600"
        ],
        button![
            button_class,
            simple_ev(Ev::Click, Msg::Increment),
            format!("Click Me!")
        ],
        div![
            class!["w-56", "text-center", "mt-2"],
            format!("Click {} times", model.counter)
        ]
    ]
}

こんな感じの表示になりちゃんと表示されました(クリック時にカウント数を表示するラベルが動くバグがありますが・・・)

まとめ

もうちょっとまとまりがあれば良いと思ったのですが, 意外と機能が多く詳細は公式のREADME.mdを読むのがいいと思います. examplesフォルダに例が豊富なので参考になると思います.

tailwindcssはかなり使いやすいですしSeedもいい感じです(ただビルドが遅いですが・・・).

補足

WorkspaceとWorkspace Flow

タスクにworkspace属性を指定できました. Workspaceとは何でしょうか?

A workspace is a set of packages that share the same Cargo.lock and output directory.

Cargo Workspaces - The Rust Programming Language

要するに複数のパッケージを一つにまとめたものです. ただし単一のプロジェクトとして管理される前提なので最終生成物やCargo.lockなどで全体のクレートのバージョンなどは共通化されています. 実態は以下のような内容のCargo.tomlとmembers属性で指定されたメンバーとなるパッケージが存在するフォルダです.

[workspace]

members = [
    "client",
    "server",
]

こうした構成はSeedのserver_integrationという例が参考になると思います. 例えば適当なウォークスペースにmakefileを作りworkspace属性を指定します.

[tasks.do_something]
workspace = false

なぜこのような設定が必要なのでしょうか. 通常cargo-makeのタスクはworkspace直下では実行されません. タスクの要求はメンバー・クレートで実行されます(workspace flow). このおかげでウォークスペースで実行したビルド処理が各クレートで実行されることになり, 共通の処理をウォークスペースにまとめられるので構成ファイルを小さくできます.

しかしウォークスペースで実行したい場合もあるでしょう. その場合にこの機能をオフにするのがworkspace属性の意味です. この値はデフォルトでtrueになっています.

[config]
default_to_workspace = false

のようにも指定するとデフォルト値をfalseに上書きできます.

あるいはコマンド実行時にオプションとして渡すこともできます.

cargo make --no-workspace mytask

CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILEフラグ

CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILEフラグはウォークスペース直下のmakefileに指定します. そうすると自動的に個々のメンバー・クーレトが持つmakefileはルートのmakefileをextendで読み込み参照できるようになるようです.

WASM in A Nutshell

WebAssemblyという技術の略称がWASMでコードの拡張子にもなっている. 通常ブラウザはJavaScriptのランタイムを備えており(V8やスパイダーモンキー)JavaScriptのみを実行できる. JIT(Just In Time)コンパイラによる最適化など高速化されたが, 原理的にはランタイムはJavaScriptを逐次解釈してマシンコードに翻訳しそれを実行するために遅い. このプロセスを飛ばせれば, ネットーワークにるRTT(Round-Trip Time)を無視すればネイティブ並みに高速化できるわけです. これはPythonやRubyなどのインタプリタ言語がC/C＋＋やRustなどの言語より遅い事と基本的には同じ関係と言えそうです.

そこでWeb版のアセンブラを導入しようという話になるわけです. 通常アセンブリ言語はマシン語と1対1に対応するニーモニックを用いて表現されますが, WASMがターゲットとするのは複数のマシンを抽象化したマシンになります.

So WebAssembly is a little bit different than other kinds of assembly. It’s a machine language for a conceptual machine, not an actual, physical machine.

Creating and working with WebAssembly modules

この説明を聞くとJavaに近い感じを受ける. 実際に(この比較はおかしいけど)WASIとJavaの類似性を指摘した記事なんかもある.

MozillaがWASIイニシアティブを発表、WebAssemblyをすべてのデバイス、コンピュータ、オペレーティングシステムで動作可能に

また公式ではWASMを以下のように定義している.

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.

WebAssembly

スタック・マシンは良くわからないけどWikipediaによるとJava仮想マシンも似たような定義で紹介されている.

Java仮想マシン (Java virtual machine、Java VM、JVM) は、Javaバイトコードとして定義された命令セットを実行するスタック型の仮想マシン。

Reference

例題

タスクの依存関係, watchモードやcrateの導入などcargo-makeの基本的な使い方を学べる.

seed-quickstart

examplesフォルダからルート・フォルダにあるMakefile.tomlの参照法などが参考になりました.

examples -seed

課題

SeedのようなWebフロントエンドの開発では, プロジェクトをcargoパッケージとしてマインに構成するのかnpmパッケージとしてメインに構成するのかが問題になる. cargo-makeがない場合はnpmパッケージ以下にcargoパッケージを作らないとビルド・プロセスが自動にできない. seed-quickstart-webpackもwebpackを使ってrustライブラリのビルドからwasmモジュールの読み込みなどを行なっている. これをcargo-makeベースに置き換えたい. npm-scriptでコマンド化しておけば, cargo-makeから呼び出せる.

seed-quickstart-webpack