過去の2月17日より。
納品の日。 今年に入ってから各スタッフに割り込みが多発したりして、かなりシンドい状況ではあったが皆がんばった。
やはり年度末は、いろいろ仕事が集中する。 この時期は作業が飛び込んでくるのを想定して、かなりゆとりを持った計画にすべきのようだ。 もっとも、その前の期間は期間でやることがあって前倒しもなかなか難しい。 ここら辺で一発、よりよい体制にシフトするようにせねばなぁ。 ……って3月末までは、まだまだ目白押しだったっけ。
都合によってCVS リポジトリにアクセスできないところにいるチームメンバから、変更した作業ファイルを送ってもらった。
さて。
どうするか。
ファイルに $Id$ などが含まれていてどのリビジョンに対して変更したのかが簡単にわかるものは diff をとって patch をあてるか。 自分の作業ディレクトリとは別にもう一つ作業ディレクトリをチェックアウトして、そこに変更されている作業ファイルを上書きコピー。
cvs diff -r リビジョン -au ファイル名 | patch /path/to/my/working/dir/ファイル名
で自分の作業ファイルにマージ。
とりあえず HEAD と diff してみて問題なさそうならそのままマージ。
やっぱりリビジョン番号を埋め込んでおいた方が便利やね。
社内サーバ上の Subversion リポジトリを気軽に閲覧できるように、以前から試そうと思っていた SVN::Web をインストールしてみる。
しかし Subversion の Perl バインディングである SVN::Core は、Subversion パッケージに同梱されていて独立していないのか。 Subversion は Red Hat Linux 8.0 へ RPM パッケージで入れているのだが、SVN::Web の方は /usr/local/perl-5.8.8 以下にインストールした Perl 5.8.8 上へ入れようと思っていたので、はたと困る。
--with-perl5=/usr/local/perl-5.8.8/bin/perl
で configure して、Perl モジュールだけインストールしてみたけれどうまく動かず。
素直に Red Hat Linux 8.0 に標準で入っている Perl 5.8.0 に入れるかなぁ。
昼休みに会長がぶらりと立ち寄った。 入社以来、お会いするのは初めてである。
その後、南極だか北極だかの話をして帰っていったようだ。
年末に割れて年始に修理依頼をしていた便座の調達がようやくできたと、業者から昨日連絡があった。先週「1度見にきてもらって以来、音沙汰がないのでそろそろ再度電話してみるか。」と思った矢先に「あと1週間ほどで部品が届きそうです。」という連絡があり、「そろそろ1週間立つんだけれど……」と思った矢先に「届きました。伺います。」と連絡がくる絶妙なじらし加減。
入居時に設置してあったのは東芝設備機器製だったのだが製造をやめてしまったとのことで、その辺りで手配に手間取ったらしい。
新しくきたのは TOTO ウォームレット S2。 以前のものに比べ本体部分がかなりコンパクトになり、便器と便座のサイズもぴったりあうようになっていい感じだ。 感じの良さそうな業者の人が、あちこちに頭をぶつけながら取り付けていってくれた。
これでようやく座りションベンともおさらば。
階層社会では、すべての人は昇進を重ね、おのおのの無能レベルに到達する。- ピーターの法則
読んでいると嫌な気分になれる本である。 そしてこれを読んでしまうと、上司や政治家やその他みんなを無能か否かという目で見がちになってしまう。
今の仕事で優れた能力を発揮している人は昇進の対象となり、昇進し、そのポジションでも優れた能力を発揮できればまた昇進、そうでなければそのポジションで無能としてどとまるというのはもっともらしい。 ただ実際のところ、能力以外の他の要因で昇進できなかったり、組織を移ってまた階層の下に移るなどで、順調に無能レベルに到達できない方が多いのではないだろうか。
それと本書では事例らしきものが沢山でてきて理解を助けてくれるのだが、どれがそのまんま実話でどれが仮名にした実話でどれが創作なのかが明確に区別できないのがもったいない。 それゆえ、主張が怪しく思えてきてしまうことがある。
それと最後の章の「無能につけるピータの特効薬」が失速気味なのが残念だ。 「もしかしたら最後に光明となるなにかが述べられるのか、それとも悲観論で終わるのか」ドキドキしながら読み進めたのだが、最後はなんか処世術がきて、人類についての漠然とした話がきてオシマイ。「アレアレ?」という読後感。
ただこうついこう否定的な書評になってしまうのは、本書の主張に自分が何とか反論したい、そうではないと言い聞かせたいからなのかもしれない。 どちらにしても組織の中で生きる以上、一読しておくべき1冊であることは確かだ。
[ 読書ノート ]
昨年から会社内で「Google Apps でカレンダー共有したい」という声があって、計算機管理者として頭にはあったんだけれど「メールがどうなるの?」「今までの Google ドキュメント上のドキュメントはどうなるの?」などがクリアでないので二の足を踏んでいた。
今のメールアドレスを Google Apps の Gmail に移行させると
といった問題が出る。 ということで、Google Apps は今のドメイン (ここでは example.com としておく)に apps サブドメインを作って apps.example.com としてそこで社内向けサービスとして使うことにした。
申し込みページから、ドメイン名の指定 (apps.exemple.com)・管理者の入力・管理者アカウントの作成を実行。 これで管理画面に入れるようになる。 そこでドメイン所有権の確認の指示にしたがって
googleffffffffxxxxxxxx(確認用の名前).apps IN CNAME google.com.
を example.com の BIND のゾーンファイルに追加。
ヘッダ用のロゴもばっちり設定。
各サービスごとに CNAME を設定する。
管理画面の指示に従ってゾーンファイルに以下を追加。
mail.apps IN CNAME ghs.google.com. calendar.apps IN CNAME ghs.google.com. docs.apps IN CNAME ghs.google.com. sites.apps IN CNAME ghs.google.com.
これで http://calendar.apps.example.com/ などで各サービスに入れるようになる。結局すぐにリダイレクトされてしまうから絶対必要ではないけれど、設定しておいた方が格好いい。
メールは今まで通りレンタルサーバで運用するので、Gmail はいいかなと思ったがサブアドレスとして使えるように一応設定しておいた。
管理画面の指示に従ってゾーンファイルに以下を追加。
apps IN MX 10 ASPMX.L.GOOGLE.COM. apps IN MX 20 ALT1.ASPMX.L.GOOGLE.COM. apps IN MX 20 ALT2.ASPMX.L.GOOGLE.COM. apps IN MX 30 ASPMX2.GOOGLEMAIL.COM. apps IN MX 30 ASPMX3.GOOGLEMAIL.COM. apps IN MX 30 ASPMX4.GOOGLEMAIL.COM. apps IN MX 30 ASPMX5.GOOGLEMAIL.COM.
これで username@apps.example.com 宛のメールは Google Apps の Gmail に届くようになる。
あとはまずは自分のユーザアカウントとテスト用のアカウントを作って、Google Apps の機能、特に共有関連についてチェック。 ここら辺の作業までで最初の申し込みフォームの入力始めから4時間ぐらい。 BIND は自社サーバ上にあるのですぐに反映させられたので、そのあたりの待ち時間が必要なかったのでその点は楽であった。
基本は Google アカウントで提供されている機能とたいして変わらないな。Standard Edition だからかもしれないが、思ったほどドメイン内のユーザ間での共有や管理者からの一括管理機能ってなくて拍子抜け。 Google カレンダーも基本はユーザ間で共有をかけていくみたいだし。
新しくドメインを用意してユーザ管理していくには Google Apps 導入は効果的そう。 逆に既に別にメールアドレスがあって、しかも皆個別に Google アカウント使って活用とかし始めちゃっていたりすると、また別に Google Apps アカウント作るから使ってねっていってもメリットを感じてもらえないと使われなくなりそう。
Google ドキュメントなんかは、個人で個別に発行した Google アカウント上にあるのが気持ち悪かったので、Google Apps 上にもってきてそこでドメイン内で共有していけるようになるというのは嬉しい。 それと Google Apps の Google サイトに Google ドキュメントを貼りつけることができるので、ドメイン内での情報共有に使えそう。Google ドキュメント上の共有だけだと、ナビゲーション的にどれがどのドキュメントかわからなくなって埋もれてしまいそうだったので、プロジェクト別に Google サイトを作れば良さそうだ。
しかしこれから Google Apps を活用していくにはガイドラインを作る必要あり。 スケジュールの共有は Google Apps 上でこのようにしてねとか、Google ドキュメントは個別 Google アカウント上ではなくて Google Apps 上で作るべしとか。
まずは何人かにモニター利用してもらって「これって便利」探しをしてみよう。
2010年、2011年といって、去年は休んで、今年またいってみた。
一昨年10:00時過ぎに行った時はきなこ棒配ってたので期待していったんだけれど、今回は配ってなかったのでその事には一言も触れずに帰ってきた(10:00)。
14:00 にもう一度行ったら獅子舞が舞ってお金食べてた。
今シーズン、東京としては2度も大雪が降っていて、なんでも今度の水木曜日はそれを超す大雪の可能性もあるらしい。
先週の金曜日に降った雪はその前のに比べて翌日にビシャビシャになった。その日は1日家にいたのだけれどもし外出していたらきっと靴ぐしょぐしょになること必至だった。やはり長靴を持ってないと困るなぁ。以前台風の時に通勤でぐしょぐしょになって厳しい思いをしたこともあるし。
ということでカジュアルに履けそうなのをと思ったのだけれど探すの難易度が高い。とりあえず思い浮かんだ crocs に、洒落た感じのがあるのでそれはどうかなと。
会社の近くの crocs 青山店に行けば見られるだろうと思っていたのだけれど、朝 Web サイトを見たら2013年11月30日に閉店していた。むむむ。他に近いところだと、crocs 恵比寿三越店かなと思ったら今日は定休日だった。むむむ。ということで帰りに crocs アトレ大井町店に寄ってみたんだけれど、直営店なのにそれほど品揃えがなくてここでは実物見られなかった。むむむ。残念。キツいという評なので、実際に履いてみて検討してみたいんだよね。
ついでに近くのイトーヨーカドーで(crocs によらず)長靴見ようと思ったのだけれど、これまた見当たらない。長靴どこへいってしまったんや。雪かきスコップと一緒に買われてしまったんか。
今日は雪の予報だったので、もし雪が降ったら写真に場所と気温も入れたいなと思って Android アプリの InstaWeather をインストールしたみた。フォローしている Twitter-er でこのアプリを使った写真を投稿している人がいてデザインがいいなと思っていたので自分も使ってみることにした。
フリー版を入れてまずまず良さそげだったので、「ロゴ透かし」や(決め打ちの)「タイムスタンプ」をオフにしたり高解像度(1920x1920)を選べたりする InstaWeather PRO を購入。
気象データは位置情報をもとに wunderground.com から取ってきてくれる。場所名は Facebook か Foursquare の情報を使って出てくる候補から選んだり(検索も可能)、あるいは手で入力したものを使うことができる。
写真は InstaWeather PRO でも撮れるんだけれど、自分は静かに撮りたい時は「カメラ ICS+」を使い、また露出補正等含めきっちり撮りたい時は「Camera FV-5」を使って撮影して、インテントで InstaWeather PRO に渡すことにした。
また気象情報のスキンを被せてできた写真は同じものを「保存」と「mixi と Flickr の2つへの投稿/アップロード」とをしたいので、今はいったん ES ファイルエクスプローラに対してシェアをすることで保存し、その後 QuickPic アプリで開いて mixi アプリと Flickr アプリにそれぞれインテントで送って投稿/アップロードするようにしてみている。
Foursquare はリーダーになれる訳でもなくなってチェックインするメリットが自分的には減ってきているので、記録的としてはこういう形の方が面白いかも。
[ Android アプリレビュー ]
iPhone 5c 用の無音カメラを何にしようかなと調べたところ OneCam か StageCameraProが良さそうでした。どちらにしようかしばらく迷って、よし OneCam にしようと思って App Store を開いたら既に購入済みでした。あれ。そういえば以前 iPod touch 5th 用に買ってみたのでした。確か iPod touch 5th だと低い解像度しか選べなかったのでその時は使わずじまいだったのでした。
それからファイルベースでの管理のアウトライン(OmniOutliner) やマインドマップ(iThoughtsX)はやっぱり Evernote ノートにタイトルやメモを書いた上で添付して保存しておくのがいいかなと。Evernote から直接添付したファイルを OmniOutliner や iThoughtsX で開いて編集し Evernote ノートに自動反映といったこともできますし。スマートフォンで参照・編集することのないものはこれで良さそう。
ちなみに OmniOutliner 3 形式 .oo3 だと Evernote ノートに添付する時に ZIP でまとめられてしまって直接開けなくなるので OPML で扱うのが便利です。
今年は「人工知能とは」「機械学習とは」を繰り返し聞きました。
グーグル株式会社 佐藤一憲(@kazunori_279)氏
わかりやすくわくわくする発表でした。簡単に出来ちゃうと感じさせるトークでしたが、製品に適用していくには泥臭いトライアンドエラーとリリース後の保守が待っているのだなあというのも想像しながら聞いてました。
ハードウェアの話を聞いていると、もはや超大手の手のひらの上で学習させていくしかないのかなーと感じさせられちゃいます。
株式会社ジャストシステム 宮崎哲哉(@miya2tetsu)氏 大島教雄氏 岡美香氏
自社製品の訴求セッション。デブサミじゃなくてもという感じではありました。
ソニーデジタルネットワークアプリケーションズ株式会社 吉田万里子氏
エンジニアとしての思いと親としての思いを叶えるためにラズパイで遊んでみるという話。子供の成長についていろいろ考えていらっしゃって素敵だなと感じました。
後半にだんだん技術的に具体的な話にきちんともっていく構成も上手いなと。
グロースエクスパートナーズ株式会社 関満徳(@fullvirtue)氏
プロダクトバックログアイテムを準備完了にしていくためのサイクルやタスクをどうするかなと思っていたので参考になるかもしれないなと思いました。複雑になるので今のチームの状態でやるべきかは見極める必要がありそうですけれど。
日本マイクロソフト株式会社 千代田まどか(@chomado)氏
一つ前のセッションを見終えてからいったらもう満席でした。
TickleCode 代表 小林由憲(@yoshiii514)氏 関西Javaエンジニアの会 阪田浩一(@jyukutyo)氏
勉強会の話。
「運営に関わろう、なければ作ろう」
なりたい人に近づくといいよという話と、貢献しなよという話。
株式会社インターネットイニシアティブ 穴吹健一氏
最後は IIJ のセキュリティビジネスの話に落ち着いて終了。さすが IIJ 的な内容のトークはあまり無かったです。
株式会社ワークスアプリケーションズ 井上誠一郎氏 株式会社ノーチラス・テクノロジーズ 神林飛志 株式会社セゾン情報システムズ 小野和俊氏
お互いにレスペクト感があるなかでの軽快な対談を楽しみました。
Developers Summit 2017 で iPhone SE を使ってメモをとるの、Textforce が重宝した。
結果の共有・フィードバックがあればメンバやチームでも意識ができいろいろ取り組めて良い。
午前中の天気がいいあいだにカメラをもって旧東海道を散歩。目黒川沿いにある荏原神社に立ち寄ると境内にある寒緋桜が花開いていました。区のニュースだと1月下旬には満開だったようです。
旧東海道をもう少し北に進むと、美味しそうなどら焼きが以前テレビで紹介されているのを見て一度来てみたかった「一福桃」。土産に帰って午後のお茶の時間にいただきました。手作りらしいちょっと雑な形でしたが、手焼きの生地は柔らかくてまた食べたくなる美味しさでした。買った時はまだ温かく、すぐ食べていたらもっと美味しかったのでしょうね。今度は店内のカフェで食べてみたい。
[ 撮り歩き ]
記事を書くのに調べたことを出典として保存しておきたいことがある。ノートはできるだけテキストファイルにするようにしているのだけれど、さすがに Web クリッピングをテキストファイルにというのは非現実的だ。
そうするとやはり今だと Evernote になるのかな。
オフィスのデスクで Pixel 4 を急速充電するのに MacBook Pro の電源アダプタを外して使っているが毎回だと不便なので Pixel 4 付属の 18 W USB-C 電源アダプターをオフィスに持っていっておいておくことにした。家では去年旅行前に買った RAVPower のを使うことにする。USB Type-C ケーブルは定番の Anker のを購入。最大3A /60W まで対応の。
Obsidian Publish したノートにアクセスした時の表示が速くて驚いている。
これはいいと Google Chrome のホームボタンで表示するページ用に Obsidian のノートを2日前に作成し設定した。いい感じなのでさらに Google Chrome で新しいタブを開いた時にも表示しちゃおう。
Chrome 拡張機能 New Tab Redirect を入れて Obsidian Publish したノートの URL を設定。
最近の関心事をブラウズするための内部リンクだったり、よくアクセスするためのリンクを書いておくとなかなか便利だ。
[ スタートページ ]
新型コロナウイルスワクチン接種券が今日届いたので早速予約。予約争奪戦だった去年7月の1・2回目と違い、ゆったり日時を選びながら手続きできた。
ファイザー社製ワクチンの接種を受けられる予約枠がほとんど無かったので、今回はモデルナ社製ワクチンを選択。
平日に接種を受けてから出社することにした。
一昨日の女子シングル ショートプログラムに続き、女子シングル フリースケーティングを観戦。
坂本花織選手がロシア選手との圧倒的な技術差がある中で演技の完成度を上げることで銅メダルを獲得したというの、いろいろ励みになるな。
zebra#photography
— Naney (@Naney) February 16, 2022
RICOH GR IIIx #GR #GRIIIx #GR3x pic.twitter.com/KeB6DfoHrw
Slack のスレッドで長くやりとりを続けたくなったら良くない状態と思った方がいい。
スレッドはスレッドに関わっていないメンバがやりとりに気付きにくい。長くやりとりを続けるほど重要な内容であれば、チャンネルメンバが状況を把握できるようにチャンネルでやりとした方が良い。チャンネルメンバが状況を把握する必要がないのであれば、そもそもそのチャンネル向きのやりとりではない。
Slack のスレッドは案件管理の場ではない。案件管理には課題管理システムなどのツールを使おう。
[ opinion ]
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。