「なんでRubyなんか作った!? 迷惑だ！」に対するMatzの答え：Rails Hub情報局：エンジニアライフ
2012年9月に行われた札幌Ruby会議2012の基調講演の1つで、Rubyの生みの親のまつもとゆきひろさんが、最近あった面白いエピソードを混じえて“イノベーション”の本質について語っていました（44分の動画）。ポイントとなる部分をまとめてみました。まつもとさんの話はもちろん、統計的裏付けだとか学問的裏付けがある議論というものではありませんし、ご本人も楽しそうに話し、聴衆も楽しんでトークを聞くというゆるい感じのものでした。ただ、「イノベーションの本質は捉えがたい」というメッセージや、「だからあれこれ考えずにコードを書こう、われわれはコードを書くことにアイデンティティを感じているのだから、それこそがハッピーになる道だ」というメッセージは、参加していたRubyistたちの胸に響くものがあったのではないかと思います。 以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半
Ruby 2.0初のプレビュー版がリリース！ 注目機能は!?：Rails Hub情報局：エンジニアライフ
2012年11月2日、Ruby 2.0.0-preview1のリリースがアナウンスされました。Ruby 2.0はRuby生誕20周年となる2013年の2月24日にリリースが予定されています。現在の安定版であるバージョン1.9系の次のメジャーバージョンアップとなります。ちなみに、1.9の正式版が初めてリリースされたのは2007年12月25日でした。 Ruby 2.0のリリースマネージャ、遠藤侑介さんがメーリングリストに流したアナウンスによれば、2.0.0の主な新機能は以下の通り。 Refinements キーワード引数 Enumerator#lazy Module#prepend Hash への変換メソッド #to_h %i: シンボルの配列のリテラル 正規表現エンジンを Onigmo に変更 DTrace サポート それぞれの機能について特に説明がなかったので、西村が分かる範囲で少し各機能
なぜエンジニアは勉強会で会社名を出せないのか：雲（クラウド）の隙間から青空が見えた：エンジニアライフ
■勉強会で自社名を隠す人々 今年の2月に転職して以降、勉強会やカンファレンスでの発表資料に僕は会社名を書くようになった。 2010年9月にコミュニティで初めてのライトニングトークをして以降、今年の2月に転職するまで、僕は合計9回、ライトニングトークや、セッションで登壇している。そしてそのいずれも、会社名はあえて伏せていた。 そういった場面で名刺交換をする機会はあっても、僕は個人で作成した名刺を使い、会社の名刺を出すこともしていない。その当時、僕がなんという会社に勤務しているのか、おそらくほとんどの人は知らなかったはずだ。 転職以降も、こういった活動は続けているが、今は自己紹介で、どこの会社で、どういった仕事をしているか名乗るようになった。名刺交換でも、会社の名刺を出している。 勉強会やカンファレンスに行くと、様々な人と出会う。登壇者と仲良くなることもある。そういった人たちと話をしていると、
ついに軽量Rubyの「mruby」のソースコードが公開！：Rails Hub情報局：エンジニアライフ
Rubyの生みの親、まつもとゆきひろさんが、ついに新しいRuby実装である「mruby」のソースコードをGitHub上で公開しました！ 2012年4月20日です。ライセンスは、MITライセンスとなっています。 以下にまつもとさんがmrubyについて語るインタビュー動画を貼り付けます。18分30秒のあたりからどうぞ。インタビューは昨秋の時点でのものです。 公開されたmrubyのレポジトリから、Readmeの一部を引用します。 mrubyはISO規格に準拠したRuby言語を様々な環境で動作可能となるように軽量化したものです。モジュール構成によりインタプリタ実行形式やコンパイル＆VM実行形式でも動作させることができます。 2010年度の経済産業省の地域イノベーション創出事業により開発されました。 MRI(Matz Ruby Implementation)版との互換性 以下要修正 + シンプルな文
「だから、作れ」と_whyは言った：Rails Hub情報局：エンジニアライフ
Ruby/Railsと直接関係ありませんが、かつてRubyコミュニティで愛された_why氏の名言を紹介したいと思います。 when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create. – Why the lucky stiff （何も作っていないとき、人は自分の能力よりも好みによって特徴付けられることになる。好みは世界は狭め、他人を排除するばかりだ。だから、作れ） これは2005年頃から2009年にかけてRubyコミュニティで「Why the lucky stiff（_why）」のペンネームで活躍していた、ある多才なRubyistのツイートです。 発言の文脈が分からないので、もし
ナイナイの岡村さん無期限休養に思う「頑張りすぎない生き方」：It’s Party Time!：エンジニアライフ
「ナインティナインの岡村さんが無期限休養」のニュース。 僕がまだ小中学生で、2人が東京（全国放送）の番組に出始めたころからファンとしてテレビでよく観ていたので、この報道にはビックリしました。少し前にも岡村さんは、体調不良を理由に休養したものの、数週間で復帰して「あぁよかった」などと思ったものですが、事態は深刻なようで……。 事務所や相方の矢部さんからは「体調不良で」との言葉しか聞かれないため、ネットではさまざまな憶測が飛んでいます。癌や白血病といった生死に関わる重大な病気なのでは、という説。うつ病やパニック障害といった精神疾患なのでは、という説。いずれにせよ、個人的には「過労」が根本原因なのだろうなと思っています。 ■プロの芸人として頑張りすぎ？ 皆さんは岡村さんにどういうイメージを持っていますか？ gooランキングのアンケート調査によれば「ダンス芸」と「何にでも真面目」が断トツ。やはり「
ベターJavaScript!? CoffeeScriptが注目されるワケ：Rails Hub情報局：エンジニアライフ
JavaScriptへコンパイルして実行することを前提としたスクリプト言語「CoffeeScript」がちょっとした注目を集めています。CoffeeScript自体は2009年末に登場し、その1年後の2010年12月にバージョン1.0がリリースされていますが、注目を集めたのは、数日前（2011年4月13日）にRuby on Railsの生みの親であるDHHが、次期バージョンのRails3.1でjQueryやSCSSと合わせて、CoffeeScriptをデフォルトとして採用するとTwitter上で発言して議論が巻き起こったからです。 Yes, it's true, Rails 3.1 is going to ship with CoffeeScript and SCSS in the box for use with the new asset pipeline. It's bad ass.
優秀なエンジニア5人は二流の1000人を完全に凌駕する：Rails Hub情報局：エンジニアライフ
1990年代後半のインターネットブームの火付け役といってもいいWebブラウザ「Netscape」の創業者で、現在シリコンバレーで投資家として活躍するMarc Andreessen氏が、あるインタビュー中で「優秀な5人のプログラマは、二流のプログラマ1000人を完全に凌駕する」（Five great programmers can completely outperform 1,000 mediocre programmers.）と発言したことで、ちょっとした話題となっているようです。インタビューはライターのBill Taylor氏（個人サイト）が、自著「Marvericks at Work – Why the Most Original Minds in Business Win」（アマゾンUSへのリンク）のためにインタビューした際の答えとして、Harvard Business Revie
実在しない人間関係、行方知れずのサーバ：雲（クラウド）の隙間から青空が見えた：エンジニアライフ
■雲の中の知性 あなたはキーボードとディスプレイを使って、自然言語を用いた対話をしている。 対話相手の顔は、あなたには見えない。あくまでもディスプレイ上に表示される言葉が、対話相手との唯一の接点である。対話相手が、仮にあなたの言葉に自動応答する機械だったとして、あなたがそれを機械と認識できなかった場合、すなわち人間と機械との区別ができなかった場合、対話相手の機械は人工知能を有しているとみなせる。 これは、計算機科学の父 アラン・チューリングが1950年に発表した論文『Computing Machinery and Intelligence（計算する機械と知性）』の中で考案した、人工知能を判定するためのテストで「チューリングテスト」と呼ばれている。 このテストを用いて人工知能を完全に立証できるか、という観点においては、さまざまな議論がなされているが、このテストを人間側に視点を移して考えた場合
炎上プロジェクトに見られる3つの共通点：プロトタイプ開発の日々：エンジニアライフ
わたしは、これまでのキャリアのほぼすべてを派遣先で過ごしています。もともと「火消し部隊」と呼ばれていた派遣先。運良くデスマーチは回避してきましたが、それでも問題のあるプロジェクト、俗にいう「炎上プロジェクト」のヘルプを行ったことがあります。 振り返って考えると、この「炎上プロジェクト」には、必ず共通する特徴がありました。ここでは、その3つの共通点を紹介します。 ■♯1 うそをつく うそをつく……いったい、プロジェクトにかかわる誰にメリットがあるのでしょうか？ わたしが長年お世話になっている顧客からの要請で、直接関係のないA事業部が外注したプロジェクトの手伝いを行うことになりました。作業に着手した時点（＝プレス・リリース前日）で、サーバがSIGSEGV（セグメンテーション違反シグナル）でダウンする状況でした。サーバのダウン状況を再現してほしいと依頼されたものの、サーバの実行形式ファイルは次々
Twitterを捨てよ町へ出よう：雲（クラウド）の隙間から青空が見えた：エンジニアライフ
一般のユーザーにとって、ネットワークを介して利用するクラウド的サービスの中で最もイメージしやすいのは、GmailなどのWebメールや、mixiなどのソーシャル・メディアではないだろうか。そしてその代表格に、Twitterがある。 ふと気付くと、Twitterはいつのまにやらずいぶん普及したようだ。 企業プロモーションにも頻繁に登場し、テレビでは芸人がTwitterトークで笑いを取り、ドラマにまで発展。このコラムの読者にも、利用されている方が多いのではないだろうか。 一方で、フォロワーがつかず「自分のつぶやきに誰も反応しない」と孤独を抱えているユーザーもいるようである。確かに、Twitterに限らず、ブログであろうと掲示板の投稿だろうと、自分の発信した話題に誰もレスポンスを返してくれないというのは、むなしいものである。 ■わたしも昔は孤独でした…… いまでこそTwitterでさまざまな人とコ
Twitterを「捨てる」という発想：＠IT自分戦略研究所の「おすすめエンジニアライフ」：エンジニアライフ
本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部がおすすめするコラムを紹介しよう。Twitterとの付き合い方、仕事の改善方法、炎上プロジェクトに関する3本を取り上げる。 Twitterを捨てよ町へ出よう トップダウンによる改善 炎上プロジェクトに見られる3つの共通点 Twitterは「娯楽の1つ」にすぎない！ SEである粕谷大輔氏による『雲（クラウド）の隙間から青空が見えた』。Twitterとの付き合い方について。 いまやクラウド的サービスの代表格ともいえるTwitter。世間では大流行中である一方、「フォロワーがつかない」「つぶやきに誰も反応してくれない」などの「Twitter疲れ」ともいえる現象が発生している。 粕谷氏はホームページを立ち上げた当初、反応がなく同種のむなしさを抱いたという
チームで働くなら、エースプログラマが集まるだけじゃNG：わたしの愛するエンジニアライフ：エンジニアライフ
本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「チームで働く」。 エンジニアは多くの場合、チームで働くことになる。チームの在り方や、チームリーダーに求められることなど、「チーム」にまつわるコラムを紹介しよう。 チームプレイの本質 「エースプログラマ」が集まっても、プロジェクトが失敗する確率は、普通に人数を集めたプロジェクトとそれほど変わらないのでは――『地方からの戯言』のAhf氏はそう主張する。 開発プロジェクトは個々の能力も去ることながら、チーム全体で目標に向かい一丸となって作業を行えるか、という点が特に重要である。当然、リーダーの良し悪しはプロジェクトの成否に大きな影響を与える。 ただし、チームで働くとき、リーダーだ
炎上したコラムについて：ベンチャー社長で技術者で：エンジニアライフ
わたしが書いてきたことは「炎上マーケティング」と揶揄されても仕方がないと思っています。しかし、炎上して欲しいと思っていたわけではなく、激しく対立する主張が存在することを承知のうえで、衝突を恐れずに書いているだけの話。もっとも、本文に沿わない明後日の方向のコメントから、明後日の方向へ燃え上がることも多く、それは予想も予防もしようがないのですけれど（苦笑）。 みながわけんじさんのコラムは、予想どおり炎上した。予想どおりというのは、＠ITの読者層の大半は、反対のことを考えているのを知っているからで、言い掛かり的な部分が多いと思う。わたしが書くとさらに炎上する可能性が高いため控えていたけれど、収束したようなのでTwitterでつぶやいていた内容を少し。 そもそも論ですが、社内SEとSIerやソフトハウスのSEは、根本的な職務が違います。 社内SEはコストセンターとして存在するため、できる限りコスト
中小企業が守っていない企業経営の基礎：インフラ系SEの波瀾万丈伝：エンジニアライフ
皆さん、こんにちは。読んでいただいて、どうもありがとうございます。さて、僕には、お金がないので（素直に認めます）、授業料の分割払いが効くユーキャン（月謝制）で、中小企業診断士の資格を取ろうと、初歩から勉強中です。まずは1冊目からノックアウトされているんですが、なんとかマークシートにチェックが入りました。たかが24個のマークを塗るのに、10日もかかってて、ほんまにええんかいな。進もうと思えば、いくらでもすっ飛ばせるけど、すっ飛ばさないようにするためには、じっくり進まないといけない。すっ飛ばしが効かない難しさはありますね。また、企業会計部分につきましては、TACの簿記テキスト（講座ではなく単行本）が有効だと聞きましたので、いま、それを使っています。うう、見るだけで難しい。 ■資格試験勉強で初めて知る真実 そもそも、中小企業ばかりに勤めていたので、たとえ何度徹夜しようと、弁当代1000円だけとか
主任を目指す……その前に：オブリガート ～元テストエンジニアの過去と現在～：エンジニアライフ
こんにちは、第3バイオリンです。 今月のお題は「1年、2年後のキャリアビジョン」だそうです。 先日、タイミングよくそのことについて考える機会がありました。今回は、そのお話をします。 ■同期のひとりが主任に昇進しました それは4月1日、新年度が始まった日のことでした。 どの会社でもそうだと思いますが、この日は昇進や異動の発表がある日です。わたしの会社でも、組織表を更新し、掲示板にアップします。 アップされたばかりの組織表を見て、わたしは驚きました。なんと、わたしの同期の1人が主任に昇進していたのです。 もちろん、おめでたいことです。素直に祝福したいと思います。しかし、一方で「あーあ、先を越されちゃったよ……」という気持ちがあるのもまた事実でした。 ■主任昇格試験 わたしにも、主任昇格試験の受験資格はあります。今年中に、最低でも一度は受験したいと漠然と思っていましたが、同期の昇進を目の当たりに
SQL ServerとOracleの一番大きな違い：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 ぶっちゃけて、SQL Serverも、Oracleも、フリーのPostgreSQLも、RDBMSとしての本質的な性能差は本当に小さい。そのためRDBMSのベンダーを選択するのは、バックアップとか、レプリケーションとか、クラスタリングなどの機能や関連ツールのできと、IDEとの相性などを検討するのが良いでしょう。 しかし、一般的にあまり検討の対象になってない部分が、実は一番大きな違いだったりします。わたしは、SQL ServerとOracleの差で、もっとも大きいのはストアドプログラム（プロシージャ・ファンクション）の書き方（構文）の違いだと思います。 単純なロジックはOracleの方が書きやすい。SQL ServerのIfなどのステートメントブロックにBEGIN
SQLさん、ごめんなさい：プログラマで、生きている：エンジニアライフ
わたしはプログラマ歴は長いんですけど、SQL歴は短いです。 別に避けていたわけではなく、データベース（以降DBと略）を扱うプロジェクトに放り込まれたことがほとんどありませんでした。DBを扱うシステムに関わった時も、そこにはDBのマイスターと呼ばれる方々がいらっしゃって、全部をお膳立てしてくださっていたので、本を読んで文法を覚えただけの状態でもなんとかなっちゃったものだから、それ以上のことを追求する気がおきなかったんですね。 一度、SQL Server 2000のインストール、テーブル設計、SQLおよびJavaのコーディングをすべて1人きりでやる機会があったんですが、その時は速度性能をまったく要求されなかったので（←動く様子がわかる程度のものを短期間で作ってくれ、というオーダーだった）、これまた本を読んだだけの知識でなんとか乗り切れてしまいました。 とにかくわたしはSQLにまったく興味があり
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドラクエで学ぶオブジェクト指向（1） 勇者を作ろう！：フリーなスキル：エンジニアライフ