  |
はてなキーワード: javaとは
C言語を最初に覚えると、楽は楽だよ。変なクセがつかないから。
全てのC++はCに展開できるし、展開の原理を知っていると、C++でオブジェクト的に組みながら、アセンブラの展開とかを見ながら書いているらチューニングが楽。
メモリの事とかCPUリソースのことを考えずに書かれたプログラムって、チューニングに限界があるから、あとあと苦労する。
そういう意味では、Cから入ると、とっつきにくいが、あとあとまで、ちゃんと生きてくるよ。
今のところの言語のオススメはJavascriptだね。理由は簡単で
１ ブラウザがあれば誰でも試せる
２ ブラウザとの連携で絵や音を使ったサンプルを作れるのでつくっていて楽しい
という点。
さすがに、今時PerlでもRubyでもいいけど、絵や文字ばかりのサンプル作ってもCと同じで楽しくないから初心者向きじゃない
とりあえず、そのへんで楽しんでもらえたら、
プログラムの職人的なチューニングのところが気に入ったのならC/C++に転向すればいいし 机の上で理論や設計を楽しみたいならRubyやJavaをやればいいし
Web系のところが気に入ったのならPHPでもPerlでもいいかもしれない。
大切な事は、プログラムを楽しむこと。プログラムにもいろいろな側面があるので、自分がどういう側面を気に入るのか？というのを早めに掴むこと。
あとは、長く続けられるものを選ぶこと。
まぁ、言語は所詮道具だ。道具の良し悪しを言っても、釣りにバットを持っていくわけにもいかないから、釣りがしたければ釣竿を、野球がしたければバットを選ぶしかないわけで
目的にあった言語を選ぶための最初の言語は、気軽に選べばいいよ。
dwang厨が無謀にもfroyoを入れてみる記録のページ。
結局CM6-RC1+yay-gapps で落着きそうな雰囲気。
dwang-1.17.1
→ eMonster用に使ってた sandisk 2GB (メモ)
7/9 にリリースされているもの
ext partition 要対応？ とおもったら仏語じゃねーか
@kenmood
Wifi OK
どっかから落した20090801-docomo-ht-03a.rar のうち、boot, cache, data, system のみをnandroidで復旧してみる。nandroid.md5 の復元も忘れずに。
手順
追加手順:
http://www.androidinforum.fr/htc-dream-android/froyo-french-connection-100-t1742.html#p6156
partition: swap 160M, ext 500M, 残り vfat がおすすめとな。
何度か丹念に「目標をwipeしてreboot」を繰り返してたら安定した気がする。
豆腐をfont入れ、localeをlibicudata.so の入れ替えで対処 (できるかな？ reboot中)
→ libicudata.so は入れかえちゃダメ。起動しなくなる。recoveryで起動して/systemをマウントしてことなきを得る。
2010-07-11 追記
2chでも報告されているとおり、wlanが使えない。あと細かい話だけど、live wallpaperが使えない気がする。メモリが足りないだけかもしれないけど。
marketが死にまくる (acoreが死ぬ)。ほかにも死にまくるけど、何故かはよくわからない。とりあえず体験はできるけど、まだ常用には至らないかも。
(安定している、と言っている人もいる)
2010-07-11 追記
zip落してきて上書きinstallしてみた。なんか日本語fontが消されたんだけど(ぶー！)
ちなみに日本語fontはM+を利用してます。
数時間つかった限りでは、他人にお勧めできるほどじゃないけど何とか使いものになるかも。dwangの環境はnandroidでしかバックアップしていないので、手作業でアプリなどは手作業で復帰する予定。
(2010-07-11 午後5時追記)
どうもSPF Connectionが安定しないのと、ベースがCM6ということで、まずはベースに近いほうが良いだろうと
CM6-RC1を焼いてみる(この項続く)
http://www.cyanogenmod.com/home/cyanogenmod-6-0-0-rc1
E/AndroidRuntime( 2000): FATAL EXCEPTION: UpdateCheckinDatabaseService
E/AndroidRuntime( 2000): java.lang.SecurityException: Permission Denial: writing com.google.android.gsf.settings.GoogleSettingsProvider uri content://com.google.settings/partner from pid=2000, uid=10036 requires com.google.android.providers.settings.permission.WRITE_GSETTINGS
すぐ直りそうではあるけど。
(エラー内容から察するに、installされたapkの記録をgoogle accountに書き込めない)
c.f. http://forum.xda-developers.com/showpost.php?p=7139560&postcount=109
まともな言語であるJavaでは、メモリモデルを定義していて、その上で挙動を議論することができる
例えば、一定の記述をすることにより、オブジェクトへのメソッドコールやフィールドアクセスが線形化可能になる（とJavaの仕様が規定している）
一方、C言語には、そのような「メモリ」が存在するのであろうか？しないのであろうか？
そのような定義なしに、メモリ管理の正当性は議論可能なのであろうか
いやはや疑問は尽きない
PHPユーザー会の中の人とたまたま話したんだけど、アプリケーションのPHP5.2系からPHP5.3系への移行が滞っているようだ。
「業務でPHP5.3使ってますよー。」って言ったらむしろ驚かれた。どういうこった？
いま移行せずに、PHP5.3ってどうなるのよ？その先にあるPHP6系ってどうなるのよ？不安しかでてこない。
国連FAOは韓国と日本で発生の口蹄疫に対して国際的な監視体制の強化を提唱:5月4日
http://www.meattradenewsdaily.co.uk/news/070510/uk___foot_and_mouth_concerns_.aspx]
UK - Foot and Mouth concerns 04 May 2010
So far Japan has had to slaughter 385 animals ? buffaloes, cattle and pigs.
“We are worried because the rigorous biosecurity measures in place in the two countries were overwhelmed, pointing
to a recent, large-scale weight of infection in source areas, very probably in the Far East,” said FAO’s Chief
国連FAO（国際連合食糧農業機関）の獣医学主任、Juan Lubrothは日本で口蹄疫により385頭の動物の処理があったとのニュースにコメントし「日本と韓国で厳密なバイオセキュリティの規制措置があるにも関わらず極東地域のソースと思われる口蹄疫の発生のあることに憂慮している」と述べた。
“In the past nine years, incursions into officially FMD-free countries, as were Japan and the Republic of Korea, have
been extremely rare so to have three such events in four months is a serious cause for concern,” he noted.
“We also have to ask ourselves if we aren’t facing a possible replay of the disastrous 2001 FMD transcontinental
epidemic which spread to South Africa, the United Kingdom and Europe after earlier incursions in Japan and South
Korea,” Lubroth added.
「過去9年間に日本や韓国での口蹄疫は稀であったが、今は4ヶ月に3回の発生事例が見られ,深刻な状況と思っている。2001年に南アフリカから英国、欧州に口蹄疫の広まった大規模感染の事例の二の舞にならないかと心配している」
http://www.wattagnet.com/15657.html]
(java切ってると読めん)
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
さて、スクリプト言語は軒並みトロいということが分かったうえで、次のグラフをご覧頂きたい。これは各プログラミング言語でのテンプレートエンジンのベンチマーク結果である。
…（中略）…
これを見ると、Java や C で実装されたテンプレートエンジンが必ずしも最速ではないことが分かる。
…（中略）…
このように、プログラミング言語の速度とアプリケーションの速度は、必ずしも一致しない。一致しないどころか、まるで関係ないと言っても差し支えないぐらいである。もちろんテンプレートエンジンの速度でアプリケーションの速度を測れるわけではないが、「必ずしも一致しない」という結論は変わらない。
…（中略）…
.@tagomoris あんなテンプレートの記事に感心してちゃだめですよ。テンプレートの処理の全体に対する時間の割合が出てないと意味ないのに、ああいう結論を出している時点でその釣りレベルがわかるというものです
んー、「言語の速度 != アプリの速度」という主張を示すにはあれで十分だと思いますけど。データベースやネットワークまで含めて計測したら、それこそ言語の速度に関係ない部分が増えるわけですから、先の主張がもっと強調されるだけです。そういった、明らかに言語に関係のない部分を含めなくても「言語の速度 != アプリの速度」というのがよくわかるという点で、あのベンチマークは十分意味があると思いますが、いかがでしょうか。
パフォーマンスの結果は、その測定対象に対しては事実ですが、別のモノに対しては確かな根拠とは成り得ません。あるひとつの測定結果のみで、ほかも大体そうだろうというような人は、根拠がないので、それを説得した上で認めないならしかとしてもいいんじゃないかな。しょせんそのレベルの人だから
wwwwwwww
「言語の速度 == アプリの速度」という思想に対し、id:kwatchが反証を出している。
id:kwatchの反証は、つまり、アプリケーション中でテンプレートエンジンについてのみ取り出してみた場合に、テンプレートエンジンの速度とアプリケーションの速度が関係ないということを示している。
このような事実にも関わらず「言語の速度 == アプリの速度」という思想を維持するには、テンプレートエンジンの速度差にも関わらず、アプリケーションの他の部分の速度差によって必ず「言語の速度 != アプリの速度」が達成されなければならない。そしてそれは有り得ない。テンプレートエンジンの速度差は主にアーキテクチャや実装によって生じており、アプリケーションの他の部分もそれぞれ異なるアーキテクチャや実装を採用している以上、同様に速度差が発生するからだ。
もちろん他の部分の実装等で差を取り戻し、あるいは逆転するアプリもあるだろうが、差を広げられるアプリもあろう。しかし、それはアプリごとにバラバラなので結局「言語の速度 == アプリの速度」というおとぎ話に立ち戻ることは出来ない。
結局のところ、「言語の速度 != アプリの速度」を証明する場合には、アプリ中で同じ役割を担う一部分どうしを比較して「言語の速度 != アプリの速度」となることを示せば十分だ。
ところがid:higayasuoはテンプレートエンジンの速度差があろうと、アプリの速度が言語の速度で決まることを否定出来ないという。
端的にいって勘違いだ。
これが仮に「言語の速度 == アプリの速度」という妄想を証明するために「言語の速度 == テンプレートエンジンの速度」である例を持ち出したのであれば、パフォーマンスの結果は、その測定対象に対しては事実ですが、別のモノに対しては確かな根拠とは成り得ません
などという不抜けた妄言も成り立つところである。
しかし今回は != だ。
!= と == の区別がついてないとすれば馬鹿だし、!= への反証が == への反証と同じだと考えているのならやはり馬鹿だ。!= を証明するには、ただ１つでも反例を挙げれば良い。 == への反例が一つでも挙がれば != の証明になるのだ。
まさかid:higayasuoは、id:kwatchが「テンプレートエンジンの速度 == アプリの速度」と書いていると読んだのだろうか。
そんなことは本文のどこにも書いていないばかりか、上記の引用の中で明確に否定されている。
Tomcat上のJRubyから呼んだJavaプログラムから呼び出し元のJRubyの環境(Runtime)を使いたいときにどうすればいいのか？
方法が1つわかったのでメモ。
(追記2:こんなめんどいことしなくてもJRuby.runtimeで取れたみたい)
イメージ的には以下の感じ
↑↓
↑
JRubyは1.4.0、jruby-rack.jarは0.9.7、warblerは1.0.1
まずは必要なクラスをimport
import org.jruby.Ruby; import org.jruby.rack.PoolingRackApplicationFactory; import org.jruby.rack.RackApplication; import org.jruby.rack.RackServletContextListener;
ServletContextをどっかから取ってくる(Listener作ってfieldに埋めるとかして)(追記：$servlet_contextで取れる[JRuby-Rack使うから])
ServletContext context;//=～～～
warblerでwar化するとweb.xmlにRailsServletContextListener(extends RackServletContextListener)が登録される。
そのListener起動時にFactoryがServletContextに登録されるので、それを取得する
PoolingRackApplicationFactory factory = (PoolingRackApplicationFactory)context.getAttribute(RackServletContextListener.FACTORY_KEY);
PoolingRackApplicationFactoryのapplicationPoolを取ってくる
(protected fieldなのでリフレクションを使用)
Field poolField = factory.getClass().getDeclaredField("applicationPool"); poolField.setAccessible(true); Queue<RackApplication> pool = (Queue<RackApplication>)poolField.get(factory);
RackApplication ap = pool.peek(); Ruby ruby = ap.getRuntime();
呼び出しもとのJRuby環境を使ってRubyコードを実行できる
ruby.evalScriptlet("p 'test'");
実際に使うときは、applicationPoolにちゃんと入っているかなどのチェックが必要になる。
JRuby上で動くRubyとJavaのログを同じファイルに保存したいときなど
JRuby界隈で何かいい方法ないかな～と探していたけど見つからないので
RubyのLoggerのインターフェースをcommons-loggingを使用して実装してみた
使用バージョンは以下
require 'logger' class CommonsLoggingLogger def initialize(name="ruby") @progname = nil @logger = org.apache.commons.logging.LogFactory.getLog(name) end def add(severity, message=nil, progname=@progname, &amp;block) if message.nil? and block_given? message = yield end case severity when Logger::DEBUG debug(progname){message} when Logger::INFO info(progname){message} when Logger::WARN warn(progname){message} when Logger::ERROR error(progname){message} else fatal(progname){message} end end def debug(arg0=nil, &amp;block) @logger.debug make_log(arg0, &amp;block) end def info(arg0=nil, &amp;block) @logger.info make_log(arg0, &amp;block) end def warn(arg0=nil, &amp;block) @logger.warn make_log(arg0, &amp;block) end def error(arg0=nil, &amp;block) @logger.error make_log(arg0, &amp;block) end def fatal(arg0=nil, &amp;block) @logger.fatal make_log(arg0, &amp;block) end def debug? @logger.isDebugEnabled end def info? @logger.isInfoEnabled end def warn? @logger.isWarnEnabled end def error? @logger.isErrorEnabled end def fatal? @logger.isFatalEnabled end def level if debug? Logger::DEBUG elsif info? Logger::INFO elsif warn? Logger::WARN elsif error? Logger::ERROR else Logger::FATAL end end def level=(lv) #do nothing end def sev_threshold level end def sev_threshold=(lv) #do nothing end def datetime_format nil end def datetime_format=(fm) #do nothing end attr_accessor :progname private def make_log(message_or_progname, &amp;block) if block_given? progname = message_or_progname || @progname message = yield else progname = @progname message = message_or_progname end progname_message(progname, message) end def progname_message(progname, message) progname.nil? ? message : "#{progname}: #{message}" end end
「人材の流動化か囲い込みか（http://remote.seesaa.net/article/147006872.html）」で示される問題は、SIerの案件であれば１つや2つはよく起こっている。ここまで問題が積み重なっててひどいのはあまりない（...と思いたい）以下は実際にみてきた現場の惨状。
excel方眼紙はよく見かけます。修正にやたらと手間がかかるので苦痛です。継続的にメンテナンスする必要があるドキュメントには向いてません。あと、ソースコードを日本語訳したようなひどい設計書が多いです。そんなもんソースコードで十分だろって思います。
本番環境でコンパイルしたりとか、恐ろしい事をしている現場がありました。それでソースコードレポジトリとの同期が取れてなくてどのファイルが実際に稼働しているコードなのか分からなくなったりもしていました。
ユニットテストがないのはデフォルトです。テスト仕様書が残っていればまあいい方ですが、テスト項目に「正常に動くこと」としか書かれてない場合もあって信用できません。
5.GUIがひどすぎる
RDBMSをつかったシステムで、会社の休業日を管理するテーブルの編集画面にレコード番号が必要かどうかで議論が始まり一時間くらいぐだぐだと会議をしたりします。そんなもん年月日でユニークキーにしておけば十分。いちいちユーザに番号を振らせるという手間をとらせたいんだろうか。
自社で一貫して設計から実装まで担当しているSIerは別として、そうでないSIerには実際にモノを作っている人間は居ない。仕様の検討段階での資料作成から、アーキテクチャ設計、設計、テスト、運用までほとんど外注にたよりきっており、ざっくりなマネジメントをしているだけだったりする。
設計から外注に丸投げしているSIerでは、日本式のやりかたとか言う以前に、そもそもSIerの社内にシステム開発を行ったオリジナルメンバーが存在すること自体少ない。
すでにSIerでは内製することすら出来ない状態まで空洞化している。
元記事のコメントより
コストダウンの名の下に人減らしだけは進みましたが、そのことがどれくらい破壊的な影響をもたらしているかを、上の人が全く理解できていません。上の人ほど開発経験に乏しく、細部を理解できていないのです。
『鉄筋減らしてコストダウン』して住めないマンションを大量生産したマンション販売会社がありましたが、IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。
IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。
ってのは言い得て妙だ。
「SIerはモノを作るのが仕事ではありません、マネジメントするのが仕事です」ｷﾘｯ!
ってよく言うけど、マネジメントに関しても、技術的な問題が起こっても解決するだけの力がないので、下請けに残業してくれという根性マネジメントしか出来てない。顧客から仕様変更の要求があった場合でも、どういう影響があるかも理解できてないので、全部請けてきて下請けに丸投げとか。
たちが悪いのは見当違いなルールを課して管理したつもりになっている事。
外注に頼り切っているSIerでは、アーキテクチャ設計、ドキュメント整備、ソースコード管理、テストの自働化、GUIデザインは社外の他人まかせになってしまっており、現状の開発方法でどのような問題があるのか気づくことができない。そういった現場から遠い場所にいる連中が現場をうまく回すためのルールを作れるとは思えない。
古くは、Windows98とNEC PC-9800シリーズ。
ちょっと前だとJavascript と JAVA。
冗談だと思う人もいるかも知れないが、そういうことの区別がつかなくても、IT業界で年収が高い人はいる。
「でもでも、作る人がいなかったらどうしようもないですよね？」
「どんなに君がいい商品だと思っていても、買ってくれる顧客がいなければビジネスは成立しないんだよ。」
また別のケース。
「〇〇の仕様では〇〇はできない、しかし〇〇することで出来そうだ。これについてどう思うか。」
「よく分からないから任せる。あっ追加コストの掛からない方で」
区別が付かないベテラン上司の言う事は至極まっとうなことを言っていると思う。
しかし、これにより現場の開発者は社内で相談できなくなり、孤立化する。
「よく分からない、あの人のやっていることは難しくて、分からない」
同僚は帰る。現場開発者はひとり黙々と仕事に励む。そして孤立化は進む。
「何のために、誰のために仕事しているんだろう。」
「俺はコミュニケーション能力の欠落した人間として欠陥のある人なのでは。」
こんな増田を書いているIT業界９年目の私も本年度マイナス査定を受けそうだ。
社内で数少ない利益を上げている一人だし、提案営業としても顧客を獲得しているのにも関わらずである。
さて、景気回復まで我慢の子なのか、２度目のキャリアアップ（笑）を検討してみるか。
「ツイッター信者」にその素晴らしさを熱く語られたときの平和で適当なかわし方｜石原壮一郎「大人のネットマナー教室」
http://diamond.jp/articles/-/7884
-----------------------------------------------------------------------------------------------
クラウドほど、経営層の人と現場の人との温度差が激しいIT用語はないと言えるでしょう。
経営層やCIOの人の中には、「クラウドの素晴らしいビジネスチャンスをもっとうちにも取り入れなければ！」という危機感を抱いて、
ことあるごとに現場の人への啓蒙活動に励もうとする“信者”が少なくありません。
その博愛の気持ちは尊いといえば尊いのですが、現場の人がさほどクラウドによるビジネスにメリットを感じない場合は、
どう対処していいのか困ります。今日も全国各地で、クラウド信者の経営層の熱い講釈を受けて、
尻を叩かれる現場の側が苦笑いを浮かべているという構図が繰り広げられていることでしょう。
自社がクラウド事業に参入することにさほどメリットを感じない側のあなたが、そういう災難にあったときはどう対処すればいいのか。
程度の差こそあれ、クラウドを熱く勧めたがる信者のみなさんは、「クラウドによってもたらされる新たなビジネスチャンス」を信じ、
そんなクラウドの知見を人より早く深めていることに、ちょっぴり優越感を抱いていると言えるでしょう。
どう見ても熱が入りすぎている人の中には、クラウドに過大な望みを託して、
いまいち不本意な会社の現状から自分達を救い出してくれる救世主のように見ているように思えるケースもあります。
いや、あくまで極端な例をあげているだけなので、「俺は違う！」とムキにならないでください。
もちろん、私の周囲のクラウド好きの経営層やCIOや上司に対して、私がそういう目を向けているわけでもありません。
今後の人間関係を考慮した言い訳で話がそれましたが、クラウドを熱く勧めてくる人にとって、
クラウドにはまっていることが誇りであることは確か。何はさておき、そこを見逃さないようにしましょう。
たとえば、最近クラウドにはまっている経営層や上司に、「うちも取組んだほうがいいだろう」と熱心に勧められたとします。
自分の会社がクラウド事業に参入する必要性を説かれても、いまいちピンと来ないからといって、
「うーん、よくわかんないですねえ。コアコンピタンスなシステムをみんなが勝手にリソースを食い合いしている共用環境に置くなんて
なんか気持ち悪い世界のようにも思えるんですが」
「柔軟にリソースを拡充できるっていっても、ハードを跨って分散処理できるシステムならともかく、
結局リソースプ－ルの上限内の話ですよね。なんか嘘っぽいですね」
などと、偉大なる「クラウド様」の仕組みを否定する言い方をしてしまうのは危険すぎます。
ムキになってさらに熱く語ってくるぐらいならまだしも、「ハァ～」と深いため息をつきながら、
救いがたいダメ社員を見るような目を向けてくるかもしれません。
まあ、わかり合えなくてもべつにいいといえばいいんですけど、経営層や上司に悪い感情を抱かれたり、
異動のきっかけになるのは避けたいところです。
向こうだって、今の時期たまたまクラウドにはまっているだけで、けっして悪気があるわけじゃないし、
SOAのことを忘れてしまったわけでも、人間として何かを失ってしまったわけでもありません。
一生懸命にクラウドの魅力を語ってくれたら、たとえピンと来なくても、
「なるほど、そういうふうにインフラ環境を意識せずにインターネットでつながるっていうのも、ユニークな考え方ですね」
と、独自性に衝撃を受けたかのような反応をしておくのが、大人の包容力であり相手をそれなりに満足させるマナーです。
そういうふうに言えば喜ぶのはわかっていても、まるでその相手までホメるみたいで抵抗がある場合は、質問に逃げましょう。
「仮想化によるサーバ統合とか、ホスティングとか、ＷＥＢ２．０とか、データセンターにアウトソーシングするのとはどう違うんですか？」
と、クラウドの旧称を持ち出してきて、クラウドの優位性をさらに語らせるもよし、
「なんか利用分だけ請求する従量制課金にして、結果、利益率の低くなるのをスケールメリットで吸収しないといけないんですよね？」
そんな歪んだ先入観丸出しの誤解（じゃないけどな）をわざとぶつけて、ひとしきり説明させるもよし。
いずれにせよ、無理無理と思っている気持ちを覆い隠したまま、相手にそれなりの満足を覚えてもらうことができます。
まったくクラウドに興味がないわけではなく、ちょっと前に自社製品をＳａａＳやＡＳＰ化してやってみたけど、
全然受注できなくて放置してあるケースも、けっこう多そうです。
そういう状態にあるあなたに、はまっている上司や経営層が例によって熱い口調で、
「まずは、機能限定の無償版をいろんなユーザーに提供してみると、フリーミアムの凄さがわかるよ」
「何でもいいからどんどん無償提供すれば、そのうち有償版にアップグレードする客がでてきて利益がでるよ」
とフリーミアム教、じゃなかった、クラウド教、じゃなかった、クラウド界における定番の説得フレーズを説いてきたとします。
「ほお、そうなんですね。今期の研究課題として取組んでみます」
と適当に納得しておくのはいいとして、つい勢いで、
「しかし、ずっぽりはまってますねー。クラウドの話をするときは生き生きされてますし」
などと冷やかしてしまわないように気をつけましょう。
はまっている上司や経営層は、誇らしさの裏側に、多くは無自覚にですけど、
「自社の戦略に自信がなくてクラウドにすがっているように見えるんじゃないか」
「競争力が欠如した製品をクラウドの冠で紛らわそうとしているように見えるんじゃないか」
といった不安を抱えています。
何気ない冷やかしが引き金になって、心の奥の地雷を踏んでしまいかねません。
そこまでややこしい話じゃなくても、はまりっぷりを感心するセリフの裏側に、
「よっぽどヒマなんだな」
「丸投げばっかりで、手動かしてるの外注ばっかりで、Hello Worldぐらいしかプログラム作れないうちの生産部隊が
どうやってフレームワーク備えたPaaSなんか構築するんだよ」
なんせ今までビジネスセンスではなく社内の空気を読む根回しセンスで出世してきた経営層や上司だけに、
仮にビジネスセンスのないことに対してカケラも自覚がなかったとしても
（カケラも思っていないケースは稀ですがビジネスセンスがないことは稀ではないでしょう）、
相手はそう受け取るでしょう。
はまりっぷりに対しては、ひたすら、
と前向きな返事をすることが無難であり、相手に対する大人のやさしさ。単なるおためごかしではなく、
そのセリフを聞いたときの上司の満足そうな表情を見ることで、社畜としての深い喜びも味わえるでしょう。
仮に、クラウドの話題をきっかけに経営層や上司との距離を縮めたいなら、その場の口先だけではなく、次に顔を合わせたときに、
「あれから、SalesForceとかGoogle AppsとかAzureとかAmazon WSとか、試験導入してPythonやJavaでHello World作ってみましたよ」
と具体的な実績を話せばバッチリです。
熱く勧めてきた上司や経営層が、特に自分の進級昇格を左右する人物だったりした場合は、
とりあえず勧められたとおりにやってみて、クラウドの魔力に魅せられたフリをしましょう。
「やってみると使えますねー。勧めてもらってよかったです」
とまで言っておけば、さらに完璧。
たとえ動機が不純でも、それをきっかけに部内から企画をあげたという実績ができればこっちのものだし、
上司としてはこの上ない喜びを……おっと、結局、経営層へのご機嫌取りという本音が出てしまいました。
曖昧な立場で書いてきましたが、私は何を隠そう、嫌々クラウド事業に取組んでいる社畜のひとりです。
スケールメリットなんか出せねえんだから競争力ある価格設定なんか無理、
無理矢理仮想化しなくても安いサーバで提供すりゃいいんじゃねーの？
そもそも高い人件費のプロパー使ってレンタルサーバ屋と競争してどうすんのよ？
とかいう会社じゃ言えない本音に悶々としながら、仕事中にこっそり書かせていただきました。
そんなことを踏まえつつ、それぞれの立場や環境に応じてお役立ていただければ幸いです。
※
次回も、引き続きクラウドをテーマにしてみたいと思います。（嘘）
今期の事業戦略などで、「クラウド事業への取組み」なんつーキーワードが出始めた場合の対処法や、
自分に企画立案を振られた場合の振る舞い方について考えてみましょう。
■今回のマナー
「クラウド信者」が抱える誇らしさと不安――その両方を見逃すべからず
全然かわせてねー！なんか立案しないとマズい
明日から本気出す
ゲームを作りたい C言語の基礎を学ぶ それだけじゃゲームが作れないことが判明
win32apiを学ぶ 多すぎて？状態で挫折
ゲーム作るのはあきらめよう！チートだ！ アセンブリが面倒で挫折
向き不向きってあるよね・・・。もう勉強したくない・・・。
俺には向いてないんだろな。だってwin32apiでGUI作りで投げ出したくなったもん
俺の読んだ本
明快C言語 ダイテルC言語（例題飛ばしたのでほとんど意味なし） やさしいC 独習C
windowsゲームプログラミング（最後のテトリスとブロック崩しが面倒で飛ばした）
独習java（ガベージあたりで挫折） windows32api徹底理解 ホームページ作成の本（名前失念）
アセンブリ言語の教科書（100ページあたりでソースを読み解くのが・・・以下略）
何のために勉強しているかわからなかった・・・たぶんC言語の基礎すら身についてないと思う
じゃあweb関連や初心者用言語（php,ruby,pythonとか）学べばいいじゃんってネットで指摘されたんだけどさ
そうじゃないんだよ問題なのは。ライブラリの使い方がわからないし必要な技術がそれだけじゃないだろうし
今roboformのようなもの作りたいんだけどどうつくったらいいんだろ（guiは無理なのでコンソールで）
perlとかruby,phpで記述して通信プロトコルの勉強すればできるんだと思うんだけど俺にはもう体力が残ってない
あまりにも無駄な遠回りをしてきた。でも願望だけが空回りしてる。ライブラリもごまんとあるうえに通信プロトコルも勉強しないといけないんでしょ。甘えっていわれてもかまわない誰か助けて
