【IT】Microsoft、Excelカスタム関数としてJavaScriptのサポートを発表
■ このスレッドは過去ログ倉庫に格納されています
Microsoftは先日、JavaScriptでExcelのカスタム関数の作成をサポートする開発者プレビューを発表した。これは、Officeホストアプリケーションのオブジェクトモデルと対話するアドインやWebアプリケーションに限定される既存のMicrosoft Office JavaScript APIを超えて実現できる。
Microsoft Officeチームは、GitHubソースコードリポジトリを作成して、JavaScriptを使ってExcel関数の使い方を学習できるようにした。このサンプルリポジトリは、主要な4つの機能に分けている:
* JavaScript: カスタム関数のソースコード
* JSON: 利用可能なカスタム関数を表示するためにExcelで使用されるメタデータ
* HTML: 関連するJavaScriptソースコードとカスタム関数を初期化するためのメソッドを参照するためのプレビューリリースメカニズム
* XML: カスタム関数とそのリソースの場所と名前空間をExcelに伝える
カスタム関数はユーザーインターフェイスと関連付けられていないため、DOMを操作してはならない。この機能の最終リリースまでにカスタム関数の初期化のためのHTMLは削除される予定だ。
PromisesのサポートのようなモダンなJavaScript機能がサポートされているため、開発者はカスタム関数を、すぐに計算済みの値を扱うために同期にしたり、完了までの複数の計算をする非同期処理としてカスタム関数を定義できる。1回だけではなく、複数回値を返す非同期promiseであるStreamsもExcelカスタムJavaScript関数のオプションである。
ExcelのJavaScriptは、Microsoft Edge Webブラウザで使われているものと同じChakra JavaScriptエンジンを利用している。
カスタム関数は現在、WindowsとMacの開発者プレビューバージョンのExcelに限定的にサポートされている。カスタム関数は、モバイルデバイスや、製品バージョンのExcelでは、現在サポートされていない。
この追加により、シートでJavaScriptのカスタム関数をすでにサポートしているGoogle Sheetsと同等になる。
TypeScriptユーザーは、カスタムJavaScript関数を書くことができる。他のJavaScript環境と同様に、TypeScriptをJavaScriptに変換する必要がある。MicrosoftはExcelでTypeScriptを直接サポートする予定はない。
ExcelでのカスタムJavaScript関数の正式な製品リリース日はまだないが、ExcelのカスタムJavaScript関数に興味がある人は、このプレビューリリースを試して、Officeチームにフィードバックを提供して欲しい。
https://www.infoq.com/jp/news/2018/06/microsoft-excel-js-functions それよりワープロと表計算を一つにまとめられないのかよ もうexcelなんていじるなよ
やればやるほどおかしい品物になる だからフロントエンドにはならんと何度言えばわかってくれるんだろう。 どんどん別物になっていくな、2003ぐらいが一番使いやすかった ついにエクセルでマイクラが動くようになるのか(情弱 JavaScriptのサポート = ハッキング、ウィルスなど様々な攻撃を受ける ウェブアプリでいいじゃんって話になるわな まあ攻撃の対象にしかならんが 素人が作った変な処理を解析させられるのは苦痛以外の何物でもない
修正するくらいなら全部作り直したほうが早い場合が多い Execl2000で完成してたのに、あとは改悪一途 VBAの代わりにPythonを使えるようにする話はどうなったの?
待ってるんだけど これさ、現場だとVBAで全部組むと怒られるんだよね
他の人が分からないって
だからできるだけ関数で作るんだが。 >>2
いや、逆だろ、有名ウィルスパターンが見つかりやすくなって、
元のマクロウィルスより害が減る。
マイクロソフトのベースコードに潜むバックドアの方が凶悪。
変数の代入だけでウィルスコードの開始を始められる条件とかあるし・・・ >>20
Cプログラムの安全性解析とか、実行速度の改善にエクセルは良く使うな。
計算に制限かかるから、計算式を単純化しないといけない。
単純計算が大量に見える様になるから無駄な計算を洗いだしやすいと言う利点がある。 JAVA?
時代はピィトホンだろ
AIなんだ
ガハハ ピィトホン?
素晴らしいセンスだな
我々もかくありたいものだ >>19
Pythonも検討したけどやめて、JavaScriptを採用しましたって話だろうな
開発リソース的に新言語を同時期に2つも統合するとは考えにくい MSならTypeScriptだろうな
pyのほうでのサポートに期待してたけど、やっぱそうなるか TypeScript直サポートしろよ
あとC#も頼む javascriptってブラウザ使って半ば強引に動的に表示させる案件でなければ
なるべく触りたくない。
getelementbyidのidはセル番地になるのか。
変なexcel用関数増やされても邪魔くさいし。 それよりexcelにマクロ埋めるのやめようよ。本当に業務上、パーソナルな使い方するならいいけど。
得意先が「これに書け」と命令してくるマクロ付きexcel書式が特にひどい。
1文字打つごとにHDDが激しく動き、あらゆるシート、セルにカーソルが移動しまくった3秒後に1文字目の入力が確定する、みたいのが結構散見される。 「公明党、創価学会よどこへ行く」( 週刊東洋経済 eビジネス新書 ) 
与党協議に関わった横山氏は 
「自民党の北海道連の意見が 
まとまっていなかったこともあるが、 
札幌延伸をリードしたのは明らかに公明党。 
函館に新幹線を上陸させれば、後はなんとかなると、 
『青函(青森と函館)同時開業』を公明党が言い出したときが 
(事態が動き出した)転換点だった。」と振り返る。 
http://56285.blog.jp/archives/49650766.html 
----------------- 
国土交通省で「天下り」が完全復活した。 
その中心的人物が、石井啓一国交相だという。 
要するに「バリバリの元国交省キャリア」が、 
かつて自分が勤務していた省で大臣となり、 
天下りを復活させたことになる。 
http://www.yellow-journal.jp/politics/yj-00000295/ 
----------------- 
当時、内田氏は 
都議会自民党幹事長として売り出し中だったが、 
今ほどの権力はなく、公共工事の仕切り役は、 
都議会公明党のドン・藤井富雄氏だった。 
藤井氏は、05年に政界を引退し 
仕切り役、調整役の座を内田氏に禅譲。 
(中略) 
老朽化した築地市場の移転は、 
石原氏の前任の 
青島幸男知事の時代に持ち上がったが、 
その構想を推進したのは、 
東京都港湾局長時代の石川雅已・現千代田区長で、 
臨海副都心開発部長として石川氏を支えたのは、 
前川あきお・現練馬区長だった。 
山田氏は、後述するように 
両氏をOBとなっても物心ともに支えた。 
つまり豊洲移転は、 
石原都政の前に都の官僚が 
議会や市場関係者に対する根回しを行い、 
推進してきたのだ。 
http://gendai.ismedia.jp/articles/-/50989 
----------------- 
公共事業絡みで口利き 
公明・藤井都議が都幹部などに 
コンサルタント会社を紹介 長男が「顧問料」もらう 
http://www.jcp.or.jp/akahata/aik2/2004-01-08/01_02.html 
--------------- --  
創価大学生のおもな就職先 
http://56285.blog.jp/archives/49851484.html これならオンライン版でのマクロもサポートできるもんね
グーグルのものそんな感じだし、今後はもうVBAは無くなってくんだろうね >>2
>マクロウィルスが凶悪化しそうだな
COMとAPI使えば今でもなんでもできるぞ? >>26
> >>19
> Pythonも検討したけどやめて、JavaScriptを採用しましたって話だろうな
> 開発リソース的に新言語を同時期に2つも統合するとは考えにくい
カスタム関数による関数の拡張はJavaScriptで,VBA的な自動処理は
Pythonで,と言うことじゃないですかね。 >>5
某政府「今後公文書の作成はexcelに統一 JSONあるならXMLいらなくね
どっちかにしろよ 勘弁してくれ
GPで無効にできるようにしてください
うちにはまだ早い ググるのスプレッドシートから乗り換えられるよ、って言うための布石とか >>46
将来的には完全クラウド化するのはもう必然なんだから当然グーグルをつよく意識せざるを得ないよね >>36
無理やり全角文字入れたり、文字列にしたり、報告ボタンを押せって言ったのに自力でメールに添付したりする馬鹿が多いからな >>47
office365はすでにクラウドベースなんだが
あとGoogleのクラウドなんてショボいぞ >>40
COM久しぶりに聞いた。ActiveXって言ってたんだよな。もっと前はOLEオートメーションとか。懐かしいわ ここでTypeScriptを採用してたらまたJSコミュニティを警戒させたろうけど、大人になったなMS。 >>49
だからこの先ローカルインスコ版がなくなるって話でしょ JSで検索するとJavaScriptのページばかりヒットするので、本当に迷惑です まーさっぱり内容は判らんがGoogle SheetsがJavaScriptのカスタム関数をサポートしとるからExcelも追随すると。
互換officeアプリが後追いだけじゃなく独自機能を搭載するようになって来とるという事なんかな。 JSONなどという気味の悪いものを Excelのような適用ソフトで使用するのはいかがなものか
マイクロソフトは説明責任を果たすべきではないだろうかw まあ日本じゃいくら機能を搭載したところでデータの再利用性をまったく考えていない
ゴミを生産し続けるだけだろ。 所詮はパーソナルなツールだよ。
これからも日本人は神エクセルを生産し続けることだろう。 >>58 Excelにデータ入力したら「印刷して」○○さんに渡してね
ってよく頼まれます 違う、そうじゃない
JavaScriptじゃなくて、みんなはC#が欲しいんだ >>51
そりゃTSをJSに変換すればいいだけだから JSON形式のデータに対応したデータベースやソフトウェアにExcelを関連付けられるのかな >>57
個人情報や機密情報が数多く含まれるエクセルでJSONなる気味の悪いものを使うとは如何なものか。 >>57
今日は13日だけど金曜日じゃないから説明は無しな Excelいじっている時間があるなら Edgeをちゃんとしたものにしろー。
またまた脆弱性が問われる報道がでてきた。
もう頼むからだれか日本発のOS開発してくれないか?
まったく、安心して使えないMicroなんざ御用なしー。 >>69
ソフトウェアエンジニアを小汚い奴隷のように扱う日本でOSなんか無理w
オマエみたいなクレクレ野郎ばかりで自分でなんとかしようってのがいない支那www >>69
Edgeなんてもう諦めたほうが良いくらいのシェアだろ というかもうOSなんてほんとになんでもよくなってくでしょ Access触らないとなんないんだけどこっちも頼むよ マルウエアがえぐいことになってまともな企業なら使用禁止になりそう
実装するのは勝手だけどデフォルトはコンポーネントインストールなし、
入れてもデフォルトオフにしてくれ accessで帳票一枚印刷するつもりが
全件印刷し始めて慌ててプリンターのコンセントを引っこ抜く JSだとウィルスが増えるとか言ってる奴はよくわかってないだろ。
VBより生産性が高いからウィルス作成が捗るとかいう話なら別だがw それよりVBE何とかしろよ、使いにくい
VSと簡単に連携できるようにしてほしい >>78
VSEもVSなるものも分からんが時代はそこじゃないんでは? >>80
言語なんか手段でしょ固執するなよ。もったいよ 自分用の「ちょっと便利ツール」用にACCESS VBAばっかり
やってて、たまにjavascript触ると、{ }が多すぎて
「あれ?どこまで閉じたっけ?」と迷うこと多い。
仕方なく「関数なんちゃらを閉じるやつ」とか、アホみたいな
コメント書いてる。 >>84
開発用のまともなエディタ使えば対応するカッコが強調表示されたりして一目瞭然なのに pythonじゃないのか。
web屋にすり寄った方が良いと判断したのか。 >>7
Wordもいじってほしくない。
一太郎がライバルだったときはWordの日本語ローカライズもそれなりにしっかりしてたけど、
今やWordはどんどん日本語無視の方向に行ってる。 (´・ω・`)そのうち、pythonとLaTeXをサポートするに1000点 >>88
wordはtex形式の数式入力に対応したな >>84
スパゲティなのが眼に浮かぶwでも良いんだよ業務が効率化出来てれば 社内共有のexcelにマイニングのjavascript入れたら、
退職後も掘り続けてくれるな。 Excel本体とVBAとの間でちゃんと統率が取れているのかどうかすら怪しいのに、JavaScriptなんて大丈夫なのか?
Excelでは行の高さは0.01ポイント単位で設定出来るのに対して、
VBAで行の高さをコピペすると0.25ポイント単位に切り上げられてしまうとか
マクロで長い帳票を出力すると段々と帳票のページがずれてくるんで、
その誤差が積み重なったのが原因って分からずにずっと悩み続けてたわ 余計な機能ってあほかよ
Google Spreadsheetじゃ普通にJavaScriptつかえるだろ
むしろおせーわ >>93
行の高さw
データの本質は行の高さになんて左右されません
ばかすぎ いやまあ、実際のところ、他人が作った糞長い処理を解析するぐらいなら、
同じ目的で作り直した方がずっと早いと思うw >>96
バカそうだなぁ
関数ですかそれ?
典型的なばか 追加要件に合わせて、全体の処理も最適化するつもりで作り直してしまえばいい。
EXCELの式は可読性無視だから、判らないとこや面倒なところだけに処理を絞って参考にして、
全体を作り直すころには前の奴が何をしてたか凡そ理解できてたり。 VisualStudioを買えばいくらでも拡張できるよ!! byゲイツ 非同期、イベント駆動型であるJavaScriptを選んで正解。
Google Apps Scriptだってそうなんだし。
俺としては大歓迎。
おっと、MSOffice使ってないんだった。 officeの拡張システム(適当まとめ)
1.VBA
Office標準機能、他の手段より分かりやすいが現代的な言語ではないので規模が大きい物は作りにくい
基本的に誰でも解る(MS基準)ように言語仕様が作られてるのでオブジェクト指向を知らない残念なプログラマでもそれなりに作れる。
2.com
ほぼ無制限にWindowsの機能を使える。VisualStudioで作成
C#やVB .netでも作成可能なので一応、これがプロがOfficeを拡張する時の標準的手段?
3.XLL
Excelだけに準備されたC++ライブラリ。当然、VisualStudio必須
低レベル処理なので(プログラマの腕が良ければ)コンパクト+爆速
これを使ってバリバリC++で処理が組めるエンジニアなら、そもそもExcel必要無いという矛盾
4.JavaScript(計画) ←new Pythonがエクセルに実装されるって聞いたんだけど
どうなるの? >103
1.VBA
APIを使えばなんでもできるぞ。
なんちゃってでもそれなりに動くので残念なコードが生まれやすいのが欠点だな
2.com
COMのインターフェースを準備しておけばDLL(OCX)経由でなんでもできる
つーか、Office自体がCOMのオバケだ
3.XLL
使ったことないのでしらね
4.JavaScript(計画) ←new
どうなんすかね?文法はJavaScriptかも知れんがオブジェクトは
Excelのオブジェクトを操作するんだから文法だけ同じでも仕方ない気がするが、、、
あれ?JScriptってのがなかったけ? >>1
とうとうVBA要らない子になったか…
前から要らんかったけど 余計なことしなくてもいいよ。
手を広げても大混乱に陥るのがおちだ。 VBAで頑張っちゃったの見るよりかは・・・
Excel使ってまで無理矢理頑張らなくてもいいのにってやつを見なくて済むようには
ならないよなー単に置き換えるお仕事とか発狂ものだろうし そんなことより、Excel VBAの開発環境をどうにかしてくれよ。。。 >>113
>そんなことより、Excel VBAの開発環境をどうにかしてくれよ。。。
不満か?そこそこ使いやすい環境だと思うが? 自動構文チェックとか設定が間違ってるんじゃね?>>ExcelVBA開発環境 久々にVBAの画面みてワロタwww
ここだけ完全に時間が止まってるのなwww
でも、逆に言えばこれを最初に作った人が凄いということなんだろうな。
先見の明があるというか。。。
Stack Overflow作ったおっさんだっけ。作ったの。
VBAの設計案をゲイツの前でレビューしたとき、あのダメ出し王
のゲイツが黙ったとか。。。 Basic系はMSの基礎みたいなもんだからゲイツ氏が元気なうちは消えないと思っていたが >>119
なんでVBAが消えるという解釈になってるの? >>120
将来的にクラウド一本でやってくなら遅かれ早かれ消えるでしょ >>122
Excelがクラウド一本になるというニュースではないんだが >>124
これはちがうけどいずれそうなるってことよ >>120
あーごめ
そんな感じのレスがあったんで
消えると思ってるわけではない 皆そんなにEXCELにマクロいれてんの?
ちょっと信じがたいというか。
数千〜数十万レコードを解析したいなら、自分なら
はなからデータベース側で集計かけてデータリンクか
エクスポートで出力するし、ちょっと小奇麗に成形するに
してもピボットで済ませる。
たまに得意先から「これに書け」って書式渡されて
「最後にここのボタン押せ」ってCSV吐き出すやつとか
意味わかんない。 早く触ってみたいんだけどプレビュー版いつ頃出るの? >>19 >>86 >>106 >>123
言語としては明らかにPYTHONよりJavaScriptの方が優れているから今回は正しい判断
特に非同期イベント駆動でのJavaScript有利が大きい 部署の外に送るExcelファイルに使うんじゃねーぞ ■ このスレッドは過去ログ倉庫に格納されています