タグ

ソフトウェアに関するkei_yam1209のブックマーク (8)

  • 君のための本 -- ソフトウェア開発を一生の仕事としていいのか悩んでいる開発者に贈りたい1冊:2015年版 - 思っているよりもずっとずっと人生は短い。

    (これは、『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』に寄稿した原稿の草稿を元に、XP完全新訳版に合わせて加筆修正したものです。なんで完成稿ではなく草稿を元にしたかというと、草稿の方が長かったため短くまとめたものが完成稿になったからです。完成稿の方は『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』をどうぞ。) エクストリームプログラミング 作者:ベック,ケント,アンドレス,シンシア発売日: 2015/06/26メディア: 単行 コンピュータ書を読むのが好きだ。だから「誰かに贈りたい」と言われると、たくさんのが思い浮かぶ。 たとえば君の問題が「プログラミングのスキル向上に思い悩んでいる」という話であれば、『Code Complete』辺りを勧めるだろう。プログラミング技術を10冊あげろと言われれば20冊くらいあげるかもしれない。 け

    君のための本 -- ソフトウェア開発を一生の仕事としていいのか悩んでいる開発者に贈りたい1冊:2015年版 - 思っているよりもずっとずっと人生は短い。
  • 大学院に入った時に知っておきたかった、ソフトウェアエンジニアとして学んだ9つのこと | POSTD

    3年前、私はバルセロナの神経科学の研究室で働いていました。被験者に電極を取り付けたり、認知体系の授業で講義をしたりと多忙な日々を過ごしていました。現在はソフトウェアの製作で生計を立てています。 もちろん科学研究をしていた当時も多くのソフトウェアを書きました。40GBの脳スキャンデータを解析するには、計算処理のプログラムを、気合を入れて書かなければなりません。私は常に優秀なプログラマでしたが、学術研究の職(および、私の約束された将来)に別れを告げて、 小規模ながらも野心的なスタートアップ企業 で働き始めるまで、気付かなかったことがあります。それは、ソフトウェアエンジニアであるということはどういうことか、ということです。そしてさらに重要なことですが、ソフトウェアエンジニアの業界に身を置くということはどういうことか、ということです。プログラミング言語やライブラリ、アルゴリズムやデザインパターンに

    大学院に入った時に知っておきたかった、ソフトウェアエンジニアとして学んだ9つのこと | POSTD
  • 何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita

    エンジニア組織を強くするためのを出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ

    何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
  • やさしいデスマーチ

    7月31日付で2年半ほど在籍した株式会社エスプラニングを退職しました。退職系のエントリーはブクマが稼げると聞いて、状況報告を書こうかなと思います。 前職でやっていたこと 前職は主にJavaによるアプリケーション開発が主業務でしたが、珍しくWeb系というわけでもありません。入社した頃は、Swingでのデスクトップアプリケーションが主プロダクトでした。最近はWebアプリケーションやスマフォ系もやっています。そんな会社で自分が行ってきたことは、開発環境の整備、コード品質の向上、プロジェクト全体の進め方の改善などです。 具体的には、ユニットテスト、読みやすいコード、リファクタリング、レビュー、KPT、カンバン、Trac/Redmine、バージョン管理、継続的インテグレーション、ユースケース駆動開発などなどです。 ぶっちゃけ言えば、入社した当時はお世辞にも技術レベルは高いと言えませんでした。バージョ

    やさしいデスマーチ
  • テストコードのリファクタリング

    JJUG CCC 2012 fall / 札幌Javaカンファレンス2012での発表資料です。 ソースコードは https://github.com/shuji/demo-refactering-unittest から取得してください。Read less

    テストコードのリファクタリング
  • MacBook Pro Retinaに入れたフリーなソフトウェア - ザリガニが見ていた...。

    MacBook Pro Retinaを使い始めて1ヶ月が経過した。Snow Leopardである旧MacBookの環境は丸ごとコピーせず(OSが劇的に変わっているので)、必要なものだけ、その都度、ひとつ一つ手作業でコピーしてきた。ゆっくりだけど、少しずつ便利な環境になりつつある。以下は何をインストールしてきたか、のメモ。 方針 可能な限りOS標準の状態を維持する。 可能な限りOS標準のソフトウェア・機能を利用する。 しかし、そうなっていない気もする...。 Resolution changing app Retina入手したら、まずは2880×1800の素の解像度を試したくなった。 圧巻!なんて広いデスクトップだろう! と同時に、なんて小さな文字だろう...。 現状はAppleScript&Quicksilverを利用して、以下の解像度に自由自在に変更できるのだ!楽しい! Retinaの広

    MacBook Pro Retinaに入れたフリーなソフトウェア - ザリガニが見ていた...。
  • 自分が書いたコードは自分で守る - rabbit2goのブログ

    チームでソフトウェア開発を進めていると、他の開発者が書いたコードを自分が呼び出したり、逆に自分の書いたコードが他の開発者のコードから呼び出されることがある。その境界はクラスやライブラリだったりする訳だが、何らかのデータのやり取りが発生することに変わりはない。問題はそのデータが妥当なものか否かということだ。 例えば、仕様書に「引数にnullが指定された場合、例外を投げる」と記載しても、実際のコードでは意図せぬ形でnullが指定されて呼び出されることは全然珍しくない。もちろん、所詮は人間が書くコードだからそんなバグが出てくるのは当然のことであり、これ自体は大した問題ではない。問題なのは「そのような異常状態をいかに早く見つけ出すか?」ということだ。中途半端な状態で動作が継続してしまうと症状が拡大し問題発見がかえって遅れるので、見つけ出すのは早いほど望ましい。 だから、各処理の冒頭において、外部か

    自分が書いたコードは自分で守る - rabbit2goのブログ
  • すごい!CSSだけでHTMLの検証を行う·Holmes MOONGIFT

    Holmesはスタイルシートを使ってHTMLの検証を行うソフトウェアです。 HTMLの検証を行ってくれるソフトウェア、サービスは多数あります。ソースやURLを指定してエラーの行数や場所を返してくれるタイプのものです。しかしそれでは分かりづらい、そう感じていた方はHolmesを使ってみましょう。エラーをその場で赤や黄色の枠で表示してくれます。 テスト画面です。赤または黄色でエラーが表示されます。 マウスオーバーでエラーが表示されます。例えば右側にある黄色の枠はリンクに対してtitle要素がないというエラーです。 黄色は注意、赤は警告メッセージです。 Holmesはエラー部分がカラーリングで表示されるので非常に分かりやすいのが特徴です。さらにマウスオーバーすれば詳細なエラー内容も確認できます。面白いのはこの機能をCSSだけで実現していることでしょう。HolmesでよりValidなHTMLを書け

    すごい!CSSだけでHTMLの検証を行う·Holmes MOONGIFT
  • 1