<< 2007/12/ 1 2 1. [教会] 子供を理解することの力 3 1. マシン不調 2. ConsistentHashing - コンシステント・ハッシュ法 3. The Chord/DHash Project - Overview 4. [Ruby] 市報松江12月号 5. [Ruby] 山陰中央新報 - 島根県の産業活性化戦略 住みたくなる環境も必要 6. 梅田望夫×まつもとゆきひろ対談「ウェブ時代をひらく新しい仕事，新しい生き方」(前編)：ITpro 4 1. 新ディスク 2. 梅田望夫×まつもとゆきひろ対談「ウェブ時代をひらく新しい仕事，新しい生き方」(後編)：ITpro 3. [言語] YouTube - Upcoming Changes to the JavaScript Language 5 1. [Ruby] 新潟 - Rubyビジネスセミナー 6 1. 取材 2
developmentに関するokuharakensukeのブックマーク (13)
-
okuharakensuke 2007/12/18
-
ユメのチカラ: プログラマの仕事はプログラムを読むことである
ソフトウェア開発コストのほとんどは保守のコストだと言われている。各種統計がそれを示しているわけだけど、自分の実感とも合う。 古典的なウォータフォールモデルでは保守というのが意識されないか、あっても一番下流なので、その重要性に対する認識が非常に薄い。 保守という言葉は若干大げさな響きを持つが、プログラムの不具合の修正や、ちょっとした機能変更、機能追加などなど、運用していけば、つまりそのソフトウェアが利用されていれば必ず必要なものである。保守されていないソフトウェアは早晩利用されなくなるか、既に利用されていないかである。 Unixの哲学を持ち出すまでもなく、優れたプログラマはプログラムを書くのではなく、再利用する。いかにしてプログラムを書く機会を減らすか虎視眈々としている。可能な限り再利用して、どうしても書かざるを得ない場合はリサイクルをしちゃったりする。（プログラマにとってのReduce/R
-
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
-
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
-
C言語ラブ - なつたん
shinhさんの所からいろいろ回る。 http://blog.livedoor.jp/dankogai/archives/50910559.html のコメントから > shi3zさんはverilogやVHDLを出さずに「論理回路」なんて表現を使っている点からして知識が浅い。 > それで大言壮語してるんだから、反論されてもしかたない。 HDL厨キターー。もっと煽れ。2chにマシン語厨とHDL厨が煽り合うスレが立つまで煽れ。スレが立ったら僕はそのスレで毎日煽り、煽られするよ。 もとはここか。こことは違うらしい。 マシン語を知らない子ども達 > 最低でも、論理回路だけで桁上がりをサポートした加算機を作れる程度の理解はしておいて欲しいと思います。 これは、マシン語とかそういうレベルでなくても簡単に理解できるし、それで理解できれば十分じゃないかと。 sum = a ^ b ^ cin; cout
-
fladdict.net blog: 「本当に素晴らしいデザイン」とは、PICASAの変なスクロールバーみたいなものを言う
お気に入り巡回先の、羨望は無知の「なぜ「デザイン」という行為、「デザイナー」という職業は誤解されるのか」や、分裂勘違い君劇場の「エンジニアの方が優れたユーザインタフェースデザインができる理由」、F's Garageの「エンジニアがダメなUIデザインをする原因」 のあたりのデザイン論が、あんまりデザインと縁のない人にデザインをわかりやすく説明してて面白い。面白いのだけどちょっと抽象的なんで、具体例の話とか書いてみるテスト。 最近、これらのエントリーで言及されるようなよいデザインを身をもって体験をした。それは画像管理ソフトPICASAのヘンテコなスクロールバー。 今まで気付かなかったけど、あのヘンなスクロールバーは単なるアヴァンギャルドやオシャレじゃあなかった。実は合理性に裏打ちされた素晴らしく美しいデザインだということに気付いた。 まずPICASAを知らない人に説明すると、このソフトのスクロ
-
-
「SI業界の悪習，人月と訣別する」---スターロジックが1タスク8万円の“明朗会計”システム構築を開始
「1タスクあたり8万円の明瞭な価格体系でシステムを構築する。そして要件はユーザーが決める」（スターロジック 代表取締役兼CEO羽生章洋氏）---システムインテグレータのスターロジックは7月19日に開催した同社初の単独イベント「Starlogic Conference 2007」で新しいSIメニューを発表した。同社が考案した要件定義ツール「マジカ！」やアプリケーション自動生成ツールを組み合わせることで，定額かつ低額のシステム構築を実現するという。「人月はSI業界の問題の根源。もう二度と人月商売はしない」（羽生氏）。 エンドユーザーが自分で要件を書けるようにするツール 「マジカ！」は同社が考案し公開している，エンドユーザーが業務プロセスを自分で書き出せるカード型のツールである（関連記事「仕事の流れをマンガ風にまとめよう」，スターロジックが業務分析ツールの新版「マジカ！」をお披露目）。人物が仕事
-
複数でサービスを作るコツ | ランサーズ社長日記
いいね！ 2 ツイート B! はてブ 88 Pocket 4 「個人サービスを作るコツ」というエントリーを書いたが、最近、個人ではなく、友人と2人でQuemlというモバイル検索メールサービスを始めた。 基本的には「個人サービスを作るコツ」とノウハウは共有できるが、複数でサービス企画して作っていく作業独特のコツもあると思う。と、いうことで、今回は「複数」にスポットをあてて、個人ではなく複数でサービスを作り個人以上の成果を得るためのコツを書き出してみた。 複数でサービスをつくるコツ １．決起集会を開く ２．ドメインを取る ３．サービスに名前をつける ４．リリース日を決める ５．常に連絡を取れる手段を用意する ６．予定を共有する ７．誰にも依存しない開発環境を用意する ８．良いものは良いという ９．タスクを明確化する 解説 １．決起集会を開く 「こういうサービスあったらいいよね。」というのは飲み
-
大迫正治 REPEDANT BLOG > 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む : ITmedia オルタナティブ・ブログ
日本のソフトウェア産業は「製造業」よりも「サービス業」に分類される。なぜなら、革新的なプロダクトを研究開発し、一気呵成に市場に展開するよりも、顧客ニーズに沿ったオーダーメイドのシステムを逐次的に開発することが主流となっているからだ。 創業期は受託開発で糊口をしのぎ、徐々に自社製品の研究開発に資金を回して、いつかは自社ブランドで世界を席巻する、というストーリーは巷にあふれるが、これは結局のところローリスクでスタートしながらハイリターンを得ようとする野望であり、実現へのハードルは低くない。その理由は、中毒性のある受託開発と、ソフトウェア産業の悲惨この上ない「重層下請け構造」にある。 １．受託開発では「技術」が蓄積しない 住信インベストメントの辻俊彦氏はご自身のブログで次のように述べている。「クオリティの高い受託開発力は、オリジナリティ溢れる尖った自社開発力を生み出す素地になると思っている。投資
-
-
実録! Webサービスの作り方
今、個人でWebサービスを作る趣味が大流行していますが、Webサービスをイチから作ろうとしても、ノウハウや事例は意外にまとまっていません。そこで今回より、koress projectが先日リリースしたWebサービス「Cha-Cha-le!」の構想からリリース・運用までを含めたリアルな事例を連載します。これから個人でWebサービスを作ろうとしている学生や技術系サラリーマン、企業戦略として超低コスト・超高スピードのサービス開発を研究したい人など、Webサービスの裏側に興味がある人の参考になるように、なるべく詳しく書きたいと思います。 第一回は、Cha-Cha-le!の構想から設計までの事例についてまとめました。 1. はじめに この連載は、koress projectがWebサービス「Cha-Cha-le!(チャチャーレ!)」をリリースするまでを、時間を追って記述したものです。技術的な内容だけ
-
個人サービスを作るコツ | ランサーズ社長日記
いいね！ 5 ツイート B! はてブ 477 Pocket 96 今、個人発サービスがアツイ。字幕inやSocialTune、コトノハなど人気サービスの一部には個人サービスが多い。その背景には、安い高性能マシン、何でも無料の開発環境、ウェブ上にある各種ノウハウ情報などがある。 個人的には、このような環境であれば、もっともっと個人発サービスが出てきてもよいと感じるのだが、それほどまで爆発的に増えているようには思えない。やはりそこには、誰でもできる超参入障壁の低い個人サービス、自由が多くなんでもできる個人サービスだからこその「自由の中の不自由」みたいなものがある。実際に作る時間を作るのは難しいし、開発をいつでもやめる自由もある。責任もない。飽きる。と現実にサービスを出すとなると大変なのである。 長々とひっぱったが、そんな個人サービスを作るコツを今までの経験から書き出してみた。 個人サービスをつ
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました