Google Cloud Platform (GCP)の英語ブログに、Google Compute Engine (GCE)のライブマイグレーション機能について解説記事がポストされた。個人的にもいくつかの大規模な案件でこの機能の能力に触れて、GoogleまじGoogleだなと思わされたし、GCPチームで実際に作った人たちと会うととても誇らしげに説明してくれる。熱いのだ。そこで、上記ブログ記事＋個人の経験をもとに簡単にまとめてみたい。 なお、以下の内容は個人の感想です！ Heartbleedバグの時もVM再起動なし GCEでは2013年12月より、ライブマイグレーションを利用したTransparent Maintenance（自動メンテナンス）という運用を開始している。これはつまり、VMを動かしたまま同一ゾーン内の別のサーバーへ移動することで、ハードウェアやホストOSのメンテナンスを勝手にや

@armorik83です。最近はAngular芸人とまで呼ばれ始めています1。最近の拙記事 (1, 2)を書くにあたって、AngularJS 1.x系、およびAngular 2の開発者について異様に詳しくなってしまったため、まとめて共有しておきます。誰得だろう。 「主力」は主観で概ね2万行以上の関与。敬称略。 Angular全般 印象としてはMiško Hevery氏とIgor Minar氏の二人は特筆すべきと感じました。 Miško Hevery Google AngularJS立ち上げ時主力 AngularDart立ち上げ Angular 2立ち上げ、主力 AtScriptの生みの親 Igor Minar Google ng-japan登壇 AngularJS全期間の主力 最近Angular 2に参加 AngularJS 1系 この半年ほどの1系最新版の開発者は非Googleも増えてい

JavaScript, TypeScript界隈におけるDecoratorsについて取り上げます。 JavaScriptとDecorators JavaScriptでは馴染みのなかったDecoratorsが目に触れるようになったのはAtScript発表の際だったと記憶しています。 AtScript AtScriptとは、2014年10月23日、ng-europeにて発表されたTypeScriptを包含する「新構文」です。 docs.google.com | Keynote AtScript YouTube | Miško Hevery - Keynote on AtScript at ng-europe 2014 このときの例文を引用します。 @Directive({ selector: ['[blink]'] }) class Blink { constructor(element:El

はじめに Angularの1系2系両方に対応した新しいrouterとして開発が進められているNew Routerをさわってみました。 ドキュメントやサンプルがまだ整備中ということもあり、何が必須の要素で何が必須ではないのか読み取りにくかったので、実際にコードを足したり消したりで重箱の隅をつついてみました。 ドキュメントではまだ説明されていないnested routeも試してみます。 対象バージョンは執筆時点で最新の0.5.3、AngularJS本体は1.3.15とします。 Route設定 routeの設定をするために2通りの方法が提供されています。 1つは、controllerの$routeConfigプロパティで設定するパターン、もう1つはcontrollerにDIした$routerで設定するパターンです。 これらの違いを説明する前に1点確認なのですが、New Routerではcontr

Angular 2 alpha.11, alpha.13 時点の情報です。現時点の最新版とは全く異なる内容です。現在では公式サイトのドキュメントが充実しているので、そちらを参照することをおすすめします。 昨日参加してきた ng-japan の間、Angular 2 の 5 Min Quickstart という Hello World 的なサンプルから始めて、貧弱な TODO アプリを作ってみました。感想と、その過程でいろいろハマったところを書いてみます。 まずは感想から。 別のフレームワーク？ やっぱり Angular 1.x とは別のフレームワークだなあという印象です。概念も書き方もツールも違う。ライブラリもそのまま使えない。Angular とは別の名前にした方がいいのでは、というくらいです。 現時点では、他のコンポーネント志向のフレームワークに乗り換えてもコストは同じな気がします。Ne

2017/03/01 WebサービスとしてリニューアルしてHerokuで公開しました。 QiiTrend QiitaトレンドをリニューアルしてQiiTrendを作った - Qiita データ取得方法を変更したので、長期間のデータが高速に取得できるようになりました。 サーバーサイドでデータをキャッシュしているので、一度表示したデータは次回から高速に表示できるようになりました。 Qiitaの検索オプションがそのまま使えるようになり、タグ以外の検索もできるようになりました。 以下、2015/04/06の内容 最近話題になってるReact.jsを使ってクライアントサイドだけで動く簡単なアプリを作ってみた。 ソース https://gist.github.com/tag1216/819ded0722cedf75996f デモ http://bl.ocks.org/tag1216/raw/819ded

【追記150805】さらに憔悴しないための有用な記事『アカベコマイリ | gulp なしの Web フロントエンド開発』が掲載されましたので、こちらもお勧めします。 こんにちは、@armorik83です。皆さん、Grunt / gulp使ってますか。おなじみなので、ここでは説明はしません。 この記事の要点 なぜGrunt / gulpは憔悴に至るのか、経緯と問題点 npm run-scriptの仕組みについて package.jsonにscriptを羅列することに対する是非 シンプルなgulpfileについての提言 経緯 さて、先日このような記事が界隈で広まっていました。 Grunt/Gulpで憔悴したおっさんの話 この記事については同意できるところと、そうでもないところと、両方有りました。ただ、Grunt / gulpを使っていて色々歯がゆさを感じている方は昨今増えているだろうと感じます

要約 rimrafかdelを使用しましょう。 はじめに gulp.jsにおいて、かつてはファイル削除のためのプラグインとしてgulp-rimrafやgulp-cleanが存在しましたが、どちらもdeprecateされました。gulp.srcを用いない、ファイル削除以外の余分な処理を行わない手段を用いれば、これらのプラグインを使用する必要はありません。 単一のファイル／ディレクトリを削除する rimrafを使用します。従来より、gulp-rimrafの作者が推奨している方法です。 var rimraf = require('rimraf'); gulp.task('clean', function (cb) { rimraf('./dir', cb); }); gulp.task('build', ['clean'], function() { // Something });

この記事はCC BY 3.0に基いて公開されてゐるWebサイトChoosing an OSS license doesn’t need to be scary - ChooseALicense.comのコンテンツ各ページを翻訳し、単一記事として再構成、訳者による補足を追加したものです。 2017年5月9日に開示されたコミュニティガイドラインに伴って、本記事の翻訳部分につきましては削除いたしました。 (この記事が削除または非公開化されない限り、編集履歴からお読みいただくことは可能です。) (訳註: この「はじめに」及び末尾の「訳者による補足」の章は原文にはなく、翻訳者(@tadsan)によるものです。記事の著作権表示及び元Webサイトの利用規約、免責事項、そしてこの記事についての訳者の見解について記します) (この記事の一部または全て ——ただしコメント欄は含まれない—— はCC BY-SA

React Native 概要 React.js とだいたい同じ作法で、JavaScript で書いたコードが iOS ネイティブアプリとして一応動く。そのフレームワークと開発環境を提供する。 React.js と同じ React を謳っているとおり、JSX で UI コンポーネントを定義するとか、Props や State で View のデータフローを整えるとか、setState() によるデータバインディングとか、諸々が一緒。従って React.js でアプリケーションを作ったことがあれば、学習コストをほとんどかけずにアプリが作れる･･･かも 例えば以下のように、入力値をそのまま画面にエコーするアプリケーション。 これはこんな感じのコードになる。 var React = require('react-native'); var { AppRegistry, StyleSheet, T

これ mizchi/sabizan ServiceWorkerっていう名前がサビ残っぽいよなってみんな思ってたと思う。 ServiceWorkerの勉強兼仕事で使うためのモックサーバーとして作った 用途 ServiceWorker層でビジネスロジックを持つAPIサーバー またはテスト用のAPIモックサーバー できるだけexpress風にしようとしたけどRequestのネイティブオブジェクトに値を挿入するの気持ち悪くて互換は諦めた。適当なラッパー書けば同じコードから生成できる気がしている。 どう動くか dist/sabizan.js は service worker上で動くことが必須で、他のクライアントJSと同じくbrowserifyを使うか、importScriptで読み込むことを意図している。 Sabizan = require 'sabizan' # with browserify o

続編 JavaScript - Qiitaのtextarea自動補完がOSSになりました GitHubのコメントでは@と入力するとカーソルの下に入力補完が出現する。さらっとやっているが、実はこれが結構難しい。なぜ難しいのかというと、JavaScriptではカーソルが何文字目にいるかは分かるが、 カーソルのXY座標を取得するAPIが存在しない からだ。カーソル位置が分からなければ、適切な位置に補完候補を表示することができない。では一体どうすればいいのか？ 今回Qiitaではコメント欄でのメンションの補完機能を実装した。本稿では前述の問題を解決するために用いたテクニックを解説する。 ちなみにこのメンション補完機能はチーム用プライベートQiitaである「Qiita:Team」でも勿論使える。現在絶賛無料トライアル実施中なので、興味を持たれた方はそちらも使ってみて欲しい。 要約 textarea内

最初に言っておきます。 Dartは死んでません。ただの方針転換です これが負け惜しみでないことは以下のリリースノートを見てわかってもらえれば幸いです。 1.9.1リリース！ 今朝、待望のDart1.9がリリースされました。リリースノートはこちら 今回のアップデートはECMA標準に制定した仕様の実装が完遂された記念すべき内容です。具体的には async/awaitの正式サポート enumの正式サポート が含まれています。その他にも多くの変更が盛り込まれているので1つずつ紹介します 言語仕様の変更 async/awaitサポート ついにasync/awaitが構文レベルでサポートされました。使用可能になった予約語は以下の6つです。 async await sync* async* yield yield* Future & Stream : async, await asyncとawaitはF

朝起きたらこんなページを見つけたので15分だけ触ってみた。 基本的な導入は以下にあるが、ここでは最低限動くまでメモ。 http://facebook.github.io/react-native/docs/getting-started.html 1. 準備 React Nativeを動かすには、最低限nodeとreact-native-cliが必要になる。 上記をインストール後、react-native initでプロジェクトを作成する。 $ brew install node $ npm install -g react-native-cli $ react-native init AwesomeProject $ cd AwesomeProject $ tree -L 2 . ├── AwesomeProject.xcodeproj │   ├── project.pbxproj │

はじめに どうも。 slack 内の hubot は今まで sakura vps の jenkins さんにお願いしていました。 しかし deploy のためだけに 1000yen/month はお高いなあと思って無料 ci サービスを探していたら 7kaji から wercker という ci サービスが最近話題だというので使ってみました。 その時のメモをここに記します 前提条件と、これを読んで出来るようになること 前提条件 GitHub アカウントを持っていること 既に Heroku でサービスをうごかしていること 今回は hubot です 出来るようになること github, wercker, heroku でデプロイ環境の構築 wercker 登録 まずは ci サービスに登録する必要があります。 私は GitHub アカウントを使って登録しました https://app.werc

1年程前にリリースしたモジュールなんですが、最近になって Node.jsで超簡単にスクレイピングを実装してみる - もやもやエンジニア node.js スクレイピング cheerio-httpcli の使い方 | まとめーたー とかで紹介していただいていたようなので、便乗して本人によるアッピールもしてみようかな、と。 Node.jsでスクレイピングする利点 何と言っても非同期で多数のサイトをガンガンスクレイピングできるところじゃないでしょうか。 一つのサイトに大量にアクセスするのは迷惑になるのでイカンですが、不特定多数のサイトに対してであるならば同時並行で処理できると処理時間の短縮にも繋がるかと思います。 cheerio-httpcliの特徴 WEBページの文字コードを自動判定してUTF-8に統一してくれる WEBページのhtmlをcheerioというモジュールでjQueryライクな操作が

Atom Is Now Open Source | Atom Blogによると，Atom開発のためにNode-Webkitを試してみたが利用はせず，別途フレームワーク(Atom Shell)を作成したとのこと． We experimented briefly with Node-Webkit, but decided instead to hire @zcbenz to build the exact framework we were imagining. Node-Webkitを採用しなかった理由を開発者に質問したところ以下の回答が得られた． 技術選定のタイミングではNode-Webkitは安定していなかった&分離されたコンテキスト(nodeのコンテキストとwebのコンテキスト)があった 他のプロジェクトに依存しない，完全に自由な状態でzcbenz(Atom Shellの中心開発者)に

今回はReact.jsとも関わりがあるFluxについて紹介したいと思います。 Flux is Architecture ↑の図はfacebookのfluxのリポジトリにあるものですが、Fluxは上記のようなArchitectureの名称です。facebook/fluxのrepositoryに行ってもらうとわかるのですが、実装としてはDispatcherの部分があるだけです。 Unidirectional data flow 先ほどの図を見てもらうとわかる通り、Fluxではアプリケーションの複雑さをなくすため、データの流れを一方向にします。 そのため全体の処理の流れはわかりやすくなりますが、Angular.jsなどで書くときに比べて冗長に感じることもあるかと思います。 しかしながら単純なデータの流れを作ることで、ある程度の規模になってアプリケーションが複雑化してもデータやイベントの流れがスパ

僕はIncrements(このQiitaの会社)に入社して以来、KobitoのWindows版を作っていて、その中枢の画面遷移と状態管理をライブラリとして抜き出した。それがArda。 基本的には昨日発表した https://speakerdeck.com/mizchi/real-world-virtual-dom というスライドに書いたとおり。 mizchi/arda Ardaの概要 Ardaの目的はFluxの概念をベースに、画面遷移と状態とシーンをベースにしたヒストリ管理、その際のDispatcherのコンテキスト切り替えを行うことを主な目的としている。 CoffeeScriptでの最小構成だと次のようなコードになる Arda = require 'arda' # Arda.Component extends React.Component class HelloComponent ex

@armorik83 さんの記事を受けて Fluxフレームワーク Arda が気になる10の理由 - Qiita 設計思想とか指針とか残しておきます。 mizchi/arda Arda - MetaFluxなフレームワークを作った - Qiita Ardaは実践的なものを目指した 他のフレームワークは思想から入って実装されたものかもしれませんが、ArdaはFluxを意識しつつも実際のアプリで使われている画面遷移の機構を抽象化する点から開発がスタートしています。 またKobitoという比較的寿命が長い(ことを予定している)アプリの基盤にすることで長くメンテされる予定です。なのでKobitoはちゃんと使ってもらえるようなものにしたい、と思って開発しています。(この記事が宣伝兼ねてないとは言いませんが。) (自分の開発したものにしては)ドキュメントが充実していることについて 開発者の今回の様子に