生き様144. 次世代の開発手法を紹介しよう！：コレがワタシの生きる様：エンジニアライフ
GW中如何お過ごしですか？ 世間はGWですが、このコラムは休まず書きます。 このコラムを読んでらっしゃる方々は「仕事の合間に読む」という習慣をお持ちの方が多いでしょう。 かくいう白栁も、昼休み等の時間に他の人のコラムを読んでいます。 つまり、GW中に書いても余り読まれない、ということですね。 今年のGWは、３・３・２の飛び石ですが、その間を埋めれば10連休！という大型連休です。 この時間を使って、普段できないことをしている方もいらっしゃるでしょう。 僕もこの時間を使ってプライベート用のPCのメンテナンスをしています。 そして、GW中に誕生日を迎えました。 41歳です。いつの間にやら不惑を越えていました。 ですが、厄年、しかも大厄なんだそうです。 まだ公にはしていませんが、今年はいくつか人生の大きなイベントが控えている予定です。 来年、無事にこのコラムが書けているでしょうか？ 本コラムで定期
「だから、作れ」と_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のツイートです。 発言の文脈が分からないので、もし
本家の5倍速？ Pythonで実装したRuby処理系の「Topaz」が登場：Rails Hub情報局：エンジニアライフ
日本時間だと2013年2月7日未明のことですが、「Topaz」（トパーズ）と名付けられたPythonで実装されたRubyのバージョン0.1がリリースされました（リリースに関するブログ、プロジェクトのページ、GitHubのリポジトリ）。Ruby処理系はC、Java（JVM）、Ruby、CLI、JavaScript、Smalltalkなどによる実装がありましたが、Pythonというのは、ちょっと驚きです。ただ、Pythonといっても、Python言語で書くのが主眼なのではなく、Pythonエコシステムで高速処理を目指して作られた「PyPy（パイパイ）」の成果物の上に実装したというのがTopazのようです。現在のところコード作者リストに9人の名前が上がっていて、JRuby実装で知られるチャールズ・ナッター氏の名前も入っています。 Topazは正確にはPythonではなく、RPythonと呼ばれる
プログラミング地獄への道は“ベストプラクティス”で敷き詰められている：Rails Hub情報局：エンジニアライフ
Ruby on RailsのメジャーバージョンアップとなるRails4のリリースが近づいて来ました。先日、日本人（あるいはアジア人）として初めてRailsコアチームのコミッタとして迎え入れられた松田明氏によると、Railsの生みの親であるDavid Heinemeier Hansson氏（以下、通称のDHHを使います）は、プロジェクトをリードするという意味で活動が活発になっているそうです。 そして最近のDHHは、ブログもよく書いています。彼は歯に衣着せぬ発言でも知られています。強い主張を持った（opinionated）なフレームワークの作者らしく、DHH自身もきわめてハッキリと物を言います。攻撃的とまでは言いませんが、IT業界や技術動向などでは割と何かをクソミソにけなしたりということをします。 DHHが何かをけなすときは、だいたい何らかの鋭い洞察とパンチの効いた皮肉が含まれていて、Twit
Fatal/ZERO 第四次コーディング戦争：SEは眠らない ―Fatal / stay night―：エンジニアライフ
■ はじめに どうもー。＠ITの捨てがまり担当、terukizmです。にしても、深夜アニメ楽しいですよねー。ほんとに。かるたとか、超やりたい。 嘘です。 で、題名の元になってる某アニメなんですが、「歴史上の偉人の英霊を召喚して戦わせる」ってコンセプト…… すごく、いいですよねー。 となると当然「プログラム言語」でやってみたくなるのがプログラマの「業」というもの……。当然各方面に喧嘩を売ることになりますが、書いてたらだんだん楽しくなってきてついやっちゃったんだ。しかたないね。 ■ コーディング戦争概要（元ネタを知らない人向け） 「エスイー」が「プログラマ」を使役してコーディングする 「プログラマ」は7つのクラスに分けられ、それぞれの用いる言語に関わりの深い「英霊」が割り当てられる 最後に勝ち残った「エスイー」の願い（定時で帰りたいとか）が叶う 確かこんな感じ。で、以下、本編です。 ■ プログ
なぜ、エンジニアは木から落ちたがる？：気分はどうしようもなくSE：エンジニアライフ
随分昔のことではありますが、「人間とは、木から落ちたがる猿だ」というようなことを聞いたことがあります。 普通の猿は木から落ちることはありませんが、人間は木に登れない猿だと……。 思考実験として、ここに、人が真っすぐに歩けるくらいの十分な幅をもった平均台があるとしましょう。 平均台自体の高さは大して高くありません。その平均台に人を乗せます。そしてその人に、平均台の端から端まで歩いて渡るように指示します。 最初、その人はまっすぐに歩けますが、一瞬でも下を見てしまったら、その人はもう 「平均台から落ちなければならない」 という暗示にかかる、という説でした。 人は、下を見なければそのまままっすぐに歩けるらしいのですが、下を見た（つまり落ちられる状況であると認識した）途端に、運命があらかじめ決められていたかのごとく”落ちて”しまうらしいのです。 「俺はここから落ちなければならない」という強迫観念に駆
これからの生産性向上の考え方：真の顧客満足を目指して：エンジニアライフ
ビガーです。おはようございます。 今回は、1月のお題「生産性向上の仕方」について、エンジニアの視点で生産性を向上させる方法というか考え方について、考察してみたいと思います。 ■そもそも生産性とは？ 現在、生産性に関するWikipediaでの定義で「生産性」とは、 「経済学で、生産活動に対する生産要素（労働・資本など）の寄与度のこと。あるいは資源から付加価値を生み出す際の効率の程度のこと」 となっているようです。 続いて、生産性の測定法について、 一定の資源からどれだけ多くの付加価値を生み出せるかという測定法と、一定の付加価値をどれだけ少ない資源で生み出せるかという測定法がある。 と書かれています。 ここで言われている資源とは、あるタスクのインプット（前提など）、付加価値とは、あるタスクのアウトプット（成果物など）であると定義できます。 要するに エンジニアに求められる生産性とは、アウトプッ
基本設計をうまくこなせない経験者たち：Road To IT-Engineer / ITエンジニアの生きる道：エンジニアライフ
エンジニアとしてどうあればいいのか、企業の期待とどう折り合いをつけるのか、激しく変化する環境下で生き抜くための考え方 ●コラム執筆にあたって 筆者はスキル標準（ITSS、UISSなど）を活用した人材育成の仕組みづくりのコンサルタントですが、職歴はユーザー企業のIT部門に始まり、国内ITベンダ、その後は日本オラクルに11年勤務していました。過去を振り返ると、様々な環境で様々な役割をこなしてきましたが、一本線が通っているという状態ではありませんでした。 日本オラクル時代に、マネジメントとして一番気にしていたのは「後進の育成」でした。人事や人材開発などの部署に属したことはなく、長い間エンジニアとして現場を歩いてきましたが、その中で一番頭を悩ませていたのが若手の育成でした。若手の多くは、入社して2、3年経つと社内の一通りを分かった気になり、もうやることが無くなったように感じたり、ここにいては成長で
職場評価の傾向分析 ←職場を評価してみよう！ 自分が成長できる環境ですか？：Road To IT-Engineer / ITエンジニアの生きる道：エンジニアライフ
エンジニアとしてどうあればいいのか、企業の期待とどう折り合いをつけるのか、激しく変化する環境下で生き抜くための考え方 前回のコラムでは回答ありがとうございました。 皆さんが働いている職場を評価してもらうために、10個の質問を投げかけました。 （1）従業員の持っている能力のレベルを測定し、高めていく仕組みがあるか？ （2）それは、教育研修と連携しており、従業員の多くが活用しているか？ （3）会社から新しい仕事や学習のための機会を提供しているか？ （4）それは、従業員側から手を挙げて挑戦（参加）できるか？ （5）それらは、職場の活性化やモチベーションの向上につながっているか？ （6）それらは、多くの職場で活用されているか？ （7）従業員の強みや持ち味、希望を把握した上で、組織力（プロジェクト含め）が最大化されるような体制になっているか？ （8）経営層、職場リーダークラス側は、（個別では無くて）
オブジェクト指向。教科書と現実のはざまで：Innovation “D”：エンジニアライフ
新人教育のため、久しぶりにオブジェクト指向の教科書をつらつら眺めていると、ふと何点かの疑問がわいてきました。 ■「集約」の章にて 「集約」の説明用に、『ハンドル』『タイヤ』『エンジン』などが集約されて『自動車』になっている図が掲載されていました。 ○（ささやかな）疑問その1 そういえば昔、日本やヨーロッパの自動車メーカーから部品を調達して組み立てた中国製の自動車が、別の国では安全性の問題から自動車として認められなかった、というニュースがあったような……（うろ覚え）。 各部品はちゃんとしていたから、自動車は走ることができたのでしょう。でも、各部品が「集約」されても『自動車』として認められない場合がある。そういうのって、どう表現するのだろう？ ○（ささやかな）疑問その2 唐突ですが、『歌』を「集約」で表現したら、どうなるのだろう？ 『歌詞』と『曲』、『歌手』の「集約」？？？ そういえば昔（昔の
ブルドーザー：情報システム部門のリアル：エンジニアライフ
どうもです、すごく久々のコラムです。最近何かと忙しくて……。今月のお題が「これまで出会ったひどい上司」ということで、わたしの思い出の上司のことを書きたくなり、時間を作って書いてます……。 ■10年前 わたしは小さなITベンチャーの社員でした。客先に呼ばれてトラブル対応し、帰りに喫茶店でサボって適当に過ごしてたSEでした。心がけていたのは、客先になめられちゃいけないと思って、なるべく堂々と振舞っていたこと。内心ドッキドキでしたが……。 ある日、某企業の案件の話がきました。わたしのいた会社から何名か常駐しているのですが、大分トラぶっているとのことで助っ人として一時的に借り出されたのです。 そこの常駐先の上司ですが、まあとんでもない人です。 怒る！ 怒鳴る！ けなす！ 例えば、会議中に「お前、これ説明してみろ！」と突然ふるのですが、そこで答えられないと、 「お前そんなこともわからないでここにいる
ググるな危険：プログラマで、生きている：エンジニアライフ
だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス
6歳で心筋梗塞になって、学んだこと。：On the Shoulder of Giants：エンジニアライフ
【川崎病（かわさきびょう）】 アジア諸国の乳幼児に多くみられる原因不明の急性熱性疾患。長期予後として発症から1～3週間後に10～20％の頻度で冠動脈に動脈瘤が認められ、まれに心筋梗塞により突然死に至ることがある。 （参考： 「川崎病」（2009年1月09日(金) 03:37 UTCの版）『ウィキペディア日本語版』） 小学1年生の冬。まさに私の心臓は血管に狭窄を起こし、心筋梗塞の状態になっていました。実際の入院期間は1カ月ほどだったのですが、幼い目は優に半年や1年、病院の白い天井を映し続けているように感じたものです。 こんにちは、かわばたです。そんな思い出（？）が今年の初夢でした。おいおい......。 ■コラムのサブタイトルを変えました 年が明けたら変えようと思っていた、このコラムの筆者プロフィールやサブタイトル。サブタイトルだけがずっと思い浮かばなかったのですが、2009年お正月、この夢
―CAP定理のジレンマをOracle RACで理解する―(2/2)：クラウドを理解するためのサーバ技術：エンジニアライフ
3. Oracle RACアーキテクチャ Oracle RACは、共有ディスク有りのActive-Active型クラスタリング構成となります。共有ディスク有りとは、複数のサーバで１つのディスクを共有しデータベースファイルを配置する構成です。Active-Activeは、Webサーバを複数台並べて、ロードバランサで負荷分散を行うのと同じ構成です。複数サーバを並べることにより「パフォーマンス」と「障害復旧性」の向上を図ります。 Webサーバは基本的にステートレスで、状態（データ）を保持しないので、複数台並べやすいのですが、データベースの場合はそう簡単にはいきません。データを管理しますので、「データの同期化」を行う必要があります。 この「データの同期化」が重要なポイントとなります。複雑なアーキテクチャとなりますが、データベース3大原則「パフォーマンス」「データの一貫性」「障害復旧性」を考えれば、
「開発言語」を知らない設計者：地方からの戯言：エンジニアライフ
いま勤めている会社の中で問題になっているのですが、最近の潮流としてターゲットとなる開発言語を知らない設計者が増えてきているという話題があります。酷い場合には、言語のみならずプラットフォームであるOSやネットワークの基礎すら知らない人というのも目にすることがあります。このあたりは「人材の空洞化・ドーナツ化」などとよく言われていることだと思います。 要件定義から概要設計の中において、言語を知らなくとも構わない部分が存在しますので、個人的にはOKだと思っています。ですが、今回のような点が話題にあがる環境ですと、言語に大きく依存する部分まで設計してしまおうという状態ではないでしょうか。要件定義をほとんど行わない状態で概要設計を行う、概要設計と詳細設計の区別がついていない、GUIのデザインだけでAPを実装させる（時間的な都合はわかるのですがね……。人のことは言えないですが）など、落ち着いて考えれば酷
プチ炎上したのでまとめ：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「炎上してでも議論がしたい」 と書いたおかげか、プチ炎上しました。 上流の技術者はSQLを習得すべき テーブル設計は実装の後に！ 御意見いただいた皆様、どうもありがとうございました。 こんな長ったらしい文章を読んでいただいた皆様も、ありがとうございました。 10年近く言い続けていることですが、賛同いただけることも以前より増えてきたし、以前の反論はほとんど感情論でしたから、ずいぶん議論がしやすい環境になってきたなと実感します。 私なりのまとめです。 ■適用範囲の条件は？ あくまでも「RDBMSを使うシステム」の話です。 「RDBMSを使わないシステムもある」という御意見も頂きましたが、それは最初に断っておくべきでした。 また、あまりSQLを使ってこなかった人は、自
IT業界のシュールな現実（3）：下流から見たIT業界：エンジニアライフ
数年前（もうかなり古いことなので恐縮ですが）、ある大手SIerでのことです。 ●ありがたいお話 突然Webアプリケーション事業部長が話をするから、下請けを含めた開発者全員、会社の大会議室に集まるようにと言い渡されました。大学の大教室のような広い会議室で待っていると、年のころは60歳近く、小柄でやせていましたが重役クラスと思しき事業部長が1人出てきて、講壇に上がり、話し始めました。 話の内容はこうです。わがWebアプリケーション事業部は発足以来、時代の波に乗って高収益を上げてきた。しかしこの数カ月その勢いがなくなっている。個々人の仕事ぶりも沈滞しているではないか。これはいったいどうしたことだ。 わたしもその職場では組織上の問題があると思っていたところでした。さすが大企業、問題をいち早く認識している、と感心したのはそこまで。あとがいけない。その事業部長の見解は、要するにわたしたち開発者の自覚が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
