タグ

ブックマーク / www.geekpage.jp (12)

  • 強者のWeb、弱者のWeb:Geekなぺーじ

    畑違いではありますが、たまに、Webデザイナー系の雑誌を読む事があります。 それを読んでいると、つくづく自分のWeb制作方法というのは「弱者のWeb」なんだなぁと思い知らされます。 Webデザイン系の雑誌に掲載されている、最新サイトWeb例の多くは非常にお金や時間をかけて作っているようなイメージのものが多いです。 例えば、大手企業の宣伝用企画で、何人もの人がコンセプト/ターゲットなどを練って、全体的なイメージを作って、サンプルを作って、プロカメラマン同行でモデルを使ったり海外ロケを行ったり、Flashで細かい作りこみや面白い試みを行ったり、大規模なイベントと連動させたり、というような記事が雑誌に掲載されています。 雑誌に掲載されているようなトップレベルなサイトは、TVのCM並に気合が入っているような感じがします。 それらの由緒正しい強者のサイト制作と比べると、個人ブログというのは個人ブログ

  • 生々しい製品紹介を読みたい:Geekなぺーじ

    様々な製品やサービスの開発社インタビューが雑誌やネットに載っていることがあります。 ですが、インタビューに答えているのは大抵偉い人かマーケッティング担当者か企画担当者です。 そして、インタビュー内容は製品に関する性能や、狙ったマーケット、聞こえの良い表向きの苦労ポイントなどです。 それらを読んでいると、何か物足りません。 もっと生々しい、執念のこもったような、そんなインタビュー記事を読んでみたいと思ってしまいます。 現場には無数の無名エンジニアがいるはずです。 使う人が誰も気に留めないような、ちょっとした機能を作った人の苦労を聞いてみたいような気がします。 外注先がコケて現場が騒然となった話を読んでみたいと思います。 締め切りに間に合わない状況になって土日も関係なく、ひたすら苦労した現場の修羅場具合を知りたいと思います。 例えば、オンラインサービスであれば、一つの画面が出来上がるまでの社内

  • [未来予想] Google恋人Search:Geekなぺーじ

    Google社の理念」というページに以下のような一文があります。 Google の共同創設者ラリー ペイジは言います。「完璧な検索エンジンとは、ユーザーの意図を正確に把握し、ユーザーのニーズにぴったり一致するものを返すものだ」。 また、ウェブ進化論ではグーグル社は「増殖する地球上の膨大な情報をすべて整理し尽くす」ことを目的としていると書いてあります。 Google社は、検索エンジンだけではなく様々なサービスを手がけています。 しかし、人類にとって最も需要が高いと思われるある分野はまだ手がけていません。 その分野とは恋人探しです。 現在、ネット上で恋人探しというとmixiか出会い系サイトなのではなかいと思われます。 (その分野は非常に疎いです。ごめんなさい。) mixi内ではそのような目的で活動して欲しくないと思っているユーザも多いと思われますし、出会い系サイトは多くの人にとって敷居が高す

  • Geekなぺーじ:技術の盗み方

    新入生や新社会人として組織に入ったり、他の組織から畑違いの場所に異動すると、ゼロからのスタートになるときがあります。 そのときに、先輩からいかにして技術を「盗む」かが重要な要素になると思われます。 ここでは、自分の養分として吸収するために、先輩から技術を引き出す一手法を紹介したいと思います。 先輩から見て教え易い後輩や、ついつい必要以上に色々教えてしまう後輩などがいます。 今回は、そのような人の特徴を考えたり、過去の私が失敗したと思われる点を思い出しながら書いてみました。 ここで紹介する方法は、あくまで方法の一つであり偏っています。 性格によって向き不向きがあると思います。 また、あまりに露骨にやり過ぎると嫌われてしまう場合もあるのでご注意下さい。 あまり参考にはならないかも知れませんが、まあ、許してください。 やる気を見せる 非常にやる気があって、色々やっている人を見るとついつい応援した

  • 中小企業にプログラマはいらない:Geekなぺーじ

    「Small ISVs: You need Developers, not Programmers」という記事がありました。 2003年5月の記事のようです。 半分根性論な気もしましたが、この記事の視点は非常に面白かったです。 そうなのかもと思う面もありました。 この記事を書いている人は25人の社員がいるソフトウェアベンダを運営しているそうです。 6年間会社を続けてわかったこととしては「小規模な企業にプログラマは居てはならない」だそうです。 必要なのは「プログラマ」ではなく「開発者」だそうです。 以下が駄目な「プログラマ」の特徴だそうです。 小規模企業では以下のような人は「いらない」そうです。 新しい機能を実装することばかりする たまにバグを修正する 仕様書を書かない ドキュメンテーションを書く手伝いをしない 自動化されたテストを作成しない テスト実行を手助けしない 開発環境を最新に保たな

  • GUIほど難しいものは無い:Geekなぺーじ

    突然ですが、個人的にはGUIほど難しいものは無いと思っています。 そのため、何か作る時にはCLI(Command Line Interface, もしくは CUI)とかライブラリになりがちです。 丁寧にするにしても、manファイルを書いたり、headerにdoxygen書いたり、perldocを書く程度で済むというのが良いです。 GUIを作る時に一番難しいのが、使い勝手を良くすることです。 いつも作っていて最悪なのが、自分が使いやすいものは大抵は他人にとって使いにくいものになってしまうことです。 作っている人の前提(私の場合)は、コードの中身になりがちです。 コードを書いていると「この関数に入れられるこのパラメータもどこかから入れたいなぁ」などの煩悩が湧いてきてしまい、結果としてパラメータが無限に多い煩雑なUIになってしまいます。 さらに、コード内部の意味論をGUIの構成に持って来がちにな

  • ペアプログラミングに必要な知恵は全て幼稚園の砂場で学んだ:Geekなぺーじ

    「"All I really need to know about pair programming I learned in kindergarten", Communications of the ACM, Volume 43, Issue 5 (May 2000) Pages: 108 - 114」という論文を読みました。 幼稚園(もしくは保育園)で習うような社会生活の基礎から、ペアプログラミングを遂行するときに注意すべき点を論じています。 ペアプログラミングは、二人で一緒にプログラムを書くという手法です。 XP(eXtreme Programming)などで利用されています。 面白かったので一部を抜き出して要約してみました。 さらに興味のある方は論文をご覧下さい。 何でも分け合うこと ペアプログラミングでは一つのものを二人が作り上げます。 片方がプログラムを書き、相方がレビューを続

  • Geekなぺーじ : Second Lifeをやってみて思ったこと

    最近、何かと話題のSecond Lifeをやってみました。 最終的な感想としては「超ワクワク、色々やってみたい!」だったのですが、その感想になる人は少ないと思いました。 私は、「Second Lifeの仮想空間での生活はどうでもいいけど、LSLスクリプトで遊びたい。」という感じなので、少数派だと思います。 で、一般的な感想としては岡田有花記者が書かれていたことが非常に適切であると思いました。 個人的な感想としては一般の人は以下のような感じになるかも知れないと思いました。 とにかく難しい。 慣れる前にやめてしまいたくなる。 普通の人は、がんばって慣れようと思うようなインセンティブが見つけにくそう。 という感じですかね。 まず、私は最初の初心者用 Help Islandをクリアできませんでした。 途中で、「イベントがどこで発生するんだよ!ムキー!」となってしまって main landに飛んでし

  • インターネットの次:Geekなぺーじ

    「A New Way to look at Networking (Google Video)」を見ました。 Van Jacobson氏による1時間21分のプレゼン映像でした。 ビデオでは、コペルニクス的発想が必要だとか、昔は電話システムを前提に皆が議論をしていたからインターネットの仕組みはあり得ないと当初は皆が言っていた、という内容の事を何度か言っています。 確かに、私も聞いていて「WinnyかBitTorrentをDRMと組み合わせたもの?」という感じの方法論を考えてしまいました。 恐らく、今の仕組みで作ってしまう方法を考えるのではなく、アーキテクチャとしてこの案を考えなくてはならないという物だと思いました。 きっと、ここで言っている話が実現するとIPの上でも動くけど、下にその他の通信形態が来ても動くという新たなアドレッシング手法に近いものを提案しているのだと思いました。 どうしても現

  • Geekなぺーじ:UNIX哲学の基本原則

    「Basics of the Unix Philosophy」でUNIX哲学の基原則がまとめられています。 UNIXの設計思想として紹介されていますが、多くは普通のソフトウェアを設計する場合にもあてはまると思われます。 1. Rule of Modularity(モジュール性): きれいなインターフェースで接続された、簡潔な部品を書きましょう。 2. Rule of Clarity(明瞭さ): 明瞭さは賢さよりも良いです。 3. Rule of Composition(構成): 他のプログラムと接続できるようにプログラムを設計しましょう。 4. Rule of Separation(分離): ポリシーとメカニズムを分離しましょう。エンジンとインターフェースを分離しましょう。 5. Rule of Simplicity(単純性): 単純化された設計をしましょう。複雑さは必要な時だけ追加しま

  • 無断リンクを法的に制限する方法?(2):Geekなぺーじ

    以前「無断リンクを法的に制限する方法?」という記事を書きましたが、今回は違った手法で無断リンクを法的に制限 出来るかも知れない方法を思いつきました。 (前回に続き半分ネタみたいな方法ですが、、、) 念のため書いておきますが、このエントリは「無断リンク禁止」について良いか悪いかの議論ではありません。 タダ単に特定のケースにおいて無断リンクを法的に制限できるのか?と思いついたので書いています。 私自身は無断リンクを禁止するつもりは毛頭ございません。念のため。 世の中には秘密保持契約(NDA)というものがあります。 これは相手に秘密の保持を約束させるものです。 今回、無断リンクを法的に制限する方法として、この秘密保持契約を利用できないだろうかと考えました。 まず、無断リンクを禁止したいサイトは、全てのページを全ての検索エンジンcacheから削除します。 サイト立ち上げ時に検索エンジンがクロールし

  • こんなあなたは。。。(ry:Geekなぺーじ

    TOP > ブログ > こんなあなたは。。。(ry こんなあなたは。。。(ry 2006/12/7 1. この項目が1ではなく0から始まるべきだと主張する 2. ++が1を足すことだとわかる 3. 人を/dev/nullに叩き込みたくなることがある 4. 25歳なのに0x19歳だといいはる 5. 30歳ではなく32歳が区切りだと思っている 6. 飲み会でcore dumpと言って意味が通じる 7. 話題が変わる事をコンテキストスイッチと言う 8. 起床の事をbootと言う 9. 「ラクダ」と言われて動物のではないと思う 10. /* この文が読めない */ 11. <!-- この文も読めない --> 12. # この文も読めない 13. #if 0 この文も読めない #endif 14. // この文も読めない 15. ; この文も読めない 16. % この文も読めない 17. dnl

    hirusagari
    hirusagari 2006/12/07
    コア吹いたw/コメントってのは、プログラマが読むためのものだと思ってた。俺もまだまだだな。
  • 1