somathorのブックマーク / 2016年1月29日

somathor id:somathor

2016年1月29日のブックマーク (6件)

複数のgroutineが連携する通信オブジェクトの設計方針 - Qiita
忘備録的に。推敲が足りないので読みづらいので心の広い人以外は読まないように。 goでは、Socket扱ったりいろんな通信をする複数のgoroutineが生えてるアクター的なStructを作ることが多いので、綺麗に全てのgoroutineを終了して何らかの終了処理を実施するための基本構成をまとめる。まず停止処理に関係なくdeadlockを避けるために気をつけること socketでも待つしchannelでも待つしsync.Condとかでも待つというような複数のwaitが行われるようなgoroutineはdeadlockする可能性が高いのでそもそも作るべきじゃない。 threadsafeじゃないオブジェクトを触るのは基本的に一つのgoroutineに収める channelにオブジェクトの操作を完全に任せられない場合は、Mutexを使うことになるが、Mutexでロックしている範囲を不用意に広くし
somathor 2016/01/29
golang

goroutine
リンク
末尾呼び出し最適化が実装された - JS.next
概要ある関数Aから別の関数Bを呼び出すとき、処理系は後で戻って来れるように一旦Aの状態を保存し、関数Bの処理に入る。これが問題になるのは再帰の時で、数万回程度の再帰でスタックが一杯になり、エラーとなってしまう。しかし、もし関数B呼び出しの際に、関数Aに戻ってきて処理を続ける必要のない形で呼びだされていれば、状態の保存を省略して関数Bに移行する最適化が可能であり、ES2015でその詳細が定義されることとなった。例具体的には、strictモードの関数で、「 return fn() 」という形での呼び出しについて最適化が有効になる。最適化が効く例： function fn( n ) { 'use strict' if ( n <= 0 ) { return 'done!' } return fn( n - 1 ) // この関数がする処理はこれ以上ない } fn( 1e6 ) //
somathor 2016/01/29
javascript

optimization

v8
リンク
[意訳]私がGulpとGruntを手放した理由 - Qiita
このポストは、Why I Left Gulp and Grunt for npm Scriptsを筆者の許諾を得て意訳したものです。間違いがありましたら、ご指摘いただけると幸いです。（以下、訳）私はGulpとGruntが不要な抽象化レイヤーだと気づきました。npmのscriptsはとても強力で、そっちの方が便利だったりします。例を挙げましょう私はかつてはGulpが大好きでした。しかし結局のところ、100行ものgulpfileと大量のgulpプラグインを扱うハメになりました。Gulp上でWebpackやBrowsersync、Mochaなどを統合するのは本当にたいへんでした。なぜでしょうか？それは、プラグインによってはドキュメントが不十分だったり、APIの一部しか公開されていなかったためです。これらを解決しようと思えばできました。しかしなんとそれらのツールを直接使用すると不具合が
somathor 2016/01/29
node.js

npm
リンク
ドラクエ風スキルマップ - nemorineのブログ
あるとき突然『チームのキーマンが抜ける』というイベントが発生しました！まあ会社という組織ではよくありますよね（苦笑チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。これもまさにゲーミフィケーションって感じですねぇ～スキルマップを作る過程元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。これだけでもかなり盛り上がりましたッ！！以下は川口さんのオリジナルから変更したところです。要件定義のスペシャリストとして、商人を追加。旅芸人はマネージメントのイメージに変更スキルの方向を上方向に変更盗賊のスキルレベルの見直し CやC++をイメージして文言を見直し特性に対応するキーワードを追加スキルマップを記述するチームメンバーに実際に
somathor 2016/01/29
development

management
リンク
AWSで避けるべき5つの間違い | POSTD
今年からAWS（Amazon Web Services）クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。仮想マシンを活用しない。典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。典型的なWebアプリケーション典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。ロードバランサスケーラブルなWebバックエンドデータベースそしてこのアプリケーションは、次の図のような仕組みを持っています。注釈：（左から）DNS、CDN、静
somathor 2016/01/29
aws
リンク
マイクロサービスの開発とテスト
Spring BootによるAPIバックエンド構築実践ガイド第2版何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
somathor 2016/01/29
microservice

testing
リンク
- 2016年1月30日
- 2016年1月29日
- 2016年1月28日