最近のビルドツールって何なの？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
TypeScriptでは、コンパイルが必要です。プログラムをブラウザーとNode.jsの両方で使おうとすると、さらに加工が必要です。ミニファイだの文書も作るだのすると、ちょっとしたビルドプロセスとなるので手作業では辛くなります。 今更Makeでもないよなー、と思い、最近のビルドツールを試してみました。 内容： 流行りすたりが激しすぎる gulpを使ってみる：こんなサンプル gulpのビルドスクリプト タスクランナーってのはビルドツールとは違うのか？ ビルドツールは進化したのか 参考資料： 例題のファイルとコマンドの一覧 ソースファイル 追加の話： gulp問題ひきずり：ウォッチがまたおバカ過ぎる 流行りすたりが激しすぎる 「確かGruntってツールがあったよな」と、インストールと使い方を調べていると、やたらにgulpって単語が目立つんですよね。Gruntのライバルの新興勢力らしいです。 「
本日のtip その2：アーカイブにゴミや見せたくないファイルを入れない方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっとしたtipでも「ヘーッ」と思う人もいるようなので書いてみます、その2。Unix/Linux/Cygwin/MSYSとかでの話、GNU tarね。 tarは単一のファイルをアーカイブすることもできますが、普通はディレクトリを丸ごとアーカイブするでしょう。アーカイブに入れたくないファイルがあるとき、tarの--exclude=pattern、--exclude-from=file オプションを利用できます。patternはファイル名パターンで、シェルのワイルカード'?', '*'が使えます（ブレイス'{'と'}'は、期待通りには機能しませんから事実上使えません）。 例えば、 $ tar --exclude='*.tmp' -cvf ../archive.tar . とすれば、*.tmp という名前のフィイルはアーカイブに入りません。--exclude='*.tmp' の代わりに --e
WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記 (はてなBlog)
分散バージョン管理システムの利用は拡大しています。そのなかでも最も人気のあるツールはGitでしょう。しかし、GitをWindowsで使うのはなかなか困難でした。 Windows向けのGitであるmsysGitは、bashのコンソールを出して、最小限のUnix風コマンドライン環境を提供するものです。これは使いやすくありません。もう一つの選択肢であるTortoise Gitは、Windowsのエクスプローラー（ファイルマネージャ）に統合されたGUIツールですが、僕は「なんか違うな」と感じてました -- これは個人の感性の問題ですが、ファイルマネージャに横付けすることが、分散バージョン管理システムへの良いUIを提供するようには思えないのです。 ところが、最近は事情が大きく変わっています。使いやすいGUIツールとして、2013年6月に正式公開されたSourceTree for Windowsが存在
ブラウザが消滅して： APIベースのWeb - 檜山正幸のキマイラ飼育記 (はてなBlog)
「僕らが大好きだったWebはなくなるのかもしれない」において、「Webページ／Webサイトから構成される従来型のWebはなくなるのではないか」と述べました。 ここで、極端な想定として「Webブラウザが消滅してしまった」としましょう。これは、あくまで想定であって、未来予測をしているわけではありません。 汎用のブラウザに代わるのは、個別の機能を持ったアプリ群です。これらのアプリ（の多く）は、通信のインフラとしてインターネットを利用するので、インターネットはやはり必須で重要な存在です。 ブラウザがなければ、Webページから構成されるWebサイトは意味を持ちません。Webサイトはアプリのリモートバックエンドに置き換えられ、Webページはアプリの状態に取って代わられます。 アプリとそのリモートバックエンドは通信をするのでプロトコルが必要です。そのプロトコルは、HTTP（の発展形）がやはり主流でしょう
bitbucketはもう信用する気になれない - 檜山正幸のキマイラ飼育記 (はてなBlog)
bitbucketは、分散バージョン管理システムのリポジトリと関連機能をホスティングしているサービス。Catyの開発にはずっとbitbucketを使ってきた。細かい不満はあるものの、「これはダメだ」というほどの問題点は感じていなかった。だが、最近の変更は酷い。それについては、既にKuwataさんが書いている。 http://return0.info/note/2012-10.html#id2012-10-10 http://return0.info/note/2012-10.html#id2012-10-19 Wikiの記法が、WikiCreoleからMarkdownに変わったのだが、互換性への配慮が一切されてない。ユーザーが今まで貯めこんできたデータが壊れる事態もヤムナシという判断らしいが、ヒド過ぎる。具体的に言うと、過去にWikiCreole記法で書いた（イシュートラッカーの）イシュー
マイクロフォーマット(microformats) vs. マイクロデータ(microdata) - 檜山正幸のキマイラ飼育記 (はてなBlog)
「マイクロフォーマット（microformats）の蹉跌と希望」において、マイクロフォーマット（microformats）のデータモデルもマークアップも曖昧すぎて、どうもダメな感じだと指摘しました。しかしそれでも、次の点はマイクロフォーマットの優位点だと僕は思います： 今ある技術だけですぐさま出来る、新しいナニカを必要としない。 CSSデザインとの相性がよい。 hCard、hCalendarなどのスキーマが既に存在する。 特に最後の「スキーマのレパートリーがある」という点はとても大きな魅力です。もっとも、スキーマ記述言語がない（しいて言えば自然言語）ので、スキーマって概念も曖昧な状態ではありますが。 「マイクロフォーマット（microformats）の蹉跌と希望」のコメント欄にて、神崎正英さんより「microdataはどうか」というヒントをいただきました。Kuwataさんも「microda
論理的であるかのごとくに装って、根拠のないイチャモンをつける 13+2 の方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと挑発（コレの最後）してみたけど、どうせ反応はないだろな。しらけてしまわないうちに自分でテンション上げて解説を書いてみました。 内容： 前がき 本編 定義の違いを真偽の議論にすり替える 言ってもない事を否定して印象操作をする 傾向や量に関する主張に、勝手に全称限量子を付けてしまう とある階層でなされた主張を、別な階層で否定する 権威や前例に訴える 権威や前例に訴える 別バージョン 論点ズラシ、意図・論点の曲解 論点ズラシ、意図・論点の曲解 感情バージョン 意味もなく自分の経験や知識を強調 問題点を他の事情により帳消しにする 意味不明でもいいから難しそうなことを言ってみる 普通とは異なる解釈を持ち出す 反論されたときは最小コストでごまかす 余計なお世話な悪口も辞さない 言い張る 後がき 前がき すぐあとに続く「本編」では、ホントに「根拠のないイチャモンをつける方法」、もう少し正確に言う
論理的言明を装った感情論は嫌い、という感情論 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと時間がたってしまったネタですが： プログラミングの出来る人と出来ない人の決定的な違い。 「プログラミングの出来る人と出来ない人の決定的な違い」？ ワンヤグさんの「プログラミングの出来る人と出来ない人の決定的な違い。」は、たくさんのブックマークを集めた記事。それに対して、id:JavaBlackさんが随分と否定的な記事を書き、さらにワンヤグさんが当該記事への追記として反論（らしきこと）を書いています。内容的に、ドチラかが全面的に正しいとは思えないし、ドチラかに味方する気もありません。 ですが、僕のセンサー（どんなセンサーかは最後に述べます）が反応したので、思うところを書いておきます。 時間順が前後しますが、まずはJavaBlackさんの記事のほうから。僕は、元記事「プログラミングの出来る人と出来ない人の決定的な違い。」を読む前に、JavaBlackさんの記事のほうを先に読んだのです。
Webサービスを設計するための単純明快な方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサイト」、「Webアプリケーション」、「Webサービス」、「Web API」などの用語の区別はそれほど明確でもないし、きっちり区別して使うのもめんどくさいので、ここでは、これらを総称してWebサービスと呼んでしまうことにします。 山本陽平さんは、その著書『Webを支える技術』のなかで、人間がブラウザを使って利用するWebサイトとプログラム向けのWeb APIを区別すべきではないと述べています。この点は僕もまったく同感・同意です。 人間が相手となると、視覚的な効果や装飾、JavaScriptを使った操作性などにフォーカスが向けられ、Web APIとはまったく別物のような印象を与えます。しかし、各ページが持つべき情報やページ遷移の有向グラフ構造などは、相手が人間でもプログラムでも同じだと思うのです。そんな事情で、Webページの機能的／情報的なエッセンスを表現したHTML文書をクリーンH
RESTfulなWebサイトと拡張子を含むURLについて - 檜山正幸のキマイラ飼育記 (はてなBlog)
2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
JavaScript大域変数の存在確認 - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記]id:zorioさんのブックマークコメントの指摘により、抜けていた「.apply」を挿入しました。[/追記] JavaScriptで、大域変数（大域オブジェクトのプロパティ）fooが存在しないときに何かをしたいとしましょう。例えば、こんな書き方をしますよね。 if (!foo) { // 何か } でも、式 !foo は、fooがnullでもfalseでも0でもtrueに評価されます。 if (foo == undefined) { // 何か }としたほうがよさそうです。が、null == undefined もtrueとなるのであまり改善されてません。 if (foo === undefined) { // 何か }イコールが3つなら、厳密に「fooが未定義値であるとき」を表現します。ここで、undefinedはリテラルではなくて、仕様として事前に定義されている大域変数です。u
JavaScript用のアサーションを作ってみる - 檜山正幸のキマイラ飼育記 (はてなBlog)
ここで触れたシステム、ある程度は動くので、サンプルを作り始めました。すると、あれまー、随分とバグがあるなー。 これは全面的に僕の監督責任ですわ。そもそもが、 たぶん、こうだから、 おそらく、こうすればよくて、 うまくいけば、あーなるはずだぜ。 みたいな方針しか言ってないし、「防衛コードを書くな」といったアドバイスも説明不足でうまく伝わらなかったようです。 内容： 防衛コード、うざすぎ 防衛と契約（コントラクト）は違うんだよ アサーションを使えばこうなる 安直なアサーションを作ってみる ライブラリコードとビルドシステム ●防衛コード、うざすぎ 防衛コードに関して言えば、歴戦の勇士のような職業プログラマが「俺は誰も信じねー！」みたいなコードを書くわけですよ。 function sum(x, y) { var objectUsed = false; if (x === undefined) {
檜山正幸のキマイラ飼育記 - プログラマのためのJavaScript (0)
ジジイの手習いで、JavaScriptを勉強中でございます。その動機は「結局、ブラウザベースRIAかよ」のようなこと。非ブラウザベースのリッチクライアントへの期待を失ってしまったんですね。短期的・現実的な策としては、Ajax的な手法によるRIAなのかなぁ、という気分。ただし、「短期的」が“1年”と“5年”ではえらい違いです。今のところ僕には、「短期的」の実際の期間はわかりません。 僕のJavaScript調査の結果は、「初心者でも使えてプログラマでも困惑するJavaScript 」などに書きました。これらの続きとして、「プログラマのためのJavaScript (*)」というタイトルで書こうかと予定してます。あくまで予定、気まぐれでモノグサな僕のことだから、…… “プログラマのための”というのは、C, C++, Java, C#など“普通の”プログラミング言語にある程度慣れていることを前提に
プログラマのためのJavaScript (2)：融通無碍な型システム - 檜山正幸のキマイラ飼育記 (はてなBlog)
JavaScriptは「型のない言語だ」と言われています。これは、変数に型を宣言する必要がない（現状ではできない）ことです。しかし、データには型があります。よって、データの分類体系としての型システムもあるはずです。とはいえ、ホレッ、JavaScriptのことですから、型システムも“どうとでもとれるような（解釈の任意性がある）”曖昧な分類体系ですね。よくいえば融通無碍＜ゆうずうむげ＞、有り体＜ありてい＞にいえばエエカンゲンですわ。 ●とっかかりはtypeof演算子 （[追記]： typeof演算子をtypofと書き間違えていた（で、直した）。こういうのはtypoofと言うのだろう:-) ） typeof演算子（関数ではありません）の引数に、定数リテラル、変数、式（expression）などを指定するとその型（の名前である文字列）を返してくれます。 js> typeof 123 number
もう一度、ちゃんとJSON入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
シェルのリダイレクトを「こわいものなし」というくらい完全に理解しよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Java BlockingQueueで遊ぶ：パイプラインごっこ」でパイプラインの話をしたので、本来の、つまりUnixのパイプやリダイレクトを少し調べてみました。 たまに話題となる some-command >file 2>&1 と some-command 2>&1 >fileの挙動の違いについて、「シェルはコマンドラインリダイレクトの指定を右から左に解釈実行する」なんて説明が見つかりました。んなバカな！ パージングは左から右にするものですよ。パーズツリーを逆順にたどることはできるけど、そんなことする必然性はなんにもないよ。 次の記事を読むと、「右から左」なんて事情じゃないことが分かるでしょう。 UNIXの部屋 検索: リダイレクト シェルのリダイレクトにまつわる失敗 さてここでは、複雑なリダイレクト処理も完全に理解できる処方箋を示しましょう。例えば、次のコマンドラインが何をするか分かる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
