社内であったFlexの勉強会 ? 的なやつの内容をまとめてみる
大分前に、社内でかなり初歩レベルではありますが Adobe Flex の勉強をチームの何人かの人としました。その時にとったメモをブログのネタに使おうというのがこの記事です (おい
自分自身の Flex との関わりについては、 Flex の既存のコードを個人的に改造したりという程度はやっています。ただ仕事で使ったことはないです。
前置きはここまでにして以下メモ。基本箇条書き…
- mx:Spacer でコントロール間のすきまとか調整できるよ
- ポップアップの背景のスタイルをセットできて、黒くすると後ろのものが見えなくなる。ログイン画面で使える
- Dynamic Event は Event と違いパラメータを渡せる
- 解説役の方は mxml は全て手書きとのこと。あとから mxml ソースをいじることになるので最初から手書きする。
- 解説役の方のイベントハンドラの命名方法は on + イベント名。ResultEvent.RESULT -> onResult
- (ResultEventインスタンス).result にとってきた値が入っている
- ポップアップからメインの mxml のメソッドを実行する時にイベントを使っている。今回は別にメイン画面の参照を取得してメソッド実行してもあまり違いはないけど、そういう参照を持ってたりしたくないときはイベントを使いましょう。
- minWidth や rowHeight について単位はいらないみたい
DataGrid の話
- セルのカスタマイズについて、非フォーカス時は itemRenderer、フォーカス時 (編集モード) は itemEditor を自作する
- itemRenderer とかのコード内では this.data でそのセルの値が取得できる
- itemRenderer とかのコード内で外の mxml の何かを参照したいときは this.outerDocument を使う
- コード内で this.backgroundColor = 0xFFFFFF みたいにして背景色を変えたいときはその前に this.background = true
- dataProvider は ArrayCollection
- データベースの値を編集するような機能の場合、DataGrid 用のデータ以外に少なくとも 1 つはそのデータのコピーが必要。元に戻したり、変更があったところをマークしたりするため。コピー時にイコールを使うと参照を代入することになるので注意
- ComboBox も DataGrid と似ている。ラベル列の指定は labelField
本気でただのメモになりましたが今日はここまで。
東京体育館のプールが1年間閉まるので世田谷のプールに行ってみた
自分は社会人になってから、何か運動をやらないと太るだろうな、ということで水泳を始めました。泳ぎに行っていたのは、東京体育館のプールでした。東京体育館はアクセスがよく、そして都内でも数少ない、屋内で50mコースのあるプールでした。
ところが2012年の4月から、この東京体育館のプールが1年間改修工事のために休館することになりました*1。
それで別のプールを探すことにしたんですが、今まで50mで泳いでいたんだから、25mじゃなくて50で泳ぎたい! という気持ちがあり、個人で使える屋内50mのプールを探しました。そこで世田谷区のプールに目星をつけて、先週末行ってみました。
で結論をいえば「行く価値あり! ただしアクセスがやっぱり微妙すぎるので東京体育館が再開するまで!」です。というか、自分は他に選択肢がないのでこの結論意以外ないんですが…汗
ではこっからは具体的に東京体育館と世田谷のプールを比較してみます。
1. アクセス
| 世田谷 | 東京体育館 | |
|---|---|---|
| 最寄り駅 | 小田急線 祖師ヶ谷大蔵駅 | 総武線 千駄ヶ谷駅 |
| 新宿から最寄り駅まで | 21分 210円 | 3分 130円 |
| それぞれの最寄り駅から | 徒歩20分 1.6km | 徒歩3分 260m |
東京体育館のアクセスのよさがよく分かるデータです。世田谷の方はマンションと家の並ぶ道をひたすら歩く感じで、歩道が細いところもあり、天候がものすごく悪い日は行くのをあきらめた方がよさそうです。
2. 料金
| 世田谷 | 東京体育館 | |
|---|---|---|
| 料金 (6-9月) | プールのみ2時間 400円 | ジムも使えて2時間30分 600円 |
| 料金 (10-5月) | プールのみ無制限 400円 | ジムも使えて2時間30分 600円 |
これは単純には比較できないんですが、プールしか行かない自分からすれば断然、世田谷の方が安くていいです。しかも夏季以外は時間制限なしなのがすごい。プリペイドカード的なやつは、東京体育館だと5000円で5900円分のやつがあったと思いますが、世田谷は3000円で3300円のが一番高いっぽいです。
3. 設備
これは東京体育館がそもそも改修工事に入るあたりから推して知るべしですが、世田谷の方が圧倒的に綺麗です。世田谷は 50m と 25m プールが同じ空間にあり、かつ真ん中に8人くらいまでは頑張ったら入れるくらいのジャグジーがあります。基本的にガラス張りで開放感があります。ただ東京体育館の足をのばせる風呂も捨てがたいです。ジャグジーよりは広いし。
続いてプールの深さ。
| 世田谷 | 東京体育館 | |
|---|---|---|
| 50mプールの深さ | 1.3 - 1.4m | 1.2 - 2.2m |
世田谷はプールの深さでは東京体育館にはかないません。逆にいえば溺れる心配がないので、あまり泳いだことのない人が練習するにはもってこいかもしれません。
ちなみに注意ですが、世田谷はシャワーにシャンプーを持ち込めません。お湯で洗うだけになります。
4. コースの構成
- 東京体育館
- ウォーキングと25m (あげ底・真ん中で分割)、低速&初心者 (あげ底)、高速×2、中速×2、低速×2 (団体使用時は1)。全コース往復OK。
- 世田谷(土日祝)
- 往復コース×2、片道コース×2、ウォーキング×1、フリー×3 (コースロープなし)
東京体育館に慣れていると、世田谷の方はそもそもターンしちゃだめなコース (片道) があってびっくりします。これ何のためにあるんでしょうね…。あとおもしろいのは間にコースロープのないフリーゾーン。東京体育館の 25m にもこういうコースがあるんですが、50m だと印象が全然違います。これも初心者にうってつけだと思います。どこから泳いでもいいし、人さえいなければななめに泳いでもいいし、歩いてもいいです。3コース分とはいえ実際の印象だとかなり広く見えます。ちなみに長い距離を泳ぐには往復コースということになりますが、2コースのうちどちらが速い、遅いとかはよく分かりませんでした。世田谷は追い越ししてもいいみたいで (東京体育館はだめです)、端の方を泳いどけば速い人がきたときに勝手に追い越ししてくれるっぽかったです。ただ追い越しありのせいでターンのときにたまにカオスになってこわいです。
ターンといえば、世田谷の方は両端の壁の高さが高く、東京体育館のようにへりをいったん持つということができません。自分はこの方法でしかターンできないんで (あのでんぐり返りのやつは鼻に水が入るトラウマが…) 最初世田谷で困りましたが、とりあえず壁に手をあててから体勢を変えて、沈まないうちに壁を蹴れば何とかなります。自分以外にそうしている人もいました。
5. 混雑度
世田谷の圧倒的優位!!! まあアクセスの良さは混雑度と反比例してるんでしょうね。東京体育館の低速だと1コース内に15人くらいいてムカデみたいに並んで泳いでるとか割と普通です。世田谷の方は土曜昼間でかつ雨の日に行ったのもあるでしょうが、1コース内に多くても6人くらいしかいなかった気がします。少ないときは3人程度。余裕で泳げます。
という訳で東京体育館と世田谷を比較してみました。東京体育館プール難民で、かつ世田谷のプールに興味がある人にだけはすごく有益な記事を書けたと思います。どんくらいいんだろそんな人…
『Being Geek』の第 2 部から最後まで
まずお詫びして訂正なんですが、一つ前の記事から取り上げているオライリーの『Being Geek』という本、3 部構成と書きましたが 4 部構成でした。何で今まで気づかなかったんだろうと思いますが、内容が読み物系だし、各章のタイトルもよく分からんと思ってろくに目次を読んでませんでした。
Being Geek ―ギークであり続けるためのキャリア戦略
- 作者: Michael Lopp,夏目大
- 出版社/メーカー: オライリージャパン
- 発売日: 2011/06/25
- メディア: 単行本（ソフトカバー）
- 購入: 8人 クリック: 118回
- この商品を含むブログ (34件) を見る
で前回は第 1 部についてだけ書きましたが、今日はその残りで印象に残ったところをピックアップ。
まず「マネージメント」を扱った第 2 部。10 章の「愚かな上司の作り方」より。
筆者が CEO にある不満を長々と説明したところ、CEO のリアクションが「それで ?」だったそうです。まあなぜこうなったかとか細かい説明は実際に読んでいただくとして、そのまとめを引用します:
CEO の対応には失望したが、結局、悪いのは CEO ではなく自分たちだったことを悟った。ただ、不満を言うばかりで、結局、何が問題で、どうすれば解決するのかを言わなかったからだ。
ただ不満を言うだけではだめ。これは覚えておこうと思いました。
同じ章で気に行ったところを次いでに:
ソフトウェア業界は、「自分で何でもできる」と信じている人たちが集っているところだろう。私は、この業界のそういうところが好きだ。
何でもとは全然いえないけど「色々できるよ」くらいは確かに自分も信じています。
ちょっと戻りますが、 9章「マネージャのマネージメント」ではマネージャを
- 有機的マネージャ
- 機械的マネージャ
の 2 つに分けて、それぞれの特徴を挙げています。すごく大ざっぱにいうと「有機的マネージャ」は感性重視、「機械的マネージャ」は理性重視みたいな感じです。どちらの方がいいという訳ではなくて、両方のバランスがとれてるといいという話です。自分のまわりの人についてもこれを当てはめてみると、マネージメントのやり方がそれぞれ違う訳が分かった気になれます(笑)
また「機械的マネージャ」は報告書を書かせたがる、という話が出てくるのですが、その報告書についての記述も引用:
…… 書けと言われたから仕方なく書くということではよくない。書くのなら積極的に取り組むべきだ。受け身の態度で嫌々やるのは最悪である。
これは報告書に限らない話だと思います。何でもそうですねー耳が痛い。
そしてかなり印象に残っている 21 章「困った人」。社内の誰ともうまが合わない人、会議などでのリアクションが予想できなくて困る人 の話です。
結論を書いてしまうと、困った人は他の人と何が違うかといえば、文化だそうです。「困った人」が何で腹を立てているのか分からないことがありますが、それは自分の文化と会社の文化が違うところに腹を立てているんだそうです。まあ何だか投げやりな気もしますが、こう言われると合点がいきます。
こういう人がいるのは良くないという訳ではなく、またこういう人の存在が会社を発展させる可能性もある、とフォローはしています。ただし最後はこう締めくくられています:
本当に困った人というのは、ただ会社を混乱に陥れるだけではない。 …… ただ、時間や労力を奪われるだけではなく、大きな精神的苦痛ももたらす。もし、その人が本当に害にしかならないことが明らかなら、一刻も早い対処が必要だ。
第 2 部のラストは 22 章「在宅勤務」。筆者は在宅勤務を自分ではしたいと思っていないし、どちらかというと反対しているようで、そのニュアンスで書かれています。
例えが出てきて、会社は池で、社員はその中の魚のようなものと例えられています。在宅社員はその池の外に出た魚で、池の中でさざ波が起こっても、それを知ることはできません。筆者は度々、廊下などで交わされる雑談などにも価値を認めるような書き方をしていて、そういう雑談や噂から得た情報が仕事を左右することもあり得るので、在宅勤務はそれがない分難しい、というのが筆者の意見のようです。
雑談や噂に限らず、社内の人間との情報交換自体たしかに手間がかかるようになって、その辺は問題だなと思います。ただうまく在宅勤務でやっていた人の話も載っていて、その人はたまに会社に出社する時に「さざ波」をできるだけキャッチするようにしていたそうです。
第 3 部はタスク管理やプレゼンについてで、「トリクルリスト」とか「ビット・機能・真実」のモデルとかおもしろいところもあるのですが、そろそろ長いので第 4 部の 37 章「マネージャとコミュニケーション」から引用して終わり:
エンジニアからマネージャになったばかりの人は、何か予想外の困った事態に直面すると、エンジニアに戻ってしまうことが多い。エンジニアだった頃に馴染んでいた方法に戻ってしまうのだ。何もかもを自分一人で解決しようとする。その方が安心できるからだ。ただ、マネージャとなったからには他人を、部下を信頼して任せなくてはならない。
自分の学んできたことを、部下にわかるように翻訳して教えていく必要がある。 そして、学ばせるには、信頼して任せるということが必要だ。以前なら、自分でしていたことを任せてしまうのである。
そんな訳で『Being Geek』読み終わりました。終わり方も素敵な感じですが (40章) そこは敢えて書かずにおしまい。
今さら『Being Geek』
最近、遅ればせながらオライリーの『Being Geek』を読んでいます。日本語版が出てからもうすぐ 1 年が経とうとしてるみたいで、早いもんですね。
Being Geek ―ギークであり続けるためのキャリア戦略
- 作者: Michael Lopp,夏目大
- 出版社/メーカー: オライリージャパン
- 発売日: 2011/06/25
- メディア: 単行本（ソフトカバー）
- 購入: 8人 クリック: 118回
- この商品を含むブログ (34件) を見る
この本は 3 部構成 4 部構成になっていて、最後の第 3 部をまだ読んでいる途中ではあるのですが、ここまで読んだ範囲でも「おもしろいな」と思える内容でした。
第 1 部は「キャリアの形成」「転職」についての話です。
まずなるほどと思ったのは、「どんな些細なことでも、自分がこれをやります (できます) と言ったことを全てこなすように」というアドバイスです。またできないことはちゃんと「ノー」と言いましょう、とも書いてあります。そうしないと、自分の評価は下がってしまうという話です。
当たり前じゃないか、と言われそうですけど、自分は「ナード」である筆者に言われて、初めてあらゆるタスクをちゃんとこなす必要性を感じました。多分普通のノウハウ本を読んでも動かなかった気がします。「ナード」に言われちゃ仕方ないな、って感じでちょっと改心しました。
このことから分かった派生的なノウハウは、自分のようにギークやナードに憧れている人に言うことを聞かせるためには、ギークやナードの言葉を引用すればいい、ということです。「名前重要」ということを教えたければきのこ本を持ってくればいいし、マネージャの人はプログラマに『Being Geek』を読ませればもうちょっと真面目に働くかもしれません。
他になるほどなーと思ったところでは、「会社が嫌いだという理由で転職してもうまくいかないよ」というのは自分も含め結構色んな人にグサっとくる内容じゃないでしょうか。理由は怒りから行動を起こすとまともな判断ができないから、ということみたいです。
あと第 1 部でおもしろいなと思ったところですが、採用の時の面接官を「怒ってる人」「静かな人」「質問しまくる人」みたいな感じで類型化している章があります。この中で誰か影響力が高いのかも書いてあります。
今日のところはここまで。そういえば表紙を見た感じ、ギークといえばスニーカーなんですかね。
何でもいいから数日連続ではてなダイアリーを書く、というのをやっていました
何かのアウトプットの場所としてブログを始めたのは結構前になりますが、やってみるとどうしてもなかなか更新しない日々がほとんどでした。でもそれだとなかなかアウトプットの練習にならないなと思ったので、最近は何でもいいから毎日ブログを書く、というのをやってみています。
ただいきなり毎日はむずかしいかと思って、連続で書く日数を2日から始めて、2日連続で書けたら3日、3日をクリアしたら4日、みたいに段階的に増やしていっています。こうするとゲーム感覚になって、とりくみやすいかなーと思っています。
またこの方法に伴なって、今までは書く度に twitter や Facebook で「書きました」お知らせはしていたのですが、敢えて今はしないようにしています。今は読む人のことを考えて有益な記事を書くというよりは、まず量を書いてみるべきなんじゃないかと思ったためです。読む人のことを考えるとハードルが上がるので、今はひとまず下げている状態です。
でさらに元々は土日も連続で書こうとしたのですが、土日は仕事がなく少なくとも仕事の中で学ぶことがないので書かない、という方針に変えました。
それから、急に飲みとかオールとかが入ったときのために、スペアの文章をあらかじめ作っておく、みたいなのもノウハウとして必要なんだなと思いました。
でこんくらいハードルを下げた結果、5日連続って結局平日は毎日書くことになるのでこの程度であれば毎日書くというのも無理な話ではないということが分かりました。
あとは質を上げられるといいんですが、その辺はまだまだ回数こなさないと & もっと勉強しないとできなさそうです。
リスクアセスメントについて勘違いしてた話
ISMS のリスクアセスメントについて勘違いしてたのでメモ。
こういうページにちゃんと書いてあることですが。。
＠IT：ISMS構築で重要なリスクアセスメントの手法：GMITS-Part3
ISMS では現状のリスクを認識する必要があって、そのために「リスクアセスメント」を行なうんですが、その方法の一つに「詳細リスク分析」というのがあります。(「詳細リスク分析」自体やり方は色々とあると思いますが自分が知っているのは) 情報資産を洗い出した上で、その価値、リスク、脅威、脆弱性を数値化します。それらの値からリスク値というのを算出して、それを元にどういう対策が必要か考える感じです。
で自分はいつの間にか「詳細リスク分析」＝「リスクアセスメント」とどっかで勘違いし始めたのですが、実際には他の方法もあって、例えば「ベースラインアプローチ」があります。「詳細リスク分析」ではリスクを自分たちで考えなければいけませんが、どうしてもそれには限界があります。ありとあらゆるリスクを想像で網羅する、というのは難しい話です。それで「ベースラインアプローチ」といって、こういうことの対策をするともっといいよーみたいなあらかじめ作られたリストを元に、ここも対策するといいよねーみたいな感じで「詳細リスク分析」の穴を埋めるってのがベタなリスクアセスメントのやり方っぽいです。
自分はアセスメント＝評価という認識なんで、リスト見ながらこれやりましょう、みたいな感じのベースラインアプローチのどこがリスクを評価してるの…と思ってしまいますが、それも含めてリスクアセスメントだそうです。
見積りにどんぐらい時間かけていいんだろう
今日は見積りをやっておりました。見積りって別に嫌いではないけど、正解がないというか、タイムマシンでも持ってないと正解が分からないのでやってももやもやした感じは残ります。プログラムみたいに動く、動かないって答えがすぐ分かるものの方がやっぱりいいなあ。
でこの見積りって作業、とても重要だと思うんですが、お客さん (候補?) から見積代がもらえる訳でもないので、あんまり時間をかける訳にはいかない。でもある程度設計とかまで考えとかないと正確な見積りなんてできないし、よく調べた上での見積りじゃないと値段が高過ぎたり逆に罠を見抜けずに安く出しすぎて炎上したり。
お客さんも安く頼むお! って言ってくるなら、可能な限りの資料は出してほしいなーと思います。余計な機能想定して工数乗せたりしちゃうし。もちろん質問してある程度情報を引き出してから見積りすればいいんだけど、それは見積り提出の締切までに余裕がある場合の話で、最初の資料が出てきてから数日ではい締切ねーと言われてしまうと確認する間がなかったりする (はっきり言ってしまえばうちが○次請けの場合、質問しても伝言ゲームなのですぐに返ってこない)。
なんか最初が肝心なんだから依頼する方も見積りする方もある程度時間かけてやれたらいいのにと思います。あとで炎上するよりは。見積り系についての本で知ってるのは『アジャイルな見積りと計画づくり』くらいなのでとりあえずこれは近いうちに読みたいです。でもアジャイルてことは顧客の協力が必要ですよね…
