Google I/O 2013 の基調講演のライブ・ビデオから。
ベクター画像になって、検索が軽くなって、ルート検索がスマートになって、Google Earth 機能も付いて... 変化が多すぎて追いきれない。
新 Google Maps のリリースは? すぐ。翌朝とのこと。今、アメリカは夜だから、12 時間もすれば新 Google Maps を見られるかな。日本だとお昼頃から見られる様になるのかしらん。
新 Google Maps は招待制で、ベータ用の URL が用意されている。下記サイトに招待状メールの発送ボタンがある。
Google I/O 2013 の基調講演のライブ・ビデオから。
Android Studio という Android 開発環境がリリースされる。new editor と言っていたから、Eclipse のフォークではなく、新アプリなのかな? ちょっと分からない。IntelliJ ベースとのこと。
複数のスクリーン・サイズのテストを一度に出来るデモを見せていた。Android の問題の一つは、統一されていないスクリーン・サイズだからね。これは良い機能。
Android の開発も楽しくなりそう。
Google I/O 2013 の基調講演を見た。Google+ のアップデートが目をひいたので、記事にしおく。
ぼくは新 Google+ を見ていない。ライブ・ビデオの記憶を元に書いているので、間違いがあればごめんなさい。
新 Google+ の見た目は、アニメーションを排す。Facebook の様なカード式の落ちついた感じになる。Flat Card と呼んでいたかな。ライブ・ビデオでは見やすそうだった。
Google+ の画面は、どうも長く見続けるのにつらかったので、この変更はありがたい。
Babel というコードネームは触れられなかった。ただし、新しいアイコンとアプリが提供される。Android アプリ、iOS アプリは今日リリースされる (というけれど、まだ見つからない)。
アプリは iOS/Chrome 版がリリースされている。
Nexus 7 では Hangouts はサポートされていなかった。何故?
Gmail の chat も Hangouts に対応する
Google+ が見た目落ちついて、それでいて Google Wave の様な先進性を入れてきた。ユーザーを驚かさない様に小さな変化だけれども。新しい Google+ を早く使ってみたい。
このエントリーで書きたいことをまとめてみたら、大仰なタイトルになってしまった。事の発端は知人から転職の相談を受けたことに始まる。ただ、あたしってほんとバカ……だし、最近風邪気味でその人と会うのが少々憚られる。とはいえ、「早めに来てもらえないか」との言葉をもらったので放置することも出来ない。そこで、個人情報が出ない程度に一般化して自分の考えを纏めてみた。
知人は、ここでは次の様な人間としておく:
なお、本エントリーはぼくの転職記事で書いたことも繰り返しているので、よろしければそちらもお読み頂きたい。
以下、知人向けのメールという形で本文を書く。従って、clmemo@aka の文体は控えることとする。
こんにちは。IT ベンチャー企業への転職を考えていると伺いました。
拙い私の経験を元にしてではありますが、参考になればと筆を取ります。
まず、ベンチャー企業の定義を明確にしたいです。「ベンチャー企業」の定義が喰い違っていては、議論が平行線になることもあるからです。最近、知ったのですが「ベンチャー企業」というのは和製英語なのだそうですね。
そもそも”ベンチャー企業”という単語は日本人が作った和製英語で、通常英語で”Venture”と言うとVenture Capital (VC) など投資をする企業や人を指す。
海外ではスタートアップ企業という用語をよく使うようです。しかし、これは日本でいうベンチャー企業とは違います。上記ブログの説明を再び引用します。
実はアメリカで”Startup”と呼ばれるかどうかは、会社の設立年数や規模はあまり関係無い。むしろどんな事をやっているかや、どんなチームで構成されているかを中心に、その存在目的や組織の構成、成長スピード、収益方法、目指すゴール等の内容において一部の特殊なタイプのものをスタートアップ (Startup) と呼ばれる。
この記事の説明はなるほどと思いますが、日本においてスタートアップ企業がどれだけあるか疑問です。それも世界に影響を与える程のスタートアップ企業となると、寡聞にして私は知りません。
少し話が免れました。
ベンチャー企業とは何か? 日本で「ベンチャー企業」と呼ばれる代表的な企業を挙げてみます。Google, Yahoo!, DeNA, GREE。社歴が長いですが創業当時を考えれば、Panasonic (旧・松下電器産業株式会社) や Sony も日本を代表するベンチャーです。
岸博幸氏が面白いことを言っています。
昔のソニーは面白いものを作りたくて入社した、今はただソニーに入りたくて入社している
朝ナマ「激論：アベノミクスは日本を救うか」を見て「1」130331 - 安岡明夫（[email protected]） - Yahoo!ブログ より引用
私は、自分が面白いものを作りたくて会社を選びました。そう、かつてのソニーの社員が入社したようにです。
一方、ベンチャー企業と言われる Google や DeNA では、「Google に入りたくて入社している」人や「DeNA に入りたくて入社している」人を見かけます。それは企業のブランド力が強くなり、安定した企業となったことの証明なのかもしれません。
しかし、私はそういう安定性やブランド力を求めて職探しをしませんでした。ですから、私が語れるのは「歴史が浅く、小規模な企業」でかつ「企業のやりたいことと、社員のやりたいことがマッチしている」ところへの転職となるでしょう。このような「限定的ベンチャー企業」への転職について書きます。
企業が一番求めていることは何か?
いくつか企業を受けて感じたのは、社風とマッチしているか? ということでした。ここでいう社風は 2 つあります。
第 1 点。会社は小さいです。必然、一人一人の仕事の重みが増します。上から降ってくる仕事をやるだけの社員では務まりません。自分から動いてくれる社員が望ましいです。そういう社員の多くは、会社の目的と社員の目的が一致しています。
目的のマッチ度合は一概に計れません。ですが、自分が何をやりたいのかを明確に持つことは必要でしょう。自分の目的をちゃんと見定めなくては、会社の目的とのマッチングなど取れるはずがないからです。
言い換えれば、その会社の福利厚生であるとか面白手当て (小さな会社は、大手にないちょっと面白い手当てを支給していることが多いです)、働き方やワーク・ライフ・バランスなどを目的に会社選びをしても大低面接で見透かされます。
第 2 点。人の集まりは、コミュニケーションの集まりです。小さな会社では、社員同士が円滑にコミュニケーションを取れるかどうかは死活問題です。どんなに会社の目的と転職者の目的がマッチしていても、社員達が作った会社文化に溶け込めなくては、歯車が回りません。
これは、事前に知ることが難しいです。ただ、小さな会社はこの点を重視しているので、「社内の雰囲気を見せて欲しい」と言ってみるのは良い手だと思います。大手の会社では一部しか見ることができません (そもそも、仕事している所へ入れてくれないことが多いものです) が、小さな会社だと社内を案内してくれることもあります。まあ、ある程度、「採用」を決めている人に限るかもしれませんが。でも、このお願いは試しにすることをお勧めします。
会社の雰囲気が合わなさそうであれば、その時点で自分から断る方が良いでしょう。もちろん、会社も転職者が社内の雰囲気になじみそうか見ていると思います。リスクを大きくしているように感じるかもしれませんが、本当に良い転職を望むなら、目先のリスクを大きくして転職後のリスクを小さくできたと考えれば良いと思います。
エンジニアとして転職するなら、会社が使っている主な言語に精通していることが望ましいです。やはり、中途採用者には即戦力を求めていますから。ただ、これは絶対というわけではありません。実際、私は Rails でメインに開発している会社に、Rails アプリを一つも作ったことなく入社しましたから。
これは、プログラミング言語がある程度同じなことが理由でしょう。C++, C#, Java, Ruby といった言語は一つに修熟していれば他の言語の修得もた易いものです。他の言語をすぐに修得できる実力さえ見せることができれば、言語の壁はあまり大きいとは思いません。実際の開発では、何らかのフレームワークとライブラリーを使っているものです。高望みをすれば、これらのフレームワークとライブラリーを実務で使うのと同程度に使いこなせることが理想なのでしょう。ですが、そんな都合の良いエンジニアはそうそう見つかりませんし、業務に入れば嫌応なく覚えなければならないので、プログラミング技術の高さがある程度あれば良しとする気がします。
もちろん、会社によっては一つの言語のエキスパートを集めた所もあります。そういう会社に入社するには、「その言語」を修熟する必要があるでしょう。
私は言語の壁よりも開発スタイルの壁の方が厚いと考えます。
プログラミング・コードを書くのに「構造化プログラミング」の修得は必須でしょう。今は開発スタイルとして次のどれかを実践したことが望まれます。
加えて、下記ツールも使い込なせておくと良いでしょう。
技術力や人格は、たった数回の面接で分かるものではありません。そして、最大の問題として、小さな会社には「採用」のプロがいないことの方が多いです。大手企業の人事部、中途採用の面接官、ヘッドハンティングをする人達ですね。彼らがいません。
他の仕事をしている人が兼任で行ないます。そういう彼らに正確な情報を与える手段があります。github、ブログ、twitter、Facebook です。
どれも長い年月をかけて転職者が残した足跡です。他人に偽ることが出来ません。偽造することも出来ません。
github では、転職者の技術力・コーディング能力・開発スタイルを見てもらうことができます。
ブログは技術ブログであることが望ましいです。修得した技術の知見、及び技術の文章化能力を見てもらうことができます。エンジニアといえども、ドキュメントを書く必要はありますから、文章力も疎かにできません。
Twitter と Facebook ではコミュニケーション能力を見てもらうことができます。転職者が個人情報や社外秘情報を流したりしないか、社外で素行が悪くないか、を知ってもらうことができます。基本、趣味の内容はスルーされると思って良いと思います。人がどんなアニメを見ようが、会社にとっては関係ないからです。それよりも社外に出してはいけない情報を流していたりすることの方が重要です。
github もブログも Twitter も Facebook も採用担当者に存在を伝える方がメリット高いと思います。ただブログ、Twitter、Facebook はプライバシーの問題を含むので、会社に教えるかどうかは転職者の自由にしたら良いと思います。
私の見た感じ、月 20 万〜 30 万というのが相場でした。月 35 万円出ると上ランクのエンジニアです。新しい会社ですから、社員も若いのです。平均年齢 20 代の会社も多くあります。歳相応の給金でしょう。
しかし、そういう会社に 30 歳を越えた人間が入っても「年功序列」に高い給料が払われることはありません。給料は前職より低くなるでしょう。世の中には Google や Sony で高給を取っていた人々がベンチャー企業に入り、給料が下がったという話も聞きます。志や夢を追うことも良いです。でもお金の問題は家族の問題です。小さな会社ですから、潰れることもあるかもしれません。皆、そういう覚悟で会社に心を与けています。
貯金やローン、今後の子どもの養育費などを考えて転職先を選ぶことをお勧めします。
大手の家電メーカーでは組み込みプログラマーも健在です。組み込みプログラミングは制約が多いですね。オブジェクト指向型のコンパイラーの動かない環境、ANSI C すら通っていない C コンパイラーでのコンパイル、アセンブリでの直接コーディング。
ウォーターフロー開発で C やアセンブリしかコーディングしたことがない場合、IT 企業への転職は難しいです。
ただ、最近はハードを作る会社も現れ始めています。Cerevo やユビキタス・エンターテインメントなどです。世の中には、私の知らないハードを作る会社があることでしょう。
生憎、私はハード系の会社をよく知りませんが小さな希望はあると思います。
プロダクト・マネージャーをなさっているのですね? 社員数が 2、3 人の小さな会社では厳しいでしょうが、エンジニアだけで 20 人くらいの会社であればプロダクト・マネージャーを必要としている場合があります。
前職において大きなプロジェクトを成功させた、もしくはチームの開発をウォーターフォール開発からアジャイル開発に移行させることに成功した、といった成功事例を持っていれば転職先はあると思います。ただし、少し成熟した会社になってしまうでしょう。
私は正直に伝える方が良いと思います。詳しくは過去記事「アクトインディに入社しました」に書きました。自分の「不安要素」を伝えて、それを受け取める会社でないと、お互いが不幸になると考えています。
IT 企業は激務が多いため、心の病気を発症してしまう人も多いです (悲しいことですが)。その分、人事は、心の病気を持った人達との付き合い方を、他社に比べて知っているように思います。小さな会社では、不幸にも受け入れられない所もあるでしょう。逆に、社長自身が心の病気を患った経験を持ち理解のある会社もあるかもしれません。
心の病気を隠して、数か月も持たずに退職したという話も聞きます。「心の病気があります」と言う勇気が必要だと思います。
30 歳を越えるということは、10 年以上企業で働いたわけです。その間、良いこともあったでしょう。嫌なこともあったでしょう。転職を考えるからには、辛いことが多かったのかもしれません。
しかし、レイオフ通知を受けたのでなければ、貴方は企業にまだ求められている存在です。
過去に辞めようと考えた時、誰かに引き止められはしませんでしたか? 手術や病気で長期入院をしても、自分のポストは残っていませんでしたか? 自分の仕事がままならない時、サポートしてくれた人はいませんでしたか?
企業という組織は意外と冷たいものです。ですが、その中で働いている人達には温かい人もいます。ポジティブに思い返してみませんか?
本当に転職は必要でしょうか? 企業に残るという選択肢はありませんか?
IT ベンチャーに転職するのであれば、企業から逃げるように会社を探しているようでは失敗すると思います。やりたいことがあって、今の企業では出来なくて、小さな会社に移ってでもやりとげたい「想い」があってはじめて「成功する転職」があると思います。
改めて書きますが、本エントリーは私の体験を元に「小さな IT ベンチャー」に転職するケースだけを書いています。大きな IT ベンチャーや同業他社への転職は、私自身に経験がないので書けません。そして、このエントリーに書いたことも、一人の人間が一回の転職をした経験から書いたものです。参考にして頂きたいとは思いますが、盲信はしないで下さい。
Google は Gmail と Google Drive と Google+ の容量を「統一」してカウントすることを発表した。統合された容量は、全部で 15 GB になる。なお、Google Apps ユーザーに対しては 30 GB が与えられるとのこと。ストレージ統合は、今後数週間でゆっくりとユーザーに展開される。
今までは Gmail に 10 GB、Google Drive と Google+ (Picasa Web Albums) に 5 GB の容量が個別に割り当てられていた。今回の統合によって、各サービスの垣根がなくなる。
現在の利用量は、Google Drive Storage ページで確認可能。
ストレージ増量オプションは 2 つ (もしかしたら、もっと上のモデルもあるかもしれない)。$4.99/月 の 100 GB モデルと $9.99/月 の 200 GB モデル。今までの 25 GB ($2.49/月) は撤廃。
思い返せば、大容量ストレージの始まりは 2004-04-01 の Gmail 発表から始まった。当時、フリー・メールのストレージ容量が 20 MB 程度だった頃に 1 GB の容量をひっさげて Gmail は登場した (最初は招待制だった)。後に Gmail は 2 GB, 7 GB と大きな増量を重ね、日々ストレージ容量を増やしながら 10 GB にまで達した。
人というのは面白いもので、容量が急激に増えても対応してしまうらしい。Gmail の最初の 1 GB を使い尽した人は多いと思うし、10 GB の MAX に近づいている人も少なからずいる。
対抗するサービスも Google にヒケは取らない。Yahoo! Mail (米) は容量無制限だし、Microsoft の Skydrive は最初 25 GB の容量でスタートした (今は 7 GB にストレージ容量が少なくなって残念)。Amazon や Dropbox なども次々と Google を脅かす存在になっている。
ストレージ容量が大きいことがアドバンテージになることを Google は実証してみせた。今、複数のサービスが Google のストレージに迫るか上回るかしている。そして、Google はストレージ統合を行ない、使い勝手の向上を目論んだ。ぼくには、まだ他社サービスを大きく引き離す力に欠けている様に感じられる。Google の第二手を楽しみにしている。
ぼくは git add する時、-u オプションを好んで使う。-u オプションは --update の省略形。git 管理下にあって、変更のあったファイルだけを git add する。
gid add . だと、カレント・ディレクトリー以下に出来た中間ファイルを誤って add してしまうこともあるけれども、-u オプションを使えば、そういうミスがないので気に入っている。
今、ぼくの使っている git のバージョンは 1.8.2.1。次なるメイン・バージョン 2.0 で -u オプションの仕様が変わると警告が出てきたのでメモしておく。
変更の理由は何だろ? 安全性を高めたいのかな?
すぐに忘れてしまいそうなのでメモ。
一応、現れた警告テキストもコピーして残しておこ。
warning: The behavior of 'git add --update (or -u)' with no path argument from a subdirectory of the tree will change in Git 2.0 and should not be used anymore. To add content for the whole tree, run: git add --update :/ (or git add -u :/) To restrict the command to the current directory, run: git add --update . (or git add -u .) With the current Git version, the command is restricted to the current directory.
最近、clmemo@aka の更新情報が Facebook page に反映されない。見ると、2012-04-25 から更新がない。今日は 2013-05-05。この間に 13 本の記事を書いている。どうも、ブログ更新を Facebook page に通知する RSS Graffiti の調子が良くない。
今日、sorarium さんも RSS Graffiti の不具合に悩まされていると知った。sorarium さんは RSS Graffiti から IFTTT に移行した。ぼくも習ってみる。
設定方法は sorarium の記事に詳しいのでサラリと。
「Choose Action Channel」で「Facebook page」を選択 (右側ね)以上で終了。さてどうなるか... 結果が見えたら、スクリーンショットを貼る。
お、上手くいった。
rbenv 版の ruby が rvm 版の ruby よりも遅いという話がある。理由を調べてみると、最適化オプションに違いがある。rvm には -O3 オプションが使われていたのに対して、rbenv では -O2 オプションが使われていた。この最適化オプションの違いが ruby のスピード差になっている。
ruby-build の git log を見るとこうある。
commit 9f8d53365aef52c940095f583cdc82f02caba90f Author: Erik Michaels-Ober <[email protected]> Date: Wed May 1 07:38:43 2013 -0700 ruby-build 20130501 commit 2f8dcafb0ec2c5f478e7f45d7eca3a0f0a5ae8c0 Merge: 28b9bcb b219192 Author: Sam Stephenson <[email protected]> Date: Fri Apr 26 16:00:19 2013 -0700 Merge pull request #351 from jeremy/restore-o3-cflags Restore -O3 default when we build with clang commit b219192020b4641e057c9f168089f8488624ec64 Author: Jeremy Kemper <[email protected]> Date: Fri Apr 26 15:06:43 2013 -0700 Restore -O3 default when we build with clang
2013-04-26 に -O3 オプションが適用されるよう修正が入っている。
rbenv に reinstall サブコマンドはない。ただ、install サブコマンドに --force オプションを付けると、強制的にもう一度インストールできる。これを使って、ruby を再インストールする:
$ cd ~/build/ruby-build $ git pull $ sudo ./install.sh $ cd ~/.rbenv $ git pull $ cd $ rbenv install --force 2.0.0-p0
rbenv で -O3 オプションが適用される様になったことは書いた。ログを見るとコンパイラーが clang の場合に -O3 オプションが使われる様になっている。GNU gcc の場合はどうなのかな? そこまでは調べていない。
過去記事の内容が古くなっていた。新しい方法をメモ。
過去記事では vagrant は ruby の gem だったけれども、バージョン 1.1 以降 (?) vagrant はパッケージとして提供されている。2013-05-05 現在、最新版は 1.2.2。
$ pwd ~/project/vagrant $ ls Gemfile Gemfile.lock vendor Vagrantfile
念のため旧 vagrant でインストールした vagrant の OS イメージは破棄。gem はもう使わないので、Gemfile を削除。vagrant コマンド一式は vendor ディレクトリー以下に入れているから、ディレクトリーごと削して旧 vagrant の削除は完了。
$ bundle exec vagrant destroy $ rm -rf Gemfile Gemfile.lock Vagrantfile .bundle vendor
Vagrant のダウンロード・ページから最新版の Vagrant dmg を選択して、ダウンロード & インストール
$ which vagrant /usr/bin/vagrant $ vagrant -v Vagrant version 1.2.2
うん、最新版の vagrant がインストールされた。インストールの方法は前と変わらない。
$ vagrant box add ubuntu12_10 https://github.com/downloads/roderik/VagrantQuantal64Box/quantal64.box $ vagrant init ubuntu12_10 $ vi Vagrantfile
Vagrantfile の中身は次の通り:
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu12_10"
config.vm.network :private_network, ip: "192.168.50.12"
endconfigure("2") は Vagrant 1.1+ or 2.0.X の config ファイルを指す。仮にこれが 1 ならば、Vagrant 1.0.x を指す。config.vm.network の書式が変わったので注意。
$ vagrant up $ vagrant ssh $ vagrant halt
以上。
Vagrant 1.1+ の情報を書きました。
最近、Vagrant (ヴェイグラント) という名前を良く聞く。
VirtualBox というツールがあって、これを使うと他の OS を動かすことができる。一般に仮想 OS 環境と呼ばれるもの。Mac OS や Windows の中で Linux を動かしたり、Linux の中で Windows (勿論、ライセンスは必要) を動かしたり... といったことができる。
vagrant は VirtualBox で簡単に OS をセットアップするツール。ruby の gem として提供されている。
VirtualBox サイトから最新の VirtualBox をダウンロードしてインストールする。
vagrant を始めてみる。
今回はローカル環境にインストールしたいので、~/project/vagrant/ 以下に vagrant をインストールする。
$ mkdir -p ~/project/vagrant $ cd ~/project/vagrant $ cat <<'EOF' > Gemfile source 'https://rubygems.org' gem 'vagrant' $ bundle install --path vendor/bundle $ rbenv rehash (rbenv を使ってる人だけ)
以下、vagrant を使ってインストールする OS を選択する。流れは以下の通り:
$ bundle exec vagrant box add {name} http://.../...box
$ bundle exec vagrant init {name}
$ vi Vagrantfile (Vagrantfile の編集)
$ bundle exec vagrant up
{name} 部分のデフォールトは base。base を使う場合は vagrant init 時の {name} は省略できる。
vagrant 用に提供されている OS イメージは下記サイトで公開されている。
例えば、「Ubuntu 12.10 Quantal x86_64 (Guest Additions 4.2.2)」を vagrant でインストールするなら URL は「https://github.com/downloads/roderik/VagrantQuantal64Box/quantal64.box」になる。
Vagrantfile の編集
Vagrantfile の中身はほとんどコメント・アウトされている。書くべき内容は次の二つ。
Vagrant::Config.run do |config|
config.vm.box = "base"
config.vm.network :hostonly, "192.168.50.12"
endbase の部分は、vagrant add の時に付けた名前が付ける。デフォールトなら "base"。
ssh でログインできる。
$ bundle exec vagrant ssh
インストールが終わったら、四つのコマンドを覚えておけばいい。
今回の vagrant の内容は「入門 Chef Solo」を参考にした。電子書籍は何時でも読めるし検索性に優れるけど、自分のメモにはなり得ない。やっぱり自分でブログの記事に落とし込まないと、頭の中に残らない。
入門Chef Solo - Infrastructure as Code
伊藤直也
伊藤直也 2013-03-11
Amazonで詳しく見る by G-Tools
Gemfile で gem を取得する時、git を使うなら次の書き方ができる。
gem 'rubygems-format-dummy', :git => 'git://github.com/ataka/rubygems-format-dummy.git'けれど、もし git のソースコードを github でホスティングしているなら、もっと簡単に書くことができる。
gem 'rubygems-format-dummy', :github => 'ataka/rubygems-format-dummy'この書式のお蔭で chef 用の Gemfile が更にスッキリした。
$ cat /etc/chef/Gemfile source 'https://rubygems.org' gem 'chef' gem 'rubygems-format-dummy', :github => 'ataka/rubygems-format-dummy'
イイナ。これ。
XML ファイルを Emacs で開いた時に nxml モードで開きたい。色々方法はあるけれど、ぼくは次の様なコードを書いている。
<?xml version="1.0" encoding="utf-8"?>
<!-- -*-nxml-*- -->これも Emacs の File Variables を使った設定方法の一種 (変種?)。
シンプルで好み。