スペック http://h50146.www5.hp.com/products/portables/personal/mini_note2133/specs/v1289w1024120gvhbr.html

たまたま貸してもらったものを触ってみたので、その感想をまとめる。短い時間だったので機能にあまり触れられずホント触ってみた感だけだけど。

• デザイン的にはマグネシウム色が重厚感を出していて、Macをさらに重たくした感じ</p>
  • 細かい部分も含めるとおしゃれというよりアメリカンなざっくりした感じ
• キーボードは思ったよりもピッチが広く、むしろ予想以上に指を広げないと届かなかったりする
• ポインティングのボタンが左右についているので、かなり慣れるのに苦労する
  • やはり下をクリックしてしまうので、ポインティングが思わぬ方向にずれたりして、、、
  • あとボタンは結構安っぽくて押すときは押し込まないと反応しないので、打感はよくない
• 8.9インチワイドディスプレイは横には十分だけどやはり縦が短いのでそれなりの作業には向かない
  • 特にブラウザは文字も小さくなるしスクロール回数も増えるし、フォント崩れも若干あったりして厳しいなぁ
  • ここら辺は大きさとのトレードオフなのだろうけど、ワイドは流行だったりするしな。。。
  • あまりワイドにしてもメリットは少なく、むしろ縦を長くしたほうが良いのになぁと思ってしまう

確かに軽くって腕にストレスなく移動できるのは肉体的にやさしいのだけど、ある程度外でもちゃんと打ちたいし見やすさを求めたいから、もう少し使いやすくないと、、、

個人的にはなしかな。

生ジーンズは一回もウォッシュされておらず、糊がついてバリバリなのでそのまま履こうと思うのは無謀です(w

ということで、自分も久しぶりで忘れて調べてしまったので今後のために生ジーンズの最初の糊落としの方法メモ。

1. タグを取る

買ったばかりのの状態

まずはタグを切り取る。

2. 裏返しにして前のボタンを全て止める

表だと生地が痛むから。ボタンを止めるのは形をちゃんと作りたいから。こんな状態になる

3. ぬるま湯につける

39度くらいのお湯を洗面台 or 風呂場 or 洗面器に張って折りたたんだ生ジーンズをつける。

あまりお湯がぬるすぎると糊が落ちないと思う。ゆっくり上からやさしく押さえつけつつジーンズにお湯を染み込ませる。

そのまましばしつけておく。最初は2時間くらい。

4. 脱水する

3分くらいやれば十分では。特にネットに入れることもせずにいいと思う。

乾燥機は生地を痛めそうなのでかけない。

5. 干す

裏返しのまま干す。裏のままなので、天日干しでも陰干しでもどちらでもいい気がする。気分的に天日干しにしてみる。

6. チェック

干しあがったところ

ちょっとよれ具合が出てきている。糊が落ちたかどうかチェック。まだ硬いなぁという感じならもう一度ぬるま湯につけるところから行ってみればいいのでは。2回もやればいい感じのよれ具合と落としがいのある色になる。

表に返したところ

これからどんな具合に仕上がっていくのか、ワクワクするなぁ。

Sさんは今の会社に入った時にすでにコンサルで関わっていただいていた個人で立ち上げた会社の社長さん。実は出身がNTTだったりして先輩にあたっていたのね。時々飲んだりしてお付き合いさせてもらってたけど、今回は今後自分がピンでやっていく場合に気になっていることあれこれを聞いてみたくてお誘いした。

すでに忘れかけてうろ覚えの部分もあるけど、メモ。

• 起業して1～2年でお金の感覚と人を見る目が変わる</p>
  • 全てのお金の使い方に敏感になる、と同時に金額の規模も変わる
  • 自分のビジネス的にその人がどういう影響をもたらすかを見極められるようになる
• 最初からコーシュマーで行くのは難しいので、確実に受託で売り上げられるように
  • 受託で潤ってきたキャッシュを元にサービスを作って見ようになったとのこと
• 受託で行くなら自己資金で最初は300万くらい、その後なんだかんだでトータル500万くらいかかる
• 最初から一緒にやろうとするメンバはトータルなスキルがないと厳しい
  • 例えば技術力だけで売り込む力がない場合、こちらがその不足部分を批判的に見てしまう
  • どこかの時点で根本的な違いが露呈されてしまう
  • 大きくなっていった場合、必要な部分を足していければいいのでは

コンサルタントとエンジニアで若干アプローチも異なるかもしれないが、すごく現実的で実践的なお話を聞けた。

実際自分も言葉にしてみて自分の考えを再確認した部分もあり、いいきっかけになった。

今後は同じ夢見る立場として、末永くよろしくお願いいたします。

珍しく本屋でついでに買ってしまった本。ジョブズが何で人々を魅了するのか。そのヒントみたいなのが少しでも見えたらいいなぁと思いつつあまり期待しなかったけど、

今日仕事でなんとも不思議な体験をした。

通常、電話とメールは基本的には機能的特長が違うので、同時に使うことはないと思うのだが。。。以下、今日の電話のやり取り。

• S社: こちらS社のAと申します。今から xxxxx@xxx.com へメールを送りたいのですが間違いありませんでしょうか？
• 私: ？。。はい。アドレスあってます。
• S社: では、これからメールを2通お送りいたしますので、受信の確認をお願いいたします。
• 私: ？。。今からですか、、はぁ。。 # すでに理解不能状態
  # メーラにて受信処理、メール受信される
• 私: あっ、メール届きました。
• S社: それでは2通目を送らせていただきます。# この後若干の説明
  ありがとうございました。失礼します。

その場でなんかおかしいなと思ったのは、このやり取りだったら電話要らないじゃんということ。

• メールアドレスは情報として向こうに伝わっているのでこちらに確認を求めることではない
• メールが届くかどうかを確認したい時は送ってみればいい、宛先不明なら error メールが返ってくるので
• メールサーバまで届いているかも不安だったら BCC に自分のアドレスでも入れておけばいい
• 電話で話したことはメール本文に書いてあるので、話さなくてもいい

いまどきメール送受信の信頼性を疑う必要はない。それを電話で補完する必要もないと思うし、、、今回のをもっと簡潔にやってみるなら、

「今メール送りますからね～」

「はいはい～、今来ました。」

「確かに届きましたね～ 良かった良かった」

ね。あほらしい。。。電話とメールを同時に使うことはやっぱりない。

このムダをフロー化しているこの会社はちょっと観点が狂ってしまっているのだろう。

仕事上、ほとんどのコミュニケーションはメールで完結できると思ってるし、逆に電話は緊急性が高くない限り不確実で無駄な部分が多いと思うのでほとんど使わない。ムダはなくしたいと常に思っているので、異常に気になった今日の出来事。

大学の時から履いていたジーンズは一応ビンテージモデルの走りだったりして10年間はきつぶしたらさすがに穴があいてしまった。さすがにこれでは会社には履いていけないし、新しく生ジーンズを買った。

やはり Levi’s 501XX でいくでしょう。501XX もモデルがいくつかあって履いた感じ一番スタンダードな形の1955年モデルにしてみる。

買ったところはここ。定価の￥1,000引きくらいかな。サイズは縮んだ後のサイズを参考にゆったり履きたかったから33インチ。

さて、まずはノリを落とすために水洗いしなくては。また、10年くらいかけて楽しめるといいなぁ。

KとI は新卒で入った最初の会社の同期。一番最初の泊り込みの研修の同じクラスで、その後配属先もバラバラで一度も一緒に仕事はしたことはないが、今だにつながっている社会人として長い友達。

最初に出会ったのが1999年4月だからもう9年以上が経っているんだなぁ。その間彼らは辞めずに異動も経験しつつ本社へ(Kは北海道から東京へ)、こちらは3.5年で辞めて3回転職、5社目か。

だいぶそれぞれ経験してきたことは違うと思うのだけど、話始めると自然とあのころのノリのまましゃべれてしまう。

人を通してフラッシュバックできるのは、自分を振り返るられるポイントづくりになる。

みんな結婚して、子どもが出来てで確実に環境は変わっているのに、面白いもんだ。

また、会おう！！今度は家族ぐるみで。

異常にwebの表示が遅くなった時の原因が TIME_WAIT の大量発生だった。PHP だと生じやすいなぁ。

CentOS 4.5 finall にて TIME_WAIT を短くするための方法。

• 状況</p>
  • web と DB を別サーバでネットワーク経由のデータやりとり
  • DB サーバ側は TIME_WAIT ほとんどなし
  • web(phpで作ったもの) にて TIME_WAIT 多めに残る それでも 150セッションくらいか

• 確認

# netstat -an | grep -i time_

(状況確認)

# netstat -an | grep -i time_ | wc

(行数として確認)

• 作業

# cd /proc/sys/net/ipv4/

# more tcp_tw_recycle

# echo ‘1’ > tcp_tw_recycle

特に再起動などいらず即反映される。

重めなページを読み込ませつつ

# netstat -an | grep -i time_ | wc

を定期的に見れば数が減っていく速度が速いことが分かる。

• 参考サイト</p>
  • http://ohac.pun.jp/blog/2005/200502.html
  • http://www.linux.or.jp/JF/JFdocs/Adv-Routing-HOWTO/lartc.kernel.obscure.html

Googleの人たちに直接触れたことがなかったので、登録していってきた。目的はプレゼンテーションの中身と言うよりかはそれを話している人たちがどんなものなのか。の方が興味があったりして。

3セッションほど聴けた。最後のエンジニアの日常の紹介では正に梅田望夫の本と同じ内容が紹介されていた。それ以外の部分で気になった点は、

• カルチャーを重んじる</p>
  • 人の邪魔をしないとか新しい人を受け入れる など
• 情報を共有することを徹底する
  • グローバルにやっているのでリアルなコミュニケーションより基本メーリングリストベースなのだろう
• リフレッシュする
  • 結構日本人的には休むことに関してネガティブな感覚が根強いので、リフレッシュベタだと思う
• 完全にボトムアップ型
  • プロジェクト参加も自分で手をあげて参加するそうな
  • 大企業に多い 言われてやる型 では成り立たない。逆に言えば言うだけの人はいらないと言うことだろう

080610 Google Developer Day 2008 @パシフィコ横浜

KML

Mano Marks

# 最初質問 KML使ったことある人 聞く

# 話してほしいこと聞く

KML とは (http://code.google.com/intl/ja/apis/kml)

• Google Earth のために最初開発された位置情報などの静的ファイル形式
• Google Earth API として
• Google Earth 以外も連携可能になった
• チェックしてみてください
  • http://code.google.com/intl/ja/
  • もうすぐ日本語化される

Google Earth を見せながらデモ

• Google Earth 上で Place Mark 追加
• Google Earth 上でコピーして KMLファイルがテキストに貼れる
  • mark のスタイルとサイズ、高度、座標軸の指定など可能</p>
    • 記述方法は HTML タグのように , のように囲む

Google Maps 上でも Place Mark がつけれる デモ

• ある場所にマークをつける
• ファイルに保存すると Google Earth で見れる
• KML ファイルはローカルではなくリンクによってファイル指定が可能
  • Google Maps 上のマークをコピーしてテキストエディタでペーストするとコードが貼れる
  • 逆に KML として Google Earth にペースト可能

Google Earth にてデモ2

• tokyo の年度ごとの人口変動を見せる
• 3D 上で各区市 の人口が高さで表示されている
  • 増加したところ赤、減少 青 出表示
• 動画再生のように 1955年から2015年予測を変動させた Community が作ってくれたKMLファイルらしい
• 記述 を必ず決める タイムスライダーを見せるため </li> </ul>

  QA その1

  • Q1 紀元前も可能？
  • A1 TimeSpan は紀元前も可能
  • Q2 Event も制御できますか
  • A2 時間を制御している
  • Q3 高さのマイナス 海の中とか扱うためにマイナスの値が使えるか
  • A3 マイナスの値は取り扱いは出来ない KMLでは定義可能、Google Earth では出来ない

  Google Maps と Google Earth を統合したもののデモ

  • Maps API に1行追加することで Earth API と連携できる</p>
    • # code.google.com からたどれるようだ
  • 4つの Google Earth の画面をブラウザ上で操作できる

  # うまく Google Earth 表示できず

  Google Earth デモ3

  • Places のチェックボックスをはずす
  • サーバとの通信を削減できる
  • デート相手を探す情報を表示させる
  • している ローカルからでなくサーバへの問い合わせ？ </li> </ul>

    QA その2

    • Q1 古い地図データは持ってこれるのか？
    • A1 ある時点での地図データを使っている ユーザが地図データをオーバーレイすることは可能
    • Q2 Google Earth API でも KML でもマーカー作れるけど どっちがいいの？
    • A2 データ量が多い場合(マーカーの数が多い)は静的ファイルで格納したほうがいいKMLかXML、情報が少ない場合はダイナミックでもいい Earth API

    Google Maps API for Flash

    加藤定幸

    Google Maps API for Flash

    • Flash 上で Google Maps を表示させる
    • 080515 にリリース すでに開発してくれているユーザいる

    作成手順

    • ビルド環境の準備 Adbe SDK でもいいしフリーでもいい</p>
      • swf ファイルの生成
    • ActionScript ソースファイルを作成
    • Maps API Key の取得
      • API Key は AJAX用のキーがそのまま使える

    作成手順 詳細

    • Interface Library が必要 最新版推奨 verison1.4

    記述方法

    • パッケージをimport する必要あり
    • インベントリーリスナー
      • 座標情報、maptype などを定義
    • Mapクラスを拡張
    • MXML ファイルを作成 => コンパイル swf ファイル生成 => サーバにアップする

    制御

    • イベント 4種類あり
    • コントロール 4種類あり # Google Maps と同じイメージ
      • ControlBaseを拡張することでカスタマイズ可能
    • オーバーレイ 4種あり
    • Poloyline:線をかく、Polygon:塗りつぶし
    • 画像表示可

    デモ いろいろなアプリケーション紹介

    • マーカー位置をドラッグアンドドロップ移動させる
    • 移動後の拡大縮小時に地図の中央にマーカーが来るように制御
    • ユーザ作成 飛行機操作
      • 飛行機が飛んでいるようなもの 3Dマウス？操作 ゲームコントローラーみたいなもの
    • プライオリティに応じてマーカーの表示非表示が可能 ズームすると現れるマーカーがある
    • マーカーをクリックしたときに Flicker から画像を引っ張って表示する

    まとめ MapsからいくつかAPIがあるので比較

    • Flash 版 視覚効果生かしたい
    • Ajax 版 普通のwebサイトに埋め込むとき JavaScriptが得意な場合
    • Static 版 静的なコンテンツが取得できればいい場合

    最後に

    • 日本のFlash製作能力はおそらく世界一
    • ノウハウを生かしてアプリ作ってください
    • 開発チームは日本発のアプリケーション期待されている
    • 公開するときは英語のページも作ってください
    • http://code.google.com/intl/ja/ 見てね

    QA

    • Q1 携帯は？
    • A1 Flash Lite 対応していない 今後も多分なし 互換性維持するのが難しい
    • Q2 Javascript と Flash パフォーマンスどっちがいい？
    • A2 評価したことない 前なら Flash だけどブラウザも向上しているのでよく分からない
    • Q3 オフラインだと使える Javascprit だとだめだけど、KML みたいに出来るか？
    • A3 Flash 版同じようにサーバ通信が発生しない ローカルファイルのアクセスはサポートしてない
    • Q4 Airアプリは？
    • A4 強い要望ある どうするかは未定
    • Q5 Ajax 版で出来て Flash版で出来ないことは
    • A5 Flash版ばかりやってたのでよく分からない。。
    • Q6 カスタムアイコン 影つけられる？
    • A6 やればできるけど、どうなっているか分からない

    ソフトウエアエンジニアの日常

    藤島さん

    Googleのカルチャー

    • カルチャーを重視している会社
    • すべてを明瞭に
    • 出来るだけすべての情報を共有する
    • 意思決定は命令ではなく社員の総意に基づいて判断する
    • エピソード: 会社の移転先を決めるときに 社員の住んでいるところをみて移転先を決めた 合理的に決める
    • 他人の仕事がしやすいように
    • 20%の時間を使ってグループ横断活動で支援
    • メンター: 新しいエンジニアについてヘルプする
    • 個人攻撃は起こらない
    • 自ら始める
    • 問題があれば 自ら直す
    • 完璧になるのを待つのではなく試してみる
    • 結果には柔軟かつ迅速に対処する
    • 今使えるものを使って目標を実現する
    • 安く効率的に実現する方法を考える
    • ex.) 非効率な作業を見つけたらツールを作る
    • 周囲の人を楽しませる
    • 地味な仕事、泥臭い作業にも光を当てる
    • 世界を変えられることを忘れない

    ソフトウエア開発

    • 世界に20カ国以上に50箇所オフィスある
    • すべてのオフィスは対等 自分の近くのオフィスに参加する
    • コミュニケーション 1箇所のオフィスで完結するものなし
      • wiki、チャット あらゆるものを使う
    • アイデアがひらめいたら 20% プロジェクトとして開始する ボトムアップ
      • 認められたらメインプロジェクトになる
    • 少人数 変更も柔軟にできる
    • ソフトウエアエンジニアが開発のすべてに携わる
      • アイデアから運用保守まで すべてのエンジニアがかかっている
    • 必要な文書を作る、不要なものは作らない
    • 百文書は1デモにしかず # まず作って説明する

    コーディング

    • 言語 C++、Java, Python, Javascript
    • 読みやすいコード スタイルは全社で統一 スタイルにあったコードをかけるか社内認定がある
    • 1つのソースツリーを全世界で共通

    採用活動

    • 開発以外の重要な例外 採用活動への協力</p>
      • 社風に会うか お互い Happly になるか
    • 一緒に働きたいと思うか
    • 結構エネルギーと時間を使っている

    業績評価

    • 一緒に仕事した人の業績評価する 四半期ごとに目標の設定と評価している
    • メリット 目立つだけでなく重要な地味なものも評価される
    • 社員間の信頼関係が前提

    遊び

    • 遊びと仕事は両立する
    • チームでリフレッシュ

    スピーカーの例 紹介

    • 入社動機 優秀な中でやってみたい
    • 優秀だけでなく人間的魅力ある人が多い
    • 意見に対して誰が言ったかではなく、正論か通りやすい
    • 動きが早い すぐ世界に出て行く どんどん改善されていく
    • エンジニアが 尊重/信頼されている
    • 良いソフトウエア開発のために泥臭いこともやる

    1日の過ごし方紹介

    • 10:00 メール USはまだ起きているかも
    • 11:00 コードレビュー
    • 12:00 昼飯
    • 13:00 コーティングに没頭
    • 16:00 tech talk を聞く 他のプロジェクト、技術話題聞く
    • 17:00 メールチェック後、コーディング
    • 18:00 夕食
    • 19:00 三度、コーディング

    心がけていること

    • 分かりやすいコードを書く
    • 他人のコードを尊重する
      • 必要ならリファクタリング
    • 正確かつ簡潔なコミュニケーションをする
      • 文化が異なる、英語を使っている
    • 仕事以外も目に向ける
      • TechTalk(他プロジェクトの紹介、技術紹介など) などに参加する
    • 良き仲間と思われているかどうか
    • ボトムアップの会社なので指示待ち、承認待ちをしていては進まない

    QA

    • Q1 意思決定の承認フローは？
    • A1 プロセス、承認を固める文化ではない
    • Q2 20%プロジェクトからメインサービスになるにはどうなっていく？
    • A2 やっている人たちの熱意 デモの力の入れよう いろんな人に話す。最終的にはマネージャの承認を得る
    • Q3 テスト環境は？
    • A3 詳しくは言えないが自分のテスト環境は自分が作る
      • 自分が直したことで解消されたことを証明する 担当チームへレビューする
    </div>