はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 採用試験としてコードチェックを導入している会社はまだまだ少ないのですが、実際にコードチェックを導入するにあたっては以下のような問題があります。 そもそもコードチェックは必要なの？ コードチェックの目的は何？ どんな問題を出題するのが適切なの？難易度は？ コードチェックで何をみればいいの？得点だけ？ 応募者へのフィードバックは何をすればいいの？ これらの問題は企業の体制や、規模感、どういう人材を募集しているのか？によって答えはまちまちで正解は無いのですが、株式会社ゆめみにおける一例を紹介できればと思います。 株式会社ゆめみ（以下

結論 CDNでのキャッシュヒット率が低いときにTTL（キャッシュ生存期間）を伸ばすのは無意味なのでやめるべき。 これはCDNだけでなく、通常のキャッシュコントロールでも同じです。 CDNとは この章は知ってる人は読み飛ばしてください。 大量のコンテンツ配信を実施する際に、コンテンツ配信元のサーバの能力以上にユーザーへのサービスを提供するための仕組み。 Akamaiとか、CloudFrontとか、いろんな業者がサービスとして実施しています。 配信元のサーバを増強するよりよほど安上がりなことが多いので、大量コンテンツ配信が必要なサービスでは導入は必須と考えていいです。 CDNは大量のユーザーアクセスの中から、同一のコンテンツを返答して良いと設定されたコンテンツに関して、一定期間（TTL）の間コンテンツをキャッシュして、そのキャッシュから同じものを返答します。 コンテンツ配信元サーバ（オリジンサ

はじめに 有名なプログラマージョーク プログラマの夫に「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」と言ったら、夫は牛乳を6パック買ってきた。 プログラマーを笑う自虐ジョークとして使われがちですが、 良い題材なのでこれを元に要望 と 要件定義 と 設計 と 実装 の違いを纏めてみましょう。 下記、それぞれのフェーズの原理原則論を記載します。 各フェーズの原理原則 1. 要望 顧客(妻)の要望 を書き出す：顧客の仕事 買い物に行って牛乳を1つ買ってきて、卵があったら6つお願い。 2. 要件定義1（ダイジェスト） 顧客の要望から曖昧な点を除いて復唱する：PMの仕事 上記だとプログラマーの夫は牛乳を6本買ってきました。夫は妻に、要望をより具体的な形で復唱する必要があります。 ここでは、卵を6つ買ってくるという事を確認することで事故を防ぐことができます。 牛乳を1本買ってくる 卵が

はじめに 人権剥奪PCをRDP端末として利用して一年後のレポートの続き 世間には人権剥奪PCと呼ばれるPCが存在します。 人権剥奪PCとは、マシンスペックが不足することで開発効率が下がったり、開発者にストレスを与えてしまうPCのことという理解なのですが、それ以上に問題なのは、システムの更新ができないレベルの低スペックPCでしょう。 具体的はストレージが32GB eMMCのWindowsマシンのことになります。 理由は明らか。初期状態で15GB程度のメモリを利用、Windows Updateファイル類が累積で10GB以上貯まる、インストール時には更に空き容量が必要という状況のため、PCに何のアプリやデータの保存を指定ない状態であってもそのうちWindows UpdateがPCを自殺に追い込むためです。 そこで、Windows UpdateファイルをMicro SDカードにダウンロードさせるよ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Cache利用ポリシーについての一般論 適切なCache利用はシステム全体の性能を上げることに非常に効果的です。また、うまくCacheを利用することによって、スケール対応しにくい部分の負荷を逃がすこともできるようになります。 CDNの利用も含めて、積極的にCacheを利用したいケースとして以下のような例が挙げられます。 [前提条件]Cacheのヒット率が高いケース マスタデータの参照など、実行時にほとんど結果が変わらないケース どのユーザーに対してもほぼ同じページを返答して良いケース [前提条件]Cacheが古くても大きな問題とならないケースまたは古い状態のCacheの更新が出来るケース Cache保持期間を短くすることである程度解消可能 DBを更新した時にCacheの内容も書き換える事ができるケース（Read Through Cacheとして利用している場合は、Cacheの削除だけで良い

はじめに LambdaからRDSに接続する時に、Lambdaでは全てのプロセスが独立してしまうので、connectionも使いまわすことが出来ません。 このため、Lambdaに対する同時接続数を増やしていくと、RDS側でconnection数が上限を超えた時にエラーになります。 ※ただ、これはLambdaに限らず、Connection Poolingが出来ないシステムでは同じです。 このことにより、Lambda+RDSはアンチパターンであるという見方をすることがあるようです。 結論 Lambdaを利用してもRDSのmax connection設定"だけ"が原因でスループットが実用に耐えなくなるということはなさそう。(即アンチパターンというわけではさそう) [追記]RDSがSingleAZの場合、(試験した範囲では)インスタンスタイプを変えることでスループットをスケールすることができる。 [

Windows使いの私がシンクライアント端末としてMacBookを選んだ際にRDP接続時のキーボードの違いに苦しんだので忘備録。 シンクライアント端末としてMacBookを選んだ理由 高解像度 比較的軽い バッテリーの持ちが良い Mac上での開発も可能 キーボードの問題さえクリアできれば結構メリットが多いです。 やりたいこと 通常時は外部モニタをつなげて外付けWindows向けJISキーボードを接続し、デスクトップマシンとして作業する 緊急時はMacBook上のキーボードで作業 上記2つのキーボードのキーバインドを出来るだけ揃える RDPでWindowsマシンに入って作業するときにワンキーで日本語入力のON/OFFを行う 対象OS OS X 10.11.6 [Step1] 外部接続したJISキーボードを利用可能にする JISキーボードの無変換キーと変換キーを利用可能にします。 Mac上での

はじめに 負荷試験ってとっても重要ですが、リリーススケジュール優先でどうしても後回しにされたり、省略される事がありませんでしょうか。 特に近年はクラウドでの動作が前提となっているため、リリース後のスケールアップやスケールアウトが容易であるというということも、事前の負荷試験が軽視されてしまう要因となっているかもしれません。 しかしながら、ある案件で負荷試験を行ってやっぱり重要だなということがわかったので自戒を込めて負荷試験実施からパフォーマンス・チューニングの流れを記載します。 各ツールの詳細な紹介などは自分が参考にしたリンクを随時追記したいと思います。 ※以下、数字は例であり、適当に丸めてあります。 負荷試験を軽視することにより発生しうるケース 簡単に思いつくこと サービスの継続に必要なサーバリソースが予算またはサービスの収入を上回った。（ワーストケース） サービスの継続に必要なサーバリソ

はじめに ※ タイトルは、正確には、「Zephir使えばPHP Extensionが(PHPのコードさえかければ)誰でも超絶簡単に作れる」ですが、PHP Extensionを書きたい人はPHPのコードを書ける人だと思われますので、省略してます。 メモリ操作を気にせずにPHP Extensionを作れる言語”Zephir” こちらの記事を読んで面白そうだなと気になってストックだけして積んでた状態でした。 しかし、とある案件でファイルのフルスキャンをしたくなったのでPHP Extension化を試みました。 情報は公式の Zephir Language にもありますが、日本語情報が少ないのでこちらに簡単にまとめます。 結論から箇条書きすると 面白い。 初めて触ったその日にメモリ管理に気を使う必要なく、PHP Extensionの開発が出来ました。 今回のケースでは、PHPでベタ書きした場合と比

はじめに どうも、最初にみたforeachの便利さに触れて以降、なかなかそれから離れる事ができないforeachおじさんです。 Shin x blogさんのblog http://www.1x1.jp/blog/2014/06/how-to-scan-array-in-php.html にて、いろいろとモダンな感じのarrayの処理方法を紹介されていたのでベンチをとってみました。 やりたい（かった）こと 対象の配列が巨大な場合と、小さい場合それぞれにおけるベンチマークをとりたい ただし、あまり高速過ぎるとよくわからない結果になるので、配列が小さい場合にはループ回数を増やして最終的な配列の処理レコード数を同じにする composer使ってゴニョゴニョの練習 しかしながら、Laravel(Illuminate\Supportパッケージ）のインストールができなかったのでこちらに関してはSkip

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Memcachedと、一般的なクライアントライブラリを用いた時の問題を 本当は怖いMemcached としてまとめました。 その時の結論としては「お手軽にMemachedを冗長化したいんだったらKyotoTycoonの相互レプリケーション機能を使うのがいいよ。」でしたが、多少のパフォーマンス劣化を許容できるのであれば、Memcachedでも信頼性を担保出来るやり方がありましたので、その記事になります。 この方式は過去に実際に利用したことのある方式に少し手を入れてデータ削除時の不整合発生を抑制する方式になります。 前回の記事の補

はじめに データアクセスの高速化、セッションの保持などに非常に重要なポジションを占めているMemcached 特徴をあげると、速い安い美味いで、AWS上のサービス化などされており、非常に扱いやすいプロダクトなのですが、Memcachedそのものが単一障害点とならないように冗長化を測った時に深刻な問題が発生する可能性があることをご存知でしょうか。 システムに心あたりがある方は今すぐ代替手段を検討しなければなりません。 どうしてもMemcachedを使いたいという方はこちらへ それでもMemcachedを使いたいあなたへ 前提条件 そもそも冗長化をしなければ問題ないという運用はその時点で怖いのでNG cache機構という性質上、データが飛ぶのは問題ない(”正”となるデータを他から読み出すだけ)が、誤ったデータが読み出されるのをNGとする Memcachedを利用した時に利用ノードを決定するのは

はじめに 各種のDB中の集計作業を行うにあたって、以下のようなデータをどうしても扱わなければならない場合は、SQLのみで完結させないことを検討しなければ、サーバリソースを大量に消費した挙句、何時まで経っても作業が完了しないということが有ります。 SQL操作だけに頼らないことを検討したい集計例 explainすることで大体の傾向はわかりますが、おおよそ以下のような要素を含む集計が対象となります。 対象のレコード数が巨大である（数百万レコード以上） DBの余剰リソースにもともと余裕が無い indexのふられていない項目で集計/joinしなければならない join対象の項目がやけに多い not in 巨大なサブクエリ is null group by like etc... ではどうするか？ 集計対象のレコードを一旦ファイルに吐き出した上で、ファイルベースの処理をしてしまいましょう。 実践例1