データ分析の「7つの進化のステップ」を今一度おさらいしてみる - 渋谷駅前で働くデータサイエンティストのブログ
2016年最初の記事ということで、もはや1月下旬に差し掛かりつつありますがこちらでは改めて、あけましておめでとうございます＆本年もよろしくお願いいたします。 で、新年一発目のお題は。。。実は似たようなお題で過去にも記事を書いていますが（笑）、年も改まったことなので今一度備忘録的におさらいしてみたいと思います。観点としては、どちらかというと「これからデータ分析のカルチャーを職場に導入していくとしたらどうやってステップアップさせていくか」みたいなところです。なお過去記事はこちら。 この辺の話題を踏まえながら、過去記事リンクのオンパレードで恐縮ですがちょっと一席やってみます。なお以下に挙げる「ステージ」はあくまでも一例であり、業界によってはもっと高度な方向に展開させられる（orもっとプリミティブなレベルに留まる）こともあるので、参考程度に見てもらえればと。 特にここでは「まだデータ分析を始めてい
[iOS]端末の時間を進めることによるチート(不正行為)の現状と、それをお手軽に防ぐ方法 - Qiita
端末時間を進めることによるチートの現状 iPhoneでは、ユーザーは端末時間の変更を設定アプリから簡単に行うことが出来ます。これはこれで便利な機能なのですが、例えば時間の経過が重要な要素となるゲームなどでは、この機能を利用することによりチート(ズル)を行うことが出来ます。 いわゆるソーシャルゲームの場合、基本的にサーバーと通信することが前提となっているため、端末の時刻に依存しない仕様となっているか、時刻の設定が不正だった場合には警告を出す、という仕様になっているものがほとんどです。 しかしながら、いわゆる進化系ゲームなどに見られるような個人開発のカジュアルゲームでは、チート対策が行われていないことがほとんどであるように思います。もちろんあえて実装してないというパターンもあるのだとは思いますが、サーバーとの通信処理等も必要となるため、小規模なアプリや個人開発アプリでは、実装コストを考えて対応
![[iOS]端末の時間を進めることによるチート(不正行為)の現状と、それをお手軽に防ぐ方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ff0f2aa516a98bee29ec3913a758cc0b22e24add/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCaU9TJTVEJUU3JUFCJUFGJUU2JTlDJUFCJUUzJTgxJUFFJUU2JTk5JTgyJUU5JTk2JTkzJUUzJTgyJTkyJUU5JTgwJUIyJUUzJTgyJTgxJUUzJTgyJThCJUUzJTgxJTkzJUUzJTgxJUE4JUUzJTgxJUFCJUUzJTgyJTg4JUUzJTgyJThCJUUzJTgzJTgxJUUzJTgzJUJDJUUzJTgzJTg4JTI4JUU0JUI4JThEJUU2JUFEJUEzJUU4JUExJThDJUU3JTgyJUJBJTI5JUUzJTgxJUFFJUU3JThGJUJFJUU3JThBJUI2JUUzJTgxJUE4JUUzJTgwJTgxJUUzJTgxJTlEJUUzJTgyJThDJUUzJTgyJTkyJUUzJTgxJThBJUU2JTg5JThCJUU4JUJCJUJEJUUzJTgxJUFCJUU5JTk4JUIyJUUzJTgxJTkwJUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0yNmE1ZWIxNzQwZDExZDE5OTMxYTUwMjExNTBmNTEyMA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrYXp1MDYyMCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9Y2U2Njg3MjUyMGM1MzhmNzFkZGM0NDQzYjczOGI3NjY%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D7006f62b7ac71bd5c3b8e9352610a6f5)
もしもデータベースサーバがクラッシュしたら
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
APCキャッシュを安全に扱うSafeApcを作った - nazolabo
https://github.com/nazo/safeapc なにこれ？ APC(APCu)のユーザーキャッシュ（アプリから指定するキャッシュ。ソースコードのキャッシュではない）を「そこそこ安全に」扱うための簡単なラッパーです。 どう使うの？ packagistに登録してあるので普通にcomposerから入れてください。 基本的には普通にapc_fetchとかするのがSafeApc::get等に変わっただけです。 あと、リクエストの最初に、以下を入れる必要があります。 // キャッシュで使用するリクエスト開始時間を指定 SafeApc::setCacheStartTime($_SERVER['REQUEST_TIME']); // キャッシュのバージョン番号を指定（この例では外部ファイルから） SafeApc::setCacheVersionKey(file_get_contents('
【PHP】 APCu apc.shm_sizeを超えるとどうなるか - 旅するえんじにあ - Engineers to Travel -
さてAPCuを使うようになり、まず気になるところがキャッシュと云えど限界はある。 そう、apc.shm_sizeだ。 毎回悩ましいのが、どれくらいの容量を設定していればいいのか。 実際にはttlに設定されている(実際にはプログラム上で明示的に指定するのだけど)時間でクリアされるため そこまで大きなメモリを確保する必要はない、けれども、一体どれくらいを設定したらいいのか。 更に言うと、設定したメモリを超えてしまった時、どういったことが起きるのか。 今回のAPCuはCSVデータを保存しておく（消えても問題ないようなデータ）ことが利用目的です。 どれくらい確保するかについては実際保存するだろうCSVデータなりを運用することを想定として多めに作成し、実際にAPCuに保存した上で容量を確認すれば問題ないかと思っています。 もちろんバッファも考えて多めに確保はします。 問題はその想定を超えて、オーバフ
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
memcached活用は、格納オブジェクトの”粒度”がキモ
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”（granularity）がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
memcached を使ったアプリケーションの設計について - blog.nomadscafe.jp
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
これがスマホで見る動画だ。アイドル「リリカルスクール」の新曲がすごい
90年代生まれの6人組、ヒップホップアイドルユニット「リリカルスクール」の新曲「RUN and RUN」のミュージック・ビデオ（MV）がすごい。
TCP/IP と OSI 参照モデル
これは、国際標準化機構 (ISO) が異なるシステム間接続の標準を定めようと、 OSI (Open Systems Interconnection) というネットワーク構造の設計方針を決めたものです。 その中に出てくるのが上記の OSI 参照モデルです。 OSI は政府 (特に欧州)・学者・企業がこぞって支持した規格でしたが、 実際にはあまり普及しませんでした。 理由としては、実装を考慮せずに机上で決められた規格であること、 トップダウンの中央集権的な規格であったこと、 政治的なかけひきで規格策定が進まなかったこと、 安価で入手しやすい実装がなかったこと、 などがあるのかもしれません。 一方、TCP/IP は ARPAnet から発展したプロトコルです。 4.2BSD で一般的に利用できるようになり、RFC によるゆるやかな規格と インターネットの普及に伴い爆発的な発展を遂げました。 AR
調べなきゃ寝れない！と調べたら余計に寝れなくなったソケットの話 - Qiita
なるほど、最近ソケット通信、ソケット通信と言ってるのはUNIXドメインソケットの事か！ UNIXドメインソケットって何がいいの？ Performance Analysis of Various Mechanisms for Inter-process Communicationに素晴らしい検証があった。 It was hypothesized that pipes would have the highest throughtput due to its limited functionality, since it is half-duplex, but this was not true. For almost all of the data sizes transferred, Unix domain sockets performed better than both TCP so
【コーポレート】一部報道内容に関する当社の見解について（追記・更新あり） | ニュース | LINE株式会社
本日、一部報道機関において、当社のスマートフォン向けゲームに関し、当社が資金決済に関する法律（以下「資金決済法」といいます。）に基づく規制の適用を意図的に免れ、同法に基づいて必要とされる供託を逃れようとしたかのような報道がなされましたが、そのような事実は一切ございません。 当社のスマートフォン向けゲーム内で販売されるアイテムが資金決済に関する法律の規制対象となり、一定額の供託を要することとなる「前払式支払手段」に該当するか否かに関しては、専門的、技術的な問題があり、法令上も行政実務上も判断基準が明確でないことから、現在、関東財務局とこの点につき協議中です。 なお、関東財務局から立入検査を受けていることは事実ではありますが、この立入検査は、前払式支払手段発行者に対して数年に一度定期的になされているものであり、LINE POP「宝箱の鍵」につき資金決済法上必要な届出をしなかったという疑いに起因
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分割と整合性と戦う
『瞑想ってネットで調べてもイマイチ何をやればいいのかわからない』へのコメント
memcachedからKyotoTycoonへ
ＬＩＮＥ：立ち入り検査 ゲームの「鍵」、通貨の疑い 関東財務局 - 毎日新聞
