タグ

developmentに関するkimura_m_29のブックマーク (35)

  • 継続開発のススメ - Twisted Mind

    概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、

    継続開発のススメ - Twisted Mind
  • テスト駆動開発チートシート - やさしいデスマーチ

    TDD(テスト駆動開発)のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ(OmniGraffle)が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記2 このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。

    テスト駆動開発チートシート - やさしいデスマーチ
  • WEBプログラマー必見!WEB脆弱性基礎知識最速マスター - 燈明日記

    以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。 WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。 また、WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。 WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。 そう、WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。 今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。 このまとめがWEBアプリケーション開発の参考になれば幸いです。 インジェクション クロスサイト・スクリプティング セッション・ハイジャック アクセス制御や認可制御の欠落 ディレクトリ・トラバーサル(Directory Traversal) CSRF(

    WEBプログラマー必見!WEB脆弱性基礎知識最速マスター - 燈明日記
  • 大規模受託開発におけるCI - wyukawa's diary

    そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト すばらしいスライドだ。ディリービルドとリグレッションテストを大規模パッケージ開発において適用したときの雰囲気が良く現れている。10年前の話のようだが今で言うCI(継続的インテグレーション)だよね。 僕も2年ぐらい前にパッケージ開発でCruiseControlを適用したことがある。junitのテストケースがあったがメンテされていなかったので使わなかった。結合レベルの自動テストもあったがこれもメンテされておらずそんなに使わなかった。スローテスト問題もあったしね。その代わり新たに結合レベルの自動テストを作っていってそれなりにうまくいったように思う。ただ実質一人プロジェクトだったこともあり途中から面倒になってやらなくなった。一人だと自分のローカルがマスターといってもいいので大規模に比べるとCIのメリットは薄い。

    大規模受託開発におけるCI - wyukawa's diary
  • ログ設計は難しい - wyukawa's diary

    デバッグ、コードリーディング、構成管理、例外あたりは情報が近年でつつあるように思う。ただログに関してはあまり見ない。 開発時にはほとんど考慮されず保守で必要なログが出ていないで困るというパターンが多い。 開発と保守では担当する人が異なることが多く(しかもどちらも協力会社まかせだったりする)、保守経験が無くて開発ばっかりやってるとログに関するノウハウが蓄積しないし、必要性もわからなかったりします。 まあそんなわけで(どんなわけで?)、ログに関してこうやればいいんじゃない的なものを書いてみたいと思います。 とりあえずAOPによるログ出力は強力です。これは実感しています。ただ効果を最大限にするには呼び出されるメソッド名だけを出力してもあまり意味が無い。引数や戻り値、例外が発生したならそれも出力してはじめて効果を発揮する。 引数や戻り値は単純なStringやintとかだけではなくてList、Map

    ログ設計は難しい - wyukawa's diary
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

  • 作業計画とスケジュール作成の実践知識:緻密なWBS定義こそが重要

    進ちょく管理の第一歩は,納期・コスト・品質を守るためのスケジュールを立てることにある。その時に最も重要なのは,現実感のある作業内容を明確に定義することだ。ここでは,「WBS(Work Breakdown Structure)」を使って,緻密で現実的な計画を作るための勘どころを解説する。 「納期から半年遅れでようやくシステムが稼働した」,「要員の追加投入を繰り返し,人件費がかさんで予算を大きく超過した」――。 当初計画した納期を守ることができず,結果的に赤字に陥るプロジェクトが後を絶たない。仕様があいまいで手戻りが多発した,新しい技術の導入に手こずったなど,原因は様々だろう。 中でも多いのが,きちんと計画を立てていないこと,つまり基ができていないことである。どこかの工程に遅延が生じたら,その場しのぎとばかりに別の工程を担当する要員を投入。今度は別の工程が遅れ始める。こうなると誰もプロジェク

    作業計画とスケジュール作成の実践知識:緻密なWBS定義こそが重要
  • 意図が伝わる設計書作成の心得【第1回】:行きすぎた技術志向

    設計書の書き方には絶対的な公式があるわけではない。必然的に,設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで,このような事態を避けようとしている開発現場は多いだろう。しかし,型通りに作った設計書が,常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが,設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に,設計者の「経験」と「力量」に依存する部分が多くなり,完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん,標準の設計フォーム(ひな型)や設計書作成ガイドラインを用意することで,このような事態を避けようとしている開発現場は多いだろう。しかし,型通りに作った設計書が,常に目的にかなった“正しいもの”であるとは限らない。一

    意図が伝わる設計書作成の心得【第1回】:行きすぎた技術志向
  • HugeDomains.com

    Captcha security check coolcoding.com is for sale Please prove you're not a robot View Price Processing

    HugeDomains.com
  • Java開発におけるフォルダ構成 - wyukawa's diary

    こんな感じでいい気がしてきた。 http://.../svn/sample/ | |--trunk/ | |--tools/ JDK, Ant, Eclipse, Tomcat, DBなどのツール類 | |--doc/ ドキュメント類 | |--sample-project/ 各プロジェクトのビルドスクリプトを呼び出す大元のビルドスクリプト | |--build.properties |--build.xml | |--build-test.properties |--build-test.xml | |--conf/ Eclipseの設定ファイル(epfファイル)などを格納する | |--sample-common/ 共通的に用いられるユーティリティクラスなどの置き場 | |--build.properties |--build.xml |--.classpath |--.project

    Java開発におけるフォルダ構成 - wyukawa's diary
  • 連載:アジャイル開発者の習慣―acts_as_agile|gihyo.jp … 技術評論社

    第4回特別コラム 「なぜそんなにも(アジャイル開発者にとって)Wikiは重要なのか」 角谷信太郎 2008-04-22

    連載:アジャイル開発者の習慣―acts_as_agile|gihyo.jp … 技術評論社
  • HTML5時代の「運営しやすいアーキテクチャ」の話

    増井君と二人でPhotoShareというサービスを立ち上げてもう15ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ(JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく(上の図で、CSS,

    HTML5時代の「運営しやすいアーキテクチャ」の話
  • @IT:連載記事 「ゼロからのデータモデリング入門」

    Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26) データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24) 連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21) 日オラクルのデータベーススペシャリストが「DBAがすぐ

  • Teedaでの開発ポリシー - akiraneko’s blog

    私が思っている小規模から中規模向けのTeeda開発ポリシーです。 大規模はそもそもSAStrutsを(あわわ) 前提の前提 オフィシャルサイトの『現場で役立つ実践Teeda』(http://teeda.seasar.org/ja/presentations.html)が標準的な開発環境をきれいに記述しているドキュメントになります。 全体的にここのプレゼンテーション資料は非常に質が高いので、すべて目を通しましょう! 前提 データベース周りの処理はDBAが担当、ロジックはロジック専用の人が担当、画面は画面専用の人が担当っていう階層わけした開発用ではありません。機能ごとでの分担を前提としています。 また、デザインパターンを意識しないでいます。そもそもデザインパターンは作っていて問題がでたから導入する流れが好ましいと思っているので、無駄に複雑なデザインパターンありきで実装をするのもどうかと思ってい

    Teedaでの開発ポリシー - akiraneko’s blog
  • さらに分かっておきたいトランジスタの種類 − @IT MONOist

    IoT(モノのインターネット)市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS(RTOS)について解説する連載。第44回は、MCUとDSPのデュアルモードに対応した先進的RTOS「RTXC Quadros」について紹介する。

  • 【連載】ゼロから始めるUMLモデリング講座 | エンタープライズ | マイコミジャーナル

    Copyright (C) Mainichi Communications Inc. All rights reserved. 掲載記事の無断転載を禁じます

  • さらに分かっておきたいトランジスタの種類 − @IT MONOist

    IoT(モノのインターネット)市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS(RTOS)について解説する連載。第44回は、MCUとDSPのデュアルモードに対応した先進的RTOS「RTXC Quadros」について紹介する。

  • ビギナー Web プログラマに一皮むけるためにやってほしい5つのこと - イトウ アスカ blog

    1. Web サーバの設定方法を覚えてほしい そんなに深くじゃなくてもいいんです。Apache でも IIS でも、なんだったら AN HTTPD だっていい(というか AN HTTPD って学習用にはかなりおすすめです)。それでどこにファイルを置くと外部からアクセスできちゃうのかということを知ってほしい。直リンクで様々なファイルを叩いてほしい。 「どんなところで稼働するのか」ということをほとんど学ばずに Web アプリケーションを書いている人って意外と多くて、そういう人が顧客情報がぎっしりつまったデータファイルを平気で外部からアクセス可能なところに置いたりするんですよね。 2. HTTP クライアントを作ってみてほしい とにかく Web プログラム自身が吐き出した HTML を善意に解釈するブラウザ(IE や Firefox)からのみアクセスされるものだと思い込んでいる Web プログラ

    ビギナー Web プログラマに一皮むけるためにやってほしい5つのこと - イトウ アスカ blog
  • プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ

    プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

    プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
  • 満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ

    ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo