Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用 - Qiita
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用Fluentdgooglecomputeenginekubernetesgooglecloud まずはFluentdコミュニティの皆さん、おめでとうございます！！！ Googleを中心に開発されているオープンソースのDockerジョブスケジューラKubernetes (k8s)、それにGoogle Cloud Platformのログ収集サービスGoogle Cloud LoggingのGoogle Compute Engine用ログコレクタとして、Fluentdが標準採用されました。もうひとつおまけに、fluent-plugin-bigqueryをフィーチャしたソリューションページも、あと1か月くらいでcloud.google.comにて公開される見込みです（これは私がいま仕上げ中）。
モバイルアプリのログ収集ライブラリ「Puree」をリリースしました - クックパッド開発者ブログ
モバイルファースト室の @rejasupotaro です。 クックパッドでは、サービスをリリースしてログを収集して分析して改善してまたリリースして、というサイクルを素早く回すことでより良いものを作るということをウェブではやってきました。 クックパッドのサービス開発のフレームワークをモバイルアプリでも適用したいのですが、モバイルアプリにはウェブアプリと違ったロギングの難しさがあります。 今回はモバイルアプリのロギングの問題点とPureeというログ収集ライブラリについて話します。 モバイルアプリのロギングの難しさ ウェブアプリでは、基本的にはサーバー側でログを収集することができますが、モバイルアプリの場合は画面の制御はアプリ側で行われ、APIを介してデータを受け取るため、クライアント側でログを収集して送信する必要があります。 アプリのログを収集するのに、画面遷移をしたりタップするたびにサーバー
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
組織外部向け窓口部門の方へ：「やり取り型」攻撃に対する注意喚起 ～ 国内5組織で再び攻撃を確認 ～：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：藤江 一正）は、J-CSIP(*1)とJ-CRAT(*2)の一連の活動により、標的型サイバー攻撃の手口の一つである「やり取り型」攻撃（無害なメールのやり取りの後でウイルス付きのメールを送信してくる手口）が、2014年8月から10月にかけ、再び、国内の複数の組織に対して行われたことを確認しました。また、メールの添付ファイルを開封させ、ウイルスに感染させるための「やり取り」が巧妙さを増していることから、改めて利用者、特に各組織の外部向け窓口の担当者へ注意を呼びかけます。 「やり取り型」攻撃とは、一般の問い合わせ等を装った無害な「偵察」メールの後、ウイルス付きのメールが送られてくるという、標的型サイバー攻撃の手口の一つです。攻撃者からのメールは、その内容を確認したり、返信せざるをえない外部向け窓口部門等に対して送られてきます。メールの受信者が攻撃者か
そこそこセキュアなlinuxサーバーを作る - Qiita
先日「サーバーのセキュリティ設定がなにすればいいかわからない」と相談をうけまして。 自分も初心者の時どこまでやればいいかわからず手当たりしだいにやって沼に入っていたのを思い出しながら自鯖構築したときのメモを元にまとめてみました。 注意 セキュリティ対策は用途や場合などによって違います。 自分で理解したうえで自己責任でおねがいします。 対象読者 Linuxのサーバーを建て慣れていない人 Linuxはある程度さわれる人(自分でパッケージを入れたり、サービスを止めたりできる) ラインナップ ☆は導入の重要度と導入の容易さから個人的偏見からつけた値です。 4つ以上が"最低限やること"だと思ってください。 sshd
S3 Event NotificasionsをAmazon SQSで受け取る - Glide Note
最近やっている仕事で先日発表されたS3 Event Notificationsが利用出来そうな感じがしたのでちょっと調査。 S3にファイルがアップされたらAmazon SQSで通知を受け取るようにしてみた。 S3 => SNS => SQS への通知は解説しているサイトが結構あるんですが、S3 => SQS への通知設定の 情報が見当たらなかったので、動くようになるまで、いろいろと試行錯誤を繰り返した。 特にSQSのPermission設定が恐ろしく分かりにくくに2日くらいハマったので、自分用にメモしておく。 S3 Bucketの作成 S3でBucketを作成。既存Bucketを利用する場合はここはSKIP。 今回は検証用にglidenote-sqs-testという名前でBucketを作成 SQSの設定 S3のイベント通知を受け取るQueueを作成する Queue名をsqs-testをして
golangのWebフレームワーク、revelの機能紹介 — そこはかとなく書くよん。 ドキュメント
golangのWebフレームワーク、revelの機能紹介¶ golangでのweb application frameworkはいろいろなものがあります。その中 でどれがいいのかというと、どれも鋭意開発途中だし、新しいのも出てくるし でなんとも言えません。 その中で、 revel というフレームワークが結 構昔からあります。これは、Railsに例えられるようになんでも揃ってるいわ ゆ る重量級なフレームワークです。 薄いフレームワークであれば、標準のnet/httpでもいいような気もちょっとす るので、現在このrevelを使って実際に作ってみています。 なお、以下のページを参考にさせていただきました。 Go言語製のWeb Application Framework - Revel - を触る ʕ ﾟ皿ﾟ ʔ GolangのWeb Application Frameworkを色々試してみて
Goを使い複雑性を回避する | POSTD
『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』 を書いたFred Brooksはその論文の中で、 偶有的な複雑性と本質的な複雑性 について重要な区別をしています。 本質的な複雑性 とは、問題特有の領域から生じる複雑性のことを指します。例えば、SMTPクライアントを作成しているディベロッパは、 RFC 5321 の核心の細かいところ全てに取り組む必要がありますが、これはSMTPクライアントの作業をする上で避けては通れないものです。これに対して 偶有的な複雑性 とは、私たちが自ら作り上げた問題から生じる複雑性のことを指します。 技術者としては、自らの選択で生じる偶有的な複雑性によって、余計な負担が増えないようにとても注意しなければなりませんよね。その意味では、言語の選択は偶有的な複雑性を軽減できる完璧な例と言えます。Webアプリケーションを書くのにアセンブリ言語を選びます
プレイブック -開発- | POSTD
thoughtbotはWebとモバイルアプリを開発するWebコンサルティング会社。Railsの有名プラグインであるPaperclipやFactory Girlなどのオープンソースプロジェクトや、自社プロダクト（hound、Upcase）も開発している。ボストンをベースに、サンフランシスコ、デンバー、ニューヨーク、フィラデルフィア、ローリー、ストックホルムにオフィスを持っている。 開発手法の大半は、まずKent Beckの有名な著書『Extreme Programming Explained: Embrace Change』（邦訳『XPエクストリーム・プログラミング入門』）、そしてGerald Weinbergの『The Psychology of Computer Programming』（邦訳『プログラミングの心理学』）で詳細に述べられています。それらを試したところ、多くの手法を開発中に
[AWS][Java] CloudFront+S3の署名付きURL発行手順のドキュメント | DevelopersIO
こんにちは。こむろです。すっかりサーバーサイドJavaに戻ってます。 今回は、CloudFront＋S3の署名付きURLの発行をAWS SDK for Javaから行う方法を探してみました。 が、いまいち公式ドキュメントの更新が追いついていないようだったので、怒りととともにメモしておきます。 CloudFront + S3の署名付きURLのドキュメント これらをどのように連携すればよいかは、弊社ブログでもいくつかエントリーが投稿されています。 CloudFront+S3で署名付きURLでプライベートコンテンツを配信する [CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する この辺りを参考にしています。 しかし、AWS SDKからのコードを通してのアクセス方法など、開発寄りのものではなかったので公式のドキュメントを追ってみました。 Am
![[AWS][Java] CloudFront+S3の署名付きURL発行手順のドキュメント | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/05bf92c3dad6e282bf2cded7bb4b61f42547e50e/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_CloudFront.png)
OpenLDAPをCentOS6にインストールしてLDAP Adminで疎通確認する | DevelopersIO
はじめに こんにちは、虎塚です。 唐突ですが、今日はAWS上のCentOS6にOpenLDAPをインストールして、LDAP Adminから疎通確認をする手順を説明します。（追記）phpLDAPadminを利用した疎通確認の手順は、LDAPサーバにphpLDAPadminをインストールして疎通確認する ｜ Developers.IOをご参照ください。 OpenLDAPは、LDAPのオープンソース実装です。ドヤ顔した青虫のロゴがキュートですね。LDAP Adminは、Windows環境で利用できるLDAPブラウザ/エディタです。 CentOS6の起動 CentOS6の公式AMIは、AWS Marketplaceから選択できます。Management ConsoleからCentOSのAMIを探すと、たくさん出てきてどれを使えばよいのか迷ってしまいますね。ここは公式版を使いましょう。 CentOS
Microsoft Azureが10時間を超える障害。原因はストレージの性能改善のバグと運用のミスとの報告
Microsoft Azureが10時間を超える障害。原因はストレージの性能改善のバグと運用のミスとの報告 マイクロソフトのクラウドサービス「Microsoft Azure」は、11月19日水曜日の午前10時前（日本時間）から午後8時45分の10時間を超える長時間、ストレージや仮想マシンなど多くのサービスでサービスの中断や性能低下などの障害を引き起こしていました。 その原因について、Microsoft Azureのブログのエントリ「Update on Azure Storage Service Interruption」（日本語訳「Azure Storage サービスのサービス中断について - Microsoft Azure Japan Team Blog (ブログ)」で報告されています。 この障害で影響があったのは、Azure Storage、StorSimple、Azure Backu
ビデオチャットもさくっと作れる！ WebRTCによるブラウザ間リアルタイム通信はじめの一歩
WebRTCを使えば、このようなリアルタイムコミュニケーションを行うWebアプリケーションを作ることができるのです。 WebRTCの通信形態 WebRTCの特徴の1つは、通信をP2P方式で行う点です。通常のWebサイトでは、ブラウザとサーバの間で通信を行います。また、WebRTCとよく比較される規格に「WebSocket」がありますが、WebSocketでは必ずWebブラウザとサーバ間で通信を行うことになっています。チャットなど、ユーザ同士でデータをやり取りを行うのに使われることもありますが、その場合も必ずサーバを介して通信します。 一方、WebRTCはサーバを介さず、P2Pによりユーザ間で直接通信を行うため、レスポンス性がより高い通信を実現できます。また、下位層のプロトコルに（TCPでなく）UDPを使っていることから、品質よりもリアルタイム性を重視した通信方式といえるでしょう。 API仕
小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ
アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこの本を買って、カラーグレーディングの勉強をしています。とても良い本です。 さて、今回お話するのはバックエンドにあるフロントエンドについて。 以下はほぼ実際にカメリオで運用しているバックエンド構成です。 図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンドAPIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。 まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに NodeベースのフロントエンドAPIサーバーを置きます。 ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。 エンドポイント(api.kamel.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Internet Week 2014】“未熟なDNS”をDDoSで拷問、「DNS水責め攻撃」が原因らしき実害が日本でも 