Archive for 2010年4月

AdobeはなぜComputational Photographyに注力するのか

4月 23rd, 2010

a canon camera
Creative Commons License photo credit: lett -/=

最近Adobeのニュースが賑わっています。CS5の発表もありましたが、多くはAppleとやりあっているFlash関連のニュース。とうとう先日AdobeはiPhone/iPad向けのFlashから手を引き、Androidに注力することを宣言しました。業績が好調のAppleがAdobeを買収するのではという憶測も定期的に出てきています。

AdobeはFlashを共通のミドルウェア化することでWebの覇権を取りに行こうとしていますが、Flashそのものでは利益を生めません。Flashをオーサリング出来るAdobe Flash、さらにはPhotoshop, Illsutratorを買ってもらってソフトウェアで利益を上げるビジネスだと自分は認識しています。MicrosoftがOfficeの値段を下げる中、AdobeのPhotoshopはアップグレードでも48300円するそうです。まとめて購入するとMac Proが買えるぐらいの金額になります。

これだけ高いお金を払ってもらうには相応の機能が必要と考えるのが一般的です。Adobeは今回のCS5で様々な目に見える機能を実装しています。「えげつない」と評されたPatchMatchは話題になりました。

こういった新しい技術はCG技術を画像処理に応用する”Computational Photography”に分類されます。一口にComputational Photographyと言っても色々アプローチがあって、SIGGRAPHなどの有名な国際会議で活発な研究成果の発表を知ることが出来ます。Adobeは世界で最も”Computational Photography”に注力している企業の1つです。なんですが…なんでAdobeがこんなに注力するのかが自分にとって謎でした。Photoshop/Illustratorに最新の画像処理技術を組み込んでさらに魅力的にして、CS6, CS7とアップデートしてもらうのも1つの理由でしょう。でも”Computatioal Photography”は特殊なハードウェアを要求するものもあり、どんなにAdobeが頑張っても実現出来そうに無いものもあります。そこが謎でした。技術の将来性があるからといって、すぐに利益を産めないものにリソースを使いすぎなんじゃないかと。

で、教えてもらったのがフランケンカメラプロジェクトです。カメラのハードウェアとソフトウェアを切り離し、ハードウェアを共通化する。その上でソフトウェアで価値を生み出せるようにするカメラ、それがフランケンカメラです。iPhoneで沢山あるカメラアプリを想像すると、このカメラでどんな可能性が広がるか伝わりやすいかもしれません。

これがあれば、Adobeはカメラメーカーになることができます。それもレンズや撮像素子は差別化要因にならず、ソフトウェアで差別化を図る必要がある「ソフトウェアで画質が進化する次世代カメラ」です。今のカメラよりも従来のデジカメとは2世代ぐらい先を行っているでしょう。こうなればComputational Photographyに一日の長があるAdobeがカメラメーカー、携帯メーカーとは異なる軸で戦うことができます。フランケンカメラにAndroidを積んで、その上で動くUI/アプリをFlashで作れるなら現実的にAppleと戦えそうな気も少しだけしてきます。

実際Adobeぐらいの規模なら業績が悪いカメラメーカーを買収することぐらいできるでしょうから違うアプローチを取るかもしれません。カシオはソフトウェアで差別化を図っていくつもりのようなので、Adobeと波長が合うかもしれません。

以上、会社の同僚から教えてもらった話でした。
間違ってる可能性の方が高いと思いますが参考まで。

並行コンピューティング技法 第6章

4月 23rd, 2010

いよいよアルゴリズムの並行化に着手する。今回は並列和、プリフィックススキャン、セレクションの3種類。

◯並列和
配列の和を全部求めるよくある処理。楽なのはOpenMPやTBBを使ってリダクション処理をそのまま利用すること。
自前で実装するなら配列をスレッド数で分割して個別に小計を計算。全スレッドが計算終わったら小計を全部足して合計をもとめるというやり方がおすすめ。

◯プリフィックススキャン
[3, 5, 2, 5, 7, 9, 4, 6]という配列を与えたときに[3, 8, 10 15, 22, 31, 35, 41]という配列を求める。配列のN番目に元の配列の0〜N番目までの和を入れておく処理に当たる。包含的プリフィックススキャンとも言うらしい。
先頭を覗いて[0, 3, 8, 10, 15, 22, 31, 35]の配列を求める排他的プリフィックススキャンの方法もある。

並列化の手法として、スレッド数で配列を分割し、個別にプリフィックススキャンを行う。次に末尾の要素を使って前後のチャンクに伝搬させる値を計算する。計算が終わったそれぞれのスレッドが担当するチャンクに値を加算してプリフィックススキャンを完了する。

さっきの例を3スレッドでやるとこんな感じになる。2と4のステップが並列化可能になる。
2から3、3から4に移るときに毎回スレッドを生成/破棄するとオーバーヘッドになるので、スレッドのイベント通知機能を上手く使って使いまわすのが吉。

1. 入力をスレッド数で分割
[3, 5, 2, 5, 7, 9, 4, 6] -> [3, 5, 2], [5, 7, 9], [4, 6]

2. 個別にプリフィックススキャン
[3, 5, 2], [5, 7, 9], [4, 6] -> [3, 8, 10], [5, 12, 21], [4, 10]

3. 配列の末尾の値で排他的プリフィックススキャンを行い、伝搬させる値を計算する
[3, 8, 10], [5, 12, 21], [4, 10] -> [10, 21, 10] -> [0, 10, 31]

4. 3で求めた値を2の処理結果にそれぞれ加算
[3, 8, 10]+0, [5, 12, 21]+10, [4, 10]+31 -> [3, 8, 10, 15, 22, 31, 35, 41]

◯セレクション
配列をソートしてN番目の値を取ってくるという処理。
ソートしてもいいけど、1回しか呼ばれないとか、適宜順番が変わるような配列だとセレクションがおすすめ。

公知のセレクションアルゴリズムがあって、その中でいくつかを並列化する。

1. 配列数がQ(本では5を勧めている)より小さければデータをソートして、k番目の要素を返す。Qより多ければ次のステップへ
2. チャンクから中央値を選ぶ(本では配列を分割して中央値を求め、その中からさらに中央値を求めるやり方をしているけど、配列の中身が適度にバラバラなら適当に選んでもいいかも)
3. データを A.中央値より小さい値を持つ B.中央値と同じ値である C.中央値より大きい値を持つ の3種類に分け、A,B,Cの数を数える。
4. 求めるk番目の要素がどこに入るかを調べる。Bに入るなら値を返して終了、AかCなら再帰的に1から処理を続ける。

本で高速化しているのはこのうちの2の処理、3の処理、4の処理の一部である。ポイントは4の処理で、再帰的に呼び出す際の配列の部分集合を使うのにプリフィックススキャンを使って詰め直し先のインデックス値を求めている。逐次処理に慣れきっていると重そうだけど、実際実行してみたら早いのかな? 要検証。

並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング
Clay Breshears
オライリージャパン
売り上げランキング: 8422

情熱プログラマー ソフトウェア開発者の幸せな生き方

4月 15th, 2010
情熱プログラマー ソフトウェア開発者の幸せな生き方
Chad Fowler
オーム社
売り上げランキング: 12001

ソフトウェア開発者のみならず、あらゆる分野でその道を極めようとしている人におすすめです。プログラマ固有のところは極めて少なく、自分の人生を自分で切り開いていくために必要な情報が分かりやすく整理されています。

以下この本で気になった所を引用しておきます。この本がプログラマ以外の人にも示唆に富む内容であることが伝わるのではないかと。

より良い製品を作って仕事を確保することだけが大切なのではない。より実りある人生を送るためのスキルと感性を磨くことも大切だ。人生には素晴らしいことがたくさんある。仕事はそのひとつに過ぎない。(David Heinemeier Hansson)

偉大になることを望んでいる人のほうが、自分の仕事をこなせれば良いと思っている人よりも、偉大になる可能性がずっと高いからだ。

何かのスペシャリストであると言うことを、単に他のことを知らないという意味で使っている人が多すぎる。

ビジネスの仕組みを知りもしないで、ビジネスが利益を上げるために想像力を働かせて協力できるだろうか?
・・・
想像力を働かせて付加価値を高めるためには、自分が関わるビジネスについての徹底的な理解が必要だ。

本当の意味で何かを習得しようと思ったら、誰かに教えてみることをおすすめする。自分の理解をはっきりした形にする一番いい方法は、自分の言葉を使って、他の人にもわかるように説明することだ。

プロセスを身につけたいなら実践しろ。

いいマネージャの役割は、チームの仕事に優先順位を設定し、チームが仕事をこなすために必要なものを用意し、チームがやる気と生産性を維持出来るように配慮し、最終的に要求を実現することにある。

短く働いた方が、より多くの成果をあげられる。

ソフトウェアの品質が本当の意味で試されるのは、何か問題が起きた時だ。

本当に出来ないときに臆せずに「できません」と言える強さを持ったチームメンバーがいれば、彼らの「できます」という言葉には偽りが無いと確信出来る。

多くのソフトウェア開発者は勘違いしている。事情に通じたマネージャや雇い主なら自分の技能を見ぬいて当然だと思い込んでいるんだ。・・・全部言い訳。彼らは怖がっているだけさ。
誰かが何かすごいことをしても誰もそれを知らなければ何もなかったのと同じだって言うんだ。

大局的に見るなら、作文技術は必要かつ供給不足なんだ。
君ももっと大量の文章を書くことになる。文章を書くことが仕事の一部になるとすれば、もっと作文技術を磨いた方がいい。

君に信念がないと、こういうことはできない。会社の連中が間違った事をするのを傍観していられない。改善の余地があるなら君が変えなければ。

目立つっていうのは、聞かれる前からみんなが君のことを話題にするっていう意味なんだ。

君のキャリアにとって本当に重要なのは昇進でも昇給でも無い。重要なのは、そういう成果を得るために努力した時間だ。もっと重要なのは、そういう成果とは関係ないところで努力した時間だ。

並行コンピューティング技法 第4章 & 第5章

4月 11th, 2010

短いので今週は2章分まとめて読みました。

◯第4章 マルチスレッドアプリケーション設計の8つのルール
・8つのルール

  1. スレッド化設計モデルに加えるべきルール、順不同。
  2. 真に独立した処理を特定する
  3. 並行性はより上位で実装する
  4. コア数増加に備えスケーラビリティ対応を早期に計画する
  5. スレッドセーフなライブラリを使用する
  6. 適切なスレッドモデルを採用する
  7. 実行順序を前提としない
  8. ローカル変数を使用する、できなければロックで保護する
  9. 並行性向上のためのアルゴリズム変更を恐れない

・ルール1: 真に独立した処理を特定する
これが最も重要。 処理が互いに独立していなければ並行実行できない。

・ルール2: 並行性はより上位で実装する
並行性を見つける方法は2種類ある。

  • ボトムアップ
  • トップダウン

どちらを選ぶにせよ、より上位で並行化した方が良い。 アルゴリズムの上位レイヤほど、より多くの独立した処理を含んでいるからである。

・ルール3: コア数増加に備えスケーラビリティ対応を早期に計画する
今後もプロセッサコア数は増加の一途であることが予想される。 開発中のソフトウェアであっても、このことは考慮に入れておくべき。

並行性の設計はタスク分解とデータ分解の2種類があったが、 アプリケーション内の独立した処理とデータサイズではデータサイズの方が増える傾向が強いため、 データ分解設計の方がスケーラビリティーでは有利である。

設計中のソフトウェア/システムが計画している処理能力を十分に達成できても、 将来要求される処理能力は増加する可能性が高い。 処理能力に余裕があれば、処理するデータはまだ誰かが持っている。

・ルール4: スレッドセーフなライブラリを使用する
車輪の再発明は決していい方法ではない。 一般的なライブラリ関数で置換可能であればそれを使うこと。

使用の際には、マニュアルを参照してライブラリがスレッドセーフであるかを必ず確認する。 自作ライブラリなら関数がリエントラントであるように設計する。

・ルール5: 適切なスレッドモデルを採用する
スレッドの明示的な使用(Pthread/Windowsスレッドの直接的な利用)は避けるべき。 抽象化ライブラリ(OpenMP/Intel Threading Building Blocks)を通してスレッドを利用すること。 多くの並行化作業はスレッドを明示的に操作する必要があるほど柔軟性が求められておらず、 実装が複雑になるとバグが入る可能性が高くなる。

開発上の規約などにより、抽象化ライブラリの使用が禁止されている場合でも、 プロトタイプは抽象化ライブラリを使うことで手間を省くことが出来る。

・ルール6: 実行順序を前提としない
スレッドの実行はOSなどのスケジューラで管理されるものであり、 アプリケーション側で順序を決定することは出来ない(非決定性がある)。 スレッドがどんな順序で実行されても正しい結果を返すように設計すること。

また性能の観点から、出来る限りスレッドの実行に制約を課すべきではない。 例えばスレッド処理の待ち合わせをするときは本当に必要か立ち止まって考える必要がある。

・ルール7: ローカル変数を使用する、できなければロックで保護する
同期処理は必要悪だが、最小限の使用に留める必要がある。 共有変数の更新が少ないほど、オーバーヘッドも少なく済む。

まずはスレッドごとに持たせるローカル変数で問題が解決出来ないかを考える。 駄目なら適切なロックを共有データに対して適用する。 デッドロックの温床となるため、1データに対して複数のロックを対応付けてはならない。

・ルール8: 並行性向上のためのアルゴリズム変更を恐れない
逐次処理では最良だったアルゴリズムが、並行処理では最良でないことがある。 並行化出来なかったり、他のアルゴリズムの方が並行化による恩恵を受けやすいことがある。

◯第5章 スレッドライブラリ
・抽象化ライブラリ
スレッドの制御(作成・管理・同期)を抽象化し、プログラマに楽をさせてくれるライブラリ。 スレッドを明示的に作成する処理は無く、柔軟性は落ちる。

・OpenMP
専用のpragma、指示文(ディレクティブ)、環境変数を用いて並行処理可能な部分を指定する。 並行実行コードはコンパイラにより生成される。 並列環境と非並列環境でほぼ同一のソースコードを使用できるという利点がある。

スレッドの管理はfork-joinモデルを採用している。 マスタスレッドが並行処理可能な領域(パラレルリージョン)に到達すると、子スレッドが生成され(fork)、 各スレッドがパラレルリージョンを実行する。 パラレルリージョンの終了時には子スレッドが待ち合わせ(join)、 パラレルリージョン後からメインスレッドが処理を続行する。

・Intelスレッディング・ビルディング・ブロック
並列アルゴリズムが定義、実装、提供されており、 並行処理がカプセル化されたクラスを通して使用する。 商用バージョンとオープンソースバージョンがある。

・明示的スレッドライブラリ
PthreadとWindowsスレッドがある。提供される関数は大差ないはず、必要に応じて調べて使いましょう。

並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング
Clay Breshears
オライリージャパン
売り上げランキング: 18712

麻雀問題解いてみた

4月 4th, 2010

Mahjong set [04/04]
Creative Commons License photo credit: drdaeman

makeplex salon:あなたのスキルで飯は食えるか? 史上最大のコーディングスキル判定 (1/2) – ITmedia エンタープライズを解いてみました。ソースはtune’s itmedia_makeplex at master – GitHubに上げてありますのでリビジョンも見れるようになってます。最初のコミットを上げるまでに、面子の表示順の違いを抑えるところで詰まってチンイツの待ちを出力するプログラム – 107143955443560を参考にしました。参考にしましたというよりもC++のソースをRubyに移植しましたと言う方が近いほど同じ処理です。基本的なアルゴリズムは最後まで踏襲しています。

最初のコミットまでが3時間ぐらい、リファクタリングに1時間ぐらいです。ちょっと時間がかかりすぎですが、日常的に書いてないRubyで、日常的にプログラムしてない家のMacパソコン、プラグインが古いのか5分に1回落ちてしまうMacVimで時間がとられたと言い訳しておきます。ただの実力不足です、ごめんなさい。

成立する可能性がある面子を減らしながら、総当たりで探索しています。面子の順序違いによる重複表示を避けるのが結構面倒ですね。刻子を優先して探さなければならず、色々試行錯誤してみたのですが、参考にさせていただいたid:staebchenさんよりも良さそうな方法に達しませんでした。もっといいやり方があると思いますが、参考まで。

#!/usr/bin/ruby

class Array
  def sum
    s = 0
    self.each do |v|
      s += v
    end
    return s
  end
end

class Fixnum
  # 刻子
  def anko
    num = self+1
    "(#{num},#{num},#{num})"
  end

  # 順子
  def shuntsu
    num = self+1
    "(#{num},#{num+1},#{num+2})"
  end

  # アタマ
  def atama
    num = self+1
    "(#{num},#{num})"
  end

  # 単騎
  def tanki
    num = self+1
    "[#{num}]"
  end

  # リャンメン(ペンチャンも兼ねる)
  def ryanmen
    num = self+1
    "[#{num},#{num+1}]"
  end

  # カンチャン
  def kanchan
    num = self+1
    "[#{num},#{num+2}]"
  end

  # シャボ
  def shabo
    num = self+1
    "[#{num},#{num}]"
  end
end

#
# 雀牌を表す数字列を解析し、0〜8の配列に与えられた個数を入れて返す
#
def parsePai(str)
  pai = Array.new(9, 0)
  str.split(//).each do |p|
    pai[p.to_i-1] += 1
  end

  # 入力の妥当性チェック
  if pai.sum != 13 then
    # 与えられる牌は13枚
    raise RuntimeError
  else
    pai.each do |val|
      if val > 4 then
        # 1種類の牌が4枚より多いことはない
        raise RuntimeError
      end
    end
  end

  return pai
end

#
# 手牌を再帰的に解析し待ちを表示する
#
# 順子を刻子に優先して探索する。
# 順子はfromが9〜18の時に探索される
#
def analyzeTehai(pai, from=0, mentsu=[])
  shuntsu_phase = 9
  skip_anko_check = false

  if from >= 9 then
    skip_anko_check = true
    from -= shuntsu_phase
  end

  if pai.sum > 4 then
    # 面子を揃える

    # 刻子
    unless skip_anko_check then
      from.upto(8).each do |i|
        if pai[i] >= 3 then
          tmp = pai.dup
          tmp[i] -= 3
          analyzeTehai(tmp, i+1, mentsu+[i.anko])
        end
      end
    end

    # 順子
    from.upto(6).each do |i|
      if pai[i]>=1 && pai[i+1]>=1 && pai[i+2]>=1 then
        tmp = pai.dup
        tmp[i] -= 1
        tmp[i+1] -= 1
        tmp[i+2] -= 1
        analyzeTehai(tmp, i+shuntsu_phase, mentsu+[i.shuntsu])
      end
    end

  else
    # 残った4枚から待ちを絞る

    # アタマを探す
    0.upto(8).each do |i|
      if pai[i] >= 2 then
        tmp = pai.dup
        tmp[i] -= 2
        analyzeMachi(tmp, mentsu+[i.atama])
      end
    end

    # 面子(刻子 or 順子)があれば単騎待ち
    # 刻子
    unless skip_anko_check then
      from.upto(8).each do |i|
        if pai[i] >= 3 then
          tmp = pai.dup
          tmp[i] -= 3
          analyzeTanki(tmp, mentsu+[i.anko])
        end
      end
    end

    # 順子
    from.upto(6).each do |i|
      if pai[i]>=1 && pai[i+1]>=1 && pai[i+2]>=1 then
        tmp = pai.dup
        tmp[i] -= 1
        tmp[i+1] -= 1
        tmp[i+2] -= 1
        analyzeTanki(tmp, mentsu + [i.shuntsu])
      end
    end
  end
end

#
# 4枚から待ちを絞る
#
def analyzeMachi(pai, mentsu)
  0.upto(8).each do |i|
    # リャンメン(ペンチャン)
    if pai[i]==1 && pai[i+1]==1 then
      puts mentsu.sort.to_s + i.ryanmen
    end

    # カンチャン
    if pai[i]==1 && pai[i+2]==1 then
      puts mentsu.sort.to_s + i.kanchan
    end

    # シャボ
    if pai[i]==2 then
      puts mentsu.sort.to_s + i.shabo
    end
  end
end

#
# 単騎待ちの数字を調べて待ちを表示する
#
def analyzeTanki(pai, mentsu)
  # 単騎待ち
  0.upto(8).each do |i|
    if pai[i] == 1 then
      puts mentsu.sort.to_s + i.tanki
    end
  end
end

# 以下実際の処理
pai = parsePai ARGV[0] unless ARGV[0] == nil
analyzeTehai(pai)

4年前、新社会人だった自分へ

4月 2nd, 2010

Cherry blossoms / Sakura / 桜
Creative Commons License photo credit: TANAKA Juuyoh (田中十洋)

早いもので大学院修士卒で働き始め5年目に突入しました。4年間も働いていれば色々なことがあるもので、同期入社の友人が退社したり、同期同士の結婚式に呼ばれたり、海外赴任もいれば、自分のように同じ業務をこなし続ける人もいます。仕事は一貫して同じ内容ですが、異動はあって上司は4人変わったし、私生活では結婚して子供もできました。4年間は短いようで振り返るといろいろありますね。

今日から新年度ということもあり、色々な方が新社会人にエールを送った文章を書いているかと思いますが、自分も4年前の自分に教えたいことをまとめるつもりで書いてみます。リクルーターに選ばれる機会もなくて自分で振り返りをしないといつか忘れちゃうのも理由の一つです。ちなみに私の仕事はカメラやコピー機を作っているメーカーの研究開発職(ソフトウェアエンジニア)です、会社名まで知りたい人は2006年の5月あたりの過去ログを探すとわかるんじゃないかと思います。大学で情報処理を学んでいて、将来はメーカーで働きたいなんて人のお役に立ちますように。

◯これから就職活動を始める方へ
自分が就職活動をしていたときに気にしていたけど、今となってはどうでも良くなってしまったことです。

  • その会社の社風
  • 長く勤められる企業かどうか
  • 初任給

ベンチャーならともかく、社風は気にしすぎない方がいいと思います。
大きい会社になればなるほど事業部や部門によって雰囲気がぜんぜん違います。気になるなら何とかしてそこで働いている人にコンタクトを取ってご飯を食べながら話を聞くのがいいかと思います。今ならtwitterで呼びかければ誰かしら見つかるのではないでしょうか? もちろん真摯な態度でお願いする必要はありますが。

「リストラはしない方針」、「外資系だけど日本文化も取り入れた日本企業」、「長く勤められる会社に行きたい」もアテにならないですね。リストラしないというのはこれまでしてこなかった過去の結果を言ってるだけで、この先不景気にやればやらざるを得ません。この不景気なご時世だから信じてかかる人のほうが少ないかと思いますが。自分が就職活動で第2希望に挙げていた外資系の企業は昨年研究所を閉鎖してしまいました。20何年間の歴史があっても終わるときはきます。長く勤められる会社を探して寄生するよりも、どこの会社でも生きていけるスキルを持っている方がいいですよね。自分のキャリアは自分で作りましょう! 情熱プログラマーの受け売りです。

初任給がそのままの給料の会社もあれば、しばらくは「研修期間」で少しすると(ウチの場合は修士卒だと1年)ぐっと上がる会社もあります。実際に働いている人に聞けば手取りでいくら貰えているのかすぐに教えてくれるので新卒の募集要項なんて見てないで聞いてみるのがいいでしょう。

やっておいた方がいいのは自分が行きたい「部門」で働いている人へのインタビューと、できるならインターンですね。私の大学院の指導教授は「どこそこの会社に行きたい」と言ったらその会社の組織図を使ってどこに行きたいのかと指させましたが、とても理にかなっていると思います。「就社」でも当面の間働くのは配属先の部門ですからね。大学で情報系を学んでいてもプログラムが好きな人ばっかりでは無いと思います。私の毎日は朝から晩までC言語とにらめっこをしていますが、駄目な人は駄目みたいです。根性や気合でどうにかなるものではないので早めにわかっておいた方がいいでしょう。

◯アウトプットは将来の履歴書
ブログなり、Mixiなり、Twitterなり学生の頃は暇に任せて使う時間がありますが、就職するととたんに更新頻度が落ちて、使う人が減っていきます。会社での成果は当然会社に帰属するので、ただ毎日を過ごしていると自分の社会人になってからの成果を示すものが何もなくなってしまいます。自分の会社は学会活動も活発ではないので、転職することになって何か出せと言われたら特許公報でも持っていくしかありません。最初から転職ありきでブログを書けというつもりはありませんが、何かしら社会人になってからの自分の成長を書き留めておくアウトプット先があるといいでしょう。会社の業務も秘密のものばかりではなくて、よくよく見てみるとブログに書けるような一般性が高いものもあります。でもどこかに書き留めておかないとそれに気づくことも出来ないでしょう。

◯新卒が即戦力足り得ないのはその会社のルールを知らないから
持論ですが、どんな能力を持った人も入社してから半年は立たないと本来の力を発揮出来ないのではないかと思っています。会社には独特のルールや文化があり、それを踏まえて動かないと思ったように成果がでないことが多々あります。最悪なパターンに「事前の根回し」がありますが、それ以外にも小さなところで考慮すべき点はあります。例えば「その技術は会社の事業にどう貢献するのか」、「顧客にどう付加価値を伝えるのか」、「特許的な問題はないのか」、「製品アーキテクチャを考えて十分なパフォーマンスが出るのか」、「事業部の方針と提案する技術はあっているのか、興味を持ってもらうにはどう話したらいいのか」などなど、ベテランになるほど暗黙のうちに受け答えのパターンを作ってしまって気づかない点です。最初はしかられたりして落ち込むこともあるかもしれませんが、学ばなければならないルールを一つ気づくことができたと割りきってどんどん失敗するのがいいと思います。先輩も上司も失敗しない新入社員なんて期待していません。

◯仕事は自分で楽しくするもの
これも情熱プログラマーの受け売りです。エキサイティングな業務もあれば、つまらない業務もいっぱいあります。資料集めでネットサーフィンを延々とやるとか、PowerPointファイルを1ヶ月ぐらいこねくり回すとか、上司に指摘された修正をその上の上司に覆されるとか、いっぱいあります。
こういう時に発想の転換をして「いかにネットサーフィンが快適な環境を会社につくるか」、「今度の資料ではプレゼンテーション Zenを取り入れてみよう」と視点を変えてみましょう。

◯「この上司は分かってないな」と感じたら、上司に情報が十分に伝わってない可能性を疑うこと
「上司が分かってないのは仕様だ」というツッコミも来そうですが、私のアドバイスとしては、まは自分の伝え方を疑ってみることをおすすめします。上司はなぜそう判断したのか考えて、分からなければ聞いてみましょう。

「これからはクラウドだ」と言う上司にきちんとクラウドの動向情報をインプットしましたか? プライベートクラウドが駄目な理由を伝えましたか? クラウドで何ができるか事例を調べてメールで送りましたか? 飲みの席でDropboxとかEvernoteとか見せびらかしましたか? 上司に伝える情報を偏らせて自分の望む方向に誘導するのはやりすぎですが、「分かってない」と落胆する前に出来る限りのことをしましょう。

◯身だしなみを大切に
新入社員研修でお互いに毎朝プレゼンするというのがあったのですが、今でも覚えているのは「毎週靴の手入れをしましょう」というものでした。靴の磨き方は靴の手入れなど検索すればすぐに見つかりますが、実践している人は少数かと思います。自分も実践してみた(今でも隔週ぐらいで革靴の手入れをしています)のですが、足元を気にすると全体の身だしなみにも注意が行くようになります。