はじめに 「Typescriptの次はRustかもしれない」という記事がバズってるのを見かけました。 なかなか面白くて、PAとしてのWASMとRustを比較している記事です。ちょうど最近「レガシーおじさん、SPAを始めてみた。そして限界を知る」でも書いた通り最近SPAに手を出してみたのですが、いろいろやろうとするとSSRのためのBackend for Frontend (BFF)等が必要になるとわかり「これJSでやる必要なくない?」とも感じていたのでちょうど良かったです。 こういうのを見るとRIAやGWTのように似たアプローチで廃れた技術や、登場が早すぎたMeteor、今も頑張ってるMSのBlazorなど色々頭をよぎります。といわけで歴史を俯瞰する意味でHTML + JavaScriptとそれ以外の技術のせめぎ合いの歴史やMSのBlazorやRustのyewなどWebassemblyを使う
Build Modern .NET Web Apps in C# and XAML, effortlessly Windows, Android, Mac, Google Chrome, Firefox, Safari… – Build Once, Run Everywhere Discover the future of .NET web apps with OpenSilver. Our latest 3.1 release offers an AI-enhanced drag-and-drop UI designer, unmatched compatibility with Microsoft Silverlight, and extensive WPF support. Code in C#, VB, or F#, and leverage enterprise-grade c
JavaなどのNPAPIプラグインは2016年末までに、Firefoxの全バージョンで機能しなくなる。ただしFlash Playerだけは例外とした。 Webブラウザ「Firefox」からのプラグイン締め出しを進めているMozillaは、Web初期のAPIである「Netscape Plug-in API」(NPAPI)を使ったプラグインについて、2016年末までにサポートを打ち切ると表明した。 NPAPIプラグインはWebサイトでストリーミングビデオやゲームなどの機能を提供するために使われてきたが、ブラウザをクラッシュさせたりセキュリティなどの問題を引き起こすこともあった。こうした機能の多くはWebベースの技術で代替できるようになり、Googleの「Chrome」やMicrosoftの「Edge」などのブラウザは、既にNPAPIプラグインのサポートを打ち切っている。 Firefoxでも廃止
Chromium 開発チームは過去に NPAPI プラグインを廃止すると宣言しており、2015/4/14 にリリースされた Chrome 42 Stable ではデフォルトで無効になりました。 2015/9 頃にリリースされる予定の Chrome 45 で完全に利用不能になる予定です。 Unity Web Player や Silverlight を利用しているサイトの開発担当者は気張ってください。 また、 PPAPI ではなく NPAPI の Flash Player を自分でインストールした(そして忘れている)ユーザが「サービスが利用できない」とお問い合わせメールを投げてくる事もあるかもしれません。 NPAPI の Flash Player をアンインストールしてもらうなど頑張って誘導しましょう。ちょっと面倒ですね。 Chromium の中の人達は、NPAPI の無効化を4〜5年前から
Mac で Chrome Canary (Ver 39, 64bit版) を使っているんですが、Silverlight を入れても入れても Silverlightが利用できません と表示されるので、 (ε・◇・)з o O ( ?? はて ?? になってました。 Chrome Stable (Ver 37, 32bit 版)だと動きます。 こういうことかな? んー、恐らく…こんな理由かなと ちょっと前まで Chrome は 32bit 版しかなかった 64bit 版の開発が進み、Chrome Canary などから順次 32bit → 64bit に移行中 Chrome 64bit 版では、32bit 版の NPAPIプラグインは動作しない Chrome は 2013/09に、2014/01 から NPAPIプラグインはサポートしないと表明(Unity Playerなど一部例外あり) NP
[これは米国 Mozilla のブログに掲載された DRM and the Challenge of Serving Users の抄訳です。] Mozilla は現在、完璧な解決策が存在しえない困難な状況の中にあります。ユーザから求められる機能と、ユーザによるコントロールとプライバシー実現のため構築する機能のいずれかの間で選択を迫られています。この状況について以下に説明します。 人々は映画やテレビ番組を含むビデオの視聴を望んでいます。ブラウザがビデオ視聴機能を提供しなければ、そのブラウザはユーザが必要としないものになってしまいます。しかしコンテンツ所有者 (特に映画やテレビスタジオ) の多くは人々がそのコンテンツを使用する、特にコピーを作成する手段を制約するための仕組みを求めています。このような仕組みは一般に DRM (デジタル著作権管理) と呼ばれます。ブラウザにはコンテンツ所有者が満
PCでもスマホでもタブレットでも動く――Windowsの秘策「ユニバーサルアプリ」とは?:鈴木淳也の「まとめて覚える! Windows 8.1 Update」(1/3 ページ) タブレットとスマートフォンの“Windows”は異なるが…… これまでMicrosoftのPC/タブレット向けOS「Windows 8/8.1」と、スマートフォン向けOS「Windows Phone」はプラットフォームが分離しており、開発者はそれぞれのターゲットに合わせて別々の形でアプリを開発する必要があった。さまざまなデバイスに同じアプリを提供したい場合、これが開発の負担になる。 同時に、同じ“Windows”の名称を冠しながら異なるプラットフォームが存在することは、Microsoftにとっても「盛り上がっているモバイルプラットフォームに、既存のWindowsでの蓄積を生かせない」というジレンマになっていた。 特
デスクトップ環境での動作を主眼に開発された「.NET」のオープンソース実装である「Mono」は、どのようにモバイル開発に向かって流れていくことになったのか。 ← 前回 連載 INDEX 次回 → 前回まではMonoについて詳しく説明した。Monoは.NET Frameworkのオープンソース実装としての側面が強く、.NET Frameworkはデスクトップで使用されることを主眼に開発されていた。それがどのようにモバイル開発に向かって流れていくことになったのだろうか。今回は、Xamarin.iOSやXamarin.Androidが誕生するきっかけとなった「Monoのモバイル化の流れ」について説明する。 Silverlightの登場 最初の大きな動きは、Silverlightだ。Silverlightは、Webブラウザーのプラグインとして「Webブラウザー上で、HTMLより機能豊富なアプリケー
Mozilla は、Flash、Java、Silverlight など、サードパーティ製のプラグインを Firefox で読み込む方法を変更します。この変更は Firefox のパフォーマンスと安定性の向上に役立ち、セキュリティ上も大きなメリットがある一方、プラグインに対するユーザのコントールをより強化することができます。 これまで Firefox では、Web サイトで必要となるプラグインを自動的に読み込んでいました。しかし今後は Firefox では Click to Play 機能 によって、ユーザが特定のプラグインを有効にするボタンをクリックした場合のみ、または特定の Web サイトでは 常にプラグインを実行 するようにユーザが事前に Click To Play 機能を設定している場合にのみ、プラグインをロードします。 ユーザによるコントロールの強化自分のマシン上でどのソフトウェア
Mono project 創設者でもある Miguel de Icaza 氏は、InfoQ とのインタビューのなかで Mono Project 版 Silverlight の開発を中止していることを認めた (I PROGRAMMER の記事、InfoQ の記事、本家 /. 記事より) 。 Mono project は、.NET Framework および Silverlight 互換環境をマルチプラットフォームで実現するためのオープンソースプロジェクト。Icaza 氏曰く、Silverlight の Mono のバージョンの開発にこれ以上注力する意味はないだろう、とのこと。Silverlight は可能性のある技術だったが、Microsoft が機能的な制約を加えたこともあり Web 上でほとんど使われていないのが現実だ。Microsoft は Silverlight が死んだことを認めな
先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの?」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob
金曜日に、@ITで以下のような記事が公開されました。 特集:XAMLファミリ共通開発のすゝめ(前編) Windows 8時代のGUI開発を考える そして、Silverlightを囲む会で以下のような発表をしてきました。 https://r.office.microsoft.com/r/rlidPowerPointEmbed?p1=1&p2=1&p3=SD5C622397E11C979D!3402&p4=&ak=!AFg49XomaSVgLM4&kip=1&authkey=!AFg49XomaSVgLM4 https://skydrive.live.com/#!/view.aspx?cid=5C622397E11C979D&resid=5C622397E11C979D%213402 1万字程度の原稿に加えて、25分間のプレゼン発表って、何この学術発表スタイル。 公約数 VS プラットフォーム
SilverlightはVisual StudioやWindowsなどマイクロソフトの技術と連係したリッチな体験やツールの提供と、Windows Phoneの開発プラットフォームとして位置づける。HTML5は多くの用途に利用でき、重要さが増すクロスプラットフォームの技術としてこれからもコミットしていく。 マイクロソフトは4月4日付けのSilverlight Team Blogにて、HTML5を中心とするWeb標準が進化し、マイクロソフトもそれにコミットしていく中でSilverlightをどう位置づけていくのかに関する長文の記事「Standards-based web, plug-ins, and Silverlight」をポスト、上記のように両者を位置づけることをあらためて表明しています。 しかもこの記事は、同社のプラットフォームや開発部門をリードする3人のエグゼクティブ、デベロッパー部門
MVVMパターンに関する認識・知見があちこちに散らばっているように見えるので、そろそろまとめてみる事にしました。この記事は、他の各サイトの記事などでMVVMの基本的な考え方・実装方法などを把握されている方が対象です。 そういった方がMVVMパターンを実務に適応してみようと思った時や、MVVMパターンを要件に合わせてカスタマイズしていく際に、認識すべきパターンの実装方式のそもそもの理由と考え方、要件に合わせて考えていかなければならないポイントを把握する助けとなる情報を提供するのを目的としてこの記事を書きました。(文字ばかりですいません><) MVVMの実装の各要素の実装をこねくりまわすばかりで、その過程でパターンを把握している気になって、パターンの本来の目的を破壊してしまうような実装を推奨してしまっている人も見ます。そんな滑稽な事をしない認識を持って欲しいのです。 MVVMパターンは、WPF
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く