該当する記事が見つかりませんでした。

スライダーを表示するには最低5件記事が必要です。

SSH 時にリモート先でコマンドを実行する

Install sshrc# wget https://raw.githubusercontent.com/Russell91/sshrc/master/sshrc && chmod +x sshrc && sudo mv sshrc /usr/local

DBストレージエンジンまとめ

Archiveデータのアーカイブに最適されている。 テーブルデータを圧縮してディスク上でのデータ格納量を低減することを目的としたストレージエンジン。 クラスタや、トランザクション、インデックスがサポートされていない、INSERT と SELECT をサポートされているが、DE

サーバーの容量がいっぱいになったときの対処方法

ルートディレクトリからさg

SIGMA初のミラーレスカメラの sd Quattro H を買ってみたので作例を交えてレビューしてみる

社会人になって初めての記事です。毎日決まった時間に起きるというのは大変ですね。普段持ち歩くカメラが欲しいなと思って今回は sd Quattro H を買いました。購入してから2ヶ月経ったので購入レビューとか書いてみようと思います。  SIGMA のボディ(コンデジ)についてセンサーの違い他社の一般的

OPPO R11s の優秀と言われるカメラ性能は本当に優秀なのか #撮らずにはいられない #OPPOカメラフォン #r11s

OPPO R11s の体験みたいのを申し込んだら当たったのでレビューしてみようと思います。 特徴的なのは「カメラ」だそうです。テスターの際に「#撮らずにはいられない」、「#OPPOカメラフォン」をつけてツイートしてねって言われているぐらいです。 ということで今回はカメラを重点的にレビューしたいと思います。   スペック OS種類 ColorOS 3.2(based on Android7.1) キャリア SIMフリー CPU Snapdragon 660 SDM660 CPUコア数 オクタコア 内蔵メモリ ROM 64GB RAM 4GB インターフェース microUSB 外部メモリ最大容量 256 GB バッテリー容量 3205 mAh(交換不可) 画面サイズ 6.01 インチ 画面解像度 2160×1080  パネル種類  AMOLED  無線LAN規格  802.11 a/b/g/n/ac  背面カメラ画素数  2000 万画素  前面カメラ画素数  2000 万画素  手ブレ補正  –  4K撮影対応  –  耐水・防水機能  –  おサイフケータイ/FeliCa  –  認証機能  指紋/顔認証  デュアルSIM  ○   デュアルSIMデュアルスタンバイ(DSDS)  –  幅x高さx厚み  75.5×155.1×7.1 mm  重量  153 g 値段 62,510円(2018/03/19)     開封~付属品 SIGMA sd Quattro H (30mm, f/2.8, 1/160 sec, ISO100) シンプルな外箱でかっこいい   SIGMA sd Quattro H (30mm, f/5.6, 1/50 sec, ISO100)紙2枚、SIMピン、透明ケース 製品版でも最初からケースが付属されています。   SIGMA sd Quattro H (30mm, f/5.6, 1/50 sec, ISO100)イヤホン、マイクロUSBケーブル、USB電源   液晶の発色が綺麗 SIGMA sd Quattro H (30mm, f/7.1, 1/30 sec, ISO100)OPPO R11s の液晶タイプが AMOLED…

買わない理由が分からないくらいコスパが最高で軽くて小さい、PENTAX K-70 をレビューしてみる 作例もあるよ

ちょうど半年前に SONY α7II から PENTAX K70 へと交換しました。 フルサイズを使っているときに、「別にこれフルサイズじゃなくても撮れる画像しか撮ってねえ」と思ったのがきっかけです。 PENTAX K-70 にした理由はコスパが良いなと思ったぐらい。 PENTAX のセンサーから出る画像も見ずにただただ K-70 を買いました。 買って大正解なボディでした。 最後に作例も載ってるので見てみてください。   スペック タイプ 一眼レフ 映像素子 APS-C 画素数 2424万画素 ファインダー形式  ペンタプリズム 手ブレ補正  4.5段 防塵・防滴 ○ 幅x高さx奥行き 125.5x93x74 mm 重量  628 g 価格 61,361円(2018/03/13)   メリット1:手ブレ補正 PENTAX K-70 はボディ内手ブレ補正が乗ってます。 オールドレンズと言われる昔の Kマウントレンズが使えたり、 m42 レンズでもボディ内手ブレ補正が発揮される。 Kマウントレンズだけじゃなくて、マウントアダプターを使えば m42 レンズが使えるのが素晴らしい。オールドレンズにはレンズ内手ブレ補正がないので僕が感じるメリットと言えばこの辺。   メリット2:防塵・防滴 この価格とこの重量で防塵・防滴! WR と書かれたレンズは簡易防滴のあるレンズです。 山とか登る人は PENTAX 一択ですね!   メリット3:サイズ、重量もコンパクト これだけの機能があって、コンパクトで軽い!   メリット4:Kマウントレンズに良いのが多い Kマウントレンズって、Eマウントと違って安いんですよ。 の割にいい写りをしてくれるレンズもたくさんあります。 スナップで使えそうな単焦点では HD PENTAX-DA 35mm F2.8 Macro Limited もうちょい行くと smc PENTAX-DA★ 55mm F1.4 SDM さらにもうちょい行くと smc PENTAX-D FA マクロ 100mm F2.8 WR 中でも FA Limited シリーズのレンズは 2002年発売にも関わらず未だに人気で FA 31mm F1.8 AL Limited となると10万超えます。   デメリット1:ない ない   作例 中でも DFA Macro 100mm 一番大好き 程よい解像度に、程よい柔らかさ。何でも撮れちゃうレンズです。人を撮るならこのレンズが良いと思った。人を撮って思ったけど自分にセンスはないと思ったので今後は動物、植物が増えると思う。 DA★ 55mm は安定した描写で人にも使える感じなのでオールマイティーな中望遠レンズとして最高です。

Goを使って画像の類似度を超簡単に行う / perceptual(image) hash

コンビニの有人レジがすごい混んでるのに、セルフレジを誰も使わない日本人を理解できない長谷川です。 概要 2つの画像の類似度を算出したい。 得られるハッシュ値は64bit 対象は静止画, 画像, 音声等のマルチメディアデータ コンテンツ内容が類似しているケースでハッシュを得た場合、例えば静止画画像の拡大、縮小といった加工の場合ハッシュ値が全く同じになる また、色調の修正やノイズが加わった場合も得られるハッシュ値間のハミング距離が近くなる 64bitのハッシュ値なので最も遠いハミング距離は64 (=全くコンテンツが異なっている) 逆にハミング距離が0であればperceptual hashで得られた結果上は同一コンテンツ こういった特徴があるため具体的にWebアプリケーションでの用途を考えると コンテンツの重複判定 類似画像検索 などに使えそうというのは上の特徴でわかるのではないでしょうか。 引用元:http://hideack.hatenablog.com/entry/2015/03/16/194336 計算方法もいくつか種類があります。 ・aHash:画像の平均輝度からの差分を使った方法 ・pHash:画像を離散コサイン変換(DCT)し周波数領域に変換後、低周波領域に対してaHashと同じ方法で算出する方法 ・dHash:隣接領域との差分を使った方法 ・wHash:pHashのDCTの代わりに離散ウェーブレット変換(DWT)を用いた方法 参考:http://tech.unifa-e.com/entry/2017/11/27/111546 ここでは aHash と dHash を使ってみようと思います。 使用したライブラリはこちら https://github.com/devedge/imagehash   実装 [crayon-5b7b26b3ccbc7372505175/] imagehash.Ahash を imagehash.Dhash にするだけで aHash から dHash に切り替えることができます。   aHash と dHash の比較 こちらのサイトによると、dHash は aHash と同じ速度にも関わらず、精度が良好らしいです。 ちなみに2つの画像の distance(違う画像だと数値が大きい) を求めるには 2つの []byte をループさせて比較して値が違う場合に +1 すればいいだけです。 [crayon-5b7b26b3ccbcd006253360/]   試した画像 laptop1.jpg laptop2.jpg iqos.jpg laptop1.jpg と laptop2.jpg は似たような画像(若干右にズレてます)、 iqos.jpg は全く違う画像を用いりました。   aHash 平均輝度の差分を使った超シンプルな方法 スマホで撮影した画像の場合、撮影時にタップした場所によって露出が変わるためスマホの画像を取り扱う場合には不適切なような気がする。 [crayon-5b7b26b3ccbd1333023843/]   dHash 隣接領域との差分を使った方法でシンプルで精度も、速度も良いらしい。 グレースケールに変換した後、9×8サイズに縮小する。 右隣のピクセルと値を比較して大きければ1 同じか小さければ0 0を黒、1を白に置換し、1pixelを1bitとして、16進数に変換することで値を取得できる。 aHash と違い、輝度ではなく実際にピクセルを見るので精度が良いと言われるのも分かる。 [crayon-5b7b26b3ccbd5756433169/] aHash と dHash の比較をしてみたけど精度にそこまでの差を見つけられなかった。 まあ今回用いた画像が悪かった。 distance だけを見ると、dHash の方が粒度が高いように見えるけど似たような画像と、アイコスと1枚目の差が 4 しかない。 しかし、aHash では差が 5 ある。 しかも1000回ループした結果では、aHash の方が16秒速い。 全く違う iqos.jpg でも真ん中にディスプレイがあり、dhash の手法だと白黒に変換したタイミングで同じような結果となってしまい、たまたま aHash と差が内容になってしまったと推測。 どちらを使うにしても distance の閾値を適切に設定する必要性がありますね。 もっといろんな画像で試してどっちを使うか決めたいと思います。

AWS-SDK-Goを使って、ユーザーが投稿したファイルをS3から削除してみる

はじめに S3でユーザーが投稿した画像を管理している場合、ユーザーがアプリを退会した際にユーザーに関する情報、S3からもユーザーのファイルを削除する必要性があります。 S3上のプレフィックスは userID/ となっており、全体のキーはbucket/userID/fileName.jpg となっています。   問題点 AWSの制約上、bucket/userID以下にファイルが1つでもあると、 いきなりbucket/userIDを削除することはできません。 加えて、リストを取得するListObjectsでは1度に1000個のキーか取得することができず、 オブジェクトの削除を行うDeleteObjectも1度に1000個のキーまでしか指定できません。 もしユーザーが1000個以上のファイルをアップロードしている場合、 一筋縄ではいかないため工夫する必要性があります。   コード   解説 ユーザーが投稿したファイルを全て取得する [crayon-5b7b26b3cce28176383951/] 最初のリクエストをする際に、Delimiter: aws.String(userID + "/"),をつけてリクエストをすることで、レスポンスにIsTruncatedが含まれています。 IsTruncatedがtrueだと全てを取得できず、まだ残りのオブジェクトがある状態 falseだと全てのオブジェクトを取得できた意味をします   [crayon-5b7b26b3cce2f755659163/] 最初のリクエストでIsTruncatedがtrueの場合、 NextMarkerがレスポンスに含まれているのでこれを次のリクエストに含めておきます。 ループの中でこれらを繰り返しておき、 IsTruncatedがfalseになった時点で終了。この関数では[]stringを返します。   オブジェクトを削除する [crayon-5b7b26b3cce33184874131/] 関数全体↑   [crayon-5b7b26b3cce37810758631/] getAllObjectで取得したキーが入った配列の長さが1000以上だった場合、 先程述べた様に、1度のリクエストで削除できるキーが最大1000のため配列を分割する必要性があります。   [crayon-5b7b26b3cce3a815680406/] func chunk()では1000要素以上の配列に入ったキーから1つの配列が1000個未満のキーとなるように複数の配列に分割して[][]stringを返します。   [crayon-5b7b26b3cce3e005116055/] この分割された[][]stringをfor-rangeでループさせ、画像を削除していきます。   [crayon-5b7b26b3cce41625655809/] bucket/userID 以下のファイルが0になったら、bucket/userIDを削除します   使い方 ちなみに画像数が5,000枚レベルになると、マシンのスペックにもよりますがAPIサーバーからアプリへレスポンスを返すまでに1分程度、かかってしまいとても使えたものではありません。 なので、今回はDBからユーザーの情報を削除する部分はGoroutineで制御し、 このS3から画像を削除する部分はレスポンスを返した後に実行されるようにしてみました。 [crayon-5b7b26b3cce44445040833/] DBからユーザー情報を削除する部分はerrgroup(goroutine)で制御を行って、 エラー処理ができるように。全ての処理が終わったあとに、   [crayon-5b7b26b3cce47205359953/] WaitGroupをインクリメントしておき、wg.Wait()をせずにそのままreturn nilでレスポンスを返します。 ただ、これを行うとS3から画像を削除する部分でエラーを起こるとユーザーへ通知できなくなってしまうので、Slackへ通知するようにしてます。 (そして手作業で該当ユーザーのファイルを削除していく…)   おわり Go言語に自信が全く無い素人のコードを晒して大変恐縮していますが もし間違いや、こうした方がいいのご指摘がありましたらぜひコメントしていただけると本当に幸いです。