@tyskdm

Search This Blog

test#2

on January 28, 2013

Get link
Facebook
X
Pinterest
Email
Other Apps

これはどうなる？

Get link
Facebook
X
Pinterest
Email
Other Apps

Comments

Googleドキュメントの共有は必ずラベルで。

Google driveのドキュメントはオンラインで共有できて便利です。わたフク。では当初、データをエクセルで管理していたのですが、Googleに載せてからは常に最新の状態をメンバーで共有できるし、履歴もみられるし、とても便利になりました。ただ、だんだんとメンバーが増えるにつれて、どのファイルを誰と共有しているのかがわからなくなる、という問題が大きくなってきました。ファイルをユーザーに対して直接共有してはいけないこれはGoogle driveの話というより情報システム一般の話でしょうが、ファイルへのアクセス権限付与を、個人に対して行うと混乱します。そのひとの役割が変わったり、メンバーが増減したり。誰にどのファイルへのアクセス権限を付与したか、全部記録しておかないと、必ず作業で漏れます。ひどく面倒な自体になってしまいます。（なってしまいました T-T）また、もっとひどいことには、Google driveでファイルを直接誰かに共有すると「このファイルを誰かと共有しているかどうか」を確認しようと思ったら、そのファイルの共有設定を開いてみる以外に方法がありません。マイドライブのドキュメントリストをみても、そのファイルが共有されているかどうか、共有解除を忘れていないかどうか、全くわからないのです。こうなると、もう最悪です。初期のころ、そのへんよくわからず共有していたファイルがあり、一度大掃除（フィルをひとつずつ、共有設定を開いて全数確認する）をしたのですが、昨日、共有解除漏れのファイルを見つけました・・・。＊それで今、これを書いているわけです。自戒を込めて。ドキュメントの共有は役割に対して幸いGoogle driveにはラベルの機能があるので：アクセス権/ 　経理係・参照　経理掛・編集　配送係・参照　配送係・編集などのように、役割毎の参照権限ラベル・編集権限ラベルをつくっておいて、シェアしたいファイルにこのラベルを付与します。そうすると、あるファイルが共有されているかどうかは、文書リストでどのラベルが付与されているかを見ればわかります。また、アクセス権のフォルダの中をみれば、その役割のひとたちにどの文書を共有しているか、いないかがすぐにわかりま...

GASライブラリの、Global Object

GASのライブラリ機能 GASには、あるプロジェクトを他のプロジェクトからライブラリとして読み込む、という機能があります。このとき、読み込まれるプロジェクト側では：グローバル空間で、 function宣言文によって定義された関数だけが、公開されます。読み込み側へは、利用者側で設定した名前のグローバルオブジェクトに公開された関数が格納されるという形で、公開されます。 Javascriptでライブラリセットを構築するとき、グローバル空間を汚さないように単一のオブジェクトにすべてを格納することが多いかと思いますが、これと似ています。 Where is this? で、気になったのが、「ライブラリにとってのグローバル空間ってどこだろう」。ライブラリは、ロードされ、初回の実行コンテキスト（目的関数の起動ではなく、On Loadでの実行。なにか呼び名があるんでしょうか？）のときに認識しているグローバル名前空間（グローバルオブジェクト）は、利用者側のオブジェクトのなかに納まってしまいます。ライブラリからみると、最初自分が「ここがグローバル」と思っていたところが、いつのまにか「１オブジェクトのなか」に変化してしまうんでしょうか。 Jasmine & Rajah による実験と、いうことで、実際にコードを動かして試してみました。 Rajahを使って、Jasmineを走らせながら実験を。書籍：「テスト駆動JavaScript」のなかで、「学ぶためのテスト」として紹介されていた方法です。 jasmineを使って、気になることをまず仕様として記述し、成功・失敗を繰り返しながら、正しい仕様だけが記述されたSpecファイル（つまりすべてパスする仕様）をつくってゆくやりかたです。試して学んだことが仕様として残るので、あとで見直すにせよ、他の環境で再実験するにせよ、よい資産になると思います。ソースコードとSpecコード眠い。おやすみなさい。 --- 翌日 --- 結果とりあえず、結果から。ユーザーコードと、ライブラリコードは、それぞれ別のグローバルオブジェクトを持ち別々の名前空間で実行されています。ユーザー空間からライブラリ関数を呼び出したときに、コンテキストが...

Lockをあてにしないデータ構造とフロー

Lockの効果は限定的 GASがあまりに便利で楽しいので、ついつい、SpreadsheetをDBのようにあれこれいじり倒したくなるのですが、わたふくシステムでは、我慢がまん、が方針です。データやデータ構成の一貫性が破壊されることを厳密に防ぐ手段がないので、いずれ必ず問題の原因になる、ということが理由です。 GASにはLockもあるのですが、その2種類あるLockの機能は以下のとおりです。 Private Lock : 同一ロックを同時に取得できるのは、ユーザー毎に１つのスレッド（execution）のみ。 Public Lock : 同一ロックを同時に取得で切るのは、そのスクリプトを実行するスレッド全体から１つのみ。 Public Lockを使えばきちんと排他できそうに一瞬思いますが、ロックはスクリプト（プロジェクト）に所属しています。なので、複数のプロジェクトはそれぞれ勝手に動くので、全てのスクリプトからのアクセスを排他的に処理できるわけではありません。やるとしたら、以下のように運用することになると思います。あるスプレッドシート上のデータにアクセスするには、そのスプレッドシートの保有する単一のスクリプトコードからしかアクセスしない。他のプロジェクトからそのスプレッドシートにアクセスしたいときは、上記のスクリプトコードをライブラリとして取り込み、必ずそのライブラリ経由とする。スプレッドシートというデータにアクセスメソッドを付属させて、ひとつの独立したオブジェクトのように扱う（内部を勝手に触らない）、という意味です。この運用でスクリプト同士の排他は実現できるのですが、、、結局最後は、ユーザーがスプレッドシートを開いて編集を行う、という操作をLockすることができません。なので、上記の運用だけでは不足で、データを本当にLockしたいなら、人間にも触らせない、という運用を含めることが必要になります。そうすればできる、、、、ということではありますが、そうやって生データへアクセスできるのはシステム管理者だけ、ということになってしまうのなら、最初からSQL使ったほうがよほど堅牢で、機能も豊富で、なぜわざわざスプレッドシートを使うのかわからなくなってしまいます。なので、Lock...

Powered by Blogger

test#2

Comments

Post a Comment