タグ

開発に関するbull2のブックマーク (147)

  • 大企業アジャイルの勘所 #devlovex #devlovexd

    DevLOVE200 Bridge の登壇資料です。 https://devlove.doorkeeper.jp/events/60269 デブサミの以下の資料の焼き直しです。 https://www.slideshare.net/i2key/devsumib

    大企業アジャイルの勘所 #devlovex #devlovexd
    bull2
    bull2 2019/06/23
    大変参考になる。
  • VSCodeのRemote Development機能が革命的な話。 - Crieit

    背景 今月始めにMicrosoftからRemote Development Extension Pack. というのが発表された。簡単に言うと、VSCodeでコードを書くOSとプラグインが実行されるOSを別にすることが出来る。 よくあるパターンで、「MacでNokogiriがビルドできません」「WindowsでESLintを実行するにはどうしたら良いですか」みたいな質問がある。 最終的にサービスを公開するときにはどうせLinux使うのに、開発するときしか使わない別のOSで同じものを動かす苦労って無駄だよなあ、と思っていた。 じゃあ最初からLinuxで開発すればいいかというと、最近の高度化したWeb開発はIDEの支援なしに実行することが困難で、RubyだったらRuboCopJavaScriptだったらPrettierやESLintで文法チェックしてもらわないと人類にはついていけない。これら

    VSCodeのRemote Development機能が革命的な話。 - Crieit
  • ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ

    マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた1つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは? 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ

    ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
    bull2
    bull2 2016/02/11
    他部署で開発したソフトの作りを開発者に聞いていたら、俺の部下を勝手に使うな、と怒られたな。偉い人は部門間連携でシナジーを発揮しろというけど、セクショナリズムが強いと実現が難しい。
  • 炭坑の庭師 - steps to phantasien

    Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro

  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
    bull2
    bull2 2010/11/24
    滝はダメだと言われ続けているが、それでも無くならないのは何故だろう?100人×1年規模の新規開発をAgileでうまくまわせるのかな?MSはVS2010の開発で少チーム製でやってると言ってたけど、これは改良だからなぁ
  • ホント?「業務定義」だけでシステム完成:日経ビジネスオンライン

    「今、困っていることは」と聞かれて、こう答える経営者はまずいない。不祥事や事故を起こした企業の経営者であれば「信用を取り戻したい」と言うかもしれないが、昔からそうだったとなると尋常ではない。 スペイン語で冒頭の回答をしたのは、ウルグアイのIT(情報技術)企業、アルテッチ社(Artech)の創業者であるブレオガン・ゴンダ(Breogan Gonda)社長である。記者になって25年、スペイン語の通訳を介した取材は初めてであったが、聞き間違えたわけではない。 “魔法”と誤解されるその製品は「GeneXus(ジェネクサス)」と言い、システム開発ツールと呼ばれる製品分野に位置付けられる。情報システムの設計・開発作業をコンピューターによって支援するものだ。 不思議なことに、情報システムの設計・開発にあたって、コンピューターはあまり利用されてこなかった。一連の設計・開発作業はすべて、システムズエンジニア

    ホント?「業務定義」だけでシステム完成:日経ビジネスオンライン
  • kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥

    Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方(ビジネスモデル)に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー(経営者)にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい!・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、

    kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
    bull2
    bull2 2010/05/18
    解雇規制を撤廃すれば、ユーザ企業がIT関係者を雇いやすくなると思われ。PJ終了と共に解雇される危険もあるけどなー(多分大部分がそうなるだろうけど)
  • MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場

    読み込み>書き込みなデータベースだと、実体化ビュー (materialized view) を使って読み込み速度を上げるってのは有効な手法 ちなみに MySQL や PostgreSQL だと実体化ビューはトリガーを使って書く *1 では、トリガーベースの実体化ビューを後から追加した場合に、どうやって既存データを新しいビューに反映させるのか。 UPDATE トリガを、ビューの側に対応するデータがない場合は INSERT トリガと同様の動作をするように実装すればいい (典型的には REPLACE INTO 文を使う)。ビューの初期データ充填は UPDATE src_table SET id=id; MySQL だと CREATE INDEX CONCURRENTLY がないから副インデックス作成はスレーブでやったりする*2けど、上の UPDATE を LIMIT つきで回すことで、ビューをイ

    MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場
    bull2
    bull2 2010/03/17
    マテビュー
  • ひらめきへの4ステップ

    Amir Khella / 青木靖 訳 2010年2月17日 2004年の夏、私は最初の起業体験を変わった場所ですることになった。夏休みをMicrosoft Researchで過ごさないかという招待を受け取ったのは、私がまだ博士課程の学生の時だった。私が関心を持つ領域で研究している最高の研究者の何人かがそこにいたので、彼らがどんなことをしているのか是非見たくもあり、彼らの仕事に関わりたいとも思った。それで私は青い方の錠剤を選ぶことにした。 初日のオリエンテーションの後、自分がやることになるプロジェクトが何なのか教えてもらおうと、メンター役の人の部屋に行った。机の前に私が座ると、彼は研究論文やノートの山の間から私のことを覗き込んで、大きな笑みを浮かべながら言った。「やあ、来たね。僕らと12週間一緒にやることになるから、なんか面白くて役に立つことをするいいよ!」 彼のことを見つめながら、具体的

  • はてなブログ | 無料ブログを作成しよう

    週報 2024/04/28 川はただ流れている 4/20(土) 初期値依存性 さいきん土曜日は寝てばかり。平日で何か消耗しているらしい。やったことと言えば庭いじりと読書くらい。 ベランダの大改造をした。 サンドイッチ 一年前に引っ越してからこんな配置だったのだけど、さいきん鉢を増やしたら洗濯担当大臣の氏…

    はてなブログ | 無料ブログを作成しよう
    bull2
    bull2 2010/02/08
    Amazonはそうなってる>ITに人を合わせる。日本だと人切りができないから難しそうだ。
  • 沈没した「スパコンの戦艦大和」に補足して - SiroKuro Page

    引っかかった点が1つ。 「日の丸技術」の開発には意味がない:スパコンというのは、きわめて特殊な科学技術用コンピュータであり、世界で年間数十台しか売れないものだ。富士通がクレイの4倍以上のコストのスパコンを開発しても、世界市場では売れない。日の大学でも中規模のスパコンをリースで利用するのが常識であり、このような「日の丸技術」の開発にはビジネス的な意味もない。 池田信夫 blog : 沈没した「スパコンの戦艦大和」 これは日だけに限らない。スパコンというものは、きわめて特殊な科学技術用コンピュータであり、世界で年間数十台しか売れないものだ。IBMがクレイの4倍以上のコストのスパコンを開発しても、世界市場では売れない。世界の大学でも中規模のスパコンをリースで利用するのが常識であり、このような技術の開発にはビジネス的な意味もない。 では、なぜIBMはスパコンを開発するのか。それはビジネス的に成

    沈没した「スパコンの戦艦大和」に補足して - SiroKuro Page
    bull2
    bull2 2009/11/15
  • アジャイル開発のボトルネック | Social Change!

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

    アジャイル開発のボトルネック | Social Change!
    bull2
    bull2 2009/10/23
  • 第28回 日本企業を見限ったインドの“システム屋”から学んだこと

    経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO(最高情報責任者)を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回(第27回)で登場したインド人の“システム屋”経営者の言葉をもう1つ紹介したいと思います。彼から「日企業向けの仕事はもうやりたくない」と言われたことがあります。英語力の問題ではなく、日人はそもそもシステム開発に向いていないというのが彼の主張です。 これを聞いた私は、その場では苦笑するほかありませんでしたが、日人の“システム屋”として悔しいという感情が残りました。しかし今ようやく、この意見には反論が可能だという思いに至りました。

    第28回 日本企業を見限ったインドの“システム屋”から学んだこと
  • だれも教えてくれなかった外部設計の「極意」---目次

    外部設計書で最も大切なことは,「システム開発を依頼してきたお客様」(発注者)に読んでもらい,理解してもらうことです。外部設計書を,開発メンバーではなく,発注者に理解してもらうためには,「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。連載では,発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 [システム振舞い編]一覧表に一工夫入れることで漏れや重複をなくす 第3回 [システム振舞い編]全体を俯瞰でき,システム化範囲が一目で分かる業務フローを作成する 第4回 [システム振舞い編]発注者が理解しやすいシナリオの記述方法 第5回 [画面編]見れば“わかる”「画面レイアウト」の作り方 第6回 [画面編]画面遷移を

    だれも教えてくれなかった外部設計の「極意」---目次
  • 偽装請負のススメ:ベンチャー社長で技術者で:エンジニアライフ

    株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 偽装請負というのは、コの業界(古い隠語だけれどコンピュータ業界のことね)のいわゆる悪弊であったりするのですが、それぞれについて分からないというお話や勘違いしてることも多いかと思うので、ちょっと整理してみよう。 ● まずは言葉の意味から ■ 請負契約 納品物に責任を負う契約。つまり、成果物が完成しなければ報酬はもらえない。どのように作ったかは個別に契約していない限り問われない。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ■ 委任契約(準委任契約) 作業に責任を負う契約。ちゃんと作業をしていれば(善管注意義務を果たしていれば)成果物がなくても報酬がもらえる。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ※ ここまでを分かりや

    偽装請負のススメ:ベンチャー社長で技術者で:エンジニアライフ
  • C言語〜ゲームプログラミングの館〜

    ※ 更新履歴 ※ 2017/11/03 ・sp.8章追加 2017/10/11 ・配布しているプロジェクトをVisualStudio2017に更新(それにまつわる説明も更新) 2015/09/12 ・s.3章 Androidのようなボタンの作り方(C++) 追加 2013/09/02 ・VisualC++2012のプロジェクトを追加 2013/02/23 ・d3.5章追加 2013/02/20 ・d3.1章追加 ・d3.2章追加 ・d3.3章追加 ・d3.4章追加 2013/01/19 ・sp3章追加 ・sp4章追加 ・sp5章追加 ・sp6章追加 ・sp7章追加 2012/06/23 ・3.14章追加 2012/06/16 ・sp1節追加 ・sp2節追加 2012/02/11 ・d6節追加 2011/11/10 ・h11章追加 2011/10/31 ・s1章追加 ・s2章追加 2011/

    bull2
    bull2 2009/08/24
  • 2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ

    不況の嵐が吹き荒れていますが、SI業界の中の人はどうお感じでしょうか。たぶん、仕事が減ってきている気はするけど、製造業ほどひどくないと思っているのではないでしょうか。 ただこれは、不況の波が押し寄せてくるのが、遅いだけです。 SI業界では、プロジェクトが一年くらいかかることも多いので、まだ不況じゃないときに受注した案件分でそれなりにっていけるのです。しかし、SI業界の主なお客様である製造・金融業界は、案件を凍結したりなど、新規の受注案件はかなり減ってきているので、今やってる仕事が一息ついたら、やることがなくなってくるでしょう。 仕事が減ってまずすることは、人減らしですね。元請なら、下請けをきることが最初に検討されるでしょう。ある程度はこれで調整できますが、直ぐに限界が来ます。今の元請は、下請けに任せていたようないわゆる下流工程を自分たちでは行えないので、単純に下請けをきるだけではすまない

    2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ
  • はてなブログ | 無料ブログを作成しよう

    来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

    はてなブログ | 無料ブログを作成しよう
  • ソフト開発の常識が変わる!「何百人が一斉にテスト、バグがなければタダ」という凄いサービス - japan.internet.com Webテクノロジー

    bull2
    bull2 2009/06/16
  • プログラミングだけできればいい、なんてことは無いさ。 - GoTheDistance

    なんで管理について書きたいのか 動機です。 単純に「プログラミングだけできればいい」「SIする人は要件定義だけやれ」という声を聞くと切ないからです。 ただし、わたしは個人的に、開発というお仕事においてプログラミング技術が何を差し置いても最重要だと思っていますから、その軸は絶対にぶれない、ということを念押ししてから始めたいと思います。 ひとりにはなりきれない空を見あげる これも昔思ったことなので、取りとめも無く書いておきたいと思います。 技術リテラシーが死んでいる人間が立ち上げた or 回しているプロジェクトは高い確率で砂上の楼閣のように崩れ落ちていく。だからプログラミング技術に代表される技術リテラシーは必要不可欠。だけど、全員が全員その道を突っ走ると今度はビジネスにならない。取ってきたシーズをプロジェクト化できない。僕は後者が出来ない自分でありたくないという思いから、スーツ的な何かを2年ぐ

    プログラミングだけできればいい、なんてことは無いさ。 - GoTheDistance
    bull2
    bull2 2009/06/15