タグ

開発に関するt_yanoのブックマーク (52)

  • いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道

    最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 (なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

    いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
    t_yano
    t_yano 2012/02/19
    とてもよい記事。開発者は考えないといけないところだよなー
  • 新規サービスサイト制作の受託開発はなぜ上手くいかないのか - 思っているよりもずっとずっと人生は短い。

    メモ。 自分で自社サービスを運営する立場になってわかったこと。あんまりよそで言われてないような気がするので書いてみます。ちなみに業務システムとかは関係ないです(というのは最後にもちょっと触れます)。 ふつう、受託開発では、9割がた成功する、というか失敗しないように開発の体制を組みます。まあ仕事で請けているので当たり前の話ですね。もっとも、先方のスケジュールや予算の都合で、7,8割くらいになる場合もあります。その場合は始める前から残念感というか貧乏くじ感があったりしますが、断れない場合もあるので仕方ありません。それでも、基的にはそんなに失敗しないようなスキームにしようとするはずです。 ところが。新規にビジネスとしてサービスを立ち上げようとする発注側に立ってみると、「9割がた成功する」という基準はちょっとありえないことに気づきます。言ってみれば、新規サービスを作るということは、新規に事業を起

    新規サービスサイト制作の受託開発はなぜ上手くいかないのか - 思っているよりもずっとずっと人生は短い。
    t_yano
    t_yano 2011/06/08
    これは的を射ているように感じた。「予定通り完成する」ではなく「ビジネスとして成功する」のが目的で、ある程度捨てることが前提の開発。そしてコスト支払いの争いとか。
  • ヒッキーがリーダやってみた

    すぺっく 仕事:ソフトウェア開発 性格:ヒッキー。 立場:特定派遣。メンバーは自社の人。人事権はない。 何の因果か、リーダーとかやるはめになったのでその経験を書いてみる。 技術的な話はない。 ■方針:プブチャラティの精神。 「任務は遂行する。部下も守る。両方やらなくちゃならないのが『幹部』のつらいところだな。覚悟はいいか? 」 プブチャラティさん!俺やるよ! …というわけで、尊敬するプブチャラティさんの姿勢をすべての行動の方針とした。 ■実際にやったこと。 ○作業日誌を送りつけた。 日やった作業とともに顧客と自社の上層部に送りつけた。 われわれたはちゃんとやってますよという言い訳と、問題が発生した場合に上司に詰め腹を切ってもらうため。 ○朝会 毎朝、問題点と作業の状況を2,3分で確認した。 これで、問題点を抱え込まない状況を作り出すのと、一体感、連帯感的なものを演出した。 ○作業の目的を

    ヒッキーがリーダやってみた
    t_yano
    t_yano 2011/02/20
    「あの記事書いた本人です」ってブログを(証拠付きで)書けば職はすぐに得られるんじゃないの、と思った。
  • Engadget | Technology News & Reviews

    How to watch NASA's first Boeing Starliner crewed flight launch today (scrubbed)

    Engadget | Technology News & Reviews
    t_yano
    t_yano 2010/10/29
    ドラえもんの手はこういう仕組みだったのか
  • Python初心者によるPythonのいいところ、はまりどころのまとめ - Webtech Walker

    Python勉強し始めて一ヶ月くらいたったんで一度復習を兼ねてまとめてみようと思います。僕が今までPHPとかPerlとかJavaScriptを使っていて、Pythonはこうやるのかーとか、これは便利だなーと思ったところ、開発していてはまったところなどピックアップしてみました。 初めてのPythonを読んで初心者向け勉強会に参加した程度の知識です。とりあえず初めてのPythonがかなりいいのでこれ読むだけで大体基礎は習得できた気がします。基的な文法の説明だけでなく、大事なことは何回も繰り返し書いてあったり、Pythonの思想などにも触れているのでなぜこういう実装になっているかということも理解できます。これオススメ。 尚、このエントリーではPythonのバージョンは2.5をベースにしてます(主にGoogleAppEngineで使ってるので)。間違えなどあったらツッコミお待ちしてます。 文法、

    Python初心者によるPythonのいいところ、はまりどころのまとめ - Webtech Walker
  • MessagePack for Java 作りかけリリース! - Blog by Sadayuki Furuhashi

    バイナリシリアライズ形式 MessagePack のJava版の、作りかけをリリースしました^^; シリアライザやデシリアライザの体は実装できていますが、例外やインタフェースの完成度はまだ高くないです。開発者募集中! msgpack-0.0.0.jar msgpack-src-0.0.0.tar.gz 実装はPure Javaです。JNIは使っていません。 MessagePack は Ruby, Perl, Python, PHP などのLLにも対応しているので、JavaとLLの間で簡単にオブジェクトを交換できるようになります。 ベンチマークテスト 他のシリアライズ形式と速度を比較してみたところ、↓このような結果になりました。 thrift-protobuf-compare MacBook Pro 2.53 GHz Intel Core 2 Duo java-1.6.0_17 Messa

    MessagePack for Java 作りかけリリース! - Blog by Sadayuki Furuhashi
    t_yano
    t_yano 2010/08/05
    Serializableより10倍高速なシリアライザ実装。ちょうとシリアライザを調べていたところ。
  • 知識ゼロからはじめるiPhoneアプリ開発 - A Day In The Life

    iPhone アプリ開発を初めてはや2年。わけわからんレベルからなんとかアプリをリリースするところまでこぎつけました。もともと趣味ではじめた事ですが今は仕事でも iPhone アプリ開発をしています。ここに至るまで自分が調べたことや参考にした文書をアプリの構想からアプリをリリースするまでの手順にそってまとめてみました。 iOSアプリ開発関連のを書きました 初めて iOS アプリ開発をされるかた向けに「プロの力を身につける iPhone/iPadアプリケーション開発の教科書」というを書きました。 この記事を読んで iOS アプリ開発に興味を持たれた方におすすめです(2013年2月26日発売)。2015年1月17日にSwiftに対応した改訂版がでました。 の内容に関する詳しい記事はこちらです。 iOSアプリ開発のを書きました 初期投資 8400円とプライベートな時間、iPhoneまたは

    知識ゼロからはじめるiPhoneアプリ開発 - A Day In The Life
  • “誰でもプログラマー時代”の先端サービス「QuickFuse」【増田(@maskin)真樹】 | TechWave(テックウェーブ)

    1990年代初頭から記者としてまた起業家としてITスタートアップ業界のハードウェアからソフトウェアの事業創出に関わる。シリコンバレーやEU等でのスタートアップを経験。日ではネットエイジ等に所属、大手企業の新規事業創出に協力。ブログやSNSLINEなどの誕生から普及成長までを最前線で見てきた生き字引として注目される。通信キャリアのニュースポータルの創業デスクとして数億PV事業に。世界最大IT系メディア(スペイン)の元日編集長、World Innovation Lab(WiL)などを経て、現在、スタートアップ支援側の取り組みに注力中。 Googleが7月13日、コーディング不要で誰でもAndroidアプリが開発できるサービス「App Inventor for Android」を発表したことで、アプリ開発への関心が高まったという人が多いようだ。ちなみに、iPhone/iPod touch向

    “誰でもプログラマー時代”の先端サービス「QuickFuse」【増田(@maskin)真樹】 | TechWave(テックウェーブ)
    t_yano
    t_yano 2010/07/27
    ビジュアルプログラミング環境
  • ガラパゴス化する日本の開発環境

    とある日企業との仕事で衝撃を受けたことを前回のエントリーで書いたのだが、より驚いたのが、それに対していただいたコメントやはてぶのほとんどが別に驚きもしない、うちもおなじ、というものだった。 ・いや、おそらく日では普通だと思います。 ・そもそも人事部が採用する時に、技術スキルの高い人は取ろうとしませんし、ユニットテストのような基礎知識さえも全く知らない人が大半を占めます。 ・見直すための工数は悪、辻褄合わせるのが正義。 ・以前、某ERPパッケージの下請けで働いていましたが、テストを手動でやり続けるのに嫌気がさして、辞めました。あれはになる...。 ・日では専門家を軽視して、「ビジネスゴールを最優先して考える俺は偉い。技術馬鹿、専門馬鹿とは違う」っていうタイプの人材が評価される組織が結構多いのですよね。 ・あるあるすぎて、笑えない。 ・請負的な開発はこういった傾向が強いと思う。残念なが

    ガラパゴス化する日本の開発環境
    t_yano
    t_yano 2010/05/11
    さすがに選べばちゃんとやってるところもあるんだがね。
  • Pythonが金融向け言語に成りそう

    Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

    Pythonが金融向け言語に成りそう
    t_yano
    t_yano 2010/04/26
    pythonがビジネス言語
  • ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記

    20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが(今でも職業としてコードを書きたいと強く思っている)、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数

    ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
    t_yano
    t_yano 2010/02/12
    いい記事だと思った
  • こんな顧客に気をつけろ 〜 未然にトラブルを防ぐ10のNGワード

    いつも さぶみっと!JAPAN をご愛顧いただきありがとうございます。 この度、誠に勝手ながら2017年9月29日(金)を持ちまして、「さぶみっと!サイト制作マッチング」のサービスを終了させていただきます。 日頃よりご利用いただいております皆さまにはご迷惑をおかけすることとなり、誠に申し訳ございません。長らくのご愛顧、厚くお礼を申し上げます。 終了するサービス ・サイト名:さぶみっと!サイト制作マッチング ・URL:http://hp.submit.ne.jp/ ・サービス終了日:2017年9月29日(金)11:00 サービスご利用中の方へ ・案件情報のご登録は2017年8月28日(月)より停止しており、新規でご登録をいただくことはできません。 ・現在掲載中の案件に提案を行うことはできますが、サービス終了日を持ちましてサイトをご利用いただくことはできなくなります。 ・現在サイト内で商談中の

    こんな顧客に気をつけろ 〜 未然にトラブルを防ぐ10のNGワード
    t_yano
    t_yano 2009/12/12
    たしかに経験あるなあ
  • 「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言

    ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル・ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ

    「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言
    t_yano
    t_yano 2009/11/20
    その考え方でずっと来てるし、昔難しかったものがいまは恐ろしく簡単になったのもその成果ともいえる。ただ、人はあるものが簡単になったら、今度はその上でまた別の何かをやりたくなるんだよね。お客さんも。
  • アジャイル開発のボトルネック | Social Change!

    お金なら出しますから、4ヶ月のところを2ヶ月で作ってくれませんか?」 システム開発で、顧客からこう言われた時、どうするか? SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか

    アジャイル開発のボトルネック | Social Change!
    t_yano
    t_yano 2009/10/20
    『発注側のかけるコスト(工数)の限界が、ソフトウェア開発における速度の限界点』 結構納得できる。すくなくとも、発注側(客側)の判断速度が開発速度に直結しているという実感はある。
  • Q.電球を変えるのに、SE/PGが何人必要か - SiroKuro Page

    答え 約2000人月 開発の流れ 要件定義 顧客の発注を受ける 1次請け、要件定義書の執筆を始める 1次請け、顧客と交渉し、家の中に繋がっている家電製品を全て調べ上げる 一次請け、基設計実施要領の執筆を始める 基設計 この工程は、2次請け以下には秘密裏に行われている 詳細設計 1次請け、詳細設計実施要領の執筆を始める 1次請け、だいたいこのあたりで2次請けへと乾坤一擲 2次請け、使用する規格やフレームワークなどの部品を選定開始 詳細設計書の執筆がスタート、電球の大きさや重さ、丸み、光度、味、匂いなどを定義する このあたりで、既に5次請けくらいまで仕事が割り振られている 製造 1次請け、製造工程実施要領の執筆を始める 1次請け、単体テスト実施要領の執筆を始まる 5次請け、電球フィラメントのくるくるを手で作成しはじめる 4次請け、求める匂いが上手く出せないと3次請けに駄々をこねる 3次請け

    Q.電球を変えるのに、SE/PGが何人必要か - SiroKuro Page
    t_yano
    t_yano 2009/08/06
    だいたい合ってる。そして「こんな無駄なこと遊びより価値があるのかね」という意見に妙に共感した。
  • Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby

    以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日語訳である。 ThoughtWorksは、2006年から格的なプロジェクトRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。

    t_yano
    t_yano 2009/07/13
    『私は、プロジェクトのみんなと話すときはいつも、O/RマッピングフレームワークはSQLを80〜90%を隠してくれるが、きちんとしたパフォーマンスを得るにはSQLをいじらなければいけないと言っている』これは正しい。
  • http://twitter.com/t_wada/status/2217678785

    http://twitter.com/t_wada/status/2217678785
    t_yano
    t_yano 2009/06/18
    ア女医ルソフトウェア開発。TDDで何を開発していたんだ。
  • How to be a program manager – Joel on Software

    I’m Joel Spolsky, a software developer in New York City. More about me. Read the archives in dead-tree format! Many of these articles have been collected into four books, available at your favorite bookstore. It’s an excellent way to read the site in the bath, or throw it at your boss. Ready to level up? Stack Overflow Jobs is the job site that puts the needs of developers first. Whether you want

    How to be a program manager – Joel on Software
    t_yano
    t_yano 2009/03/11
    MSの「プログラム・マネージャ」とはなにか、という話っぽい。あとで。
  • 業務システムとか - monjudoh’s diary

    クソの役にも立たない言葉なので使うのやめようぜ というのは半分冗談だけど半分音。 「業務システムでは実装なんて3割程度だから大して重要ではない」がSI業界が解決すべき問題を端的に示している - @katzchang.contexts このエントリ見てふと思ったんだけど、 一口に業務システムと言っても、お客さんの商売の種類や何のシステムかによってずいぶん違うと思うのだ。 IT技術者の所属している業界について、SI業界とWeb業界みたいにきれいに分かれているように言う人も結構いると思う。 でも、例えば、ECサイトのユーザ側じゃなくてバックエンド側のシステムの開発はWeb業界の仕事となると思うんだけど、 SI業界の仕事で似たようなのあるでしょ? 同じようなものを扱ってるのに、SI業界の仕事だからどうだとかWeb業界の仕事だからどうだ、 とか言ってたら正確な議論はできないし、逆もまたしかりで、

    業務システムとか - monjudoh’s diary
    t_yano
    t_yano 2009/02/21
    今の仕事はもろに業務システムだが実装6〜7割くらいな気がする。まあ実装中に細かい仕様は変わるだろうという読みがあってのことだけども。こういうのって特殊なんだろうかなー。
  • はてなブログ | 無料ブログを作成しよう

    今の自分は、出会った人や読んできたによって、できあがっている あの小冊子は、新聞の付録だったのか、記憶が曖昧で定かではないのだが、1ヶ月に1回程度の頻度で届いていた気がする。オールカラーで内容もさまざまだった気がする。その中には、プロ野球の選手名鑑もあって、私は、母から受け取り、大切にしていた記憶がある。母は、…

    はてなブログ | 無料ブログを作成しよう
    t_yano
    t_yano 2009/02/15
    あずまんが/あるあ...あるある!