トップ «前の日(10-27) 最新 次の日(10-29)» 追記

2003-10-28

_ Wazilla 1.5 へ乗り換え

http://www.mozilla.gr.jp/wazilla/

Alt + [半角/全角] での切り替えを行ったときにメニューにフォーカスが取られてしまうバグなどに修正が加えられている模様。うん、いい感じだ。

Tags: Tool Web

2004-10-28

_ 午前の部ぅ〜 正答率78% orz

ビミョー。やはり午前対策不足は否めませんな。

Tags: 日々

_ Opera 7.54 for OSX

6 のときより速い。特別これに乗り換えたいと思わせるほどじゃーないと思う。でも選択肢には入ったと思う。確実によくなってる。しかし文字化けとか基本的なとこがね。まだ。

Tags: Apple Tool Web

2005-10-28

_ FreeStyle Wiki 4 と PDF 関連の機能

[Fswiki-dev] FSWiki 4.0のコードベース

FreeStyle Wiki はあまり真面目に使い込んだことが実はないのだが、PDF の生成が最初っから組み込まれていることに感心したのはよく覚えている。これは自分が Wiki をコミュニケーションツールとしてではなく、コラボレーションツール、もっと言えばドキュメンテーションツールとして捉えているからである。(だから頑張って印刷用 CSS を作ったりする。)Wiki はとても便利だが、印刷資料を重んじる文化は残念ながら根強く、往々にしてパワーの強い側がその文化圏内に居ることが多い。だからきれいな印刷が得られる Wiki はとてもユニークで存在意義があると自分は思っている*1

しかしこの、今もって独特の実装の一つである FreeStyle Wiki の PDF 関連の機能が、オプショナルな扱いに変わるかもしれないくらいに足かせになってしまっているってのは知らなかった。まぁ最近はクライアントサイドで無料のツールを使って PDF が作れるようになってきているし、Wiki の機能としては需要はあまりないのかもしれない。自分としても Firefox 1.5 で OS X でもヘッダフッタを操作できるようになればそれでいいかも。*2

FreeStyle Wiki は実は PukiWiki よりずっとページの管理も考えられているし、機能的にはあんまり不満はないんだよな。記法以外は。

Tags: Tool Web

*1 簡単に言うと多くの人にとっては 1000ページの Wiki よりも 100ページの印刷資料の方が説得力があるってこと。コの業界的には 1000ページの javadoc, phpdoc よりも 100ページの Excel 書きドキュメントが重んじられることだと言えば、いやな感情を抱ける人は多いはず。あれこそ印刷に応用できたら嬉しい人は多いだろう。

*2 コマンド一発で全ページ PDF 化、とかはできなくなるけど、それこそ現状では需要なさげ。

_ 古川ブログの font size 指定が外れない

ただのにっきへの降臨から続く、古くて新しい本文のレイアウトに関する問題の件。

私の知っているビルゲイツ、その12

span style は外れたが、font size=3 は外れないまま。OS X + Firefox ではなぜか MS P ゴシックの指定が外れた方が文字が太くなって見にくくなってしまった。(Firefox でのフォント指定はヒラギノ角ゴW3)

しかし本人は無指定にしたつもりで size=3 が頑固に残るってことは、無指定だと size=3 になる仕様なんだろな、たぶん。これなら style で指定してくれた方がユーザースタイルシートで上書きできるからまだマシだなぁ。(現状でも文字サイズ的にはずいぶん見やすくなったけど。)

ともあれ、記事ごとにフォントサイズが指定できることがものすごく無駄に思えてしまう時点で、msn Spaces の中の人とは相当大きな文化のギャップがあるのは間違いないな。

Tags: Font Web

2008-10-28

_ gnome-terminal って賢いな

中で less とか Emacs を開いている状態で PageUp, PageDown を押すとそのアプリの中がスクロールする。Mac の Terminal.app ではそんなことできないんだよね。これは地味に便利だなぁ。

Tags: Linux
本日のツッコミ(全2件) [ツッコミを入れる]

_  [kterm でも rxvt でも同じ動作になります! > less + UpAllow & DownAllow M..]

_ wtnabe [なるほどと思って調べてみたら Terminal.app では shift を押しながら PageUp, PageDo..]


2018-10-28

_ Webpack 4でyaml-loaderからjs-yaml-loaderに乗り換え

単なるメモ。

Nuxt 1 + Webpack 3 なプロジェクトでは

okonet/yaml-loader: YAML loader for webpack (converts YAML to JSON)

を使ってこんな感じで、

config.module.rules.push({
  test: /\.ya?ml$/,
  use: [
    { loader: 'json-loader' },
    { loader: 'yaml-loader' }
  ]
})

で YAML を読み込んでいたんだけど、これが Nuxt 2 + Webpack 4 だと cannot find module や Module parse failed: Unexpected token エラーが出て使いものにならなかった。

調べると Webpack 4 で json-loader は不要だの CommonJS, AMD, ESModule だのの扱いが変わって七面倒くさい感じの話があり、YAML を import する方法のブログだけで様々なやり方が出てきて「あーもう、こういうとこやぞ Webpack は!」と思ってたんだけど、そういや Nuxt 1 + Webpack 3 の頃になぜかうまく動かなかったような気がする js-yaml-loader を思い出して試したらあっさり動いた。

ということで Nuxt 2 + Webpack 4 なプロジェクトでは

wwilsman/js-yaml-loader: JS-YAML loader for webpack

を使って

config.module.rules.push({
  test: /\.ya?ml$/,
  use: 'js-yaml-loader'
})

としていこうと思う。ここの変更だけで import 部分は変えずに

import yaml from <path-to-yaml-file>

で ok なので、たいへんよい感じである。

おしまい。

Webpack は機能の根幹に関わる API が変わりすぎだろ。最初からイヤな予感してたけど、やっぱり地雷感強い。