はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Ruby Hit Squad
¿Cómo jugar a la lotería de navidad online de forma segura? La Loteria de Navidad Online es una tradición muy esperada por millones de personas en España. Con la creciente popularidad de las plataformas en línea, ahora es posible participar en este emocionante… Mejor ruta por cabo de gata para este verano El Parque Natural de Cabo de Gata-Níjar, ubicado en la provincia de Almería, es uno de los de
ウノウラボ Unoh Labs: ベンチャー流Webサービスの作り方(開発チーム編)
尾藤正人(a.k.a BTO)です 前回はWebサービスを作るときの企画の部分について書きました (ベンチャー流Webサービスの作り方(企画編))。 今回はWebサービスを作るときの組織作りについて書いてみたいと思います。 僕がウノウに入って始めたのがフォト蔵の開発でした。 当初は開発が僕、ディレクションが代表の山田という二人体制でやってましたが、 組織が大きくなるにつれてだんだんと人数が増えていきました。 現在は僕も山田もフォト蔵からは離れて新しいチームで開発を行っています。 二人体制から始めて、少しずつ人数を増やしていって、 立ち上げメンバーが開発から離れるまでいろいろ経験しながら 自分が感じた事を簡単にまとめたいと思います。 ・最終決断は一人で 何をするのか、戦略はどうするのか、方向性は何なのか、最終的な決断はリーダーが一人で行います。 個人の主張を尊重しすぎて、各々が好きな事を始め
人気のAPI／フレームワークを作るための39カ条
ある仕様を利用するための網羅性の高いライブラリを用意したいとき 再利用性が高い（と思われる）プログラムをライブラリ化したいとき Webシステムを外部から利用してもらうために一部分を公開したい場合 多人数で開発する事柄で共通化させておきたい部分をまとめたい場合 ほかの言語で作られたアプリケーションをある言語で利用したいときの橋渡し用 ちなみに、JSP／Servletの世界でよく使われているStruts Frameworkは開発者のCraig McClanahan氏が休暇中に思い付いて開発したものだそうです。オレゴン州のビーチで、ラップトップに向かい、3日間の休暇中ずっとコーディングしていたそうです。 一緒に行った奥さんは機嫌が悪かったようですけど。 ここでは、作成したAPIが自分だけではなく、多くの人に使ってもらえるよう、便利に使えるポイント、広く普及するためのポイントをとらえていきましょう
【ハウツー】Rubyでも継続的インテグレーション!! - Ruby版CruiseControlを使ってみよう (1) CruiseControl.rbが正式リリースに (MYCOMジャーナル)
ビルドツールの代表的なものと言えばUNIXプラットフォームにおけるMakefileや、Java開発で使われるAntやMavenが挙げられる。これらのツールにお世話になっているデベロッパーは多いだろう。しかし、複数のデベロッパーが共同でアプリケーションを開発するとなると、それらのツールでは対応できない場面も出てくる。 そこで、ベンダーやオープンソースコミュニティでは、共有リポジトリ上にプログラムを格納するだけでビルドを自動的に実行するツールを開発している。そういった統合ビルドツールは「継続的インテグレーションツール」と呼ばれ、大抵は、ビルド結果をまとめたレポートを生成し、Webページやメール、メッセンジャーなどで自動配信する機能も備わっている。チーム開発を進めるうえで大変重宝するはずだ。ここでは、そのうちの一つとして、最近新しいエディションがリリースされた「CruiseControl」を紹介
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
■sanonosaベンチャー起業日記:バグがあってもいいではないか - livedoor Blog（ブログ）
ベンチャー企業の成長はなかなかドラマチックなので、これまでのベンチャー起業と成長にまつわる経験をblogとして記してみることにしました。企業秘密な部分には一切触れないつもりですが、所属企業名は今は明かせません（退職したら公開するかもしれませんけど）。 「大きな目標を達成するためには、時にはバグを放置するのはやむを得ない」というのが私の経験則です。無論致命的なバグに関しては放置できませんが、そうでないのであれば大きな目標達成に近づくために有効な開発案件を優先させたほうが最終的には利益が大きい場合が多々あります。 と、このように書くと反発したくなる方も多いでしょうが、これは私の経験則から生まれた事実なのでどうしようもありません。それでも納得できない方はこう考えてみてください。「自分が借金を負ってまで会社を創業し、従業員をたくさん雇いました。今、とある機能の開発をすれば黒字化することがわかって
ODD - おもいやり駆動開発：An Agile Way：オルタナティブ・ブログ
思いやり駆動開発（ODD） ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製
ウノウラボ Unoh Labs: バグに効く習慣〜より良いテストを実現する企業文化
こんにちは！ やまもと＠テスト番長です。 プロダクトの品質を上げるには、会社ぐるみで品質管理に取り組む意識が重要です。 より良いソフトウェアテストを実現する為の企業文化として、大事だと思うことを幾つか挙げてみたいと思います。 新人にまずやってもらうことは？ 新人テスターをいきなりテストに参加させるのは良くありません。製品への理解が深くないと有効なテストは出来ないからです。 まずは製品の仕様を覚えてもらったり、バグレポートの書き方を覚えてもらったりしなくてはいけないのですが、仕様書をポンと渡して、「これを見ながら製品を全部動かしてみて」といった指示を出しても現実味がなくモチベーションは揚がらないでしょう。 最初にやってもらうことは、先輩テスターの書いた障害報告の再テストか、 画面遷移図の更新など手探りで学習しながら行えることが良いと思います。 極力固定したビルドでテストする テスト対象の
モデリング・リファクタリングのススメ
ビジネス・モデリングなどのモデリングを始めてはみたものの，なかなか上手くモデリングできない…そんな悩みを持っている方も多いと思います。そこで，今回はモデリングを上達させるための「モデリング・リファクタリング」という方法をご紹介します。 モデリング・リファクタリングとは 「モデリング・リファクタリング」とは筆者が考えた造語です。（すでに誰かによって提唱されているかもしれませんが）筆者が発明したものではなく，モデリングに慣れている方なら自然とやっているようなテクニックです。 もともと「リファクタリング」というのは，小さなプログラム（例えばクラス）を作るときに，プログラムの外側の仕様（使われ方）は変えずに，中身の構造だけを変えることです。 なぜそんなことをするかというと，とりあえず仕様は満たしていたとしても，中身が汚い設計のままでは，変更に弱く，保守性も悪いからです。そこで，小さなプログラムを作
「サービスは半日で完成させる」—— SETAKE・たつをさん
「有名人身長推定サイト SETAKE」「EREK」などのサービスを作ったたつをさんはドメイン取得からサービスリリースまでは半日でこなすという。飲み会で生まれたアイデアをもとにサービスを開発することもあるため、ペンはどこにでも持ち歩く工夫をしている。 「ひとりで作るネットサービス」第11回目は、Web APIを活用して次々と小粋なサービスを開発するたつをさん（35）にお話をうかがった。「ドメイン登録からサービスリリースまで半日が目安」と言い切る彼は、どのように企画・開発・運用を行っているのか。その秘訣に迫った。 飲み会の会話から「有名人身長推定サイト」が生まれた 「作ったものはたくさんの人に使ってもらいたいですよ。エンジニアですから」と話すたつをさん。彼が作るサービスはWeb APIを使ったシンプルなものが多い。ちょっとしたアイデアが、情報の見せ方を工夫することで“意外と便利”なサービスにな
新しいソフトウエア開発手法
マーチン・フォウラー チーフサイエンティスト , ThoughtWorks 過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。 開発手法ゼロから、重量級の手法へ、そして「ライトな」手法へ 予見的手法 対 適応的手法 デザインとモノ作りを分割する だいたい仕様を予見できたことがない 予測は絶対に不可能なんだろうか? 予見不可能なプ
■sanonosaベンチャー起業日記:きれいに作りすぎないことの重要性 - livedoor Blog（ブログ）
ベンチャー企業の成長はなかなかドラマチックなので、これまでのベンチャー起業と成長にまつわる経験をblogとして記してみることにしました。企業秘密な部分には一切触れないつもりですが、所属企業名は今は明かせません（退職したら公開するかもしれませんけど）。 ITベンチャー企業のジレンマとして「システムをきれいに作らないとあとで運用が大変になるけど、きれいに作っていたらビジネススピードに追いつかない」というものがあります。このジレンマは概して「営業・マーケティング・経営陣」vs「技術陣」という対立を生みます。こういった場合どう考えればよいか。 これは結果論ですが、例え後で運用が大変になったとしても、不完全でもビジネススピードに合わせてシステムをリリースさせていったほうがよいようです。 この根拠はいくつかあります。1番目はあとで発生する運用コストよりも早くビジネス展開したほうが結果的に得られる利
Martin Fowler's Bliki in Japanese - ペンディングHEAD
http://martinfowler.com/bliki/PendingHead.html 2007/4/26 諸君、私は継続的インテグレーションが大好きだ。 シンプルなプラクティスが開発チームに甚大な影響を与えるのが好きだ。 だがあらゆるプラクティスがそうであるように、欠陥^H^H^H^Hカイゼンの余地がある。 Paul Duvall（まもなく出版される継続的インテグレーション本の著者）がこの点について指摘していた。 コミットビルドが失敗すると、チーム全体に影響し、それが修正されるまでスピードが落ちてしまう。 ThoughtWorksで継続的インテグレーションを始めた頃、 そのやり方について心配していたことがあった。 ThoughtWorks 2000のスタイル（訳注：2000年頃のやり方）と C3プロジェクトで使っていたスタイルが違っていたからだ。 ThoughtWorks 2000
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
顧客の機能要求に折れないこと!
Kathy Sierra /青木靖 訳 2006年5月10日 製品やサービスが成功するほど、ユーザの要望を受け入れるようにというプレッシャーは強くなる。ユーザが多くなるほど、要望の範囲は広がっていく。あるユーザにとっての ｢それがないんだったら買わない｣機能が、別のユーザには取引をぶちこわすものになる。そしてあなたの製品やサービスが人気になるほど、そういった要望は、要求と最後通牒へと変わっていき、ついには痛烈な批判になる。 私たちになしえる最悪のことは、それに折れるということだ。しかし要望/要求や批判が強く、怒りを帯びたものになるほど、誘惑に抵抗するのは難しくなる——｢この1個だけ付け加えれば･･･きっとあの連中もおとなしくなってくれる｣ しかしあらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私
ウノウラボ Unoh Labs: 個人でWebサービスを作る時に一番大変なこと
komagataです。 最近、個人でWebサービスを作る人が増えています。 僕も個人（2人）で※Plnetというしがないサービスを作っています。Plnetを作るにあたって、もう一人の作者t-kawaduと目標に掲げたのが、 「とにかくオープンすること。」 なんて低い目標だと驚かれるかもしれませんが、仕事で作るのとは違って個人でWebサービスを作る上で一番大変だったのは“やる気を継続させること”でした。やる気を継続させるためにやったことを紹介したいと思います。 （普通こういうことは成功しているサービスの作者が言うものですが・・・） 寝る前にドメインを取る よく飲みながらこれこれこういうサービスを作ったら便利なんじゃないか、なんて話をしますが実際に作ったためしがありませんでした。自分の口ばっかり具合にうんざりしていたので、寝て気が変わる前にドメインを取りました。 寝る前にレンタルサーバを借りる
今日は楽しいバグ修正の日 : 小野和俊のブログ
昨日でこのところ取り掛かっていた大きな仕事が一段落したので、 今日からは待ちに待ったバグ修正の作業を始められる。 この1ヶ月、私はバグ修正がしたくてしたくてたまらなかった。 今朝は出社してすぐにバグレポートの一覧を表示して、 これは早く直さないとまずいな、とか、これはちょっと後でいいかな、とか、 レポートの内容を見ながら優先度順にバグを並び替えていく。 これからこれらのバグが次々に修正されていくのだと思うと、 もうこの時点でワクワクしてくる。 新しいソフトウェアのアイデアを考えるのは大好きだし、新機能を実装するのも大好きだ。 でもバグ修正には他の作業にはない独特の快感がある。 新しいソフトウェアを開発するのは見た目にも派手だし、世間の注目を集めやすい。 それに比べると既存のソフトウェアのバグ修正というのは地味で注目されない作業だ。 だが、バグ修正は確実に誰かの役に立つ。 もちろん、自分の考
インターネットを利用した情報提供サービスの利用規約作成のポイント
インターネット情報提供サービスの利用規約作成のポイント 2000年5月16日 Home >>> 論考・資料室 >>> インターネットを利用した情報提供サービスの利用規約作成のポイント インターネットを利用した情報提供サービスは様々です。ここ数年間の間に、提供される情報の種類も豊富になり、質も向上しているようです。利用者にとっては嬉しい限りです。そこで、このような情報提供サービスにおける利用規約のポイントをまとめてみました。一般的な内容で具体性に欠けますが、利用者への情報開示とサービス向上を目指す際に、ご参考にして頂ければ幸です。 原則として、インターネットの特性を考慮しつつ、サービス内容に合った規約作成を心がけ、それに加えて一般的な契約条項を網羅するのが良いでしょう。 （１）前文 ここでは、規約（利用にあたってのルール）全体の概要を示します。誰がサービスを提供するのか、サービスを受けるのは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TRICHORDの背景 - (3) 人に目を向ける