  |
はてなキーワード: WIkiとは
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
２日後、承認が出た。フェーズが設計から開発に移った。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
裁判長「母親としてあるべき愛情が見いだせない」検察側「自己の欲望や幸福を満たすためには子供の命を犠牲にしても構わないという、母親としては考えられない自己中心的で身勝手極まりない動機」懲役14年
「障害児として生まれない権利」確立を回避するための法律を可決
CiNii - 日本におけるwrongful birth訴訟と障害胎児の妊娠中絶
CiNii - 障害胎児中絶は是か非か : 人は自然を「主」とすることなしに正しさを主張し得るか
heartbreaking. レイプされて出来た子供を堕胎するか否か
Amazon.co.jp： なぜ人を殺してはいけないのか―新しい倫理学のために (新書y (010)): 本: 小浜 逸郎
同人なんか読んでるとどれが公式で、どれが二次設定なのかわからなくなるので、公式設定資料集「東方求聞史紀」を買おうと思ってたんですが
東方系の動画をニコニコで見てるせいか、ニコニコ市場経由で「東方求聞史紀」買ってしまいましてね
まあ、買ったのいいけど全然読まないね。単体で読んでも面白いもんじゃないし。このレベルでハードカバーってのがびっくりだ。
でも、正直なところ、ネットに情報があるわけだから(Wikipediaとか,東方wikiとか)別に絶対必要ってわけでもないかな
出典にあたるという価値はあるかもしれないが。
そもそも、東方の世界観ってある程度適当に出来てる気がするんで、いろいろ推測しても後でひっくり返る可能性も
それにしてもこれ、目次が大項目のみで、キャラごとにインデックスがついてたりしないのね……探すの凄い面倒
アリス...p54
パチュリー...p57
とかキャラごとにページ数付けるとか
あるいは索引付けるとか
http://anond.hatelabo.jp/20070724133040
まあ増田のせいというよりは、はてな記法のフォーマットルールがおかしい気もするが。「改行」と「改行二つ連続」の扱いが同じってどういう神経だ。
俺の感覚だと、前者は段落変え(p)じゃなくて改行(br)に変換(でなきゃ無視)して欲しいんだが……なんでこんな仕様なのか、誰か知ってる？
はてな記法は当時人気のあったいくつかのwikiの記法を元に作ったもの。改行の扱いが独特なのはwiki記法の影響だと思う。
当時ポピュラーだったYukiWiki、PukiWikiともに、改行は無視される仕様になってる。これは、整形済テキストの方に影響を与えないで、ソースになるテキストの方には改行を挿入して見やすくしたい、という状況を想定しているのだと思う。多分もともとは、HTML内で改行が無視される（空白と同様に扱われる）のと同じ発想なんじゃないかな。
話が少し飛ぶけど、こういった点から、国内のwikiは元々は論理マークアップ志向だった事が想像できる。各種記法は書いてあることの意味を表現するものであって、外見（ここに改行が入るとかココはインデントするとか）を指定するものではない、というような。実際、YukiWikiの開発時期は、論理マークアップという考えが広く広まるきっかけとなったHTML4.01やXHTMLの公開時期と非常に近い。
ちなみに、他の各種の記法と比較しても、はてな記法の書きやすさはかなり良好。仕様を見ていると、ソースの見易さを犠牲にして書きやすさを重視したんだろうな、と感じる。再編集する事が少ない（=ソースの見易さを犠牲にしても問題ない）日記記述に特化した感じ。ホントに、気になるのは段落や改行周りくらい。
まあ僕は Wikipedia を Wiki って呼ぶ人の中にわざわざ割り込んで忠告することはしないよ。でも、
http://dictionary.goo.ne.jp/search.php?MT=%B3%D8%B2%F1&kind=jn&mode=0&kwassist=0（左のほう）
Wiki記事
http://dictionary.goo.ne.jp/search.php?MT=%B3%D8%B2%F1&kind=all&mode=0&kwassist=0
これはなあ。Wikipedia と Wiki は異なるものなのであって、ただのにちゃんねる検索を「掲示板検索」と銘打ってるようなものだ。別に個人でやるなら勝手にすればいいと思うけど、企業がこんな半端なことやっていいのかな。Wikipedia のことを言ってるのか Wiki のことを言ってるのか、「Wiki」という言葉だけではろくに判断できなくなっていってしまうよ。辞書という言葉を扱うコンテンツでこれはないと思う。
参考リンク
http://anond.hatelabo.jp/20070530163858
http://internet.watch.impress.co.jp/static/yajiuma/2007/05/31/
http://stick.goo.ne.jp/bookmarklet/（http://stick.goo.ne.jp/bookmarklet/img/0326_image2.jpg）
http://anond.hatelabo.jp/20070521151640
記事とタイムスタンプが強固に結びついてるBlogのシステムが使いづらい用途ってあると思う。
その隙間を埋めてくれそうなベター選択肢としてWikiが挙げられるんだろうけど
WikiはWikiで、元祖のWikiWikiWebの血がながれていて、良くも悪くも癖が有る。
もっと素直なCMSが有ればいいのになぁ、と常々思う。
それと、情報を落とす動機の一つに対話があるからなぁ。体系的ってのは割りとしっかりした連載物のエントリーぐらいでいい。
だけど、割としっかりしたエントリーをブログに落としたり、２ｃｈに落としたり、そういうのが勿体無く感じる。対話がないか、すぐに役立たなくなるのかどちらかだから。
誰かとシェアしてもいいから、対話があって長い間役立つそういう場にちゃんと載せたい。そういう気持ちだよね。
個人的にはFlickrのグループに上手くいっているのがいくつかあるように思う。あれにWikiのような機能をつけてちゃんとまとめあげるページを作れば面白いと思う。
まとめサイトは融通が利かない。
はてなグループは使い方が意味不明、使いこなせるとしても応用性がとても低そう。
個人サイトでひそひそやっていくほどの根性もない。
従来の中央集権的な「伽藍型」宗教に対して、ネット上で議論し合いながら宗教を研究していく「バザール型」宗教は、果たして可能だろうかと考えてみた。
まず、宗教活動の手段としては「Wikiでまとめサイトを作り上げる」というのがすぐに思いつくが、絶対に編集合戦になって収集がつかなくなるだろう。
執筆者は、これまで信奉してきた宗教の考えを反映して書くかもしれないし、このWikiを媒体にして自分の宗教の宣伝に利用しようという人もきっと出てくる。
たとえこれがうまくいったところで、せっかくバザール型で作り上げた宗教が、カリスマのある特定個人とか特定グループの持ち物に変容してしまう危険性も常に存在する。
結局は「バザール型のオープンな宗教」というダシで人々を釣っておきながら、実態は伽藍型であり、数人の「選ばれし者」に刃向かうと追い出されるような険悪な雰囲気になるかもしれない。
内容の正確さについても、自分自身にとって都合の良い内容しか書かず、不利な内容を書く人を排除したりといった具合で、あまり期待できないだろう。
やはり「難しい」というのが結論かもしれない。
海外ラジオの音楽番組をオンライン放送で聴こう（まとめサイト）
http://kintubo.kakiko.com/classical/
FrontPage - * 番組表wiki - 海外ネットラジオのクラシック音楽番組
http://classicradio.hp.infoseek.co.jp/cgi-bin/index.cgi
ＩＰラジオの部屋（１）
http://www5a.biglobe.ne.jp/~k-horn/ipradio01.html
http://music8.2ch.net/classical/subback.html
http://music8.2ch.net/contemporary/subback.html
http://music8.2ch.net/test/read.cgi/contemporary/1115622842/
【クラ専門ネットラジオ】 OTTAVA 【２４時間放送】
Google Baseってどんなんだっけと思って検索して見たけど情報少ないなぁ。
前に名前くらいは聞いた気がしたけどその時もよく分からなかったし、現時点でもベータだったり日本語対応してなさそうな雰囲気だったり。
実際に触ってみてもGoogleが検索用に使うDBって感じで、何か別のDBを構築するのには向いてるのかどうか、そういう機能があるのかもしれないけどそこまで確認して無いです、すまん。
もしかしたら使えるような機能があるのかもしれないんで、また調べて良さそうだったら使うかも、情報サンクス。
Googleサービス内で他にカレンダーとかも使いようによっては可能かな。
局別にカレンダー作って(ひとつにしても大丈夫かも)番組と各スポンサーを載せていくとか、wikiみたいに書き込み無制限には出来ないけど編集権限も追加していけるし。
だけどアカウント持ってない人とか見れなかったりするだろうし、Ajaxって気持ち重くてちょっと敬遠してしまってるんだよなぁ、物凄く主観な意見だけども。
自前でDB用意しないと不安な性分なのでなんだかなぁというのが本音だったり、XMLか何かで吐いてくれるなら外部から使いようもあるんだけど。
なければwikiか自前でそれっぽいCMS用意するなりで、その前に使えそうなサービスあるかどうかもうちょっとちゃんと調べてみる必要ありそうですね。
今のところ、番組別とスポンサー別の両方で見れるような感じにしようと思う。
問題のある番組のスポンサーが他にどんな番組の提供もしてるかとか見れたほうが良いだろうしね。
出来れば各番組の出演者や提供CMの出演者とかも載せられるようにしたいけどそこまでいくとごちゃごちゃしそうだし、本題の「番組へ提供するスポンサーの責任」という部分から少し離れるから、もしもやるとしたら別でサイトを作ってトラックバックやらを使う感じにしようかなと今思った、とりあえず番組とスポンサーの部分をまずまとめておきたいところ。
しかしwikiだとホントに一ページごとに手作業だから、php+MySQLとかで自分で作った方がいいのかなぁと思えてきた。
0から作るとなると時間かかりそうだし、作るとしたら仮でwiki置いといてそっちに情報載せつつもし良いの出来たらそっちに移すとかそんな感じでいいかな。
