のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,645,127人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレMicrosoft Silverlight その8

silverlight覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

101 = :

>>96

> 俺は未だにAjaxプログラミング(Javascript)に慣れない
多いと思う、そういう方

俺はWinフォーム・ASP.NET・SLをやってるんだけど
WinしかできないエンジニアさんでWeb系に手を出したいと
思っている人ってたくさんいるよね

個人的な経験則からそんな人には
Winフォーム→ASP.NET
よりも
Winフォーム→SL
の方が断然入りやすいと思う

javascriptやhtml特有のお作法が壁になってWebに進出
できない優秀なエンジニアが沢山いると思う
それってそのままSLの隠れたキャパだとさえ感じるんだが

102 = :

特に、日本の場合は、技術嫌いのITドカタが多いからな
いちいちWPF(SL)を覚えようとする奴はいないだろうね
技術よりもその場しのぎの儲けなのが日本のIT
未だにMFC組んでるところもあるくらいだしw

103 = :

ハイパフォーマンスな描画が重要なWindowsアプリなんてほとんどがDirectX&C++なわけで
そういうのを取り込むつもりならXNAみたいなAPIは必須でしょ
C++開発者からすればC#はそんなに抵抗ないだろうし

104 = :

>>98
意外にそうでもないように思ってるんだけど、TPOによりけりなのかな?

基本、お客さんってブラウザで何から何まで済ませたいんだよね
それは配布コストの削減というお金的な観点と
インストール不要というユーザー視線の両方でね

一般的なユーザーってインストール作業やバージョンアップ時の
作業さえ面倒に感じている人がすごく多い
というかそれが当たり前かな

片やPCやインターネットが世の中や社会に普及して
UIに優れたアプリはいわゆるクライアントアプリであるという
認識を受け入れるところまではきてるように思う

そのITリテラシーの向上が「業務系アプリはWinフォーム」という
固定観念や諦めを作り出してると思うんだよ

「いやいや、実はWebでもできちゃいますよ
Winフォームと同じくらいUIに優れてるのが
それがSLなんすよ!」

って言えたらお客さん間違いなく食いつくと思うのだが

105 = :

>>103
ハイパフォーマンスな"描画"が求められるWinアプリってどんなの?
経験不足ゆえちょっと想像できないんだけど、シェアとしてはすごく狭いんでない?

106 = :

Silverlightって別にいいんだけどさ
何か制限が強すぎて結局phpやperlなんかで作るかーってなる
そもそもクロスサイト制限きつすぎでスクレイピングが出来ない
エンコード系が面倒と結局はなんかものたりないのよね
AIRもその辺は同じだけどさ
業務系でUIだけSilverlightに持たせましょうってなっても得られるのはわけわからんアニメーションぐらい
それなら別開発にせずに最初から鯖サイドで完結した方がいのよね

108 = :

> 得られるのはわけわからんアニメーションぐらい
これが大方のエンジニアのイメージだと思う

> 最初から鯖サイドで完結した方がいのよね
そしてこれがやっぱり大方のエンジニアの判断だと思う


マーケティングに問題があるとしか思えない
slの基盤となってるテクノロジーやアーキテクチャや思想など
大局的な方向性はいいと思う

あとは既存ユーザーやエンジニアへのアピールの仕方次第では
どのようにでも転がると思うのだが

109 = :

ファミコンが普及したのはスーパーマリオというアプリがあったからであって。
SLの技術が素晴らしいのはわかった。あとは、それを活かすコンテンツの登場だな。
OOBでも規制が強いという意見がチラホラ出てるから、セキュリティの絡みがあるのは承知の上だが
もっと緩くしないとな。
それはWPFでも言えることだろう。
WPFの有名アプリあったか?EvernoteがWPFで作ってたみたいだけど止めてC++で組み直したみたいだし。

110 = :

>>108
たとえばどういうアピールが他にあるの?
俺は言語に関しては有名所は何でも使えるしフレームワークも数十種使える
Silverlight、WPFやPrismを経験した上で聞くけど業務系においてSilverlightを組み込む必要性が今ひとつわからない
強みがない
制限が強い
他の言語やフレームワークでもっと簡単にできる
それなら普通に他の方法を俺はとるよ

>>109
winアプリはWPFで俺は作ってるな
少なくともWinFormsよりもコードの分断がしやすいし出来る事が多いから
ちなみに流行ってるとか流行ってないかは俺には関係無く、
目的を達成しやすいか楽できるか、そして楽しいかで選んでるw

111 = :

SLはクライアント技術であってサーバー側はこれまでどおりASPとか使うから
それらにとって替わるものではないと思うぞ。

112 = :

特に用途を限定してるわけではなくて、クライアントやホームユースのアプリケーションで
必要そうな機能だけ集めた小さいプラットフォームって感じなんだろ
.NETが誕生してからもう10年近く経ってるんだからそりゃ今わざわざ作り直すなら3Dくらい入るだろうさ

113 = :

Silverlightは、ドットネットとジャバの統合したようなもんだろ?
ジャバは遅い、メモリ食うので、Silverlightが主流になるといい

114 = :

SilverlightはWPFと同じライブラリをつかわせてくれませんかね
両方触ってるとその違いにイライラ来る…

115 = :

WPFで2チャンブラウザが誕生すれば大普及間違いない。
でも意外と2チャンブラウザって作るの大変みたいよ。
事実、Winform版の有名な2チャンブラウザって無いし。
未だにMFCレベル(Delphiだが)のJaneが使われてるし。

116 = :

>>114
Silverlight5で完全に旅立ちました
もうWPFのサブセットではないw

117 = :

>>110
今は>>99のようなアニメーションだとか描画のところばかりの
アピールが目立っているように感じる
まぁそれらが「見た目」のものだから目立つのは仕方ないけど

SLに限らずだけど新規エンジニアを獲得するよりも
旧技術や類似技術から既存エンジニアを取り込む方が
コスパは優れてると思うんだ

そうなるとSLがターゲットとすべきエンジニアは当然ながら
.netのエンジニアだと思うのだけど、.netのエンジニアで
描画やアニメーションやってる人って全体からみると一握り
だよね
それやるなら、それこそ他に良い手段が用意されてるだろうから

大抵の.netエンジニアってコントロールぺたぺた張って、
イベント処理記述してるようなPGが多いと思うんだ

そういった.net開発者をSLに取り込むにはやっぱり
・Winの経験をそのまま活かしてWebを作れる
・WebでもWin並みのコントロールが使える
といったアピールが必要でしょ

ようはWin・Web両方のエンジニアがそれぞれ抱え続けてきた限界を
SLで両方とも取っ払えるというところをアピールできればいいんじゃ
ないかな?
あくまで例えだけどね

118 = :

俺もWPFで組んでいるけど、WPF覚えるまでは大変だったし、
それまではバインディングに関する知識もなかったからWPFという山を超えるのはキツかった。
でもその山を超えたあとはWPFの素敵さがわかり、今ではWinFormには戻れない。
データ・コマンドバインディングなんてほとんど資料や本がないけど、本1冊にまとまるくらいの内容なのではないかと。(MVVMの思想も理解せんとあかんし)

119 = :

>>115
素朴な疑問
何が難しいんだろ?
2chのデータ取得するAPIとかは公開されてるんだよね?

120 = :

>>117
んーそのWinの経験を生かしてと言う部分はどうなんだろう
XAMLを取得しないと行けないしポトペタPGにはその辺がつらいんじゃなかろうか

121 = :

>>119
やることが多いだけ
既存のが高機能過ぎてユーザーの要求が高い

122 = :

>>119
技術面での難しさじゃなくて、結局作るのは個人レベルなんで、
実装に時間がかかる。
簡単なら、Jane以外のアプリが生まれてもいいだろ?実際Jane以外に何にも無いし。

123 = :

Java製のswingで作られた物があるじゃない
アレは結構高機能だよ
WPF製の2ちゃんねるブラウザはVIPで前に見たな

124 = :

>>120
いやいやそりゃ当然だと思う
何も新しいノウハウなしに新しい舞台に立てるわけではないでしょ
それは全ての事に言えるだろうけど

ただSLで食えるようになるためのコスト(金・時間)を.Netエンジニアはかなり低く抑える事ができるってところが重要なのでは
まったくMSのテクノロジーに噛んでないエンジニアが100かかって到達できるところに、.Netエンジニアなら30くらいで到達できると思う

125 = :

>>121,122
そゆことね
技術的に限界があるってわけではないのね

2chAPIの仕様が分かれば作ってもいーなー・・・なんてw

127 = :

あえてSilverlightにする必要性が今ひとつわからん
COM叩けますとか言われてもクライアント環境を知らないと始まらないわけだし
それならWPFでいいじゃんとならね?

128 = :

2ちゃんねるブラウザ MagicPot
http://ufcpp.net/MagicPot/index.html
でした

130 = :

なにぶん2ch用ソフトだからなー
ユーザーのレスポンスは口汚い言葉での要求と叩きがデフォだし、タダでそれに応じ続けなきゃならない
海外みたいに寄付歓迎にしたらサイト閉鎖するまで嫌儲共に叩き続けられるだろうし
そういうのに耐えられるマゾヒスト性と技術力を兼ね備えた人間は少ないだろ

131 = :

>>127
MSのWPFとSilverlightへの力の入れ具合を見ろよ
どう見てもSilverlightに本気だしてるだろ
そのうちWPFは何らかの形で統合されてSilverlight一本になるんじゃねーの?

132 = :

>>125
APIなんてないよ
最近のwebAPIという意味ではread.cgiだよ

それ以外はhttpを直接使う
これが曲者なんだよね・・・
ヘッダーいじれないし

133 = :

MSはどっちかっつーとhtmlに力を入れてるような…
IE10は凄いじゃん
何とかSVG少女とかパネェと思った(作ったのはカヤックだしクロームでも動くけどw)
しかしあれってSilverlightで作ると工数は減るのかな?

134 = :

slから入った人からするとwpfの存在が混乱を招いているからな
この混乱もsl普及の妨げになってると思う

135 = :

>>131
マイクロソフトはVisualStudio(WPF)とHTML(jquery)

136 = :

>>128
UIまわりよりも、2chアクセス、特に認証回りが面倒でやる気なくなっててそれっきり。

137 = :

俺がWPFで作ってるよJaneの時代を終わらせてやる

138 = :

UIも革新的なので頼むわ。JaneみたいなUIには飽きた。

139 = :

なぁ、silverlightでツリー内の特定のTreeViewItemにアンダーラインを入れるにはどーしたらいいんだよ・・・
まだここらへんのコツがつかめんのよ
対象のTreeViewItemオブジェクトにTextDecorations.Underlineを設定できればいいんだろうけど
その方法が分からんよ

140 = :

テンプレート使うんだよ
http://msdn.microsoft.com/ja-jp/library/dd759035(v=vs.95).aspx

141 = :

補足
表示したいテキストとUnderlineプロパティを持った型を自分で作って、
テンプレートで定義したコントロールのプロパティにバインドするわけ
SilverlightやWPFではTreeViewItemのようなものは基本的に触らないの

142 = :

>>133
Silverlightとhtml比べたら誰もhtmlで開発したくないだろう。

143 = :

失礼だけど、>>139みたいな質問はおかしい
WPFは要素内で多種多様な表現できるのだから、アンダーラインごときに躓く場合は、基礎から勉強したほうがいいのでは。

144 = :

>>143
おまえかっこいいな

145 = :

すいません。Silverlight で、描画更新タイミングってどうなっているんでしょう?
以下の、Message2 プロパティと TextBlock が Bind されていて、
Message2 = "hogehoge" とすると、正しく TextBlock に値が表示されます。
しかし以下のようにすると、ボタンを押してから 1秒たって "99" がいきなり表示されます。
WinForm の時であれば this.button2.Update() 等として描画させていましたが、
Silverlight ではどうすれば良いのでしょうか?

private void button2_Click(object sender, RoutedEventArgs e)
{
for (int i = 0; i < 100; i++)
{
this.Message2 = i.ToString();
System.Threading.Thread.Sleep(10);
}
}

146 = :

WindowsForm以上にUIスレッドは止めるなというのがSLでのセオリー。
Sleepが必要だったり、時間のかかる処理は別スレッドで処理して、
UIへのフィードバックには
Dispatcher.BeginInvokeやBackgroundWorkerを使う必要がある。

147 = :

>>146
お返事ありがとうございます。
さっそく非同期イベントと Dispatcher を使用して、以下のようにしてみました。
"pre Loading..." と表示された後、"Loading.." が表示されるのを期待したのですが、
"pre Loading..." が表示されず "Loading..." がいきなり表示され、"pre~" の描画が
キャンセルされてしまっているかのようです。
こういう動作はいけないのでしょうか?

this.Dispatcher.BeginInvoke(() =>
{
this.Message = "pre Loading...";
System.Threading.Thread.Sleep(1000); // 重い処理の変わり
this.Message = "Loading...";
});

148 = :

>>147
今だと、↓みたいになる。
ディスパッチャー → 再度別スレッドに移ってからSleep →ディスパッチャー。
Dispatcher.BeginInvoke(() =>
{
this.Message = "pre Loading...";
Task.Factory.StartNew(() =>
{
Thread.Sleep(1000);
Dispathcer.BeginInvoke() =>
{
this.Message("Loading...");
}
}
}

149 = :

Async CTP入れると簡単にできるんだけどもねぇ。
↓これだけ。
this.Massage = "pre Loading...";
await TaskEx.Delay(1000);
this.Massage = "Loading...";

150 = :

今までJavaとPHPでの開発しかしたことがないんだけど、Silverlightを勉強する場合って
事前に勉強して置いた方が良い事ってありますか?


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / silverlight一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド


トップメニューへ / →のくす牧場書庫について