そもそもソフトウェア設計って何なの？ - @katzchang.contexts
だよなあと思うけど… - Kowの日記という記事から言及されたので、もうちょっと考えてみた。 それがダメなのかといえば、それでいいと思う。建築家が製図だけしてとび職やらないみたいに、そういうのはうまくやれればうまくいく方法なのだと思う。 設計をどういう粒度でやるかってことにバラつきがあるから、時に意味不明な設計書を渡されることがあるってだけで、それはやっぱり設計書の書き方が標準化されきってないことにまつわる課題かなという気がします。 だよなあと思うけど… - Kowの日記 (引用者が一部編集しています。) システム開発は建築に例えやすい。けど、違う。その違いはどこにあるのかを考えることで、SI業界では何故建築家ととび職のように対応できないのか考えた。建築家ととび職の関係は、SEとPGとの関係にでも、元請と下請との関係にでも、スーツとギークとの関係にでも解釈できると思う。 で、検討するベース
Re:一晩で覚えるjQueryの逆引き基礎サンプル7つ (でぃべろっぱーず・さいど)
一晩で覚えるjQueryの逆引き基礎サンプル7つ*ホームページを作る人のネタ帳 jQueryに書くとほってんとり入りできるらしいので便乗。というかリンク先で紹介されているサンプルコードにちょっと意義異議あり。 一個のサンプルは非常に単純な構造になっておりますゆえ、jQueryをすでにやったことがある人にとって必要ないものだということをあらかじめご了承くださいませ。 ということであれば、「jQueryらしい」書き方をした方が良いかなと思います。 で、僕ならこう書くってことで。 全般的に使われている$(document).ready(fn)は、$(fn)でショートカットできます。 $(document).ready(function(){alert('hoge');}) は、 $(function(){alert('hoge');}) こう書けると。 まあ、これはどうでもいいや。短く書けるって
2008-04-18
ちょっといまいちな部分もあるかもだけど、10分での超訳なので勘弁。 あとは原文も読まないと駄目だわ。文脈がよみとれん。 1.REST posits an interconnected information ecosystem, not an isolated set of point Web services. RESTはWebサービスの相互接続に使うべきものであって、単独のWebサービスに使うものではない。 2.A focus on Design for Consumption instead of Design for Integration. RESTは統合のためのデザインではなく、リソースを消費するため（表現する、かな？）のデザインに注目すべき。 3.REST security is egalitarian and is as secure as the Web itself.
2008-04-18
ちょっといまいちな部分もあるかもだけど、10分での超訳なので勘弁。 あとは原文も読まないと駄目だわ。文脈がよみとれん。 1.REST posits an interconnected information ecosystem, not an isolated set of point Web services. RESTはWebサービスの相互接続に使うべきものであって、単独のWebサービスに使うものではない。 2.A focus on Design for Consumption instead of Design for Integration. RESTは統合のためのデザインではなく、リソースを消費するため（表現する、かな？）のデザインに注目すべき。 3.REST security is egalitarian and is as secure as the Web itself.
Kei-z.biz | [Business]縛り
本当なら伸び伸びとやってもらいたい。 クリエイティビティを大いに発揮してもらいたい。 しかし、うちらはプロなんです。 お客から見たら、「コードを書く」プロではなくて、「システムを作り上げる」プロである。 あなたは、コードを書くPGですか？ それとも、システムを作り上げるPGですか？ コードを書くことだけが、システムを作り上げることか？ お金は誰が出すのか？ これが現場。これがライン。スタッフなら違う。 コードを書くだけなのなら単価は下がる。 本当なら縛りなんてかけたくないんです。 だけど、上記目的を達成するためなら、縛りをかけるという手段を私は選ぶ。 ただし、それは売買が成立する間柄での話。 上記で「これがライン」と書いたのはこれのヒント。 つまりは既存SIビジネスモデルでの話。 一方でこれも何とかしていきたい。
Kei-z.biz | [Business]ゼネコンを知る
ゼネコンをつぶす前に、とりあえず敵の情報を整理していこうかと。 SIという「世界」の中心で愛を叫んでみる。"ビジネス現場"で居て思うこと。 何を隠そう、私もあるプロジェクトの上流からしてますが、PG達がやる前に先行してTeedaのソースをみたりしてアーキテクチャのウラをとったりしています。 しかしながら、物理的にそういうのに時間を割くことがきつくなってきてます。 なぜなら、 ①システムの規模がでかい そういうものなんだから、これは仕方が無い。当然フェーズ分けをしているのだが、システム全体のアーキテクチャを考えるには、一部機能だけを考えるわけにはいかない。なので、最終ゴールのシステムがでかけりゃ、仕方が無い。 ②でかいと人が要る 物理的に独りじゃやりきれない。だからといって、少数精鋭&アジャイルでやる為に期間を長くとりますか？すると、サービスインを伸ばしますか
熱くなれば冷めていくかもしれない - Net Start Technac
プログラマ, 仕事, 会社 直接的なきっかけはid:higayasuoさんの「浜口さんに贈るSI業界を良くする方法」 id:higayasuo:20080414:1208155494「プログラミングできない元請けがプログラム設計書をレビューするという矛盾」 id:higayasuo:20080415:1208224902というエントリを読んだこと。 個人と会社 ちょっと前にid:gothedistanceさんの「プログラマが仕様を決めればいい」id:gothedistance:20080410:1207832176 というエントリを読んで感じたことと同質なこと。 さらにさらにもっと前に、よしおかさんの開発工程を別々に担当してはいけないを読んで思ったこと。 それは技術力をつけよう、という熱い想い。ITのエンジニアとしての技術とはなんぞやという自分なりの答えは持っていないけれど、分裂勘違いさん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
