本日、仕事で情報科学科2年生の計算機数学という科目のレポートを採点した。 レポート採点者の立場として「読みやすいレポート」について考える。 今回のレポートは教科書の練習問題を解いて提出するというもの。
ちなみにこの見解は、私の見解であり、他の人は全く違うかもしれない。 また、私自身ここで言っている印象(だけ)で採点しているわけではない。 誤解なきように。
やはりなんといっても字がきれいでないと駄目。 字の下手な人もできるだけ丁寧に書くべき。 汚い字のものは読む気がしないし、実際読めないものも多い。 また人のレポートを書き写す人のものは、急いで写すのか殴り書きのようなものが多い。 逆にいえば殴り書きのものは、まず書き写し(コピーレポート)ではと疑われるであろう。
そういう意味では、女性の方が字がきれいな人が多いので得をしているかもしれない (別に区別しているわけではない)。
途中で挫折したのか、はたまた意図的か。 一部だけワープロなものは、逆に手書きの部分が、余計に貧相に感じる。 図などが手書きなのは仕方ないなと思うが(授業レポートにそこまでこらなくても)。 ワープロを使うなら是非全部。
安いレポート用紙はぺらぺらで、中身まで安っぽくみえそうだ。 ちょっと高いのを買えば紙をしっかりしていて厚くて良い。 まぁ、大学のロゴ入りのレポート用紙の人が多いのでまぁそれはそれでいいだろう。
採点する側もやはり、思考の流れがある。 解答の順番が問題順(または授業での順番等)に沿っていないと疲れる。 また、他人のレポートを複数の人でよってたかって写す場合に、順番が乱れることがあることも知られている(実際私もそうだった)。 提出までの時間があまりないと、とにかく手にはいったものをどんどん書き写すためこうなる。 もし順番に書けないなら、用紙をわけて書いてあとで並べ替えて閉じた方がいいかもしれない。
写すとはっきりいってばれる。 丸写しは採点者には助かるのだが。 なにせ同じ点をつければいいのだから。 が、写しの場合、写した人、写された人ともに減点、または採点の対象とならない事も多いのでやっぱりやめた方が。 どうせ写すならばれないように。
複数枚のレポートの綴じ方、体裁が指示されているのなら必ず従う。 右綴じの中に一つだけ左綴じがあったりすると、作業の流れが狂い非常にまずい。 当然みる方もやな気分になる。
問題を解いて提出する場合は問題番号をはっきり目立つように。 全問解くことを期待していない場合、解答数が採点に影響する。 解答数を数えるのに、問題番号がみにくいと、数え漏れされることもあるだろう。
テキストの問題の解答を採点する時、採点者は最初に問題とレポートの双方をみなければならい。これが面倒だ。 もちろんある程度採点が進めば問題も頭にはいるが。 問題が書いてあるレポートが採点の最初に出てくるととても助かる。 印象もアップだ。 ただし、問題がそばにあるので、じっくり答を吟味しやすいのも確かだ。 答が間違えているなら、採点者がそれをみつけやすくなるので、逆効果かもしれない。
問題だけ、レポートの最初に列挙にされてあってもどうかと思う。 もちろん実験レポートのたぐいなどは最初に問題が記述されるとおもうが、問題数の多い解答提出レポートではまず無意味だろう。
先にも述べたとおり他人にレポートを写させてあげると自分も点がとれないことがある。 覚悟すること。 どっちがオリジナルかまでいちいち判断するほど採点者は暇ではない。 特に、字の汚い人に写させてあげると危険だ。 字の汚い人のレポートはまず写しではないかと疑われやすいからだ。 となると自分のレポートもコピーだと判断されやすくなる。 また字のきれいな人のレポートも他よりじっくりみられる可能性が高いから危険だ。
それでも人間、人のを写して提出したときもあるだろう。 忙しかった? なるほど。 わからなかった? なるほど。 提出しとかないと不安? なるほど。 私もたくさん写して提出した身だ。 肯定はしないが、うまくやれ。
検討を祈る。
去年末に頼んでおいたタイムプラスのサービス開始が今日。 別になにがかわるってわけではないが。
私は夜は寝るのでテレホーダイを利用するつもりはない。 タイムプラスがはじまって1年ぐらいになる。 当初から申し込もうと思っていたがずっとのびのびになっていた。 果たしてどれほど電話代が安くなるのか。
ちなみに今晩はなぜか BUSY でつながらなかった。 いつもはつながるのに……。
Tripwire Security Systems, Inc. より Tripwire ASR 1.3 (tripwire-1.30-1.tar.gz) を入手し orion にインストール。 なお ASR は Academic Source Release の略。
tripwire はシステム中の実行可能ファイル、設定ファイルなど指定したファイルの変更があったかどうかを検証するツール。 システムがクラックされた場合、裏口を開ける機能をつけくわえた実行可能ファイルなどがインストールされたり、すでにあるものを置き換えたりされる可能性がある。 tripwire は事前に作成したファイルの情報のデータベースと、現在のファイルの情報を比較することによってこのような変更を検出することができる。
なおここでは、以下の環境、条件でインストール、設定を行った。
まずはパッケージ展開。適当な作業ディレクトリ上で。
$tar zxvf tripwire-1.30-1.tar.gz $cd tripwire-1.30-1
次に Makefile の編集。 以下の2つの変数を値を書き換える。
DESTDIR = /MO/tripwire/bin DATADIR = /MO/tripwire/var
次に OS 毎の設定ファイル。Ported をみると, conf-linux.h を使うようにかいてあるが、みあたらないので conf-sunos-4.1.h で代用する。
$emacs ./configs/conf-sunos-4.1.h
以下の通り変更する。
#define DIRENT を #undef DIRENT に
最後に include/config.h を編集する。
$emacs include/config.h
ここでは、os 別のインクルードファイルを読み込むようにするのと、各種ファイルへのパスを設定。
#include "../configs/conf-svr4.h" を #include "../configs/conf-sunos-4.1.h" に。また以下の変数の値を変更。 #define CONFIG_PATH "/MO/tripwire/etc" #define DATABASE_PATH "/MO/tripwire/var"
そして make。
$make $make test
次に MO を準備する。 マウントする前にシングルユーザモードにし、インストール、ならびにデータベース作業中に他の誰かが悪行をできないようにしておく。
$su #mkesfs /dev/sdb #mkdir /MO #init S #mount -t ext2 /dev/sdb /MO
そしてインストール。
#make install #mkdir /MO/tripwire/etc #cp configs/tw.conf.linux /MO/tripwire/etc/tw.config #emacs /MO/tripwire/etc/tw.config
とりあえず tw.config には自分でコンパイルしたカーネルファイルの指定を追加しておく。
そしてここから実際に使用。 まずは、現在のファイルの情報に関するデータベースを作成する。 終了すると、tripwire を実行したディレクトリに databases/tw.db_orion が作成される(orion の部分はホスト名がはいる)。 これを /MO/tripwire/var に移動しておく。
#cd /MO/tripwire/bin #tripwire -v -initialize #mv databases/tw.db_orion /MO/tripwire/var
以上が終了したら、一旦 MO ディスクを抜き、書き込み禁止にしておく。 そしてマルチユーザーモードに戻す。 リブートしてしまう。
#cd / #umount /MO #sync; sync; shutdown -r now
とりあえず検証してみる。Read-only でマウントし /MO/tripwire/bin/tripwire を実行する。
#mount -t ext2 -r /dev/sdb /MO #/MO/tripwire/bin/tripwire
一応何も変更は検出されないはず。 と思ったら、いくつか追加されたファイルと変更されたファイルが検出。 モジュールの依存関係ファイルやら何やら。 これらのファイルはおいおい設定でチェックしないようにしなければ。
今後は cron 等で定期的にチェックするようにする設定を行う必要がある。 今日はもう遅いのでやめ。
なお本来は、tripwire のインストール場所、ファイルの位置などはできるだけわかりにくいようにする必要がある。 公開などしてはいけない(ここであくまでも例で、具体的な位置は異なっている)。
先日とってきておいた Perl 用字句解析生成モジュール Parse::Lex (ParseLex-2.05.tar.gz) をインストール。
$tar zxvf ParseLex-2.05.tar.gz $cd ParseLex-2.05 $more README $perl Makefile.PL $make $make test $su #make install
ベータ版とはなっているが、十分使えそうだ。 使えるものは使おう。 とはいっても、目的は自前の生成系が欲しいということなので(全然使えるものを使っていない?)、これを1段目の生成系とすることにしよう。
Parse::Lex は仕様記述をメソッドのパラメータへ渡すタイプのものである。 仕様記述ファイルから読み込むものではないので、(f)lex ライクなものでもとりあえず作ってみるか(これも既にどこかにあったりして……)。
東京だと「左側は立ちで、右側は歩き」という暗黙のルールがある。 あのルールはどうやって決まったのだろう。 自然発生的に形成されたのだろうか?
誰も右側を歩く人がいないのに、普通にエスカレータに乗る人(左側に乗る人)が溢れて待ち行列が発生していると何とも納得のいかない気分になるのは私だけではないだろうな。
左上が薄くなっているので、たまに「ディスプレイが逝ったか?」と思ってしまう。
nDiki では、たつを氏が公開しているくっつき BBSを利用してコメント機能をつけている。 くっつき BBSは自前でBBS機能を実装しなくても、JavaScript Include を使うことでコメントをページに貼りつけられるという優れもの。
nDiki では JavaScript Include する際、コメントがない(=JavaScriptファイルがない)場合でも404にならないようにCGI プログラム経由で貼りつけていた。 しかし、この方法だと1ページに多くのコメント領域があると何度もCGI プログラムが実行されるのでサーバへ負荷がかかる。
また Web ブラウザもHTMLの途中でscript要素が出てくると、そのスクリプトファイルを読み込んで処理するまで残りをレンダリングできない。 このためサーバが重かったりして、途中スクリプトファイルの読み込みでひっかかるとユーザ側でのページ表示完了が遅くなってしまう。
ということでこの方式をやめて、単純にコメントJavaScriptファイルのURIを指定するようにした。 その使わなくなったCGI プログラムで、tDiaryテーマ用の「commentshortクラスdiv要素」を書き出していたので、この部分は DiKicker に戻す。 現在のコードでは、コメントが無くてもこのdiv要素が出力されてしまうので、ちょっとみぐるしいがしばらくご容赦。
コメント内の AutomaticLink 処理や cookie の連動など、前からやりたいとは思っていたのでこれを機会に実装するかな。 いろいろ決めないといかん。
パスワードを含むアカウント情報などは今のところ、テキストファイルに書いて GnuPG で暗号化して記録している。 ……のはずなのだが、面倒なので GnuPG かけてないファイルも結構あったりして実はまずい。
Emacs で EasyPG を使うと gpg 拡張子を持ったファイルは自動的に暗号化/復号化してくれるようになって便利らしい。
例えば example.gpg という名前で新しいバッファを作りテキストを入力する。 ここで保存しようとすると暗号化する相手の鍵の選択画面が出る。自分の鍵で復号できればよいのでそのまま [OK] を選ぶ。 そうすると暗号化して保存してくれる。
逆に .gpg で終わるファイルを開くとパスフレーズの入力が求めらる。 正しく入力すると復号化されたテキストがバッファに表示される。 再編集して保存する場合も先と同様に暗号化の手順が出るので、また暗号化した状態で保存することができる。
easypg-0.0.9-1 Debian パッケージをインストールして使ってみた。 便利便利。
ただ emacs-snapshot 20070122-1 (22.0.92.1) だと暗号化の際 coding の処理が正しくされないのか日本語を含んでいると文字化けしたテキストが暗号化されてしまい、復号化してももはや読むことができない。 ということで、ここしばらく Emacs 22 を使っていたのだけれど、Emacs 21 に戻すことにした。
こちらでは問題なく動作。
仕事であるサーバへアクセスするのに、 SSH の公開鍵を送るように頼まれた。 そういえば今までずっと同じ鍵を使い続けていたけれど、いちおうこういのは管理上分けておいた方がいいかもしれない。
ということでかなり久しぶりに鍵を作成。5年ぶりぐらい?
ssh-keygen -C <メールアドレス> -f id_rsa.hogehoge
手元のいくつかのサーバも新しい鍵を使えるように authorized_keys に追加しておく。 ssh-copy-id コマンドというものを今回初めてしった。 リモートホスト上の ~/.ssh/authorized_keys に、ローカルホストから直接公開鍵を追加することができる。こんな便利なものがあったとは。
ssh-copy-id -i ~/.ssh/id_rsa.hogehoge naney@サーバ名
デフォルトとは異なる新しい名前で作ったこの鍵もリモートホストへの接続に使えるようにするため、ローカルの ~/.ssh/config に設定を追加しておく。
IdentityFile ~/.ssh/id_rsa.hogehoge
それと ~/.profile の中で呼んでいる keychain の引数にも ~/.ssh/id_rsa.hogehoge を追加。
昨日の 18:00 から今朝の 6:00 まで、www.naney.org のホスティングサーバがメンテナンス作業で停止したのだが、その後もメールサーバは復旧せず。 ストレージのハードウェア障害が発生したらしい。
連続運用しているサーバって止めると立ち上がらなくなるってありがちだからなあ。
とはいえ12時間のメンテナンスだけでもかなり長いというのに、その後のトラブルで1日以上メールが止まるってホスティングサービスとしてはちょっとお粗末だよ。 ガンバレ。
Facebook での共有範囲って基本的には
という区分になっているので「友達か否か」が超重要。特定の人とだけ共有とか、特定の人には非表示とかも個別にできるようなんだけれど、それは管理的にもカンベン。
Android だと Facebook の連絡先を同期して直接表示できるので携帯電話番号なんかを知人と共有できるとすごく便利。 ただ携帯電話番号や住所を友達と共有する設定にしてしまうと今度は「ネット上で交流があって Facebook 上でもコミュニケーションしたい」ようなユーザーと Facebook で友達になるのに躊躇してしまう(うーん、まだ住所まで教えるほどでは)。
うまく共有をコントロールできるといいんだけどなあと思って確認したら、「友達リスト(friend list)」で共有する範囲を細かく指定できるじゃない。 これだよこれ。
にアクセスして [リストを作成] からリストを作る。「プライベート」とか「ビジネス」とかいうロール別にリストを作ってもいいんだけれど、自分は「電話OK」とか「住所OK」とか権限別にリストを作った。数が多くないならこの方がシンプルで間違えにくい。
なお友達は複数の友達リストに所属させられる。
で次に友達リスト単位で共有を指定する。
から[設定をカスタマイズ]へ。
で例えば携帯電話番号を特定の友達リストに登録されている人とだけ共有したい場合は [携帯電話番号]のところのリストから[カスタマイズ]を選ぶ。
そこで[対象者]で[特定の人]を選んで、下の入力欄に友達リスト名(例えば「電話OK」とか)を入力する。最初の何文字かを入力すると友達リスト名が候補として表示されるので、それを選択してもよい。
これでOK。Facebook で友達になってもいきなり携帯電話番号が共有されちゃうことはない。 共有したいレベルに応じて友達リストにゆっくり追加していけばよい。
Facebook よくできてるね。いいね!
男なんだろ? ぐずぐずするなよ 胸のエンジンに 火をつけろ おれはここだぜ ひと足お先 光の速さで あしたへ ダッシュさ
宇宙刑事ギャバン カッコイイ! 主題歌は今でも自分を鼓舞する時のテーマソングですよ。
なので以前からオフィスにギャバングッズを飾っておきたいと思ったのだけれど手頃なのが無かった。で今回の映画化を受けて何かグッズが出るかなとチェックしたら、ありましたよソフビ。いわゆる大人向けのフィギュアみたいに高額ではないのでさらっと買える金額で。やったー。
ということで早速購入。ディテールもなかなか良くできていて満足。
何かを先送りしたくなったら君のことを見るよ。「男なんだろ? ぐずぐずするなよ」
[ 製品レポート ]
IRC でトークをもらったり名前を呼ばれた時や、その他何かのイベント発生のタイミングで、Android 端末で通知を受けたいなと思って Notify My Android (NMA)を入れてみた。
対抗馬としては Pushover があるんだけれど NMA の方が
という点でいい感じ。
Web サイトでアカウント登録し、端末にアプリをインストールしてユーザ名とパスワードを設定。で Web サイトのフォームを使ってテスト通知したところ、すぐに通知が届いた。日本語も OK。ということで問題無さそうなのでアプリ上からプレミアムアカウントにアップグレードした。387円。
あとは Web サイトで API key を発行すれば HTTP POST メソッド1発で Android 端末に通知を送ることができる。
curl --data-ascii "apikey=発行した API key" \ --data-ascii "application=curl" \ --data-ascii "event=testevent" \ --data-ascii "description=testdescription" \ https://www.notifymyandroid.com/publicapi/notify
API key ごとにメールアドレスが設定されるのでそこにメールを送る形で通知することもできる。IFTTT あたりから通知させるならメールを送れば良いね。
IRC からは適当にスクリプト書いて LimeChat 2 から通知してもいいし、Growl for Windows の Notify My Android Forwarder Plugin を経由して送ってもいいかな。NMA のサイトを経由するので、見られると困るようなものは詳細は送らずに定型文のみ送るようにすると良いだろう。
お手軽に通知できるようになるのでいいね。
[ Android アプリレビュー ]
昨日ホーマック(ホームセンター)に行ったついでにマルシンの「スーパークリーナー万能Jrくん」を買ってきて、昨日と今日とでキッチンのシンクと風呂の鏡と握りバーの掃除に使ってみたところピカピカになって感激した。
今のキッチンはシンクにクレンザーとか研磨剤入りのもの使いたくないなあと思って、デイリーのお手入れだけして1年以上経ったんだけれど汚れが落ちなくてだんだん汚なくなってなってきてしまっていた。でコンポーネントキッチンの取扱説明書をみたらこれがおすすめ便利グッズとして掲載されていたので買ってみたと。ちなみにシステムバスルームの取り扱い説明書にもこれが紹介されていたので、それなら違いないと思ったわけ(しかし実はキッチンはサンウエーブ → LIXIL で、バスルームは INAX → LIXIL であれっと)。
感じとしては靴クリームのような感じ。スポンジか布につけて綺麗にしたい面に塗り、汚れが浮いてきたら擦って汚れを落とす。
シンクのずっと落ちなかった汚れは何回か繰り返すことですっきり落ちてピカピカになった。
しばらくサボっていたレンジフードの掃除にも使ってみたけれど、固まった油汚れも万能Jrくんをつけてちょっと待つと取れるようになる。仕上げに水洗い不要なので助かる。ただ、つける・ちょっと待つ・こすって落ちなかったらもうちょっとつけて繰り返すというのレンジフードだとちょっと大変なのでこれは別の洗剤の方が良いかも。
風呂は鏡と握りバー(シャワーのスライドフックがついている棒)の掃除に使ってみた。鏡のウロコ取りというと研磨剤系が多くて躊躇するのだけれど、万能Jrくんは研磨剤が入っていないのでその点は安心できる。こちらもほぼ綺麗になった。ただ1回では落ちなくて何回も繰り返しつけてはスポンジでこするのを繰り返した。まだちょっと残っているので以降は定期的に掃除する時に使って落とそうと思う。
あと金属の握り棒についていた、お風呂洗剤やメラミンフォームでは落ちなかった水垢も結構落ちてピカピカになった。これは嬉しい。
そもそもあのバー、シャワーフック用のだと思ったのだけれど取扱説明書をみたら浴槽に入るときの握りバーだったという方が驚きであった。握りバーなんだ。握りバー。
[ 製品レポート ]
「人を動かすには、相手が求める何かを提供し、こちらのほしいものと価値の交換をする」 p.17
人間関係にはレシプロシティ(互恵性)があるので、人を動かしたかったらその人の世界を理解しカレンシー(通貨)を把握・理解してまず提供し、そのかわりにこちらの望む行動をしてもらいましょうという話。特に組織における人間関係と影響力について考察した本。
大きな異論はないのだけれ説明がくどい感じはした。またちょっと戦術的すぎて打算的な印象が強いので感情的にすんなりはいってこないというのはあった。結構前に買ったのだけれどなかなか読み進まなかったのはそういうところにあるのだと思う。
ただ影響力の法則の1番目が
であったのは良いかなと思った。味方になるという意識は良いと思う(ただ本書においては「利害のために手を結ぶのだ」(p.22)とあるので、あくまでもドライだ)。 また人の行動を左右しているのは性格だけではなく、(評価・報酬などを含む)その人を取り巻く環境がありこれらの力もかなり強いというのはあらためてなるほどと思った。
ドライな感じはあるものの組織で人を動かして成果を出していくにはこういうのも理解しておいて間違いはないよねという1冊。
[ 読書ノート ]
とうとう Instagram アカウントを作成しました。
iOS 版から遅れて Android (2.2 以降) 用の Instagram アプリがリリースされたのが2012年4月3日。しかしながら当時使っていた Xperia SO-01B は Android 2.1 だったので使えず出遅れたこともあって使わずじまい。
撮った写真の共有先も Flickr + Twitter、mixi、Facebook がありましたし、フィルタ加工してエセオシャレ写真にする欲求も無かったので、あえて Instagram を使う理由もあまりありませんでした。
まあそうはいっても使った経験が無いというのもいかがなものかということでようやく使ってみることに。
当然ユーザーネーム naney (Naney) はもう取れないのでテンションはちょっと低めです。
Android アプリからメールアドレスを入力してアカウント作成を始めたのですが、名前・ユーザーネーム・パスワードを入力して「次へ」をタップしても画面が切り替わらず先へ進めません。エラー表示も無し。何回もチャレンジしたあと、もしかしてと思って Wi-Fi を切って LTE 回線にしたら先に進めました。なんでしょう。たまたまこちらの回線の問題だったのでしょうか、それともアカウント大量作成対策にはまってしまったのでしょうか。私も仕事で不正利用対策に取り組んでいるので、そういう可能性もあるのかなと考えてしまいました。
とりあえず誰もフォローしていないので全く面白くありません。ぼちぼち使っていくことにします。
Remember The Milk で予測時間を入力するための時間計測をするのに Task Coach を久しぶりに使ってみました。
Toggl を使えば Remember The Milk と連動してタイムトラッキングできるのですが、きっちり記録したい訳ではなくて繰り返しタスクの平均所要時間がわかればいいかなぐらいだったので、ローカルで実行できてデータ管理手間なしの Task Coach を使おうかなと。ただやはりタスクの入力が面倒。すぐ飽きました。 Task Coach でタスク管理自体をしているのでなければ無理。
普通にストップウォッチで時間を測って Remember The Milk タスクのノートにメモするぐらいで十分そう。
そろそろ花粉症の季節が始まるので花粉症の薬をもらいに病院へ行ってきました。ここ2年は尿路結石を診てもらっていたこともあり内科・泌尿器科の病院で薬を出してもらっていたのですが、今年は例年通りかかりつけ医で。
予定より早く病院が終わりましたが定時に間に合うほどではなかったので TSUTAYA SHIBUYA に寄り道。それから渋谷ストリーム方面の出口 16b のアーバン・コアも初めて通ってみました。小綺麗だけれどただの通路でした。
交換となった MICKE/ミッケ 引き出しユニット キャスター付きが本日配送されてきた。今日の配送の人は愛想の良い型で、みんなに挨拶していってくれた。その人曰く「IKEA さんはよくあるんですよね。」って言ってた。
今回は段ボール箱開梱開始から1時間30分で完成。これも上から3段目だけストンと引き込まれないが、ちょっと滑りが悪い程度で開閉が難しというレベルではないので、許容範囲かな。
これにて MICKE 一段落。
東京野菜#トイデジ #デジタルハリネズミ pic.twitter.com/IrDDQ6aSEE
— Naney (@Naney) January 26, 2019
エコポイントの基準に合わせて REGZA 37Z1 の省エネ性能を変更したのが REGZA 37Z1S。省エネ性能以外は同じ。
妻から「掃除機ついに壊れた」と LINE メッセージが届いた。2009年12月に購入したもので11年経過。まずまずよく動いてくれたな(その前の掃除機は17〜18年ぐらい使った)。
自走式ヘッドの紙パック式キャニスター型掃除機で絞り込むと東芝 VC-PH9 とパナソニック MC-PK21G が候補に残った。人気があるのはパナソニックの方のようだ。
比べるとパナソニックの方が「うるさめだが吸込仕事率が高い」「ヘッドがコンパクト」で、東芝の方は「本体がコンパクトで収納時のパイプ全長が短く収納時にスペースをとらない」という感じ。パイプを外して掃除する時に東芝の輪になっているグリップは邪魔ではと思ったが、店頭で触って見た感じ懸念したほど大きなグリップではなかった。実際に見比べると東芝の方が圧倒的に小さく感じた。
コンパクトさ優先で VC-PH9 に決定。壊れた日に即日に選定して夜に注文、明日には配送予定。
[ 家電 ]
What Is the PESO Model? によれば、 Gini Dietrich 氏の Spin Sucks: Communication and Reputation Management in the Digital Age が出版された2014年に PESO model が正式に世に送り出された。
の4種類のメディアで考える。
[ マーケティング ]
おは。#photography pic.twitter.com/29Qg90JxAa
— Naney (@Naney) January 26, 2021
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。