You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
![「フロントエンドデベロッパー面接時の質問事項」への解答](https://cdn-ak-scissors.b.st-hatena.com/image/square/1ef26f6cb4349557952890dbe3e567f7f98dc151/height=288;version=1;width=512/https%3A%2F%2Fgithub.githubassets.com%2Fassets%2Fgist-og-image-54fd7dc0713e.png)
#フロントエンドデベロッパー面接時の質問事項 @バージョン 2.0.0 本レポジトリはフロントエンドデベロッパー志願者のポテンシャルを見極めるのに有効な面接時の質問事項を列挙します。全ての下記質問事項を一人の志願者に聞くことは推奨されません(それは数時間もかかってしまうでしょう)。あなたが必要としているスキルを見極めるためには、下記の質問リストからいくつかの項目を選択するのがよいでしょう。 Rebecca MurpheyのBaseline For Front-End Developersもとても参考になるので面接前によく読むことをおすすめします。 注意: これらの質問の多くはオープンエンド型の質問であり、志願者から興味深い考えを引き出すことができるでしょう。この回答は単純でストレートな回答よりもより志願者の能力を見極めるのに役立ちます。 オリジナルのコントリビューター 質問の多くはPaul
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。 しかし実際は、悪い意味で期待を裏切られることになりました。 Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。 全く動かなくなってしまう原因は単純(後述)だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない!! と思いました。 フロントエンドの想定外 ウェブサイト
この記事は第2のドワンゴ Advent Calendar 2017 22日目の記事です。 ドワンゴでニコニコ生放送のWebフロントエンジニアをやっています、 @misuken です。 はじめに ここ1年半くらいは、主に ViewComponent(VC) と ContainerComponent(CC) 周りのアーキテクチャ設計、コンポーネント設計、実装を担当しています。 生放送のHTML5プレーヤーなどを開発してきました。 第1回 ニコ動/ニコ生 HTML5化への奮闘~ドワンゴ流動画配信サービスのつくりかた~ 今回はニコニコ生放送のViewComponent周りがどのように作られているのかを紹介したいと思います。 内容としては大体こんな感じです。 VCを中心とした設計から実装の流れ CSS Modulesを使いつつコンポーネントとデザインを柔軟に組み合わせられる仕組み ニコニコ生放送のコ
ここでは、フロントエンド開発の概要について説明していきます。 *元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。
お世話になります、フロントエンド担当をしている小原正大です。Webページの表示を監視して差異があった場合、どのページで表示の変化が起きているかを知ることが出来るプログラムを実装したのでそのことについて書こうと思います。 何につかったの? 僕がフロントエンドを担当しているサービス『料理サプリ』で大規模なフロントエンドコードのリファクタリング行う際に表示テストを自動化するために作成しました。『料理サプリ』はPC・スマホ合わせて大体350-400ページの表示パターンが存在する比較的規模の大きいサイトです。全ページに影響を与えるような作業は大規模な回収となり、今回のリファクタリングでは表示テストの計画などの段取りが必要でした。従来の人手によるQAでは細かいバグを見過ごしたり時間がかかり効率が悪いので、可能な限り自動化しようと考え実装しました。 実装の概要 この監視のシステムは以下の2つ実装を組合わ
趣味で作ったwebサービスのリポジトリをgithubに公開して2ヶ月くらい フロントエンドのソースが雑だったので、リファクタリング中にした対応を紹介 前記事:Go + react + ansibleでサービスを作ってOSSにしてみた http://qiita.com/wheatandcat/items/66d72445ad0c5df2a8be github 記載している内容は、下記のリポジトリに取り込み済みの内容です。 うまく動かなかったら、こちらから動きを見てもらえたらと思います。 ■dotstamp_client https://github.com/wheatandcat/dotstamp_client flow javascriptでも型が使えるようになるライブラリ。 ファイル単位で実装していけるから、稼働中のプロジェクトでも柔軟に導入していけるのが魅力。 導入的にはファイルの頭に
モバイルWebのUIを速くする基本テクニックがわかる──Google I/O 2016 High Performance Web UI 川田寛(ピクシブ株式会社) こんにちは、ふろしきです! 私はHTML5 Experts.jpで、過去2年ほどGoogle I/Oの情報を発信し、Web技術の変化についてお伝えしてきました。振り返るとGoogleは、2014年にモバイルWebの提唱と技術要素の拡大を図り、2015年からは「RAIL(モバイルWebが目指すべきパフォーマンス指標)」や「Progressive Web Apps(アプリのように振る舞うWeb)」といった、モバイルとの親和性が高いWebを作り出すための”考え方”を推し進めました。今年2016年は、さらにそれを踏み込んでいったという感じがします。 今回のI/Oで取り上げるのもそのひとつ。毎度お馴染みGoogle Developer A
LTを聞いているという感覚でご覧ください。 Qiita:Coat Qiita用のUIコンポーネント集 GitHub用のUIコンポーネント集をForkしてつくりはじめた レポジトリ: https://github.com/increments/qiita-coat デモサイト: http://increments.github.io/qiita-coat/ 今週月曜からやってる これはcommit数 Qiita:Coatが必要に感じた背景 全ての開発者に共通する願い 高速に開発したい 秩序がほしい (a.k.a. 最低限度の品質の保証) 開発体制の情勢に起因する理由 開発人数が徐々に増えつつある 社員11人+アルバイト3人 四半期に1人ぐらい増えてる 50人が51人になるとかならともかく、5人が6人とかになると大きく変わる その他の理由 サポートサイトや採用サイトなどQiita風のデザインを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く