タグ

ブックマーク / www.arclamp.jp (18)

  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

  • ITにおける品質と効率とは (arclamp.jp アークランプ)

    先ほどのエントリを最後にしようと思っていたのですが、トヨタ信奉への違和感へのnakagomeさんからのコメントが秀逸だったので。 自動車産業の製造というのは、金型作った後にやることで、何千、何万という製品を、殆ど機械的に複製することを指す。これは、ソフトウェア産業でいえば、コンパイルやビルド、または媒体コピーなどに相当するものだ。 しかし、ソフトウェア産業で製造と呼ばれるのは一般に、原始コードを書いたりすることなどを指している。自動車産業でいえば、むしろ金型を作るまでの部分に似ている。デザインの延長であって、知的で創作的で、かつ技芸的な要素の色濃い作業なのだ。 これを行灯で何とかしようとすることをナンセンス以外になんと形容できようか。 この問いかけは真剣に考えるべきことです。確かに製造業における品質向上や効率化は確実に先を行っていますし、積み重ねられてきた実績も大きい。でも、それがITにお

  • Webアプリケーション開発の今後- Rails + Spring (arclamp.jp アークランプ)

    11/6日Javaユーザーグループによる「クロス・コミュニティ・カンファレンス 2007 falll」に参加してきました。Seasarひがさん、Rails高井さんとともに 「Webアプリケーション開発の今後を占う」という題名でポジショントークとパネルを行いました。よういちろうさんがuStreamで録画してくれたので見てください。ちょっと、音声がぶつぶつですが、だいたい聞き取れると思います。ポジショントークの資料はこちら。 RailsでSpring ポジショントークで紹介したのがRailsとSpringを統合してみた、というやつです。コードはここに。 まずJavaアプリケーションですがjava\src\java\mainに入っています。クラスBusinessLogicImplは、メッセージを返却するだけのメソッドshowMessageが実装されています。 package jp.java

  • レバレッジの効く仕事をする (arclamp.jp アークランプ)

    エジケンのニッポンIT業界絶望論につられてみる。 さて、その前に「[みんなの回答]IT業界進化論: 絶望する前に”SIer 2.0”を目指せ」(cnet、いつの間にやらトラバがすごいしにくくなってる)。 クライアントとSIerは戦略的なパートナーシップを結ぶ段階にきています。 実際にそのようなアクションを起こしているSIerは、受託開発を切り口として、そこからクライアントの問題点を分析し、追加提案を行っており、時としてイノベーションを起こすこともあります。 SIerがクライアントにとって企業戦略を支えるITを提案できる戦略的パートナーとなるために必要な相手と既に関係を持っているのですから、SIerコンサル会社に手を伸ばしているのもお分かりでしょう。 確かにそうですが、これはSIer1.0を突き詰めるだけ。コンサルを取り込む動きは受託開発をうまくやりたいから、ということです(コンサルがSI

  • 運用の仕事はボタンを押すことではない (arclamp.jp アークランプ)

    「レバレッジの効く仕事をする」にkanaiさんからコメントをいただきました。 リンク先にあるようなシステム運用って観点はどうなんでしょうか http://japan.cnet.com/blog/0040/today/2007/11/13/entry_25001556/ コメントの意図を計りかねるのですが「一般的なシステム運用という観点においてレバレッジの効く仕事とはなにか」ということなんですかね? ところで僕はユーザー系のシステム会社にいたので、開発したシステムを運用部隊に運用してもらうという経験があります。運用部隊のためにドキュメントを作り、アプリの改修があるとリリースプロセスに従って番移行してもらっていました。テストをどうやるかとか、運用をどうやってもらうかとか、いろいろと開発するだけではない苦労があったものです。 ですが、今となっては違うんだなと感じています。「サービスとして提供す

  • Zeroとマルチコアと日本の現状 (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨日はwakhokナイトセミナーにてProject Zero 第2回「GroovyとProjectZero」を話しました。資料はこちら。 Zeroとマルチコア さて、その後の懇親会では色々と話をさせていただきました。面白かったのはマルチコアとアプリケーションアーキテクチャの話。将来的にZeroが実行されることになるJavaVMは次期IBM J9の派生版になるそうです。で、このVMではZeroの実行はスレッドではなくて、すべてプロセスで起動することになると。こうした処理はマルチコアのサーバを想定します。各プロセスはコアに割り当てられるのです。簡単にいえば、ぽこぽこVMが起動して、それらが処理を行います。 前日、マルチコアなサーバでSUNのJavaVMをいじっている時、

    bull2
    bull2 2007/10/15
    アジャイルで作ったモノの保守って難しいよね「アジャイルはコミットを避けているのではなく、短期的なコミットをエンジニアに求め、長期的なコミットは顧客がするという分担な気がします」
  • プロセスこそアーキテクトのもの (arclamp.jp アークランプ)

    ちょいとした事情で品質まわりの情報を調べていたのですがISO 9126-1(JIS X 0129-1)というのに初めて目を通しました(不勉強ですみません)。物は、JISの検索ページで、「x0129」と入力するとでてきます。 で、品質とは何かというページがうまくエッセンスを抽出しています。まず品質をモデル化すると次のようにすることができます。 ※上記ページからの直リンク 右側の「利用時の品質特性」というのは特定の状況における利用者が感じる品質です。だから、状況や利用者が違えば変わってきてしまうもの。で、一般的な指標は「外部品質」と「内部品質」で、それぞれソフトウェアの動きと中身の構造のこと。 そして注目すべきは一番左側のプロセス品質でしょう。プロセスとは設計/開発のやり方や手順。さてJISのドキュメントから少し引用してみましょう。 プロセス品質(JISX0160に規定されているすべてのライ

  • 人月を超えるということ

    人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか=レバレッジを効かす 使いまわすというのはレバレッジ(てこ)を効

    bull2
    bull2 2007/08/20
    マジカいいよね。残念ながら私が関わっている仕事には使えないけど。
  • Struts化するRails (arclamp.jp アークランプ)

    良い悪いは置いておくとしてRubyOnRailsはStrutsになるのだなと感じています(エンタープライズ開発でデファクト・スタンダードになって一定のポジションを獲得する)。先日のRubyKaigiでの話し、あるいは最近のエンタープライジーな企業のプレスリリースを見ていると着実にその道を歩んでいるようにみえます。特にSUNがJRubyへのコミットメントを強めている中でJava環境でもRailsが使えるという期待感が強まっており、この傾向に拍車をかけているようです(既にJRubyの上で動きます)。 背景としては金融・内部統制景気が続く一方で、中大規模のSIerでも小粒案件(1-4千万円)をちゃんと利益出してやっていこうよ、みたいな流れがある気がします。これまではプロダクトなどでカバーしていましたがOSSの発展や顧客ニーズの多様化によってSI案件化せざるをえなくなってきた。でも社内の標準フレー

    bull2
    bull2 2007/08/01
    最近のRoRは一体どうなったのかな?1年くらい前の情報は知ってるけど、変化が早すぎてついていけん。
  • 自分がやるという覚悟 (arclamp.jp アークランプ)

    フューチャリスト宣言や茂木さんのことやはてなのことなどを酔っ払いながら書いてみるから、 僕は茂木さんと違って、自分の才能をぜんぜん認めていないし、万能感などはとうに高校生くらいのときの挫折ですべて失われていて、そのあとは「戦略性」を拠り所に何とかゴチャゴチャやりながら、今日に至っている。 あぁ、そうなんだよなぁ。僕の周りにもびっくりするほど軽やかに進む人がいて、そんな人を見るたびに自分の才能のなさをくやんでみたりする。実際に会ってみてもオーラがあって、まずアタマノヨサっていうのが違うし。ちなみに梅田さんも慶應、東大という学歴。そんな人でも茂木さんを見て 一言でいえば、彼には当に自信があるのだ。何でもできるという自信が。僕にはそれがない。だから戦略を練る。羨ましいなともべつに思わない。人は与えられた条件でつべこべ言わずにやっていくしかないから。 という。 僕はどうかな。たぶん中途半端な頭だ

  • DBマガジン(6/23)「Ajaxによる最新型DBアプリ開発」を寄稿 (arclamp.jp アークランプ)

    2007年6月23日発売のDB Magazine (マガジン) 2007年 08月号にて、特集1「Ajaxによる最新型DBアプリ開発」のうち、PART1「従来のWeb-DBアプリとはここが違う Ajaxの効用と基アーキテクチャ」とPART4「JavaScriptレスな開発技法とAjaxによる認証処理の実装」を寄稿しました。 Ajaxを硬派に扱うというのがコンセプト(w。Ajaxというのはインタラクションモデルであり、それを支えるためにどのようなアーキテクチャが必要なのか。UIの派手な演出は一切なしで、ひたすらアーキテクチャとしてのAjaxにこだわっています。FasterFoxを使ってAjaxリクエストが10並列でサーバにアクセスしているのを、FireBugで見るのが楽しめそうな人におススメ。 Ajaxというのは非同期処理を取り扱っているので、サーバ側の並列処理も、通信結果をハンドリングし

    bull2
    bull2 2007/07/31
    まだ買えるかな?
  • フリーランスってね。 (arclamp.jp アークランプ)

    Groovin' Highの「アンチ・フリーランスエンジニアという反発心」というエントリがすばらしい。 この状況って、結局エンジニアの現状。限界だと思う。能力がある程度高まったんで、サラリーマンやってるより個人契約というか、個人事業主になったり、自由に遊ばせてくれる会社に転職するとかね。なんか小さいなぁ。エンジニアだからビジネス・センスないって、どうなの?それでいいのか?自分の能力を限界まで尽くしたら、もっとやり方違うと思うけど。そりゃみんな起業できるわけじゃないかもしれないけどね。 もうグサグサ来ますね(w。 僕も自分自身が小さいなぁと反省しています。まさに自由にさせてくれる組織に居候して仕事をさせてもらっている立場。ただ僕の場合に恵まれているのは外部に対してフリーランスであるという立場を明示しながら、内部にはチームでアプローチする形が許されていることです。都合よくワラジを履き替えなが

  • Processing (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ Processingというツールをご存知でしょうか。 公式サイト 日のサイト  MITで開発されたオープンソースのグラフィックツールです。 Processing is an open source programming language and environment for people who want to program images, animation, and interactions. そうなんです。面白いのはスクリプトで記述すること。ドラッグ&ドロップもありません。ひたすらスクリプト。しかもJavaで作られていているので構文がJavaっぽくて書きやすい(例外もJavaで吐かれるので僕にとっては分かりやすいw)。 で、ずいぶん前のエントリ「複雑系

  • 抽象化がもたらすリアル (arclamp.jp アークランプ)

    Inter Communication (インターコミュニケーション) 2007年 04月号 の特集は、「デザイン/アート 芸術と科学のインターフェイス」というもの。いくつか面白い記事があったのですが、抽象化がもたらすリアルみたいなことで思うことがありました。 まず、巻頭の茂木さんと山中さんの対談はそうだよねぇーの連続。山中さんはSuica自動改札機やCyclopsをデザインしたことで有名な方。 ところでヒューマノイド・ロボットを作るうえで、人間に似せていくほど不気味になってくるという「不気味の谷(Wikipedia)」という現象があります。山中さんは、これを「サイエンティストの傲慢」と切った上で次のように述べています。 彫刻を作るとき、睫毛を植えたり、髪の毛を生やしたりは普通しないですよね。なぜならば、そんなことをしないほうが美しく、よりリアルであることをアーティストたちは気がついてい

    bull2
    bull2 2007/05/17
    観察によって「ユーザーの言っていることではなく、やっていることを信じろ」というのはいまや常識となっている。
  • 私的ITアーキテクト考:3.ITアーキテクトの仕事 (arclamp.jp アークランプ)

    先日、デブサミの「ITアーキテクト大解剖」でご一緒させていただくマイクロソフトの萩原さん、建築家の大川さんとミーティング。いろいろと話をしてきました。デブサミでは、ここで書かれていることを中心に話題を広げていきたいと思います。 技術や知識は最低限のこと まず全員が一致したのは「工学的な知識や技術を知っているというのは最低限のこと」である点。同じような知識としては、先人の知恵という意味でパターンや実績・実例をあげることもできます。 建築業界で技術の親分というのは構造エンジニアや現場の大工で、アーキテクトとは明確に分離されています。もちろんアーキテクトが設計図を描くために知識は必要になるので、知っている範囲であればその中で、新しい技術を試すのであれば設計段階からエンジニアに入ってもらうそうです。 一方のIT業界で、アーキテクトとエンジニアに分離は見えていません。これはIT歴史が浅いからでし

  • ずっと足らない経済と自分で作る経済 (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 梅田さんのエントリ経由で知った、「The Economics of Abundance」という概念。 ロングテールの提唱者、クリス・アンダーソンが新しく言い出したことで、大筋としてはチープ革命から起きている現在の流れを示しているもの。いままでが"Scarcity Economics"で、これからが"Abundance Economics"。参照は、以下。 梅田さんのエントリ 原文 日語:日語でわかるロングテール著者の新理論 で、超訳なのですが、Scarcityっていうと意味としては「足りない」って感じなのですが、うん、資料とかをみると皮肉をこめて「ずっと足らない経済」みたいな感じかなと。で、Abundanceは超訳して「自分で作る経済」。 ずっと足らない経済

    bull2
    bull2 2006/10/30
    ロングテールの提唱者、クリス・アンダーソンが新しく言い出したことで、大筋としてはチープ革命から起きている現在の流れを示しているもの
  • ロボットから考える、身体性としての構造が持つ意味 (arclamp.jp アークランプ)

    なにげなく季刊d/SIGN(デザイン) no.13の表紙を見たら「特集 ロボットのデザイン」の文字。おおっと思って著者人を見ると「國吉康夫+佐々木正人」ときたもんだ。ロボットの身体性でも語っているのかと思ったら、ある意味裏切られたような、でもすばらしい内容でした。 國吉康夫さんはロボットを開発しているわけですが、ロボットを作ること自体が最終目的というわけではなく、ロボットを作ることで人間の理解を進めることを目的にされています。早速ですが、國吉さんの研究室サイトにある「スクワット起き上りロボット」の動画を見てください(ページへの直接リンク)。 (画像はWebサイトより直接リンクで引用) このロボットは寝た状態から足を上げて、それを振り下げる勢いで膝を曲げたスクワット状態で起き上がりをします。動画をみてもらうと、すごく人間くさい。起き上がった瞬間にはゆらゆら身体を揺らして踏ん張っているのがわか

  • 知の編集工学 (2) (arclamp.jp アークランプ)

    引き継き松岡正剛さんの「知の編集工学」より。前回はこちら。正剛さんは、これからのITシステムについても面白い意見を述べています。 これまで情報技術をつかったシステムには、もっぱら「強さ」ばかりが求められてきた。大型で大容量で、高速で、広域であること、これらが情報ネットワーク技術に求められていた常識であり、「強さ」というものだった。 けれども、湾岸戦争や阪神大震災は、はからずも私たちに「柔らかさ」と「弱さ」が重要であることを示唆してくれた。もしそうであるなら、いまや<情報化>と<編集化>を一体化する経済文化のための技術は、むしろ「弱さ」をベースに設計されるべきではないだろうか。リニアで強い交換のモデルではなく、すこしばかりノンリニアで、広がりをもった弱い交換モデルも必要ではないだろうか。 かくて私は、編集技術の思想を「強さ」による提示やシステム化に依存するのではなく、むしろ「弱さ」によって表

    bull2
    bull2 2006/10/12
    構造そのものに動的な要素が求めれます
  • 1