アジャイルにおける事前合意について - arclamp
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。 ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。 アジャイルは最初に全てのCDSを決めない まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。 ウォーターフォール型開発というのは、 「スコープは最初に確定」し、 「コストや期日はスコープを達成するために必要な分を最初に設定」し、 必要
日記を書くWebアプリケーションを書いている - Sexually Knowing
GitHub - aereal/nikki 昨年末からぼちぼち書いている。 モチベーション いわゆるページを動的に生成するWebアプリケーションのパフォーマンスチューニングの練習台 サーバサイド、クライアントサイド双方に渡る改善を試みる余地がある 諸々のWeb技術の遊び場 TypeScript Google Cloud Platform Kubernetes HTTP/2 GraphQL SPA = Single Page Application 以上が目的としてではなく、手段として求められ高度にバランスされること 普段から自分が使うアプリケーションであること (技術採用など意思決定の練習) ……を目的に考えて日記を書くためのブログシステムを書きはじめた。 Web技術で遊び続ける定まった場所がないと、技術を使うための技術の域を出ない学習が続くなという問題意識から何か作ることにし、自分はWe
Gyazo 開発環境の Docker 化 - r7kamura - Medium
The easy way to save screenshots, GIFs, and websites. Make everyone happy by sharing smarter, faster, and with your… 単純にスクリーンショットを保存するだけなら OS の機能だけでも十分ですが、GIF 動画を保存できたり、いつどこでどんなアプリケーションを利用しているときに撮影したのか、あるいは画面にどんな文字が写っているかといった情報を元に検索できたり、保存した画像をコレクションという単位でまとめて共有できたりと、Gyazo を使って保存しておくと意外と便利なことが多く、個人的にも重宝しているサービスの1つです。 我々が開発環境で Docker を使うメリットGyazo のサーバサイドの実装には、プログラミング言語の観点で見ると Ruby、Go、JavaScript などが
開発運用チームを立て直した話 - 下町柚子黄昏記 by @yuzutas0
SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。 発表スライド 「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」 ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。 参加した感想 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。 一方で内容面については全体的に違和感を覚えました。もやもやです。 内容 思ったこと 補足事項 「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。 現場にメ
Rustで高速な標準出力 | κeenのHappy Hacκing Blog
κeenです。Rustで何も考えずに標準出力に吐いてると遅いよねーって話です。 今回、標準出力に「yes」と1000万回出力するアプリケーションを書いてみたいと思います。 println! まあ、最初に思いつくのはこれでしょうか。
Flow導入して数ヶ月がたった所感 - tomoima525's blog
ReactNativeプロジェクトで、型がないことによるつらいシーンが多くなり(特に変数の解釈に起因するバグ)、Facebook製の静的型解析ツールであるFlowを数ヶ月前に導入しました。導入時の学びと、しばらく運用して感じていることについて個人的な感想を書きました。 Flow選定理由 Javascriptで静的な型付けをするといえばTypeScript(正確にはJavascriptのスーパーセット)がありますが、プロジェクト途中からの導入しやすさの観点からFlowにしました。Flowはお作法(行頭に @flow つける等)さえ押さえれば誰でも使えることから導入障壁はだいぶ低いといえます。導入のメリットについては以下のスライドがとてもわかりやすいです。 speakerdeck.com flow status でプロジェクトに対して静的型解析を走らせることもできますが、 コーディング時にワー
Big Sky :: Vim で端末機能が動くようになった。
ひさびさ Vim のエントリを書く気がします。 今から4年ほど前、Vim にスレッドセーフなメッセージキューが欲しいというメールが vim-dev 届きます。 [PATCH] Proof of concept: thread-safe message queue https://groups.google.com/forum/#!searchin/vim_dev/tarruda%7Csort:relevance/vim_dev/65jjGqS1_VQ/fFiFrrIBwNAJ その時はまだ、vim-dev の中にも「Vim はエディタだし必要ない」といった空気があったと思います。 [PATCH] Non-blocking job control for vimscript https://groups.google.com/forum/#!searchin/vim_dev/tarruda%
Pythonで常に意識すべき非直感的な振る舞い
Pythonには独特の仕様がいくつかあります。 その中には、他のLLを習得している方ほど気が付きにくく、認識を誤りやすいものがあります。 そこで、Pythonで頻繁に用いる仕様の中から、意外と知る機会の少ない仕様を七つ取り上げます。 Pythonって愛嬌がありますよね はじめまして、寺坂です。 ビザスクのエンジニアです。 業務的にはビザスクのエンジニアの例に漏れず、主にPythonと{ECMA,Type}Scriptを喋ります。 私はLinuxユーザーであることも相まって2006年頃に趣味としてPythonを触り始めたときから、 なかなかに面倒くさいこの言語に日々愛嬌を感じずにはいられません。 とはいえ業務で書くとなると愛嬌では済まされない部分もあります。 ビザスクの開発チームでは、管理しているコードのうちプログラミング言語に限れば60%が、そこから{ECMA,Type}Scriptを除く
リスペクトがない人はOSSから排除するしかない
Question regarding writeboost and MYSQL · Issue #146 · akiradeveloper/dm-writeboost · GitHub 最近ライトブーストを試し始めたユーザだが、他人に対するリスペクトがないため「お前の質問には一切答えない」と言って打ち切った。出来るだけそういうことはしたくなかったため、過去に同様のことをした時は忠告する程度に止めていたが、再発したため追放することとした。(Issue 141でも同様に、foolなど罵る言葉を使っていたため忠告した) OSSでは、会ったこともなく、それこそ本名も知らない人がコミュニケーションをとることになる。言語は英語だが、お互いにネイティブである方が稀である。そこで大事なのは、他人をリスペクトする気持ちだ。まじでリスペクトする必要はない。本当にリスペクト出来ないなら去ればいいだけだし、リスペ
Mozilla、Microsoft、Operaが拡張機能のコアAPIの標準化を提案 - Mozilla Flux
Mozilla、Microsoft、Operaの三社は、2016年5月2日（米国時間）、W3CのBrowser Extension Community Groupのメーリングリストにおいて、ブラウザの拡張機能におけるコアAPIやマニフェスト、パッケージを標準化することを共同で提案した。今後はGitHubで仕様を公開するとともに、Twitterアカウントでも情報を発信していくようである。 今回の共同提案に至る経緯を補足する記事として、Dev.Opera — For a Better Extensions Ecosystemがある。Operaは、2013年7月時点で、ベンダー中立的なブラウザアドオン用パッケージフォーマットである「NEX」を提唱しており、将来的にはフォーマットの策定作業を標準化団体において行っていくとしていたが、ようやくその努力が実った形だ*1。 現時点で、以下のようなコアAP
PHP7 で PSR-7 と Middleware を使うマイクロフレームワークを書いてみた - ぷぎがぽぎ
コードはこちら。https://github.com/brtriver/karen [追記] この記事に書いてあるコードからさらに改良加えてApplicationレイヤーを作りました(v0.2) 詳しくはこっちの記事を参照をば http://d.hatena.ne.jp/brtRiver/20160106/karen_framework この記事の時点のコード(v0.1)を見たい場合は https://github.com/brtriver/karen/tree/v0.1.3 からどうぞ。 なにこれ？ PSR-7が用意されてからコンポーネントを色々好きなのを選択できる時代が来つつあります。 たとえばzend-expressiveとか。 ただフレームワークががんばってこれらを抽象化しようとしてるのですが、もっとシンプルでもいいなぁと。 というわけで、コンポーネントをむき出しにして、ざぁーっと
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
PHPのJSON HashDosに関する注意喚起
4年前にHashDos（Hash Collision Attack）に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね？ json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
