フロントエンド「エンジニア」とは何か? - nobkzのブログ
フロントエンド「エンジニア」 僕は、良くフロントエンドのコミュニティに顔を出していて、フロントエンドの動向などの情報を交換を良くしているのだが、最近、というか昔から、同じフロントエンドエンジニアでも技術的関心事が全然違う事に気がつく。 同じ技術的な領域であるはずにも関わらず全然違う事を話しているのだ。なぜこのような事が起るのだろうか? 今回の記事はそのことについてだ。 なぜ彼らは「フロントエンドコミュニティ」に集まっているのか? なぜ、彼らはフロントエンドのコミュニティを形成しているのかを記述していきたい。 フロントエンドがなんなのか漠然としている アンカンファレンスなんか開いていたりすると毎回の如く「フロントエンドエンジニアとは何か?」という話題が出てくる。そういう話題が出てくるというのは、そもそも「フロントエンドエンジニア」がどういうものか曖昧であり共通認識が無いからだと考えている。
jQueryはNGと言われた時の便利なメソッド - Qiita
とあるお仕事で、jQueryなどのライブラリー利用不可というものがありました。その際利用した、jQuery的に使える便利なメソッドをメモしておきます。（※ 昔使っていたものを引っ張りだして改善したものなので、どこかで公開されている可能性があります） 更新 addClass,removeClassを修正致しました。 元記事 下記エントリの転載になります。 jQueryがNGな時に備えて、用意しておきたい便利なメソッド イベントリスナ jQueryでいうところの、.on() に該当するものです。 "addEventListener" か "attachEvent" かを判定し、addEventメソッドを定義しています。 var addEvent; if (window.addEventListener) { addEvent = function (target, name, fn) { if
フロントエンドできない人が、フロントエンドやりすぎだ。あと、Vanilla.jsが便利だ。 - nobkzのブログ
最近、なんというか、フロントエンド勉強会に出席する度に、「フレームワークじゃねぇんだ! MVC設計がな! 」とか言い続けている気がする。たくさんフレームワークが出てきて、○○フレームワークの問題とか、開発の困難の話を聞く度に、自分の設計を棚に挙げて、「これは、フレームワークがスケールできないせいだ!」「jQueryが糞」とか言ってて、「何言ってんの?コイツ?」みたいな気分になる。 最近になって、なんでこの状況がいつまでたっても変わらないんだろう? って理由が分かってきた。フロントエンドできない人が、フロントエンドやりすぎなのだ。 なんでフレームワーク使うの? そもそも、なんでフレームワークを使うか?ってことに答えられない人が多い気がする。というか、大抵「上司が決めたから」とか「チームで決まっているから」という答えが返ってくる。そもそも、フレームワークを強制して学習させる環境になっている現場
Rails 4のturbolinksについて最低でも知っておきたい事
Rails 4のturbolinksについて最低でも知っておきたい事 （追記）turbolinksに関するセキュリティ上の懸念について turbolinksとは、ページ遷移をAjaxに置き換え、JavaScriptやCSSのパースを省略することで高速化するgemで、Rails 4からはデフォルトで使用されるようになります。 高速化は大歓迎なのですが、JavaScriptのイベントの起き方が変わるため、Rails 3までの書き方をしているとまず間違いなく問題が起きます。しかも、Rails 4ではデフォルトの機能ですので、最新版を使いたいなら必ず知っておかなければいけません。 本エントリではturbolinksを使うために絶対に知らなければいけないことを分かりやすく紹介したいと思います。 動作 turbolinksの動作は、すごく大雑把に言うと以下の通りです。 リンクのclickイベントをフッ
小さく始める JavaScript のテスト - Qiita
書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通にこのスクリプトを node/io
大学でフロントエンドエンジニアは評価されない | Kimamass News
大学の課題で milkcocoa を使って、マウスカーソル共有協力プレイ Web サイトを制作しました。 Endless Doors そして、そこで発表したプレゼン資料がこちらになります。 その授業でちょっと思うことがあったので、書いていこうと思います。 まず、その講義について。 基本的にその講義は HTML をほとんど書いたことがない人が半数以上受講します。 WWW とは何かの解説から始まり、Unix コマンドについて、HTML について、そして PHP, MySQL と続いていきます。CSS, JavaScript に軽く触れたりするものの、授業の大半が PHP, MySQL となっていて、Web がサーバーサイドとデータベースで成り立っているということを認識させる授業です。 ところで私は生粋のフロントエンドエンジニアです。デザイナーでもなければ、バックエンドもやっとここ最近
10年間JavaScriptをコピペしていた僕がJavaScript本格入門して知った驚愕のJavaScript言語仕様覚書 | niwatako$
JavaScriptをなめていた私が勉強しなおした結果、色々驚愕の事実が発覚したお話。JavaScriptをご存じの方には当然の内容かもしれません。 むかしむかし 私にとってJavaScriptといえば、高校生時代(10 […]
超簡単に3DCGできるJavaScriptライブラリ作った - aike’s blog
ブラウザでWebGLが使えるようになって3DCGプログラミングはずいぶん身近なものになりました。と書いてるそばから違和感を感じるくらい生のWebGLをJavaScriptで書くのは敷居が高かったりします。できなくはないけど前提となる知識がかなり必要な感じ。 three.jsが登場したときは、これで普通に3DCGができるということで一気にひろまりました。とはいえ、それでもまだやることは多く、画面に四角い箱を表示する場合以下のようなプログラムを書くことになります。 ・シーンを作成 ・ライトを作成、位置と向きを設定、シーンに追加 ・カメラを作成、位置と向きを設定、シーンに追加 ・マテリアルを作成、色を指定 ・BoxGeometryを作成、サイズを指定 ・メッシュを作成、位置と向きを設定、シーンに追加 ・レンダラーを作成 ・レンダリングループ処理 これらのひとつでも間違えたりパラメーターが適切でな
仕様の決まる速度で実装する - mizchi's blog
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
最近の行儀のよい JavaScript の書き方 - Qiita
JavaScriptは移り変わりの早い言語です。 もう1年以上経っていますし、記事のメンテもちゃんとできていないので、消し線を入れることにしました。 参考程度のために記事は一応残しますが、より新しい情報を読まれることをお勧めいたします。 はじめに --- 最近では JavaScript の実行環境はブラウザに限りません。（node.js, Web Workers） また、旧来のような <script> 経由でのロードもとうに古くなっています。今は CommonJS スタイルで、require を用いたモジュールのロードを行なうことがより良いとされています。 ですから、次のようなことは改める必要があります。 - var YourModule = {}; などとして、外部から YourModule.hoge(); などと呼び出す書き方 - this === window だと思うこと 今回は、
Nginxを改造して欲しかった画像サーバーを作った | nonomura.jp
スマートフォンサイトに向けての最適化だったり、 Webページのレイアウトの変更だったりで、 同じ画像でも様々なサイズを利用することがある。 サイトの運用を続けていると、 同じ画像でも数通りのファイルを保存していて、 ファイル数が大量になってIOがキツくなってきた。 数多くなるとIO辛いから、 ファイル増やさないように気をつけてね、 と社内で言い続けていたら… Webサイトでは、本来小さい画像で良いところに 大きい画像を使用して、 JavaScriptでリサイズする処理が多用されはじめ、 今度は転送量が増加しはじめて、 これ以上増えるとデータセンターの月額費用が 増加してしまいそうに…。 なんとかせねば！と対応をはじめるわけです。 そこでまず最初にやったのが、 本当は速いImageMagick と同じように、Apacheモジュールを自作して、 ImageMagic
【翻訳】リッチなWebアプリケーションのための7つの原則 - from scratch
はじめに この話はGuillermo Rauch氏が書いたhttp://rauchg.com/2014/7-principles-of-rich-web-applications/ という記事の翻訳です。許可を得て翻訳しています。 ここ最近Web業界を賑わしているSingle Page Applicationの必要性、HTTP2/SPDYといった技術、リアクティブプログラミングやIsomorphicデザインという考え方について包括的にまとめたすごく良い記事になっております。 最初に断っておきますが、ものすごく長いです。各セクションがわかれているので時間がない方はセクションごとに書かれたtl;DRとまとめを読むだけでも参考になるかと思います。 ちなみに明日のNode学園祭には、本記事を記述したGuillermo Rauch氏が見えるので、そこで詳しく聞いてみるのもいいのではないでしょうか。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
