はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
On Lisp
Paul Graham著，野田 開 訳 前書き 拡張可能なプログラミング言語 関数 関数的プログラミング ユーティリティ関数 返り値としての関数 表現としての関数 マクロ いつマクロを使うべきか 変数捕捉 マクロのその他の落し穴 古典的なマクロ 汎変数 コンパイル時の計算処理 アナフォリックマクロ 関数を返すマクロ マクロを定義するマクロ リードマクロ 構造化代入 クエリ・コンパイラ 継続 複数プロセス 非決定性 ATNを使ったパージング Prolog オブジェクト指向Lisp パッケージ 翻訳者 野田 開のサイト 原著者Paul Graham氏のサイト (c) 野田 開 NODA Kai <t50473@mail.ecc.u-tokyo.ac.jp>
なぜ依然としてウォーターフォールが残っているのか？ - レベルエンター山本大のブログ
マネージメントに携わるようになってウォーターフォールにも理があると思うことが多い。（もちろん最適解ではないが。） ウォーターフォール・反復に次ぐ、実践的な開発プロセスを検討したいとずっと思ってる。そんな検討をしていこうと思う。 ということで、語りつくされてはいるが「アジャイルかウォーターフォールか？」から考える。 アジャイルかウォーターフォールか？ アジャイルプロセスが提唱されてから既に数年、業界の多くの著名人がアジャイルを推奨し、多くの書籍が揃う。 アジャイルの考え方は、ウォーターフォールプロセスによる開発で「仕様変更」と「コストオーバー」、「スケジュールオーバー」に苦しめられてきた開発者達の、怨念にも似た声から生み出されたものだ。 エンジニアの視点から考えると理想的な開発の進め方のように思う。 しかしながら、やはり実際の開発現場は依然として、ウォーターフォール式の開発プロセスを採用する
ちょっとづつアジャイルへ - レベルエンター山本大のブログ
久々にプロジェクトに参画して「変更に対して柔軟」であることの意義を強く感じる。 それも、実装レベルの柔軟性が開発全体の柔軟性につながるということを強く感じるのだ。 例えば今回参画したプロジェクトで実装上で取り入れた柔軟性の１つとして、 ViewベースのDB設計がある。 全体に影響があると思われた仕様変更が Viewの内側の変更に納めたことで １人日程度の作業で済んだという例が毎日のようにあった。 柔軟な設計をするには、柔軟な実装を知っていなければならない。 進め方での柔軟性 私は、 要件定義→設計 →単体テスト→実装→仕様変更→単体テスト →結合テスト→システムテストの流れこそが、日本での現実的なアジャイルの姿だと思う。 「イテレーションのように、初めからやり直す」 というタイプの繰り返しではなく。だ。 そもそも、ウォーターフォールの問題点である 「変更を認めない」という流れになるのは実装
システム開発で再利用可能な最大のコンポーネントは開発チームだ。 - レベルエンター山本大のブログ
開発プロジェクトは知識産業です。 プログラムは知識労働の成果ですが、 知識労働の一番大事なエッセンスは、 それを生み出す「過程」にあると思います。 つまり知識労働で別のプロジェクトでも再利用可能なのは 知識とその所有者だと思います。 その考え方を発展させて「再利用可能な最大のコンポーネントは開発チームだ」と言いたいです。 そう言うわけで、以下のひがさんの意見に賛成。 ■ひがやすを blog 〜 SIerが自動車産業をまねしようとするのはいい加減やめなさい 自動車だと、同じマフラーを作り続けることができるけど、システム開発の場合は、同じマフラーを作ることは意味がない。同じプログラムを作り続ける意味がないからね。 （中略） これからのSIerは、分業などせずに全部自前で構築できるようになれることが、重要だと思う。 http://d.hatena.ne.jp/higayasuo/20080305
ユニットテストの方法論 - レベルエンター山本大のブログ
ひがさんの意見！さすが！目から鱗の提案だ！ ひがやすを blog ■極力ユニットテストを書かずに品質を確保する方法 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 http://d.hatena.n
プログラミングファースト開発でのRDB設計 - レベルエンター山本大のブログ
ひがさんの提唱する「プログラミングファースト開発」で困難だと思われるのはDB設計だ。 本家ブログのコメント欄でも言及されてる。 要件定義は、プログラムファースト設計の前に行うということでいいと思いますが、DB設計は、作りながら変わっていくと思うので、プログラムファースト設計と同時にするのがよい(しかない)と思っています。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 ツールでリファクタリング機能が、いかに整ったとしても RDBのリファクタリングがアプリケーションに及ぼす影響は計り知れない。 SQLServerは、機能が豊富でRDBMS的にかなり融通が利くほうだが、 機能だけでDBのリファクタリングが可能かといえば、まったくそうではない。 開発途中では、列や値の業務的な意味づけが変わることも多々ある。 また、DBのリファクタリングは開
１プログラマとして生産性を見直す。 - レベルエンター山本大のブログ
普段の仕事はアーキテクトやDBAやらフロントSEが多いんですが 久々に、１プログラマとして、自分の関わっていないフレームワークで 自分の関わっていない仕様書に則ってプログラミングをしました。 やってみると、結構気づかなかったことに気づきます。 プログラミングしていて困ったのは、 「この記述はどこを探せばいいのか？」 「他のメンバーと統一できているのか？」 といった「迷い」であり、これらの時間が最も効率を下げると思います。 そういうことで、フレームワークでコーディングの効率を上げるよりも、 以下の資料をしっかりとまとめておく方が、開発効率の向上に効果があるとおもう。 変数や画面項目名の名前付けのルールが整っていること 全体資料が整っていること メッセージ登録の一覧 ER図 コピペで実装したくなる気持ちも分った。 コーディングルールがあいまいだったり、 フレームワークが提供する部品の使い方がよ
自動テストとデイリービルドの組み合わせは最強！ - レベルエンター山本大のブログ
自動テストとデイリービルドを組み合わせることの超絶な威力を感じてる。 しかし、開発の中に上手く自動テストを組み込めていないプロジェクトは多い。 デイリーでテストコードを流しておくと、修正による副作用を最低でも1日以内に発見することができるようになる。 影響を恐れずに修正ができるため、大胆なリファクタリングも可能だし、仕様変更にとても強くなる。 結合テスト以降は、特に強力で自分の作っていないプログラムでの修正や操作が自分のプログラムに影響を与えることがある。 それを知らせてくれる仕組みがあるということが安心感は絶大だ。 そもそもテストコードを作ると、コーディング時やデバッグ時に起動ポイントとして使える。 Web画面を起動しなくていいぶん楽にコーディング・デバッグできる。 「じゃあ、Web画面からの入力テストはどうするんだ？」とか 私も昔は思っていたけど、画面入力のテストなんかは無理に自動化し
データベースのアジャイル開発を実現する8のプラクティス - レベルエンター山本大のブログ
アジャイルな開発に欠かせない割りに、あまり言及されていなかったのが データベースのアジャイル開発です。 今、私の参画しているプロジェクトで、データベースに関するアジャイルな開発の方法を模索していました。 現在実践していて効果のあるプラクティスをまとめます。 1.データベース作成ツールのVSS管理 「スキーマ定義クエリ」と、移行に必要な「初期データCSV」および「移行クエリ」、「移行プログラム」は、管理ツール（VSS）にチェックインされていて、だれでも修正が可能です。 スキーマ定義クエリだけでなく、「移行データ」についてもVSSで管理しているのがポイントです。 マスタなどのデータは、業務の設計に応じて変わるものですし、移行プログラムも実装チームやテストチームが柔軟に修正できたほうが便利です。 データは、単体テスト用データとしても利用できます。 2.データベースのデイリービルド データベースの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flatline