食べログのフロントエンドエンジニアってめっちゃ大変やねん･･･
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
「フロントエンド開発に再入門する」タスクフォースの進め方 | MEDLEY Developer Portal
2017-11-09「フロントエンド開発に再入門する」タスクフォースの進め方こんにちは。開発本部の宍戸です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（タスクフォースと呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分
GraphQL概要（React Europe2015での発表の簡易まとめ） - Qiita
GraphQL Lee Byron - Exploring GraphQL at react-europe 2015 - YouTube React Europe 2015内でGraphQLのworking draftとGraphQLサーバのtechnical previewの公開が発表されました。GraphQLのアイデア自体は以前に発表されていたようですが、今回のReact Europe 2015で初めて具体的な仕様と実装が発表されました。 GraphQLはFacebookが開発した、クライアントとサーバ間のデータのやりとりを簡単にするための言語です。 言語だけではなく、GraphQLを使うクライアントとサーバの仕様も含んで「GraphQL」と表現していました。 参考資料 GraphQL GraphQLのworking draft graphql/graphql-js GraphQLサー
Node.jsでのJavaScriptメモリリークを発見するための簡単ガイド | POSTD
目次 初めに 極小理論 ステップ1. 問題の再現と確認 ステップ2. 最低3回のヒートダンプ採取 ステップ3. 問題の発見 ステップ4. 問題解決の確認 他のリソースへのリンク まとめ Something you might want to bookmark: Simple Guide to Finding a JavaScript Memory Leak in Node.js by @akras14 https://t.co/oRyQboa8Uw — Node.js (@nodejs) January 6, 2016 注釈：お気に入りに登録してください。 Simple Guide to Finding a JavaScript Memory Leak in Node.js （Node.jsでのJavaScriptメモリリーク発見簡単ガイド） @akras14 http://www.ale
Scala.jsが凄い - mizchi's blog
タイトルで嫌な予感がしてる人もいるでしょうが、ScalaがJSに変換されて動きます。やったぜ。 Scala.js http://www.scala-js.org/ 試す このサンプルプロジェクトを git clone するのが良いです。 sjrd/scala-js-example-app https://github.com/sjrd/scala-js-example-app サンプルコードはこんな感じ package example import scala.scalajs.js import js.Dynamic.{ global => g } object ScalaJSExample { def main(): Unit = { val paragraph = g.document.createElement("p") paragraph.innerHTML = "<strong>
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Brackets - Web デザインを認識する最新のオープンソースコードエディター