久しぶりのMindTouch Deki Wiki TIPSです。
Dekiでは各ページにファイルを添付でき、添付ファイルも検索対象になるため、とても便利です。
しかし、ページ数が増えてくると全添付ファイル一覧を見たくなることもあると思います。
今回は、Wiki内の全添付ファイルを一覧する方法を紹介します。かなり強引なDekiScriptなのですが・・・
まず、テンプレートに新しいページを作り、以下の内容をDekiScriptフォーマットで記述します。
ページ名はShowFilesとして保存しておきます。
<ul>
var pages = [ ];
foreach (var a in xml.select(wiki.tree("/"), "//a"))
{
var text = xml.text(a, '.', null, true);
var id = string.match(text, 'pageid="([0-9]+)"');
var p = wiki.getpage(num.int(id));
let pages ..= [ p ];
}
foreach (var p in pages) {
foreach (var f in p.files) {
<li>
web.link(f.uri, f.name);
web.html('<span style="color:#999999;"> (' .. num.floor( f.size / 1000) .. 'KB)</span>');
if (f.description) {
web.text(f.description);
}
web.html('<br />');
web.html('<span style="color:#999999;">' .. f.page.path .. web.link(f.page.uri, 'goto this page') .. '</span>');
if (f.ThumbUri) {
web.html("<br /><img src=" .. f.ThumbUri .. " />");
}
</li>
}
}
</ul>
あとは、任意のページで
{{ ShowFiles(); }}
と書けばOKです。
ちなみに、トップページに添付したものだけは出てきませんが、これは手抜きです^^
落ち着く、コーヒーがうまい、資料を置いて話せる
良い打ち合わせスポットの条件です

三軒茶屋に住むデザイナと打ち合わせする時
よく利用するカフェがあります
RAIN ON THE ROOF
その名とおり、雨の日には雨の音が響くカフェです
三軒茶屋は良いお店が多そうですね
普段から愛用しているそこらへんのノートパッド。
日常ではバイブルサイズを好んで使っています。
ただ
打ち合わせではA5くらいのサイズがあるといいですよね。
誰といつ話し合った内容か、を後から振り返りたいことが多いので
インスピレーションの走り書きとは別にしています。
弊社馬場先生にきいてみたら、
手書きで書いたものをそのままPCに送ってくれるデバイスがあるそうな。
(1)
http://allabout.co.jp/mensstyle/stationery/closeup/CU20090420A/
小さくて手軽、精度が若干劣る
(2)
http://www.princeton.co.jp/product/tablet/ptbdip1.html#02
http://bb.watch.impress.co.jp/cda/items/21854.html
かさばるけど、精度が良いらしい。ペンが少し壊れやすいらしい
だ、そうです。
たしかに、アマゾンとかでもそう書いてある。
仕事効率が上がりそうなので購入してみました。
メールアドレスを設定しておいて、
日付をファイル名にして自動的に送ってくれちゃうように設定がしたい。
ライトキャッシュを無効にしてもこのスピード!
なんていいやつなんだ・・・

同僚と日本の携帯電話とiPhoneの話しをしました。
所謂持続的イノベーションを続けて消費者のニーズを大きく上回り、
結果として、携帯事業に関してはガラパゴスと言われてきました。
iPhoneは、スペックこそ低くても、新しい携帯電話ではなく、
ユーザの目的にあった携帯コミュニケーションツールを提案したのです。
ぼくは成功したと、考えています。基準は、人それぞれでしょうけれども。
生産ラインの品質やバラエティを確保するためのコストなど
小難しい話しを抜きにしちゃえば同じことが
Wii vs Playstation3、JR vs 駅周辺の店にいえます。
いずれはBPS(やWEB受託開発で生活している人)も
それに当てはまるようになっていくような気がするんですよね。
最初は安くてもいいからサイトをさくっと作れることを武器に仕事をして、
今度は少量の追加料金で綺麗なデザインを添えられるようになった。
でも、ある時気づくのです。
コーポレートサイト一つ作るにしても、
デザインだけあっても、綺麗に開発されているだけでも、だめで、
作って何をしたいか、それをどこまで実現できたか、が重要だと。
その後は、ディレクションによって品質マネジメントまでやるようになる。
それに慣れてくると、プロジェクト全体のリスクヘッジまでやるようになる。
これまで作ってこなかったマニュアルやテスト仕様書までガンガン作っちゃう。
そして、また気づくのです。
仕事し始めたことよりも案件を引き受ける条件も価格も数倍近くになっていて
人材も固定コストもリスクも増えていて、でも利益率だけはあまりかわってない。
・・・
数年後の弊社は、数年前の弊社のような会社に負けてしまう。
会社力で勝っていても、戦略で負けているのです。
安さとスピードで勝負しよう!と考えていた数年前の自分に、
いかに定常業務に慣れるかだけを考えた自分が負けるのです。
アルフレッド・チャンドラーさんの言葉を借りると、戦略がない状態です。
たとえ間違っていたとしても、
仕組みを変える努力をしていかないといけないですよね。
ちなみに、
ある程度定常業務がこなせるようになってきた弊社の来年の戦略は、
1.定常業務を内作より低価格・高品質で外注する手段を設けること
2.ぽっと出の会社が真似できないほどの信頼を獲得すること
3.恥ずかしながら様々な社内ルールがまだ未確定なので基盤をつくること
です。
スイッチを一部ギガビットにリプレースしました!
しかもアライドテレシスです。今日はとっても幸せです。

Intel SSDを購入しました!
しかも、34nm版のリテールパッケージです!!

幸せです。
新しい仲間が増えると、採用当初はまだお互いへの優しさがあっていいけれども、
たいていは時間がたつにつれて、足並みが揃わない度にお互いにイライラし始める。
イライラし始める理由は、コミュニケーションミスによるものばかり。
例えば弊社では最近↓があった。
上司はホウレンソウもできないやつは・・・といい始め、
部下は連絡しづらいとか説明してもらわないとわからない・・・という。
自分で考えて行動してほしい一方で、考える前に行動してほしいものもある。
というわけで、そういったものは予めやりとりのルールを決めて問題を解決する。
BPSスタンダード(やってあたりまえ)を決める。
未確定部分が多いけれども、毎週と毎日かならずやるべきことを設定した。
●毎週
一週間の目的と目標を定める
* まずは自分で考えてまとめる
* 上長にチェックしてもらう
* その内容を共有する
一週間の成果と達成度合いを報告する
* まずは自分で考えてまとめる
* 上長にチェックしてもらう
* その内容を共有する
●毎日
まずやること
* TODOリストをまとめる
o 重要度をかく
o 優先順位をつける
o 所要時間(予想)を加える
* 上長にチェックしてもらう
* その内容を共有する
●帰宅前にやること
* TODOリストの進捗をまとめる
* 次回なにやるかをまとめる
* 上長にチェックしてもらう
* その内容を共有する
細かい部分は各部署毎で設定してもらったほうが良さそう。
もっと良い方法あるかな。。
他社の方針が気になる。