  |
はてなキーワード: firebugとは
企業がなにか不祥事を起こし、謝罪文を会社のサイトに掲載するというのは、昨今珍しくないどころか、むしろ記者会見を開くより当たり前となっている。
その謝罪文で、単なるテキストではなく、画像で作った文章が使われる事例がある。
これを「検索エンジンに引っかからないようにするための姑息な手段」とする意見があるけれど、実際にはそれとは違う理由で、画像を使う事もある。というのも、今どき企業の不祥事など、新聞社のサイトにだって何年も残るし、その不祥事が炎上まっただ中ならGoogleで検索すれば、まず企業のサイトよりも、その不祥事を報じた記事の方が上に出てくる時代である。
不祥事を隠している段階ならともかく、公となり、謝罪文まで作った以上、企業側としては、むしろ謝罪文を検索エンジンのトップの表示したいほどである。企業がこの事件をどのように考えているのか、今後どのような対策を取るのかということは、マスコミというフィルターを通してよりも、ダイレクトに客に知らせたいというのが本音であるという企業は少なくない。企業の中には、わざわざテレビで「火災を起こす可能性があるので、○○という給湯器を探しています」というCMを流す事もあるのが、今どきの企業である。
では、どうして企業側は、検索エンジンに引っかかりづらい画像で謝罪文を載せるのか？
簡単に言うと、捏造対策。HTMLにただテキストを埋め込むだけだと、例えばFirebugなどを使って謝罪文をおちょくった文章に書き換えることが手軽にできる。それをスクリーンショットに取り、Twitterなどで公開して「ここの企業、こんな客をバカにすること言ってるぜ。なんて企業だ」と、さらなる炎上を狙うような人々に対する対策である。他の人から「元の謝罪文と違うじゃねーか」というツッコミが入っても、「さすがにやばいと思って差し替えたんだ。この企業は断りなく謝罪文を差し替えるような腐った企業なんだ」という反論すら予想される。それに対する対策である。
「いや、画像だって改ざんは可能だろ？」というのは、確かにその通り。しかし、画像での謝罪文だと、やはりテキストよりは改ざんは面倒だし、使用しているフォントも、よほど詳しい人じゃないと分からない。一部だけを書き換えると、フォントの違いが出てくるかもしれない。そういうのがあれば、企業側としては「ここのフォントが違う。これはこの人が改ざんしたんだ」という主張ができるようになる。全文を似たようなフォントで書き起こす、OCRソフトを使うという方法もあるだろうけど、さすがにそこまで手間をかける人は少ないだろうし、そこまで考えると謝罪文自体、ネットで公表できなくなるので、そこまでは考えない。
「PDFでも良いじゃん。そっちの方がGoogleとかにも引っかかるし」と言われれば、確かにその通り。それは企業の好みというか、単に普段からOfficeばかりで思いつかなかったとか、その程度の違い。
もちろん、「Googleにできるだけ引っかからないように」という目的で、画像にしてる企業もいるだろう。しかし、「改ざんしづらくする」という目的で、画像を使ってる企業もあるので、画像だからといって即叩くのはやめてほしいものだ。叩くのは、不祥事そのものと、その対応が十分かどうかで叩いて欲しい。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
テーマストアが公開されたので、週末の時間を使ってちょっと作ってみたんだけど、想像以上に手間がかかったのでまだ完成してない。
手引きに「オリジナルテーマの作成は、CSSの知識がある方を対象にしています。」なんて逃げを打ってるけどさ。プロ向けにしたってちょっと投げっぱなしじゃないの？
そのため、気合いで解析する必要がある。保守するプログラムに設計書もコメントもないなんて常識だよねー、的な？ まあ頑張ってFirebugするわけですが、当然、解析できるのはCSSの構造までであり、そのスタイルの意図などはわかるはずもないわけで。もしかしてアレですか。Webデザイナであればフィーリングで伝わるようなレベルの問題なんでしょうか。私のような卑しいSIerのエンジニアはWeb業界に転職してから出直した方がいいのでしょうか。
テスト用に別ブログを自分で開設し（！）、自分であらゆる表示パターンを網羅するテストページを作成（！！）し、カスタムCSSを記述しては保存、各種確認URLを開いて回る、ということを公式に求める始末。なんではてな様のテーマ作成コスト削減にそんな苦労をしてまで貢献しないといかんのですか。ちなみに手引きで紹介されているサンプルエントリーでは何かと不十分。脚注とかないし。シンタックスハイライトじゃないPREないし。コメントとかスターとか自分でつけないとだし。複数ページないとPagerでてこないし。つーか、はてなの公式テーマとか作ったときに使ったテスト用HTMLやテストケースを公開してくれればいいんでないの。・・・あるよね？
この前のトップページデザイン変更もそうだけど((自分の場合、横方向の視線移動を求められるようになったのが苦痛で仕方が無い))。使う人のこと、基本的にあんまり考えてないよね、はてな。とにかく、はやりの技術やデザインを使ってみたいんだろうね。それがユーザーにとっていいかどうかは二の次なんだろうね。個人の趣味じゃないんだからさ。ねえ。お願いしますよ。こんなんで月980円（だっけ？）もとろうだなんてどうかしてるよ。
公式でも投稿でもいいからはてなダイアリー並にテーマがたくさん使えるようになるのはいつなんでしょう。
あと全然別の話だけどついでに文句書いておくと、スマホ用はてブのWebはなんでわざわざAjaxでPager実装しているの？ だって最新ホットエントリー一覧なんて、前のページのコンテンツ保持しておく必要性も薄いじゃない。何が困るって、次ページ読み込み中（■がくるくるしてる状態）に電波切れると（地下鉄とかね）、ボタン押せなくなってるから電波復帰してもどうにもならなくなるのよね。リロードすると1ページ目に戻るし。普通にリンクで次ページ遷移じゃダメなの？
前編はこちら
http://anond.hatelabo.jp/20120926165407
会員情報や文章などのコンテンツを保存しておくデータべース、ＭｙＳＱＬを調べます。
データベースは他にもPostgreSQLやSQLiteなどが有名ですが、やはり王道を勉強します。
MySQLはCakePHPや、ステップ４のWordPress他、よく使いますので把握しておきましょう。
今はまだ関係ありませんが、余裕があればこれも読むといいです。
操作はコマンドラインを覚えていく方向で、始めはブラウザで操作できるphpMyAdminを使ってＯＫです。
技術調査はこの位にして、これからは実際にWebサイトを作っていきます。
ここまで来ると何となく、Webサイトがどんな仕組みで動いてるかが分かってくるので、
ステップ０でイメージした作りたいサイトがどんな技術で実現出来るか調べます。
TwitterやGoogle、Yahoo、AmazonなどのAPIを使ってサテライトサイトを作っても良いと思います。
が、高度な事をするとはまりやすいので、ある程度やって無理だったらあきらめて次回にまわしましょう。
まずは何か一つ完成させる事のほうが大切です。
それから開発効率ＵＰのため、Chromeにプラグインを入れましょう。
説明はそれぞれのリンク先を見て下さい。
https://chrome.google.com/webstore/detail/ggfgijbpiheegefliciemofobhmofgce
Firebug Lite for Google Chrome
https://chrome.google.com/webstore/detail/bmagokdooijbeehmkpknfglimnifench
View Selection Source
https://chrome.google.com/webstore/detail/fbhgckgfljgjkkfngcoeajbgndkeoaaj
Pendule
https://chrome.google.com/webstore/detail/gbkffbkamcejhkcaocmkdeiiccpmjfdi
BuiltWith Technology Profiler
https://chrome.google.com/webstore/detail/dapjbgnjinbpoindlpdmhochffioedbn
iPSim
https://chrome.google.com/webstore/detail/gcligifbhamdimemnemmlkffkpmflehh
Color Picker
https://chrome.google.com/webstore/detail/ohcpnigalekghcmgcdcenkpelffpdolg
CSS Tester
https://chrome.google.com/webstore/detail/pjncppaiejjkcjlcgegcbmhgkflhenfp
MeasureIt
https://chrome.google.com/webstore/detail/pokhcahijjfkdccinalifdifljglhclm
あとはFireFoxにはFireBug。デバッグの定番らしいです。
https://addons.mozilla.org/ja/firefox/addon/firebug/
それから、空いた時間に無料のプログラミング動画サイト「ドットインストール」を見ておくと
ここまでの知識が定着すると思います。
ステップ７で作りたいサイトがイメージ出来てきたら、ドメインを取りましょう。
サーバーがさくらの場合はドメインもさくらで取得すると楽ですが、もっと安いところもあります。
希望するドメインが空いているか調べて取得、空いていなければ他のドメインを考えます。
http://www.sakura.ne.jp/domain/
定番の.com、.net、.orgは誰が見ても親しみがあるし安いので、できればこの３種類のどれかにしたい所ですが、
一般的な言葉はほぼ埋まっているので、その場合は.jp等にしても良いでしょう。
日本語ドメイン(www.日本語.netみたいな)は流行っていないですが、
自分のサイト名が「○○○.com」のような名前の場合は一緒に取得して、アルファベットのドメインにリダイレクトしましょう。
（ChromeユーザーがURL欄で検索する時、「○○○.com」のように後ろに.xxxが付いているとそのURLに直接アクセスしてしまい、
僕はバリュードメインで取得して、サーバーはさくらのレンタルサーバーにしました。
その際の親切な設定方法の解説はこちら。
VALUE DOMAIN で取得したドメインをさくらのレンタルサーバで使う
http://nekohacks.com/wordpress/domain/value-domain/
どんなサイトで、どんな機能があって、どんなページがあるかノートに書き出して行きます。
サイトの基本的なレイアウトをCSSで組みながら、デザインのイメージもしておきましょう。
ここではデザインはまだやりません。
先にデザインを作っても、プログラムを進めていく過程で変更がでたりする為です。
（でもあんまり後回しにしても、見た目がチープなせいでモチベーションが下がったりするので、次のステップでやります）
あと、ここで気をつけたいのは、あくまでメインとなる機能の開発を優先することです。
外堀から埋めていくとそこでモチベーションが尽きてしまったり、
メインの機能を実装してみたら外堀の修正が発生してしまったりするためです。
始めると分からない事がどんどん出てくると思うので、本を読み返したりGoogle先生で検索しながら進めて行きます。
なかなか進まなくて検索８割、コーディング２割くらいの進め方になると思いますが、それでＯＫです。
いじっているだけでモチベーションを使い切ってしまったりするので危険です。
ＣＧソフトは色々ありますが、おすすめはフォトショ(Photoshop)です。
WebサイトのデザインはFireworksなども有名ですが、学習コストがかかるので、
Webサイトにもそれ以外にも使えて一番つぶしが効くフォトショップでOKです。
今年からクラウド契約が始まり、今なら１ヶ月８０００円、年間契約なら１ヶ月５０００円で
http://www.adobe.com/jp/products/creativecloud.html
お勧めの本はこれ
一から全部自分で作らなくても、素材サイトからダウンロードして加工するなどして手間を省きます。
ＰＣ・スマホ・携帯(ガラケー)全部に対応するのは大変なので、
初めはそのサービスを最も使うだろうと思われるどれか１つに絞ります。
ＰＣ用サイトならスマホでも最低限アクセスはできるし、携帯は縮小傾向なので優先度低、
スマホは画面サイズがまちまちでタブレット端末が目下発展中、AndroidはブラウザがたくさんあるがChromeに統一されていくかも、
対応する際はＣＳＳを切り替えてレスポンシブレイアウトにするのがお勧めです。
その他、困ったらTwitter社が公開しているブートストラップを使うのもお勧めです。
ブートストラップはcssのフレームワークで、簡単にシャレ乙なデザインに仕上がります。
超便利！Twitter BootstrapでさくさくWeb開発
どうしても自分でイケてるデザインが出来ないと思ったら、友だちに頼んだり、ＳＮＳのコミュで募集したり、
デザイン系の大学や専門学校の掲示板にビラを貼らせてもらったりしましょう。制作費が出せればランサーズで募ってもいいかも。
Lancers - 仕事をフリーランスに発注できるクラウドソーシングサービス
僕はたまたまフォトショップの使用経験があったので、ここにかけた時間は30時間ではなく5時間程です(トータル275時間で開発)。
後編はこちら
10/18 改訂
なお、取得した画像の著作権はグーグル他各社が保持しています。
ご利用は計画的に私的範囲でどうぞご利用ください。
#!/usr/bin/perl use strict; use warnings; use Getopt::Long; use LWP::UserAgent; use GD; my $cmdline = join(" ", $0, @ARGV); my $usage = "usage: $0 -sx=116423 -sy=51603 -ex=116426 -ey=51605 -dx=4 -dy=3 -z=17 -size=300 -get=30 -dir=cache -output=output.jpg -nodebug"; my ($sx, $sy) = (0, 0); my ($ex, $ey) = (0, 0); my ($dx, $dy) = (4, 3); my $z = 17; my $size = 300; my $get = 30; my $dir = "cache"; my $output = "output.jpg"; my $debug = 0; GetOptions("sx=i" => \$sx, "sy=i" => \$sy, "ex=i" => \$ex, "ey=i" => \$ey, "dx=i" => \$dx, "dy=i" => \$dy, "z=i" => \$z, "size=i" => \$size, "get=i" => $get, "dir=s" => \$dir, "output=s" => \$output, "debug!" => \$debug) or die "$usage\nDied"; if ($ex == 0) { $ex = $sx + $dx; } else { $ex++; $dx = $ex - $sx; } if ($ey == 0) { $ey = $sy + $dy; } else { $ey++; $dy = $ey - $sy; } $sx>0 and $dx>0 and $sy>0 and $dy>0 and $z>0 and $dir and $output or die "$usage\nBad arguments"; $dx*$dy > $size and die "Getting too large."; $debug and print "debug: mkdir $dir\n"; mkdir $dir; -d $dir or die "can't make dir $dir: $!"; my $base = sprintf("http://khm%d.google.co.jp/kh/v=46&z=%d", int(rand(4)), $z); my $ua = LWP::UserAgent->new; printf "now get %d images...\n", $dx*$dy; for (my $x=$sx; $x < $ex; $x++) { for (my $y=$sy; $y < $ey; $y++) { my $file = sprintf("%s/%02dz%06dx%06d.jpg", $dir, $z, $x, $y); $debug and print "debug: check of $file\n"; -s $file and next; --$get < 0 and last; my $req = HTTP::Request->new(GET=>+"$base&x=$x&y=$y"); $debug and print "debug: fetch from ".$req->uri."\n"; my $res = $ua->request($req); unless ($res->is_success) { print "fail fetch from $file: ", $res->status_line, "\n"; next; } if (open(my $fh, ">", $file)) { $debug and print "debug: write of $file\n"; binmode $fh; print $fh $res->content; close $fh; } else { print "fail open in $file: $!\n"; } } } $get < 0 and print "reach the getting limit, skip after all.\n"; printf "creating %dX%d image...\n", 256*$dx, 256*$dy; my $image = new GD::Image(256*$dx, 256*$dy); for (my $x=$sx; $x < $ex; $x++) { for (my $y=$sy; $y < $ey; $y++) { my $file = sprintf("%s/%02dz%06dx%06d.jpg", $dir, $z, $x, $y); $debug and print "debug: check of $file\n"; -s $file or next; $debug and print "debug: read of $file\n"; my $part = GD::Image->newFromJpeg($file); $debug and print "debug: image copy\n"; $image->copy($part, 256*($x-$sx), 256*($y-$sy), 0, 0, 256, 256); } } #$image->string(gdSmallFont, 0, 0, $cmdline, $image->colorAllocate(255, 255, 255)); open(my $fh, ">", $output) or die "fail open $output: $!"; $debug and print "debug: write of $output\n"; binmode $fh; print $fh $image->jpeg(); close $fh;
例えば秋葉原とか
perl gmwall.pl -sx=116423 -sy=51603 -ex=116427 -ey=51606
駅だけとか
perl gmwall.pl -sx=465701 -sy=206420 -ex=465705 -ey=206423 -z=19
使う数値はfirebugなどで拾ってください。
寝る前にいくつか返信。
http://anond.hatelabo.jp/20080902220835]
たぶんそうだと思う。
http://anond.hatelabo.jp/20080902221735]
でもほら、ダイアリーの立ち上げ当時は似たようなもんじゃないかと。
同様の意見としてb:id:hatayasanとかb:id:ululunとかb:id:nakano87とかb:id:te2uとかね。元記事にチェックボックス案もmetaを使う前提でチェックが off なら head に件の meta を入れる
って書いてあるのになぁ。リテラシーって大事だ。
そっちの仕様は別にいいの。自社サービスの機能を使うのにmetaを本文に書かせるのがダメ。
b:id:masayc 技術力を期待してはてな使ってる人ってどれくらいいるんだろうね？俺は、日本”語”でweb2.0ごっこしたいだけで、もし英語が達者ならdiggとdelicious使うけどな。
日本語のWeb2.0ごっこなら、私が唯一中期間使った例で申し訳ないけどドリコムブログの方が優れてた。使ってたの数年前だけど(今はWP)。例えばデザイン編集画面で、ブログの2or3カラムレイアウトに表示する要素をDnDで並べ替えたりとか。DHTMLすげーって感じ。
はてなはWeb2.0の特徴の一つと言われてるマッシュアップとかがろくにできない。はてなのデータを外で使うための機能は多いけど、外のサービスとかをはてなに持ち込めない。Blogパーツ、裏技使わないと自由に貼れないでしょ？
2.0っぽさではてなよりも劣ってるサービスってあんま無いんじゃなかろうかと。むしろ往年のWeb日記の仕様を引きずってるし、メジャーバージョンは1。Web1.9。
b:id:xevra 技術的には指摘の通りだろう。だが経営的にはこれが正解。なぜなら一覧非表示機能を希望し、文句言ってくる人は0.01%程度。この程度のものにリソースは割けない。完璧を求めるのは趣味の領域。jkonは正しい。
今は一覧非表示機能に限った話してないんだけど。上の方のアレもそうだけど、非表示絡みでコメしてる人は何故かピントが合わない。
例えばブログモード使ってる人ってけっこう多いけど、彼らは絶対に記事毎に編集やコメント管理できた方が便利。トラバ先を記憶する機能ってそんなに開発リソース必要ですか。大した事無い機能変更にもがっつりリソースを割かないと改善できないのが問題。
まぁでも確かに、現在のはてダの低い技術ポテンシャルという前提の下では、jkonは正しいね。
b:id:ghostbass なんだって？？テーブルの変更なんか必要ないけど？
そうなんですか。考えてみます。思いつかなかったら勉強してみます。Boromさんの案が正解かも。
b:id:EvilGood おそらくそうなんだろうけど、小手先回避なんだろうとは思うが、さきざきサーバーの処理能力が上がって、すべて記法解析でやった方が速度出る日が来そうなんだよな。はてなはXMLDBとか検討してるんだろうか？
はてなが未来を見据えてそういう拡張をしてきたのか、という点はさておき、すべてを記法でやろうとすると記事の編集時の可読性が下がります。本文にmetaとか記事見出しなのに何故か本文にあるとかトラバ送ったかどうか解らないとか。
ユーザーの快適性とか開発の柔軟性とかを犠牲にしてまで、未来の鯖速度を追求するというのはなかなかどうも、説得されないです。
さらに追記。
b:id:skicco はてな記法でごまかしてくれたおかげで、他のブログサービスではできない重複したカテゴリへの登録ができてる。これが可能なのってはてダくらいじゃね？
最近のブログサービスは知らないですけど、WordPressではできます。ところでカテゴリってリストから選べないと Typo りますよね。
ごめん、年1000万の間違いだったかも。倍近く違うじゃん。malaさんが入社したてのころにどっかでこういうの書いてた。うるおぼえ。
b:id:kana-kana_ceo 「普通なら、日記の編集フォームに一つ『ブクマページでブコメを表示する』というチェックボックスを付ける。チェックが off なら head に件の meta を入れる」← なんで、非表示がデフォなんだろう？
一人くらい勘違いする人がいるとは思ってた。非表示がデフォなんて書いてない。デフォでチェックが on にしてあればおk。
チェックボックスのラベルは肯定文で書くのが UI の Tips。「非」表示は否定語。
b:id:al001 "少なくとも"技術力の問題では無いと思うが。面倒とかそういうのであれば分かるけど。 / チェックボックスでオンオフ出来るだけで良いなら、DB弄らずともJavaScriptだけで出来る。
まず後半。またまたご冗談を。クライアントサイドの解決法じゃ meta が body の下にある事は変わらなかろうて。パース後に動かすつもり？
そういや手元で試してみたら、 Firebug でソースを見ると body 内の meta も head の下にあったものとしてパースされるね。
前半は、他の人も同様の事言ってますね。要するに費用対効果の話。
でも、面倒
=費用が高くついてるのはシステムの出来が悪いから。スパゲッティーを紐解きたくないんでしょう。
ブコメ非表示みたいなおそらくほとんど使われないような機能だけがこうやって糞仕様存置されてるってんなら、経営判断って意見も説得力がありますね。
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
_________________ここから下は古い情報▼__________________________________________________
今、自分のブログをスクラッチしているので、こちらで。→2008/9/28 スクラッチ完了！BLACK-OUT.CSS公式ページ
作りました
要は、LynxのようなシンプルWebに世界がなればいいのになと思っている方。
そして、どんなサイトでも目線は左右に動かしたくない！スクロールは上下だけで済ませたい！
と、強く考えておられる方むけの情報です。
私はテキストブラウザのLynxを時々使っているのですが、これでサイトを見るとシンプルに見れるのですごく良いんですよね。
ただ、LynxはFlashとか画像が見れないし、マウスが使えないのはいざって時にちょっと不便。
で、Firefoxをテキストブラウザ化できないかなあと、ふと思いまして、思いつきで作ってしまいました。
私めもwebデザイナーやっとるんですが、上記のように、昨今のwebデザインなんて普段はなくていいって思っている奴でして。
仕事じゃ3カラムのサイトとか作りますが自分はそんなん好きじゃないです。色がサイトごとに違うってのも理解できない。
必要なのは情報であってデザイナーのデザインなんてどうでもいいんですよ。
そんな訳で、どんなサイトでもテキストブラウザ状態で閲覧できるFirefox用の拡張cssを作りました（やっつけだけど）。
ただ、ニュースサイトで画像が見れないと困る時もあるので、普段は小さなサムネイルで、カーソルを合わせた時だけ大きく表示されるようにしています。
＠このcssはコンセプト実証モデルです。思いつきで作ってるのでちょっと問題もあります。フィードバックとか意見など頂けると嬉しいかも。
＠将来的には、グリモンでjsも組み合わせてもっとコンソールのような感覚でブラウジングできるようにしたい
＠（参考用）私のよく見るサイト・・・ニコ動、wikipedia、スラッシュドットジャパン、2nn.jp（2ch）、mixi、はてなでホッテントリに上がっているブログ各種
ちなみに、こんなん使うな、既にこんないいのあるわいってのをご存知の方は教えてくれると嬉しいです。
それなりに探したのだけど、見当たらなくて・・・だから自作したので。
/* * ---------------------------- * black-out.css * author zamamin.com * build 2008.8.09 15:03 * version 0.0.31 * fix @namespaceを書いてなかったので追加 * ---------------------------- * */ @namespace url(http://www.w3.org/1999/xhtml); /* 全てのエレメントをリセット */ body,body * { background-image:none !important; background-color:#000 !important; border-color:#333 !important; text-decoration:none !important; color:#aaa !important; /*<- テキスト色 */ font-size:16px !important; /*<- 文字サイズ */ font-weight:normal !important; padding:0.15em !important; margin:0 !important; line-height:1.25em !important; text-align:left !important; text-indent:0 !important; font-family:Arial,Helvetica,Verdana,'ヒラギノ角ゴPro W3','Hiragino Kaku Gothic Pro',Osaka,'メイリオ',Meiryo,'ＭＳ Ｐゴシック',sans-serif !important; float:none !important; clear:both !important; position:relative !important; width:auto !important; height:auto !important; } body { background-color:#000 !important; padding:0.5em !important; } body * p, body * div, body * h1, body * h2, body * h3, body * h4, body * h5, body * h6{ margin-bottom:0.3em !important; float:left !important; clear:both !important; } /* リンク色 */ body * a, body * a *{ color:#a50 !important; } /* アクセス済みのリンク色 */ body * a:visited{ color:#a50 !important; } /* カーソルを合わせた時のリンク色 */ body * a:hover, body * a:hover *{ color:#0aa !important; background-color:#609 !important; } /* 画像は普段は小さくサムネイル表示。鬱陶しいので薄く表示 */ body * img{ opacity:0.3 !important; height:15px !important; width:15px !important; } /* 画像はマウスカーソルもっていけば原寸サイズになる */ body * img:hover{ opacity:0.9 !important; height:auto !important; width:auto !important; } button, input, select, option, textarea{ color:#f00 !important; padding:0.05em !important; height:auto !important; } /* テーブルのスタイル */ table{ border:none; } table td, table th{ border:none; border-right:1px dashed #999 !important; border-bottom:1px dashed #999 !important; } /* for 2ch（暫定） */ body * dt{ font-weight:bold !important; } /* 二コ動 */ embed#flvplayer{ height:540px !important; width:952px !important; }
ほんとにもう最高。
楽したい人間+ハマり性な人間には、こーゆーカスタマイズがしがし出来るツールが最高なのよ。
エディタならvim。emacsでもいいけど、あんまり詳しくない。
他のツールはカスタマイズ性で見劣りする。
こだわりのない人間にはどんなツールでもオッケーなんだろうね。
オレはこだわるところはこだわる。
ちょっとした不便に気づかないか気づいても甘受してしまうような人間と、今はクリアできなくともなんとか今後の課題にしたいと考える人間。
そこの違いだね。
どっちが得かというのはわからんけどね。
優劣とか損得の問題じゃなく、ただオレはそういう人種だってこと。
追記
vimperatorrcねえ。特筆すべき点はないけど、あえて一部抜粋すれば、こんな感じ。
inoremap <C-1> <Esc>1gt inoremap <C-2> <Esc>2gt inoremap <C-3> <Esc>3gt inoremap <C-4> <Esc>4gt inoremap <C-5> <Esc>5gt inoremap <C-6> <Esc>6gt inoremap <C-7> <Esc>7gt inoremap <C-8> <Esc>8gt inoremap <C-9> <Esc>9gt noremap <BS> H noremap <S-BS> L noremap ,b <Esc>:bmarks -tags= noremap u :o<Space> " ldrc+ldrでoで:open出来ない問題を解決
" wildoptions=auto時に一瞬補完が表示されてウザいmapがある - Dis Communication - 符号無し " http://unsigned.g.hatena.ne.jp/Trapezoid/20080620/1213961754 javascript <<EOM [ [',a',':dialog addbookmark'], [',c',':viewSBMComments -t h'], [',C',':viewSBMComments -t hdl'], [',d',':pindownload'], [',ld',':set ldrc'], [',p',':mb clear-pin'], [',q',':toggleldrc'], [',R',':so ~/_vimperatorrc'], [',r',':res'], [',v',':!vim ~/_vimperatorrc'], ['\\s',':scrapbook'], ['\\S',':scrap'], ['\\f',':firebug'], ['\\d',':dialog downloads'], ['\\p',':tabopen chrome://browser/content/places/places.xul'], ['!',':set invum'], ['B',':ls!'], ['\\a',':addons'], ['\\e',':errorconsole'], ['\\F',':firebugwindow'], ['\\d',':dialog downloads'], ['\\g',':oepnGMpanel'], ['\\G',':toggleGM'], ['e',':note'], ['<F11>',':fullscreen'], ['\\P',':placesnewwin'], ['\\H',':historynewwin'], ['<C-j>',':togglebookmarksidebar'], ['<C-k>',':togglehistorysidebar'], ['<C-l>',':addtoldr'], ['<C-S-Right>',':removerighttabs'], ['<C-S-Tab>',':previousfirebugtab'], [',o',':openselectedlinks'], [',3',':copy titleAndURL'], [',ig',':imageGet'], [',io',':imageOpen'], ['w',':submit'], [',lo',':logout'], // nicontroller.js [',ni',':nicoinfo'], [',np',':nicopause'], [',nm',':nicomute'], [',nv',':nicommentvisible'], [',nz',':nicosize'], [',ns',':nicoseek'], ].forEach(function([key,command]){ liberator.mappings.addUserMap([liberator.modes.NORMAL], [key], "User defined mapping", function () { liberator.execute(command); }, {rhs: key, noremap: true}); }); EOM javascript <<EOM [ ['<C-j>',':togglebookmarksidebar'], ['<C-k>',':togglehistorysidebar'], ].forEach(function([key,command]){ liberator.mappings.addUserMap([liberator.modes.INSERT], [key], "User defined mapping", function () { liberator.execute(command); }, {rhs: key, noremap: true}); }); EOM
javascript <<EOM // nicontroller.js plugin // [N]- // N 秒前にシークする。 // 指定なしの場合 10 秒前。 liberator.mappings.addUserMap( [liberator.modes.NORMAL], ['-'], 'seek by count backward', function(count) { if(count === -1) count = 10; liberator.execute(':nicoseek! ' + '-' + count); }, { flags: liberator.Mappings.flags.COUNT } ); // [N]+ // N 秒後にシークする。 // 指定なしの場合 10 秒後。 liberator.mappings.addUserMap( [liberator.modes.NORMAL], ['+'], 'seek by count forward', function(count) { if(count === -1) count = 10; liberator.execute(':nicoseek! ' + count); }, { flags: liberator.Mappings.flags.COUNT } ); EOM
Vimperatorで;bでリンクを新しいバックグラウンドのタブに開くようにする。
http://anond.hatelabo.jp/20080709195527
も俺の仕業なんだけど、これvimperator本体に実装してくれないかな。
気になる点・これからの課題
窓の杜 - 【NEWS】Firefox 3のスマートロケーションバーに対応した「XUL/Migemo」
http://www.forest.impress.co.jp/article/2008/07/07/xulmigemo0105.html
余談
Index of /
http://vimperator.driftaway.org/
に上がるのはたいてい朝の07:30になっているので、いつからかチェックするのが朝の習慣になった。
javascriptで存在するほとんどのオブジェクトの実体はハッシュだよ。
var arr = [0,1,2,3];
とかをみると配列(人によってはリスト)に見えると思う。でも実際は違うんだ。
これは
var has = {0:0,1:1,2:2,3:3};
と基本的には等価なんだ。ただちょっと束縛されているメソッド(インターフェイス)が違うだけ。
ためしに
arr[4] = 4; arr['x'] = 'string'; arr[-1] = -1;
としてみよう。
Firebugで確認してみると[0, 1, 2, undefined, 4]というような値がかえってくるよ。
でもarr[-1]やarr['x']の値は保存されてないのかな？そんなことはないちゃんとアクセスできるんだ。
それどころかarr.xで'string'がかえってくるんだ。
別の例を見てみよう。
var fx = function(){}; fx[0] = 'somestring';
こうするとfx[0]に'somestring'が束縛される。
つまりfunctionも一つのハッシュだったんだ。
これでほとんどのものがハッシュだということが解ってくれたかな？
ハッシュじゃないのは文字列とか数字とかそいういシンプルなものだけなんだ。
ハッシュへはhash[name]でアクセスすることが出来る。
それ以外にもnameが演算子や空白を含まなくて頭が数字でない場合はhash.nameでアクセスできるんだ。
これでhash[name]が関数だったらhash.name(args)とできるよ。まるでメソッドみたいだね。
関数には名前を付けなくても使用可能だよ。
function(x){return x+x}(2); -> 4
関数宣言の書き方って次見たいの覚えてる人が多いんじゃないかな？
function funcname(args){ do something};
でもこれはsystax sugerだってことを知ってほしい。
上でも使ってるんだけど。
var funcname = function(args){ do something};
と等価になる。もちろんどちらの書き方でもかまわないよ。
ただ、(無名)関数を宣言してそれをfuncnameに束縛しているっていうことを理解しておくと便利だよ。
javascriptはレキシカルスコープを採用してるんだ。
レキシカルスコープなんていうと難しく感じるかもしれないけど、結構単純なんだ。
var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){var x = 'local';return x}
これの実行結果は以下になるよ。
fx1() -> 'global' fx2() -> 'local' fx1() -> 'global'
fx2の変数xはほかの場所に影響しないんだ。これは関数の中と外ではスコープが違うからなんだ。
でも以下のような場合に注意してほしいな。
var x = 'global'; var fx1 = function(){return x}; var fx2 = function(){x = 'local';return x}
fx1() -> 'global' fx2() -> 'local' fx1() -> 'local'
fx2は自分のスコープに変数xがないからその外側スコープに探しに出かけたんだ。
つまり宣言文varはそのスコープに新しい名前を登場させる機能なんだよ。
別の場合を見てみようね。
var x = 'global'; var fx1 = function(){ var x = 'local'; return function(){return x} }; var fx2 = fx1();
x -> 'global' fx2() -> 'local'
この例だとfx2()の値がlocalになってるね。
なぜなら外側スコープっていうのは関数を評価した場所じゃなくて、関数を定義した場所の外側なんだ。
一つ上の例では実際に関数を返り値にしているね。
var fx1 = function(){ var x = 0; return function(){ x = x+1; return x; } }; var fx2 = fx1(); var fx3 = fx1();
fx2() -> 1 fx2() -> 2 fx2() -> 3 fx3() -> 1 fx3() -> 2
fx2とfx3の値が違うのはそれぞれ別の関数が作られるからだよ。
こんな風に関数が状態を持つことも出来るんだ。クロージャーとよんだりするよ。
関数がハッシュを使って複数の関数を返すとこんなことも出来るよ。
var fx = function(){ var x = 0; return { 'up':function(){ x = x+1; return x; }, 'down':function(){ x = x-1; return x; } } }; var obj = fx();
obj.up(); -> 1 obj.up(); -> 2 obj.down(); -> 1 obj.down(); -> 0
thisという機能があるよう。ちょっとだけつかってみるね。
var x = 0; var add = function(n){this.x = this.x + n; return this.x}; var mul = function(n){this.x = this.x * n; return this.x}; var obj = {'x':0,'do':add};
add(1); -> 1 add(1); -> 2 mul(2); -> 4 obj.do(); -> 1 obj.do(); -> 2 obj.do = mul; obj.do(); -> 4
thisは評価された場所によって値がかわるよ。
objの中にいるときはobj.xを扱うし、グローバルにいるときはグローバルのxを扱うんだ。
http://anond.hatelabo.jp/20070620200618を改訂してみたよ。
このぶんしょうがjavascriptを覚える上の一助になるとうれしいんだ。
あとここでつかってるハッシュは伝統的な意味。連想配列のことね。
突っ込みも大歓迎だよ。
javascriptで存在するほとんどのオブジェクトの実体はハッシュだよ。
var arr = [0,1,2,3];
とかをみると配列(人によってはリスト)に見えると思う。でも実際は違うんだ。
これは
var has = {0:0,1:1,2:2,3:3};
と基本的には等価なんだ。ただちょっと束縛されているメソッド(インターフェイス)が違うだけ。
ためしに
arr[4] = 4; arr['x'] = 'string'; arr[-1] = -1;
としてみよう。
Firebugで確認してみると[0, 1, 2, undefined, 4]というような値がかえってくるよ。
でもarr[-1]やarr['x']の値は保存されてないのかな？そんなことはないちゃんとアクセスできるんだ。
それどころかarr.xで'string'がかえってくるんだ。
別の例を見てみよう。
var fx = function(){}; fx[0] = 'somestring';
こうするとfx[0]に'somestring'が束縛される。
つまりfunctionも一つのハッシュだったんだ。
これでほとんどのものがハッシュだということが解ってくれたかな？
ハッシュじゃないのは文字列とか数字とかそいういシンプルなものだけなんだ。
ハッシュへはhash[name]でアクセスすることが出来る。
それ以外にもnameが演算子や空白を含まなくて頭が数字でない場合はhash.nameでアクセスできるんだ。
これでhash[name]が関数だったらhash.name(args)とできるよ。まるでメソッドみたいだね。
javascriptはレキシカルスコープを採用してるんだ。
var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){var x = 'local';return x}
これの実行結果は以下になるよ。
fx1() -> 'global'
fx2() -> 'local'
fx1() -> 'global'
fx2の変数xはほかの場所に影響しないんだ。これは関数の中と外ではスコープが違うからなんだ。
でも以下のような場合に注意してほしい。
var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){x = 'local';return x}
fx1() -> 'global'
fx2() -> 'local'
fx1() -> 'local'
fx2は自分のスコープに変数xがないからその外側スコープに探しに出かけたんだ。結果fx
つまり宣言文varはそのスコープに新しい名前を登場させる機能なんだよ。
関数宣言の書き方って次見たいの覚えてる人が多いんじゃないかな？
function funcname(args){ do something};
でもこれはsystax sugerだってことを知ってほしい。
上でも使ってるんだけど。
var funcname = function(args){ do something};
と等価になる。もちろんどちらの書き方でもかまわないよ。
関数は返り値として関数はハッシュを指定できるよ。次のハッシュを返す関数を見てみよう。
var fx = function(){ var x = 0; return { 'x':x, 'add1':function(y){this.x = this.x+y;return this.x}, 'add2':function(y){x = x+y;return x} } } var obj = fx();
実行結果を見てみよう
obj.x -> 0 obj.add1(0) -> 0 obj.add1(0) -> 0 obj.x -> 0 obj.add1(1) -> 1 obj.add1(0) -> 0 obj.x -> 1 obj.x -> 1 obj.add1(0) -> 1 obj.add1(2) -> 2 obj.x -> 1
となる。
add1はthis.xにたいして演算をしている。つまり返された値が変化しているんだ。
add2は関数fxに閉じ込められた値に対して演算している。つまりこれらは別の値なんだ。
とここまでかいたら疲れた。
読んでくれた人ありがとう
ちゃんとまとめてなかったし、自分のブログに描いても見てくれる人はいないから増田に書いてみたよ。
ほかの言語や技術についても同じような解説が欲しかったら何らかの方法で言及してくれるとうれしいな。
ここまではてブが300突破してるみたいだけどいま、自分のブログへリンクを張ったら増田に書く意味がなくなるんじゃないかと思うんだ。
やらないけど。
こんなのもかいてみたよ、増田で。 http://anond.hatelabo.jp/20070621153600
JavaScriptなんでどうでしょうか。
べつにAJAXを書くとかそういう訳じゃなく、
「7時ですよ。朝早くからお疲れ様です(^^)」って時代のやつ。
ある程度HTMLの知識が必要になってくるけど、
変数の宣言とかその辺に関してはだいぶ緩いし
ファイルを扱うのはややこしいけど
文字列の入出力はフォームで簡単にできるし
とりあえずフローチャートを書きさえすれば
あとはわりと何も考えなくても使えるっつー点で
プログラミングに慣れるのに向いてると思います。
慣れておくと後々楽だと思います。
追記：タイトル改訂しました。こんどこそ大丈夫かな…？
【コラム】そろそろきっちりJavaScript 第1回 "Firebug"の導入〜関数リテラルとは? (MYCOMジャーナル)
多彩な演出効果をカンタンに導入できる事で脚光を浴びたprototype.jsの登場を皮切りに
のっけから間違ってて読む気なくす。冒頭くらいちゃんと調べて書こうよ。prototype.jsのどこを読めば多彩な演出効果なんて出てくるんだ。使ったことないだろ。多彩な演出効果はたぶんprototype.jsベースのScript.aculo.usのことだ。prototype.jsが流行ったのはいろいろあるけど、主としてAjax.*の存在が大きい。
function mtof(x) { return x*3.2808399 }
mtof(3)
;書こうよ。そりゃなくても動くけど、初学者向けの解説としてはダメだろう。タイトルも「きっちり」なんだし、Rubyで;ないのとは意味が違う。思わぬところでハマったりするよたぶん試したことないけど。
ちなみに仕様的には、「セミコロンを補完可能なら補完する」なので、補完不可なら補完できずエラー、そもそも補完ってことはセミコロンついてるのが正規の状態って意味だろう。何にしろ;なしで改行してるの見ると気持ち悪い。
*{ margin : 0 }はもう古い！？ | Emotional Web
はてなブックマーク - *{ margin : 0 }はもう古い！？ | Emotional Web
はてなが酷い。
base.cssとかcommon.cssとかを書いて読み込ませるのは、何のためだったか考えてみよう。古い新しいの問題じゃないと気づくだろうか。少なくとも、レンダリング時間なんて完全に後付けだと洞察できるはずだ（あなたたちはjs大好きだよね）。
さて、真っ新なとこからCSS書いてくとき、どんなデザインにしろほぼ毎回指定する要素が出てくる。a img{border:none;}とかhtml,body{margin:0; padding:0;}とかだ。それなら始めにa img{border:none;}とかを羅列したファイルを用意しておけば、余計な手間が省けるじゃないか。たぶん根本の動機はこんなとこだろう。
それがいつの間にかデフォルトで適用されるスタイルをキャンセルするっていう方向へ迷走し、*{margin:0; padding:0;}なんて表現が生まれた。この指定は言うまでもなく有害で、著名なのはフォームのボタンが縮こまったり、liのネストが判別できないなどの副作用が生まれる。あまりにもすべてがキャンセルされるため、わざわざひとつずつ要素のスタイルを定義しなければならなくなって、ファイルサイズは増え可読性は下がり、冒頭で言うようにレンダリングにも時間が掛かるようになる。FireBugがない時代、この要素のスタイルはどのファイルのどの部分で指定されてるのか調べるのは本当に大変だった。*.cssをgrepしたとしても、単にul li{}とか書かれてるのがカスケーディングしてたらお手上げ。
これらのデメリットを認識したとき、はて*{margin:0; padding:0;}のメリットはなんだろうと考える。あ、特にないよね。じゃあやめよ。←いまここ
こんなのは実際にCSSを書いてたら気づくことだ。海外とか時代とか関係ない。元記事の趣旨は「*{margin:0;}は古い」じゃなくて「どんなCSSが効率的か Part2」だ。レンダリング重いから*{margin:0;}やめようなんてコピペ脳丸出しじゃ、いつまで経っても効率的なCSSなんぞ書けんよ。
＊原理主義者が「（例えば数十年後にリリースされた）UAがどんなスタイルを適用するかわからないので、最初にリセットするのは永続性完全性の観点から意味がある」と言うけども、未知のUA（というかデフォルトスタイル）まで考えてCSSを書くのはあまりに大変だ。それに、そんなことになれば、たぶん、compat.user.cssみたいなのが流行るはず。デフォルトスタイルに頼った表現がしょせん実装依存なのは認めるけど、ちょっと非現実的すぎるので、考慮から外させてもらう。俺はいま実務の話をしたいんだ。
で、元記事では、じゃあどんなCSSがいいのかって点がついで程度にしか触れられていないので、俺なりに考えてみた。
これは外せない。aの中のimgにborder付けたいってほうがイレギュラーなので、わざわざa.logo img{border:1px solid #333;}なんて書き直すのも苦にならない。例外には手作業でもって対応すべき。
ほとんどの場合、隙間を空けたいよりも隙間を空けたくない。キャンパスはフルに使いたい。
印刷時にはそうでもないので、@media print {body{padding:1cm;}}なんてのがあってもいいけど、それはまた別の話。あとそういうのは印刷するユーザー側で指定すべきだとも思う。理想論だけど。
lang="ja"な文章において斜体は不要。どうせあなたはemとかaddressとかにfont-style:normal;付けるんだから。
preやcodeがsans-serifだとイラっと来ますよね。
やられるとイラっとくるもの。個人的。
俺はページをメイリオやヒラギノやM+ FONTやVLゴシックで見たいんだよ！ お前の趣味を押しつけんな！ あと最後に一般名（sans-serifとか）くらい書け！
でもpre.2ch-ascii-art{font-family: "MS Pゴシック";}なんてのはやさしさが溢れていてとても好ましいと思う。部分的にfont-family指定するのは別にいいけど、全体のデフォルトフォントをいじられるのは不愉快でしかない。
まあ仕方ないのはわかる。解決法も知らない。けどホイールでスクロールしてるとき興味のないサンプルコードで引っかかるのはとてもムカつくんだ。俺は君のサイトが崩れてるかどうかより、いつも通りのスクロールに関心がある。
pre以外にグラフィック目的でoverflow:auto;を指定するのは論外。
「CSSは個々人のスタイルを反映してるということでしかないんじゃないの」
「そうですね」