タグ

関連タグで絞り込む (2)

タグの絞り込みを解除

engineerに関するsnaka72のブックマーク (11)

  • 「情熱プログラマー」から、プログラマとして心に刺さった言葉 - 今日もスミマセン。

    開発者を探す僕のレーダースクリーンにうつること以外に、実際の仕事で利用できそうもない非主流の周辺テクノロジに投資する意義が何かあるだろうか? 採用責任者である僕にとって第一の理由は、志願者が好奇心を持っているってことがわかる点だ。志願者が自己啓発と純粋な楽しみのために何かを学んだとわかれば、僕はその人が自分の職業に対して意欲的な人物だと判断する。ある主流じゃないテクノロジについて、それを見たり使ったりしたことがあるかどうか誰彼なく訊いて回った。「私はそんなものに取り組む機会を与えられたことがありません」という答えが返ってくるばかりだった。 機会が与えられるだって!そんなの僕だってなかったよ!僕は学ぶ機会を自分でつかんだんだ。 自分の知性に投資しよう - 情熱プログラマー 結局のところ、インディー・ジョーンズが聖杯を探し出す機会を拒めなかったのと同じように、僕も自分が当に好きな事に自ら取り

    「情熱プログラマー」から、プログラマとして心に刺さった言葉 - 今日もスミマセン。
  • 技術者のレベルとソフトウェア開発の難易度(2): 柴田 芳樹 (Yoshiki Shibata)

    ソフトウェア開発を続けていけば、自然とレベルが上がるということはありません。中級職人と上級職人の間には、大きな溝があります。上級職人になれるかどうかは、「新たな技術も含めて自分で常に学習を行い、自然と実践できている」ということです。これは、急にできるものではなく、初心者の頃から行っていくものです。それを行わずに、知っている知識だけで開発業務をこなすと、中級職人で終わってしまいます。中級職人に関しては、次のように拙著の中で解説しています。 このレベルは、多くのソフトウェアエンジニアが到達して、ここで停止してしまうレベルです。 つまり、五年以上のソフトウェア開発を経験して、30代になり、すでに過去の開発業務で使用している技術であれば、問題なく使用してソフトウェア開発を遂行できるレベルです。 このレベルで停滞すると、キャリアパスとしては危ない状態になってしまいます。とりあえず業務は遂行できるため

    技術者のレベルとソフトウェア開発の難易度(2): 柴田 芳樹 (Yoshiki Shibata)
  • 侵略的なフレームワーク - 達人プログラマーを目指して

    SpringやSeasar2などの軽量なフレームワークが登場し、POJO、DI、AOPという考え方が今ではすっかり浸透してきているのかと思いきや、ぜんぜんそんなことはないみたいです。客先でも(主に社内での)実績最優先という考え方から、最近のOSSフレームワークには手を出さず、日の大手SIer謹製のフレームワークを採用したり、自社フレームワークを採用したりするケースが意外に多いですね。そういう場合によくありがちなのが、プログラマーのスキルによらずに作れるようにするという目的から、無意味な規約を強制するケースです。 実際、今日ある国産ベンダーのフレームワークを採用したシステムの設計書に記載されているクラス一覧を見ていて無駄がいかに多いかということに驚いてしまいました。たとえば、ユーザー一覧を検索するという処理でSeamならエンティティクラス、画面、JPQLがあれば実装完了なのですが、そのフレ

    侵略的なフレームワーク - 達人プログラマーを目指して
    snaka72
    snaka72 2010/12/05
    つかえないフレームワークは使わない。政治的理由で使う必要がある場合、使ってるふりして独自にフレームワーク組むという手もある。
  • Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して

    プログラミングと設計は来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の

    Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して
  • SEとPG、どっちが頭がいい?(1):下流から見たIT業界:エンジニアライフ

    ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。SEとPGの分業がIT業界にもたらしている問題が今回のテーマです。 ●SEとは何か、PGとは何か まずそれぞれの職分を正しく認識することからはじめましょう。プログラマ(PG)とはどういう仕事をする人たちでしょうか。 いうまでもありません。プログラムを作る人たちのことです。大工さんは家を作る人、漁師さんは魚を取る人。こういった人々と同様にPGもその仕事の内容から自明です。 一方SE――システムエンジニアの方は必ずしもそうではありません。システムのエンジニア? システムの技術者? ひどくあいまいな言葉です。この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。海外のコンピュータ技術書にもSEという言葉はほとんど見かけません。日人が適当に言い始めた言葉だとしたら、あいまいなのも当然です

    SEとPG、どっちが頭がいい?(1):下流から見たIT業界:エンジニアライフ
    snaka72
    snaka72 2010/11/26
    興味深い仮説
  • SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ

    刺戟的な題名で続けます。 前回は日独特のSE/PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE(システムエンジニア)だというものでした。 ●C言語@UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ

    SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
  • プログラミングに関するあまり知られていない7つの真実

  • 私がソフトウェア技術者でもありつづける理由 : 404 Blog Not Found

    2010年09月25日22:45 カテゴリLoveCode 私がソフトウェア技術者でもありつづける理由 一言でいえば、「自分に報い続けたいから」ということになる。 私がソフトウェア技術者をやめた理由 - Rails で行こう!私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 以下に照らし合わせれば、その複雑な感情とやらそのものがお嫌いなのだろう。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 で、何をもって美醜を決めているかといえば、コルモゴロフ複雑性と、そこからの距離をお使いのようだ。 うるう年を計算

    私がソフトウェア技術者でもありつづける理由 : 404 Blog Not Found
  • 分裂勘違い君劇場 - エンジニアがUIデザインしたがる本当の理由

    ハイライトピックアップ Web2.0を引き起こしているのと同じ時代の潮流が、エンジニアの地位の低下を引き起し、エンジニアUIデザインをしたがる動機を創り出している。 Googleは、「エンジニアの会社」という皮をかぶった「企画・マーケティング・デザイン」の会社である。 エンジニアよりデザイン能力の低いダメデザイナーがうじゃうじゃでてくる構造。 優秀な人ならデザインスキルがなくてもいいデザインができるのは幻想。現実には、デザインスキルの差は容易には超えられない壁。 デザイナーに必要な技術的知識とエンジニア技術的知識は別物なので、エンジニア技術力はデザインをする上でそれほど強みにならない。したがって、技術力とデザイン力を兼ね備えた優秀なデザイナーはエンジニアとデザイナーのハイブリッドではない。 一人の人間がUIのデザインと実装を両方やると二兎を追うものになってUIの質が低下する。二兎を追

    分裂勘違い君劇場 - エンジニアがUIデザインしたがる本当の理由
    snaka72
    snaka72 2010/09/28
    あとで...
  • はてな退職しました - 2nd life (移転しました)

    7/16 が最終出社日*1となり、はてな退職しました。はてなブックマークでのチュートリアル機能がはてなでの最後の仕事となりました。 はてなに入ってからを振り返ってみると2006年1月にはてなに15番目の社員として入社し、4年7ヶ月はてなのメンバーと一緒に働いてきました。当時はまだ誰も辞めていなかったため、過去はてなで働いた人すべて一緒に仕事をしてきたことになります。入社時はまだオフィスが東京にあり、毎日全員が朝会でディスカッション、時には数時間も熱く語るというエキサイティングな職場だったのがとても印象的でした。 当時は当に自由な環境でいろいろな事を試行錯誤していた日々でした。入社約2ヶ月で、会社のフレームワークに DI の概念を実装したころで Perl もう無理と投げ出して Perl を書かない仕事ばっかりやっていたのも今となっては良い(?)思い出です。今だったらあり得ないですねほんと

    はてな退職しました - 2nd life (移転しました)
  • 1