SharePoint開発者のプロフィール

Question

私はASP.NETに特化した開発チームを持っています。したがって、私たちが提供するソリューションはWebベースで、IIS上で動作し、MS SQLサーバーを使用しています。会社のイントラネット内のすべて。チームにはこの専門知識があり、一般的にはC＃と.Netに優れています。

この会社は、SharePoint MOSS 2007を展開しています。この展開は、私が関与していないプロジェクトの一部であり、情報はほとんどありません。しかし、私は彼らが「思考者」層（何をすべきかを言う者）、統合層（誰が生産を構成、展開、管理するか）、いわゆる開発層を確立する必要があることを知っています他の2つのことをする人はできません）。

私は、SharePoint開発を追加してチームの専門知識を向上させる可能性を評価するように求められます。これは簡単な部分です、私は必要な訓練を見つけて、私の人々を送るだけです。

しかし、最近では、言葉の開発は多くのことを意味する可能性があり、開発の代わりに構成が使用されることがあります。 新しい専門知識を開発してチームを進化させることに異論はありませんが、私は開発者にとって常に刺激を与えたいと思います。 第2に、私たちはSharePoint開発の専門知識を持っているとは言いません。実際には、CSSやXMLファイルを変更するだけです。また、ウィザードを使用してソリューションを作成することは、C＃開発者を追い求める最良の方法ではないと思います。

私が最初に尋ねる質問は、SharePoint開発者の背景は何ですか？ .Net開発者はSharePoint開発者になるように求められたらどのように感じることができますか？

ご意見をいただければ幸いです。

Answer 1

私は自分の会社でWSS 3.0ソリューションを継承した1年前にSharePoint開発を開始しました。

個人的には、私はSharepoint開発を少し知っていて、WSSチームがどのように解決したのかよく分かっていた多くの問題（セキュリティ、負荷バランス、ゴースト）があります。私が取り組んでいる他のソリューションの問題を解決するのに役立ちます。しかし、私はWSSソリューションではフルタイムで働かないので、毎日WSSでどのように働いているのかを理解する必要があります。

WSSとSharepointはASP.NETプラットフォームの拡張機能です。したがって、ASP.NETと.NETの経験は、Sharepointソリューションの作成を開始する開発者のための良い基礎となるはずです。私はWSSプロジェクトの作業を始める前に、基本的な概念とwssのソリューションアーキテクチャーを得るためにInside Microsoft Windows Sharepoint Services 3.0本を読んでいます。

Sharepoint開発用の仮想マシン環境が必要であることがすぐに分かりました。これは、クライアント上で動作し、サーバーのリモートプロセスに接続してデバッグモードになるのが苦痛だからです。したがって、ソース管理システムにアクセスできるVisual StudioがインストールされたMOSS仮想マシンを作成することをお勧めします。そのマシン上でソリューションを開発し、終了したらソース管理をチェックします。

stsdevやwspbuilderなどの開発ツールを参照してソリューションを構築することをお勧めします。これにより開発プロセスがかなり簡単になります。ウェブ上にはかなり多くのツールが用意されています。あなたを助けるためにcodeplex。

場合によっては、これらのソリューションを開発する際に苦労することがあります。IISプールまたはブルートフォースIISResetのリサイクルが必要になることがあります。しかし、あなたはすぐにキャッチしてどこを見るかを知っています。 Sharepointはまた多くのことを助けます。私はクライアントから何百万もの質問を受けています。これは、標準のアウトオブボックスのWebパーツで解決できるので、クライアントを幸せにするために何かをコードする必要はありません:)

Sharepointはまた、ソリューションが特定の方法でコード化されることを期待しています。 12ハイブファイル構造を使用すると、ソリューションの標準化に役立ちます。あなたがうまくいけば、これは2010年

初期学習と良くなり、ちょうど枠組みの中で何が起こっているかを知るために、反射板と、このようなツールがたくさんに依存する必要がなるように

ドキュメントの深刻な不足が、ありますカーブは高く、新しいコンセプトの多くは学ぶテクノロジーです。共有ポイント、フィーチャ、ゴーストコード、コードアクセスセキュリティ内のワークフロー 共有ポイントは、開発者が習得しなければならない多くのXML設定があります。これには、サイト定義、リストテンプレートなどが含まれます。私はXml編集モードに陥っていて、なぜ機能しないのか分からないことがあります。

これは私の考えのほんのわずかですが、私は主にWSS開発に取り組んできました誰かがSharepointのWebパーツ構成に関してコメントできるならば素晴らしいだろう。検索を構成します。私はずっとやっていないことです。

Answer 2

私が聞いたことから、SharePointは顧客の視点からは一般的なテクノロジですが、開発者の間では憎悪の対象です。

Answer 3

DevとAdminが「間違って」使用されていることにお気づきになりました。

SharePoint用の開発はまったくそのようなものかもしれませんが、webpartsの作成などの開発は、皆さんとチームがSharePointの展開、インストール、および設定を手助けすることを強くお勧めします。私は完全にSharePoint Certified（WSS Config/DevとMOSS Config/Dev）です。両方の知識があれば、私にとって非常に貴重です。

どこに設定されているかを知ることで、デバッグやトラブルシューティングに役立ちます。私はあなたのチームの少なくとも1か2のためのMCTS WSS 3.0構成の訓練および/またはMOSSの設定の訓練を取ることを提案する。残りのチームは、2人の認定された同僚がconfigとadminに関する人に行くようにして、必要に応じて本質を拾います。

IMHOは、デベロッパーとしての機能をどのように作成し、その機能を管理者（または少なくとも知っているエンドユーザー/パワーユーザー）として展開、構成、および維持できるかを知っています。 。

Answer 4

私の同僚は現在SharePointを勉強しています。いつも彼を楽しませる。頻繁に彼は "wtf is that ?? !!"のような何かを吐く。そして、私はちょっと悲しいと感じています。私も知っているから、そのことも学ばなければならない可能性があります（私は今日はプロジェクトを手に入れるのが簡単ではないと思います）。

私はソフトウェア開発（3日続けて指チェックボックスを狩るようなもの）よりも設定とカスタマイズの方が多いと思う。それらのクレイジーシェイプデザイナーを介して粘土を拾い、それを無限にカスタマイズします。

既に知っているすべてのもの - 新しい名前（つまり、 - spGridView）とその下に予期しない動作があります。

レンダリングされるHTMLは、bizzare（テーブルとシリアライズされたviewstateの束）です。

しかし、これらの設定xml`s ...o_0
これは私が乗り越えることができないハードルです。ハードコアなSQLのものでさえ、幼稚なゲームのように見える。

多分私は間違っていますが、私は聞いたことがあります - マイクロソフトでは、主にSharepointのためにSQLの '空間的な列'（あなたは何千ものもの以上のテーブルの列数を拡張しましょう）を開発しました。それは私を恐れさせる。

もちろん、私の意見はHIGHLYで、主観的で少し不快です。しかし、私はそれがよりよく私は& Sharepointについて考えると思うものを明らかにするのに役立つことを願っています。

あなたが作業している開発者が、これとは異なることを望むことを望みます。要するに

---

：私は好きではないだろう
号は、SharePointの開発者になるために。

---

編集：
私はその初期の複雑さを扱うことができます。しかし、私が望んでいない主な理由 - 私はSharepointでの開発が正しい方法だとは思わない。つまり、最近は、Webフォームがあまりにも抽象度が高いと議論しています。その後、Sharepointについて何を言いたいのですか？

Answer 5

アルバート、この別のスレッドIs a sharepoint developer technically “equipped” to do custom app dev and vise-versaを見てください。純粋な.NETからSharePointへの飛躍に関わることについて、そこにはかなりの情報があります。

Answer 6

すべての回答をいただきありがとうございます。それらは本当に役に立ちます。

私がここで読んだことから、私は考慮すべき2つのことを見ます。

まず、私が重要な要素だと思う利用の文脈です。いくつかの場所では、SharePointの "開発"は非常に遠くになり、新しい顧客のニーズを満たすために、本当にエキサイティングなものを開発する必要があります。それはコードを書くことなどを含むことができます。そして、すでに確立されているソリューションを維持するためには、他の場所では単に管理と設定だけが可能です。

第二に、個人的な動機です。それは本当に人に依存します。良い経験を持つ.Net開発者の中には、 "SharePointの方法"をコーディングしない方向に進むことを好まず、C＃やその他の言語でコードを書くことを好むだろう。しかし、この道を選ぶ他の人たちがいるだろうし、そのようなキャリアを持つことに満足しています。彼らは動機づけられ、本当に素晴らしい解決策を提案します。

たとえば、個人的な観点からは、私が開発とプログラミングに留まっていたとしても、私のキャリアの進歩の道筋として、高度なウィザードとメニューを使用してSharePoint開発を選択しませんでした。最近私はそれをやっていませんが、私はまだコーディング、コンパイル、デバッグなどを楽しんでいますが、これは私だけです。

Answer 7

成功したSharePointデベロッパーになるためには、痛みと仏の忍耐のための高いしきい値が必要です。