タグ

2007年6月5日のブックマーク (8件)

  • #12~#50 SEOで検索エンジンから呼び込もう | Web担当者Forum

    検索エンジンの上位表示を狙ってアクセス数アップ!誌の読者ならばSEOに関して相当詳しく理解して実践していることだろう。しかし、改めてSEOの基を理解しておくことも大切だ。 SEOとは「検索エンジン最適化」(Search Engine Optimization)のこと。検索エンジンで検索したときに、検索結果で自分のウェブサイトの表示順位をより上位に押し上げるためのマーケティング上のテクニックだ。検索結果の上位に表示されるものほど、より多くのユーザーの目に留まりクリックされることは明らかなので、SEOのアクセスアップに対する効果は非常に大きい。 SEOの対象とする検索エンジンは、日でよく使われている順に、ヤフー、グーグル、そして余力があればMSN(Liveサーチ)を選ぶのが一般的だ。オプトとクロス・マーケティングが2006年4月に発表した「検索エンジン利用状況実態調査」では、国内検索エン

    #12~#50 SEOで検索エンジンから呼び込もう | Web担当者Forum
    honeybe
    honeybe 2007/06/05
  • 勉強会のススメ 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    勉強会のススメ 記事一覧 | gihyo.jp
    honeybe
    honeybe 2007/06/05
  • [動画]Ruby設計者まつもとゆきひろといろいろ語りたい - @IT情報マネジメント

    プログラム言語Rubyアジャイルソフトウェア開発の連携が生み出す新たな可能性を縦横無尽に語り合う。全6回シリーズの第1回。まつもとゆきひろ(ネットワーク応用通信研究所)がRubyの来歴を語り、平鍋健児(チェンジビジョン)がアジャイル開発とRubyの接点を模索する。角谷信太郎(永和システムマネジメント)が両者の橋渡しをする。 なぜ、「まつもとゆきひろ」か? 「RailsによるアジャイルWebアプリケーション開発」は一風変わった書籍である。RubyによるWebアプリケーションフレームワーク、Ruby on Rails解説の決定版である書は、書名に「アジャイル」を冠しながらも、文では具体的なアジャイルソフトウェア開発手法への言及がほとんどない。その理由は「アジリティ(agileであること)はRailsの構造の一部」であり「フレームワーク自体にアジャイル宣言の原則を語らせるように」執筆したと

    [動画]Ruby設計者まつもとゆきひろといろいろ語りたい - @IT情報マネジメント
    honeybe
    honeybe 2007/06/05
  • Concepts Principles - プログラミングの原則 - Concepts Principles - Top

    ここはプログラミングの原則を集める Wiki です。巨人の肩に乗って、ふつうの人がよいプログラムを書くための指針を集めたいなと思ってます。 目次 よいデザインのための Concepts + Principles DRY (Don'tRepeatYourself) 名前重要 直交性 トラッシュではなくクラッシュ DuckTyping よいルーチンを書く 凝集性 結合性 契約による設計 (DesignByContract) ルーチンを作る正当な理由 よいモジュールを書く 適切なモジュール性を確保するために守らなければならない5つの原則 開放/閉鎖原則 (OpenClosedPrinciple) よいアプローチのための Concepts + Principles 曳光弾 可逆性

    honeybe
    honeybe 2007/06/05
  • YouTube - Google Developer Day Tokyo - 鵜飼 文敏

    Software Engineer in Google 鵜飼 文敏

    YouTube - Google Developer Day Tokyo - 鵜飼 文敏
  • steps to phantasien t(2007-06-01) ChangeLog の作法 つづき

    Subversion の開発者が ChangeLog について面白い記事を書いている. 記事の要旨はこうだ: ChangeLog (Subversion なので commit log) を書くのは面倒だよ, メーリングリストもあることだし書かなきゃダメ? ってよく訊かれる. 書きましょう. バグトラックもあるけど, 書きましょう.これらのツールは補完しあっている. メーリングリストはノイズが多いし, 変更を特定するには情報が足りない. バグトラックはバグの記録がメインだからコードの話を細々書くのは邪魔になる. 変更については ChangeLog に書くのがいい. プログラマは ChangeLog を読む. 記録を検索して, どの関数に何が起きたかを調べるものだ. この類の記録は ChangeLog を読まないとわからない. 逆に ChangeLog を書く時は, それを特定できるように省略

  • ChangeLog の作法 steps to phantasien t(2005-10-13)

    ソースコードなどの変更履歴を ChangeLog と呼ぶ. オープンソースのソフトウェアで変更履歴を "ChangeLog" というファイルに書いたのが ChangeLog のおこりだと思う. 最近は Subversion などに登録された変更履歴も change log, あるいは commit log などと呼ぶ. 以下ではそれらを ChangeLog と総称する. 最近わけあってこの ChangeLog をどう書いたものかと考えている. コーディング規約には山ほど資料がある. コメントの書き方もよく議論される. しかし ChangeLog についての読み物は少い. GNU コーディング規約 は数少ないそうした文書である. この説明はよくかけている: ChangeLog は将来のメンテナがバグの原因を探るのに使うものだ. コメントに書くべきものはコメントに書け. 関数名を並べろ...

  • NOT_FOUND 404

    ■ ファイルが見つかりません。 Not Found 誤ったURLを入力された可能性があります。再度ご確認のうえURLをご入力ください。