エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠typeエンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。
辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)
▼ [Software]辞めていった人達が作ったシステムの保守を楽しいものにする はてなは「絶対すべきでないこと」をやらかしたのか？ nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) この辺りの話題を眺めていて思うところあったので少し書いてみる。 別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。 まず、大前提として、 新しくスクラッチから書き起こす 既にある機能と互換性を保ちながら改修する プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。（最近無くなったらしいけど）グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。 ただ、現実問題として、IT業界では後者の仕事を行う機会の方が
言語は思考にも影響を及ぼす、だからRuby開発を選んだ--まつもとゆきひろ氏
「ソフトウェア・エンジニアの幸せ」とは一体何だろうか? 報酬、評価、やり甲斐。何に喜びを見出すかは人それぞれかもしれないが、ここでは一つの仮説を立ててみたい。 一生涯エンジニアであり続けること――仕事のためだけにプログラミングをするのではなく、仕事を離れても自発的にプログラミングに取り組むようになれば、エンジニアとして日々を楽しめるようになり、ひいては幸せなエンジニア人生を送れるのではないだろうか。 この仮説に基づいてソフトウェア・エンジニアの幸せを考えたときに、切っても切り離せない存在となるのがOSS(オープンソースソフトウェア)である。OSSのコミュニティは、ソフトウェア・エンジニアが仕事を離れてプログラミングに向き合う環境を提供してくれる。先の仮説が正しいとすると、「生涯エンジニアへの道」にぴったりな場所と言えるだろう。 そこで本誌は、日本発のプログラミング言語にして日本発のOSSコ
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
書籍『アプレンティスシップ・パターン』は、7月7日発売予定: 柴田 芳樹 (Yoshiki Shibata)
Amazon.co.jpでは、まだ予約注文できませんが、7月7日に発売予定です。 タイトル： アプレンティスシップ・パターン サブタイトル： 徒弟制度に学ぶ熟練技術者の技と心得 著者： Dave Hoover（デイブ・フーバー）、Adewale Oshineye（アデウェール・オシネエ） 翻訳： 柴田 芳樹 定価： 2,200円（税抜） ISBN： 978-4-87311-460-6 裏表紙の紹介文より アプレンティスシップとは、「徒弟制度」のことで、中世ヨーロッパに広く普及した 職人の組合「ギルド」で用いられていた職人養成制度です。アプレンティス（徒弟） のほか、ジャーニーマン、熟練職人と技術習熟度により段階分けされ、職人は仕事と 心持を学びながら技を習得し、日々腕を磨きました。 本書は、徒弟制度をモデルとし、真のソフトウェア熟練職人を目指すためのパターンをまとめたものです。新しい技術の
防御的プログラミングとテスト駆動開発: 柴田 芳樹 (Yoshiki Shibata)
1978年に大学でプログラミングを学び始めてから1990年代まで、私自身は防御的プログラミングを行ったことはほとんどありませんでした。また、ソフトウェアのテストと言えば、手作業でテストするのが普通の時代でした。それは、私一人が防御的プログラミングをしていないとか、私だけがテストを手作業で行っているとかではなく、それまで属した開発組織がすべてそうでした。 2000年になり、コンサルタントとして設計レビューやコードレビューを行ってきたソフトウェア開発組織に対しては、徹底的に防御的プログラミングを指導してきました。防御的プログラミングを行うことは、トータルで開発コストを下げる活動です。 パラメータの値を検査するコードを書き加えるのは、ほんの数分のプログラミングで済みます。しかし、防御的プログラミングを一切行っていないモジュールを結合して、発生した不具合の原因を調べるのは、数分では終わりません。数
「富豪プログラミング」もいいけど「けちな大富豪」になるべき
Ruby on Railsに代表されるDRY（Don't Repeat Yourself）スタイルのフレームワークは、手っ取り早くサイトを立ち上げるのにはとても便利だ。特にRailsのActive Recordの様に、ランタイムにダイナミックにコードや設定ファイル（もしくはそれに相当するもの）を生成してくれる仕組みは、情報を一カ所のみに記述することによりミスを減らすという意味でもアジャイルな開発という意味でも重要である。 ただ、この手のフレームワークを使う場合に一つ気をつけなければならないのは、それがスケーラビリティの面で商用に耐えられるものか、という点である。特に、その手のダイナミックなコードや設定ファイルの生成（Railsの場合だとデータベース上のテーブルのスキーマに基づいたActive Recordクラスのダイナミックな生成）が、最初にサイトにアクセスが来た時に一度だけ実行されるもの
他山の宝石 - 書評 - プログラマーのジレンマ : 404 Blog Not Found
2009年05月29日18:30 カテゴリ書評/画評/品評Art 他山の宝石 - 書評 - プログラマーのジレンマ 日経BP高島様より献本御礼。 プログラマーのジレンマ 伊豆原弓訳 [原著:Dreaming in Code] はてなブックマーク - 【書評】プログラマーのジレンマ：シロクマ日報：ITmedia オルタナティブ・ブログ個人的に id:dankogai さんの感想がすごく聞いてみたい本。日経BPは献本してないんだろうか。 お待たせしました。 結論から言うと、プログラマーに限らず、まだこの世に存在しない製品を作ろうとしている人はぜひ目を通しておくべき一冊。それだけに翻訳の質の低さが目に余るが。本書の価値はそれを補ってあまりある。 本書「プログラマーのジレンマ」というタイトルだけ見ると本書は Brooks の「人月の神話」の系列に属する本に思われ、また実際に本書には「人月の神話」か
グーグル、オープンソースのプログラミング言語「Go」を発表
Googleは米国時間11月10日、オープンソースのプログラミング言語「Go」を発表した。Goは、首席ソフトエンジニアRob Pike氏やUNIXの共同開発者のKen Thompson氏らで構成されるチームにより開発された。 現在、Goプロジェクトは、プログラミング言語、コンパイラ、Goで書かれたプログラムに多くのビルトイン機能を与えるランタイムパッケージプログラムで構成されている。Pike氏によると、Goは、CおよびC++と類似しているが、最新の機能を採り入れ、ウェブブラウザ内でも使用可能にするなどの汎用性を備えているという。 Goは、ソフトウェアをマルチコアプロセッサで実行する場合に発生する問題に対処するよう開発されている。またオブジェクト指向プログラミングが持つ問題点を緩和するためのアプローチが取られているほか、同社はオープンソースブログで、Pythonのようなダイナミック言語で作業
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Googleの開発者によるJavaVM向けの新言語「Noop」、公開 - SourceForge.JP Magazine
米Googleの開発者らが中心となって、Java仮想マシンで動く新しい言語「Noop」が、Google Code上で公開された。新・旧の開発言語の良い点をブレンドし、可読性の高いコードが書きやすい文法を備えているという。 Noopは、Googleの開発者を中心に有志が集まって開始したプロジェクト。当初、Java仮想マシンを対象とする。Google Codeのプロジェクトページでは、Spring、Guiceなどのコンテナがアプリケーション開発に大きなメリットをもたらしていること、Unit Testingなどの自動テストの重要性が高くなっていることなどから、言語レベルでこれらの特徴を備える必要がある、と開発の背景を説明している。 Javaに似たソースを持ち、言語レベルで依存性の設定やテストを言語レベルで統合する。最初からこれらの特徴を持たせることで、サードパーティのライブラリが不要になる。この
InfoQ: 複雑な外部DSLを開発する
Railsフレームワークは、Rubyで書かれたWebアプリケーションを管理するための、RubyベースのDSLと呼ばれています。RailsがDSLと呼ばれる理由の一つは、汎用的な目的のRuby言語とは対照的にRailsがプログラミングでは無いように思えるのに対して、Ruby言語の機能のいくつかがプログラミングをするのに利用されているからです。言語として考えたとき、その基盤がそれ自体で言語となるのにとても有利なスタートであるとして、RailsはRuby上で作られました。 Dave Thomas (PragDave)が、Rails全体をDSLとして考えているのかは私にはわかりません。しかし、Railsのいくつかの機能が異なるDSLによって支えられていると彼は言っています。彼が示す例は、DSLとしてのActive Record宣言です。ドメインモデルのエンティティの関連に特有な、いくつかの単純な専
½ñɾ - ¤ä¤µ¤·¤¤(¥¤¥ó¥¿¡¼¥×¥ê¥¿|¥³¥ó¥Ñ¥¤¥é)¤Îºî¤êÊýÆþÌç : 404 Blog Not Found
2009ǯ08·î26Æü13:30 ¥«¥Æ¥´¥ê½ñɾ/²èɾ/ÉÊɾLightweight Languages ½ñɾ - ¤ä¤µ¤·¤¤(¥¤¥ó¥¿¡¼¥×¥ê¥¿|¥³¥ó¥Ñ¥¤¥é)¤Îºî¤êÊýÆþÌç ¤ä¤µ¤·¤¤¥¤¥ó¥¿¡¼¥×¥ê¥¿¤Îºî¤êÊýÆþÌç ¤ä¤µ¤·¤¤¥³¥ó¥Ñ¥¤¥é¤Îºî¤êÊýÆþÌç Æü¸þ½ÓÆó ¡Ö¤Õ¤Ä¤¦¤Î¥³¥ó¥Ñ¥¤¥é¤ò¤Ä¤¯¤í¤¦¡×¤ò¸¥Ëܤ¤¤¿¤À¤¤¤¿¤Î¤À¤¬¡¢¡Ö¤ä¤Ï¤êº£ÆüÆü¤Ï¤Õ¤Ä¤¦¤Î¥³¥ó¥Ñ¥¤¥é¤ò¤Õ¤Ä¤¦¤Ëºî¤í¤¦¤È¤¹¤ë¤È¡¢¤³¤ì¤¯¤é¤¤¤Õ¤Ä¤¦¤ËÆñ¤·¤¯¤Ê¤Ã¤Æ¤·¤Þ¤¦¤Î¤«¡×¤È¤¿¤á©¤·¤¿¤È¤³¤í¤Ç¸«¤Ä¤±¤¿Æóºý¡£ ¤¿¤·¤«¤Ë¤³¤ì¤
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 初めての人のためのLISP 増補改訂版: 竹内郁雄: 本
Amazon.co.jp: ソフトウェア開発の名著を読む 【第二版】 (技評SE選書) (技評SE選書 4): 柴田芳樹: 本
Amazon.co.jp: The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで: Maurice Herlihy (著), Nir Shavit (著), 株式会社クイープ (翻訳): 本
レガシーコード改善ガイド (Object Oriented SELECTION) | マイケル・C・フェザーズ, ウルシステムズ株式会社, 平澤 章, 越智 典子, 稲葉 信之, 田村 友彦, 小堀 真義 |本 | 通販 | Amazon
