イケてる人材は3つの“J”を持っている ―VASILY 金山裕樹のキャリア論[1]から読む 大手企業とスタートアップとの、決定的な違い。 ― 金山さんは、大手企業とスタートアップの両方を経験されていますよね。両方で求められる能力に違いは感じますか? まったく違うと感じます。決定的に違うのは、ビジネスとして「成立させる」フェーズ。そこにくると、必要になるスキルが全然違うんです。 大企業の場合は、すでに独自の強いビジネスモデルってものがあるんですね。すごく雑な言い方をすると、“Yahoo! の強み”って「どんなページを作ったとしても、広告が入って、収益があがる」ところなんです。Yahoo! として広告がガンガンまわっているから、極論、あとは“どれだけ低コストで広告が入るようなページを量産できるか”の勝負なんです。あとは、自分がやりたいことをビジネスモデルに“どうはめるか”だけを考えればいい。
![エンジニアよ、ゼネラリストなんて目指すな!―VASILY 金山裕樹のキャリア論[2] | キャリアハック(CAREER HACK)](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f58a3e10f06dd303c1c10c9198c4ac511cdea921f%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fimage-careerhack.en-japan.com%252Fold%252Fno_content%252Freport%252F20121129_2fa030e3-07b0-4550-b084-ef507b9d5f04.jpg&f=jpg&w=240)
4月まであと一週間ということで。 昨年書いたのはどうだったかなと見直したら、言いたいことがほとんど書いてあった。 今春“プロ”グラマーになる人が、あと1週間で学ぶ3つのこと(+1) - holyppの日記 簡単に言うと、「経験する前から頭でっかちになるな」ということ。 あるべき設計、あるべきコード、というのはもちろんあるんだけど、それよりも組織の一員として評価を得ることが大事なので、そこにフォーカスすべき。 そのあたりについて、つい先日のこの記事がとても良かった。 入社1、2年は「良き社畜」として騙され続けよ。 で、最後に1回だけ裏切ればいい 人気ブロガー 藤沢数希 聞き手:ライフネット生命保険副社長 岩瀬大輔|対談:入社1年目の教科書|ダイヤモンド・オンライン 中でも、特に良かったのはここ。 藤沢 ロジカルシンキングだかなんだか分かりませんが、指示されたことに対して理詰めで、これは間違っ
Latesttopics > より良いコード 宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! «CSS3のborder-imageを先行実装した-moz-border-imageの仕様変更とその対策 Main tabFx2Compatible.xul、tabFx2Compatible.css、tabFx2Compatible.xmlを使わないようにした » より良いコード - Feb 01, 2012 自分で自分の書くプログラムが(道具として使って目的を達成できるかどうかという評価ではなくて、プログラムコードそのもの綺麗さとかそういう意味で)良いかどうかっていうのは正直よくわかんない。もちろん「良いコードを書こう」と思って意識はしてはいるけど、他
「気分やノリがソフトウェア開発には重要だ」と断言し、そこに注目して自らRubyを開発してきたまつもとゆきひろ氏は、どのようにしてプログラマに育ち、Rubyを生み出し、そして開発を続けてきたのでしょうか? 今や日本初のオープンソースソフトウェアとして100万人規模のユーザを持つRuby。数々の賞を受け、なおも変化と成長を見据えるまつもと氏が日本最大のゲーム開発者向けカンファレンス「CEDEC2011」にて、自らの若かりし日々から長いRubyの開発の歴史とそこで培われたコンセプト、そして未来への展望までを余すところなく披露してくれました。「Ruby開発が教えてくれたこと」と題されたこの講演の全内容は以下から。 まつもと: はじめまして、まつもとゆきひろです。 最近はRubyを開発した人ということで有名になりましたが、Ruby自体ゲームのソフトウェアというより、それを動かすサーバとして使用して頂

_ TDD、リファクタリング、フレームワーク ちょっとした案件があって8本ほど、アプリケーションを作ったのだが、仕様は単純、内容は明白だったので(あと、ユーザインタラクション系だというのもあるけど)、ついTDDせずに1本作った(別に強力なテストチームがいるからお任せモードというのもあるが、もちろんTDDのテストとは異なるから言い訳っぽい)。で、また一本、そして一本。 3本作って、それらすべてに共通する構造があれば、フレームワークが作れる。 というわけで、簡単なフレームワーク――というよりもテンプレートメソッドパターン(ファクトリメソッドパターンを含む)を実装クラス(十分に小さなやつなのでファクトリクラスを兼ねる)と、そいつを回すストラテジパターン――を実装し、4本目からそれを使うようにした。当然のようにあっというまに8本できる。 そこでしまったと気付く。 最初の3本が浮いている。が、既に動
ソフトウェアエンジニアの中には、(手)作業を一生懸命行って、仕事した気になる人がいます。あるいは、開発組織の中には、手作業の手順を文書化して管理することを重要視していたりします。 単純な作業は、コンピュータが得意とするところです。ところが、それは、作業手順を自動実行可能なスクリプトとして人間が用意することで達成される訳です。 したがって、ソフトウェアエンジニアとしては、誰かから作業を引き継いだり、作業を指示された時に、「これはコンピュータにやらせるべきことか、それとも、やはり人間しかできない内容なのか」を考えることが求められます。そして、作業は積極的にコンピュータによる自動化を行うことを心がけることが重要です。 手作業や手順書の大きな問題点は、作業をきちんと行ったことを監査できないことです。作業手順が文書化されていても、実際の人間が間違いを繰り返せば、対策として、手順書をきちんと守ったかを

“イトケン”こと伊藤賢治氏と“ヒャダイン”こと前山田健一氏が初遭遇。音楽的ルーツからゲーム音楽について思うこと,そしてプロ論に至るまで語り合ってもらった 編集部:TeT カメラマン:増田雄介 ←123456→ 制作機材を入れ替えることの怖さ 制作機材を入れ替えることの喜び 伊藤氏: ところで前山田さんは,どんな機材を使っているんですか? 前山田氏: 僕はWindowsです。64bitと32bitのPCで「Cubase」(※46)を中心に,ソフトシンセで作り上げています。伊藤さんは? 伊藤氏: 僕は最近まで,Windowsの「SONAR」(※47)を使ってきました。スクウェアの頃はMacで「Vision」(※48)を使っていたんですが,Visionがなくなってしまったので,泣く泣く「Digital Performer」(※49)に行くしかなかったんですよ。ところが,PowerMacからInt
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしているエンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への

食事を抜く、おざなりにする 朝食、昼食、夕食を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず食事をとること。食事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな?とあれもこれもと手を出すうちに2,3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか?QAやテストやドキュメントなどはいりませんか?誰に承認をえるのですか?これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。本当に足りないことはあ

なかなかちゃんとしたブログ記事書く時間もないので、チラ裏してみます。 厨房時代 パソコン部に入る 兄が残した『こんにちは!マイコン』という本を読んでBASIC をやる。詳細よく覚えていない 16パズルを作ったはずなんだけどソースはもちろん残っていない 工房時代 実家は自営業なので、家業のホームページを作るよう頼まれる 技評の本を買う Web 標準とかその辺に一時期凝り、よくわかんないインターネットの争いに巻き込まれたりするCGI やったり、 Delphiでフリーソフトウェア作って配布している人たちはリア充だと思っていた 大学時代 大学デビューを志していたのでプログラミングしてない 就活 営業とか出版社とかに落ちまくり、当時なぜか「SEなら誰でも内定もらえる!」 という話があったんでSEで応募したら内定が出た 就職後 DWH(DHH じゃないよ) っぽいシステムの運用からキャリアが始まる
確かにCでしか書けない類のプログラムは存在する(例を挙げるならKernel)が、それはCの存在を赦す理由にはならない。確かにCに輪をかけてさらにダメな類のプログラミング言語は存在する(例を挙げるならC++)が、それはCの存在を赦す理由にはならない。確かにCでしか書けないダメプログラマは存在する(例を挙げてほしければここにおまえの名前を入れろ)が、それはCの存在を赦す理由にはならない。 そもそも計算機にできて算盤にできないことなど存在しない。存在しないんだぞ。なのに何故人はプログラムを書くのか。それはオートメーションのためなのであり、奴隷的使役から人類の尊厳を開放して、この地上に楽園を築くためである。まあそこまで大上段に振りかぶって普段から書いてる輩はいないにせよ、プログラミングとは楽をするため、豊かな人生を実現するため、誰かの幸福のために行うものだ。違うか?じゃあなぜプログラムを書くんだ?
釣りの仕方を教えてもらうという機会は人生においてそうそうあるものではない。老子曰く「授人以魚 不如授人以漁」。魚を与えるのではなく、釣りの仕方を教える。ということらしい。*1 新卒は、研修でいろいろな釣りの仕方を教わっている最中かと思う。新人ゆえの特権だ。中途入社の人間は基本的には放置というのが世の常だろう。釣り方は既に身につけているという前提で雇用されているのだからしょうがない。 よく考えてみると例えばDebugの方法とか誰かに教わったかというと多くの人は見よう見まねでどうにか自分のスタイルを確立していったのではないだろうか。いまでこそ、テストの方法とか、ソースコードの読み方のような書籍があるけど、そのようなものは例外的な存在のような気がする。IT業界のような変化の激しい業界では、2年前には影も形もなかった技術がぽっとでてきて業界を席巻しているようにみえる。そして、そのようなものは当然
http://togetter.com/li/130686 およそプログラミングを志すものとして,より開発効率を上げるために優れたツールを使いこなそうと努力しない人間に未来はない. 「統合環境を使え(キリッ)」と言えるのは,Java,VB.NET/VC.NETなどのごく一部の言語だけというのは分かっているんだろうか. 統合環境ってエディタ,コンパイラ,デバッガ等を組み合わせただけのもの.そして特にエディタは非常にショボい. ちなみにEmacsイラネとか言ってる人は,EclipseにだってEmacs風キーバインドはあるという意味を,どのように捉えているんだろうか.vimやEmacsは単なる手段ですよね。大事なのはアウトプットの品質。そういえば「仕事してる感じを出すために、会社のPCでは常にDOS窓を開いている」という人を以前見かけました。。。アウトプットの品質を高めるためには,開発効率を

2011年5月3日(火)〜5日(木)に開催された第21回 世界コンピュータ将棋選手権*1が終わった。 結果は次の通りで、激指、GPS将棋が上位から転落。長年、決勝で活躍していたYSS(≒AI将棋)に至っては来年は決勝に残れるかどうかすら怪しい。 もちろん、この3つのソフトにしても昨年に比べて弱くなっているわけではないので、他のソフトが伸びてきたということだ。いま、まさに世代交代が起きようとしている。 コンピュータ将棋にこれほどまでの伸び代が残されていたという事実には驚きを隠せないが、今回の結果に関しては次のまとめがわかりやすい。 そんな大波乱の大会ではあったが、優勝したのはA級リーグの伊藤さんだった。 http://aleag.cocolog-nifty.com/blog/ Bonanzaの高速化(bonasse)から、そこで得たノウハウを元に1からソースを書いて、効率的なクラスター並列化

QConTokyo2011 に参加してきました! まともに参加した初めてのセミナーだったため、非常に新鮮でした。 まとめをしたい所なんですが、時間も時間で眠いため、 参加した各セッション毎の決め台詞というか、ポイント一覧だけまずは投稿します。 ドメイン駆動設計:複雑な問題群に対する有用なモデル達 現実/何にでも使える1つのモデルを追い求めるべきではない。 あくまで"何のために?"をベースに役に立つモデルを選択すべき。 設計時に役に立つモデルが見えていることはまず無い。 Webアプリケーションエンジニアがみてきたこの10年エンジニアの誇りとは、高度な技術によって得るものではない。 自らが使命とする問題領域をより高度な技術基盤によって発展させることによって 得るものである。 #微妙に違うかもしれません。 自律的な学びのデザインと誘発 ― 学びのパターン・ランゲージ 変化が激しい現代社会では、
元記事はこちら。 今春“プロ”グラマーになる人が、あと1週間ですべき7のこと | Act as Professional - hiroki.jp by HIROCASTER シリーズ化? 今春サーバを触っていくのにびくびくしてる人が1週間ですべき7のこと - カイワレの大冒険 今春“組み込み”プロ”グラマーになる人が、あと1週間とはいわないけどこれからやってほしい7のこと - what you see is what you get 元記事はターゲットが広すぎたからか、対象を指定したエントリが書かれている。 私はもう一度、対象を広く戻して、自分なりのエントリとしてまとめてみた。 と、いうのも。 元記事は少なくとも「新卒」が一週間で準備すべきことには当てはまらない。 「新卒プログラマーがこの1年で意識すること(マスターすること)」という趣旨なら十分納得できるのだが。 見出し ・プログラミング
1.一般的なコーディング規約に目を通し、エレガントなコードを知る エレガントなコードを書くためには、エレガントなコードを知らなければならい。その土台を築いているコーディング規約について、オープンソースではどのようなものが使われているのか理解しておこう。入社する予定の会社が採用している言語については必ず目を通しておこう。PHP PEAR 標準コーディング規約 symfony CodingStandardsPerlperlstyleRubyクックパッド株式会社のRubyコーディング規準 Matzスタイル NaClで採用している規約Python PEP 8 そして、あなたの身近にあるオープンソースのコードを実際に読んでみよう。この時点でコードの仕組みや設計が理解できなくても良い。コードがエレガントかどうか?を感じ取って欲しい。こう書いた方が、良いのではないか?など、考えてみよう。

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く