HrsTのあれこれ

PlanetWilson SharePoint Blogにあるカレンダーのカラー化スクリプト （ http://planetwilson.blogspot.com/2011/07/sharepoint-2010-colour-calendar-post.html ） をちょこっと改造して、文字も変更できるようにしました。 背景と文字はセットで変えないと表現の範囲が狭くなりますからね。 ってことで、変更点を・・・ の前に言っておきますが、私はプログラミングは素人なので、 効率が悪かったり、間違った記述かもしれません。その辺は許してください。 ---オリジナル--- function ColourCalendar() {   if(jQuery('a:contains(' + SEPARATOR + ')') != null)   {                  jQuery('a:contains(' + SEPARATOR + ')').each(function (i) {       $box = jQuery(this).parents('div[title]');       var colour = GetColourCodeFromCategory(GetCategory(this.innerHTML));       this.innerHTML = GetActualText(this.innerHTML);       jQuery($box).attr("title", GetActualText(jQuery($box).attr("title")));       $box.css('background-color', colour);     });           }    }    ---変更後--- function ColourCalendar() {   if(jQuery('a:contains(' + SEPARATOR + ')') != null) {     jQuery('a:contains(' + SEPARATOR +

久々に参加できました。 それにしても毎回サーバーを落とすこのイベントですが、運営側も落ちないサーバーを準備していますね。 一応、瞬間最大風速は世界一なので、バルスに耐えられれば処理能力的には問題ないってことですね。 前回は、バルスの前に処理遅延が発生していたけどね。 ラピュタとかって四半世紀前アニメなんだけど、未だに楽しめるよね。すげぇー

ふ～～ん　意外としっかりしてた・・・ まぁ、ちゃんと調べてないから？とかが原因なんだろうけどね。 System Center Configuration Manager 2007の資産インテリジェンスではMicrosoft以外のライセンスも管理できます。 で、どうやって管理するかというと、定義ファイルを読み込んで、レポートで集計するのですが、この定義ファイルが面倒だなぁ～って思ってたの。 だって、ブログラム名、バージョン名（本当は前方一致）を一致させないとダメじゃん？ 勝手にバージョンも完全一致だと思い込んでいたので、運用に乗るわけないじゃん！！って勝手に思ってたんだけど、読み込みエラーでうまくいかないものがあったので、何度か試してみると、どうやら前方一致っぽい感じがしたので、確認すると前方一致でした。 エラーのパターン Name,Publisher,Version, hoge,age,8,,,, hoge,age,8.1,,,, hoge,age,8.2,,,, この場合、バージョンが8の行を消しても成功し、8.xの行を消しても成功する。 で、8を残した場合、8.1と8.2の合計数が表示されるのね。 こういう動きって当たり前なんだけど、バージョン列まで完全一致だと思い込んでいたので、気が付かなくて勝手に評価を下げていたの。 ごめんね。 あと、日本語を扱うにはunicodeってのも常識だね。

jQueryなんかでinputタグに文字列を入力したり取得するとき、 inputタグを特定するためにnameやid属性を利用するのですが、 SharePointではnameやid属性はソースでは「 ff1{$Pos} 」ってかんじの 短い値なのですが、実際に表示されると 「 ctl00$m$g_cafe866b_6e5b_416a_bf46_5bad614998d9$ff11$ctl00$ctl00$TextField 」 みたいな感じで長～い文字列になってしまって、あれれ～～って感じになります。 でも、該当の <SharePoint:FormField> タグを <div id="hoge"> で囲んで、 <div id="hoge"> 内の <input> を選択するようにすれば楽勝ですね。 jQueryでいえば $("#hoge input") で見事にinputタグを特定できます。 これを使えば、入力補助機能が簡単に作れたりしそうですね。 これに気が付くのにだいぶかかってしまいましたが・・・ 初めは長いid値に $ff11 って文字列があるので、これを部分一致で検索すれば～って着手したら、 ff1{$Pos} なら $ff11 だけど、 ff20{$Pos} の場合 $ff20_1 になったりと一桁と二桁だと動きが違う。 3ケタの場合は確認してないけど、この方法はだめだなってね。 たぶん <asp:> と <SharePoint:> のidとnameはシステム側で競合を防ぐ処理が動くんだろうね。

SharePointでちょっと見た目を改善したい！！ってことよくあると思うのですが、SharePoint Designerを使ったり、ソースを弄ったりするのはちょっとということもあると思います。 というのも、どちらの方法も直接ファイルを編集するってことで、元に戻せなかったらどうしよう～なんて心配があるからです。 でもね、スタイルシシートをちょっと変更するだけでも、やっぱりやらないといけないのかなぁ~って思ってしまいますが、TEXTファイルにJavaScriptを書いて「コンテンツエディタWEBパーツ」で読み込ませるだけで、スクリプトを埋め込むことが出来ます。 じゃぁ、あの場所のタグにstyleを追加しよう！！なんてソースを書くのは結構疲れるのですが、jQueryを使うととっても簡単。 IEの開発者ツールで変更したい場所を特定すればあとはメモ帳で数行書けば出来上がりです。 元に戻すのもコンテンツエディタWebパーツを削除するだけでOK。 jQueryってめちゃくちゃ便利なライブラリです。 アイディア次第ではユーザが喜んでくれるカスタマイズもできるかもしれませんね。 <script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.2.min.js"></script> <script type="text/javascript"> jQuery(function(){ jQuery('ul.dfwp-list li').css('float','left'); }); </script> これだけで<ul class="dfwp-list">内のすべての<li>にstyle="float:left;"を追加してくれます。このレベルだとCSSをかける人なら十分書けますね。

今作ってるフォームって・・・3月から作業を始めているから、そろそろ5か月くらい試行錯誤してるなぁ～ってね。本当は5月に完成してて、打ち合わせしたら追加要件があって、それによって 列の66問題 ってやつにぶつかって、7月中旬にやっと解決して、じゃぁ～って感じで、新規と編集フォームを現在作成中って感じです。やっと利用者にお披露目できそうな感じです。 そんな中で感じたのが、SharePoint Designerでフォームを編集する際は試行錯誤してもいいけど、手順を確立しておくってこと。 そして、次の機能追加するときは、その手順をもとに一から作り直すことが、トラブルを避ける最も確実な方法。 面倒だけど、そうやっておかないと、次の機能を追加したら今までの機能がおかしくなったりして、傷口がどんどん広がっていく可能があります。だから、不具合が出たら出る前まで戻って、どこを触ったらおかしくなったか原因を特定していくことが解決の早道。 品質を確保するなら、最終版までの手順を完成させて、一から手順に沿って淡々と作り上げるってのが一番だと思う。 一歩ずつ確実に進むことがポイントですよ。

ドキュメントに沿って作業したのにエラーになるんです！！ Microsoft Volume Licensing Service Senterの[ライセンス]-[製品の一覧]を開き、「すべてのライセンス情報をダウンロード」で保存したCSVファイルをExcelで開いてXMLスプレッドシート2003形式で共有フォルダーに保存したらSystem Center Configuration Managerの資産インテリジェンス　インポートウィザードを実行すれば入る予定。 だけどエラーになる。なぜ？って感じでいろいろ調べてみて思ったのが言語の問題？ってことで、ブラウザを英語設定に変えて見たらどうだろう？ ダメでした。 じゃぁ～って国外の情報に手を伸ばしてみると書いてありました。 XMLで保存したときに、「バージョン」列は内容によって型指定が文字列と数値にばらばらになるらしい。 で、さっき作ったXMLファイルを確認してみると、     <Cell><Data ss:Type="String">Office SharePoint Server</Data></Cell>     <Cell><Data ss:Type="Number">2010</Data></Cell> ってNumberになっています。これをStringに編集して再チャレンジすると成功。 ちなみに、MVLS以外のライセンス情報のインポートでも日本語だとダメみたい。データフィールド名を英語にしたらさくっと入ってしまいました。 日本語で表示されているソフトウェアでヘルプも日本語（機械翻訳だけど）だと、そのまま指示に従ってうまくいくと思ってしまうけど、多言語対応ってだけで、内部は英語なんだよな～ こういうところって結構ワナだよね～

久々の大阪上陸。 前職では大阪が本社だったので回数券を個人で買っても十分使い切れるくらい大阪に行ってましたが、今は大阪は1営業所があるだけ、正直なところ用事がない場所。 久々の新大阪や大阪駅はなんか、工事中が多くてごちゃごちゃしてました。おまけに帰省ラッシュなのか、人も多いし・・・ さてと、今日のセミナーはSharePoint2010の見た目の改善についてとドキュメントライブラリ活用についての2点。標準設定だけで出来る範囲での改善や活用だったのですが、いやぁ～コンサルティングをされている方の説明は説得力がありました。 悪く言えば機能説明なんだけど、ちゃんと設定する理由があるので感心することばかり。早速自社のサイトにも取り入れてみよう！！って思っちゃいました。 Webパーツとドキュメントライブラリだけだったけど、サイト構成や魅力アップのヒントがたくさんありました。 やっぱり、こういうセミナーって参加しないと得られないことって多いですよね。最近はインターネットで検索すれば大概のことは解決できてしまうかもしれませんが、ノウハウってのはお金をかけないと手に入らないってことも忘れちゃだめですね。（今回は無料でしたが・・・） 再来週もセミナーがあるんですけど、今から楽しみです。

Notesだったら簡単に実現できるのに～～～～SharePointだとどうすればいいの？ グループによってビューを切り替える グループによってフォームの一部を非表示にする ほんと、ノーツなら簡単に実現できるのに・・・ すべてをDesignerで実現するNotesとの違いってここなんだよな～ SharePoint Designerのフォーム編集でスクリプトを書くスキルがないだけなんだけどね。 書いてもいいの？どこに書くのがいい？ってJavaScript初心者レベルだな・・・ 記述するところが悪いとデザインビューで編集したらコードが消えたり、壊れたり・・・ この辺はノーツはしっかりしていて安心して作業ができるんだけどね フォームの表示に関してはasp:LoginViewをごにょごにょ ビューは・・・あれ？なかったっけ・・・

子供が夏休みに突入したので、私も・・・ってことにはなりませんね。 今日もしっかり働いていますよ～ って今日はSharePointのバージョンアップ作業があるので、朝から頑張っているのですが、 ハマりまくってますよ。 前回テストした時には、時間はかかるけど、特にエラーもなく成功していたので、今日もうまくいって、本番環境へのインポート作業は深夜バッチでって思ってたけど、うまくいきませんね。 とりあえず、バージョンアップするためには、作業用ーバへデータをコピーしてアップデートして本番へコピーする作業が必要なんだけど、作業用のサーバへデータが入りません。 なんか、エラーで止まってしまうんですよ。 何度か環境を増強しながら試したけど、結局メモリーを16GB割り当てて成功。 （仮想サーバでよかった～と実感した瞬間） じゃぁバージョンアップだ！！って始めたら、コンテンツデータの容量制限に引っ掛かり、ちょっと寄り道。 今度はディスク容量が足らないとか言い出した・・・もちろん仮想サーバなので容量を割り当ててパーティションの拡張でクリア。 でもエラーで作業が進みませんでした。 はぁ、結局10時まで頑張ったけど、こんな状態。 作業用サーバの環境をちょっと作り直して作業するかなぁ～（明日） なかなかうまくいかないねぇ～ ってか、データ増えすぎだよ！！

データフォームWebパーツを4つ使うことで260フィールドまで設置できました。 ただ、列の制限より少ない260列までしか1行テキストを作れないんですけど・・・ まぁ、上限が276列なのでたった16個。たいした問題じゃないですね。 いやいや、16個になく人がいたらいけないので言っときます。261個目が作れませんでした。不思議ですね～ 話を戻して66問題ですけど、状況から見てWebパーツに制限があるらしく、複数のWebパーツを使うことで1画面で260フィールド設置し、問題なく保存、編集ができました。 細かなカスタマイズは行っていないのでだめかもしれませんが、レイアウトをうまく調整すればこれで解決って感じです。 じゃぁ、Webパーツは何個まで？ってのはおそらく25個だと思う。 さて、今回は100項目程度のフォームを作成してぶつかった問題だけど、作業をしてみてやっぱりこの数になると、現実的にカスタマイズは保守段階で問題になるよなぁ～って思った。 項目名が変われば3フォームの修正が必要だし、同じ設計のリストが複数あればそれだけ修正に稼働がかかるってこと。今回はまさにそういう利用のされ方をするのでちょっとどうかなぁ～って感じです。かといってオリジナルのままだと縦に100項目ならぶので操作性に問題ある。セルの幅も同じなので見やすさの問題もあります。

SharePoint 2010で新規または編集フォームをSharePoint Designer 2010で作成した場合、列の制限や列の種類にかかわらず、タイトル　＋　66項目しか入力フィールドを設置できない問題のこと。 そんなに多くの項目をだれが使うんだよ～って思うのですが、列の制限では200以上用意できるし、標準のフォームだと問題なく列の制限まで入力フィールドが動く点が悩ましい。WEBフォームで200項目なんて縦に並べて誰が入力するんだよ～って思ったので、カスタマイズしてちょっとでも使いやすくしてあげようと思ったのに、66項目という制限によって、その熱い思いをぶち壊してくれる。 さて、これは仕様ですか？バグですか？ ちなみに、SharePoint Designer 2010のx86版、x64版関係なく、SharePoint FoundationでもStandardでも発生する問題。 ん～～～InfoPathって選択肢はライセンス的にないので、AccessかWebパーツなんだけど、どうしたものか・・・・ 次の一手が思いつきません。

System Center Comfiguration Manager 2007 R3をWindows Server 2008 R2で構築する際に気を付けることは、Internet Information Servicesの設定を確実に行っておくこと。 WebDAVの設定がおかしいと、正常にインストールが終わったように見えても、いくつかの設定ができない場合があるみたいです。（今回の教訓） BITSの設定でmdbを許可する例が書いてありますが、これが必要かどうかは未検証。 たぶん文書からは例と読めるので不要なのでは？と思ってますが・・・ 一応エンタープライズCAを構築しているので、ネイティブモードにチャレンジしたけど、証明書の認識がうまくいかず断念。とりあえず混在モードで構築するのが楽ですね。 今回はSCCMを構築するのが目的ではなく、ForeFront Endpoint Protection 2010の構築が目的なので、配布とレポートが動けばいいんです。 で、今回SCCMでハマった原因はWebDAVの設定。 一応ちゃんと設定したんだけど、どっかがおかしかったみたいで、SCCMのセットアップが終わってみるとWebDAV設定が真っ白になってたのに気が付かず、SCCMの設定を弄りまくってたのが解決を遅くしてしまった。まぁ、おかげでその辺の設定の理解度も向上しましたがね。 今は待っているのはクライアントエージェントのプッシュインストール。XPはグループポリシーの設定で問題なくできるようになったけど、Windows7が微妙な感じ。 一応ファイルとプリンタの共有とWMIは許可しているんだけど、OKな端末とNGな端末がある。 たぶん他にも許可しないといけないのかもしれない・・・ 来週は、この辺の調整だな～ ちなみに、共有フォルダを使ったインストールなんだけど、アクセス権がないよね。 これって、Windows 2008以降の仕様によるところだと思うんだけど、 ドキュメントに書かれていないですよね。 話は変わって、FEPの感想だけど、ウイルスバスターコーポレートエディションと比べると、使いずらいというか特化していない分弱いですね。 リアルタイムに制御ができないのでなんか心細いし、レポートもなんだかなか～って感じです。CoreCALに含まれるようになるので、ほぼ移行は確定だけど、管理

今週はSystem center configuration manager とForeFront Endpoint protection の構築で大ハマリ。やっとクライアントが管理下に入りました。Windows XPは問題ないけどWindows 7が入らない。これはセキュリティの設定でなんとかなると思う。 明日頑張ってクライアントテストに入りたいですね。 で、はまってた原因はWebDAVの設定がうまく反映されてなくてIISの設定が入ってなかったみたい。 はじめのフォルダ数と今じゃ大分違う。 Exchange Server の検証の時もそうだったけど、セットアップのスピードが早すぎたりすると設定漏れが発生するような気がします。ADやDBがからむ設定は時間をちょっと開けるのがコツかもしれませんね。

SharePoint Designer 2010で列が80個あるフォームのレイアウトを変更しているのだが、新規フォーム（NewForm1.aspx）を新しく作って素の状態でエラーが出る。 オリジナルの新いいフォーム NewForm.aspxだとエラーが出ない。 この Web パーツを表示できません。この問題のトラブルシューティングを行うには、Microsoft SharePoint Foundation と互換性のある Microsoft SharePoint Designer などの HTML エディターでこの Web ページを開いてください。問題が解決しない場合は、Web サーバーの管理者に問い合わせてください。 関連付け ID:353a2e2e-b169-4097-b92d-0e3ebf61d68f    入力フォームが多いから？と想定してNewForm1.aspxから<SharePoint:FormField を削除してみたら、61個以下ならエラーにならないことを確認した。 <SharePoint:FormFieldは列の種類によって自動的に表示をかえるので、その処理が原因かもしれないので、<asp:checkboxに書き換えてみたけど結果は変わらなかった。 入力フォームの内訳は 1行テキスト　29 選択肢　　　　9 数値　　　　　10 日付と時刻　2 はい/いいえ　10 ハイパーリンク　１ これ以上の入力フォームを作成するとエラーになる。 でも、この数は列の制限から見ればまだ余裕はある。 試しに、はい/いいえ　を上限である96個作成して新規フォームを作成するとエラー。 フォームを削っていくと、67個以上で同様のエラーになる。 この時の列の内訳は 1行テキスト　１　　（タイトル） はい/いいえ　96 とりあえず、状況から見てカスタム新規フォームは列の制限より少ない数でエラーになることが分かった。 今作ってるカスタムリストは81列必要だし、もう一つは項目が増えて100程度必要なんですけどね・・・

SharePointを利用するうえで列が多くなると制限を考慮する必要があるけど、種類と組み合わせによって上限が変化するのでちゃんと計算しないとダメなんだよね。 この制限を理解するため、簡単にチェック出来る計算表をExcelで作ってみた。 SharePoint2010列の制限-計算表.xlsx ポイントは３つ SQL Serverのテーブルにデータを配置する際に、一定数上になると複数行になって制限が6行（変更は可能） リスト内の列の合計サイズが8,000バイトで、組み込み列用に256バイトが予約されているので、実質7744バイト。 列の種類によってサイズ、折り返しが発生する数が異なる。( 詳しくはTechNet列の制限を参照 ) この3つのポイントを元に計算すれば、実際に利用できる列（フィールド）の数がわかるってことですね。 たとえば・・・ １行テキストは276個まで利用可能ですが、数値を5個追加すると1行テキストは274個までしか利用できません。これは行数の制限ではなくサイズの制限です。 数値は72個が上限で、日付と時刻を5個追加すると、数値の上限は64個になります。これは行数の制限です。 って書いてもピンとこないかもしれませんが、そういうことらしいです。 ただ、私も勉強不足なので、初期設定にあるタイトルや更新日や作成日、作成者などがどのようにカウントれているのかはよくわかってません。また、GUIDと管理されたメタデータについてもちょっと分からなかったので、存在を無視してます。 この辺は、いずれわかった時に補足したいと思います。 注意：この計算表を使って問題が発生しても責任はとれません。 また、修正・配布は自由にしてかまいません。 さらに、ブロックという単位は私が勝手に作ったり、間違った表現があるかもしれません。 もしかしたら、計算方法すら間違ってるかもしれません・・・検証はしてないので～

SharePointは100項目あるフォームの表示系はMultiViewでほぼ作りましたがレイアウト調整がまだできてません。手書きだと面倒ですね。一から手書きだと無駄な記述はしないけど、TDタグすべてにWidthを指定してくれているので、修正するのが面倒です。Designerに任せるとxsl:templateの構造を破壊してくれるので手動。 入力系はこれからって感じ。一つの項目がトリガーで殆どの項目が不要になるので、表示・非表示の制御をしたいけど、どうすればいいのかなぁ～って感じですね。 問題はこのフォームとセットの4GBファイルのアップロードについて、Visual Studioでワークフローでごにょごにょすればできると思うけど、Visual Studioでってところがさっぱりなので、こっちは進みそうな気がしません。 とりあえず、来月になれば時間が取れるはずなので、ごそごそやってみる予定。   リモートアシスタンスの接続サポートツールは、OS判別部とIP取得、招待ファイルのメール送信部はほぼ完成。あとは、招待ファイル作成時のパスワードを考えるのと、ファイルのチェック。メールの宛先選択の辺を考えれば完成。ついでにSharePoint上のリストに保存するようにしてなんか面白いことができないかなぁ～なんて思ってます。  

SharePoint Designerでフォームをカスタマイズしていた時に気が付いたけど、ビューで編集すると一発でコードが壊れる条件があった。 今やっているのは、チェックシートを記録するためのカスタムリストの表示フォームで、項目数が多いので、ASP.NETコントロールのMultiViewを利用して1画面の表示項目を制限しているんだけど、全体表示もほしいよなぁ～ってことで グループA グループB グループC グループA,B,C って感じに分割している。 この場合、<xsl:template>で分割して記述することで重複を防ぐことができる。 <asp:MultiView>   <asp:View>     <xsl:call-template name="A"/>   </asp:View>   <asp:View>     <xsl:call-template name="B"/>   </asp:View>   <asp:View>     <xsl:call-template name="C"/>   </asp:View>   <asp:View>     <xsl:call-template name="A"/>     <xsl:call-template name="B"/>     <xsl:call-template name="C"/>   </asp:View> </asp:MultiView> こんな感じで作ったフォームをビューで文字を編集したりすると一発でコードを書き換えてくれます。意図しない方向で・・・ このフォームを作っているときから、数回書き換えられてしまってやり直したんだけど、その時はマウスでなんかしちゃったかなぁ～なんて思ってたんだけど、そうじゃなかったんだね～ Designerとかってかなり複雑な処理をこなしているから糞ソフトが～～って思わないけど、ビューで編集したければコードを手書きするのは最低限にした方がいいっ

 昨日からSharePoint Foundationの開発環境を構築しており、やっと構築が完了したぞ～って感じです。ハードはPowerEdge R710上に用意した仮想インスタンスのWidnows7です。別にサーバでもよかったけど、ライセンス的にクライアントOSにしてます。（4インスタンスまでライセンスに含まれる。） 開発ツールはもちろんSharePoint DesignerとVisual Studio。 なぜかDomino Designerも入ってるけど・・・ SharePoint Designerは日ごろよく使っているので問題なし。 CPUリソースは2つしか割り当ててないけど超快適。 社内向けサーバよりリソースが割り当てられているいい環境です。 あの超モッサリだったデザインビューがかなりスムーズに入力できるようになりました。とはいっても、最近いじってるフォームはデザイン画面で編集するとぐフォームが壊れてしまうので、コード画面で手入力ですけどね。 問題はVisual Studio 2010。 家ではExpress版を使っているので、ソフト自体は情報量が増えただけで何とかなる。ただ、SharePoint関連の画面を開いた瞬間昔味わった絶望感を味わうことになった。 そう、初めてSharePoint Designer2007を触ったときのあの、「触ったらだめだ」って感じ・・・。 へたに触ると壊すこと間違いなしって感じですね。 まぁ、やりたいことはワークフローである機能を付けるだけなので問題ないけど、なんでもできそうな分よくわからない所が多いなぁ～って感じですね。 ん～～でも、これを使いこなせればいろいろやりたいことが実現できるよなぁ～って思いますよ。使いこなせればの話だけどね・・・

先週から90項目のフォームを準備してるんだけど、項目設定めんどくさい。 しかも、チェックリストなので、項目名が文章になっているので、標準フォームだと改行の嵐。 じゃぁ、別名用意してdesignerで項目名入力すれば～ってやってるんだけど、スクロールが長くて嫌な感じ。 たぶん、利用者もこの項目数を見ただけで、入力する気が失せてしまうような気がします。 まぁ、今は紙ベースでやっているので、インタフェースさえうまくすれば大丈夫だと思うけど・・・ でね、とりあえず縦長なのは見た目も悪いし入力しづらいと思うので、タブでページわけをしようと調べてみたけど、WEBだとタブコントロールってないんだね。そういうページはよくあるので標準で出来ると思ったけど、ASP.NETコントロールにないっす。当然HTMLコントロールやSharePointコントロールにはあるわけないので、代わりになるものないかなぁ～って探してみるとありました。 一つはMultiViewコントロール。そしてWizardコントロール。 Wizardコントロールは、インストールウィザードのように「次へ」と「戻る」およびメニューが自動生成？なので便利そうな感じ。じゃぁ試してみるか～ってフィールドを挿入したら、レンダリングのループ・・・ ただのテキストボックスとかだとまともに動くけど、フィールドはだめらしい・・・たぶんバグ？ MultiViewコントロールはView切り替えボタンを作ったりする必要があるので、すべて手動なわけですが、こっちは素直に動いています。Viewのボタンでカレントボタンを無効化するとこら辺を自動化したいと思ってるけど、今は手書きで動作確認中。 これで、一画面の入力項目数は減らすことはできたけど、見えない項目が増えるので、入力忘れとかの原因になりそうだなぁ～って思った。 項目数が多いと画面設計も大変だなぁ～

Lotus Notes/Dominoからシステム変更するにあたって、絶対に避けられないデータ移行作業を大幅に楽にしてくれるのがこのSharePoint Converterです。 うちの場合、ほとんどがディスカッション掲示板をベースにしたテンプレートで利用していたので、ディスカッションへのコンバートになります。ってことで、コンバートを試しているのですが、まぁ、無難にコンバートしてくれます。 見た目の違いはあるものの、ほとんどの内容は維持されていて問題なし。 意外といいかもしれない。 しかも、SharePointのディスカッションのほうが、コミュニケーションをするためのディスカッションに近いため、「あぁ、この使い方はディスカッションじゃなかったんだなぁ～」って気付きがあったりします。これを見せると、リストに変更したりする話が自然と出てきそうだなぁ～ でね、まぁ、その辺はいいんですよ。ユーザとの対話の話だしね。 ただ、NotesユーザとActiveDirectoryユーザの変換がね、どうしたものかと悩み中。 定義ファイルは淡々とXMLファイルを作成すればいいんですよ。 Notes漢字アドレス帳からCSV出力して、Excelで加工、XML化の準備して、テキストエディタで置換をやりまくって、XMLを作成すればいいので、面倒だけど、淡々とできる作業。 問題は退職者の扱い。ADを構築した後の退職者は両方のアカウントをもっているので、何とかなるけど、AD構築前の退職者をどうしようかなぁ～とね。標準だとシステムアカウントになってしまうけど、文書によっては結構重要なのがあって、その人が書いたことを記録に残すのも必要だよなぁ～って思う。かといって、Notesユーザ名を表示するのもかっこ悪いし、やっぱりADユーザとして表示させたい。そうなると退職者のアカウントを作らなければならない。でもそれもやりたくない。 では、どうすればいいのか？ やっぱり、これもユーザとの話し合いで決めるのかなぁ～

今日のNotes/DominoからSharePointへの移行打ち合わせは・・・失敗。 まぁ、私も移行について話すのは初めてだったので当然な結果ですが 1年以上WSSを利用し、SharePoint2010も利用している部署の方だったので安心していたというのも原因ですね。   今回の打ち合わせでは一回目ということもあり、サイト構成、権限設定について説明し、Notes掲示板の権限をもとにサイト構成案の提案を行いました。その後、単純にコンバートするのではなく、リストにするものライブラリにするものを考えながら掲示板移行しましょうという話。 サイト構成、権限についてはスムーズに進みましたが、掲示板移行については・・・ Notes掲示板をSharePointのディスカッションに移行しましょ！！って話からてんかいすればよかったと思うのですが、初めからいいものにしましょう！！って欲張ったのが失敗ですね。この場合はどれがいいの？ってやり取りが永遠に続くことに・・・ 今思えば、今日の相手はSharePointを利用しているといっても、カスタムリストだけで、ほかのテンプレートは使っていないんです。だから、各テンプレートに合った使い方って知らないんですよね。それなのに私は・・・   今日の反省をもとに考えたシナリオ サイト構成、権限設定についてはNotes掲示板をベースに話して問題ない。 　（なんだかんだ言ってもベースはNotesなので） Notes掲示板はコンバーターを使いディスカッションに移行する。 　（とりあえず、安心させる。） 移行したディスカッションから、リストやライブラリで管理するものを抽出する。 　（利便性を高めるため整理整頓しましょう） 作りこんだ掲示板は、作りこみましょう～ 　（さらに安心させる） 慣れてきたら、デザイン権限を渡すこともできますよ～って夢を与える。   今日の相手には申し訳ないけど、いい勉強になりました。 疲れた・・・

いよいよ、移行の時がやってきました。 といっても、自部署は2年近く使っているのですが・・・2010を待っていたり、その他もろもろの体制というか根回しに時間がかかってしまったのが原因なんですけどね。 改めて、ノーツからの移行が難しいなぁ～と痛感しております。（まだ始まってませんが・・・） 製品が違うので、同じことは出来ないことは誰でも知ってるけど、提供する側のこだわりとして、変化を少なく、より使いやすいものへ。ノーツ以上の評価をもらいたいと思ってしまうのです。 それが、ユーザへの負担となることもわかっているのですが・・・ 何が難しいかっていうと、一つの掲示板でSharePoint　1サイト分の機能を余裕で実現していることかな？権限設定も細かく設定できるし、ツリー構造の権限なんて考慮しなくてもいい自由度。ノーツの場合はそれが負担だったんだけど、これを移行しようとするとねぇ～。 掲示板をSharePointでどう表現するか？ 文書を目的、機能ごとに分割する いくつかのリストにするのか？サイトとしてまとめるか？ アクセス権限を再考する 応答文書があるものはディスカッション掲示板なのかカスタムリストなのか？ お知らせなのかカスタムリストなのか？ 一部署の掲示板が一つだったら、サイトという単位に展開して～ってとっても簡単だけど、複数掲示板がある場合、掲示板の数だけサイトを作ると使いにくいだろうし、今までと一緒の問題を抱えてしまう。かといって、一つのサイトに複数の目的を持ったリストが存在したときに分かり易さが維持できるのか？まとめる組み合わせ、サイトにする判断。権限・・・ 考えれば考えるほど、考えなければならないことが増えてしまいます。   意外と標準テンプレートのディスカッションが一番難しいのかもしれない・・

入力時にチェックボックスを利用したフォームの表示をチェックボックスのまま表示したい。Dominoだったら簡単なのにSharePointだとできない。 色々ゴソゴソやってみたのですが、選択数が一つの時はうまくいくけど、複数になるとチェックが入らない。「選択肢1;選択肢2」って項目が追加されてチェックが入る。 これってどうにかならないのかなぁ～と思っているのですが、スクリプトで記述するしかなさそうな感じ。一応<asp:ListItem Selected={contains(フィールド名,'項目名'}>で実現できるけど、Designerに強制修正されてしまう。Selectedの値はTrueかFalseで代入される値自体は問題ないけどダメらしい。 そういえば、こんな問題がアンケートにもあったよなぁ～と確認するとやっぱりありました。選択肢が3つあった場合、回答としては A,B,C,AB,AC,BC,ABCの7パターンあるけど、集計としてはA,B,Cそれぞれでカウントしてほしいのですが、AB,AC,BC,ABCもそれぞれ独立した回答としてカウントされるんですよね。A,B,Cそれぞれ3票にしてほしいけどそうならない。 Microsoftでも出来なかった。いや、理由があってしなかったんだと思う。そう考えると、今私がやろうとしていることはスクリプトなどで実現しないとダメなんだなと。

SharePoint 2010勉強中の問題として、Designerでゴソゴソしているサイトが複数のサブサイトに分散しており、そろそろ整理整頓しないといけないよなぁ～なんて感じております。 そこで、リストなどはテンプレートを作成して新しい作業サイトへお引越しを試みているのですが、結構制限があるんですね。 とりあえず動作はするけど、参照フィールドはオリジナルの参照先を見てるし変更できない。フォームをDesignerで編集しようとするとデータソースがオリジナル設定を引き継いでいて、修正するまでデザインビューがエラーで表示出来ないのは困ったものです。 テンプレートを配布している方々はいったいこの辺の問題をどう解決しているのか？知りたいですね。 また、なんでデータソースの設定が間違っているのに正常動作しているのだろうか？もしかして、データソースはDesigner用の設定？   ところで、Dominoではテンプレートを直接編集できるし、そのテンプレートを使って作成したアプリを自動更新とかできるのですが、SharePointにはその辺の機能がなさそうな感じ。トラブルの原因にもなるこの機能ですが、いざなくなるとさびしいですね。 今はカスタマイズリストの数も少ないので、テスト環境で作成して、編集部分を本番環境に書き写すというアナログな方法で対応していますが、今後増えてくると一括更新とか出来るような機能が欲しくなりそうです。

今週はトラブルとかなかったので、SharePoint Designer 2010べったりでした。 結果はHrsT個人の能力によるものですので、できる方はできると思います。 ビューのカスタマイズ データソースを利用した他リスト参照はできない。 データソースの追加設定ができない。 カスタマイズするとあとで困りそうな感じ。 スタイル変更は設定変更できるけど、したらダメ 新規・編集フォーム データソース設定を行うとデータの編集、保存がエラーになりできない。 チェックボックス、リスト、ラジオボタンなどは自作できなかった。 コントロールはあるので何とかなると思ったけど・・・ 表示フォーム 他のリストをフォーム内で一覧表示すること、集計結果を表示できる。 チェックボックス、ラジオボタンの状態で表示するのは難しい。 今のところListItemで非選択項目を含めた手動設定が必要 表現自体は自由度が高く、カスタマイズ難易度も低い リストテンプレート（ちょっと試しただけ） 参照はテンプレート作成元の絶対パスが埋め込まれる？ データソースは再設定が必要？ カスタマイズしたテンプレートを使いまわすのは注意が必要。 って感じです。 フォームの表示系についてはどうとでもなりそうな感じです。 でも、本当にやりたいのは入力系の利便性向上。 こっちはなかなか難しそうです。 やっぱり難易度的に言ってもDominoのほうが低いです・・・

SharePoint Foundationをインストールしようとすると、Serverじゃないとだめよ！って怒られますが、ちょっと設定ファイルを編集するだけで可能になるみたいです。 ということで、先輩方のウェブページの手順を参考にごそごそ・・・ まず、DVDをHDDにコピーして・・・ってexeなんですが・・・ 　どうもSharepointFoundation.exeを実行すると、C:\Program Files(x86)\MSECache\SharePoint2010ってフォルダが作成されて、セットアッププログラムを起動するみたいです。（64bit専用アプリなのにx86を選ぶのも意味不明ですが・・・） 次にコピーしたファイルの\Files\Setup\config.xmlに追記って・・・ 　あぁ、同じファイルがある。とりあえず追記 では・・・ って作業を始めたんですが・・・ 大変申し上げにくいのですが・・・ MSDNライブラリに書いてありました。(・_・;) 他の解説者がきれいに纏めていただいてたので本家を見なかったのが敗因でした。 基本的な部分で失敗してました。 そして、物理メモリーをちゃんと搭載していなかったので・・・ガリガリ言い出しました・・・ ん～～確認したいことだけ確認して消そう。

SharePoint Designer2010でカスタムリストのビューはカスタマイズしない方針で進めようと思っています。 ってのも、ビューをカスタマイズしようとするとわかると思うのですが、いくつかのテーマ用の設定が記述されており、引き継いだ人が苦労するのかなぁ～と思ったからです。 たぶん、ビューのカスタマイズ要望は非常に多いと思うのですが、ビューだけはやらない方がいいんじゃないかなぁ～と本能的に感じました。 まぁ、まだ理解度が低いという点もあるのだと思いますが、メニューで設定できる範囲やフィルターの設定程度に抑えておいた方が良いと思います。 いじる場合は、しっかりと仕様書を記録しておかないと、バージョンアップや再編集時に苦労しそうな予感。 最低限の記述しかないビューを作成できれば話は別だと思いますけどね～

SharePoint Designer 2010と格闘し始めてだいぶ経ちましたが、今日はちょっと進展がありました。リストビューでほかのカスタムリストの集計がうまくいかず断念していたのですが、フォームで別のカスタムリストの表示ができることを確認しました。 これができると、表現の幅が広がります。 私がやっているカスタマイズはDesignerを利用しているので、WYSIWYGでいろいろできるのですが、ほとんどソースをいじっています。 XPathはさすがに編集ツールを使っていますけど・・・。 で、最近感じていることはXMLの理解を深めるとカスタマイズの幅が広がるということ。 SharePoint Designerを極めるにはXMLは必須ですね。 あと、SharePointのタグやコマンド群なんだけど、こっちはリファレンスの読み方がいまいちわからないので、まだまだって感じですね。これが使えるようになればさらに自由度が高くなりそうです。 とりあえず、表示フォームについてはあともう少しで何とかなりそうな感じ。 問題は新規フォームと編集フォーム。そしてビューだ。 合わせてカスタムリストでディスカッションを作れるようにならないといけないなぁ～ これらができれば、Dominoの掲示板の過半数を同等機能を維持しつつ移行することが技術的に可能になります。 実際には、棚卸を合わせて行うので、そんなにカスタマイズをするつもりはないけどね

SharePointの勉強をしていて思ったこと。 開発環境に要求するスペックはSharePointが格段に高い。 DominoのXPagesは使ったことないのでわかりませんが、LotusScriptなどを使ったアプリ開発は多少低スペックでもストレスなくできましたが、SharePointDesignerだと快適に作業しようとすると今どきのパソコンが必要ですね。VisualStudioでの開発だとSharePointサーバを同居させないといけないのでより要求が高くなってしまいます。 職場のメインPCはLet'sNote CF-W5なのですが、SharePointDesignerがモッサリでつらいです。ちょっと触ったら、画面更新でちょっと待って・・・って感じです。 私の中での評価はまだまだDominoの勝ちですね。  

最近、SharePointDesignerでいろいろ試しています。 とはいっても、まだ表示用のフォームを触ってるだけですが・・・ 将来のDominoアプリ移行の際に向けた準備ですが、Domonoで簡単に表現できてたことがうまく実現できません。 製品が違うので仕方がない部分は理解していますが、今までチェックボックスで表現していたものを実現できないというのも、利用者にとっては大きな問題じゃないかなぁ～って思います。もちろん、チェックボックス表現より視認性に優れた良い案があればいいのですが、そういうのも特にないし・・・（表現できないのは技術的ではなくスキル的にです） どうやったら同じ表現ができるのかなぁ～って日々頭を抱えています。 ある程度、表現できたら、それをSharePointらしいレイアウトに修正して、違和感を感じないようにしたいと思っています。 ただ、Dominoと違ってバージョンアップに対する不安感は非常に大きく、どこまで許されるのか？というのは分からないですね。Dominoならほぼ100%動作するのですが、そういう実績もないSharePointはどのくらい互換性があるのか？維持できるのかってまだ、わからない所が多いです。 そして、何よりドキュメントが全く・・・。DesignerでSharePointコントロールを設置しても、設定方法がわかりません。 いったい、どこに説明が書かれているのでしょうか？

ふと、マイスペースのアカウントを作ってみました。 特にこれといった理由はない。目的もない。 ただ、Windows live に連携サービスがあったので試してみただけ。 だから、何をすべきかサッパリわかりませんでした。当然だけどね~　とりあえず、連携サービスの設定を行っているだけ。 これから何をすべきか、どうすれば楽しめるのか？