Goのバッチで統計を取得するAPIを用意しておくと便利 - Qiita
package main import ( "fmt" "sync" "time" ) // なんかしらの処理 func someprocess() { somedata := []string{"a", "b", "c", "d", "e"} var wg sync.WaitGroup for _, s := range somedata { wg.Add(1) go func(val string) { defer wg.Done() fmt.Println(val) }(s) } } func main() { // ずっと動き続ける for { someprocess() time.Sleep(3 * time.Second) } } このとき、この処理の稼働状況を知りたくなるのが人の常なので、以下のようにhttpサーバを立てて、 jsonで統計情報を取得できるようにしておくと便利
プログラマの履歴書
「コードを書け。それが履歴書だ」という昔の名台詞が目に留まったので、常日頃感じていることを書き出してみることに。 コードが GitHubで公開してあると、まず採用する側の視点としては非常に助かります。プロジェクトを２、３つ眺めるだけでも、この人が普段どんなことを意識してプログラミングしているのかが見えてきます。例えば、性能を重視しているとか、拡張のしやすさを意識してインターフェースをデザインしているとか。さらに本人の興味の方向性、得意な言語などがわかるが何より嬉しい。過去の経験から、自己申告でJavaができます、C++ができますなどと言うだけの人が期待したレベルでコードを書けた試しがありません。 その次にわかるのがコミュニケーションスキル。基礎的な英語力の判断材料にもなるし、チームを組んだ時のイメージがしやすい。問題を共有する能力も大事。自分一人の頭の中でたくさん難しいことを理解して解決で
JavaScriptフレームワークの寿命 | POSTD
(注記：9/13、いただいた翻訳フィードバックを元に記事を修正いたしました。) 半年ごとに”今一番ホットな”フレームワークが新たに登場しては、私たちは興奮に沸き返ります。 誇大広告を信じてはいけません。 フレームワークの寿命 はプロジェクトの成功を左右するほど重要な要素です。フレームワークを選ぶ際、テクノロジにおける多くの意思決定者は納得のいく選択をするために、コミュニティの大きさ、人気、大企業によるサポートの有無などを基準にしています。しかし実際は、こうした要素によって寿命が決まるわけではありません。 最初は勢いがあったのに、徐々に弱まり、最終的には線香花火のごとく儚く消えてしまうようなフレームワークを選んでしまうと、書き直しに無駄な時間を費やしたり、チームの士気を下げたりする原因となります。本記事は、そうした残念な結果を回避するヒントをまとめたものです。 本記事では以下のことを示したい
流行りのDockerの使い方について触って覚える (CentOS7編)③
この記事には広告を含む場合があります。 記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。 作成したコンテナに接続 まず、コンテナイメージがある事を確認します。 ・コンテナイメージの確認 # docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE docker.io/centos 7 fd44297e2ddb 6 days ago 215.7 MB docker.io/centos centos7 fd44297e2ddb 6 days ago 215.7 MB docker.io/centos latest fd44297e2ddb 6 days ago 215.7 MB # docker run centos:centos7 cat /etc/centos-release CentOS
Elasticsearch with Amazon Machine Learning
Elasticsearchには色々なAPIが用意されているので、それらのAPIを色々使って今回やろうとしていることに近いこともできるのですが、今回は機械学習に Amazon Machine Learning 使ってみようかと。 やりたいことは、各ドキュメントの文章を元に、３つ以上の分類を予測するための機械学習モデルの作成です。いわゆる多項分類（Multiclass Classification）。 Elasticsearchはこのモデルを作成するための、教師データ作成に使います。Elasticsearchを使うことで、言語処理などの正規化をElasticsearchに任せてしまうことができるというメリットがあります。 正解データの作成正解データの作成は、Elasticsearchに文章とカテゴリが付与されたデータをインデックスするだけです。既に商品データなど、インデックスされていればそれを
新しく更新されたAWSのIPレンジをAmazon SNSで通知してもらう | DevelopersIO
こんにちは、せーのです。今日は前回の記事に引き続きAWSのIPレンジのネタです。 AWSのIPレンジは公開されている 先日こちらの記事にも書きましたが、AWSにて使用されているIPレンジはJSON形式にて公開されています。IPレンジは定期的に更新、拡張されるので使用時にダイレクトにこのファイルにアクセスし、動的に取ってくるのがスマートかと思います。 しかし要件によっては毎回インターネット上にあるIPレンジにアクセスするのが困難なときもあります。例えばセキュリティ上インターネットへの口を閉じなければいけない場合や、逆に頻繁にIPレンジによるチェックが行われる場合はこのJSONへのリクエストが性能の低下やコスト増になる場合も充分考えられます。つまり、IPレンジは手元にとっておいて、変更した時のみ新しいものを取ってくる、という方法はとれないでしょうか。とれます。 SNSで通知してもらう 本日アッ
うまくメソッド名を付けるための参考情報 - Qiita
クラス名編をつくりました あるメソッドを定義しようとするとき、そのメソッドを使う人達が名前からどんなことをするか理解できるようにするには、メソッドの内容に応じて適切な情報量の命名が求められます。 この記事では、メソッド名に用いることでどのような情報が提供できるかを見ていきたいと思います。 真偽値を返すメソッド 場所 単語 意味 例
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
AWSチーム社内勉強会「EMRおじさんに聞いてみよう」レポート | DevelopersIO
弊社AWSチームでは最近「◯◯おじさんに聞いてみよう」というタイトルで各分野について詳しそうなメンバーを講師としてQA形式の社内勉強会を開催しています。今回はその中でもAmazon Elastic MapReduce（Amazon EMR）に関する勉強会のレポートになります。QA形式の勉強会ですので、どんな質問が出て、どんな回答があったかをお楽しみ頂ければと思います。なお、EMRということもあり、社内でも利用経験がないメンバーもいたため、まずはHadoopの概要から説明しつつ、オンプレHadoopとEMRの違いなどについて駆け足で説明する勉強会となりました。 Q. そもそもEMR（Hadoop）が分からない かなり古いのですが、前述のスライドを元に以下の点について説明しました。 Hadoopは並列分散処理基盤。スケールアウトする。 バッチ処理用に開発された。とはいえ、最近は対話処理用に利用
Goのsyncパッケージで相互排他ロックを行う - Qiita
syncパッケージには、相互排他ロックがあります。 これを使うと意図的に処理にブロックを入れることが出来て goroutineのチャンネルのやりとりのウェイトのようなことが実装出来ます。 Mutex型 相互排他ロック。 使わない場合 package main import ( "fmt" "time" ) func main() { c := make(chan bool) for i := 0; i < 5; i++ { go func(i int) { time.Sleep(500 * time.Millisecond) fmt.Println(i) c <- true }(i) } for i := 0; i < 5; i++ { <-c } } package main import ( "fmt" "sync" "time" ) func main() { m := new(sy
私が実施する Heroku x Rails の高速化をまとめてみた - ボクココ
Herokuの欠点は、Tokyoリージョンがないため、ネットワークによる遅延が気になる と言われている。どの程度による遅延が気になっているのかは人によると思うが、Herokuを最大限に高速化させるために私がやっていることをまとめてみた。 これを実施すれば、Herokuが遅いとはあまり思わなくなると考えている。 Asset Sync を利用する [追記（重要）] Asset Syncを利用するのは公式で止めるよう勧告が出ている。CloudFrontを利用する方法が推奨されている。以下の内容は古いのでご注意を。 ーーーーーーーーーーーー Asset Syncは、Amazon S3に画像やCSS/JavaScriptを置き、各アセットのパスの向き先をそちらにかえてくれるgemだ。これを利用しないと、HTMLとかに置いた静的コンテンツが全てHerokuにアクセスしてしまうため、Herokuサーバー
AWS のセキュリティ関連資料（セキュリティ三部作）を読んだ - ようへいの日々精進XP
自分メモ。 追記 aws.typepad.com DDoS に関するホワイトペーパーも日本語訳されて公開されている。後ほど読みませう。 tl;dl こちらに紹介されている資料をダウロードして読んでみた。 セキュリティプロセスの概要 AWS セキュリティとコンプライアンス AWSのセキュリティについて 内容をちゃんと把握は出来ていないが、以下に雑にメモる。 感想等 読んでみて セキュリティプロセスの概要 はホワイトペーパー（全 27 ページ）でほぼ文字だったが、各 AWS リソースのセキュリティ実装について触れられていた AWS セキュリティとコンプライアンスと AWSのセキュリティについてについては上記のホワイトペーパーをわかりやすく解説するような構成になっていた ピックアップキーワード 責任分担モデル（セキュリティ共有モデル）→ AWS はインフラ部分のセキュリティに責任を持つ セキュリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
