Python Generator

>>> def make_counter(x): print(‘entering make_counter’) while True: yield x print(‘incrementing x’) x = x + 1 >>> counter = make_counter(2) >>> counter >>> next(counter) entering make_counter 2 >>> next(counter) incrementing x 3 >>> next(counter) incrementing x 4 >>> next(counter) incrementing x 5 >>> def fib(max): a,b = 0,1 while a < max: yield a a,b = b, a + b >>> for n in fib(1000): print(n,end = ‘ ‘) 0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 >>> list(fib(1000)) [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987] >>> Python Generator の話

K.Yairi のVintage Guitar

1981年の春ごろだと思うからもう40年近く前の話になる。 初めて米国の土を踏み、 2か月ほど働いて最初の給料が払われ、当時の金額で大枚500ドルを(為替レートが一ドル220円くらいでしたな)握りしめ真っ先に向かったのは前から目を付けていた町のギターショップだった。  あまり高くなくてもいいからMartinのDシリーズのボディーのギターを購入するつもりだった。  ところが店のマスターは「売らんでもないが、マーチンなんか買うな。」という  350ドルで勧められたのは日本製のギターの K.Yairi。 当時 S.Yairi と K.Yairi という二種類のYairiががあるというくらいは知っていたのだが、 日本にいたころはやはりMartinとかGibsonとかコンポジット材を使ったObationなんかが有名で、アメリカに行ったらアメリカ製を買うつもりだったのに、「悪いことは言わないから、値段も一回り安いし、この日本製を買いなさい。」と言われてしまったわけだ。 というわけで諭されてK.Yairi(Alvarez)を購入した。 時は過ぎ、結婚して子供ができ、その息子が大きくなってギターを弾きたいと言って地下室にしまってあったYairiをひっぱりだしてきた。10年くらいは触ってもいなかったわけで Tune UPに出すように言って、彼がGuitar Centerという最寄りのChain店に持って行った。 息子曰く、 Techが「お、Yairiだ」と言ってfHoleの中を望みこみ、 顔を見上げて、「兄ちゃんこのギターどこで手に入れた? これは掘り出しものだぜ」 と言ったそうな。 預かり証に書き込んてくれた時価評価額が3,900 USドル ずいぶんと中途半端な値段だが、これを聞いた親のほうが驚いた。 息子はホクホクものである。 ギターは初心者のはずだったが、さすがは鈴木チルドレン。 コードも難なく覚え、すでに自分より手練れの様子である。 さすがです。    

React Revisited after version 16.8

React というのは DOMの内容を簡単に操作しようという JavaScriptのライブラリーの一つだが、Shadow DOMという概念を導入し、JQueryのようにコマンドごとの実行でDOMを書き換えることはせず、Shadow DOMにある程度書き込んでおいてから描画する直前にまとめてDOMに書き込む。なので軽快に動作する、というのが売り。 数年前に覚えようとしたのだが、 二点腑に落ちないところがあって、結局、Vue.jsという他のLibraryを愛用(溺愛)するに至った。 その二点というのが 1.JSXという新しい概念の導入。 一見するとHTMLなのだがHTMLではなく、XML書式をJavaScriptで理解できるようにしたプリプロセッサ。この一見HTMLというのがくせもので、class= はJSの予約用語ゆえに使えずclassName=にしなければならないなど、細かいところで違っていて気持ちがわるい。(これに比べてVueのTemplateはまごうことなきHTMLの拡張) 2.コンポーネントで操作できる変数(State)を使うためにはコンポーネントをClass表記してsetState()という関数を使って管理しなければならない。 というもの。 その後 「JSXは単なるJavaScriptの関数表現」という開発チームの解説をYoutubeでみて ストンと納得できるものがあったものの、 二つ目のJavaScriptにClassが必要というのがなんとも納得いかない(個人の意見です)身としては今いち手が出せずにいた。 Class表記をするあまり、 thisの多用を行い、しかもそのContextを明示するためにClass Constructorに this.function=this.function.bind(this) を書きまくるというのがなんとも切ない。 しかしながら、 Reactの勢いは侮りがたいものがある。 特にMicrosoftのOffice開発系の方たちは Office UI GraphicsのComponentに「Reactは正義!」という感じで使いまくっている。 SharePoinitの JavaScript Frame workも Reactびいきがすごい。 で、最近React-client-appというCLIでReactのScaffoldingが簡単にできます、という記事をよく見るので、実際どれくらい簡単なんだいと試してみたら、 生成されるScaffoldingのComponentがClass表記ではなくfunction表記になっている。 あれ、これって、Stateful Componentは Class表記しなければいけないんじゃなかったっけ、と思ったが、 実はReactも進化していた。 Version 16.8から Hooksという機能が追加されて Functional ComponentでもStateの管理ができるようになっていた。 そして今まで、 Functional Component = Stateless Component, Class Componnet=Stateful Componentとなっていたものが、 どちらを使ってもよいようになっている。 Reactのサイトにも将来の開発にはFunctional Componentを使うのがおすすめと書いてある。 なので、React-client-appもDefaultで生成するコードはクラスレスになっていたわけだ。 紹介ページ https://reactjs.org/docs/hooks-intro.html にあるコードをみれば一目瞭然だが、クラス表記のようなConstructorもなければ、this. でメンバー指定をすることもない。 非常に簡単。 ただ、このHookを使ったクラスレスのステートフルコンポーネントの作り方、オフィシャルサイト以外で解説しているサイトはまだ少ない。 この const [ var1, setVar1]=useState(‘this is variable one’); で気をつけなければいけないのは Var1が複数メンバーから構成されるオブジェクトだった場合、 const [obj1,setObj1]=useState({member1:”this is member 1″, member2:”this is member 2″}) のように Obj1を宣言したときに、 setObj1({member2:”this is member 2 modified”}) とやってもsetState()と違って、オブジェクトの他のメンバー(Key)とマージしてくれない。上の例ではmember1が消えてしまう。 セット関数には元のstateがパラメータとして渡されているのを利用して、 setObj1(s=>({ …s, member2:”this is member 2 modified”})) とスプレッド表記を使ってマージしてあげる必要がある。(上のサイトにはObject.createを使うのも可と書いてある) また、いわゆる ComponentWillMountなどのLife Cycle hookの代わりには描画毎に発火するuseEffect()を使えと書いてある。 このHookは発火を限定するために二つ目のパラメータ―で発火する条件を指定できる。 ファイルデータを読み込むなど、あるいはイベントリスナーを設定するなど、一回だけ発火させたい場合、 このパラメーターを空のアレイで渡してあげることで実現できる。(なんとなくハックっぽいが) useEffect(()=>{Data を読み込む云々}, []) 他にも何種類かのHooksが用意されているが、 演習用にアプリを書いてみると、上の二つのHookだけで、それなりのものができる。 すでにJSXへのアレルギーはなくなっているので、クラスを使わなくてよいReactという選択は結構魅力的です。 すべてにVue.jsを使いたいのはやまやまなれど、SharePoint関連においてMicroSoft が Reactありきの開発を推しているというのはやはり大きい。

Using Vue with WebPack

I wanted to transfer my existing script to WebPack bundle.  The application is a simple page that uses  Vue.js.   Note that I only read Introduction part of Vue and started using it.  At that time, I did not even know the concept of Vue component files .  Thus my application was entirely in one JavaScript file. I rewrote it using typescript.   WebPack bundling was necessary to make it work. I had to decipher minor (but important) detail on NPM’s Vue  module that should be used along with WebPack.  If I were to use a Vue package from node_modules/ and bundle it with WebPack, then the default module that will be […]

String.replaceで知らなかった件

User がノート欄にやたら長いリンク先をそのまま張り付けて、SharePointのリストの表示が著しく損なわれるという現象が自分の管理するサイトコレクションで何件か発生している。 ユーザー教育を行ってリンクの説明を別途短文入力してください、というのは簡単だが、だまって従ってくれるような従業員ばかりではない。 そこで長いリンクを見つけたら強制的に短い文字列に置き換えてしまう、という仕掛けをJavaScriptで書いてしまえばよいのだと思いつき、 試してみた。 結果、以下のような関数を記述し、これを描画時に呼び出す形で解決した。 function shortenAnchor(text) { if (text===null) { return “”; } let testPattern = /(<a.*?href=.+?>)(.*?)(<\/a?>)/g; function replacer(match, p1, p2, p3) { if((p2.length)>30) { p2 = p2.slice(0, 25) + ‘…’; } return [p1, p2, p3].join(”); } return text.replace(testPattern, replacer); } このコードで何をやっているか。 まずtestPatternを正規表現(RegExp)で記述する。 RegExpで a tag elements をグローバルにトラップする。トラップしたエレメントはタグの前の部分、中身のテキスト部分、タグの後ろの部分にグループわけされ、それぞれの文字列は$1,$2,$3として利用可能になる。( a tag element 全体のマッチは$&)。 そして、あとは String.replaceを使ってマジックをおこすわけだが、Implementationを試行錯誤している最中に 二つ目のパラメーターが実は関数でもよいのだ、というのを本日初めて知ったわけで、それを使ってうまく書くことができた。 ここに関数を使うと、以下の引数が この順番で使えるようになる。 まずは TestPatternそのもののマッチ $&, それぞれグループ分けした部分のマッチ $1,$2,$3。 よって match,p1,p2,p3として利用可能にしておく。実はこの後ろにIndexなどのパラメーターも続くのが、今回は必要がないので無視。  この replacer という関数ではこの中身の文字列$2(p2)の長さが30文字以上あった場合、最初の25文字以下を切り捨て点三つ…を最後に追加するというもの。 この関数自体を二つ目の引数として使う。 Testしてみたら一発で完動したので感動(おやじギャグです) 普通はString.replaceというと “this is a pen”.replace(“this”,”that”) //=>”that is a pen” という簡単な使い方は知っていたし、 最初のパラメーターを正規表現にすれば $& $1 etc., などのパラメーターを使ってかなり柔軟な置き換えなどができることも知っていて使ってはいたのだが、まさか関数まで使えるとは思っていなかった。 これは素晴らしい、と思った次第

TypeScript その2

年末の休暇を利用してtypeScriptの演習を続行中。 現在まで理解できたところをとりあえず列挙。 nodejs が導入されている必要あり。 npm install typescript -g これで tscコマンドが使えるようになる。 tsc example.ts そして、これでexample.ts から example.jsがトランスパイルされる。 プロジェクトフォルダー内で tsc init とやると、コンパイラー設定用のtsconfig.jsonが作成され規定値が設定される。例えば、出力のJavaScriptのレベルが <pre>”target”:”es5″</pre> などと記述されている。またコードをトランスパイルしたときのエラーの出力設定などもできる。今のところ全く変更の必要のないレベルでトライアル中。 TypeScript は 基本的には JavaScriptのsuper setなのだが、 ’let’, ‘const’, ‘arrow function ()=>’, ‘ … spread operator’,’Template strings’ などes2015の書式が既にサポートされている。 なのでexample.tsではこれらの言語機能を使ってプログラムを書き、tscでトランスパイルすると、これらの表記をまだサポートしていない現行のブラウザでも動くようなJavaScriptに書き換えてくれる。上のConfig例ではes5レベルのコードに置き換わる。 つまりBabelと同じような使い方ができる、。 type safeなので 異なったタイプの変数へのアサインは論外としてもその可能性が生じそうなコードにはエラー表示が鬼のようにでる。例外処理とか、Interface定義を記述して対処すると満足して何も言わなくなってくれるので、バグの可能性のあるコードを書く可能性が低くなる。

SharePoint Column Formatter の使い方

SharePoint Onlineのテナントで一ヶ月くらい前からPushされはじめた機能なのだが、リストのコラムセッティングに”Column Formatting”というのが追加されている。 Text Entry Field になっており、説明は”JSON書式でフォーマットを記入してください”とかなりそっけない。 詳細はOffice Devのほうにある。 ここ 。 さらに書式サンプルのDepositoryがGitHUBにおいてある。 ここ   で、上の記述を参考にListViewのカスタム化を自分で試してみたのがこれ。 ここではCheckedのColumn Formatting に以下を指定 { “debugMode”: true, “elmType”:”div”, “children”:[ { “elmType”: “img”, “attributes”: { “src”: { “operator”:”?”, “operands”:[ “@currentField”, “/_layouts/images/CNSAPP16.GIF”, “/_layouts/images/CbUnChecked.gif” ] }, “aria-hidden”:”true” }, “style”: { } } ] } これでYes/Noの文字表示をアイコンイメージに置き換えている。 Delivery Statusのコラム書式はちょっと長くなる。(参照する各Columnの内部名称をColumn settingsでそれぞれ確認しておく必要があることに注意 下の例では CheckedはCheckedだがDue DateはTaskDueDateになっている) { “debugMode”: true, “elmType”: “div”, “attributes”: { “class”: { “operator”: “?”, “operands”: [ “[$Checked]”, “sp-field-severity–good”, { “operator”: “?”, “operands”: [ { “operator”: “<=”, “operands”: [ “[$TaskDueDate]”, { “operator”: “-“, “operands”: [ “@now”, 86400000 ] } ] }, “sp-field-severity–severeWarning”, { “operator”: “?”, “operands”: [ { “operator”: “<=”, “operands”: [ “[$TaskDueDate]”, “@now” ] }, “sp-field-severity–blocked”, { “operator”: “?”, “operands”: [ { “operator”: “<=”, “operands”: [ “[$TaskDueDate]”, { […]

TypeScript 入門

TypeScriptのイントロがDev.office.comにあるので眺めてみた。 tsとして以下の例が載っている。 class Student { fullName: string; constructor( public firstName, public middleInitial, public lastName){ this.fullName = firstName + ” “+ middleInitial + ” ” + lastName; } } interface Person { firstName: string; lastName : string; } function greeter(person: Person){ return “Hello, “+ person.firstName + ” ” + person.lastName; } let user =new Student(“Jane”,”G.”,”Doe”); document.body.innerHTML=greeter(user); これをJSにコンパイルするとこうなる(WebStormはプラグインが動いてダイナミックに自動生成する) var Student = (function () { function Student(firstName, middleInitial, lastName) { this.firstName = firstName; this.middleInitial = middleInitial; this.lastName = lastName; this.fullName = firstName + ” ” + middleInitial + ” ” + lastName; } return Student; }()); function greeter(person) { return “Hello, ” + person.firstName + ” ” + person.lastName; } var user = […]

SharePoint Framework

去年の暮れぐらいだったか、MSのお知らせでSharePoint Frameworkという新しい開発環境を使った SharePoint SiteのCustomizationが可能になりました。という連絡があった。  自分がやりたいSPサイトのCustomizationは 基本的にJavaScriptをページに埋め込むJavaScript Injectionという手法だ。 これでクライエントサイドの描画をコントロールするCSRフックとかリストやファイルのアイテムをAjaxで読み書きするREST APIなどを使ってカスタムページを作るという方法で用が足りてしまうので、あまり気にしていなかったのだが、この方法、最近、その進化が目立つModern view  pageでは使えない。 これは開発するのにVisual Studioが必須であるSharePoint Add-Inでも同じ様で、 どうも今の時点でModern Look componentのCustomizationをサポートしているのはSharePoint Frameworkのみのようなのだ。 で、Dev.Office.comのDocumentationを眺めてみると、なんとこれ、 Node.JS上で全部動いているのだ。 NPMで yo,  gulpと @microsoft/generator-sharepoint を導入し Project folderを作って以下を実行 yo @microsoft/sharepoint これで必要なファイル群がフォルダーにインストールされる。 hello worldのテンプレートになっているので、これでもうnode.js 上のローカルPCで動くSharePointのページを模したWorkbench上での実行が可能(下記コマンドでDefaultブラウザが勝手に立ち上がる) gulp trust-dev-center gulp serve ここまで、SharePointサイトにアクセスする必要すらない。 Step by Stepはdev.office.comに詳しいので割愛 (Build your first SharePoint client-side web part (Hello World part1)) SharePointのサイトでもすでにDevelopper siteが例えば”https://mysite.com/sites/dev”などとして設定されているなら、 ”https://mysite.com/sites/dev/_layouts/workbench.aspx” にアクセスすると、開発中のwebPart のWorkbenchがSharePoint上で作動する。 そしてこのTool Chainによる開発、Visual Studioが必要ない、というか使えない。dev.office.comのお勧めEditorはVS Code. IDEの例としてJetBrainのWebStormがあげられているなどVisual Studioへの依存性が一切ない。(C#もドットnetも使わないなら当たり前というべきか) ただ、使われているコードが通常のJavaScriptではなく、TypeScriptなのだ。 TypeScriptのコードは実行時にはJavaScriptにばらされるのでそんなに大きなLearning Curveにはならない、と予測はしているのだが、これは学習する必要があるんだろう。 Node.jsは言語というより開発環境のベースとして使われるので、これ自体を学ぶ必要はない。 VSで使っていたNugetだとかMS buildーtoolなどのツールが、下のようにNode.JS上で動くツールにおきかわっているわけで、今わかっている範囲でまとめると Node.js: Install するだけ、普通のJavaScriptの知識で十分のはず。 NPM :DependencyのUpdateなど、使い方は学んだほうがよさそう。yarnでもいいのかな yeoman(yo):Install するだけ、学習の必要性はなさそう gulp: コマンドをいくつか覚えるだけで学習の必要性はなさそう typescript: 学習の要あり webpack:@microsoft モジュールを導入したときに含まれている。さわらなくてよい。何本ものファイルを、一本に圧縮する、というような作業をやっているらしい。 VS CodeまたはWebStorm:Dev.office.comはVS Codeを使った用例を挙げているが、自分は従来からつかっているWebStormを使う。 というわけで、なんと開発環境的には、2,3,4,5,6は1のNodeJSが動けば動くのでなんでもよく、VS codeもWebStormもマルチOS環境で動くので 要するに Linux上で開発できてしまうのだ。 というわけで、javaScriptをかじっている人間にはハードルが低そうな予感。 Linux環境でぼちぼちやってみようかな?

SharePoint Change Page Title without changing site address ページタイトルをサイトアドレスを変えずに変更する。

これってSharePointのこの部分がちゃんと動いていないだけなのではないかとおもうのだが、今現在のOffice365(SharePoint Online)のインプリメンテーションだと、Page Attributeでページタイトルを変更するとaspx ページの名前自体が変わってしまう。 たとえば https://mysite.sharepoint.com/sites/mysite/SitePages/thispage.aspx というページがあるとして、これだと表示されるページタイトルが”thispage”となってしまう。これを Edit pageからタイトル変更して ”This Page”とすると、 サイトアドレスが https://mysite.sharepoint.coms/sites/mysite/SitePages/This%20Page.aspx となってしまう。サイトアドレスをなるべく短くしたいのでページタイトルとサイトアドレスの一部になるページの名前を別けることができればよいのだが、今の時点ではできない。 世の中には同じことを不便と考える人がいるわけで、何件かの記事ではSharePoint Designerを使ってマスターページを変更する方法が述べられている。すでにSharePointにある機能をターンオンするだけの簡単な修正ではあるが、 1)マスターページを変更する必要がある。 2)SharePoint Designerが必要 すなわち、サイトオーナーでかつSharePoint Designerを使えるという条件を満足していなければならない。 ブラウザーのdebug Toolで確認してみたら以外と簡単にタイトルだけ変更できることが判ったのでここに書いておく。 サイトのエディター権限があればできるというのが利点。 ターゲットのページでエディットモードに移行し、適当なところに Insert ->Embed Codeでコードエディターを開く。 以下を入力する <script> document.getElementById(‘DeltaPlaceHolderPageTitleInTitleArea’).innerHTML=”My Page”; </script> これだけである。 ページタイトルが”My Page”となる。 SharePointの場合、CSRというメカニズムがあって、表示する内容の大部分は一度ブラウザーがスクリプトを実行したのち、データを描画するため、 ページへの書き込みのタイミングを遅らせなければならないのが普通だが、タイトル部分は最初の読み込み時に描かれてから変更がないため、上のようにブラウザがスクリプトを読み込んで即実行、という単純な動作でも有効なんである。 ちなみにWiki PageとWeb Part Pageの両方で有効。 Site Pageはためしていない。