ちょっとVue component試作したいときにpoiを使う
Vue.jsは「vue-cli」という便利なCLIツールがあって、下記のコマンドでvueファイルの単体起動をすることが出来た。
vue build MyComponent.vue
で、この機能なんだけど、いつの間にか削除されていたようだ。
もともとegoistさんという方がvbuildというツールを作っていて、その機能がvue-cliに取り込まれたという経緯だったかと記憶してる（その辺曖昧なので間違ってるかも）。
で、poiの方はegoistさんのプロジェクトなので、vue-cliになんでも盛り込むのではなく、興味があってゴリゴリ開発する人に移譲するというのはいい方向だとは思う。poiはVue専用でもなくてReactとかにも対応している（ElectronやPWAなんてのもある。ただこのあたりはボイラープレート戦国時代みたいに群雄割拠しているので、自分も何を使ったらいいのか全くわからない）。
で、SVGでVueコンポーネント作るのに、webpack-simpleテンプレート使っていたけど、どうせwebpack.config.jsいじりたくはないし、poiを使ってスリムダウンすることにする。
移行前
移行後
webpack.config.jsと.babelrcが消えた。
babelやwebpackはpoiのデフォルト設定で稼働するので、設定が気に食わなければ、poi.config.jsや.babelrcの直置きで変更することになる。
デプロイも簡単で、poi buildするとdist/以下に下記のようにminifyしたファイルが吐かれる。
なお、poi MyComponent.vueみたいなのは通らない。下記のindex.jsを用意してあげる必要がある。
index.js
import Vue from 'vue'
import App from './components/App.vue'
new Vue({
el: '#app',
render: h => h(App)
})
このくらいなら、別に用意するのは苦ではない。
あと、poiを使ってコンポーネント集作れそうなボイラープレートを作っておいた。 もし、まかり間違ってelement-uiのようなガッツリしたコンポーネント集を作る案件に遭遇してしまったら、使えるかもしれない。
Vue.js + SVG練習2 : Sparkline
あまり体調がよくない（言い訳）ので、今日は軽め。
何の変哲もないsparkline。可愛くもなんともない。
Sparkline.vue
<template>
<svg width="300" height="50">
<polyline fill="none" stroke="#793" :points="points"></polyline>
</svg>
</template>
<script>
export default {
data(){
return {
dat: []
}
},
computed:{
points(){
return this.dat.map((item, i)=>{
return `${i},${item}`
}).join(" ")
}
},
mounted(){
//ランダムデータ
for(let i =0; i < 300; i++){
this.dat.push(
(Math.random() + Math.random() + Math.random() + Math.random()) / 4 * 50
)
}
}
}
</script>
ポイント
- 乱数はいわゆる「コクのある乱数」
- そもそもpolylineって要素があるのを初めて知った
- Vueの場合だと、pointsにバインドして、半角スペースで座標列をjoinすればおわり
- こういう時computedのありがたみを感じる
- 何かインタラクション入れたかったけど、まぁ寝よう
考え
Vue.js + SVG練習1
Vue + SVGで色々UIを作っているんだけど、素振りが必要だと感じたので、変なものをこしらえて引き出しを増やしていこうと思う。
一作目。
コードはグダグダですみません…
CuteButton.vue
<template>
<svg width="400" height="80" @mousemove="over">
<rect width="200" height="50" rx="8" ry="8" x="20" y="20">
</rect>
<text x="120" y="54" text-anchor="middle">I am Button!</text>
<circle r="10" cx="100" cy="20" class="eye-outer"></circle>
<circle r="10" cx="130" cy="20" class="eye-outer"></circle>
<circle r="5" :cx="100 + dx" :cy="20 + dy" class="eye-inner"></circle>
<circle r="5" :cx="130 + dx" :cy="20 + dy" class="eye-inner"></circle>
</svg>
</template>
<script>
export default {
data(){
return {
dx: 2,
dy: 2
}
},
methods: {
over(ev){
const cx = 100
const cy = 20
const dx = ev.offsetX - cx
const dy = ev.offsetY - cy
this.dx = dx / 400 * 4
this.dy = dy / 80 * 4
console.log(dx, dy )
}
}
}
</script>
<style scoped>
rect{
fill: white;
stroke: #793;
stroke-width: 5px;
cursor: pointer;
}
rect:hover{
fill: #EFE;
}
.eye-outer{
fill: white;
stroke: #793;
stroke-width: 5px;
}
text{
cursor: pointer;
pointer-events: none;
}
.eye-inner{
fill: #793;
}
</style>
クリックした時に目がびっくりすると面白いかもしれないねぇ。 ３回くらい続いたら、リポジトリにしてアップするけど、飽きるかどうか五分五分
ポイント
- rectでhover時に背景色を変えたいのだが、textにhoverを奪われてしまう。そこでtext側にpointer-events: noneを設定するとスルー出来る。
- 本当はレスポンシブにしたり、props経由でラベルを自由に設定したり出来るようにしたいが、寝る前で眠いと厳しい
プレーンテキストから４コママンガに変換出来るツールを作った
白ハゲ４コマメーカー リリースしました！
— hashrock (@hashedrock) 2017年6月27日
テキストを入力してポンポンスタンプを押すだけで４コマ漫画を作れます。
※Twitterに直接画像をアップロードする機能はないので、ローカルに一旦保存してくださいhttps://t.co/RCX183cdW8#白ハゲ４コマメーカー pic.twitter.com/qbvRHqO5R3
作りました。
https://mangadown.netlify.app/
ここの所、Markdownからすべてを生成することを目指した「anydownプロジェクト」というのをやってます。
その流れで４コマもテキストから生成できそうだな、と思いついたので作りました。別にMarkdownじゃないんですが、それなりに書きやすいんじゃないかと思います。 大層なことにそれらしいWebフォントを使っていたり、縦書き頑張っていたりするので、白ハゲ漫画を作るだけじゃなくて、普通に４コマのテンプレート生成ツールとしても十分使えると思います。
白ハゲというのは一体何なのか説明すると、「Twitter上で白いキャラクターに持論を代弁させる」というのが何故か微妙に流行り、それを揶揄する用語として「白ハゲ」という言葉が生まれたようなのですが、若干ハイコンテキストです。 なので、白ハゲ４コマメーカーという名前にしていますが「Mangadown」が正式名称です。
※個人的には、Twitterはもともと万人が聞かれてもいないのに持論を展開して楽しむ所だと考えているので、別に白ハゲ漫画に対して特段の意見はありません。好きな表現方法を選ぶべきです。
※あえて言うなら、自分は色白の上に薄毛の兆候があるため、あまり白ハゲ白ハゲ言っていると自分自身が白ハゲになりそうです。
明日Node学園に遊びに行くので、そのためのネタ仕込みという側面もあります。
作っていて驚いたのは、Fabric.jsの高機能さです。canvas要素にアタッチするだけで、リサイズUIの付いた図形やら画像やらを放り込むことができます。更にisDrawingModeというフラグをtrueにするだけで、canvas上に手書きが出来て、書いた結果はオブジェクトになる。実際このツールの半分くらいの機能はFabric.js組み込み機能でまかなえている気がします。
さて、次は何をテキストから生成すべきでしょうかね。
P.S.
スタンプ募集中です。GitHubにIssueを立ててあります。
一緒にanydownやってくれる仲間も募集中です。
Markdownから日本企業っぽいメールに変換出来るツールを作った
Markdown -> 日本企業メールコンバータできた https://t.co/kw67jEpi0Z pic.twitter.com/9qOTW5uQQV
— はっしゅろっく (@hashedrock) 2017年5月1日
かなりバグが残っている（ひどいのは、インライン要素は全部消えてしまう）ので、胸をはれるような代物ではないけど（※追記：直しました）、Markdownから業務メール書式への変換ツールを書いた。
自分の考える業務メール書式とは、以下のようなもの：
- 長文は適度に折り返される（半角76文字ぐらいで折り返されることが望ましいらしい）
- 行を開けることでセクションが表現されている
- 全角記号で飾られている
経緯としては、書類をなんでもかんでもMarkdownで書いているので、メールに貼り付けるときに手で整形する必要があってつらかったために作成した。
自分の作業のみ効率化すっかと思ったのだけれど、何故かこの手のツールに需要があるらしく、意外とみんな手で書式整えてるようだ。
自分はこれに加えて、段落のインデントまでやるんだけど、作ってる最中に「これ完全に自分しかやってないメールしぐさだ」と気づいて、今日からやめることにした。
あと単語ごとに折り返すやつとか、もはや無理やり実装したけど、これもやってるの自分だけなのではないかという気分がしてきた。
メールはもはや前世紀の遺物だと思っていて、大抵のことはイシュートラッカーの方が上手く情報を蓄積できるのだし、自動通知以外の用途に使うべきではないという認識だけど、それでもみんなが使っているから、ずっと使い続けなければならず辛いところ。
メールやめよう運動みたいなのが起きないかなぁと思っています。
おまけ
anydownという、Markdownライクな記法からなんでも生成してやるぞという一人プロジェクトをやっていて、
- Markdownをカンバン形式のUIで編集出来るkanbandown
- プレーンテキストでガントチャートを生成出来るganttpad
みたいな成果物があります。こちらも興味があれば見ていってください。 Excelやメールによるコストの高いコミュニケーションをいつか撲滅したい。
追記 2017/05/03
インラインに関するバグは直しました。わかっているバグはもう一つあって、ネストされたリストはレンダリング出来ません。 ASTの扱い自体があまりわかっていないのが原因で、今もなんとなく雰囲気で動いている感じです。 このツール自体も結局あまり使われないような気もしてきたので、何かない限りそのままです。
ポケモンGoが国内でリリースされて二日目
ポケモンGoは初日に飛びついた。今時のゲームは攻略情報が過多ですぐスポイルされてしまうし、ガチ勢と差がつきすぎてやる気を削がれるので、楽しみたいなら情報のないうちに飛び込むしかない。
で、個人的には結構楽しんでいる。この規模で社会的な何かが起こっているのを見るのは久々だ。
起きていたこと
- 駅などで歩いている人を観察すると、10～20人に一人ぐらいはポケモンGoをやっている
- 歩きスマホ率はかなり高い
- 夜中に出歩いたら、駅前のロータリーに20人くらいが並んでポケモンGoをやっていた
- たった２日で無属性の集団がゲームに最適化されてる感があり、異様だった
- 新たな課題に対して、社会の方が変化して最適化された、そんな気がした
年齢層
- 男性は３０～４０代が多いと思う。
- 女性は２０後半～３０代が多そう。それ以上の人も珍しいが少しいる。
ユーザ属性
- カップル。見た限り一番楽しそうにしている。
- 友人同士
- 男性は３人組が多い。
- 女性はたいてい二人組である。
- 一人
- 男性はゲーマーっぽい見た目の人が多い。
- 女性はOLっぽい人が多い。
所感
正直、ゲーマーはこの程度のゲーム要素だとすぐに飽きてしまいそう。
しかし、カップルや友人同士でポケストップを発見して楽しそうにしている所を見ると、別にゲームとしての完成度は重要ではなさそう。Ingressユーザのポータル芸がポケモン世代を楽しませているようだ。
文句はいろいろ言いたいが省略。全体的に監修が足りていないと思う。
ゲーム要素は軽めだが、スマホの外側に面白がれる要素が存在している。今まで認識すらしていなかった地蔵にルアーが刺さってポケモンが沸きまくるのとか、かなりシュールで面白いと思う。
非ゲーマーを行動させた、ということが大事で、そういった人たちが今後、店舗とのコラボなどの展開にどの程度乗ってきてくれるのか、気になる所。
フロントエンドで使ってるものがあまり変わってない
自分のスタックはあまり変わっていない。ほとんど10年のツケを払っていない。学習能力が低いせいでもあり、選んだスタックがバージョンを重ねている成果でもある。
毎回使う
フレームワーク：Vue.js
- 消耗、などの意見が散見されたが、べつに今でも便利に使えている。
- browserifyやwebpackがあれば便利だけど、なくてもいい、ってバランスが好き
- データフローは特に考えない。状態がそこにあるので書き換えれば良い。
- あまり頭を使わなくていいのが助かる
Reactの考え方は好きなのだけど、よっしゃFluxやるぞって気持ちにはならず、Reactのみでよしなにやるソリューションが広まったらいいなと思う。
ビルドシステム： browserify / watchify
- substackの作るものはどれも品質が高いので、もうsubstack製品だけ使っていればいいやという気持ちになりがち。余計な処理が全然無いってのが安心感がある。
- watchifyはそんじょそこらのwatcherのように暴発がなく安定して動く感じがある。安心して100%依存しているし、他のwatcherを併用しないようにしている。
タスクランナー： npm run
gulpやgruntを使わず、npm run-scriptでなんでもやろうっていう方針。
- run-scriptが長くなると破綻するという話もあるが、.babelrcやbrowserify transform fieldでなんとかならない？
- なんとかならないケースはgulpを使う時もあるが、あってもbuildタスク一つだけにする。watchに凝りだすと沼に入る。
UIフレームワーク： 使わない
- Sanitize.cssは必ず適用する。無いとフォーム周りで死んだりする
- とにかくCSSの総量を削減することが大事だと思っているので、可能な限り自分で書く。
- だるい場合は、Semantic UIを使うこともある。マージン設計が適切ですっきり見えるし、アニメーションがシュッとしてるので高級感が漂う
- UIフレームワークを使う場合は、less or sassでコンポーネントのみインクルードしたほうがよい。グローバルにいろいろなものが展開されることになる（そのうち使っているのは10%だけ、とかもありがち）。
- flexboxはおおまかなレイアウトには使うが、使い過ぎない。地雷を把握してればいいんだろうけど。
オプション
TypeScript
- OOPを採用したい時に使う。
- 別言語からの移植を行う場合は必須
- Vue.js公式が使っていないのでオプションにしているだけで、最近は必須にすべきかなぁと思っている。
less
- 以前はstylusを好んでいたが、IDEのサポートが手厚いのでlessに舞い戻った。
- シングルクラス派なので、mixinが存在するだけでかなり違う。
sushipm
https://github.com/sushicorp/sushipm/
package.jsonにrun-scriptを追加したり、index.htmlの雛形を生成したりする自家製ツール。
sushipm create index.htmlとかする。sushipm devコマンドはwatchのついたrun-scriptをparallelshellでまとめる機能で、お気に入り。
Babelは使わないのか
最近Babel使わなくていいんじゃないか説が自分の中で生まれている。便利には違いないけど、自分はそれほど賢くないので、レイヤが増えた時ハマりそうと思っている。
開発中に、babel導入ですごい改善しそうな雰囲気が出てきたら使うかもしれないけど、開発初期からは入れない。
- IE11以降であればブラウザネイティブでclassが使える
- arrow functionは使えなくても死なないし、腱鞘炎だけ気をつければよい
- importはTypeScriptと解釈が揃っていないので、requireを使っている。すなわちbrowserifyがあればいい
- （たとえbreakingな変更になったとしても標準とずれてしまったら揃えるべきじゃないのかな…）
- yieldは使えないけど、フロントエンドでさほど出番ないような気がする。サーバサイドではNodeなのでネイティブで使える。
- const / letは使いたいが、今のとこなくてもいいかな。
VSCodeは結構補完が効くので、腱鞘炎はあんまり危惧していない。
自分の賢さに合わせる
RPGでも、力が足らなければ装備できない武器があるわけで、使えなくても悲観することは無いと思う。自分は諦めがいいほうなので、React/Fluxスタックからは早々に退散した。
自分が装備を選ぶ基準は、こんぼうであることである。取っ手がついていて殴れればそれでよく、更に釘が飛び出ていたら最高だけど、こんぼうの先からビームが出るべきではない。たとえ、にくいライバルのあいつが鋼の剣を持っていたとしても、スライムを倒すにはこんぼうがいいのだ。もっといいのは、地面に落ちている石を使うことだ。どこにでもあってすぐ使える。格好をつける必要はない。石にもこんぼうにも設定は必要なく、プラグインも必要ない。
