今の状態はやばい 赤塚 @3a3k
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
そらはーです! RSpec で pending 使ってテストを一時的に無効化した事ある方は大勢いらっしゃるんじゃないでしょうか! なんらかの事情で一時的に pending せざるを得ない状況ならともかく、pending したなら責任をもって該当のテストを治すか、そもそも不要なら消すなどといった対処をしてもらいたいものですね! でも、実際来週までには!とか言っても放置する人間や、そもそも直さず1年,2年以上放置される事もしばしばあるのが現実です……… pending を放置する事によって、実はそれは(他の人にとって)かなり重要なテストで、そんなテストがpendingされてる訳ないと思った、他のメンバーによる変更で実はそのテストがコケて事故っていたという可能性も存在するわけです。 重要なテストをAさんが pending する (「テストは追って修正する」みたいな感じで) 比較的大きめの変更を
2012年08月21日 ソフトウェア開発でのテストとは何かを単純に言うと、成果物が期待通りであるかを検証する作業といえる。こう動作してほしいという期待を入力に、成果物がその通りに動作するかを検証するのがテストである。 となると、成果物とは何で、期待とは何かが問題になるのだけれど、これが一筋縄ではない。というのも、システムは十分に複雑なので、ある部分を複数の部分に分けることもできるし、その部分をより大きな部分のパーツにすぎないとみなすこともできるからだ。 だからといって、一番大きな単位でもって期待通りにあるかどうかを検証すれば済む話かというとそういうわけでもない。というのも、大きな単位には大きな単位なりの期待が、小さな単位には小さな単位なりの期待というものが存在するからだ。 システム開発は、ひとつのものさしではかることができない。システムをつかって業務を遂行できるかという検証と、その部品であ
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
こんなエントリを書いて早4ヶ月。 なんでアジャイルに取り組みたいか - kaji_3's blog BtoBで対価を頂いてアジャイル開発として遂行した案件が先日終わったのでKPT形式でふりかえります。 前提 期間一ヶ月半 Scrumを参考にしてプロジェクト運用 イベント用WEBアプリケーション 案件の内容をぼかして書いているので、一部整合性の合わない記述があるかも知れませんがご了承ください。 Keep 高い顧客満足度 プロダクトオーナーから「自分たちの意志が反映できた物を作ることができた」とコメントを頂きました。フィードバックから実際のものができるまでのスプリントという考えについても好評でした。顧客の社風として良い物を最後まで模索するという考えがあるとのことで、仕様凍結後の変化は、仕様変更として好まれないウォーターフォールには不満があったとのことでした。 育つシステム 当初想定されていたシ
5分で分かる、「スクラム」の基本まとめ:開発チームを改善するためのスクラムTips(8)(1/2 ページ) 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み(フレームワーク)」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
「ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと」に釣られてみます。 6つの誤解は次の通り。 既にあるソフトウェアを流用した方が速く作れる ソフトウェアはハードと違って後から容易に直せる 誰が作っても中身は同じ品質になる 共通部品から先に作ることが出来る 人を増やせば一度に沢山の機能が作れる 正確な見積もりを出すことが出来る 記事の前提は"お客さんはITにそれなりに詳しい(けどプログラミングはしたことがない)情報システム部門の人"ということだと思います。 この6つは誤解しやすいし、僕もお客さんと会話する内容です。でもね、お客さんがそう感じていることも事実です。なるべく安く早く、そして変更に強いシステムを作りたいと願うことは当然のことです(もちろん予算どおりに)。 ソフトウェア開発に職人的(あるいは芸術的)要素があることは間違いありませんが、それ
隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな
CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…Drecom Co., Ltd.
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
先日ご案内していた通り2017年5月31日を持ちまして、サービスを終了いたします。 長らくご愛顧賜りまして、誠にありがとうございました。 サービス終了に伴いまして、ユーザー様からお預かりしていた個人情報やプログラム、各種データなどは、 当社が責任を持って削除いたします。 当社では様々なインターネットサービスを提供しておりますので、 機会がございましたら、 ご利用いただけますと幸いです。 Sqaleに関するお問い合わせは、こちらのお問い合わせフォームからお願いいたします。 平素はSqale(スケール)をご利用頂き、誠にありがとうございます。 2012年8月より運営してまいりました「Sqale」でございますが、2017年5月末日を持ってサービスを終了することとなりました。 ご利用中のユーザー様にはご迷惑をおかけし、誠に申し訳ございません。 現在ご利用中のプログラムやデータベースのデータにつきま
Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro
HTMLとJSだけで何か作ることが多くて,開発環境をどう作るかとか,ノウハウみたいなのがたまってきたと思う. ローカルのHTMLファイルをブラウザで開くと,いろんな制約がある.たとえば,ファイルAPIを使えないとか,YouTubeのプレイヤー貼り付けできないとか,/js/みたいに絶対パスで指定することもできない.ページ1枚なら他のページにリンクとかいらないけど,ウェブサイトを作ってるときとかは,/help/でヘルプページを表示するとか書いたときに,ローカルのファイルを見てリンクが切れてるということになる.開発中はリンク切れだけど本番サーバーに置くと見れるはずとか言って開発するのは怖い. サーバーでRubyとかPerlが動いてるみたいなときはローカルでサーバーを立てて開発してると思う.HTMLとJSだけ使うときでもローカルでサーバーを立てて開発したほうがいいと思う. 開発中は,nginxでフ
Internet Explorer の自動アップグレードについて | TechNet 長かった… 本当に長かった… やっと、IE 6, IE 7 が居なくなるのですね… uupaa.js ver 0.8 に埋まっている処理から情報を抜き出し IE 6, IE 7, IE 8 が居なくなった未来では何が可能になるのか抜粋してみました。 IE8 でやっと使えるようになる機能 一部は IE 6 や IE 7 でも使えるのですが、対応が限定的だったり不具合が多かったりと、安心して使えなかった機能も含まれています。 display: inline-block display: table, table-cell など position: fixed; E:active {...} E:focus {...} E::first-child {...} E:lang(C) {...} E::after
アジャイル開発手法の1つとしてよく知られるXP(エクストリームプログラミング)には、原理となる5つの価値「コミュニケーション」「シンプル」「フィードバック」「勇気」「尊重」があります。 手短に説明すると、プロジェクトにおけるコミュニケーションをつねに保ち、シンプルに作り、システムや人からのフィードバックを反映し、勇気を持って設計し開発しつつ、プロジェクトメンバーはお互いを尊重する。ということを意味しています。 先日行われたデブサミ2012のセッション「アジャイル開発の10年と今後を語ろう」で、実は5つ目の価値である「尊重」は後から付け加えられたものなんだと、講演者の平鍋さんが説明されていました。 たしかに、手もとの書籍「エクストリーム・プログラミング入門」(2000年発行)を見てみると、4つの価値しか書いてありません。調べてみると、2005年発行の「エクストリーム・プログラミング入門 第2
テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、2台構成を3台構成にするよりも、はるかに1台構成を2台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると2本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち
野中郁次郎先生を一橋大学に訪問、アジャイル、スクラム、創造、マネジメントについてディスカッションする機会を得ました。 先生はもちろん、ナレッジマネジメント、知識創造経営、そして、Scrumという言葉を生んだ、「The New New Product Development Game」という1986年の論文の著者の一人。もう一人は現在ハーバードの竹内さん。一昨年の AgileJapan 2010の基調講演、昨年は、Jeff Sutherland との対談が Innovation Sprint で実現、ハーバードの竹内さんのクラスにJeff Sutherland が呼ばれたりするなど、アジャイル会との交流が進んでいます。 ぼくが持ち込んだ、顧客を巻き込んだ、見える化された職場のワークスタイルの写真なんかを見ながらお話ししていたら、 PDCAって日本人大好きなんだけど、これは本当に欲しいもの、い
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 [スクープ]特許庁、難航していた基幹系刷新を中止へ - ニュース:ITpro 朝日新聞デジタル:費やした55億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO(ガバメントプログラムマネジメントオフィス)補佐官」の肩書きで2009年まで民間から参加した萩本順三氏(現 匠BusinessPlace 代表取締役社長)がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO(ガバメントプログラムマ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く