ダーシマ・ヱンヂニヤリングスマートフォン用の表示で見るダーシマ・ヱンヂニヤリングこの広告は、90日以上更新していないブログに表示しています。高さ」などでググると、このバグに悩まされている人たちがたくさん引っかかる。現代に於いても現存していて、生きた化石と言ってもよいかと思う。このバグは再現条件が限られるし、厄介な割にはつい忘れがちなものなので、プロジェクトも終わりに差し掛かっているところで発見されることも少なくない。色々な組み合わせで発生するみたいで、どのサイトも書いてある再現条件が違う。今回は全然違った条件で引っかかりました。書かれているスタイル指定はすべて再現条件に含まれます。なんともややこしい......。超えるほどあった場合、バグは発生しない。いう複雑な条件を満たさないと発現しないバグは、気をつけていてもなかなか取りきれない。同時に指定する時は要注意ということだ。解決策いくつかの解決策がある。当たる要素から、発現条件であるプロパティのいずれかを除去すること。別の要素のマージン等で代用できるかもしれない。構造によってはこういう融通を利かせられないことがある。使うこれはなかなかスマートな手法かもしれない。指定を除去しようとする試み。30px;}これが一番楽かもしれない。指定されていた場合は使えないですね。使う手法を思いついたので採用しなかった。ピクセルを使ってレイアウトしている時に限る。}});どうしても他に対応策がないときの最終手段といえましょう。pointer;}対応ブラウザ以下のブラウザで確認済み。動くんじゃないだろうか。スタイルを調整できない。デフォルトの表現を変えたいという機会はままあるようで、このような置換テクニックが必要になってくる。要素を透明にして、上にかぶせる」というもの。これで、見た目は好きに調整できるし、クリックした時はデフォルトの動作が呼び出されるようになる。ミソなのは以下の部分。向かって左側をシングルクリックしただけでは、ファイル選択ダイアログは立ち上がらない。使って超めんどい感じに実装してたりしたので、メモった。使ってキーボード操作まで出来るようにしていた。クラス定義において、特殊なパラメーターがいくつか存在している。チュートリアル的文書ではまっさきに触れられている特殊なパラメーターだ。特殊パラメーターで、指定しておくことでクラスをインスタンス化した際に、デフォルトの値として使われるようになる。実はオブジェクトを返す関数に置き換えることもできる。メソッドが呼ばれる前)に実行される。割り振りたい時なんかに使える。なく年齢をランダムにするコードだけど、雰囲気は伝わるかと思う。直面する問題ここからが本題。クラスの継承を使っている場合、これらの特殊パラメーターは、親が持つ同名のパラメーターをうまいこと継承してくれないという問題にぶち当たる。デフォルト値を継承して欲しい。そこで継承のやり方を考えた。継承するスニペットこうです。持っているメソッドだ。あるオブジェクトのデフォルト値を設定したいときに役に立つメソッド。指定したプロパティの示す値が関数ならば実行した返り値を、そうでなければそのまま返してくれるメソッド。そんなに難しいことはしていないです。こんなふうにして、特殊パラメーターを親クラスから継承しつつ、値を設定することができた。実際のところ、以下の部分で使える。Model.defaultsModel.urlRootModel.urlCollection.urlView.eventsView.optionsView.attributesView.idView.classNameView.tagNameView.elこんな感じに出てきた。これらには、オブジェクトや文字列ばかりじゃなくて、関数が指定できるっていうことですね。知っておくと細かい融通が利かせられるようになりそう。今日はフロントエンドの仕事について考えていることを書く。フロントエンドの人間としてどのように会社と関わればいいのか、あるいはフロントエンド以外の人達に何を求めるか、そのような人たちとどうコミュニケーションをとって行ったらいいのか、などという事を中心に。結論としては、やっぱりチームとしてモノを作っている意識を、みんなで持とうよということだった。わたくしダーシマはネコメシに入る前、たぶん平均的な受託系ウェブ制作会社で2年半くらい仕事をした。フロントエンドとバックエンドが主で、ほんの少しだけディレクション業務もかじった。そこでは分業制が基本だった。ディレクターがクライアントと要件を詰め、デザイナーが絵を作り、場合によってはプログラマーがバックエンドをつくり、コーダーがコーディングをする。したウォーターフォールでプロジェクトを進めていた。一人で複数の役割を担うことはあれど、世の中のウェブ制作会社としてはたぶん当たり前の制作フローで作っていたのではないかな。実際に、このやり方が全く滞りなく遂行されていたかというと、やっぱりそんなことはなかった。前職場の強みは、ウォーターフォールの中にも更に手戻りが起こらない工夫を盛り込んでいるという点だが、それでもやり直しは発生していた。これはどうにか改善できるのだろうか。今の自分の考えでは、まあやりようによってはある程度の改善はできるかもしれないが、だいたいの部分は「しかたのないこと」なんじゃないかと思っている。開発フローのモデルはいくつもあり、それぞれ案件に対する向き不向きはあるわけだけど、案件に最も向いているモデルを選択したところで、それで仕事が完璧に滞りなく進むようになるかというとそうではない。予期せぬことは必ず起きる。予防策をはりめぐらせる方にコストを割くのかっていうと、そんなことをしだしたら本末転倒だ。ものづくりではないよね。「もはやものづくりではない。」これは大事な意識のひとつだと思う。そのような現実的な事情の中、フロントエンドの人間が一体どのように立ち回っていくのがよいのか、という話に至る。第一は、作業者になってはいけないということだ。指示されたことだけをこなすのは簡単なことなんだけれども、少しでも軽くなるようにとか、運用が容易なようにとか、再利用性を確保しつつとか考えると、目には見えない所でできることはいくらでもある。既存のサイトの修正だったら、修正箇所とは違うけどなんか不整合を見つけたので「ついでに修正しときました」というのは素敵なことだと思う。いうのを「よしなにする」ことこそ、フロントエンダーとしての(というよりむしろ、チームメイトとしての)価値なのではないか。個人的な話に逸れるけども、前職に入社し、自分がフロントエンドの部署についた時、「よしなに」とは真逆の「作業者たれ」というのが部署の空気としてあった。砕いて言うと「問題をディレクターが把握できていないのが悪い」「余計なことをすることでコーダーの価値を下げるな」のような空気。余計なことをすることで価値が下がるという理論はつまり、あれもこれもやってくれるとディレクターに思わせるなと(=コーダーの仕事単価が安くなる)いうことなんだけども、この空気は自分にはなじまなかった。「もはやものづくりではない。