Blog

ブログ

人の意見を聞くことの大切さ

どうも、モリタです。
こんにちは。

意味をちゃんと調べることなく、生きていく中でなんとなく覚え、なんとなく使っている言葉は結構多いのではないでしょうか。

今日はそんなお話です。

先日、MySQLでテキストが保存されたカラムに対してLike検索することを「全文検索」と呼んでいたら、複数の人から「それは違う」と指摘されて、エンジニア生活10年間、ずっと間違えて使っていたことにショックを受けました。

私はいままで、全文検索の手段としてLike検索を使うのか、全文検索エンジンを使うのか、はたまた転置インデックスを自作するのか、と思っていたのですが、どうやらRDBMSでは転置インデックスを使った検索のことを「全文検索」と言うらしいのです。

(ここで納得してしまった人は最後まで読まないと危険です)

これまで、「全文検索」についてしっかり調べたわけでもなく、エンジニアになって会話の文脈からなんとなく意味を把握し、特に疑問を持たないまま使っていたので、「あー、そーだったのかー」とその時は納得しました。

だがしかし、「全文検索」という日本語からしてLike検索が全文検索ではない、というのがどうもしっくりこなくてモヤモヤが膨らんでいきました。

なのでちゃんと調べてみることにしました。こういうときはウィキペディアが頼りになります。

 

全文検索(ぜんぶんけんさく、英: Full text search)とは、コンピュータにおいて、複数の文書(ファイル)から特定の文字列を検索すること。「ファイル名検索」や「単一ファイル内の文字列検索」と異なり、「複数文書にまたがって、文書に含まれる全文を対象とした検索」という意味で使用される。

 

ん?ちょっとまてよ?

私の認識は間違ってないんじゃないか?

ウィキペディアをもう少し見てみます。

 

全文検索技術
grep型
・・・中略・・・
索引(インデックス)型
・・・中略・・・

 

Likeはgrep型だろうなあ。

 

・・・

 

確信しました。

私の認識は間違っていなかった!!

結局、Likeだろうがインデックス使おうが、全文に対して行う検索は全文検索なんですね!!

ちゃんと調べて良かったー。

 

調べていく中で、「全文検索=インデックス型の全文検索」として扱っている記事が沢山ありました。

言葉は、勘違いや間違いが元で変化していくものだと思うので、多くの人の認識を正とすれば良いと思いますし、日常生活におけるコミュニケーションでは、話が噛み合っていなくてもそれほど大問題になることはないでしょう。(男女関係は別として)

しかしそれがシステム構築となると話は別です。(ビジネスなら何でもそうだと思いますが)

認識の齟齬が重大なバグを生み出すことになるかもしれません。

プロジェクトの全員が同じ認識でいるかどうかを把握するのは難しいと思います。

ただ、少しでもおかしいと思ったら迷わず確認するのが大事だなーと改めて感じました。

そして伝える時は「全文検索」と言う漠然とした言い方ではなく、「likeを使った全文検索」などと具体的に言うように心がけようとも思いました。

 

若い時は人の意見はあまり聞き入れず、自分が正しいと思ったことは貫き通していましたが、年を重ねるごとに、なるべく人の意見を聞くように心がけていました。

それが災いした今回の事件でした。

これからは人の意見を聞かないようにしたいと思います!!!(嘘)

 

初詣

あけましておめでとうございます!!

 

新年初のブログ更新でございます!

 

 

さて今日のブログは

 

今年初のイベント!

 

会社のメンバーで赤城神社に初詣に行ってきました!

会社の近く、新松戸駅付近にある神社です。

 

天気も良く最高の初詣になりそうな予感です。

 

 

さて、まずは詣でる前に社長が清めます。

これで完全に清まりました。日本語変ですが気にせず行きましょう。

 

ようやくメインイベントです。

 

 

 

詣でましょう。

 

それぞれの想いを胸に、みなさん階段を登って行きます。

 

まずは副社長

 

続いて社長

 

染谷さん

 

鈴木さん

みなさんきっと会社がさらに成長できるようお祈りされたことでしょう!!たぶん!!

 

そして恒例のおみくじをやって、甘酒でも飲んで語らう予定でしたが、、、、

 

 

 

あれ、、?

 

もしや、、、、?

 

 

 

「ないんかい!!」

 

そんなものはありません!!なかった!!

 

そうです。きっと必要ないのです!!!

 

我々は初詣に来たんですから!!!!

 

遊びに来たわけじゃあないんだ!!詣でに来たわけですから!!

 

 

でもやはり来てよかった!!

 

新年1発目のイベントとして楽しかった!!

 

大盛り上がりでした!!たぶん!!

 

今年もどんどん盛り上げていきたいと思います!!!!

 

ということで本年もジョーレンをよろしくお願い致します!!

 

 

 

 

 

 

 

事務所を引っ越しましたPART2

昨年夏から借りていたオフィスが手狭になったため、新しいオフィスに引っ越しました。

 

順調に事業拡大しております!

みなさまのお陰でございます!ありがとうございます!

 

今度は隣にラーメン屋があるのでいつでもラーメンが食べられます。

(引っ越してから一回も行ってない)

 

大きな観葉植物なんかも置いちゃってちょっと洒落っ気を出しています。

(実は以前も小さいものがあったのですがすぐに枯らしてしまいました・・・)

 

スペースにまだ余裕があるので、丸テーブルなんかを置いてちょっとした休憩やミーティングスペースを作りたいなーと思ってます。

 

写真は今度さとーくんがあげてくれると期待して、私からは以上です。

 

まとまりのない文章を投げる勇気!

初めましての人もそうじゃない人も初めまして!僕です!
最近、joolenに入社しましたおっさんエンジニアのさとーです。
現在の仕事は腰痛めてそこからの足の神経痛で痛そうにして
皆様から生暖かい視線を頂きながらぽちぽちPHP書いたりしてます。
皆様腰は大事にしましょう!

PHPのお仕事をしてるのでPHPのこと書こうと思ったのですが
てきとーに検索して見つけた技術ブログをてきとーにコピペするだけで終わりそうなので
そちらは他の人にぶん投げて違うことを書かせて頂きます!


自分の経歴だと開発系よりセキュリティエンジニアの方が長いのでそちらの話です。
僕はセキュリティエンジニアとして主にwebの脆弱性診断をやっていました。
難しいことは偉い先生に任せて、webの脆弱性診断を簡単に説明すると
お客様のサイトを実際に攻撃して成功したらその箇所を報告するお仕事でした。

自分がセキュリティエンジニアになった当時は色々なサイトで脆弱性が見受けられましたが
最近は開発してる方のスキルやフレームワークの進化で少なくなってると思います。
実際に最近のセキュリティの問題になっているのも、話題になるのも技術的なものより
パスワードリストによる不正アクセスや標的型攻撃メールなどの方が多い気がしますですはい。

パスワードリストによる不正アクセスに関しましてはとある大企業様で働いてる時に
実際に攻撃されて対応をしたのですが、ログイン成功率が平均1/3〜1/5ぐらいで
世の中どっから情報漏れてるのこえーと思いましたまる

くっそ長文になってしまったのでまとまりないのですが本日はここまでにします。
ネタをあまり考えずノリで書いたてました反省します。
こんな具合にセキュリティのお話やら何やらを軽い感じで書いていこうと思ってますので
よろしくお願いします!それではまた!

AWSでWordPressの管理画面にログインできない

AWSでWordPressを構築する場合に行ったHTTPSのトラブルシュート

初めまして。Joolenで修行中の修行僧 おおたに です。修行のために頭を丸めました。

突然ですが、AWSでWordPressを構築する場合に行ったHTTPSのトラブルシュートについて、全世界に向けて絶賛公開いたします!!
(もったいぶらないで、回答からいくスタイルです)

[現象]

・Amazon EC2にWordPressをインストールすると管理画面でログインできない。
または、管理画面自体が表示されない。

[環境]

・サーバー:Amazon EC2

・外部からはELB(ロードバランサー)へHTTPSでアクセス

・ELBからEC2へはHTTPでアクセス

[解決策]

次の2点(1.と2.)を実施します。
セキュリティに関する設定になりますので、ご使用は自己責任でよろしくお願いいたしますm(_ _)m

1. WordPressの URL設定を変更する

<①ELBのHTTPS制限を一時的に無効にしても構わない場合>

HTTPS制限を解除すれば、WordPress管理画面へHTTPアクセスできます。管理画面へログインし、[設定]で次の2点を変更します(「WordPressのURL」は各自の環境に合わせて変更してください)

  • WordPress アドレス(URL):https://WordPressのURL
  • サイトアドレス(URL):https://WordPressのURL

変更が終わったら、解除していたHTTPS制限を元に戻すのをお忘れなく

<②ELBのHTTPS制限を無効にできない場合>

HTTPS制限があると、WordPress管理画面にログインできないので、DBを直接操作して、次の2文を実行します(「DB名」と「WordPressのURL」は各自の環境に合わせて変更してください)

  • 「UPDATE DB名.wp_options set option_value=’https://WordPressのURL’ where option_name=’siteurl’;」
  • 「UPDATE DB名.wp_options set option_value=’https://WordPressのURL’ where option_name=’home’;」

2. HTTPアクセスをHTTPSアクセスと認識させる

 WordPressのPHPファイルを編集します。

[wordpressインストールフォルダ/wp-config.php]の下の方に書いてある[require_once]文より上に、
次のif文を追記します。

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
          $_SERVER['HTTPS'] = 'on';

これで、解決できます。お疲れサマでした。南無阿弥陀仏♪

[参考ページ]

https://codex.wordpress.org/Function_Reference/is_ssl

[原因の解説]

ELBでHTTPS制限している場合は、外部からのアクセスはHTTPSに制限されますが、内部アクセスはHTTPに変わります。このため、WordPressへの内部アクセスはHTTPになります(ここがポイントです!)

WordPressがHTTP設定の場合、外部からのアクセスはHTTPSなのに、WordPressが生成するアドレスはHTTPになるため、ブラウザがセキュリティエラーを出して、[管理画面にログインできない]状態になります。

また、WordPressがHTTPS設定の場合、HTTPアクセスが来るとHTTPSアクセスへ変更してリダイレクトする仕様のため、リダイレクト無限ループが発生して、[管理画面自体が表示されない]状態になります。

■リダイレクト無限ループ

①WordPressがHTTP(内部のアクセス)をHTTPSへ変更してリダイレクト

②リダイレクトされたHTTPSを、ELBがWordPressへHTTPとして渡す(->①へ戻る)

WordPressがリダイレクトするコードはwp-login.phpファイルの先頭あたりに書いてあるので、見てみると面白いと思います。

それではまた。次回の投稿にご期待ください。南無阿弥陀仏♪

新事務所の近所で中華ランチ

新しい事務所になって、近所に飲食店が沢山あるのでいろいろ開拓しています。

ついに先日、ここはうまい!という店を見つけたので紹介します。

辣腕 https://tabelog.com/chiba/A1203/A120302/12034589/

立地が悪く、オープンから一年も経ってないということもあって、食べログの評価はいまのところ一件だけです。

知る人ぞ知る店って感じかもしれません。

しかし、お昼時は(きっと)いつも賑わっています。

私は担々麺のランチセットを頂きましたが、過去最高に美味かったです。

品のある味がしました。仕事が丁寧なんでしょうね。

お店の中も小洒落た感じで、街の中華料理屋って雰囲気ではないです。

新松戸にお越しの際は是非。

img_2111

※写真が食事中で申し訳ございません!

向かいの人が食べているのは陳麻婆豆腐です。

山椒タップリで美味しそうでした。

あー、書いてたら腹減ってきた・・・

事務所を引っ越しました

今更ですが、7月に事務所を引っ越しました。

一階がすき家なのでいつでも牛丼が食べられます。

(しかしながら、まだ3回しか行っていない)

 

事業拡大する前提で少し広めのところを借りました。

あと4、5人は入りそうです。

来年には手狭になるように頑張ります。

 

北小金でフレンチランチ

妻の誕生日だったのでフレンチレストランへランチに行きました。

北小金界隈ではちょっと有名なお店です。モン・ラパン

(私は食べログよりぐるなび派です)

 

ランチにしては贅沢にフルコース。

子供なしでゆっくりできるのは平日の日中くらいなんで。

 

IMG_1722

 

私はグルメレポーターではないので細かいコメントは差し控えさせていただきますが、

とっても美味しかったですー。

お近くの方はぜひ一度お試しくださいませ。

(メインディッシュの写真を撮り忘れるという失態を犯しました)

ECCUBE3でセッションが切れる?

eccube.CRITICAL: RuntimeException: Failed to start the session (uncaught exception) at /var/www/eccube/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php line 149 {“exception”:”[object] (RuntimeException(code: 0): Failed to start the session at /var/www/eccube/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php:149)”} []

システムエラー画面になってシステムログにはこんなエラーがでていた。

apacheエラーログは以下の通り。

PHP Warning:  session_start(): Failed to decode session object. Session has been destroyed in /var/www/eccube/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php on line 148

セッションオブジェクトをデコードできないってことなので、とりあえずセッションのデータを見てみることに。

結論から言うと、セッションデータがでかすぎて欠落した値がDBに保存されていたことが原因。

eccube3.0.8だったのでセッションはデフォルトでDBに保存される。(3.0.10ではファイルに変更されている模様)

解決策としては

  1. dtb_session.sess_dataの型をblobからmediumblobに変更
  2. 保存先をファイルに変更

が考えられるので今回は1で対応。

因に、my.cnfに「sql_mode=STRICT_TRANS_TABLES」を設定するとblobのままでも欠落した値が挿入されることは無く、

(恐らく値が更新されないので)上記エラーは起きなかった。

そもそも、セッションにCustomerエンティティとそこから紐づくエンティティが保存されるらしく、

それを知らずにリレーションしまくると大変なことになりそう。

(今回はカスタマイズでいろいろリレーションしていた)

紐づくエンティティーでも保存される物とされない物があり良くわからんのですが・・・

引き続き調査は続く。