フロントエンドはブラウザの実装と普及に律速される… | Mon, Feb 20. 2017 - 氾濫原
フロントエンドはブラウザの実装と普及に律速されるので、それほど急にできることが増えたりはしない。全てのブラウザに実装がのったとしても、十分に普及するには年単位で時間がかかる。なので急いで何かを覚える必要があるってことはまずない。 破壊と再生が繰替えされてるのは、実現性に影響するようなクリティカルな部分ではなくて、便利ツールとか便利な考え方とかの部分なので、不便を感じはじめるまで評価を遅延しても良い。 ウェブフロントエンドは動きが早いように見えるけど、あれは暇な人がそういうふうに見えるようにしているだけで、実際はそうでもない。「今はこれを覚えるべき!」みたいなのが時々あるが、いいたいだけで内容がないのであまり気にしないこと。 ずっと追いかけていないと取り残されるみたいな焦燥感を持つ必要はない。人生有限なので他に楽しそうなことがあればそっちやっていくほうが良い。
ErgoDox ではないナニか。オープンソースかつ Bluetooth 接続のキーボード | tech - 氾濫原
ここ数ヶ月ぐらいキーボードを作っていた。そのためにいろいろ yak-shaving としかいいようがないことも多々していた。 いろいろ書くことが多いので、細かい設計などについては別途エントリを分ける。 コンセンプトとキーレイアウトおよび技術仕様の決定 回路設計とアートワーク・実際の製作 ファームウェアの実装 あたりをそれぞれ別途詳細なエントリを書く。だいたいの人は細かいことはどうでもいいと思うので、概要のみこのエントリにまとめる。 コンセプトや特長 UNIX ベースのキーレイアウト (というかHHKBをベース) とし、違和感なしに分割キーボードとする。 キー配列 UNIX キーボードを2分割した形を基本にする。つまり HHKB とほぼ同じで、Ctrl キーはAの左、ESC は 1 の左など。 矢印キーはどうしても欲しい (HHKB への大きな不満のひとつ) F1〜F12キーもできれば欲しい
筋の悪さ | tech - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
YAPC::Asia で「ウェブエンジニアのローレベルプログラミング」という発表をしました | tech - 氾濫原
ちょっと時間に対して話したいことが多すぎて、各分野での掘り下げが足りなかったとは思いますが、一通り下のほうまで盛りこみました。 電子工学について：自分は学校で電子工学を体系的に学んだことはありません。 YAPC 会期中はそこらへん歩いてます。
YAPC 初心者ほど YAPC にトーク応募すべき10の理由 - 氾濫原
懇親会対策 基本的にこういうイベントは懇親会が一番重要といってもいいぐらいだが、コミュ障だと懇親会とかで誰と何を話せばいいのかさっぱりわからなくなる。LT でもなんでもいいがトークをすると一定の人から認識され、トーク後や懇親会などで話しかけられやすくなる。逆に話かける側としても「あれおもしろいですね」と気軽に言いやすくていい。 また一応の話題を前もって作れるのでコミュニケーションしやすくなる。YAPC にきて「いやぁ今日はいい天気ですね」とか話はじめるわけにはいかないので、このような話題を持っておけるのは気が楽になる。 つまりコミュ障ほど応募すべき 強制的アウトプット 普段生活していると、アウトプットといってもブログになんちゃら書いて終わりがちか、あるいはそれ自体も忘れて日々バタバタ過ごしてしまう。何らかのイベントのタイミングにあわせてアウトプットを出すといいモチベーションになる。 それと
プログラムが書けない人に「仕様変更」について説明するには | tech - 氾濫原
「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう？ と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら
そこに誰かがいた #1 - 2011
後書き この写真集は、2011年にある写真コンテストに応募して落選したものを再編したものである。オリジナルはA3ノビ、40枚、全てランドスケープのものであったが、ウェブで公開するにあたり一部削除している。また、この後書きは作品説明として書いたのを再編したものである 概要 若者たちの孤独のありかたと、入れ物としての写真というのを主題に撮り、「一年」というくくりの元にまとめて作品とした。 賑やかで薄い、無自覚な孤独の中で生きているデジタルネイティブ世代の若者達に、深いポジティブな孤独を感じとって欲しい、という思いと、この写真の集まりを通じて、自分の気持ちのありようを考えて欲しいと考えた。 若者たちの孤独のありかた 「デジタルネイティブ」と呼ばれる若者たちは、インターネットを通じ対面でないコミュニケーションを使いこなし、常にたくさんの誰かと繋っている環境に身を置いている。しかしながら、対面でない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
