Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
![スクラムマスタはフルタイムで行う役割か - スクラムマスタ宣言の結論は「YES 」](https://cdn-ak-scissors.b.st-hatena.com/image/square/3612b0742d8fa777a0901554e66180f888641268/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s2_20240705082009-1%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R&D統括本部 開発推進室 セキュリティプラットフォーム技術 セキュリティスペシャリストの戸田 薫です。 今回は、私たちが普段からヤフーのシステムに対する入力にどのような注意を払っているのか、そのいくつかをご紹介致します。 入力とは? Webサイトを運営している場合、どのような入力があるでしょうか? たとえば、Webサービスには、以下の入力があります。 Cookie URL GET/POSTのデータ ファイルのアップロード その他リクエストヘッダ そのほかにもいくつもあります。 環境変数 設定ファイル クローラが取得したデータ パートナー企業のAPIから取得したデータ(XMLやJSONなど) パートナー企業の入稿用 F
コンサルタントであるMartin Proulx氏のブログ「Analytical-Mind」に、「 Seven wrong reasons to adopt Agile」(アジャイルを導入する7つの間違った理由)」というエントリがポストされています。読んでみると、なんだかドキっとするようなことが書いてあります。 次の7つの理由、心当たりのある人も少なくないのでは? We recently attended a conference and Agile is becoming more popular. If others are doing it, so should we. 最近カンファレンスに参加したところ、アジャイルが人気らしい。他でやっているのなら、うちでもやるべきではないか Because Gartner and Forrester say so. ガートナーやフォレスターがそう言
未踏プロジェクトの支援を受けて開発していた、C/C++のための開発援助ツールGCCSenseをリリースしました。配布物やドキュメントは次のURLから入手できます。 http://cx4a.org/software/gccsense/index.ja.html 開発援助ツールと銘打っていますが、現状利用できる機能はコード補完と自動構文チェック(Emacsのみ)だけです。将来的には関数ヘルプ機能や型表示機能を実装する予定です。 GCCSenseはコード補完などの機能を搭載した独自のGCCを利用しているため、インストールがかなり面倒です。ドキュメントによってある程度カバーしたつもりですが、環境によってまちまちなのでインストール時に問題が出てくるのは必至だと思います。その際は私に連絡してください。 また、独自GCCを利用している関係上、現状ではWindowsでの利用はできません。自由なソフトウェア
DevOps: Why Silos Suck And How To Break Them というエントリをたまたま目にして、「DevOps」という見なれない言葉が出てきたので、気になって調べてみたところ、自分が何となくやっていたことや、今までもやもやと考えていたことに一定の方向性が与えらえた気がしたので、整理してみることにします。 DevOps とは? 簡単に言ってしまうと「開発者と運用者の間の壁を取り払うためのベストクラクティス」と言えそうです。 開発者と運用者の間の壁? Flickr の中の人による 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr という Velocity 2009 でのプレゼンスライドには「Devs versus Ops」という章があり、以下のような言葉が載っていました。 "It's not my mach
3月末が期限だったtracのマイルストーンをクローズする。「チケットキーパーという存在」として、未解決のチケットについてはマイルストーンの変更(要するに先送りだ)や、担当者にチケット更新の催促を行う。幾つかのチケットはクローズ出来たものの、中にはクローズを認められないものも有る。例えば、こんなチケットだ。 やるやる詐欺型 「次回はレビューを行います」「確実なチェックを実施します」なんて書かれているけれど、今までそんなことが実際に行われて成果を上げているなんて聞いたことがないし、そもそも次回の開発時には、こんな回答すら忘れられていることが多い。だから、作業手順書を改訂する、チェックリストに確認項目を追加する、実際にレビューを行うなど具体的なアクションが完了するまでチケットはクローズ出来ない。 フィードバック欠如型 障害の修正だけで作業が終わってしまい、再発予防策とか未然防止策が実施されていな
DevOps に関する理解を深めるために、資料にあたってまとめてみるシリーズ。 今回は Velocity Online Conference - March 17, 2010 でのプレゼン Provisioning Toolchain から。スライドのタイトルは「OpenSource Provisioning Toolchain」となっている。 昨日のエントリでいうと、「インフラの自動化」や「ワンステップビルド&デプロイ」に関連する話。 Toolchain というのは何らかの目的を達成するためのソフトウェアの集まり、ってことなので、Provisioning Toolchain は、プロビジョニングを行うためのソフトウェアの集まり、ってことですね。つまり OpenSource Provisioning Toolchain は、プロビジョニングを行うためのオープンソースソフトウェアの集まり、と
Firefox にこんな機能があればいいなあ → ん、Greasemonkey というのでできるらしいぞ → ユーザースクリプトとやらを書けばいいのか → どうやって書くんだ? というところからスタートして、最終的に自作のユーザースクリプトを公開するに至るまでの間、参考にしたサイトや本をできるだけ自分の学習順に時系列に沿って列挙してみました。 JavaScript を少々かじったことのある人が Greasemonkeyスクリプトを書いてみようと思い立ったときに、その学習の指針というか、道標のようなものとして役立つリンク集になればいいなと思ってます。 Greasemonkey まずは Greasemonkey ってなんだとか、ユーザースクリプトってどう書くんだというのを調べるところからスタート。(以下小見出しがリンクになっています) Greasemonkeyの開発をまとめてみる ここで Gr
ついにRedmineのtrunkにSubtasking がコミットされたのでメモ。 【元ネタ】 Twitter / yusuke-kokubo: #redmine ついにtrunkにSubtaking がコミットされた! Twitter / yusuke-kokubo: #redmine 1.0ではチケットの親子関係がサポートされます。 Redmine - Feature #443: Subtasking - Redmine Redmine - リビジョン 3573 - Redmine (下記引用開始) Adds subtasking (#443) including: * priority, start/due dates, progress, estimate, spent time roll-up to parent issues * descendant issues tree d
テスト駆動開発入門 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート出版社/メーカー: ピアソンエデュケーション発売日: 2003/09メディア: 単行本購入: 45人 クリック: 1,058回この商品を含むブログ (161件) を見る TDDって真面目に勉強したことなかったので読んでみました。 Amazonの書評では翻訳がひどいということがしきりに叫ばれていますが、別に我慢できないほどじゃないと感じました。慣れれば読めます。K&Rより100倍マシです……。 さて、テスト駆動開発ですが、私がこの本を読む前に持っていた知識は以下のような感じです。 テスト・ファースト テスト手法じゃないよ開発手法だよ グリーン→レッド→リファクタリング→グリーン…… で、実際に本を読んでみると、上記の理解はあまりに浅すぎることを知りました。 以下、特に参考になった点を挙げていきます。
TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。 #下記はロジカルでないので注意。 【元ネタ】 裏プロセスは並行プロセス: プログラマの思索 チケット駆動開発のモチーフ: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ!と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。 Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100%になり次第、随時リリースしていった。 すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。 そして、リリース後にK
Redmine¶ Table of contentsRedmineFeaturesDocumentationSupport & getting helpContributing and helping outWho uses Redmine?Redmine books Redmine is a flexible project management web application. Written using the Ruby on Rails framework, it is cross-platform and cross-database. Redmine is open source and released under the terms of the GNU General Public License v2 (GPL). Features¶ Some of the main
うちの会社(有限会社ITプランニング)でやってきたOCamlを使ったシステム開発の概要を書いておきます。ふと思うと今までまとめて公開したことはなかったなと。別に隠す程のものじゃないし、もしこれからOCamlを使ったプロジェクトを始めてみたい人の参考になれば嬉しいです。 2006年 某証券会社のWebサービスの一部を担当 株価を解析して、その結果をWebAPIとして提供。OCaml + MySQL。HTTPベースで提供されるXMLファイルが生データだったので、この時初めてXMLのパースにxml-lightを使った。これはかなり便利。その後も使い続けている。nc(network cat)ライクなモジュールも作った。行列変換のためにC言語との連携もしたけど、特に問題なし。そういえば、この頃はmarshalingが好きで、DBへmarshalingデータをそのまま保存して「Objectデータベース
開発プロセスの違いについて良い記事があったのでメモ。 【元ネタ】 [Agile]WFとScrumとリーンの違い | Ryuzee.com WFの弱点は「計画に依存しすぎているので、計画が間違っていたらリスクが高い」「プロジェクトの終了直前のデプロイまで、何の価値も実現できない」点にある。 実際の現場では、結合テストで火を噴いてビッグバン統合に失敗する症状に全てが言い尽くされていると思う。 このWFを繰り返し型開発へ変形した場合、確かにリスクは減るが、最大の弱点は「ボトルネックが発生してしまい、それを制御できない」点にある。 全ての作業の遅れが積もり積もって、バッファを食い潰すのだ。 TOCのクリティカルチェーンの話を思い起こさせる。 Scrumではイテレーション単位に、Plan・Build・Test・Reviewが並行で動き、リリース前にReviewとDeployが行われる。 つまり、実装
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 1・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く