「フロントエンドで普及が進むビルドツールたち」 インフラエンジニアの祭典「July Tech Festa 2014」でフロントエンドの自動化の話をしてきました。(まだ6月だけど) http://2014.techfesta.jp/
![Front-end Build Tools - JTF2014 Tokyo](https://cdn-ak-scissors.b.st-hatena.com/image/square/3d65776385e0c848a44fff7a450c9f0669b3bbe3/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F9da6bf20dc020131d9c52a008baf6e6b%2Fslide_0.jpg%3F3193297)
Google、大規模データをリアルタイムに分析できるクラウドサービス「Google Cloud Dataflow」を発表。「1年前からMapReduceは使っていない」。Google I/O 2014 大規模分散処理のフレームワークとしてGoogleが開発し、Hadoopに採用されて広く使われているMapReduce。しかしGoogleはもうMapReduceを使わず、より優れた処理系の「Google Cloud Dataflow」を使っていることが、Google I/O 2014の基調講演で明らかにされました。 GoogleのシニアバイスプレジデントUrs Hölzle氏は、「エクサバイトのスケールまで扱え、パイプライン処理を記述しやすく最適化もしてくれる。それにバッチもリアルタイム分析も同じコードで記述できる」と、Cloud Dataflowの特長を説明します。 Google I/Oの
肋骨が折れたかもしれん。痛え。それは置いといて…BigQuery。処理能力を体感したかったのでとりあえずMySQLの本番データをつっこんだ。fluentdでログも突っ込んでるんだけど、そっちはデータが溜まってないからまだおもしろくないかな。それについてはまた別途。まあ、fluentdでデータ突っ込むのはいろんな人がqiitaとかブログに上げてるし書くまでもないかもしれないけどね。 0. 作業の流れ MySQLからダンプを抜く ダンプをCloud Storageにuploadする Cloud Storage からbigqueryにインポートする クエリ投げる という流れになる。この記事では深く言及しないが、Google Compute Platformのコンソールでプロジェクトの作成やら課金の登録やらが済んでいて、作業を行うマシンにはコマンドラインツールがインストール済みであるとする。 コマ
Ctagsを使って、クラス名や関数名のインデックスを記述したtagsファイルを作っておくと、vimでキーワード上にカーソルをおいて、<C-]>を打つと、そのキーワードが定義された場所に飛んでくれて便利。 しかし、新たにキーワードが増えるたびにctagsを手動で実行するは面倒なのでGitのhookを使うことにする。 また、複数のプロジェクトがあるとき、各プロジェクトごとにtagsファイルを分けておくと、余計な候補が出なくてよいが、うまくやらないとプロジェクトを変えるたびに:set tagsでtagsファイルの指定を変更なくてはならないし、tagsファイルをGitのディレクトリ以下に置くと、.gitignoreで無視してやらなくてはならなかったりするので、その辺を解決させる。 まぁ、vimプラグインで有名なtpopeのtbaggery – Effortless Ctags with Git設
追記 RailsでJS辛い問題に関しての結論:http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptがRailsから独立している Railsはとても堅牢。 モデル、コントローラ、ルーティングと、変にいじらない限りはほとんどテストが要らない。 必要なのは、モデルに新たにpublicメソッドを付けたときくらいだろう。 実際、バックエンドはそうそうバグが出ない。
全国でしょっちゅうGoogle APIの変更に踊らされている皆様こんにちは 大橋です。 I/O見てましたか 楽しかったですね Google API好きにとっては前半しんどすぎましたが(白目 さてI/Oの裏でひっそりとGmail APIが公開されました。 今まではIMAPを利用した通常のメールやり取りか、GmailのInboxのみを触れるGmail Inbox APIしかなく、 Google Apps ScriptでのみGmail周りをAPIとして触れる状況が続いていました。 今回のGmail APIは * 基本的にクライアントを選ばないREST APIベース * 認証周りはOAuth2 と非常に扱いやすいAPIとなっています。 では今回はこのGmail APIをクライアント側のJSから触ってみたいと思います。 ものすごくすぐ試したい方は「API Explorer」を使うと良いと思います。
1 pixel|サイバーエージェント公式クリエイターズブログ サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。 はじめまして。 アメーバ事業本部 クロスイノベーション室のグンタ(@gunta85)と申します。 今回はフロントエンド開発用の、 ありとあらゆる依存関係を簡単に解決してくれる、 WebPackというスグレモノをご紹介します。 導入経緯大きなアプリを開発するにあたり、依存関係を解決してくれるものを探していました。 その中で、RequireJSやBrowserify、Componentなども候補に挙がりましたが、 諸々の理由でWebPackを選びました。 特徴の違いについては「WebPack vs Browserify」等で検索してみると良いかと思います
Material Design Google I/O 2014 で新しいデザインガイドラインが発表されました。 Google Design その中で注目されるキーワードが「Material Design」です。これは直訳すると「素材のデザイン」という感じになりますが、これは現実世界の素材をメタファーとすることでユーザーにとってわかりやすくなるように考えられたデザインのようです。 ということで、Material Design について簡単にまとめつつ、どうやってデザインを始めていけばいいか考えていきたいと思います。 Google Design のガイドラインを個人的に解釈した内容を掲載しています。誤解などありましたらコメント欄にて連絡ください。喜んで修正します。 イントロダクション まずはじめに Material Design の概要です。本文をそのまま引用します。 We challenge
キャッシュでレンダリングコストケチっていかないといけないようなことになってる時点でビジネスとして成立してないので撤退を検討したほうがいいと思う。 殆どスタティックな記事を配信して動的な部分は JS でやるとかあるけど、結局それってサーバー代を使わないかわりに膨大なエンジニアリングコストを使うことになる。意味ない。 予想外の形でサービスがヒットした結果酷い状態のコードをなんとか飛ばし続けないといけないこともあってその場合はとりあえずキャッシュを導入して時間かせぎをしつつビューをまともにしていくとかそんなことになると思う。けどその場合そこに「戦略」なんてものがあることはなくてひたすら泥縄的な対処が繰り広げられる。 何か問題がある時にとりあえずキャッシュで本質的な解決が得られるということはないので、データ構造を直していくとか、よい CPU を買うとかもっと本質的な解決法が重要。重ねて言いますがよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く